RE: Co-ordination protocol and BPEL

> -----Original Message-----
> From: Mark Little [mailto:mark.little@arjuna.com] 
> Sent: 22 May 2003 14:15
> To: Furniss, Peter; Assaf Arkin; Ricky Ho
> Cc: public-ws-chor@w3.org
> Subject: 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.

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

The discussion as a whole (not particularly your contribution) seemed to
be based on the assumptions of WS-T, and its particular patterns. That
was getting into the discussion about how to handle coordination issues
in the choreography (or rather in the process language).

Obviously a partisan slanging match is not useful, but there is a
general issue. The availability of a general registration protocol could
lead to "splitter" philosophy, where every minor difference in
implementation pattern used a different coordination protocol.  That's
not to say that there aren't really different coordination patterns.
They never seem to come out into the world though.

Not sure if we're still on topic for this list.

Peter

Received on Thursday, 22 May 2003 10:03:36 UTC