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