OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

I think you are right, in the general case, the action / getMarkup
processing needs to be separate operations, only in special cases the
optimization to do processAction/getMarkup in one step is possible.

Best regards,


"PAVLIK,GREGORY (HP-NewJersey,ex2)" <gregory_pavlik@hp.com> on 04/15/2002
09:17:13 PM

Please respond to "PAVLIK,GREGORY (HP-NewJersey,ex2)"

To:    "'Michael Freedman'" <Michael.Freedman@oracle.com>, "PAVLIK,GREGORY
       (HP-NewJersey,ex2)" <gregory_pavlik@hp.com>
cc:    Carsten Leue/Germany/IBM@IBMDE, wsrp@lists.oasis-open.org
Subject:    RE: [wsrp][interfaces]: Actions vs. Events

I imagine that the intent is to have semantically separate notions
explicitly in the API? It seems like cleaner code in the portlet
implementation if the event handling and action handling operations are
distinct since they are likely to have different kinds of representations.

Regardless of whether you separate actions and events into distinct
operations, we still require the same "two phase" approach to executing
actions and collecting markup if we allow actions to generate events. I'm
not sure this is really an exceptional case. It seems to me that this is
kind of thing we'd like to do routinely to allow services to be combined in
portals to create new an interesting kinds of applications.


-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: Monday, April 15, 2002 2:58 PM
To: PAVLIK,GREGORY (HP-NewJersey,ex2)
Cc: Carsten Leue; wsrp@lists.oasis-open.org
Subject: Re: [wsrp][interfaces]: Actions vs. Events

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

"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
> of first portlet.
> The user is not interested in any of the intermediate states or markup
> 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
> 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
> 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
> 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
> 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
> > and redirect them to the aggregator. The end user can click on the
> to
> > trigger such an action. The aggregator then intercepts this and issues
> > call to the action handler defined in the WSRP interface together with
> > data the service encoded in the markup. As a reaction to this action
> > 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
> in
> > the markup
> > - the end user triggers the actions
> > - there is only one consumer of an action: the service that embedded
> > action into the markup
> >
> > 2. Event:
> > Events are launched programatically by components (the aggregator or
> 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.
> > 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
> > 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
> > but leave it up to the service to support this feature.
> > Action handling however is abosultely essential for user interaction.
> > this reason it makes sense for me to include this functionality into
> > 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>

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