wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsrp] spec-2.0-draft-05: events and blocking actions
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Tue, 8 Mar 2005 13:49:17 -0500
Comments in-line
Rich
"Spector, Artem"
<artem.spector@sap.com>
03/08/05 12:59 PM
|
To
| <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [wsrp] spec-2.0-draft-05:
events and blocking actions |
|
Some more thoughts about event handling:
1.
Separate between event generations. If a Consumer during
distribution of some events (current generation) gets a response with a
new portion of events (new generation), it must finish distribution of
the current generation events before starting distribution of the next
generation events.
<rdt>Why would this Consumer implementation
choice be any more valid than a choice to queue pending events for each
portlet and send them whenever a portlet is not actively processing events?
In particular, why should the messaging protocol (WSRP) select what is
a valid implementation choice for either of its endpoints (as opposed to
defining the semantics of the message flow)? In the case of handleEvents,
the semantics are the Consumer passing a set of events it chose to distribute
to the Portlet. I think how the Consumer made the choice to distribute
these particular events or chose to order the events should remain a Consumer
choice.</rdt>
2.
What to do when handleEvent() returns redirectUrl? Should the
Consumer redirect immediately, or should it finish the event
distribution first? What if different Portlets handling the same event
return different redirectUrls?
Or may be the Consumer should ignore the redirectUrls of the event
handling, and respect only the result of the blocking action which has
triggered the event chain?
<rdt> Consensus from previous discussions
have been to leave this up to Consumer policy. Spec should probably explicitly
state this.</rdt>
3.
The optimization when a Portlet sends markup in the
UpdateResponse seems a bit problematic, because the same Portlet may be
invoked several times within the same "three-step" loop generating
each
time a different markup...
<rdt>Remember that each time a Portlet
returns markup, it is saying this markup reflects its current state. Unless
the Portlet changes its navState, mode or ..., the previously returned
markup may be fetched from a cache.</rdt>
Considering all these complications I would propose to redesign the
HandleEventResponse so that it will include neither redirectUrl, nor
Events. This would make the event handling flow more simple and
consistent.
As for the "cascading multi-generation events" (which will not
be
supported in this case), they have so many side effects that could
easily cause unpredictable behavior.
<rdt>But they are also essential
for a number of use cases. The only problems I have seen to-date with multiple
generations is when people try to make this loosely-coupled model exhibit
tightly-coupled behavior.</rdt>
Regards,
Artem
-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com]
Sent: Monday, March 07, 2005 7:29 PM
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] spec-2.0-draft-05: events and blocking actions
Some more comments below.
Subbu
> From the Producer point of view, handling the user interactions
and
the
> events are very similar tasks. The spec describes an interaction as
an
> "encodable event" (6.4.2), which points out that interactions
and
events
> are just two different ways to invoke the same Portlet logic.
> This idea however is not expressed strongly in the spec, which causes
> some confusion. Below is a list of questions:
>
> 1. HandleEventResponse and BlockingInteractionResponse
are
> identical, but defined as two distinct types, why is this?
>
> <rdt>Opened issue #43</rdt>
I thought we discussed this during last F2F, but I don't recollect what
the resolution was.
> 2. According to paragraph 6.4.2.1 Event
Handling, the Consumer
> may invoke handleEvent() on different Portlets simultaneously. But
if
> the event handling has the same Producer-side semantics as processing
> user interaction, all the restrictions described in paragraph 6.4.1
must
> be applicable as well. Which means that all the operations on the
page
> must be blocked until handleEvent() either returns or fails.
>
> <rdt>My understanding from the discussion to-date is that handleEvent
> invocations may happen in parallel, but that other processing is
blocked
> until the Consumer decides it has no more events for a particular
> portlet. The Consumer may then start a getMarkup on that portlet.
I'm
> sure we need to be more explicit about this ... do people think that
the
> Consumer must wait for all portlets to exit the event distribution
step
> before starting to collect markup? </rdt>
I agree that we need to be explicit. Semantically, it would be
consistent to specify that event distribution is blocking.
> 3. What if HandleEventResponse contains
events? Must they be
> processed by the Consumer?
> Let's consider a Consumer processing a page which contains two
portlets:
> P1 and P2.
> a. Consumer calls P1.performBlockingInteraction(),
and gets
event E1
> b. Consumer propagates the event to the
Portlets:
>
i.
> Question: should the consumer invoke P1.handleEvent(E1)? I guess
no...
> <rdt>The Consumer is not bound to send the event to any portlets
and I
> expect most will explicitly exclude the source portlet. Should we
make
> this explicit in the spec so that portlets design for it?</rdt>
It is perfectly valid for P1 to subcribe for E1. I don't see any reason
to exclude this possibility.
ii.
> Consumer calls P2.handleEvent(E1) and gets another event E2
in the
> response.
>
iii.
> Must the Consumer call P1.handleEvent(E2)? If yes, there could
be an
> endless loop; if no, the HandleEventResponse should not contain
events...
> <rdt>The Consumer is free to exit the event distribution step
whenever
> it wants to. As part of loop prevention, Consumers should have a limit
> on the number of generations of events they distribute ...</rdt>
>
> Regards,
> Artem
> *Artem Spector* | Portal Platform Infrastructure | NetWeaver
Application
> Platform | SAP Labs Israel| (+972-9) 7779567
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsrp-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsrp-help@lists.oasis-open.org
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]