Interoperability has different meanings in different contexts; in the Information Technology (IT) space, the term is generally understood to mean the ability of different IT networks, applications, or components to exchange and use information, i.e., to "talk" to each other.
In today’s heterogeneous IT marketplace, "interoperability" can be defined as the ability of diverse IT applications or systems to exchange and use information. This is increasingly required of industry and governments alike. IT users of all types continue to demand interoperability, in order to reduce costs and complexity, and they are increasingly deploying the best products from multiple vendors to meet their IT needs. Thus, whether it is sharing data between applications written in different programming languages, or trying to log on across multiple systems, the challenge is to enable technologies to work together without compromising their distinctive underlying capabilities.
The Promise of Web Services Over the years, our industry has tried many approaches to come to grips with the heterogeneity of software. But the solution that has proven consistently effective – and the one that yields the greatest success for developers today – is a strong commitment to interoperability. That means letting different kinds of applications and systems do what they do best, while agreeing on a common "contract" for how disparate systems can communicate to exchange data with one another.
The ability to easily serve and consume XML Web services using any SOAP or WSDL implementation, on any platform, using any language, is fundamental to creating a new distributed computing environment for application integration on the Internet. These same capabilities enable solving the application-to-application integration scenarios present in today's heterogeneous corporate environments. We also see a tremendous opportunity for developers and IT professionals to help usher in a new generation of software that is interoperable by design. The foundation we are building with XML is already yielding significant reductions in the time, skill and cost required to integrate systems.
If interoperability is the main promise of Web services, why is it that so many developers and organizations have a difficult time achieving it in practice? With all due respect to our hard-working standards bodies, the primary culprits are the imperfect specifications guiding today's implementations. Ambiguities and too many choices often lead to differing interpretations, resulting in incompatible implementations.
Hence, responsibility lies with the developer for early identification of problem areas that are likely to produce interoperability issues. Once identified, developers should avoid them religiously in their designs. Most developers know that achieving their scalability, reliability, or performance goals depends largely on their work during the design phase. The same holds true for achieving interoperability goals.
Interoperability Requires Teamwork Identifying problem areas is a team effort that takes time. It requires the input of numerous developers representing the different vendors involved. Because this type of work requires a significant amount of time, coordination, and political cooperation, a special organization, called the Web Services Interoperability Organization (WS-I), was formed in February 2002. The WS-I complements other standards bodies such as the W3C and the IETF. Instead of producing new specifications, the WS-I provides guidance for existing specifications around these areas:
- Web Services Profiles: In many ways, the WS-I is tasked with constraining agreement around different groups of Web services specifications. The WS-I completed their first profile, called Basic Profile (BP) version 1.0, in April 2004. The BP states that conforming Web services use SOAP, Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI), and it provides valuable guidance on using them properly.
- Messaging: The guidance on SOAP messaging clarifies some of the ambiguities that exist in the SOAP and HTTP-related specifications. For example, the guidance states that receivers must be able to process SOAP messages that contain the Unicode byte order mark (BOM), and that all messages must use either the UTF-8 or UTF-16 character encoding.
- Security: The BP also provides guidelines for using HTTPS to secure Web services today. It basically states that Web services may require HTTPS at a particular endpoint. With HTTPS, Web service endpoints can guarantee server authentication, integrity, and privacy for all message exchanges. The profile also states that Web services can require client (mutual) authentication. And since HTTPS happens to be a mature and widely available standard, using it to provide basic Web services security features can be a big win for promoting interoperability.
- Conformance: Now that the BP is finished, vendors are likely to provide more assistance in the area of conformance. All developers should follow the implementation guidance provided by their vendor surrounding their tools (such as the Microsoft Patterns & Practices document mentioned earlier). ASP.NET 2.0 is going to make BP conformance even easier with its internal understanding of the BP rules. The ASP.NET 2.0 framework provides a ConformanceClaims property on the WebServiceBindingAttribute that influences an endpoint to behave in a way that's conformant with the BP.
- Conformance Testing Tools: The WS-I Testing Tools provide a great resource to developers designing and implementing Web services. You can download the testing tools from the WS-I site and choose either a C# or Java-language version. Using these tools during design and development can assist in conformance.
- Sample Applications: Numerous vendors (including Microsoft, IBM, BEA, Sun Microsystems, Novell, Oracle, SAP, and others) have provided implementations of this well-defined sample application. They are available for download from the WS-I site. The Microsoft implementation was built using ASP.NET 2.0. Most of the ASMX code was generated from the predefined WSDL definitions provided with the architecture document. The sample illustrates the importance of proper WSDL design and the benefits of using a WSDL-first development approach.
So Where Are We?
Interoperability is not a given when using Web services. It requires research, thought, and a good understanding of the issues surrounding the various Web services specifications. Luckily, the WS-I does the heavy lifting and provides summarized guidance in the form of profiles, samples, and testing tools. Taking advantage of these resources, among others, during design and implementation will greatly improve your interoperability success, which ultimately saves you time and money during integration.
 Chris Sharp assumed leadership of Microsoft’s Asia Pacific Server & Tools business group as of 1 October 2005. As General Manager for the Server & Tools business, he is directly responsible for sales, services, operational and business development in the region which includes Southeast Asia, Korea, India, Australia and New Zealand.
|
