[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp][interfaces]: Actions vs. Events
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC