OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [business-transaction] WS-C+T and BTP: Comments and comparisons


 
We're sending this to the btp list directly to make it easier (we hope) for discussion, by just quoting bits - you may wish to de-htmlise for commenting. There is also a version on the Choreology website, where there is also a set of slides illustrating the "single outcome protocol" issue.
 
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 20 7670 1679
direct: +44 20 7670 1783
mobile: +44 7951 536168
13 Austin Friars, London EC2N 2JX

WS-C+T and BTP: Comments and comparisons

Peter Furniss and Alastair Green, Choreology Ltd
20 November 2002
Copyright © 2002, Choreology Ltd

Introduction

As Choreology, having been heavily involved in the development of the OASIS BTP specification, moves towards the inauguration on 2nd December of the Early Adopter Programme of our Cohesions 1.0 tm product (which implements BTP), and as we work to implement WS-C and WS-T in a future release of the product, it seems timely to present some comments and comparisons on the two business transaction management protocol families. As Choreology announced previously, we believe there should be a single standardization approach for web-services transactions, combining the best features of BTP and WS-C+T.

This message summarises some of the principal differences and similarities between BTP and WS-C+T, under the headings:

This message gives some detail on the first three, especially the issue that BTP and WS-T are just variations on one protocol, and summarises the other issues. We intend to expand on the other points in later messages, as well as responding to some particular points made in previous messages on the BTP list (and in Roger Sessions article, Shootout At The Transaction Corral; BTP Versus WS-T). The "single outcome protocol" issue is also illustrated in a set of slides of comparative message sequences on the Choreology website

The OASIS business transaction list would seem to be the most appropriate forum for such an open discussion - non-OASIS members can contribute via the business transaction comment list.

Terminology: sub-protocols

Several sub-protocols are required to build any distributed transactional application. It is worth emphasizing that the function of a coordination protocol is simply to server the needs of the applications involved in a coordinated outcome. The sub-protocols can be categorised as: As shown in the Venn diagram, the different specifications cover different combinations of these functions:

 Venn diagram showing functionality covered by BTP, WS-C and WS-T

The WS-T AT Phase-zero, Outcome Notification and Completion-with-ack protocols fall outside this basic categorization - they are dealt with below.

Taxonomy: atoms and cohesions

Both WS-T+C and BTP distinguish atomic and cohesion patterns. The BA model (BA 1.1 Model) corresponds closely with a cohesion - a parent activity can select which child task to include, can carry on with the activity despite an exception from a child and has a dynamic participant list.

In BTP, the difference in the outcome protocol between atom and cohesion is effectively just one bit (actually, a bi-valued flag in the BTP CONTEXT). In WS-T, different sets of messages are used.


BTP, WS-T: variations on a single outcome protocol

Contrary to some appearances and interpretations, all four outcome protocols in BTP and WS-T (BTP outcome, AT 2PC, BA with and without complete) are two-phase outcome protocols. In each of them, there is a protocol message that declares the participant is willing to abide by the decision of the coordinator, and a subsequent exchange initiated by the coordinator announces what the decision is. The messages have different names in the different protocols.

The major difference of approach between BTP and WS-C+T thus concerns whether a different outcome protocol is needed when there are different internal mechanisms for delivering on the promise to abide by the decision.

In BTP, the "outcome" protocol is the same regardless of whether the participant uses strict locking, complete-and-compensate, check-store-perform or other participant implementation strategies that may be devised..

In WS-T, there are different sets of messages that communicate equivalent semantics (AT two-phase commit, BA). These are apparently intended to be selected from depending on how the participant is thought to be implemented.

In our view, the implementation of the participant's obligations, is literally "none of the business" of its counterparty in a business transaction and may indeed vary over time.

A set of slides demonstrating the equivalences between the outcome protocol messages of BTP and WS-T are available on the Choreology website.

Our prime contention is:

Only one outcome protocol is needed: so only one should be defined.

Splitting the outcome protocol causes several problems:


Other points of comparison

The following points are outlined here, but we intend to expand on them later.

Functionality discrepancies

WS-T lacks some useful functionality:

Optimisation

WS-T is under-optimised, requiring multiple registration exchanges. There is also nothing corresponding to the "one-shot" coordination protocol message concatenation, and application message re-use patterns, that BTP allows.

Scope - WS only or wider

WS-C, WS-T reasonably target web-services only, whereas BTP also usefully targets all other potential environments, with mappings to web-service protocols as particular instances. Choreology believes from customer feedback that the ability to coordinate both WS and non-WS applications has business value.

WS-Cordination - why separate

Since WS-T and BTP really have a single outcome protocol, there is no evident need for the registration mechanism to be a separate protocol, as in WS-C. (Equally, there is nothing inherently objectionable about separating a sub-protocol specification into a distinct document.) However, it would be useful to know whether there are other genuinely different protocols (i.e. other than two-phase outcome) in the minds of the authors of WS-C/T that are likely to see the light of day.

WSDL integration

None of the specifications (BTP, WS-C+T) have any material on WSDL integration, or other means of declaring what headers or transaction protocol fields are expected by a web-service. Choreology has already carried out work in this area which we plan to publish in due course.

Synchronization

The OMG OTS specification allows the registration of a Synchronization with a Coordinator, in addition to the registration of a Resource. WS-T AT has synchronization facilities in the Phase Zero and Outcome Notification protocols. Equivalent functionality can be achieved using BTP with special participant behaviour - especially for the pre-completion, phase zero signals. There was discussion in the BTP development process about having a late "advisory" message, corresponding to the Outcome Notification messages, but this was not included in the existing BTP specification.

Security

Neither BTP nor WS-C+T addresses granular authentication, access control and non-repudiation issues. WS-T recommends use of WS-Security, but does not go into detail on the potentially complex security/transaction interactions. In BTP, security was deliberately deferred.

Transfer of control

In many business transactions, the application element that initiates the transaction will retain control of the transaction and order the completion; in others, the control may be passed from an intiating element to another that orders the completion (the terminator, in BTP terminology). Both BTP's control protocol and WS-T AT Complete protocol allow for both these patterns. In both there is no resilience to failure, and it is not guaranteed that the terminator will be informed of the final result - consequently it is inappropriate for the terminator to also hold resources that are intended to be subject to the transaction decision.

However, there can also be business transactions where an application element orders the completion and also holds resources which need to be reliably informed of the result. There are a number of ways this can be achieved (registering a co-located participant for example), but the WS-T AT Complete-with-ack protocol could be used. In such a case it would effectively be an outcome protocol, implementing "dynamic commitment".




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC