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>
