RE: Co-ordination protocol and BPEL

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

Mark.

>===== 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 
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:50:04 UTC