Peter Holditch

The waves of IT, as they are often called to, are marked out reasonably accurately by languages. Starting almost at the beginning, take COBOL. With its love of uppercase characters, and overly restrictive attitude to what column the uppercase characters appear in - not to mention its extraordinary zeal for the full stop - COBOL has always struck me as a language for programmers to use to shout at computers. I guess that's a reasonable alternative to feeding them punched cards, or worse, flicking switches on a front panel - you can see why the original COBOL guys wanted to shout!

Since the COBOL era, we have come through various languages, some keener than others on the capital letter, none as controlling about screen columns and full stops (the semicolon has now taken its rightful place as the most feared punctuation mark). During this journey, languages remained relatively free of any notion of distributed processing, and other languages came in to being to fill that gap; for instance, DCE and CORBA's idl, which tried to describe distributed computing systems and subversively surface their interfaces in programming languages in order to try and keep the distribution transparent to the language programmer.

For many reasons (that make a debate in themselves, so please just buy my assertion here) these programming models almost without exception failed to deliver very large scale distributed systems - I believe that was largely because in their effort to hide the mechanics of distribution, designers were lulled into a false sense that any application model could be implemented with any distribution model - leading to many systems which, however beautiful on the drawing board or in the design tool, performed like one legged dead donkeys, spending more time distributing stuff than doing any processing.

The Dawning of a New Age?
So now, we're told, we're at the dawning of a new age - the age of Web services, a new language, based on XML, for the distribution of computing systems. In a bizarre and unexpected throwback to COBOL, Web services messages are pretty text dense - they generally seem to use an alarming quantity of uppercase, and are more rigid about punctuation than you could dream. This time, however, we are witnessing the dramatic rise of the >, <, and \ characters. If COBOL was the language for people to use to shout at computers, Web services has provided a language for computers to use to shout at each other - through Venetian blinds.

However, I contend that this is a good thing. People frown and get paranoid about SOAP messages - they grimace as they think of the bytes passing up and down the network - and this forces them to do what CORBA et al tried to distract them from - They try to minimize the number of monstrous interfaces, they try to send big bulky messages instead of lots of small ones across the interfaces they feel obliged to provide, and they become obsessed with isolating code changes from the punctuation-laden monsters that are flying over their wires. In short, they design good distributed systems. The mantra for good Web service design is asynchronous, coarse grained, loosely coupled, all of which your gut feels you should be doing when you see the things in action.

So, Have I Lost The Plot?
So, have I lost the plot then? You can argue among yourselves about that, but I assert that I haven't. Web services are the new distributed systems approach; transactions are all about providing the infrastructure to enable people to build distributed business systems without having to spend the rest of their lives thinking through and coding for every possible failure mode, so there must be a connection between the two - and there is. So here we go with the column that you thought you were expecting...

To date, most demos of Web services have been rather simple - get a stock quote, get a weather report, etc. That's fine, until you try to implement a real system using them and find that you need the asynchronous behavior that I mentioned before - and start to think through the consequences of any number of potential failures through the distributed system as a whole. You quickly realize that the simple "knock up a servlet with SAX and/or Apache libraries" approach to Web services won't get you very far. As I've said before, transaction coordination is very closely coupled to infrastructure, so if you start messing with XML parsers and JTA APIs to try and build a concept of a distributed business action into your system, then congratulations! You've just won first prize in an infrastructure development beauty contest.

But help is at hand.... From the protocol perspective, BEA, IBM, and Microsoft have come up with a set of specifications to enable the propagation of transaction context between Web services. These two specifications are called WS-Coordination and WS-Transaction. Fundamentally, the thing you need to do to have multiple business operations behave as a cohesive unit is to associate some kind of identifier with all of them. Once you have done this, you can instruct the collection of operations to roll forward or back, without knowing what the operations actually were - so long as you know the correct identifier. This is what WS-Coordination provides - a way to generate this identifier and ship it along with the XML messages that make up the Web service interactions. This identifier is known as a coordination context. Provision is also made for identifying a service that can actually provide the coordination services. Note that no mention has been made of what is happening beyond "something is being coordinated" - WS-Coordination defines an abstract coordination relationship. Two concrete implementations of this are defined in the WS-Transaction specification. After all, it is somehow pleasingly symmetrical to have a two-phase standard define a coordination protocol!

Before I launch into WS-Transaction, let's take a step back here... remember that Web services are a way for computers to shout at each other through Venetian blinds. This isn't the kind of thing that you want a lot of going on, we already agreed on that when thinking about how to implement distributed systems. Imagine an atomic transaction.... All those pre-commit, prepare, and commit messages flying back and forth.

If you're not feeling queasy by now, you're clearly not imagining hard enough. Also, remember the Web services design mantra... the word "asynchronous" appeared there, didn't it? So did the phrase "loosely coupled." A conventional two-phase transaction is a great way to achieve synchronous coupling between things. We already decided that this is to be avoided, so what gives? Read on!

It won't surprise you to know that the WS-Transaction spec provides ways to minimize the impact of cohesive behavior on the performance of the system. First, there is explicit support for interposed managers. Imagine that your transaction coordinator was on the other side of the world, and all those prepares, commits, and so on were flying over a slow WAN. In the case where the service you're making available locally is composed of a number of other Web services, you don't want the internal workings exposed across the WAN and coordinated on that basis - after all, that would be fine grained. The spec allows the local end of the connection to interpose its own transaction manager so that the remote side sees a single resource to prepare and commit - the fact that it may map to many coordinated resources on the local side, each of which will need its own flurry of prepares and commits, is taken care of by the local interposed coordinator, achieving the coarse granularity that we seek.

So, I hear you cry, what about asynchronicity? Well, that's taken care of too. The WS-Transaction specification provides for two coordination types, called AT and BA standing for atomic transaction and business activity.

An atomic transaction is what you expect, know, and love... a synchronized set of related prepares and commits to being all the work in an identified unit to an ACID close. A business activity, on the other hand, is expected to be long lasting - maybe months, the term of a contract perhaps. In a business activity, individual changes are made permanent and visible as they happen, with the ability to back out changes (based on their coordination context), if the need arises some time in the future, with what is known as a compensating action - for example, cancelling a reservation, refunding a payment, etc. This isn't trying to make it look as if the activities didn't occur, but rather to take some new action which ensures that every party in the activity reaches a new, mutually acceptable state.

It's Time to Run!
So, the WS-Coordination and WS-Transaction specifications together identify how systems should communicate in order to get reliable, business-meaningful results from a Web service-based system. This brings the goal of using Web services as the foundation for a standards based integration solution a big step closer.

Back on the developer's view, however, the other half of the problem is implementing the code that maps this protocol onto some underlying transaction manager. It is here that the development cost will mount up. It is also here that technologies like BEA's WebLogic Workshop can be expected to come to the rescue - transaction coordination is another infrastructure-level requirement that will be best delivered by a runtime engine such as that which underpins the Workshop system.

Then, finally, truly useful transactional behavior will be delivered to the masses, and quick return on integration investment will surely follow. Perhaps shouting through window dressings isn't so stupid after all.