So-called Web-services applications will soon talk to each other without human intervention. But first everyone needs to agree on how they’ll communicate.
In my last column, I wrote about Web services, which are business applications that share data with other programs over the Internet. Instead of people initiating every communication, computers could have virtual conversations with one another, taking care of routine transactions quickly and efficiently (see “What’s Going On Down at the Plant?“).
For instance, when your production system detects that you’re low on a critical part, it could automatically post a purchase request on a private extranet site that can be accessed only by your suppliers. Those suppliers’ computers could, in turn, initiate a buy order and feed that request into their own manufacturing system so the replacement part gets made and is shipped to you — all automatically.
Right now that kind of integration is difficult to achieve. Applications vary widely in how they handle data, so techies need to link up each application with others on a case-by-case basis, carefully converting data formats one line of code at a time. It’s a tedious process, and companies such as Tibco, WebMethods, and Vitria have staked out a decent business doing this kind of legacy integration.
With Web services, by contrast, applications would make their data available to the world, along with instructions for how to access and control the application itself. If this “interface,” as the programmers call it, gets built in a consistent manner, then applications of all sorts can easily communicate with one another unaided, with no case-by-case integration needed. With Web services, for example, an airline could easily share data with online travel sites, describing not only flight information but also fare availability, seating choices, and even in-flight movie options.
“It’s like putting up a webpage,” says Barry Morris, CEO of Iona, a company that sells technology to enable Web services and application integration. “Suddenly the webpage is available to millions of people. The same thing goes for Web services, only instead of a person with a browser accessing it, you’re going to have other programs accessing it.” Naturally, companies will provide security restrictions on their Web services to limit entry, just as they do with intranets and extranets today.
The key to making this scenario work is instituting a set of widely accepted protocols outlining exactly how Web services process information and communicate with each other. Right now three main protocols look promising: SOAP, WSDL, and UDDI. This is how they work:
— SOAP, simple object access protocol, defines how applications talk to one another to exchange information and commands. Think of it as a vocabulary list for the language these computers speak.
— WSDL, Web services description language, lets applications describe what services they offer, like a virtual menu.
— UDDI, universal description, discovery, and integration standard, creates a worldwide directory where businesses and the applications they use can locate other Web services; it functions like a phone book for Web services.
All three protocols are based on extensible markup language (XML), which means they’re relatively easy for Web programmers to learn and use. But they are still relatively new and haven’t been officially recognized by any major standards organizations. Only one, SOAP, is currently under active consideration by the World Wide Web Consortium, the most influential standards-making body for Web technologies. (Microsoft is also a backer of the SOAP standard.) But the ratification process for SOAP could take years. In other words, all of these emerging standards are still subject to change — and to possible subversion by large companies with enough clout to create their own variant versions of the standards (remember the “browser wars” between Microsoft and Netscape?).
For that reason, most information technology departments are waiting until the protocols become more universal before going full-bore into Web services. It’s just too risky to bet the farm on a few emerging standards. But keep an eye on these three, because they’re the leading candidates right now. And once a common language does emerge, Web services will be a central part of the next big wave of corporate IT investment.
For more information on SOAP and the XML protocol (a related standard), see the W3C’s page.
Also useful:
SOAP, WSDL, UDDI: Digesting the Alphabet Soup (Information Week)
For details on WSDL, see the W3C’s note on the topic.
For more on UDDI, visit the homepage for the UDDI community.
Link: Common Language for the Next-Generation Internet
Link broken? Try the Wayback Machine.
