[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] The future of WS-TXM
I understand. However, we might as well tune ourselves to this forthcoming reality. It may have practical implications in terms of levels of work, willingness to travel for F2F etc. Alastair -----Original Message----- From: Martin Chapman [mailto:martin.chapman@oracle.com] Sent: 31 August 2005 17:15 To: Green, Alastair J.; 'ws-caf' Subject: RE: [ws-caf] The future of WS-TXM 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]