By now we've all heard a fair bit about Web services, a lot of hype and few hints that there's something really innovative going on here. Trudge round any developer conference and you'll hear the chatter of eager developers wanting to roll together a host of disparate Web services into the most fantastic and powerful applications the enterprise has ever seen.

Composing enterprise applications out of Web services is a hot topic, but the practicalities of building real applications out of Web services are a world apart from the sales-speak and hyperbole that we've heard so far.

Web Services: Some Home Truths
While Web services are beautifully simple and intuitive, with a really gentle learning curve, their simplicity belies a more troublesome implementation. Since the Web services model is so simple, much of the richness (and complexity) that we've been used to in previous enterprise architectures isn't there for us to draw upon ­ or at least not yet.

Enterprise developers are going to be given a hitherto unparalleled world of choice in terms of the components they'll use, and component suppliers will have to compete on criteria like cost, performance, and functionality. Better still, significant effort is going into improving the whole infrastructure on which the Web services architecture rests, like increasingly robust application servers and reliable transports like IBM's HTTPR. This all sounds like it should make a great platform ­ and it does, mostly.

With increasingly robust back-end and transport technologies, and plenty of component choice, it would seem that Web services really might be the silver bullet for enterprise computing. There is, however, a dark cloud hanging over this otherwise beautiful horizon: developers will now need to routinely support activities that span multiple Web services across multiple enterprises. This raises the rather prickly issue of how to maintain consistency among these components. While this isn't a new problem, it's a new one for Web services.

A New Hope: OASIS BTP
About a year ago, some people from a range of vendors with similar concerns got together under the umbrella of the OASIS Business Transaction Protocol (BTP) initiative. Like me, these people spent their days worrying that application developers were going to write software that spanned multiple business systems, and wanted to ensure that these systems would work reliably.

The result of this effort is a draft standard for transactioning in loosely coupled environments like Web services. OASIS BTP is an innovative, extended transaction model designed to allow work to progress even in the presence of failures ­ a significantly different take on the problem compared to the EJB or JTS transactioning we've been used to, where failure of any aspect is the undoing of the whole transaction.

While BTP is a lengthy and intricate work, it is predicated upon two fundamental constructs: the Atom and the Cohesion.