SOAP Encoding - The SOAP Section 5 Encoding Rules

There is no official name for SOAP encoding, but it is often referred to as SOAP Section 5 encoding, because the rules are presented in Section 5 of the SOAP specification.

Encoding rules define how a particular entity or data structure is represented in XML. Connecting different applications typically introduces the problem of interoperability: the data representation of one application is different from that of the other application.

In order for the client and server to interoperate, it is essential that they agree on how the contents of a SOAP message are encoded. SOAP 1.2 defines a particular form of encoding called SOAP encoding. This defines how data structures in the application’s local memory, including basic types such as integers and strings as well as complex types such as arrays and structures, can be serialized into XML. The serialized representation allows transfer of data represented in application-specific data types from one application to another.

The encoding rules employed in a particular SOAP message are specified by the encodingStyle attribute, as discussed above. There is no notion of default encoding in a SOAP message. Encoding style must be explicitly specified if the receiving application is expected to validate the message.

SOAP does not enforce any special form of coding—other encodings may be used as well. In other words, applications are free to ignore SOAP encoding and choose a different one instead. For instance, two applications can simply agree upon an XML Schema representation of a data structure as the serialization format for that data structure. This is commonly referred to as literal encoding.

A typical programming language data model consists of simple types and compound types. Compound types are based on simple types or other compound types. Dealing with simple data types would be easy, since all these types have direct representation in XML Schema. However, the story with complex types, such as arrays and arbitrary software objects, is more complicated. XML Schema defines complex types, but these are very general, and some degree of specialization, e.g., for arrays, could make job easier for the Web services developer.

SOAP does not define an independent data type system. Rather, it relies on the XML Schema type system. It adopts all XML Schema built-in primitive types and adds few extensions for compound types. The SOAP version 1.2 types extending the XML Schema types are defined in a separate namespace, namely https://www.w3.org/2003/05/soap-encoding.

XML elements representing encoded values may hold the XML Schema type attribute for asserting the type of a value. For example, the sender of the SOAP encoded message in Listing 2-1 in the last chapter in Line 14 explicitly asserts the type of the note element content to be a string:

14 		<a:note xsi:type="xsd:string">
15 			Reminder: meeting at 11AM in Rm.601
16 		</a:note> 

The XML elements representing encoded values may also be untyped, i.e., not contain the type attribute:

<a:note> Reminder: meeting at 11AM in Rm.601 </a:note>

In this case, a receiver deserializing a value must be able to determine its type just by means of the element name <a:note>. If a sender and a receiver share the same data model, and both know that a note labeled value in an application-specific data graph is a string type, they are able to map the note element content to the appropriate data type without explicitly asserting the type through the XML Schema type attribute. However, in this case we cannot rely on XML Schema to explicitly validate the content of the message.

SOAP Compound Data Types

SOAP Section 5 encoding assumes that any application-specific data is represented as a directed graph. A compound data type can be either a struct or an array. A struct is an element that contains different child elements. An array is a compound type that contains elements of the same name. Here’s an example:

<soap-env:Body>
	<ns0:item>
		<ns0:name xsi:type="xsd:string"> old watch </ns0:name>
		<ns0:startPrice xsi:type="xsd:float"> 34.99 </ns0:startPrice>
		<ns0:reserved xsi:type="xsd:boolean"> false </ns0:reserved>
		<ns0:seller>
			<ns0:name xsi:type="xsd:string"> John Doe </ns0:name>
			<ns0:address xsi:type="xsd:string">
 				13 Takeoff Lane, Talkeetna, AK 99676
 			</ns0:address>
			<ns0:bids xsi:type="soap-enc:array" soap-enc:arraySize="*">
				<ns0:entry>
					<ns0:amount xsi:type="xsd:float"> 35.01 </ns0:amount>
					<ns0:bidder> . . . </ns0:bidder>
				</ns0:entry>
				<ns0:entry>
					<ns0:amount xsi:type="xsd:float"> 34.50 </ns0:amount>
					<ns0:bidder> . . . </ns0:bidder>
				</ns0:entry>
 . . .
 
			</ns0:bids>
		</ns0:seller>
	</ns0:item>
</soap-env:Body>