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".
Subscribe to:
Post Comments (Atom)
2 comments:
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.
I''m familiar with this subject too
Post a Comment