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

If the portal is presenting 2 or more different views of the same service instance then 'getmarkup' would need some input parameter indicating what view the markup should be for. This may be preferable to defining different getXXXMarkup methods for every conceivable view type.
The action concept seems important to me. The portal developer is the one who is mixing and matching WSRP services into a meaningful application, and that is where the higher-level logic of propagating events among participating portlets needs to be handled. Unless the state-changing "action" method is temporally separated from getmarkup there is no opportunity for the event propagation to finish propagating. We should not assume that the service provider is handling all event notification and processing (and we might argue that it is undesireable for it to be required to do any).
As an efficiency, we might allow for the simpler performActionGetMarkup that is essitially a 1-phase operation when the portal somehow knows that there will be no event propagation associated with the current action that could affect the markup returned, thus removing a round-trip to the service.


Michael Freedman wrote:
Each of these seem to imply that markup is (ultimately) returned.  If this is
the case then why isn't there a single method for all calls that return markup?
If we want to name that "actions" so be it. But couldn't we also name it
"getmarkup"? In either case the "action" or operation the producer performs is
defined by a (collection) of parameters passed in that define the type/form of
the markup to be produced.

Alan Kropp wrote:

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 would
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 would
be "getEditView" or something like that. The portlet would respond with the
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 be
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
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
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
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 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
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 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
                             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