12.1. Introduction

A primary purpose of web services is to interoperate with other services, regardless of the platform on which they are running or the language in which they are implemented. While the WS-* specifications go a long way toward describing platform-independent mechanisms for message exchange, the devil is in the details. As with any specification, there are many areas of the WS-* specifications that are open to interpretation, and there are a numbers of questions to which vendor platforms must determine the answers themselves. The specifications for XML, SOAP, and WSDL were written independently of one another, and therefore have minor gaps and overlaps between them. Moreover, developers are free to implement services in a variety of ways given the choices that the specifications make available, and that makes interoperability more challenging. Between different transport layers, policy and security implementations, message encoding mechanisms, platform-specific character encodings, and differences in implementation details, interoperability can become a daunting task.

Let’s look at this concretely. A WSDL describes a web service in general terms. It allows for customizations, exposing implementation details (such as Java customizations), and a number of combinations of transport and encoding mechanisms. It is perfectly acceptable to implement your service as RPC/encoded, which defines the format of messages over the wire. As a developer starting from Java, you’re not going to see any difference between an encoded or a literally formatted message. However, some platforms have difficulty working with SOAP encoding, and some elements of SOAP encoding are handled differently from one platform to another. That makes RPC encoding a poor choice if you want to make sure as many people as possible can use your service.