12 Part I: The Web Services Architecture
SOAP provides a simple and lightweight mechanism for exchanging structured and typed
information between peers in a decentralized, distributed environment using XML. SOAP was
designed to reduce the engineering cost of integrating applications built on different plat-
forms as much as possible with the assumption that the lowest-cost technology has the best
chance of gaining universal acceptance. Given its central role in the Web services architecture,
we describe SOAP and its processing model in some detail.
A SOAP message is an XML document information item that contains three elements: <Enve-
lope>, <Header>, and <Body>. The Envelope is the root element of the SOAP message and con-
tains an optional Header element and a mandatory Body element. The Header element is a
generic mechanism for adding features to a SOAP message in a decentralized manner. Each
child element of Header is called a header block, and SOAP defines several well-known
attributes that can be used to indicate who should deal with a header block (role) and
whether processing it is optional or mandatory (mustUnderstand), both described below.
When present, the Header element is always the first child element of the Envelope. The Body
element is always the last child element of the Envelope and is a container for the “payload”
intended for the ultimate recipient of the message. SOAP itself defines no built-in header
blocks and only one payload, which is the Fault element used for reporting errors.
All Web services messages are SOAP messages that take full advantage of the XML Infoset. The
fact that both the message payload and the protocol headers employ the same model can be
used to ensure the integrity of infrastructure headers as well as application bodies. Messaging
infrastructure and applications can route messages based on the content of both the headers
and the data inside the message. Tools that have been developed for the XML data model can
be used for inspecting and constructing complete messages. These benefits were not available
in architectures such as DCOM, CORBA, and RMI, where protocol headers were infrastruc-
tural details opaque to the application.
SOAP messages are transmitted one-way from sender to receiver—they are datagram messages
of XML documents. Multiple one-way messages can be combined into more sophisticated pat-
terns. For instance, a popular pattern is a synchronous request/response pair of messages.
The rest of this chapter describes key elements of the SOAP processing model.
Any software agent that sends or receives SOAP messages is called a SOAP node. The node
that performs the initial transmission of a message is called the original sender. The final node
that consumes and processes the message is called the ultimate receiver. Any node that pro-
cesses the message between the original sender and ultimate receiver is called an intermedi-
ary. Intermediaries are used to model the distributed processing of an individual message.
The collection of intermediary nodes traversed by the message and the ultimate receiver are
collectively referred to as the message path.

Get Web Services Architecture and Its Specifications: Essentials for Understanding WS-* now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.