The encodingStyle attribute appears in both header blocks and the body element of a SOAP message. As its name suggests, the attribute conveys information about how the contents of a particular element are encoded. At first this might seem a little odd since the SOAP message is expressed in XML. However, the SOAP specification is distinctly hands-off in specifying how header and body elements (aside from the SOAP Fault element) are composed, and defines only the overall structure of the message. Furthermore, XML is expressive and does not constrain the form of document a great deal and, therefore, we could imagine a number of different and mutually uninteroperable ways of encoding the same data, for example:
<account> <balance> 123.45 </balance> </account> and <account balance="123.45"/>
might both be informally interpreted in the same way by a human reader but would not be considered equivalent by XML processing software. Ironically, this is one of the downfalls of XML it is so expressive that, given the chance, we would all express ourselves in completely different ways. To solve this problem, the encodingStyle attribute allows the form of the content to be constrained according to some schema shared between the sender and recipient.
One potential drawback is that senders and receivers of messages may not share schemas indeed the senders and receivers may be applications that do not deal with XML at all and thus the best intentions of a SOAP-based architecture may be laid to waste. To avoid such problems, the SOAP specification has its own schema and rules for converting application-level data into a form suitable for embedding into SOAP messages. This is known as SOAP Encoding, and is associated with the namespace env:encodingStyle="http://www.w3.org/2002/06/soap-encoding".
The rules for encoding application data as SOAP messages are captured in the SOAP specification as the SOAP Data Model. This is a straightforward and concise part of the specification that describes how to reduce data structures to a directed, labeled graph. While it is outside of the scope of this book to detail the SOAP Data Model, the general technique is shown in Figure 3-15. This SOAP encoding example, highlights the fact that there are two aspects to the encoding. The first of these is to transform a data structure from an application into a form suitable for expressing in XML via the rules specified in the SOAP Data Model. The other aspect is to ensure that all the data in the subsequent XML document is properly constrained by the SOAP schema. It is worth noting that SOAP provides low entry point through SOAP encoding since a SOAP toolkit will support the serialization and deserialization of arbitrary graphs of objects via this model, with minimal effort required of the developer. In fact, coupled with the fact that SOAP has a packaging mechanism for managing message content, and a means (though SOAP encoding) of easily creating message content we are close to having an XML-based Remote Procedure Call mechanism.
Figure 3-15. SOAP encoding application-level objects.