Mark Little sent:

> Green, Alastair J. wrote:
>
> >I think we should be a little more cautious about the
> maturity of all
> >these specs, and have more of an eye to product completeness and
> >maturity, including ability to protect users from standards
> variation
> >and flux.
> >
> >The WS-Coordination and WS-Transaction (later WS-AT and WS-BA) specs
> >have in fact been out since August 2002 (we implemented them
> in Cohesions 2.0 in the ensuing six months, alongside BTP).
> The specs were revised in September 2003, and then again in
> November 2004. They have not changed vastly over these last two years.
> >
> >They are therefore not that new, and they unfortunately add very
little
> >to the thinking or functionality of OASIS BTP, which was
> completed in June 2002 (and which has the advantage of being
> a single spec, not two).
> >
> >
> I think it's fair to say that the WS-AA/WS-BA specifications have been

> around in one form or another since before BTP began. Their genesis as

> Web Services specifications predates BTP by several months. However, I

> think that is less important than the fact that they are based on well

> founded technologies and protocols that go back to the 60's (WS-AA)
and
> the late 80's (Sagas) - it's even arguable that it goes back earlier
> with Jim Gray's seminal paper on Sphere's of Control, while at IBM. I
> believe it is unfair to try to imply that the specifications are
> immature compared to something else (anything else for that matter).

There's a distinction to be made between the underlying assumptions and
models
and the specifics of a protocol specification. On the model aspect, all
of the
specifications were devised in the light of ideas going back a long way.
How
much of those ideas actually impacts the protocol is less obvious - BTP,
for
example, which can certainly be used for pure-compensation, Saga-style
cases,
can also be used for atomic (since it's underlying assumption is that
the
protocol does NOT constrain the internal behaviour of the service,
though
other agreements can) - there is nothing in the WS-BA specification
that defines the behaviour above the level of one participant, so it
could
handle several compensation-only approaches (though not any applications
where real effects must not escape).


> >We therefore have (including the latest contender, WS-CAF) three
> >families and six protocols, to do one job: distributed
> service coordination using a two-phase outcome approach. This
> is a symptom of how the standards need to settle down if we
> are to see any level of genuine interoperability at work.
> They are useful work, but customers need to be protected from
> this flux to make use of product in this area.
> >
> >
> I believe the dust is beginning to settle. If you check out what
> analysts and other "luminaries" in the business are saying, they are
> talking about the transaction approach in WS-CAF and the IBM/MSFT/BEA
> specifications. These two approaches are sufficiently similar that,
> hopefully, some amalgam of them will be what the industry
> moves forward with.

I'm not quite clear what the "transaction approach" is. The only
commonality is
really that they both have a context/registration mechanism that other
things can layer on, and that one of the things is a atomic/acid
protocol.
And perhaps that the atomic protocol should be a direct translation into
the
ws-specs du jour of a previous protocol (thus allowing distribution of a

transaction between tightly-coupled applications in a single
trust/management
domain using ws protocols). That's scarcely
a transaction approach for SOA, though it has utility.

On the wider question of how to provide appropriate transactionality for

loosely-coupled systems, the dust is nowhere near settling. The WS-CAF
committee hasn't even started consideration of its WS-TXM layer, and,
based on changes it has made elsewhere, the chances of the LRA and BP
specs coming out as they went in is negligible. There has never been
open discussion on this list about the vices and virtues of the
compensation-only
approach of WS-BA (for vices, see Choreology feedback :-) ).

> There are differences, to be sure, but as we've just seen
with
> OASIS WS-DM being adopted as a standard despite the fact that the
> specifications it references aren't finalised yet, there is customer
> demand for these protocols now. Jumping in the water with something
> based on WS-AA/WS-BA and/or WS-CAF is a good approach IMO. There are
> certainly more commercial implementations of these
> specifications than
> any other Web Services transaction protocol.

Well, there are around 2 and half commercial implementations of WS-AT,
with the
ability to link into database resources in the participants to actually
do something useful. Since WS-AT is just existing ACID semantics in SOAP
messages, that isn't a big deal. There are 6 (commercial organisation)
implementations of WS-AT, and 5 of WS-BA that can send the right
protocol
messages to each other, but they don't all have real transaction
capability behind
the endpoints. (there are some academic implementations too). Are there
any WS-BA, WS-LRA, WS-BP commercial implementations that allow
integration
with database and other resources in the participants, other than
our Cohesions configured to use WS-BA ?

> >Another manifestation of the earliness of *interoperable*
> >loosely-coupled transactions is the status of the specs.
> Unlike BTP, which has been through an open standards process
> to become an OASIS Committee Draft 1.1, and reflects product
> implementation experience, the WS-C+Tx specs are still in a
> proprietary workshop process, and will have to go through a
> standards body to stabilize. Don't expect stable output
> earlier than twelve or eighteen months from now. The WS-CAF
> process also grinds slow, and the specs are changing a lot as they go.
> >
> >
> See above. This is FUD (Fear, Uncertainty and Doubt).

An interoperable protocol spec needs to have a lot more finality than
just a conceptual model based on previous work. And the loosely-coupled
case is not stable. One could take the view that whatever comes forth
from the WS-BA authors will be the final word, but if it goes into a
standards body it is unlikely to be rubber-stamped in three months.
(what
would be the value of such an endorsement). Since
WS-CAF hasn't started on WS-TXM (surely the larger part of its work), it
would seem unlikely to reach committee draft stability in less time than
it has taken so far (since October 2003).

Obviously not 100% objective.
Peter

-----------------------------------
Chief Scientist
Choreology Ltd
68 Lombard Street, London EC3V 9LJ, UK
web: www.choreology.com
phone: +44 8707 390066
mobile: +44 7951 536168