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.

Cohesions allow business logic to dictate which combination of participants can fail or succeed, while permitting the transaction as a whole to make forward progress ­ this allows the transaction to proceed even in the event of failures.

BTP provides the necessary underpinning for conducting activities of real value over Web services, but at a cost. Web service developers will have to make their services BTP-aware using one of a number of BTP toolkits ­ such as HP Web Services Transactions. There's also a learning process associated with both BTP and the various BTP toolkits. The benefits far outweigh the costs, however, since Web services that support BTP implicitly benefit from being kept in step with other Web services involved in your business.

How to Ruin an Enterprise Application...
If you really want to ruin a good Web services­based application, then simply ignore the matter of maintaining consistency among your partners', suppliers', and customers' Web services. Stand back and watch as your systems annoy anyone and everyone you do business with by sending them different, conflicting signals with no arbitration. Don't believe me? Just wait until you've "shipped" your first out-of-stock item that the credit card company couldn't authorize, with a courier that can't deliver. Now scale that to the Web ­ scary, isn't it?

...and How Not To
You guessed it. Where business transactions between multiple parties carry some intrinsic value, they must be supported by transactions. For Web services, BTP is the runaway leader in what's currently a one-horse race ­ it's a simple bet, isn't it?

Published Apr. 5, 2002— Reads 13,854
Copyright © 2002 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

About Jim Webber
Dr. Jim Webber is a senior researcher from the University of Newcastle
upon Tyne, currently working in the convergence of Web Services and Grid
technologies at the University of Sydney, Australia. Jim was previously
Web Services architect with Arjuna Technologies where he worked on Web
Services transactioning technology, including being one of the original
authors of the WS-CAF specification. Prior to Arjuna, Jim was the lead
developer with Hewlett-Packard on the industry's first Web Services
Transaction solution. Co-author of "Developing Enterprise Web Services -
An Architect's Guide," Jim is an active speaker and author in the Web
Services space. Jim's home on the web is http://jim.webber.name