By Alan Radding
The challenge: Supply chain management.
The time: Sometime in the future, maybe next year. Or maybe never.
The story: Big Retailer’s replenishment system fires off an urgent, unexpected message over the Internet to restock. Midsize Supplier’s order-entry service receives the message and triggers the production service, a Web service. The production service triggers a slew of other Web services both internally and externally, via the Internet, from component vendors, logistics providers, shippers, and others. Within moments, the urgent request has been acknowledged and confirmed. Messages fly over the Web, the systems of half a dozen companies leap into action. In short order, the goods arrive thanks to a hodgepodge of different systems running various Web services at half a dozen companies. No human hands involved.
Could this scenario play out today? Yes, but it wouldn’t be easy. It would require the painstaking tuning and integration of multiple disparate systems of every company involved. The time, effort, and cost would hardly be worth it; no sooner had you finished than something would change and you would have to start all over again.
Could this scenario play out on a widespread basis in the future? Maybe, if Web services evolve as expected and deliver what they promise. Web services are software components that talk to each other, system to system, over the Internet, and promise to enable systems that otherwise aren’t very good at cooperating to interoperate enough to perform a desired task.
For consulting companies, Web services promise to dramatically change the way they deliver enterprise application integration, supply change management, on-line commerce solutions, and more for their clients. However, Web services are not a magic bullet — although some of the recent hype surrounding them clearly suggests that. “You have to keep Web services in perspective. The technology is a tool, not salvation. And remember, we are in the early days of this technology. The standards are just emerging,” says James Hall, managing partner, Accenture Technology Business Solutions Group.
Standards, it turns out, are key to Web services, especially when it comes to ensuring interoperability. Every major vendor, including Microsoft, IBM, and Sun, is rushing to seize a dominant position in the Web services market. “We expect multiple technology solutions going into the future. But with standards, we can get a high level of interoperability,” says Hall.
Accenture, for example, has a major initiative underway with Microsoft and its .Net Web services strategy, but it will not commit exclusively to .Net. Similarly, Systems Evolution, Inc., Stafford, TX, has a big .Net effort, but it also runs a parallel Java one, reports Kelly Cook, director of consulting.
Only by supporting the same standards in the same way on every system platform will Web services work. The Web itself proves the concept, at least in its simpler form. Internet users can access any information on the Web regardless of the system they are using, provided it has a standard browser, and regardless of the platforms used by the Web sites. Through open, industry-embraced standards such as HTTP, the transport protocol, and HTML, the display protocol, users can go to any site and get any information.
Web services extends the concept to much more complex information and adds a new wrinkle, the ability to trigger or call actual application functionality. Web services don’t just send and receive static information, but also do something with it and initiate actual application processing.
Of course, organizations already are doing similar things on the Internet today, but because they are not standards-based services, they are difficult to deploy on a wide scale. “You can call applications today over the Internet, but there is no consistency in how you do it, and they are hard to manage,” says Paul Toenjes, director/strategic alliances at Compuware Corp., Farmington Hills, MI.
By adopting a relatively small set of standards — XML, SOAP, WSDL, and UDDI — organizations can create their own Web services and use those of others without having to individually code and integrate every use of the service. “Then you can treat services as black boxes,” Toenjes continues. To use a black box, you only need to know what it does and how to trigger it.
XML (extensible markup language) is core standard. Everything else about Web services is based on that. XML is a language — sometimes described as a language framework. It is a tag language like its cousin, HTML. Where HTML tags prescribe how the system should display the contents of a document, XML tags identify what a particular element of the content, such as a piece of text or a number, is. The XML tag, for example, would identify a number as zip code or phone number or product number. A system can parse a document’s XML to extract the appropriate pieces of information. XML is a self-describing system that includes the key to what a tag means in the particular circumstance through the accompanying DTD (document type definition) file. In short, XML has emerged as the universal system for system-to-system information exchange on the Internet. Industry-specific extensions of the language are popping up almost nonstop.
But XML itself doesn’t do anything. To get work done using XML, you need a messaging protocol. SOAP, simple object access protocol, provides the underlying messaging requirements (the message transport protocol) for e-commerce transactions. SOAP uses XML to issue remote procedure calls or remote method invocations — commands that trigger application processing — over the Web. Where XML describes the content of an electronic document, SOAP offers a way to initiate application processing over the Internet so that businesses can not only exchange information but also do something with it, such as processing a purchase order, without human intervention.
With “XML and SOAP you’ve got enough to do the job,” says Cook. XML handles the data while SOAP handles the logic. Using XML and SOAP, organizations can build, deploy, and use Web services and applications that incorporate Web services. Web services based on XML and SOAP already are being used for enterprise application integration within the corporate intranet, where an application uses SOAP to call the function of another application, which returns the results of its processing as XML content. Presto! Fast, nearly painless, application integration, according to Web services proponents.
More, however, is needed when you begin to face a quantity of Web services and when you try to use Web services outside your own environment. For this you need WSDL (Web services description language) and UDDI (universal description, discovery, and integration).
WSDL is an XML-based language used to define Web services and describe how to access them. It provides information the application needs to know to access and use the Web service.
UDDI is, in effect, a Web service; it is a giant database of Web services, a yellow pages for them. Organizations that offer Web services can list them in a UDDI database where others can find them. Large organizations or groups of organizations may choose to create and maintain their own private UDDI databases.
“UDDI is meant to store either WSDL information or any other description of the service. It probably will be best for private networks. It is really too huge to work efficiently for the public network,” notes Jean-Christophe Cimetiere, CEO, Techmetrix Research, Lexington, MA. Although several public UDDI databases already are up and running, you do not need UDDI to do Web services.
A slew of other related standards is in the works, some for specific industries, others to address such things as transactions or security. But with the basic standards noted above, organizations can move forward with Web services, confident that they will operate regardless of the platform used to create, deploy, or use the service. “XML created in our C# and .Net will work with XML created using Java, Perl, or any other platform,” insists Philip DesAutels, product manager for Microsoft’s XML Web Services. SOAP, too, will operate across all platforms.
Microsoft at this point lays claim to Web services leadership. “We built .Net from Day One for Web services,” DesAutels points out. Other vendors have been forced to extend and adapt their products for XML and SOAP. At this point, industry analysts suggest that Microsoft is about six months ahead of the rest of the industry, but they expect the others to catch up. “.Net may be ahead now, but we’re entering a period when we will have a number of good tools to choose from,” says Cook.
For firms like Viant, a once-high-flying Internet consulting firm that has come back to earth, Web services play a big in the latest offerings — but support for industry standards is just one part of delivering a complete services-based solution. “Standards are important, but we design the solution as part of a services-based architecture,” says Chirac Patel, senior relationship manager. Usually the company ends up building its own layers on top of the Web services standards.
With Web services standards falling into place, the Web services phenomenon takes a major step forward. However, there is much more to address — everything from security to testing to business models — before the vision of applications composed of Web services dynamically conducting business with other applications across the Internet becomes a reality.