[no subject]

> There has been a deliberate attempt not to define a single protocol=20
> that tries to satisfy all user requirements, simply because that=20
> doesn't work and certainly doesn't scale. Both WS-T and WS-TXM (the=20
> transaction part of
> WS-CAF) have essentially taken the micro-kernel approach. Back in=20
> the late 1980's we had what were subsequently dubbed macro-kernels=20
> that were bloated operating systems trying to provide services for=20
> every possible use case, even when most use cases probably weren't=20
> applicable to 80% of users. The result was massive memory=20
> utilization and degredation in performance. The early 1990's saw the=20
> evolution of micro-kernels where the core kernel service was very=20
> small and additional functionality could be added dynamically as
> and when required. The aim was to allow a kernel to be=20
> customizable on a per deployment basis. The advantages to=20
> this approach are obvious.
>=20
> The designers of WS-T and WS-TXM believe that this is the right=20
> approach for Web services transactions too. No one protocol can be=20
> applicable to all use cases and we shouldn't attempt to design
> such a thing based on our current limited knowledge of how
> transactions will be deployed in the evolving Web service arena.


The general approach, of small core and extra features as needed, is
appropriate, but the application of the principle to the problem is=20
completely wrong.

What we are all seeking is a protocol (or protocols) - a set of=20
messages with defined semantics - for communicating transactionality
between fairly loosely-coupled systems using webservices.  Applying=20
the micro-kernel paradigm means we should be looking to abstract the=20
variations in the semantics in different use cases to their=20
fundamentals, and have a protocol that transmits the fundamentals.=20
Don't even think of implementation or engines yet; just define what
the messages must mean, assuming no greater knowledge of the=20
internal behaviour of the opposite end than is mandated by=20
the use of the protocol.

We should, in the first instance, further limit the scope to the true
inter-party exchanges - what btp calls the outcome protocol, but=20
including the propagation and registration mechanisms. The control=20
mechanisms, by which an entity creates a transaction and controls its
lifecycle, are secondary - they will frequently be more "intimate"=20
than the outcome protocol (in-process api v inter-process messages;=20
intra-company transaction server v inter-company b2b exchanges), and=20
the control mechanism is meaningless without a standardised outcome=20
protocol, but not vice versa.

But WS-CAF/TXM, and to a lesser extent, WS-C/Tx apply the=20
micro-kernel approach to the engine that supports the control=20
mechanism (which doesn't need to follow a service-oriented
architecture) and forces the inter-party exchanges (which are=20
definitely SOA) to be rich and varied.

Given a common outcome protocol, with the fundamental promise/decision=20
(two-phase) pattern, the separate parties do not need to agree=20
beforehand which kind of transaction they are involved in this time.=20
Each participant is concerend only with establishing (via the
application exchanges) what the content of its promise will=20
be, making the promise, and applying the decision. It=20
generally doesn't need to know what else is going on in the=20
transaction, and the rest of the transaction doesn't need to=20
know how it is delivering on its promises.  That's service-oriented=20
transactionality.

Of course, there are cases where it is appropriate to pass more=20
information about the transactional behaviour between the parties. But=20
those are refinements of the basic exchange, and appropriately passed
as qualifiers, policy declarations etc.  For example,=20
informing all receivers of a context that any participant=20
enrolled with it will get the same=20
decision allows said receivers to share work between=20
participants, if they so wish, in a way that would be unsound=20
without that assurance. Announcing time limits and time=20
scales, allows other parties (if they have the flexibility)=20
to choose an appropriate internal mechanism for how they will=20
work in this case - but a service that lacks the=20
flexibility doesn't have to be told about a completely=20
different protocol just because some transactions it is=20
involved in will take longer than others.


The WS-CAF/TXM and WS-C/Tx "portfolio" architectural paradigm is
inappropriate for web-service transactions. There should be a=20
single outcome protocol, with the ability to take=20
qualifiers/policy statements, and as many control
mechanisms and patterns as are found useful. Defining
web-services for the control mechanisms is reasonable,
but secondary.

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