Sunday, August 26, 2007

XA versus WS-TX?

I'm really not quite sure what to say about this article. While the author is right that XA is more mature than WS-TX and that transactions are an important tool in an achitect's tool-belt, saying that XA is a replacement for Web Services transactions is a bit like saying that because IIOP is more mature than SOAP we should all be using it. It's true, but it's never going to happen and overlooks what Web Services bring to distributed transactions: interoperability. I've written about that many times, so won't go over that again.

It's nice to hear that Oracle have identified problems with WS-TX. We all have throughout the evolution of the specifications/standard. WS-CAF offered a better solution over all, but didn't get the backing of IBM and MSFT, which is unfortunate: I still think that from an enterprise perspective all of the specifications within WS-CAF have technical advantages over WS-TX.

However, who hasn't identified problems in the way different XA implementations interpret the XA specification? Last time I looked, we had several workarounds for the differences between Oracle 9i and 10g, let alone how they differ between DB2 and SQLServer. Of course many of these are down to bugs in the respective XA implementation or wrong interpretations of the specification, but just saying something is XA compliant doesn't mean it immediately has a level of maturity.

WS-AT (or WS-ACID in WS-CAF), was developed to allow arbitrary two-phase commit participants to be enrolled in a transaction. Quite similar to OTS in that regard. Obviously XA is important, so it should be considered when providing any new transaction standard, but 2PC existed before XA, so it makes sense to not limit yourself if you don't have to. On that note, I hope I'm not alone in remembering the original XAML?!