WS-I Completes Web Services Interoperability Standards Work

  • Article

imageThe final three Web services profiles developed by the Web Services Interoperability Organization (WS-I) have been approved by WS-I’s membership. Approval of the final materials for Basic Profile (BP) 1.2 and 2.0, and Reliable Secure Profile (RSP) 1.0 marks the completion of the organization’s work. Since 2002, WS-I has developed profiles, sample applications, and testinimageg tools to facilitate Web services interoperability. These building blocks have in turn served as the basis for interoperability in the cloud. As announced today by the WS-I, stewardship over WS-I’s assets, operations and mission will transition to OASIS (Organization for the Advancement of Structured Information Standards).

It took a lot of work to get real products to fully interoperate using the standards. WS-I members have delivered an impressive body of work supporting deliverables in addition to the profiles (test tools, assertions, etc.). One might ask “why did it take so long, and what exactly did all this hard work entail?”

When WS-I started up, interoperability of the whole stack of XML standards was fragile, especially of the SOAP and WSDL specifications at the top of the stack. It was possible for a specification to become a recognized standard with relatively little hard data about whether implementations of the specs interoperated. Specs were written in language that could get agreement by committees rather than in terms of rigorous assertions about formats and protocols as they are used in conjunction with one another in realistic scenarios. In other words, the testing that was done before a spec became a standard was largely focused on determining whether the spec could be implemented in an interoperable way, and not on whether actual implementations interoperated.

At WS-I the web services community learned how to do this better. One of the first tasks was to develop profiles of the core specifications that turned specification language containing “MAY” and “SHOULD” descriptions of what is possible or desirable to “MUST” statements of what is necessary for interoperability, and removing altogether the features that weren’t widely implemented. We learned that it is important to do N-way tests of all features in a profile across multiple implementations, and not just piecewise testing of shared features. Likewise, since the SOAP based specs were designed to compose with one another, it is important to test specs in conjunction and not just in isolation.  During this period of learning and evolving, it was really necessary to go through the profiling process before the market would accept standards as “really done.”

The underlying reality, especially in the security arena, is quite complex, a fact which also slowed progress. Different products support different underlying security technologies, and adopted the WS-* security-related standards at different rates. Also, there are many different ways to setup secure connections between systems, and it took considerable effort to learn how to configure the various products to interoperate. For example, even when different vendors support the same set of technologies, they often use different defaults, making it necessary to tweak settings in one or both products before they interoperate using the supported standards. The continuous evolution of security technology driven by the ‘arms race’ between security developers and attackers made things even more interesting.

This work was particularly tedious and unglamorous over the last few years, when the WS-* technologies are no longer hot buzzwords. But now, partly due to the growing popularity of test driven development in the software industry as a whole, but partly due to the hard-won lessons from WS-I, the best practices noted above are commonplace. Later versions of specifications, especially SOAP 1.2, explicitly incorporated the lessons learned in the Basic Profile work at WS-I. Other Standards Development Organization (SDO) such as OASIS and W3C have applied the techniques pioneered at WS-I, and newer standards are more rigorously specified and don’t need to be profiled before they can legitimately be called “done.” Newer versions of the WS-* standard as well as CSS, ECMAScript, and the W3C Web Platform (“HTML5”) APIs are much more tightly specified, better tested, and interoperable “out of the box” than their predecessors were 10 years ago.

We at Microsoft and the other companies who did the work at WS-I learned a lot more about how to get our mutual customers applications to interoperate across our platforms than could be contained in the WS-I documents that were just released. And to support this effort we are compiling additional guidance under a dedicated website: http://msdn.microsoft.com/webservicesinterop

image

This has a set whitepapers that go into much more depth about how to get interoperability between our platform / products and those from other vendors and open source projects.  Available whitepapers include: 

Finally, it might be tempting to believe that the lessons of the WS-I experience apply only to the Web Services standards stack, and not the REST and Cloud technologies that have gained so much mindshare in the last few years. Please think again: First, the WS-* standards have not in any sense gone away, they’ve been built deep into the infrastructure of many enterprise middleware products from both commercial vendors and open source projects. Likewise, the challenges of WS-I had much more to do with the intrinsic complexity of the problems it addressed than with the WS-* technologies that addressed them. William Vambenepe made this point succinctly in his blog recently:

But let’s realize that while a lot of the complexity in WS-* was unnecessary, some of it actually was a reflection of the complexity of the task at hand. And that complexity doesn’t go away because you get rid of a SOAP envelope …. The good news is that we’ve made a lot of the mistakes already and we’ve learned some lessons … The bad news is that there are plenty of new mistakes waiting to be made.

We made some mistakes and learned a LOT of lessons at WS-I, and we can all avoid some new mistakes by a careful consideration of WS-I’s accomplishments.

-- Michael Champion, Senior Program Manager