Recognizing that event processing occurs
in rounds would also help the presentation. Each round involves a consumer
delivering a batch of events to the producer and optionally receiving back a
further batch of events (and failure events) to process.
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 13 December 2004 14:10
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] handleEvent or
handleEvents?
The F2F decision was to drop to handleEvent for now due
to the issues involved in handling faults in the batched case. We should work
on these and seek to restore the nature to a batch operation for the reasons
you list. Basically the solution should respect the current overall design:
1.
Portlets are loosely coupled components integrated onto the page by the
Consumer.
2.
Events are notifications that something has occurred which other components may
use to impact their own state.
3.
There are times when a Consumer will care what failures have occurred (e.g. for
retry purposes)
I
think if we agree to these guidelines, then relatively simple solutions to the
failure issues in the batch operation can be designed. Any comments on these as
guidelines before we try and design/debate a solution?
Rich
|
Andre Kramer
<andre.kramer@eu.citrix.com>
12/10/2004 07:06 AM
|
|
To
|
wsrp@lists.oasis-open.org
|
|
cc
|
|
|
Subject
|
[wsrp] handleEvent or handleEvents?
|
|
My comment is on the current 2.0 draft,
so I
am
sending
it to
the TC list, even though it is specific to
coordination.
As initially written, handleEvent is constrained
to only deliver a single (IN) event and requires the consumer
to not deliver a second event while the first is being processed (but
multiple
events can be returned by a portlet). This seems an unworkable solution to
me because of (1) network latency and (2) event processing
logically
occurs
in rounds. Should we start with handleEvents rather than try to discuss a
handleEvent?
Regards,
Andre