handleEvents Proposal

[Subbu Allamaraju <subbu@bea.com>]

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