W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

RE: Co-ordination protocol and BPEL

From: Mark Little <Mark.Little@arjuna.com>
Date: Fri, 23 May 2003 12:08:37 +0100
To: <public-ws-chor@w3.org>, Ricky Ho <riho@cisco.com>
Message-ID: <3ECD028F@webmail.ncl.ac.uk>

Apologies. This was supposed to be off-line, but hit reply-all :( Please make 
any follow-ups to me and Ricky only.


>===== Original Message From Mark Little <Mark.Little@arjuna.com> =====
>Ricky, as requested by Martin I've taken this off-line.
>The reason for the BA approach is that it's very similar to what traditional
>workflow systems do and how most web services are being written today: the
>compensation work is simply considered as another activity - it's not 
>The work required to compensate is already available from the service (e.g.,
>unbook seat), and obviously book seat does the work somehow (and this may 
>be provisional until to say confirm seat, or it may not be).
>The problem with BTPs approach is that is mixes business level semantics with
>the transaction system and that isn't right: in most cases we've seen prepare
>is useless since the business-level methods such as book seat have already
>done that work. confirm is typically a null-op but in some cases it actually
>does the real work. cancel is the compensation route and is an invocation of
>some service-specific method with a specific document type to undo the work -
>it isn't an invocation on a transaction participant or via some transaction
>>===== Original Message From Ricky Ho <riho@cisco.com> =====
>>>BPEL integration with WS-Tx
>>>I'd like to see something like the following in BPEL
>>>     ....
>>>     <sequence>
>>>         .....
>>>         <receive newScope="true" ....>
>>>             <scope>
>>>                 <PrepareHandler> ... </PrepareHandler>
>>>                 <CancelHandler> ... </CancelHandler>
>>>                 <CommitHandler> ... </CommitHandler>
>>>                 <CompensationHandler> ... </CompensationHandler>
>>>            </scope>
>>>         </receive>
>>>         .....
>>>     </sequence>
>>>Thoughts ??
>>>Ricky, what do you expect in your PrepareHandler, since BPEL doesn't have
>>>a notion of preparing a transaction. Is this not a carry-over from BTP?
>>My understanding of BPEL is they don't have the notion of "provisional
>>work".  So you do the real work and compensate it later.  Effectively, they
>>only have the <compensationHandler> and <cancelHandler>.  Their model is
>>certainly simpler but less sophisticated.  If you read by airline company
>>example and Assaf's solution, I think having a <prepareHandler> and
>><commitHandler> is cleaner.
>>I think this concept from BTP is pretty useful and I don't see much
>>additional complexities it brings.  Why drop that in BA ?
>>Rgds, Ricky
Received on Friday, 23 May 2003 07:50:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:05 UTC