Increasing the Interoperability Basis for WS-*

The specs comprising the core functionality of Web Services (SOAP, MTOM, WSDL, WS-Addressing, WS-Policy, WS-Security, and WS-ReliableMessaging) have been in development a long time, and undergoing standardization for almost as long. SOAP 1.1 was submitted to W3C in May of 2000, and specifications have emerged regularly since then, most recently with the WS-Policy submission. Together these families of specifications have been dubbed WS-*.

During this time, Web Services has received a huge amount of attention, and because the inevitable hype quickly outstripped the deliberate pace of development and standardization, at present practical interoperability between Web Services implementations is spotty. Only a subset of Web Services functionality has been widely recognized as interoperable – namely the functionality represented by the WS-I Basic Profile (subsets of SOAP 1.1 and WSDL 1.1). The interoperability achieved by the Basic Profile resulted from a significant investment by the industry in staffing an effort to locate interoperability problems and solve them, to demonstrate and illustrate interoperability by building sample applications and validation tools. But as the SOAP vs. REST debate illustrates, if practical use of Web Services is limited to the core capabilities of the Basic Profile, one is left with little motivation to adopt Web Services over the alternative of simply delivering Plain Old XML over the web.

Today, the set of major implementations comprising Web Services has expanded to include SOAP 1.2, MTOM, WS-Addressing, WS-Security, WS-ReliableMessaging, WS-Policy. This expanded scope is still viewed as experimental by the industry and has not yet attained the confidence of the industry as broadly interoperable.

The lack of interoperability confidence is not wholly the result of missing pieces in the architecture of the Web Services specifications, but rather simply on the fact that there are just now emerging complete, deployment-ready products that encompass the current set of specifications. Microsoft’s Windows Communication Foundation, one of the most important implementations in this space, will begin to be broadly deployed in Vista, just now being released to customers. WSO2 invests heavily in the development of the Apache Axis2 open source implementations (both in C and Java) and has just released the WSO2 Web Service Application Server 1.1, based on Axis2 1.1, which provides similar functionality. This functionality represents a new profile of Web Services (Secure, Reliable, with Policy metadata) which is a major advance in functionality over the existing state of the industry, the WS-I Basic Profile.

Since these products and specifications are so new, and many have had fluid content until recently, there are bound to be a set of interoperability problems using them in practice, because of slightly different sets of supported specifications, different sets of supported versions, and simply bugs and ambiguities to be ironed out over time. Basic interoperability testing under the auspices of W3C Working Groups, OASIS Technical Committees, and pair-wise vendor interop efforts have verified a minimum level of interoperability, but these efforts are insufficient to provide Enterprise customers the assurances they need to rely on these technologies more broadly.

Returning for a moment to the roots of the Web Services activity, SOAP 1.1 attracted attention in part because a basic level of interoperability emerged quickly, in large part through the efforts of the SOAPBuilders forum, which organized interoperability events and provided an open channel of communication for implementation and interpretation questions. As Web Services matured, much of the attention has shifted to architectural topics rather than practical demonstrations. A return to the roots of Web Services, maximizing interoperability through open communication between developers, and between their implementations, would solidify industry confidence in Web Services as a solid basis for interoperability.

One can draw some interesting parallels between the state of Web Services and the W3C experience with XML 1.0 interoperability. After the XML 1.0 Recommendation was published, it took a period of deployment and adoption to surface some of the edge cases and ambiguities of the spec. The XML 1.0 test suite, originally developed at OASIS, proved an important component of assessing the conformance, and thence interoperability, of an implementation. As time went on, differences of opinion about the results of particular tests were surfaced to the W3C XML Core Working Group, which produced errata as necessary, and eventually took over ownership of the complete test suite. The XML Core Working Group continues to adjudicate the fine points of the XML and related specs through its errata process to this day, as evidenced by the publication of the Fourth Edition in Sept 2006.

This work is not glamorous, but is an important factor in the long-term success of these specs. W3C has a well-developed process for considering, gaining consensus, and publishing errata. Although this process cannot be simplistically applied to the entire WS-* stack (with some of it’s components coming through OASIS), it can play a vital role in ensuring that the core specs are maintained, and encouraging specs owned by other organizations to be maintained at a commensurate level.

We believe Web Services will follow the pattern established by XML, with broad adoption demanding additional clarity in the text of the various specifications. In coming months several important technologies in the Web Services Activity are scheduled to reach completion, such as the final installment of WS-Addressing, WSDL 2.0, and WS-Policy 1.5. Others are already in a maintenance mode (SOAP 1.2, MTOM.) Thinking now about how to best support the long-term interoperability benefits of these technologies is core to any comprehensive plan considering the future of the W3C Web Services Activity.

In addition to errata, the existing test suites in the Web Services Activity (WS-Addressing, WSDL 2.0) provide a valuable mechanism to increase technical communication between vendors and encourage long-term interoperability. Rather than limiting these test suites to the CR phase, continuing to develop, enhance, and run these test suites provides a forum for disseminating information (often discovered during vendor’s pair-wise interactions) to all the implementers in the community. The W3C’s leadership position gives it the unique ability to encourage activity-wide testing (for instance a scenario involving SOAP 1.2, WS-Addressing, WSDL 2.0, WS-Policy). This cross-spec testing platform will also provide a strong foundation for testing new work (e.g. new policy assertions) without developing a test infrastructure from scratch.  Periodic interoperability events would demonstrate W3C’s continued investment in practical interoperability.

In conclusion, WSO2 feels that while incubating higher layers of Web Services, the W3C should not neglect the opportunity to become the central focus for maintaining the core Web Services specifications, both individually and when composition issues arise between them, and to lead practical interoperability by maintaining and extending the test frameworks and activities. An obvious organization for this is the establishment of a Web Services Core Working Group, along the lines of the XML Core Working Group, but with a charter mandate to host regular interoperability events.