After a long period in the coffee wilderness I was fortunate to be re-acquainted with the Roger Sessions newsletter the other day. For some reason my subscription seemed to dry up around the time that my taste in coffee changed to more that of a Javanese flavour. So as you can imagine it felt quite heart warming to re-subscribe and see that the newsletter has been running for more than 10 years now. Ah the memories of taxis, airports and passengers that were used to explain MTS object pooling all came back to me! All is well I thought, and now for some catching up on pervious newsletters!

 

In typical fashion I started last first with the November 2004 newsletter - but that's as far as I’ve got ... Asynchronous messaging and transactions was the discussion with reference to WS-Specifications and their implementation in Indigo. I am interested in Indigo for many reasons – most of which Roger articulates so well in the first part of the article. However, reading on, he raises a concern (well he views it as a major flaw!) that Microsoft do not plan to support the WS-BA (Business Activity Framework) specification and will rely on implementing WS-AT (Atomic Transactions or the WS specification for implementing 2-phase commit) to ensure data consistency.

 

He argues that implementing WS-AT is flawed especially when it is used in conjunction with asynchronous services. This is because 2PC (and hence WS-AT) relies on the locking of physical resources (databases) until the transaction is completed – if a service is asynchronous then there is no guarantee as to its lifetime and therefore, in a workflow scenario disparate resources may remain locked for an unspecified amount of time severely impacting scalability not to mention all of the other problems that would arise.

 

This is true of course! But assuming that this is a flaw in WS-AT (or the Indigo implementation of WS-AT for that matter) is not correct. It is in fact a flaw in the SOA design that attempts to wrap asynchronous service calls within a WS-AT transaction!

 

So yes, anyone who tries to use WS-AT to co-ordinate workflow across web services is acting against the most strongly held Transaction Processing (TP) design pattern in the book – such that the resource should be released as soon as possible.

 

I would argue that 2PC is a necessary requirement in developing any enterprise system and therefore mandates its inclusion in Service oriented systems. Services are fractal. Services can be built from other services and so on, building up architectural layers of functionality. Activity or functional services will typically be responsible for managing transactions and this can be achieved through synchronous co-ordinated invocation of other functional services through the use of WS-AT (not forgetting the TP rules that I learnt from Roger all those years ago with MTS!). If a business process service needs to behave asynchronously then 2PC transactions are unlikely to be suitable and the pattern of its usage should differ and this should be explained by its creator.

 

In order to understand the role of WS-BA we need to look at business process management and orchestration and how this will implement such standards. It will be these tools that manage ‘long-running transactions’ and the compensating actions that occur as a result of their failure. One could imagine that these business process management services will sit above the underlying infrastructure of Indigo and provide far more sophisticated mechanisms to managing business processes and workflow than could be possible by hand-crafting WS-BA implementations directly on top of Indigo itself.