We should definitely aim for best effort
event delivery for 2.0, so that consumers should not drop events or leave failures
unreported, but as Richard noted previously should not and can't require
reliable delivery. This allows portlets to react to events in a responsive manner
but they must be prepared to handle communication failures, such as failing to
complete a complex new user join protocol (where one event serves as the
acknowledgement of another). In future (3.0?), it may also be very worthwhile
to look at the eventing requirements of a complete application (a set of
distributed portlets connected with a consumer) say as a policy declaration or
activity diagram. This could simplify constructing and deploying applications significantly.
From: Rex Brooks
Sent: 17 December 2004 13:40
To: Rich Thompson;
Subject: RE: [wsrp] handleEvent or
3. Are there no events which MUST be acknowledged and/or implemented,
regardless of whether a Producer/Portlet Container chooses to to make any
changes to the state of the Portlet? In other words, if a Portlet does make a
change, shouldn't we require Consumers to implement the change if/when they
refresh or send a new getMarkup()? I don't think it is a case where a Consumer
MAY choose to make the change. I am specifically thinking about Portlets which
are used for multi-user collaboration applications where a third, fourth, fifth
party, etc, wishes to join a session and the Producer is acting as the
moderator for the session and is required by the application to require mutual
permission from participants or from some participants before adding a user? In
this case the lack of an event failure to acknowledge and reply by one of the
parties connected to the Consumer(s) could cause the whole application process
to freeze. Obviously, I'm working on just such a problem. Also, this problem is
already way out ahead of us and I am not thrilled with answering back, "Oh
sorry you can't do that now, in the next version, but maybe in a few more years
we may get to that situation.
This also raises the question of whether or not we are starting to
diverge significantly from JSR 168's next version<s>? I don't have the
resources yet to follow both efforts, and I haven't heard much from the Java
portlet folks in a while.
Isn't December supposed to be SLOW?
At 11:10 AM -0500 12/14/04, Rich Thompson wrote:
Would the following update to #2
address your concern?
are independent notifications that something has occurred, which receiving
portlets may use to impact their state.
12/13/2004 01:37 PM
Andre Kramer <email@example.com>
RE: [wsrp] handleEvent or handleEvents?
One other important point to me is that we really
should understand the
nature of events.
Portlets shouldn't rely on event delivery and thus
also shouldn't rely on
correct event processing.
We also do not deliver failure events back to the
portlet issuing the
original event (this was the first design we had).
Therefore we might want to ask ourselves what
event failures are really for
and who will be doing what with this information.
Key point for me is that we shouldn't try to
implement a (relyable)
messaging system based on events, i.e. we
shouldn't add any
atomicy,rollback, etc. rules to eventing.
Mit freundlichen Gruessen / best regards,
IBM Lab Boeblingen,
Dept.8288, WebSphere Portal Server Development
WSRP Standardization Technical Lead
Phone: ++49 7031 16-3469 - Fax: ++49
RE: [wsrp] handleEvent or
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.
From: Rich Thompson [mailto:firstname.lastname@example.org]
Sent: 13 December 2004 14:10
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
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?
[wsrp] handleEvent or
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
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?
To unsubscribe from this mailing list (and be
removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php.
Starbourne Communications Design
GeoAddress: 1361-A Addison, Berkeley,