Title: Message
To add to that point and to the ongoing discussion around actions and
events, I would also second the opinion that trying to capture and define
complete semantics for actions and events (=a complete programming model for
portals and portlets) should be beyond version 1.0 of the
spec.
It seems to me that it's slightly optimistic to believe that WSRP 1.0
will be rich enough so that all vendors will be able to actually convert all
their portlets to be WSRP-only, and to develop all their new portlets as
WSRP-only portlets. I think we will be in a good shape even if v1.0 will
allow interoperability, namely: the ability to publish every
portlet as a WSRP portlet, and for all portal vendors to consume WSRP portlets,
even if the proprietary APIs that the vendors have (or additional APIs on top of
WSRP 1.0) will still be used for advanced functionality such as event routing,
etc.
Trying to define complete run-time semantics around event and action
handling is not only complex (and hence frameworks such as Struts, etc.), but it
is controversial whether there can ever be a single standard for those. Not only
that, it seems that even if we define an event routing mechanism,
it would still only allow portlets that "know about each other"
(code-wise) to communicate. This translates to, more or less, portlets from
the same vendor. This case can be solved without tackling the hard
questions - such as if the portal passes an opaque PageContext, or with a
packaging mechanism that allows portlets from the same company to know about
siblings on the same page.
This is not to say that events are not a useful concept. However, for
real inter-vendor usability we would need a mechanism beyond simple pub/sub of
opaquely defined events.
Hence, it may be useful to stick to a simple and abstract definition
of an action (which in the end of the day translates to a user action), and
leave event semantics to v2.0.
Eilon
-----Original Message-----
From: Rich Thompson
[mailto:]
Sent: Thursday, April 25, 2002 8:13
AM
To: WSRP
Subject: RE: [wsrp][interfaces]: Actions vs.
Events
I would disagree that an action is a notification that the
service's state
has changed. The invoker has no means
of knowing that any state change has
occurred ... an
example where it hasn't would be a button pressed that just
results in an action being invoked. At the point of the action
being
invoked, there has been not a state change for
the service (though there
likely will be as a result
of the action's execution). That is why I
proposed an
action definition that centers around it being a request for
the service to do something ... there may be state changes involved
both
before and after the action is invoked, but they
aren't central to defining
what an action is.
Jeff
Broberg
<jbroberg@silvers
To: Michael Freedman
<>, Rich
tream.com>
Thompson/Watson/IBM@IBMUS, WSRP
<>
cc: Denise Dean
<>
04/24/2002 09:37
Subject: RE: [wsrp][interfaces]: Actions vs.
Events
PM
Please respond
to
jbroberg
i have updated the glossary for these modified terms and will
be sending
the latest version out to the group either
wed or thu of this week.
jeff
-----Original Message-----
From: Michael Freedman [mailto:]
Sent: Wednesday, April 24,
2002 6:03 PM
To: Rich
Thompson; WSRP
Subject:
Re: [wsrp][interfaces]: Actions vs. Events
Rich,
I like your idea that
given we have many descriptions on the table
we should see if we can solidify the
discussion by first defining
terms. Once we have a good
definition of terms we can then more
effectively discuss requirements. I
think your definitions are a good
start but might be improved if made more
concise. What do you think
of the following definitions:
Action: a notification that
your state has changed.
There is only one recipient of an action. This recipient is
identified in the action request. For example, a portlet
encodes an action in the URI of its form's "Submit" button.
This
URI (the action request) explicitly targets the receiver
(this portlet instance).
Event: a notification that some
state in the system (that you are
interested in) has changed.
There may be 0 to many recipients of an event. The recipient
of
an event is not identified in the event request. Rather,
event recipients are managed (by an event manager). An event
request is sent to/via the event manager which then dispatches
the
event notification to interested parties. I.e. the major
differences between an action an event is that event recipients
are
anonymous and a single event may be dispatched to many
portlets.
I believe the above clearly
defines the differences between actions
and events from the point of view of the
invoker. However it doesn't
address whether the recipient needs to
see actions differently from
events -- as "your state has changed" is
just a subtype of "state has
changed". I believe we
answer this by articulating the
requirements/constraints on action
handlers vs.
requirements/constraints on event handlers. As this message
is
about terminology I
will leave this discussion to another message.
-Mike-
Rich Thompson wrote:
I'm
not sure limiting event types to those published in
meta-data would
suffice. Consider the case of a Producer that provides a
redirection to
other services that it has been instructed to instantiate (or
maybe just
"contain"). The events such a Producer would publish are
dependent on the
indirect providers and therefore can not be published
statically. An
example of such a Producer could be a portal publishing a set
of
portlets
as a
WSRP service for other portals to consume.
While I consider events to a important to both the WSIA and
WSRP
standards,
I
would suggest not pushing them into the first versions of the
standards
as
the WSDL layer of the web services stack has these poorly
defined now
and
there are efforts to clean up that portion of the WSDL
spec.
Also, unless I missed it, I don't think I saw the terms action
and
event
being crisply defined. My suggestion:
Action - A request to a Producer to execute some
functionality.
Event - A notice from a Producer that some logical
transition has
occurred.
Jeff Broberg
<jbroberg@silvers To:
"Tamari, Yossi" <>,
tream.com>
cc:
04/22/2002 11:40
Subject: RE:
[wsrp][interfaces]: Actions vs. Events
AM
Please respond to
jbroberg
my
mistake, i meant it in the context of actions not events.
-----Original Message-----
From: Tamari, Yossi [mailto:]
Sent: Monday, April 22, 2002 11:27 AM
To:
''
Subject: RE: [wsrp][interfaces]: Actions vs. Events
I do
not know if I agree on this, since events are not
generated by the
user, but by other providers (in the context of the user).
Anyway, if a provider does not wish to process a certain event
in a
certain
context, it can ignore the event in runtime.
I
think that the overhead of implementing dynamic events may be
bigger than
the
overhead of having ignored events.
Yossi.
-----Original Message-----
From: Jeff Broberg [mailto:]
Sent: Monday, April 22, 2002 6:22 PM
To:
Tamari, Yossi;
Subject: RE: [wsrp][interfaces]: Actions vs. Events
I
can imagine a scenario where the events that a provider
allows for a
particular user is context based, so that one individual may be
able
to
perform some type of action while another can't. So we could
define the
availalbe events in the metadata, but we may have to also allow
this
info
to
be
dynamically generated and discovered.
jeff
-----Original Message-----
From: Tamari, Yossi [mailto:]
Sent: Monday, April 22, 2002 11:01 AM
To:
Subject: RE: [wsrp][interfaces]: Actions vs. Events
My
take on the registration issue is that the provider should
include the
list
of events/properties that it wants to subscribe to in its
metadata.
It
seems to me like this list does not need to be dynamic since
in
order to
process more events, more code needs to be written in the
provider.
The
place were loops may actually happen is when provider A
raises event X,
which causes provider B to raise event Y, which causes provider
A to
raise
event X again (for example). There are different algorithms
that
can
prevent
this, and maybe we should leave this to the implementing
portal. We could
define that the same event can not be fired by the same
provider more then
once
per request, and that the consumer is not required to
continue
processing events if the chain is deeper than some constant
number. I would
like
to hear other suggestions to solving this problem.
Yossi.
-----Original Message-----
From: Carsten Leue [mailto:]
Sent: Monday, April 22, 2002 5:43 PM
To:
Tamari, Yossi
Cc:
Subject: RE: [wsrp][interfaces]: Actions vs. Events
I
think that this would be a good solution for events to
decouple the
portlets and solve the problems that the portlets might not
"see" each
other through the firewalls. Furthermore it take the complexity
of
managing
listeners away from the services to the portal. I still see a
semantic
difference between actions and events but maybe we can unify
that. Some
open
issues are from my point of view:
-
visibility: per definition the portal has access to the
service (e.g.
though a firewall). The same is not necessary true for the
service that may
be
shielded from directly accessing the portal. If we unify
actions and
event we need
- a way for the services to register/unregister
themselves as
listeners passively without initiating a communication to the
portal (e.g.
in
the return values for the markup call)
- is it also possible to trigger events passively?
-
chaining: a portlet that has been integrated in a portal
might be
republished and reintegrated by another portal
- register/unregister requests for listeneres need to be
delegated to
both
portals
- how can loops be avoided in such cases?
Best
regards
Carsten Leue
-------
Dr.
Carsten Leue
Dept.8288, IBM Laboratory B鐽lingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+----------------------------->
|
| "Tamari,
Yossi" |
|
|
<yossi.tamari@sapp|
|
|
ortals.com> |
|
|
|
|
| 04/22/2002
03:31 |
|
|
PM
|
|
| Please respond
to |
|
| "Tamari,
Yossi" |
|
|
|
|---------+----------------------------->
>
---------------------------------------------------------------------------
------------------------------------------------------------------|
|
|
| To:
|
| cc:
|
| Subject: RE: [wsrp][interfaces]:
Actions vs. Events
|
|
|
|
|
>
---------------------------------------------------------------------------
------------------------------------------------------------------|
This
is what I had in mind as well. If different producer want
to
communicate directly, they can do this regardless of WSRP.
What
is needed is some variation of a publish/subscribe (with
data)
mechanism managed by the consumer.
Yossi.
-----Original Message-----
From: PAVLIK,GREGORY (HP-NewJersey,ex2) [
mailto:]
Sent: Monday, April 15, 2002 10:20 PM
To:
'Alan Kropp'; 'Carsten Leue';
Subject: RE: [wsrp][interfaces]: Actions vs. Events
that
would be preferrable.
-----Original Message-----
From: Alan Kropp [mailto:]
Sent: Monday, April 15, 2002 3:16 PM
To:
'Carsten Leue';
Subject: RE: [wsrp][interfaces]: Actions vs. Events
Hi
Carsten,
On
the subject of event handling, could we simplify the
scenario a bit by
allowing the portal to act as the intermediary in event
propagation? I'm
thinking of a publish/subscribe model (somewhat like JMS), in
portlets
which
support events "publish" those events to the portal, and
portlets which
consume events inform the portal by subscribing for those event
types. The
portal acts as the intermediary, and neither event producers or
consumers
need
know specifically about each other.
Alan
-----Original Message-----
From: Carsten Leue [mailto:]
Sent: Monday, April 15, 2002 3:49 AM
To:
Subject: [wsrp][interfaces]: Actions vs. Events
Hi -
as promised in the interface call here is a definition of
what
I would
define as "actions" and "events". We might use this as a
starting point for
the
further discussion.
Both
actions and events are notifications for a WSRP service.
1.
Action:
Actions are notifications that are triggered by the user.
During the
creation of markup the service encodes special URLs in the
markup and
associates data to them.
The
aggregator may need to rewrite the URLs to make them appear
as
links
and
redirect them to the aggregator. The end user can click on
the
links to
trigger such an action. The aggregator then intercepts this and
issues a
call
to the action handler defined in the WSRP interface
together with the
data
the service encoded in the markup. As a reaction to this
action the
service may modify its state an regenerate its markup.
The
following points are important in this scenario:
-
the set of possible actions is defined by the server by
embedding them in
the
markup
-
the end user triggers the actions
-
there is only one consumer of an action: the service that
embedded the
action into the markup
2.
Event:
Events are launched programatically by components (the
aggregator or one of
the
services). Events are not directly represented in the
markup but issued
by
the components depending on their state (could be a timer, a
system
event or as a reaction to an action). Events can either be
broadcast to all
services or to a set of registered services.
The
following points are important in this scenario:
-
the set of receivers of events (listeners) is dynamic
- if
a service fires an event it needs to connect to the
listeners. This
might not always be possible due to firewall restrictions
- i
becomes possible to halt the system by (accidentally)
introducing
cycles in the event propagation
Following this definition event handling is much more complex
and
error
prone than action handling and the two serve different
purposes: user
interaction and notification.
3.
Relationship to WSRP
From
my point of view we should clearly distinguish between
action handling
and
event handling in WSRP. Event handling easily becomes very
complex and
is
not always required to support portal/portlet interaction.
Maybe we
should separate event handling out into an optional interface.
My
proposition would be to reuse the WSIA event handling
interfaces for this
but
leave it up to the service to support this feature.
Action handling however is abosultely essential for user
interaction. For
this
reason it makes sense for me to include this functionality
into
the
base
WSRP interface.
I
added a PDF document to further clarify the distinction
graphically.
(See
attached file: Action vs Event.zip)
Best
regards
Carsten Leue
-------
Dr.
Carsten Leue
Dept.8288, IBM Laboratory B鐽lingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
----------------------------------------------------------------
To
subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To
subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To
subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To
subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To
subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To
subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To
subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
