RE: [ws-caf] The future of WS-TXM

["Martin Chapman" <martin.chapman@oracle.com>]

Alastair,

Im very sympathic to your views, but until (and if) a new TC is
announced, 
there is not much we can discuss!

Martin.

>-----Original Message-----
>From: Green, Alastair J. [mailto:Alastair.Green@choreology.com] 
>Sent: Wednesday, August 31, 2005 10:25 AM
>To: ws-caf
>Subject: [ws-caf] The future of WS-TXM
>
>
>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 
>
> 
>