RE: Co-ordination protocol and BPEL

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 special. 
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 well 
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 
coordinator.

Mark.

>===== Original Message From Ricky Ho <riho@cisco.com> =====
>Mark,
>>BPEL integration with WS-Tx
>>======================
>>I'd like to see something like the following in BPEL
>>
>><process>
>>     ....
>>     <sequence>
>>         .....
>>         <receive newScope="true" ....>
>>             <scope>
>>                 <PrepareHandler> ... </PrepareHandler>
>>                 <CancelHandler> ... </CancelHandler>
>>                 <CommitHandler> ... </CommitHandler>
>>                 <CompensationHandler> ... </CompensationHandler>
>>            </scope>
>>         </receive>
>>         .....
>>     </sequence>
>></process>
>>
>>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:09:11 UTC