Wednesday, February 23, 2005

The shape of things to come

Several years ago REM released a great song called It's the end of the world as we know it. That song seems quite appropriate in some ways at the moment, because we're about to release a GA version of the Arjuna Transaction Service 4.0. As I've said before, I've been working on Arjuna since 1987 and have seen it morph quite a bit over the years. As this paper shows, its seen a lot of changes and most of those have reflected changes in middleware architectures. So it's appropriate and in line with previous changes, that ArjunaTS 4.0 merges our formerly stand-alone Web Services transactions product ArjunaXTS with what has always been called the Arjuna Transaction Service and included JTA and OTS functionality.

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


Alastair Green said...

Out of darkness, or seeing the light ...

As you know, Mark, ever since the earliest days of OASIS Business Transaction Protocol in early 2001, Choreology has argued that a single two-phase outcome distribution protocol (like BTP, or WS-AT or WS-BA) is sufficient for the coordination messages required to support any two-phase resource's involvement in one, overarching distributed transaction -- and that "two-phase resource" can be an XA-compliant RM, or a web service or a MOM listener that is capable of supporting a general, single state transition model: initial-through-provisional-to-final (confirm or cancel).

The Arjuna motto "one size does not fit all" has been a consistent bone of contention in standards bodies and industry conferences between us. I believe that one size does not fit all is a theoretical reflection of product legacy: if you are IBM or IONA, and you have existing ACID-only products, then it is easier to build (or talk about) a new, parallel product line than retrofit to the architecture which the problem actually demands: a single product with a single coordination protocol, supporting a range of participant types.

That's been the architectural principle of Choreology's Cohesions product since we started four years ago: one API (with variants and specializations for participant types, stemming from one class: ProvisionalFinalParticipant).

With our Cohesions 3.0 product, which is at the fourth, heavily tested Early Adopter release, you can unify zero-phase, single-phase and two-phase resources in a nested business transaction tree, with full selective outcome. You can run this concurrently over multiple carrier protocols (e.g. JRMI and SOAP), and you can combine this with any form of application communication you like (MOM, FTP, remote invocations, RR).

We've certainly found that this "one size fits all" is not just theoretically superior (more general) but practically very attractive. It means, for example, that we build off a single, common distributed coordination code base, with pluggable transports, and configurable alternate coordination protocols (BTP and WS-C+Tx).

I'm glad to see you're coming round to this approach, although the ATS 4.0 offering seems to be more of a packaging revamp than a true unified-architecture product. It's not clear that ATS 4.0 can support concurrent involvement, in a single transaction, of XA resources and contingent Web Services.

Worth visiting our website ( and looking at our standards pages to understand just how long and consistently Choreology has been arguing that the plurality of protocols (and in the Arjuna case, plurality of APIs) is a wrong-headed, expensive example of needless variation.

In particular, I think that the feedback paper that Peter Furniss and I put into the WS-C+Tx workshop process almost a year ago lays out this approach very fully, and from first principles. One can also refer to a paper by Bob Haugen and Peter to the OASIS symposium a month later, entitled something like "Six into Two should go".

Alastair Green
CTO, Choreology Ltd

Mark Little said...

Hi Alastair. We can all read into some text what we might like to see ;-)

I may blog separately about the "one-size doesn't fit all" issue, but since I'm sure this is going to come up in CAF at some point, it may not be worth the effort here. However, I will say that it is not a "motto" held by only Arjuna: you just have to look at everyone else: IBM, Microsoft, BEA, IONA, Oracle, Fujitsu, Sun, to name but a few.

I've always thought that our discussions in and around this area seem like the Potato
sketch from Blackadder, where:

"Edmund: I was under the impression that it was common maritime practice for a ship to have a crew.

Rum: Opinion is divided on the subject.

Edmund: Oh, really? [starting to get the picture]

Rum: Yahs. All the other captains say it is; I say it isn't"

That's not to say that I automatically agree with the crowd. As you may recall, I often quote the million flies argument. However, in this case, having worked on *both* approaches (and importantly, sold products that do both), I'm speaking from opinion that has taken into account feedback from customers.

ATS 4.0 is a unified product, that transparently ties together transactions that start in any domain and span to any other domain. Currently the supported domains are J2EE/CORBA and Web Services, but we've done work with other vertical users on domains that have their own transaction models.

It's important to recognise that previously this has been possible by using both of our individually available transaction products, but we have been working with customers to make it easier for them via a single product release.

I will say that, as was pointed out at HPTS 2003 when we both presented on a similar topic, don't mix implementations requirements with application-level/protocol-level semantics.

Anonymous said...

I''m familiar with this subject too