Re: [wsrp-coord] handleEvents Proposal

[Rich Thompson <richt2@us.ibm.com>]

Subbu,

Thanks for this approach ... it does
a reasonable job of projecting the impact of the building consensus that
handleEvents should be able to do everything pbia can do. A number of comments
follow:

1. I think there are a number of problems
with using the index to refer to failed processing of an event  (what
is the base index of the array, it requires the Consumer to hold onto the
supplied array, etc.). Two other approaches I would want to consider are;
1) Have the Consumer supply an eventID that can be used as this reference,
or 2) Have the response message simply return an ordered array of those
events that were not processed.

2. I disagree that it is always the
portlet that should be deciding whether or not to abort event processing
upon the first failure. There are examples where Consumers would want to
be able to exert control (e.g. an e-Commerce app might not want any later
events processed that could result in financial transactions if earlier
events, which could be setting up a shopping cart's data, are not handled
properly). This could just be a boolean expressing that the Consumer is
exerting that event processing must be aborted on failure vs portlet choice
on whether or not to abort on failure.

3. As to tossing out the Consumer attaching
value to the order of events in the array, consider the example I cite
in #2. The point is that there are a class of Consumers which will attach
much more intelligence to coordinating the portlets being used than what
is reasonable for a typical portal. Are there use cases you are aware of
where is will be difficult to process the supplied events in the order
the Consumer supplied them?

Rich

Subbu Allamaraju <subbu@bea.com>

11/01/2004 09:29 AM

To	wsrp-coord@lists.oasis-open.org
cc
Subject	[wsrp-coord] handleEvents Proposal

I posted a proposal update the semantics of handleEvents to address 
issues 27, 26, 16, and 17. The document is at

http://www.oasis-open.org/apps/org/workgroup/wsrp/wsrp-coord/document.php?document_id=9885

The following are the changes:

a. Add MarkupParams to the input (Issue 17). This is required for the 
producer to be able to return markup (Issue 26).

b. Make handleEvents return HandleEventsResponse. HandleEventsResponse
includes UpdateResponse, redirectURL, abortedEvents*, and new events*

c. By reusing UpdateResponse, the producer can return markup (Issue 26)
  along with mode/state changes.

d. Include redirectURL (Issue 16) in the response. This is mutually 
exclusive with UpdateResponse.

e. In addition, this operation returns abortedEvents (Issue 27). This is
an array of index/reason of events that the Producer failed to process
fully/partially. Since there is no unique handle/ID on the Event
structure, I opted for the array index (starting from or "1")
in
the incoming events array. That is, if the producer fails to process the
second and fourth events, it would return two HandleEventsAborted
elements with index 2 and 4 and the reasons for failure.

I have not accounted for the following:

a. Consumer to indicate whether to stop processing on the first 
failures. I think this should be the Producer's choice, not the Consumer's.

b. Whether the Producer should process the events in the same order.

c. Whether the Producer is allowed to process events concurrently.

For your comments and discussion.

Regards,

Subbu


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-coord/members/leave_workgroup.php.