Given that Web services are extensible by nature and adaptable to a range of business computing scenarios, it should come as no surprise to learn that there are a number of standards organizations vying to push forward future Web services specifications. It is almost certain that distributing the standards management of a technology would ultimately be the death-knell for other architectures. However, since Web services protocols are largely mutually unaware, aside from the basic SOAP and WSDL infrastructure, and designed to be extended by third parties, it is quite possible for distinct groups with diverse interests in applying Webs services to each progress the state of the art of the overall technology largely independently. This has led to the situation that we have today where a number of bodies each produce new protocol standards for the emergent Web services architecture, with the World Wide Web Consortium (W3C), Organization for the Advancement of Structured Information Systems (OASIS), and Web Services Interoperability Organization (WS-I) each providing a focus for their own particular areas of interest within the Web services arena.
The W3C has a prestigious history as far as Web services are concerned, being the driving force behind the development of the XML specifications and the home of the two most fundamental Web services standards: SOAP and WSDL. As part of an increasingly large industry-wide effort, the various committees within the W3C are engaged not only in future revisions of DOM, XML, XML Schema, XML Encryption and Signature, SOAP, and WSDL, but are also actively involved in forging an overall architecture for Web services and trying to reconcile the various Web services choreography efforts into a single endorsed standard.
However, some in the Web services community have begun to express concerns that W3C is losing ground to other bodies and may become marginalized since it also maintains its traditional role in overseeing World Wide Web standards, and provides relatively long-lived charters for its working groups (the choreography working group, for instance, has a two-year charter). Furthermore, given its strong stance on royalty-free standards and the increasing propensity for vendors to look to produce revenue from intellectual effort expended in producing Web services protocols, it is clear that the W3C is approaching an interesting epoch in its history.
OASIS was originally formed as a forum for those interested in SGML in 1993. In 1998, its name was changed to OASIS along with a change in emphasis to XML (OASIS also runs the XML.org web site) and related technologies. OASIS is currently renowned for being the home of ebXML. However, OASIS has grown with the advent of Web services and is now active in such diverse areas as UDDI, security, and management in addition to its work on transactions with BTP.
Unlike the W3C, OASIS does not strive to develop overarching architectures for Web services or drive particular areas toward standards unilaterally. Instead, OASIS acts as a mediator for third parties to collaborate on standards and as such is very industry driven. Because of this pragmatic piecemeal approach, OASIS has become almost the antithesis of the W3C and is beginning to look like the main body to oversee the individual technologies that will ultimately form the Web services stack.
The Web Services Interoperability Organization, or WS-I, has been created to foster interoperability between different vendors' implementations of the Web services standards being developed through W3C, OASIS, OMG, and so forth. The group is not chartered with the creation of standards per se, but with creating common "profiles" of the output from other standards bodies and supporting vendors in creating versions of their software that adhere to these profiles and thus interoperate.
At present, the WS-I is immersed in the creation of its basic profile for Web services, which includes specific conventions on the use of SOAP 1.1 and WSDL 1.1 to foster interoperability between services. It also provides some conventions on the use of UDDI (version 2.04) so that lookups may be made in a consistent manner across UDDI implementations and organizations. The WS-I basic profile also includes a number of security mechanisms for securing communication channels (e.g., HTTPS) and establishing authenticity (X.509 certificates).
On top of the basic profile, the WS-I working groups will continue up the Web services stack to provide conformance profiles for the other higher-level requirements by layering existing and forthcoming standards. Going forward, WS-I will become the prevalent organization for Web services middleware developers. It will also provide Web services application developers with a standard and well-known means of both assuring interoperability and choosing Web services infrastructure based on standard capabilities.
In addition to the work of standards bodies, it has become almost commonplace for individual vendors or groups of vendors with shared interests (both in the technical and commercial sense) to release their own specifications to the world independent of any formal standards body. While the backers of such specifications generally maintain that they intend to present the specifications to appropriate standards bodies eventually, this approach causes some muddying of waters in the Web services community.
While there is undoubtedly value in many of these proto-specifications, developers and architects should have their wits about them when implementing or buying technology based on them. For example, some vendor-backed specifications like WS-Reliability and WS-ReliableMessaging directly and openly compete with one another. Furthermore, once a specification goes to standardization, it does not necessarily mean that the outcome from that process will resemble the input (as testified to by BEA's and HP's initial submissions to the OASIS BTP effort which bear little resemblance to the final protocol).
However, sound judgment on which specifications are likely to make it to broad acceptance largely unchanged, does mean that a savvy architect or developer can march on the market (albeit with a certain amount of risk). When appraising proto-specifications for bleeding-edge technologies, it makes sense not only to investigate whether the technology itself is sound, but also the relative business cases put forward by its backers and the position (and indeed likely position) of those backers within the Web services community and wider industry.