Business Transaction Management Specifications Comparison

BTMBTM SpectrumBTM Spec ComparisonBTPWS-TransactionWS-CAFGGF TM-RG

Choreology people played instrumental roles in authoring and editing the OASIS Business Transaction Protocol (BTP) specification, in a 15-month collaborative effort involving people from BEA, Oracle and HP.

The members of the BTP Technical Committee were pioneers. Prior to the publication of BTP in June 2002, no evident solution existed for transactions among loosely-coupled autonomous applications.

To be fair, the newness of the concepts also contributed to the subsequent quintupling of efforts. IBM and Microsoft couldn’t understand whether BTP was correct to question Open Nested Transactions (ONT), although ONT had proven to be an unworkable orthodoxy.

BTP never got support from major vendors like IBM and Microsoft, and in the standards game, major vendor support is critical to success.

Since BTP in 20002, five other business transaction specifications have come out, all essentially covering the same ground:

• WS-Atomic Transaction (WS-AT) and WS-Business Activity (WS-BA) from IBM, Microsoft and BEA, and
• WS-Composite Activities Framework (WS-CAF), including WS-Transaction Management (WS-TXM) with three business transaction protocols, ACID, Long-Running Activity (LRA) and Business Process (BP), from Sun, Oracle, Fujitsu, Iona and Arjuna.

In fact, some of the BTP TC members helped to define some of those other specs.

Technically speaking, there is no good reason for this proliferation. All of these specs, like BTP, are essentially 2-phase outcome protocols. None of these specifications make any significant advancement on BTP.

Two indications that these are all the same thing:

 1. Comparison of outcome protocols

Each signal in the same column is semantically equivalent in its outcome protocol function, although some signals have added functions as well. The boxes with *'s indicate that, while these protocols do not have an exact "prepare" equivalent, they do have an equivalent of "prepared". In other words, the coordinator knows when the participants are ready to confirm or cancel.

2.Cohesions can support any of these specifications using the same software.

Nothing changes in the API.

Cohesions 2.0 supports three coordination protocols: OASIS Business Transaction Protocol 1.0 (BTP), and the August 2002 edition of WS-Coordination+WS-Transaction/AtomicTransaction (AT), and WS-Coordination+WS-Transaction/BusinessActivity (BA).

We could easily support the latest edition of WS-AT and WS-BA when they become finished. We have studied the WS-TXM protocols and could support any of those as well, if they become popular.

Why is this easy for us to do? Because it is easy. Because BTP, our startup protocol, is essentially a superset of all of the others. To support another protocol, we mostly need to map their message names to ours. Then, to support stunted protocols that only offer the Do-Compensate participant pattern (like the current WS-BA spec, and WS-BPEL), all we need to is turn off the Confirm handlers. Or, in other words, the app programmer voluntarily forgoes the opportunity we have provided to define a confirm handler. Our API is not changed.

Other than restrictions on the participant model, you can’t tell the difference in the API or code.

We understand the commercial requirements for the ACID clones (WS-AT and WS-TXM ACID), These resprayed specifications allow existing transaction monitors to play in the WS world. However, we don’t understand why the world needs two of these things.

We also understand that the authors of the other specs do not agree with us: that they think “one size does not fit all”, and that the world needs many different business transaction protocols.

And we understand the WS-CAF proposition that WS-AT and WS-BA are not open standards, but their authors have publicly committed to go down the standards path. We believe that, barring "WS-Rupture", they will do so.

We wish the various groups would converge from six protocols to two. Choreology would be very happy to settle on WS-BA, if the WS-BA authors would make one small change that made WS-BA able to handle the Provisional-Final transaction pattern as well as Do-Compensate. We’ve made a formal proposal that they make that improvement as well as a few others that are less important.

We would like to see WS-BA become the vanguard protocol, because it would save everybody a lot of trouble and grow the business transaction market.

What we like about WS-BA:

• It’s IBM and Microsoft
• It’s a good platform
• It can be gotten to where it needs to be

What we don’t like:

• Unless it is changed it is critically deficient in its exclusive emphasis on the Do-Compensate model
• The feedback group’s wheels seem to grind exceedingly slowly
• It hasn’t been submitted to a standards body (yet)

But if we can’t convince these guys, maybe we should take the practical path by inserting BTP into both WS-CAF and WS-Coordination, and achieve convergence that way.

Anybody interested in this approach should contact us.