Re: [wsrp-coord] handleEvents Proposal

[Subbu Allamaraju <subbu@bea.com>]

Rich,

Thanks for your comments. You gave me the right arguments. My comments 
inline below.

I'll wait for  others to comment and then update the doc.

Subbu

Rich Thompson wrote:
> 
> 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.

I was hoping for this comment :)

I think having an eventID makes it easy for both the Consumer and Producer.

> 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.

I see the use case. My follow-up question - is the Producer required to 
honor such a boolean?

> 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?

I'm not aware of any use cases. I asked this question to make sure that 
implementors planning to support the coordination model have no 
objections. In view of your use case above, it makes sense to say that 
the Producer MUST process the 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.
> 
>