RE: [wsrp][interfaces]: Actions vs. Events

["PAVLIK,GREGORY (HP-NewJersey,ex2)" <gregory_pavlik@hp.com>]

that would be preferrable.

-----Original Message-----
From: Alan Kropp [mailto:akropp@epicentric.com]
Sent: Monday, April 15, 2002 3:16 PM
To: 'Carsten Leue'; wsrp@lists.oasis-open.org
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:cleue@de.ibm.com]
Sent: Monday, April 15, 2002 3:49 AM
To: wsrp@lists.oasis-open.org
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öblingen , 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>