Re: WS-CDL requires state alignment which requires transactions, but don't re-invent them

Tony,

You make good point in this message to reuse existing protocols. It seem
resonable to add demarcation attribute in a declarative fashion.

Personaly from a ebusiness, legal and cost pov would keep a receipt ack
"signals" as the lowend simple, costeffective mechanism.

Cheers
/anders

Tony Fletcher wrote:

> Dear Colleagues, 
>
> We  (that is Bob and myself) urge this committee to recoil from 
> inventing yet another transaction protocol.
>
> Our message has 4 points.  The short version is: do nothing yet.
>
> (1). WS-CDL, as specified now, can require state alignment (align 
> attribute on an interaction element), which requires a business 
> transaction protocol.  See excerpts below.
>
> (2). The required business transaction protocol has already been 
> specified at least 6 times (and takes more than just specifying a set 
> of messages and their choreography).
>
> (3). The 6 competing protocols will shake out soon enough for WS-CDL, 
> and a good stopgap exists in the meantime (further more by using a 
> declarative style, as for the align attribute, the CD language can 
> stay above the arguments of exactly which transaction protocol to use 
> while showing in a choreography description what is included in the 
> transaction, what state is aligned and how the outcome effects the 
> possible future evolution paths of the choreography).
>
> (4). The same transaction protocol used for state alignment will also 
> handle more complex coordination requirements like the TWIST scenario 
> and Finalization.
> And to answer some points made previously - yes one could indeed 
> specify any transaction protocol or state alignment protocol in CDL 
> and then use that to wrap the 'application protocol' exchanges, but 
> you will notice that all of the transaction protocol specifications 
> are documents a few pages long and include text (amongst other 
> things)!  This is for a good reason not just because folk like to show 
> something for being at a standards meeting!  To achieve 
> interoperability and useful function the behaviour on message send and 
> receive needs to be specified carefully as well as the message content 
> and sequencing.  In particularly the behaviour under communication and 
> system failure conditions need to be specified.
>  
> Again interoperability not just on the ability of peers to be able to 
> send and receive messages (which can be done for any old message using 
> CDL) but also on the correct behaviour of the implementation at each 
> of the peer systems.  So folk are going to have to choose which of the 
> available application protocol and communication protocol 
> (etc) specifications they are going implement and I am sorry to say I 
> think that the WS-Choreography group just does not have enough clout 
> to force that issue.
>
> More details for each point:
>
> (1). The following excerpts from WS-CDL Version 1.0 require a business 
> transaction protocol, whether consciously intended or not:
>
> <excerpts>
> 2.5.2.2 Interaction Based Information Alignment
>
> In some Choreographies there may be a requirement that, at the end of 
> an Interaction, the Roles in the Choreography have agreement of the 
> outcome.
>
> [...]
>
> In WS-CDL an alignment Interaction MUST be explicitly used, in the 
> cases where two interacting participants require the alignment of 
> their States or their exchanged information between them...Their 
> variable alignment comes from the fact that the requesting participant 
> has to know that the accepting participant has received the message 
> and the other way around, the accepting participant has to know that 
> the requesting participant has sent the message before both of them 
> progress. There is no intermediate variable, where one participant 
> sends a message and then it proceeds independently or the other 
> participant receives a message and then it proceeds independently.
>
> [...]
>
> 2.5.2.4 Interaction Life-line
>
> [...]
>
> An Interaction completes normally when the request and the response 
> (if there is one) complete successfully. In this case the business 
> documents and Channels exchanged during the request and the response 
> (if there is
> one) result in the exchanged variable information being aligned 
> between the two participants.
>
> An Interaction completes abnormally if the following faults occur:
>
> * The time-to-complete timeout identifies the timeframe within which 
> an Interaction MUST complete. If this timeout occurs, after the 
> Interaction was initiated but before it completed, then a fault is 
> generated
>
> * A fault signals an exception condition during the management of a 
> request or within a participant when accepting the request
>
> In these cases the variable information remain the same at the both 
> Roles as if this Interaction had never occurred.
> </excerpts>
>
> The above excerpts declare requirements for an atomic business 
> transaction protocol: all or nothing, uniform outcome for both 
> participants.
>
> (2). You could hack something together than might work for limited 
> purposes but why?  The requirements are met by the Atomic variant of 
> the OASIS Business Transaction Protocol (BTP) or the competitive 
> specifications OASIS WS-CAF ACID and WS-Atomic Transaction. 
>
> (3). All three of those business transaction protocols are essentially 
> the same.  From a protocol viewpoint, so are the Cohesive variant of 
> BTP, WS-CAF Long Running Activity (LRA) and Business Process (BP), and 
> WS-Business Activity.  That makes six competing specifications which 
> are all essentially the same thing.  We think they will shake out to 
> two, but the shakeout will take two years.
>
> In the meantime, if you need to use a transaction protocol, BTP is an 
> approved and mature OASIS Committee Specification, moving swiftly to 
> version 1.1, with at least three implementations including one 
> open-source.
>
> (4). If you hack something together for state alignment, you will also 
> need to hack something together for Finalization and also for 
> coordinating more complex multi-party scenarios like TWIST.  The same 
> business transaction protocol can handle all of those use cases. We 
> have a demo using BTP that's a lot like TWIST:  
>  http://www.choreology.com/products/demo_securities.htm    
>  
> To summarize:  add transaction demarcation in a declarative fashion 
> (Choreology have already contributed a proposal showing how to do this 
> and plan to submit a revised proposal shortly. Let the business 
> transaction protocols shake out and use the winner.  Until then, 
> there's BTP.
>
> Thanks,
> Tony Fletcher and Bob Haugen

Received on Sunday, 18 July 2004 08:54:53 UTC