RE: Comparison of web services transaction protocols (1)

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

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