By their very nature, Web services require strong standards for interoperability, security and reliability. Yet so far the standards are immature, and they aren't yet adequate for the most sophisticated business processes.
Standards developers and IT vendors generally see the standards glass as half full, pointing out that many companies have already set up useful and workable Web services applications. But many users see it as half empty, saying more remains to be done before they would consider using mission-critical Web services applications. Some even question whether the functions contemplated by some of the standards can be automated at all.
Users also say they're confused and worried about what they see as overlap and competition among IT vendors and standards bodies.
Web services are a language-neutral, platform-independent way to loosely couple applications across an intranet, extranet or the Internet. They exchange documents, transactions and remote procedure calls using Web-based protocols.
Kelly Adams, director of client technology at Deutsche Bank AG in New York, says Web services may at last deliver on the promise of distributed, heterogeneous computing. "CORBA [Common Object Request Broker Architecture] was supposed to be the be-all and end-all, but it didn't quite turn out that way," he says. "But it looks like the sort of self-describing, easy interpretation nature of XML has opened up a lot of possibilities."
The most fundamental Web services standards are the following:
-- XML: The Extensible Markup Language is a simple, flexible text format derived by the World Wide Web Consortium (W3C) from the Standard Generalized Markup Language, a system for organizing and tagging elements of a document. The open XML standard is emerging as the method of choice for exchanging information among computer systems. The W3C has also developed specifications for XML schemas, which define how markup tags should be interpreted, and for XML namespaces, a way of naming XML document elements and attributes so they can be recognized by various kinds of software.
-- SOAP: The XML-based Simple Object Access Protocol began life at Microsoft Corp. but is now maintained and developed by the W3C. Often called a "message envelope," it consists of three parts: an envelope that describes what is in a message and how to process it, rules for encoding data, and a convention for representing remote procedure calls and responses.
-- WSDL: Originally proposed by IBM and Microsoft, the Web Services Description Language describes Internet services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. It allows a Web service to describe its capabilities by defining Web services interfaces and describing how to access them. The W3C owns the latest version of WSDL.
-- UDDI: The Universal Description, Discovery and Integration specification was developed by IBM and Microsoft. A kind of digital Yellow Pages, it enables a company to describe its business and services and discover other businesses that offer desired services. UDDI is now maintained by the Organization for the Advancement of Structured Information Standards (OASIS), a Billerica, Mass.-based standards group with both vendor and user members.
These foundation specifications are relatively mature, says Tom Campisi, an architecture analyst at Japan-based Toyota Motor Corp. and communications chairman at Standards for Technology in Automobile Retail, an industry IT standards body in McLean, Va. "XML and SOAP have been around for a while, and they are stable enough for widespread use," he says.
The standards are adequate for exchanging purchase orders between two companies, Campisi says. But, he adds, more work needs to be done to develop Web services standards for automatically accommodating business rules that accompany the exchange of purchase orders, such as the length of time a purchase order is to be valid, how to respond to open purchase orders over time and how to coordinate purchase order and invoice processing.
Are They Practical?
And some question the practicality of the goals underlying the development of some standards, especially UDDI, which is intended to facilitate automation of the interactions that accompany processes such as purchasing. The skeptics say purchase transactions, except possibly the smallest and most routine, will always require human actions such as contract negotiations.
"It would be nice if your application could go out and read UDDI and make judgment calls based on it," says Robert Wegener, national solutions director at RCG Information Technology Inc. in Edison, N.J. "But I don't think you'll see that for a long, long time." Most UDDI registries today contain little more than companies' toll-free telephone numbers, he says.
A number of efforts are under way to address two broad areas in which Web services standards are weak or incomplete: security and the accommodation and coordination of business process rules for multiple interacting Web services. These specifications are to be layered on top of the core standards developed by the Reston, Va.-based Internet Engineering Task Force (IETF) and the W3C. For example, IBM, Microsoft and VeriSign Inc. in April proposed a set of security standards under an umbrella called WS-Security, which is now at OASIS.
The base WS-Security, which is built on top of SOAP, describes how to attach signature and encryption headers, security tokens, and encryption certificates to SOAP messages. On top of that sits WS-Policy, which defines how to express the capabilities and constraints of security policies; WS-Trust, which describes how to establish trust relationships; and WS-Privacy, which defines how Web services state and implement privacy policies. Follow-on WS-Security specifications will include WS-Secure Conversion, which will describe how to manage and authenticate message exchanges; WS-Federation, which will describe how to manage and broker trust relationships in heterogeneous environments; and WS-Authorization, which will describe how Web services manage authorization data and policies.
In August, IBM, Microsoft and BEA Systems Inc. published specifications for creating and coordinating multiple business processes based on Web services. The companies announced WS-Coordination and WS-Transaction, which both specify a way of handling multiple Web services interactions, regardless of the underlying computing infrastructure, and Business Process Execution Language for Web Services (BPEL4WS), a new language to describe business processes. BPEL4WS describes the flow of tasks, the order in which they need to be performed, the type of data shared and how other partners are involved. The companies haven't yet said which standards body they will submit these specifications to, says Bob Sutor, director of Web services strategy at IBM.
Sutor says XML, SOAP, WSDL and UDDI constitute the first of three Web services standards phases, the connection phase. The second phase will be the security phase, and the third will the the enterprise -- business process or workflow -- phase. "By the time we are done, there will be 20 to 30 standards that we say are part of Web services," he says. Asked if that isn't a lot for developers and users to get their arms around, Sutor counters that all those standards are needed to provide the functions users demand. "We are roughly at Year 2.5 of a five-year process," he adds.
Building Web services specifications on top of each other in a building-block fashion gives application developers and users a lot of flexibility, developers say. "The idea is they should be relatively loosely coupled, so if you have two applications doing simple information exchange, you don't have to use much of the stack," says Uttam Narsu, an XML and Web services analyst at Giga Information Group Inc. in Cambridge, Mass. For example, he says, an internal, intranet Web service not involving confidential data might need little or no security.
Regardless of the state of evolution of Web services standards, users must not neglect their own "standards" such as security policies, says Deutsche Bank's Adams. He says he's looking at products such as Mountain View, Calif.-based Westbridge Technology Inc.'s XML Message Server, whose "policy engine" can filter messages for compliance with security policies by Web service, service requester or a combination of the two. Adams says Web services security is now in the hands of individual application developers at the bank but ultimately should go to a centralized infrastructure group. "One of our biggest problems internally is getting everyone on board using the same standards," he says.
A group likely to attract increasing interest from users is the Web Services Interoperability Organization (WS-I), which has taken it upon itself to standardize the standards.
"Our goal is to take specifications developed by the standards organizations and put them together with some implementation guidelines and best practices," says Bob Cheng, co-chairman of WS-I's marketing and communications committee and a marketing manager at Oracle Corp. "We want to make it easier for end-user companies to move forward with Web services."
"The WS-I has become the most important Web services standards body for users," Narsu says. "They are like someone with a very powerful searchlight illuminating the dark areas of the standards arena. It creates a baseline for users to just get started without worrying about the fact that all this stuff is going on with security and transactions and business process."
You should consider alternatives to Web services standards that are incomplete or changing, says RCG's Wegener. For example, you could encrypt a SOAP message using Secure Sockets Layer technology instead of the more efficient and flexible -- but less mature -- encryption specified by the W3C.
And standards enthusiasts say users should actively participate in standards groups. "Users need to be a little more involved in the infrastructure and interoperability standards," Narsu says, "because ultimately it's their payload that's being carried."