Protocol Binding

Summary

In this chapter, you learned about the underlying messaging protocol of Web services, SOAP. Specifically, you learned about the following:

• The SOAP envelope. How it is used to encode header information about the message and the body of the message itself

• SOAP Encoding. How data can be serialized into a SOAP message

• RPC messages. How RPC messages facilitate procedure-oriented communication via request/response message patterns

• The HTTP POST protocol binding. How SOAP messages can be transported via HTTP

You learned that, at a bare minimum, a SOAP message must be contained within a well-formed SOAP envelope. An envelope is composed of a single Envelope element. The envelope can contain a Header element and must contain a Body element. If present, the header must be the immediate child element within the envelope, with the body immediately following the header. The body contains the payload of the message, and the header contains additional data that does not necessarily belong in the body of the message.

In addition to defining a SOAP envelope, the SOAP specification defines a way of encoding the data contained within a message. SOAP Encoding provides a standard means of serializing data types that are not defined within part 1 of the XML Schema specification. This includes arrays and references to instances of data types.

The SOAP specification also provides a standard message pattern for facilitating RPC-style behavior. Two SOAP messages are paired together to facilitate a request message and an associated response.

The method call and its parameters are serialized in the body of the request message in the form of a structure. The root element carries the same name as the targeted method, with each inbound parameter encoded as a subelement.

The response message will either contain the results of the method call or a well-defined fault structure. The results of the method call are serialized in the body of the request as a structure. By convention, the root element carries the same name as the original method call with Result appended to it. The return parameters are serialized as child elements, with the return parameter appearing first. If an error is encountered, the body of the response message will contain a well-defined fault structure.