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

[Michael Freedman <Michael.Freedman@oracle.com>]

Carsten,
    Thanks for this write-up.  I better understand the differences between actions and
events.  What I don't understand is why action handling is absolutely essential.
Web/servlet programmers have gotten along fine without this abstraction for a long time
now.  And I don't see anything (yet) in how you have defined actions that provide
benefit over and above handling the action as part of a render/getmarkup.  And given
our performance concerns I imagine actions will either be defined to return markup --
i.e. they are another form of getmarkup/render.  Or "actions" will be modeled in the
producer as part of a producer side portlet container -- i.e. the portal makes a render
call but the producer side portlet container breaks this into an action call followed
by a render call.  This would seem to lessen the desirability of the abstraction.  Can
you motivate "actions" more?
     -Mike-

Carsten Leue wrote:

> 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
>
>   ------------------------------------------------------------------------
>                                  Name: Action vs Event.zip
>    Action vs Event.zip           Type: Winzip32 File (application/x-zip-compressed)
>                              Encoding: BASE64
>                       Download Status: Not downloaded with message