Ultimately all Web services interoperability issues center on the WSDL file. WSDL is the interface definition language (IDL) of Web services and the contract between the client and the server. The services semantics, namely the message types, data types, and interaction styles in the WSDL file, are the key to building loosely-coupled systems. Even though WSDL does not mandate the use of a particular type system, the XML Schema data types (XSD) is widely embraced by the Web services community.

XSD offers a wide range of built-in primitive types and further allows service providers to define custom complex types. The XSD-type system is more sophisticated and powerful than the type system of any programming language, and more importantly it is language-neutral. That makes WSDL the logical starting point to define the Web services semantics.

Ideally, just like the IDLs for COM and CORBA, you should create and edit the WSDL first -- define the interfaces, messages, and data types before you build the Web services and clients in specific implementation languages based on the service semantics in the WSDL.

However, in practice, even seasoned programmers like to do the opposite: they start with their implementation-language-specific interfaces, such as Java interfaces, and rely on vendors' tools to derive the service semantics in WSDL from their implementation code; they then leave it to the Web services client to figure out from the WSDL how to make the calls to the Web service. In the end, they often don't even need to know about the WSDL before they can build and run a sophisticated Web service. They might only have run their client and server in a homogeneous environment; that is, either on a J2EE platform or on a .NET platform, but not on both.

Vendors' IDE tools today are pushing toward the direction that everything can be auto-generated and no code writing is required (or, at least it is claimed and hoped by many), including the WSDL. This trend is attractive because it is productive, and it is less error-prone (only if the tool is righteous and robust) than human coding. Interoperability is usually not an issue on a single platform where both the Web services and clients use the same toolkits.

The danger becomes evident when there is a demand for interoperability across heterogeneous environments. Now you are creating the key artifacts for Web services interaction from implementation languages and then using the platform-dependent tools to map them to the language-neutral ones in WSDL. When the tool on the client platform generates the service proxy from this tool-generated WSDL, another level of mapping occurs. This process deviates from the hard fact that WSDL is the IDL for Web services. The language-neutral WSDL should be the common ground for both client and server and using the tools in this way doubles the likelihood that information is lost during the mappings.

This doesn't mean that you should abandon the tools, and that all the vendors should stop producing and marketing those tools. Automation has become an important aspect of today's enterprise application development landscape. The tools are powerful; it's a matter of how you leverage their power. You can use these tools to generate a skeleton WSDL to serve as a starting point or as a template. Schemas, message parts, and data bindings must be carefully designed in accordance with the WS-I recommendations. Just as you probably would not let a database schema be generated by a tool for the sake of the database efficiency, you should not ignore the design of efficient Web services messages and data types by hand. Sometimes, even the name of an element must be carefully chosen to conform to the naming conventions among potential interoperating platforms. WSDL is the single most important artifact for Web services interoperability. Programmers must learn to program against raw XML messages, and at least learn to read XSD, WSDL, and SOAP messages.