Posted by Paul Cotton
Partner Group Manager
Roughly 10 years ago, a handful of hardware and software vendors met to discuss the concept of Web services interoperability. Outside of e-mail, the internet had yet to be adopted into mainstream use, but the industry recognized its potential as a vehicle for relaying data between different software programs or operating platforms – such as a Windows PC and an IBM mainframe.
This need for the free flow of information across different platforms and programs motivated Microsoft, IBM, Oracle, SAP, HP and a handful of other vendors to form the Web Services Interoperability Organization (WS-I). Their goal was to codify the requirements to achieve interoperability, by creating a series of blue prints – or profiles – that developers and engineers could follow whenever they write a software program.
WS-I covered a lot of ground and today we’ve collectively achieved interoperability for standardized specifications that provide the communication framework for the Internet. Success would not have been possible without the cooperation and shared vision of the vendors, customers and standards officers who joined the ranks of WS-I and took part in ongoing discussions.
WS-I members began jointly creating interoperability profiles at the same time the W3C and OASIS were standardizing the same initial Internet specifications, the Simple Object Access Protocol (SOAP). We learned a few lessons along the way. Chief among them was this: Without very clear guidance, any two programmers will usually take a different approach to addressing the same problem.
Prior to WS-I, vendors were more accustomed to writing code that typically would not interact with other vendors’ products. It’s one thing to write an informal, 50-60 page specification that will only be used within your company. But an entirely different set of requirements come into play when you’re writing specs for use by multiple parties. This called for a much more prescriptive approach to how programmers write code. Together, we identified the requirements and spelled out specifics for code that would ensure interoperability. Additional details on WS-I findings are available on the Interoperability@Microsoft blog.
We also learned about the effectiveness of building interoperability testing into the writing of specifications.
Agreeing on how to test for interoperability was a particular challenge because each vendor had a slightly different customer base and correlating usage scenario to serve as their point of reference. But these customers wanted the vendors to sit down, work stuff out and demonstrate to them that we had achieved interoperability. And because W3C and OASIS were working simultaneously, we were able to create a real-time feedback channel that looped back into their standardization process.
Today we have interoperability profiles based on standardized versions of the specifications, customers have specs that they can point to, the industry has broad agreement on the approach to take to achieve interoperability, and vendors have work they can point to that demonstrates interoperability. We’ve also mastered the process of writing specifications to the point that technology implementers can create an interoperable software program on their first attempt.
But the payoff extends beyond WS-I’s initial focus. Interoperability testing is now built into the standardization process of W3C and OASIS, and WS-I has helped establish industry best practices for achieving interoperability and standardizing technologies.
With WS-I’s goals completed and its knowledge adopted by the industry, stewardship over WS-I’s assets, operations and mission will transition to OASIS (Organization for the Advancement of Structured Information Standards), a group of technology vendors and customers that drive development and adoption of open standards.
But the focus on interoperability will remain, likely shifting to its role in cloud computing. Microsoft looks forward to continued learning, cooperation and conversations with the industry and its customers.