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


you have a different notion of actions - actions as discussed so far are
not for getting views - actions are for letting the WSRP service know that
a user interaction requires an action to be performed on the WSRP service's
side - returning markup with the processAction response.is only an
optimization that is possible if the state of the WSRP service may not
change betweeb the processAction call and page aggregation.

Actions are for handling user actions that update the WSRP service's
instance state.

An example is this:

- In the view mode of a stocks portlet, there is an "Add symbol" entry
field with a submit button.
- When the user enters a symbol and submits the form, the portal gets a
POST request
- The portal detects that it is targeted to the WSRP service and converts
it into a performAction call on the WSRP service.
- The WSRP service receives the request in the performAction method and
processes it. In this example, it adds the posted stock symbol to it's
persistent instance state.

- If the WSRP service does not depend on data that may be modified by other
WSRP services before page aggregation, it may immediately return its markup
based on the new instance state.
- If the WSRP service does depend on data that may be modified by other
WSRP services before page aggregation, it may not return its markup before
the next getMarkup call.

The notion of "next view" is not required on the client side - it is
sufficient to have a processAction / getMarkup / processAction / getMarkup
/ ... cycle for user interaction (where for many WSRP services, the
optimization of returning the markup already as a result of the action may
be made).

Whether new views are shown or whether always the same view is returned is
an implementation detail of the WSRP service and may not affect the
protocol - or to put it in another way - any application specific
sequencing of views needs to be done inside the WSRP service, the consumer
needs to be agnostic of changing views to allow for plug and play.

The consumer just needs to

1. receive markup
2. rewrite URLs / namespaces
3. aggregate markup in a page
4. send the page to the client
5. wait for a request from the client
6. receive the request from the client
7. determine the target WSRP service instance of the request
8. generate an action from the request
9. send the action to the WSRP service by calling the processAction
10. wait for the result of the action
11. if the result contains markup cache the markup for later use in page
12. call the getMarkup operation of all WSRP services for which no markup
is cached and continue at 1.

Best regards,


Alan Kropp <akropp@epicentric.com> on 04/15/2002 09:03:02 PM

Please respond to Alan Kropp <akropp@epicentric.com>

To:    "'Michael Freedman'" <Michael.Freedman@oracle.com>, Carsten
cc:    wsrp@lists.oasis-open.org
Subject:    RE: [wsrp][interfaces]: Actions vs. Events

Mike, I would agree that the concept of an "action" for a portlet with a
single view (e.g., a counter or timer, something which does not expect user
input) is really overkill.  The portlet will render its one default, or
"main", view in response to the portal refreshing or instantiating the
containing page.

Where I think actions have merit is in two areas:

1.  The portlet supports a customization or "edit" view.  The end user
specifically invoke the "Display Edit View" action by clicking an
appropriate link or button on the portlet's main view, or perhaps on the
frame surrounding it.  The corresponding action defined on the portlet
be "getEditView" or something like that.  The portlet would respond with
markup for the edit view, and the portal would accordingly redraw that part
of the page.  In fact, this may be an example of a standard portlet action
which WSRP portlets may implement.

2.  The portlet supports a series of application-specific views, perhaps in
a step-by-step or "wizard"-lilke flow.  Each view has a control linking it
to the next view in the sequence.  The transition from view to view could
handled on the portlet side by a "getNextView" action, which examines the
associated parameters to determine which application view to fetch.


-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: Monday, April 15, 2002 11:26 AM
To: Carsten Leue
Cc: wsrp@lists.oasis-open.org
Subject: Re: [wsrp][interfaces]: Actions vs. Events

    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
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
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
by a render call.  This would seem to lessen the desirability of the
abstraction.  Can
you motivate "actions" more?

Carsten Leue wrote:

> Hi - as promised in the interface call here is a definition of what I
> define as "actions" and "events". We might use this as a starting point
> 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
> trigger such an action. The aggregator then intercepts this and issues a
> 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 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
> 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
> the services). Events are not directly represented in the markup but
> 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
> 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
> 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 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
>                              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