[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]