3. SOAP Messages
SOAP message syntax is described in detail at
A valid SOAP Message is a well-formed XML document. (For more detail on XML and well-formedness visit http://www.w3.org/XML/ ). The XML prolog can be present but, if present, should contain only an XML Declaration (ie. it should not contain any DTD references or XML processing instructions). It should use the SOAP Envelope and SOAP Encoding namespaces and have the following form:
A SOAP-encoded RPC dialogue contains both a request message and a response message. Let's consider a simple service method that doubles a given integer.
Note that most SOAP packages that you use will take care of the SOAP message syntax details for you, but for the sake of understanding and being able to read and debug SOAP dialogues, let's take a look at these messages piece by piece.
The XML prolog contains only an XML declaration <?xml version="1.0" encoding="UTF-8" ?> specifying the XML version and the character encoding of the XML message.
The SOAP Envelope tag <SOAP-ENV:Envelope ... >in the request message first specifies that this SOAP message's encoding style follows the schema defined at http://schemas.xmlsoap.org/soap/encoding/. Note that this is optional and will be presumed if not included as is the case in the response message. The SOAP Envelope tag also contains many namespace definitions. The namespace identifiers are standard and the SOAP specification requires that these namespaces either be defined correctly or not at all (ie. a SOAP message with missing namespace definitions is correct and processable but one with incorrect, ie. non-standard, definitions is incorrect and discardable). Notice that the SOAP-ENC namespace definition is missing from the response message but this does not mean the message is invalid. For more detail on XML namespaces visit http://www.w3.org/TR/REC-xml-names/.
There is no SOAP Header tag in the example. SOAP Headers are optional and are typically used to transmit authentication or session management data. It is important to remember that authentication and session management are out of the scope of the SOAP protocol although the designers of SOAP did allow for some flexibility in SOAP messaging so that implementors could include such information.
Then comes the SOAP Body tag <SOAP-ENV:Body> which is not remarkable in itself but encapsulates a single method tag porting the name of the method itself <ns1:doubleAnInteger ... > (or the same name suffixed with the word "Response" in the case of the response message). Note that the method tag is typically namespaced by the service name, in this case urn:MySoapServices to ensure uniqueness (A web service, which can contain any number of differently named methods, has a service name unique to the URL at which it is accessible - more detail on service URLs as well as service and method names can be found in the section on Server-Side SOAP ).
The method tag in turn encapsulates any number of parameter tags such as the <param1 ... > tag in the request envelope. Parameter tag names can be anything at all and are typically autogenerated and have no namespace. In the response message there is only ever one parameter tag (representing the return value of the method) and it is typically named <return>.
More complex examples...
One of the most powerful features of the SOAP protocol is its ability to handle parameters of any level of complexity. This basically boils down to the ability to handle primitive types (int, string, etc.), arrays and structs and any combination thereof. Let's take a look at what the SOAP dialogues look like for methods with parameters and return types that are complex.
Below is the dialogue resulting from a call to the initial version of getEmployeeDetails as described in the introductory section What is SOAP? In this version the client sends an int and receives an array of strings (a two-element array of strings holding the employee name and the telephone number). Notice the type information contained in the <return> tag of the response message, namely xsi:type="ns2:Array" ns2:arrayType="xsd:string", which describes the structure of the array.
Later on we made the service a little more complex. We wanted to provide a more complete set of contact numbers over time as employees came and went on business trips. The dialogue resulting from a call to this revised version of getEmployeeDetails is below. The client still sends an int but receives a complex type. Notice the nesting of the data in the response message and its correlation with the type definitions.
In the preceding sections of SOAP Basics we learnt what SOAP is and how it can be used as the message protocol for the Service Web. In this section we looked at what the messages actually look like, and indeed what the dialogues actually look like, when a SOAP-based web service is consumed. In the final section on SOAP Basics we will take a look at what the different system elements are that go to make up a SOAP-based system, what each of them does and how they interact.
[ Nicholas Quaine ]
Copyright © 2001-2007 Nicholas Quaine. All rights reserved.