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