What Interoperability Is

The definition of interoperability is straightforward: Two different SOAP implementations can communicate with each other. In practice this means that one SOAP application, developed using one of the SOAP development tools (implementation A) can send a message to a different application developed using another development tool (implementation B), have this message interpreted correctly, and be able to correctly interpret the response that it receives.

More specifically , this means that the following requirements must be met:

• The general structure of the message must be common, both for the sender and for the receiver of the SOAP message. This is usually not a problem: The development tools will most likely respect the Envelope / Header (s)/ Body structure described in the specification.

• Each communicator is able to understand potential SOAP faults (error/ status information carriers ) emitted by the other communicator.

• The data-type encoding matches that specified in the SOAP specification (section 5 of the SOAP specification).

Not all implementations have full support for all the XML Schema data types (in fact, very few do). ATL Server, for example, supports only the most commonly used basic types. So, another interoperability requirement is this:

• The data types used in the SOAP messages belong to the subsets supported by both communicators .

Most SOAP implementations use the WSDL protocol to describe their service. WSDL describes the endpoint of a service (i.e., the URL where SOAP messages are supposed to be sent), the messages that can be sent to that service (i.e., the SOAP methods exposed), the headers (if any) for each of the messages, and the parameters for those messages exposed.

In the WSDL document, the name that each parameter will take and the type of that parameter is specified. If some parameters are compound types (arrays or data structures are examples), the serialization rules for those types are also part of the WSDL. The WSDL document acts like a contract offered by a SOAP service: The service will understand a request from the client as long as it respects the rules contained in the WSDL document. This doesn t mean that any message respecting the WSDL will be accepted, nor does it mean that there won t be any faults. The destination application may still reject a message based on the semantics of the parameters. For instance, a hypothetical SOAP service performing arithmetical operations will most likely generate a fault if the second parameter of a division operation is 0 (i.e., divide by zero ), although the type (integer or numeric) matches the WSDL contract correctly.

Thus, if the service exposes a WSDL contract and the development tool knows how to use one, a new requirement should appear in the preceding list:

• The development tool for the sender of the SOAP message must understand the WSDL exposed by the receiver.

Because all ATL Server SOAP applications either expose or consume a WSDL document, this item is relevant and required.