Re: Co-ordination protocol and BPEL

Mark Little wrote:

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

I want to emphasize that how the language and its engine work is not 
related to any specific protocol. There's a basic design pattern 
involved in making it declarative, and a basic design pattern involved 
in letting it use out-of-band messages to coordinate work (so you don't 
have to write them into the choreography). And then you can layer any 
number of protocols. Some protocols may only work in some cases, others 
may support more things you just can't or are not interested in doing.

But the protocol is used by the engine when it executes the language. 
The process definition is NOT written specifically to support the 
protocol, it's protocol agnostic.

arkin

>Mark.
>  
>

Received on Thursday, 22 May 2003 15:55:13 UTC