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.
BTP Atoms are similar to atomic transactions. The difference is that Web services participating in BTP transactions aren't usually owned by the initiator and thus atomicity via strict two-phase locking can't be guaranteed. However, Web services participating in an Atom are guaranteed the same outcome as all other participants.
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 servicesbased 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?
Author Bio
Jim Webber, PhD, a senior engineer with Hewlett-Packard, is based at HP's Arjuna Laboratory, HP's transactioning center. Jim architects HP's Web Service Transactioning solution (HP-WST), is involved with standards processes for transactional Web services, and is currently participating in the OASIS BTP effort.
Jim_Webber@HP.com
All Rights Reserved
Copyright © 2004 SYS-CON Media, Inc.
E-mail:
info@sys-con.com
