Re: [wsrp] spec-2.0-draft-05: events and blocking actions

[Stefan Hepper <sthepper@hursley.ibm.com>]

When reading the spec draft I also was wondering why the event 
processing order is not defined. The event processing oder may influence 
the outcome of the eventing. I don't understand why the event array 
needs to be ordered when the event execution on the consumer is 
unspecified. What was the reason for requiring the events be in sequence 
in the event array?

For example is it possible to have the following sequence:

P1 returns events e1, e2
e1 is distributed to P2
P2 returns events e3, e4
e3 is distributed to P1
e4 is distributed to P3
e2 is distributed to P3

P3 now gets an older event as the last event even as e4 may be the more 
accurate data. I understand that events are not guaranteed to be 
delivered, so P3 may never have gotten e4. However, I think it makes the 
portlet logic a bit more complex and it should be stated explicitly in 
the spec that no order is guaranteed.

Stefan


Yossi Tamari wrote:
> Two comment bellow, marked with <YT>.
> 
>            
> 
>             Yossi.
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Rich Thompson [mailto:richt2@us.ibm.com]
> *Sent:* Tuesday, March 08, 2005 8:49 PM
> *To:* wsrp@lists.oasis-open.org
> *Subject:* RE: [wsrp] spec-2.0-draft-05: events and blocking actions
> 
>  
> 
> 
> 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>
> 
> <YT>I think leaving the order to be the consumer is under-specifying. 
> Let’s say that during the portlet’s run, it generated two events 
> “Lakers” and “Pistons”. We require the portlet to return them in the 
> correct order (in section 6.4.2.1), but we don’t specify that the 
> consumer need to send these events to another portlet in the correct 
> order, which means whether it will display Lakers or Pistons is 
> completely random.
> 
> I think the order SHOULD be kept by the consumer, or at least we need to 
> make such a recommendation. Of course, we are not even requiring the 
> consumer to propagate the events, so there is no place for a MUST here. 
> This does not necessarily imply the concept of generations, which is a 
> simplification of the ordering requirement.</YT>  
> 
> 
> 
> 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>
> <YT>I agree, but like some of the other questions raised recently around 
> these topics, these are things that took us some serious discussions to 
> realize. I think we need to add more wordage to the spec to explain the 
> reasoning behind the decisions, and the expected use patterns. Otherwise 
> we are going to get the same questions from everybody who reads the spec 
> and was not part of the discussions…</YT>
> 
> 
> 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
>