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

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