WS-Transaction

A few days ago I talked about transactions and last night I was reviewing a new integration pattern whitepaper which also talked about transactions. It was clear from both my blog discussion and the integration pattern that the term transaction is being very overused and in some instances the usage is so woolly as to cause serious misunderstandings.

Basically there are four types of transactions we deal with; business transactions (someone buying something), logical transactions which normally mirror business transactions and so are typically called long lived transactions or sagas, compensatable transactions (Logical Unit of Work) and 2PC transactions.

Each of these transaction types has particular characteristics; usage scenario’s and failure semantics, for lots more detail see Jim Grey’s Book

Fairly recently there has been a drive to provide a standard for the latter two of the Transaction types (LUW and 2PC) as part of WS-Transaction . This is not the first time that the closely coupled 2PC type of transactions has been standardised; this was done by the back in 1994 as XA which had two parts: the Resource Manager (RM) standard for distributed transactions across multiple resources (normally databases) and the TM standard for Transaction Manager to Transaction manager integration. Most databases and many Transaction Managers meet the RM part of XA and so call themselves XA compliant although this is not strictly true as they don’t meet TM. Only Tuxedo ever met the TM spec and that was because it was written around the Tuxedo implementation in the first place. As an interesting side note even the simple and old RM spec does have some unknown outcomes on recovery so 2PC transactions are not all that simple.

Anyway WS-Transaction specifies the 2PC transactions in part 1 (Atomic Transactions) and the LUW type in part 2 (Business Activity). Looking at part 1 this is clearly about closely coupled, synchronous type transactions and how to implement them in the web services or SOA space. However the definition of a SOA based system includes the fact that that it must be loosely coupled which is a clear conflict with the concept of 2PC tight coupling and so with WS-Transaction part 1.

The bottom line is that whilst there may be some specific cases where you can use WS-trans part 1 in a SOA system in the general case I don’t think it be applicable. I’m still struggling with the scenario’s when it should be used and this gets into the whole area of Service entity’s or data oriented services which is another area which is a bit fraught. I will discuss this in a future blog.

Comments

• Anonymous
  March 19, 2004
  I was under the impression that WS-Transaction has been superseded by WS-AtomicTransaction and WS-BusinesActivity. Hasn't work on WS-Transaction been discontinued?
• Anonymous
  March 20, 2004
  WS-Transaction is made up of WS-AtomicTransaction (AT, part 1) and WS-BusinessActivity (BA, Part2)