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

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

In your example, why isn't an action just an event?  I have no problem defining
an event mechanism portlets can use in special purpose situations (such as you
suggest).  And I expect such events to fire in a phase before rendering occurs.
However, all this is going to make events a heavyweight operation.  My concern
is having us define a heavyweight mechanism that is mandated for use by all but
only really needed by the few.
      -Mike-

"PAVLIK,GREGORY (HP-NewJersey,ex2)" wrote:

> A simple scenario that may help clarify why actions and events should be
> separate from markup.
> 1) user submits action to portal initiating action/event phase,
> 2) portal submits action to portlet
> 3) action generates event consumed by another portlet,
> 4) second portlet generates event that is consumed by first portlet
> 5) action/event handling phase of portal is finished
> 6) portal calls getMarkup to retrieve markup corresponding to current state
> of first portlet.
>
> The user is not interested in any of the intermediate states or markup that
> might be generated as a result of these states, only the markup
> corresponding to the final state of the portlet.
>
> Greg
>
> -----Original Message-----
> From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
> Sent: Monday, April 15, 2002 2:26 PM
> To: Carsten Leue
> Cc: wsrp@lists.oasis-open.org
> Subject: Re: [wsrp][interfaces]: Actions vs. Events
>
> 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
>
> ----------------------------------------------------------------
> 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>