Developing Interoperable Web Services - Integrating Java and Microsoft .NET
Interoperability is one of the main promises of Web services. Web services are designed to be independent of the underlying operating system and programming language. In this article we will introduce basic web services interoperability issues. We will focus on the two most popular platforms - Java and Microsoft .NET.

Introduction

Web services interoperability can be divided into two base categories: SOAP interoperability and WSDL interoperability.
In our previous articles we learned that SOAP is a very high-level protocol that mandates the structure of XML documents exchanged over some transport protocol. That's quite a vague definition. The vagueness of this definition makes SOAP extremely extensible and versatile, but it also makes interoperability a bit challenging. At a basic level, we start our quest to achieve interoperability at the transport protocol level. Both parties involved in a message exchange must agree to use the same transport protocol, such as HTTP, SMTP, or JMS. But transport protocol compatibility doesn't necessarily ensure interoperability. There are other issues that affect interoperability. One example is data type encoding. An encoding style defines how programmatic data types are encoded in XML. The SOAP specification does not mandate any particular encoding style, and developers are free to use any encoding style they want. In theory there are virtually unlimited choices of encoding styles that are mutually incompatible. Fortunately there is a standard convention. Section 5 of the SOAP specification defines an encoding style, and it has became the de facto standard for SOAP encoding. This encoding provides the basis for the automated SOAP interoperability tests that are periodically carried out by the major SOAP solutions vendors. You can see these test results online at http://soap.systinet.net/interop/soap/index.html
More and more we're finding that WSDL lies at the heart of Web services interoperability. WSDL is the description language for Web services. Usually a WSDL document is automatically generated by Web services framework tools (e.g., WASP WSDLCompiler) from the code written in a particular programming language. Developers can use the WSDL document to generate client-side stubs or proxies, which provide convenient access to Web services. Thus the key to enabling seamless Web services interoperability is the ability of one Web services framework to consume the WSDL documents generated by other frameworks. The WSDL interoperability effort is just taking off. You can see further details at http://soap.systinet.net/interop/wsdl/index.html.
Although there are still some interoperability issues to be resolved, the vendors are progressing very quickly, and we can expect delivery on the promise of Web services interoperability very soon.

How to not get trapped

The following subchapters give you some basic tips on how to write interoperable Web services using today's Web services frameworks. These tips may significantly ease your life as well as the lives of other developers who will use your Web services. Hopefully some of those tips will be outdated soon.

Keep your types simple - avoid advanced XML Schema constructs

The XML Schema standard is very complex and difficult to implement. Moreover, XML Schema processing is quite time consuming, so many frameworks sacrifice full XML Schema support for performance. Some advanced XML Schema constructs (e.g., choice) are quite hard to express in a programming language, and few Web services frameworks support them. So the key success factor in Web services interoperability is to use basic datatypes, such as primitive datatypes, arrays, and structures. As a best practice, decompose the complex types in your interfaces into simple and clean interfaces with basic dat