8.1 Introduction to SOAP

SOAP originally stood for Simple Object Access Protocol, but it is no longer restricted in any way to object access or object-oriented use. Starting with version 1.2, the acronym is no longer officially spelled out; that is, "SOAP" is just a name. Although it originated from an industrial consortium, the XML Protocol Working Group of the W3C now has change control for new versions of SOAP. Here we give an overview of the features that SOAP includes and excludes, examine its relationship to XML, and list the basic SOAP namespaces.

8.1.1 Features Included and Excluded

Draft Version 1.2 [SOAP] includes the following:

• A definition of a general structure for messages

• A general processing specification for handling SOAP messages from an originator through zero or more intermediate nodes to an ultimate destination

• A method for returning error and status indications

• A specification for encoding a variety of data types into those messages

• A specification for sending messages over lower-level transport protocols, particularly HTTP

• A description of one way to use SOAP for remote procedure calls

To achieve its goals of simplicity and extensibility, SOAP excludes the following features (and some others not listed here):

• Grouping or batching of multiple messages

• Transmission of objects-by-reference

• Distributed garbage collection (which, as a practical matter, is required if objects are transmitted by reference)

An application based on SOAP can add features through SOAP Headers.

8.1.2 Relation of SOAP to XML

SOAP imposes substantial restrictions on the XML it uses. In particular, SOAP messages (i.e., documents) must obey the following restrictions:

• Processing instructions are prohibited.

• All elements and attributes must be appropriately namespace qualified.

• DTDs are prohibited. SOAP applications must simply know the SOAP DTDs and schemas.

• No schema processing can be required. This restriction, along with the "no DTDs" rule, means that all attributes or elements intended must be explicitly present and cannot be supplied by default.

Also, note that SOAP defines some global attributes that you can use in any SOAP namespace element. In particular, you can use "id" of type ID, and "href" of schema type anyURI. The "id" attribute uniquely identifies an encoded element and the "href" attribute references a value.

The SOAP restrictions on and assumptions about the XML used are relatively strong. In this respect, SOAP is somewhat similar to BEEP [RFC 3080], which prohibits any character or entity references other than the five predefined character references in [XML]. It's a bit suspicious that "protocol" uses of XML tend to immediately throw overboard a substantial amount of the "richness" of XML this way. Thus you can't just transparently include XML from other realms of interest inside such "XML" protocols without considering the possibility that it might violate the protocol framework's severe restrictions. If XML had been simpler, perhaps protocols would be more inclined to use it without major surgery.

8.1.3 Basic SOAP Namespaces

The following namespaces are part of the basic mechanisms of the SOAP version 1.2 draft. Additional namespaces are used in connection with encoding and remote procedure calls.

The SOAP envelope syntax, discussed in Section 8.2, has the namespace identifier

 http://www.w3.org/2001/12/soap-envelope 

The SOAP MustUnderstand Fault has the namespace identifier

 http://www.w3.org/2001/12/soap-faults 

The SOAP Upgrade element that you use in connection with version negotiation has the namespace identifier

 http://www.w3.org/2001/12/soap-upgrade 

Note

Do not confuse the "MustUnderstand" fault and the "mustUnderstand" attribute that differ in terms of the capitalization of their names.