RE: [ws-caf] WS-ACID

["Haugen Robert" <Robert.Haugen@choreology.com>]

> I think that just goes to show that "one size doesn't fit all".

Funny.

But I see that you have actually had the same experience, that people
want one transaction protocol to cover many types of participants -
where the behavioral differences are in the participants, not the
protocol:

http://markclittle.blogspot.com/2005/02/shape-of-things-to-come.html

<excerpt>
There are several reasons why we took the approach back in 2002 to have
two separate products and I'll mention a couple. When we were working as
part of HP Middleware on the world's first Web Services transactions
product it was a separate entity from what was then known as the HP
Transaction Service; it also seemed unlikely that people would want Web
Services transactions bundles with a transaction manager that required a
CORBA ORB, despite the fact that you wouldn't use the ORB if you were
working purely in the Web Services arena.

That last point has, with the benefit of hindsight, proven wrong. Back
in 2002, just before the finalisation of the end of the HP-Compaq
merger, I wrote an internal document about what I called End-to-end
Transactions. (Apparently Gartner calls them Multimodal Transactions
these days.) It was a way of describing how Web Services transactions
(and specifically the product we'd been working on for HP) could be used
to glue together other transaction domains, from mobile phones to
laptops to mainframes, and incorporating potentially different
transaction models. Some of this went on to become the Business Process
transaction model in WS-Transaction Management, but most of it got filed
in the dark corners of my brain when we span out of HP. But the main
concept was that Web Services transactions don't just start in the Web
Services ether: they'll typically begin in some corporate intranet and
span to other corporate internets, with Web Services as the glue.

Funnily enough, over the past couple of years we've seen precisely this
kind of use case from the early adopters of ArjunaXTS. Many of them have
been asking for this kind of capability: bridging between J2EE
transactions and Web Services transactions and vice versa. As a result,
because we had two separate products (and the glue to stick them
together), these early adopters ended up taking them both, with the
added maintenance, setup, management etc. costs that that implies. So,
one product seemed like an obvious improvement. I see the bridging
capability a little like Sauron's ring: "and in the darkness bind them".

</excerpt>