- SOAP
- Doing Business with SkatesTown
- Inventory Check Web Service
- A Closer Look at SOAP
- The SOAP Messaging Framework
- SOAP Intermediaries
- The SOAP Body
- The SOAP Processing Model
- Versioning in SOAP
- Processing Headers and Bodies
- Faults: Error Handling in SOAP
- Objects in XML: The SOAP Data Model
- The SOAP RPC Conventions
- XML, Straight Up: Document-Style SOAP
- When to Use Which Style
- The Transport Binding Framework
- Using SOAP to Send Binary Data
- Small-Scale SOAP, Big-Time SOAP
- Summary
- Resources
This chapter is from the book
This chapter is from the book
This chapter is from the book
A Closer Look at SOAP
The current SOAP specification is version 1.2, which was released as a W3C recommendation in June 2003. At the time of this writing (early 2004), toolkits are just starting to offer complete support for the new version, and most of them still use SOAP 1.1 as a baseline. Since this chapter is primarily about the SOAP protocol, we'll focus on SOAP 1.2—the standard the industry will be using into the future. The 1.1 version is also critically important, so we'll also explain it and use sidebars to call out differences between the versions as we go. (You can find an exhaustive list of differences between SOAP 1.1 and SOAP 1.2 in the SOAP 1.2 Primer: http://www.w3.org/TR/2003/REC-soap12-part0-20030624/.) Most of the other examples in this book use SOAP 1.1, but we want you to be a 1.2-ready developer.
The Structure of the Spec
The SOAP 1.2 specification is the ultimate reference to the SOAP protocol; the latest version is at http://www.w3.org/TR/SOAP. The spec is divided into two parts:
Part 1, the Messaging Framework—Lays out the central foundation of SOAP, consisting of the processing model, the extensibility model, and the message structure.
Part 2, Adjuncts—Important adjuncts to the core spec defined in Part 1. Although they're extensions (and therefore by definition optional), they serve two critical purposes. First, they act as proofs-of-concept for the modular design of SOAP, demonstrating that it isn't limited, for instance, to only being used over HTTP (a common misconception). Second, the core of SOAP in Part 1 isn't enough to build something usable for functional interoperable services. The extensions in part 2, in particular the HTTP binding, provide a baseline for implementers to use, even though the marketplace may define other components beyond those in the spec as well.
Infosets
The SOAP 1.2 spec has been written in terms of the XML infoset, which is an abstract model of all the information in an XML document or document fragment. When the spec talks about "element information items" instead of just elements, it means that what is important is the structure of the information, not necessarily the fact that it's serialized with angle brackets. As you'll see later, this becomes important when we talk about bindings. The key thing to remember is that all the information items are really abstract ways of talking about things like elements and attributes that you see in everyday XML. So this XML
<elem attr="foo"> <childEl>text</childEl> Other text </elem>
would abstractly look like the structure in Figure 3.1 (rectangles are elements, rounded rectangles attributes, and ovals text).
)
Figure 3.1 A simple XML infoset