Re: [ws-caf] WS-ACID

[Mark Little <mark.little@arjuna.com>]

Haugen Robert wrote:

>>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:
>  
>
No, that talks about transaction bridging within the same model. For 
example, JTA-to-WSAT-to-JTA. It's not JTA-to-WSBA-to-WSAT in that 
description. Where we've seen that kind of bridging, something like 
WS-BP is appropriate. In the more common bridging (homogeneous model) 
then something like WS-ACID does this for us automatically (and WS-AT). 
You only have to look at the interoperability workshop we attended (and 
Choreology were there too) for WS-AT and WS-BA to see that. If WS-AT (or 
WS-ACID) is right for customer requirements now, then I see no reason to 
go with something that is unproven.

The text (if you read it all,) explicitly talks about implementation: 
how you support multiple protocols is a back-end implementation choice 
and should not be reflected in those protocols. So, despite the fact 
that Arjuna have the capability to support a range of protocols with the 
same underlying implementation, that doesn't mean that someone else had 
to do likewise.

>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>
>  
>
Mark.

-- 
Mark Little
Chief Architect
Arjuna Technologies Ltd
(www.arjuna.com)