[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
But the consumer is not required to dispatch all or certain events. So, any assumptions on ordering would break. Subbu Spector, Artem wrote: > But if we say that event distribution is blocking (we almost agreed on > it, didn’t we? J), then the event order will be well-defined and will > not depend on network etc. > > > > Artem > > > > ------------------------------------------------------------------------ > > *From:* Rich Thompson [mailto:richt2@us.ibm.com] > *Sent:* Wednesday, March 09, 2005 3:41 PM > *To:* wsrp@lists.oasis-open.org > *Subject:* RE: [wsrp] spec-2.0-draft-05: events and blocking actions > > > > > I would note that multiple portlets couldn't depend on events between > them being ordered even outside the Consumer's option to reorder the > events it delivers due to network and varying workload effects on the > different Producers. > > Rich > > *"Yossi Tamari" <yossi@giloventures.com>* > > 03/09/05 04:05 AM > > > > To > > > > "Stefan Hepper" <sthepper@hursley.ibm.com> > > cc > > > > <wsrp@lists.oasis-open.org> > > Subject > > > > RE: [wsrp] spec-2.0-draft-05: events and blocking actions > > > > > > > > > > > > > I think the reason we required the portlet to return the events in order > was to allow a consumer that wanted to distribute the events in order, > to do so. > I do think this is a meaningful capability, and I don't really think it > makes the portlet logic more difficult (remember that the portlet gets > to decide what is the correct order), it just tell implementations "use > a vector and not a set". > I do think there should be at least guidance in the spec, for consumers, > that if they do not have a reason to change the order of the events, > they should attempt to keep it. It seems to me that developing a > multiple portlet/multiple events application without being able to > assume event ordering will be nearly impossible. (In reality my guess > would be that every event would contain in its internal data some sort > of timestamp, so that the receiving portlet will be able to manage > dropping older events). > > Yossi. > > -----Original Message----- > From: Stefan Hepper [mailto:sthepper@hursley.ibm.com] > Sent: Wednesday, March 09, 2005 9:30 AM > To: Yossi Tamari > Cc: wsrp@lists.oasis-open.org > Subject: Re: [wsrp] spec-2.0-draft-05: events and blocking actions > > 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 >> > > > > > > --------------------------------------------------------------------- > 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]