Re: Co-ordination protocol and BPEL

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

It's not essential, but should be supported.

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

Is it appropriate to give pros and cons of one transaction protocol over
another? When I mentioned WS-C and BTP I meant only that WS-C allows
different coordination protocols (multi-phase) to be plugged in whereas BTP
is tied to two-phase. That was not a statement of pros or cons, merely fact.

If we go down your route then we could get bogged down in "my protocol is
better than yours" and I don't think we should. Let's keep this at an
abstract level.

Mark.

> 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 09:15:20 UTC