Any executive worth his wingtips knows that most exciting new technologies don't generally burst upon the business scene in full glory. Instead, they arrive in phases, like a space launch. You've got the lift-off phase, where gurus and techies foam with excitement about the concept's potential. (This also tends to be where the hype barometer registers its highest reading.) Then you have phase two, otherwise known as reality. Glitches show up, vendors start pushing proprietary solutions, standards bodies start pontificating, and users start tinkering with the technology in an effort to get it to work as originally advertised. If all goes well, you get phase three, in which the technology is finally mature enough to be widely accepted.
When it comes to Web services, we've just engaged the booster rockets on phase two. The Web services approach is supposed to make it simple and painless to integrate business applications by using the Internet and a gaggle of technology standards such as HTTP, XML, SOAP and UDDI. And Web services probably will do that--in time. Right now, however, the present technology has limitations that hinder companies' ability to use it for truly heavyweight applications, such as Web-based business-to-business transactions.
Web services, meet business expectations. It's time to have a little chat.
Ironically, the things that make Web services so promising also hamstrings its ability to deliver the kind of performance that businesses need for mission-critical applications such as e-tailing or online billing.
HTTP--the most basic protocol underlying Web services--is one reason. "The beauty of Web services are that they leverage HTTP-based Internet and browser technology, an existing infrastructure that we all use," says Benoit Gaucherin, the vice president of technology at Sapient Corp., a consultancy in Cambridge, Mass. Having this common infrastructure makes it much simpler and cheaper for companies to interconnect since they don't have to waste time and money setting up custom integration hooks.
However, HTTP, although universal, isn't built to handle many of the requirements of bigtime transactional applications, which many experts envision as a major use for Web services. One of the problems is that HTTP is what is known as sessionless, or eventless. This means that when one computer interacts with another across the Internet, there's no ongoing connection between the two--no memory of the transaction, if you will. "Interaction is done via requests or responses, but you can't maintain information between requests," says Gaucherin.
"HTTP is not a reliable communications mechanism," agrees Daniel Sholler, an analyst at Meta Group Inc. in Stamford, Conn. "It can't guarantee certain things, such as that the message will always be delivered, or that it will be only delivered once, or that it can be sent in a certain sequence."
In other words, if Web services are to be used for serious transactional processing, they will need to make a series of requests to another server, and those requests will require a history of previous transactions. For example, a retail banking application will use a number of different requests when it asks to transfer money from one place to another, from verifying account information to making the actual transfer. Each request builds on the previous one, so the different servers need to be able to store information about each session across a number of requests.
The upshot is that Web services aren't comparable to traditional transaction processing applications--such as MQ-based systems--for companies that need a truly reliable medium. Sholler emphasizes that this doesn't mean that HTTP is bad, just limited. "It's fine for things like going to a website," he says. "If the message doesn't get through, it's not a big deal, you just hit refresh and try again. But a certain class of business transaction needs more reliability. If I were trying to wire a payment to my bank, for example, HTTP would stink" as far as reliability is concerned.
There are efforts to address the problem. IBM, for example, is developing a follow-on standard to HTTP called "reliable HTTP," or HTTPR. And Internet pioneer Marshall Rose is working on a completely new technology standard called BEEP that could eventually serve as an alternative to HTTP for Web services. Both standards, however, are still in development and could take months or even years to reach fruition.
Security is another hurdle to widespread business deployment of Web services. The standards that comprise Web services contain nothing that will allow businesses to build secure applications with them. Issues such as authorization and encryption simply aren't addressed. And non-repudiation--which means that once a company receives confirmation of something like a purchase order, that confirmation cannot be denied--are also made difficult by the open nature of Internet technology.
There are security standards that have been built for the Web in general, says Bob Sutor, the director of e-business standards strategy for IBM Corp. in Somers, N.Y. But if Web services is going to be used for major transactional applications, "businesses will want a much finer level of granularity than such standards offer," he says.
When it comes to security standards for Web services, there are two opposing camps. The Liberty Alliance, created by a group of companies led by Sun Microsystems Inc., and Passport, the security segment of Microsoft Corp.'s .Net Web services strategy. "These standards efforts are already underway and we should have most of the pieces this year," says Sutor. "The big question is who is going to provide them."
And Sutor is quick to point out that even if standards are in place this year, there's a big difference between deciding on standards and widespread implementation of business applications based on those standards. "It's going to take the next two or three years to work through security and reliability issues for Web services," he cautions.
Working with Work Arounds
In spite of the limitations, Web services offers promise enough for many companies to devise ways to get around the existing technological weaknesses. For example, companies can run Web services on protocols other than HTTP, says Gaucherin. "You can use SOAP over MQ or SMTP e-mail protocols, which would be an improvement in that it would give guaranteed deliveries," he says.
Another option is to customize your Web services so that it can handle the reliability demands of transaction processing. Mark Daugherty and Randy Vanstory, the respective enterprise applications manager and cofounder of Joe Auto in Houston, Texas, hired integrators from Extreme Logic to build Web services that link the company's service centers with its parts suppliers. To get the systems to operate at the level of reliability required by Vanstory, Extreme Logic CTO Keith Landers had to build custom code into the Web services. Putting a parts order into the system requires a number of different requests to a database. If something happens and the database fails partway through that series of requests, the Web service has to know at what point in the request sequence the failure occurred and update all the systems accordingly. "Current Web service specifications don't support those kinds of concepts," say Linder, "so we had to build that in."
The problem with both of those fixes, however, arises when corporations attempt to interconnect their customized systems with the untouched technology of other companies. "The issue isn't that you can't do these things, but that there's no standard way to do it," says Sholler. "And one of the main promises of Web services is that you will have to know as little as possible about technology on the other end of the transaction."
Companies that deviate from Web services standards--or augment them with non-standard code--nullify that advantage since they must reconcile their work-around code with any outside Web services in order for everything to work. In other words, such fixes can leave companies facing the same old integration headache that Web services was supposed to cure.
There is a third option for companies that want to use Web services now. A couple of companies, such as Grand Central Communications Inc. and Kenamea Inc., both based in San Francisco, have built Web services networks that act as an integration hub between one company's applications and its outside suppliers. For a fee, usually subscription based, these companies will handle any technical deviations and will also guarantee reliability and security.
Eastman Chemical Co. has signed on with Grand Central to build a number of Web services for the Kingsport, Tenn.-based chemical giant. It started by building Web services for things like product catalogues and posting them to the website, says Caroll Pleasant, who analyzes emerging digital technologies for Eastman. Then, he says, "We offload onto GC the connection management and let them deal with it, along with different implemenations of various protocols. There are standards out there, but there are also still interoperability problems between different peoples' technology stacks, and that's unlikely to get fixed any time soon."
The last thing to do is just wait for the technology to mature before embarking on Web services for a major transactional application. Vendors are showing an unusual degree of cooperation when it comes to guaranteeing interoperability in the Web services arena. But in the meantime, you can start experimenting with Web services that don't require the security and reliability of these bigger applications, advises Pleasant.
"We are specifically taking a conservative approach and seeing what we can do with the technology the way that it is right now. We'll learn this space one step at a time," he says.
By doing so, companies like Eastman will have all hands on the flight deck and ready to rock when the technology does launch into phase three. Some people reject Web services, Pleasant says, because it can't do what it promises to do yet. However, he says, by noodling around with them now "when we get to the point where we have a need for heavier weight systems, the technology may have matured to the point where it can handle them."