Java Web Services

The Good, Bad, and Ugly of Interoperability

The primary considerations for achieving interoperability are:

• Using the same version or compatible versions of the specifications Not all specifications are backward compatible. For example, SOAP 1.2 as proposed in its latest draft form is not totally backward compatible with SOAP 1.1 or SOAP 1.0. For instance, according to the 1.2 draft specification, a node complying with SOAP 1.1 generates a SOAP Fault indicating version mismatch if it receives a SOAP Version 1.2 message. A 1.2 node has the option of processing a 1.1 message or generating a SOAP Fault. The W3C XML Protocol Working Group (XMLP) has used a different namespace for each version to give implementations a way to distinguish different versions of the specification.

• Using the same version of the web service Like any software, web services change over time. New versions are released that may not be compatible with earlier versions. It’s not clear how the standards for web services will support versioning—that is, how a client will find out what versions of a particular service are available.

• Sharing semantics The semantics must be understood and agreed upon in advance by the parties through some mechanism.

Beyond these general considerations, interoperability can depend on interpretations or misunderstandings of specifications, support for optional features within a particular web services standard, the addition of proprietary extensions, or the lack of a standard.

Interoperability ...