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

Re: Co-ordination protocol and BPEL

From: Assaf Arkin <arkin@intalio.com>
Date: Thu, 22 May 2003 11:20:20 -0700
Message-ID: <3ECD14E4.6030304@intalio.com>
To: "Furniss, Peter" <Peter.Furniss@choreology.com>
CC: Ricky Ho <riho@cisco.com>, Mark Little <mark.little@arjuna.com>, public-ws-chor@w3.org

Furniss, Peter wrote:

>Assaf Arkin sent:
>>For atomic transactions you don't need prepare or commit, you are 
>>working at a higher level than the code and all that needs to be 
>>prepared or committed should be done by the engine for you. 
>That assumes the participant side implementation treats atomic
>transactions by delegating all resource operations to transaction-aware
>RMs. That's certainly possible, but doesn't seem to be essential.
If you are working with a low level programming language like Java you 
may need to do things at the end of the transaction. You will need a way 
to know about an intent to commit before it happens and know about the 
outcome after it completed, akin to afterCompletion/beforeCompletion. 
For example, to cache data and only store it at the end, to set the 
status of a session object, to do optimistic locking, etc. WS-TX has the 
proper flow to let you do that for atomic transactions.

If you are working with a high level programming language like BPEL, 
which is not intended to replace Java, you don't do these low level 
operations. The BPEL engine can do caching, optimistic locking, etc 
because it receives the signals it needs to do that. But what you are 
writing depends on a smart engine taking care of these things, not on 
doing work at that level of detail.

We do not have a single use case where people would like to have high 
level process definitions which are best addressed by languages like 
BPEL or BPML, and at the same time want to do low-level things that 
require access to these signals. When it gets down to nitty gritty 
details they tend to prefer to work with languages like Java.

>>                                                            For BA 
>>transactions you don't have prepare or commit, every response is an 
>>indication that all previous steps have been completed (prepared and 
>>committed). You do need a way to cancel, but this can be done 
>>by a fault 
>>handler (the terminate fault). And you do need a way to 
>>compensate and 
>>this is done by a compensation handler.
>It's a major bug in the current WS-T that it exposes, in the inter-party
>protocol, how the participant handles its resources and delivers on its
>"promise" to obey a subsequent cancel. That seems inappropriate to this
>world of "loosely coupled" systems. Obviously, in some cases, the
>contract between the systems may cover the degree of exposure of the
>intermediate results, and in what circumstances faults might occur (WS-T
>BA cannot communicate a failure of committed, closed transaction because
>it is locked to a perform, compensate approach). But that's detail on
>the fundamental, common to any coordination pattern, that all the
>players have to make their final state dependent on a single decision
>(strictly, all but one, since the decider can be a resource-holder).
I disagree.

In asynchronous messaging you know that any response you get is a 
commitment to the previous steps taken. There are a lot of different 
ways to implement this. It may include persisting at the end of every 
step, or just logging all events and replying them at the end, or 
creating an end-state in some temporary place and pushing it at the end. 
I've seen many different models to implement it, and all of them seem 
consistent with the specification so it is loosely coupled in the sense 
that it does not propose any single model, and I doubt if all the 
vendors implementing this spec do it exactly the same way.

But since we are talking about interactions that cannot be rolledback 
but only compensated, the 2PC flow doesn't work with most of these 
systems. The flow that does work is based on either asking to cancel or 
compensate work, and responding not with a vote but with the outcome, 
which can be compensated if required.


>Peter Furniss
>Chief Scientist, Choreology Ltd
>   Cohesions 1.0 (TM)
>   Business transaction management software for application coordination
>web: http://www.choreology.com
>email:  peter.furniss@choreology.com
>phone:  +44 20 7670 1679
>direct: +44 20 7670 1783
>mobile: +44 7951 536168
>13 Austin Friars, London EC2N 2JX
Received on Thursday, 22 May 2003 15:55:10 UTC

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