The future of WS-TXM

["Green, Alastair J." <Alastair.Green@choreology.com>]

My apologies for missing Monday's meeting -- it was a bank holiday in
England, and family obligations beckoned.

I would like to formally raise an issue that the WS-CAF TC will have to
deal with: what future or purpose do the WS-CAF TXM specs have in the
light of the revised WS-TX specs (WS-C, AT and BA) issued this month by
IBM, Microsoft, BEA, Hitachi, IONA and Arjuna, and the current plans to
launch a new OASIS TC called WS-TX (along the lines of WS-RX) to take
these specs through to standardization?

It has long been our view at Choreology that the proliferation of
specifications in this area has been a hindrance to uptake of
distributed, loose-coupled, long-lived business transacton management.
We hear this every time we talk to prospective customers and to
analysts. 

That is why we have argued over a long period for recognition of the
technical reality that BTP, WS-AT, WS-BA, WS-TXM Acid, LRA and BP are
(in the large) simply dialects of a common language: a two-phase outcome
coordination or consensus protocol. 

We have lost that argument. In the absence of support for a convergence
strategy one has to work out which horse to back. We recognize that BTP
has no rich friends. We also recognize that WS-AT and WS-BA are
deficient technically, but do have rich backers. Now that these specs
are going into an open process, and any notion of an IP cloud will be
dispelled by the use of the OASIS RANDZ IP mode (as with WS-RX), it
seems obvious that the whole thrust of industry effort will be on the
WS-TX specs. We are certainly seeing commercial interest in
implementations of these specs, and zero commercial interest in the
WS-CAF transaction specs.

The fact that the main authors of the WS-CAF TXM specs have a) put
substantial work into becoming author compnanies of WS-TX, and b) have
put their engineering effort first into prototyping or productizing
WS-TX (rather than WS-CAF TXM) should telll us something.

As I suggested a couple of months ago on this list, WS-Acid and WS-LRA
are needless, confusing and trivial variants of WS-AT and WS-BA.
Differences such as support for heuristic notification do not justify
the existence of two atomic transaction specs, to take one example. Such
additions would be better dealt with by defining de facto or de jure
standard extensions to the base WS-AT spec.

I also wonder where the effort and time of the WS-CAF TC members will go
if these two projects operate concurrently.

I think that this TC must now discuss whether it is pointful to continue
work on WS-Acid and WS-LRA. Obviously (and this applies to BTP as well,
there may be a case for obtaining consent from all parties to submit
WS-CAF inputs and work-in-progress to the forthcoming WS-TX committee.
But I can see no real justification for continuing to excavate a
backwater. 

Alastair