wsrp message

Subject: RE: [wsrp] handleEvent or handleEvents?

From: Rich Thompson <richt2@us.ibm.com>
To: wsrp@lists.oasis-open.org
Date: Tue, 4 Jan 2005 12:53:32 -0500

Targeting the protocol at best-effort delivery of events would make sense if the Consumer was simply a backplane infrastructure. While there may be Consumers of this type, the more general view is that the Consumer is the place in the overall information flow where someone has chosen to aggregate a set of portlets. In some cases this will simply be the dropping of portlets onto a page with no thought as to whether any or all of the portlets should communicate with each other. In other cases, this will be the deliberate placement of components for the purpose of composing an overall application. In this later case, the person composing the overall application will certainly want to control which events are allowed to flow between which components. Even in the simple case, it is quite reasonable for the Consumer to default to different distribution strategies for different classes of users. In both cases, the Consumer is the right point of control for what, if any, events flow between the portlets.

This discussion has recently centered around the first guideline laid out below. Richard had helped refine the second ... any comments on the third one?

Rich

Andre Kramer <andre.kramer@eu.citrix.com>

12/20/2004 04:42 AM

To	"'Rex Brooks'" <rexb@starbourne.com>, wsrp@lists.oasis-open.org
cc
Subject	RE: [wsrp] handleEvent or handleEvents?

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.

Regards,
Andre

From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: 17 December 2004 13:40
To: Rich Thompson; wsrp@lists.oasis-open.org
Subject: RE: [wsrp] handleEvent or handleEvents?

Rich, Russ, Andre,

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?

Ciao,
Rex

At 11:10 AM -0500 12/14/04, Rich Thompson wrote:
Richard,

Would the following update to #2 address your concern?

2. Events are independent notifications that something has occurred, which receiving portlets may use to impact their state.

Rich
Richard Jacob <richard.jacob@de.ibm.com>
12/13/2004 01:37 PM
To
Andre Kramer <andre.kramer@eu.citrix.com>
cc
wsrp@lists.oasis-open.org
Subject
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,

Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Standardization Technical Lead
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com

Andre Kramer
<andre.kramer@eu.
citrix.com> To
wsrp@lists.oasis-open.org
12/13/2004 03:17 cc
PM
Subject
RE: [wsrp] handleEvent or
handleEvents?

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>

To
12/10/2004 07:06 AM 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

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.

--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309