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:
- control: between an application and the
coordination elements, to create and to order the completion of the
transaction;
- propagation: spreading the identity and existence
of the transaction to other application elements; (aka "infection")
- registration: application elements, which hold
resources that will be subject to the transactional decision, join the
transaction as participants;
- outcome: determining and communicating the
transactional decision between the coordinator and the
participants.
As shown in the Venn diagram, the
different specifications cover different combinations of these functions:
- BTP includes at least part of all four sub-protocols
- WS-C provides the registration sub-protocol, and also the
creation aspects of the control sub-protocol;
- Atomic Transaction (AT) two-phase commit protocol, and
both the Business Activity (BA) protocols are outcome sub-protocols
- WS-T AT's Completion protocol corresponds to the
completion aspects of the control sub-protocol (WS-T BA does not include such
aspects).
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:
- there is excessive design-time coupling between the
parties - there has to be more knowledge of how the counterparty works than is
necessary. BTP is more fitted to a "service-oriented architecture", in having
messages that tell the other side what is promised or required in contractual
terms, without implying how it is done.
- unnecessary restrictions are placed on what can be
communicated in a particular case - thus WS-T AT lacks any way of signalling
heuristic events, WS-T BA lacks a one-phase commit mechanism. Having a single
protocol covering the whole spectrum means there is a way of sending the
semantic in all cases (even if the occurrence may be rare in a particular
case)
- there will be considerable deployment and configuration
complications - if there are different flavours of protocol, will both parties
support the same flavour ?
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:
- there are no timeouts (especially to signal the
limitation on how long a participant is prepared to wait for a decision - a
vital element of participant autonomy)
- no or inadequate heuristic reporting (none in AT, only in
one direction in BA)
- WS-T provides an interoperable control protocol only for
atomic transactions (the Completion protocol). Although the BA model allows
e.g. "a parent activity to select which child tasks are included ...",
there is no defined interoperable means for expressing this. The BTP control
protocol allows such selection for a cohesion.
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".