WSDL Styles

As I mentioned in my last post, the SOAP specification was originally intended for performing RPC in a platform neutral way. In fact, SOAP used to stand for Simple Object Access Protocol. However since SOAP is now commonly used for message oriented interactions, the SOAP 1.2 specification stipulates that SOAP is no longer an acronym at all. But I digress...

The WSDL specification defines two different styles for interacting with a service, document and RPC. The RPC style is designed for invocation of methods on remote objects, with messages containing parameters and return values. The document style is message oriented, with messages containing whole (usually XML) documents, rather than explicit parameters.

Orthogonal to these styles are two different encoding styles, encoded and literal. The encoding styles stipulate how data are encoded on the wire (e.g. integers, strings, arrays, etc).

Before the arrival of the XSD specification, SOAP had to provide its own specification for encoding data on the wire. Once XSD arrived, service implementers now had a choice as to which style they preferred.

SOAP encoding rules are generally better at handling object serialisation than XSD as they are capable of encoding more complex data graphs (i.e. those that contain cyclic references) and handling polymorphism. However, implementations of the SOAP encoding rules don't tend to be universally interoperable, unlike XSD implementations. As a result, WS-I Basic Profile 1.0 says to prefer the use of literal encoding.

Because the SOAP encoding rules are better for serialising objects, the encoded style is generally used with the RPC operation style. As XSD is better for serialising explicit messages, the literal encoding style is generally used with the document operation style.

Most SOAP stacks in fact support only these two combinations. You don't tend to see the document/encoded and rpc/literal combinations in the field that much.

So that leaves us with document/literal and rpc/encoded. Due to the interoperability issues suffered by the encoded encoding style it is best practice only to use the document/literal style.

However for one final twist, in my next post I'll discuss how we can perform RPC with the document/literal style so we can achieve RPC style interactions in an interoperable way. However for reasons I will discuss later, RPC style interactions introduce more coupling between services than message centric interactions and as such should be avoided anyway.