Transaction interoperability: myth or reality?

I've been reading some interesting posts on a few mailing lists about transaction interoperability and whether a) it's possible, b) desirable, and c) how to achieve it. This is an issue that's pretty close to my heart because I've been working with various people over the years, such as Eric, Ian and Tom, to accomplish it in one environment or another. I hope what follows is an objective discussion.

The short answer to a) is "yes" it's possible. The longer answer is "it often takes a lot of effort to do it, and sometimes you have to go through more hoops than you really should". Historically transaction interoperability has been a kind of Holy Grail, because the likes of CICS, Tuxedo and DEC ACMS were backed by companies who had the muscle to push the homogeneous software pattern: one implementation throughout the organisation. The obvious result of this was vendor lock-in, but the knock on effect was that if you really really really needed interoperability then you'd pay one or more of these companies to tailor a solution for you. A win-win scenario for them, but not particularly attractive to the customer.

As a result, there have been several efforts to get interoperability over the years, the most notable probably being the CORBA Object Transaction Service (OTS). Unfortunately, the early versions of the OTS (prior to 1.2) suffered from the general non-interoperability of CORBA implementations (don't get me started on the BOA!) which meant that even if you had the same OTS implementation running at both sides of a conversation, unless it was running on the same CORBA ORB, interoperability was once again tricky to achieve. Fortunately the likes of Steve, Michi and others helped to massage CORBA into an interoperable distributed system (almost a decade after the OMG was first established), and OTS 1.2 and beyond became more and more interoperable. Unfortunately for one reason or another (the BOA being one of them), the OTS take up was slower than originally imagined and even today interoperability at this level isn't great.

However, that's where Web Services can help. I've said this before, but I think it's important enough to say again: Web Services are as much about interoperability as they are about Internet scale computing. We're seeing a lot of pull for them in the interoperability space. Fortunately the Web Services transactions specifications from OASIS and IBSoft provide an Atomic Transaction model that is designed specifically for interoperability (I'm biased here, but I'd say that the one in WS-TXM is better for this). So, interoperability at this level has become a reality and we're starting to see implementations of different underlying transaction services talking to each other!

OK, so some of the above is actually an answer to c). But back to b) and I think this is a no-brainer in today's world of cost-cutting and company mergers; the notion of a single implementation of anything, be it database, application server or transaction service, is simply no longer true (if it ever truly was). Companies that grow through acquisitions typically tend not to be able to have edicts about scrapping existing infrastructural investments in favour of the current software vendor of the day. So, interoperability within the organisation is happening as a fact of life today. Interoperability across organisations (even at the level of traditional ACID transactions) will happen, but it'll be less prevelant (simply because the ACID transaction model doesn't really work in that world).

That's not to say that all transaction services need to support interoperability. There are bound to be environments where interoperability is not needed by default and where extra work may be necessary when and if it ever is needed. But I think these are niche cases and should be carefully examined before going ahead.