wsrp-coord message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp-coord] handleEvents Proposal
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp-coord@lists.oasis-open.org
- Date: Mon, 1 Nov 2004 16:32:49 -0500
1. I think I prefer the eventID route
as well as this allows the Consumer who doesn't care to discard the event
after sending it and ignore the failedEvents that are returned. Consumers
who do care can easily design an event pool where events sent to multiple
portlets only need to be stored once.
2. I think that if the Consumer exerts
the need to abort on the first failure, then the Producer MUST follow the
directive. Any weaker language than that will result in such Consumers
breaking the array up as they will not be able to rely on the semantics.
Rich
Subbu Allamaraju <subbu@bea.com>
11/01/2004 03:26 PM
|
To
| wsrp-coord@lists.oasis-open.org
|
cc
|
|
Subject
| Re: [wsrp-coord] handleEvents
Proposal |
|
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.
>
>
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]