[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Comparison of web services transaction protocols (1)
I think it's very welcome that a debate on the oft-asserted need for a portfolio of separate BTM protocols is now taking account of BTP, that Banquo's ghost which everyone knows is still at the banquet ... In my view BTP is intellectually unavoidable because it is the cleanest, most abstracted view of the problem. But it is far from the last word on the matter, and the main question here is: how do we get from standards competition to a single standard for BTM for Web Services? I found the following comment from Mark and Tom's article puzzling: "There have been several subjective articles and comments comparing BTP to WS-Tx, attempting to show that BTP can do everything WS-Tx can and ignoring the important differences that exist." I assume that we in Choreology may be among the subjective people. So it falls to us, among others, to dissect the misunderstandings shown in this comment. The comparison paper and presentation that Peter and I put out a year ago was in fact a quite stringent attempt to give WS-C+T its due. Unlike the authors of the recent paper, we do not accuse those who disagree with our technical approach of being "subjective". We simply think they are largely mistaken. And we welcome a wider debate, as such debates have a habit of bringing together the contributions of those who feel themselves to be objective, and of those who feel righteous, and contributing to useful synthesis. We have never maintained that WS-C+T is identical to BTP. For example, we have always said that the synchronization facility of WS-T would probably be useful in BTP, even though it can be achieved in a rather convoluted way with the existing BTP spec. And we welcomed WS-C+T's beginning of examining the security/transaction integration issue. We think that all the existing efforts lack a sufficient concept of dynamic commitment (transfer of control from initiator to a decisive participant); we think that none (including WS-TXM despite its promises) has a reasonable standardized reliable outcome notification mechanism. We would like to see a more evolved view of shared understanding between controller and participants of commit/abort dependencies. These are repeated requirements coming from end-user scenarios. We also recognize that many context mechanisms are capable of making propagation and registration work, and have no particular problem with the idea of binding to one or more distinct context mechanisms. Our main point has been, and remains: there is no technical justification for the existence of 6 protocols for the achievement of two-phase coordination of web services (the essence of what BTP calls the "outcome protocol"). A convergence strategy leading towards a single Web Service standard for Business Transaction Management (call it WS-BTM) would do customers a favour, and would help eliminate standards confusion -- which is always a barrier to developing a new arena or category of software. In our engagements with end-users we see zero demand for standards smorgasbord. We do maintain that a great deal of energy has been expended by companies with vested product lines and/or the a priori view that "one size does not fit all", in advancing or following the proposition that somehow WS-T (AT or BA) or WS-TXM (Acid, LRA, BP) are fundamentally or usefully different from BTP (or from each other) in their principles or functionality. "Fundamentally" in the sense that each uses a two-phase exchange (sometimes explicit, sometimes optimized or disguised), whose messages have now acquired many names, but whose meaning has never altered. "Usefully" in the sense that we see no evidence that thinking will be clearer, or design or implementation will be facilitated, by this proliferation. We speak from the standpoint of having implemented both WS-C+T and BTP in our Choreology Cohesions product. One of the key questions that must be addressed here is: where are the use cases? Until we see a use case that cannot be addressed by the underlying ur-protocol (which is closest to the BTP abstract protocol), I for one will not be convinced of the underlying case for proliferation. Fusion, supercession, synthesis -- yes. Needless variation -- no. Alastair -----Original Message----- From: Furniss, Peter Sent: 13 October 2003 17:30 To: 'BTP - mainlist (business-transaction@lists.oasis-open.org)' Subject: Comparison of web services transaction protocols (1) BT TC list subscribers may have noticed the new paper comparing WS-C/WS-Tx and OASIS BTP by Mark Little of Arjuna and Tom Freund of IBM at http://www-106.ibm.com/developerworks/webservices/library/ws-comproto/ The paper includes a useful list of further reading but omits an earlier comparison of the same protocols that Alastair and I did and sent to this list last November - in the archive it's at: http://lists.oasis-open.org/archives/business-transaction/200211/msg0001 3.html and there is also a version at http://www.choreology.com/standards/btp_wsc%2Bt.html , and some associated slides at http://www.choreology.com/resources/2002-11-20.message_sequence_comparis on.A.ppt The new paper raises some interesting points, and of course by its existence shows that BTP is of significance. Since this groups list is open (or reasonably so) and publically archived, this would seem to be an appropriate discussion place. Which discussion I now commence: Some of the comparisons in the new paper are flawed by a couple of what appear to be simple mis-readings of BTP. The mis-beliefs are: a) that BTP *requires* open-top behaviour in all cases, rather than allowing it where wanted b) that up-qualifiers (e.g. qualifiers on PREPARED, like the participant timeout) are not accessible to the application These two points give rise to a large number of the "unfortunately, btp ..." in the paper. Both are of course questions of client:coordinator interaction, which is handled in BTP by the control protocol. For a), CONFIRM_TRANSACTION can be used in "open-top" or "closed-top" manner - the difference is whether PREPARE_INFERIORS is issued before the CONFIRM_TRANSACTION - if not, then CONFIRM_TRANSACTION runs the entire two-phase exchange, sending out PREPAREs to inferiors, and cancelling the transaction if any inferior will not go prepared. This is of course precisely the behaviour of classic TM commit calls. Open-topness, involving the business logic in the selection of the confirming inferiors is only used if the application wants to involve its business logic. Since such selection is only valid for a Cohesion, the spec requires that Atom's are closed-top. For b), the qualifiers from the inferiors are delivered to the application in the INFERIOR_STATUSES message, which identifies which inferior sent which qualifier (such as a timeout). One could note that the main case in which these qualifiers are useful is when the coordinator is used in open-top mode and PREPARE_INFERIORS is used - the reply to PREPARE_INFERIORS is INFERIOR_STATUSES, thus delivering the qualifiers precisely where they are needed. The control protocol of BTP is optional and it was intended that a perfectly valid, interworking BTP implementation could use an alternative API to handle the client:coordinator interactions. In such a case, of course, some API might indeed exhibit the problems asserted in a) and b) - but that would be the fault of the API, not the outcome protocol. There are several other points I'd like to make (and these obviously don't really touch the main issue of whether one has a generic outcome protocol or lots of different ones), but I wanted to raise these two error flags first. Peter ------------------------------------------ Peter Furniss Chief Scientist, Choreology Ltd Cohesions 1.0 (TM) Business transaction management software for application coordination web: http://www.choreology.com email: peter.furniss@choreology.com phone: +44 870 739 0066 <-- new, from 4 August 2003 mobile: +44 7951 536168
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]