RE: Co-ordination protocol and BPEL

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.
 
>                                                             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).

Peter

------------------------------------------
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 08:57:12 UTC