Comparison of web services transaction protocols (1)

["Furniss, Peter" <Peter.Furniss@choreology.com>]

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