SOAP messages are fundamentally one-way transmissions from a SOAP sender to a SOAP receiver; however, SOAP messages are often combined to implement patterns such as request/response.
can be optimized to exploit the unique characteristics of particular network
systems. For example, the HTTP binding described in (SOAP in HTTP)
provides for SOAP response messages to be
delivered as HTTP responses, using the same connection as the inbound request.
A SOAP node can be
the initial SOAP sender, the ultimate SOAP receiver, or a SOAP intermediary, in
which case it is both a SOAP sender and a SOAP receiver.
SOAP does not
provide a routing mechanism, however SOAP does recognise that a SOAP sender
originates a SOAP message which is sent to an ultimate SOAP receiver, via zero
or more SOAP intermediaries.
A SOAP node
receiving a SOAP message MUST perform processing according to the SOAP
processing model as described in this section and
, if appropriate,
generate SOAP faults, SOAP responses and send additional SOAP messages, as
provided by the remainder of this specification.
In processing a SOAP
message, a SOAP node is said to act in the role of one or more SOAP actors,
each of which is identified by a URI known as the SOAP actor name. Each SOAP
node MUST act in the role of the special SOAP actor named
"http://www.w3.org/2001/12/soap-envelope/actor/next", and can
additionally assume the roles of zero or more other SOAP actors.
SOAP node can establish itself as the ultimate SOAP receiver by acting in the
(additional) role of the anonymous SOAP actor. The roles assumed
MUST be invariant during the processing of an individual SOAP message; because
this specification deals only with the processing of individual SOAP messages,
no statement is made regarding the possibility that a given piece of software
might or might not act in varying roles when processing more than one SOAP
message. SOAP nodes MUST NOT
act in the role of the special SOAP actor named
blocks targeted to this special actor are carried with the message to the
ultimate receiver, but are never formally "processed". Such blocks
MAY carry data that is required for processing of other blocks.
While the purpose of a SOAP actor name is to identify a SOAP node, there are no routing or message exchange semantics associated with the SOAP actor name. For example, SOAP Actors MAY be named with a URI useable to route SOAP messages to an appropriate SOAP node. Conversely, it is also appropriate to use SOAP actor roles with names that are related more indirectly to message routing (e.g. "http://example.org/banking/anyAccountMgr") or which are unrelated to routing (e.g. a URI meant to identify "all cache management software"; such a header might be used, for example, to carry an indication to any concerned software that the containing SOAP message is idempotent, and can safely be cached and replayed.)
and the anonymous actor this
specification does not prescribe the criteria by which a given node determines
the (possible empty) set of roles in which
it acts on a given message. For example, implementations can base this
determination on factors including, but not limited to: hardcoded choices in
the implementation, information provided by the transport binding (e.g. the URI
to which the message was physically delivered), configuration information made
by users during system installation, etc.
SOAP header blocks
information items (see 4.2.2 SOAP actor Attribute)
that are used to target them to the appropriate SOAP node(s). SOAP header
blocks with no such attribute information item are implicitly targeted
anonymous SOAP actor, implying that they are to be
processed by the ultimate SOAP receiver. This specification refers
to the (implicit or explicit) value of the SOAP
actor attribute as the SOAP actor for the corresponding SOAP
A SOAP header block
is said to be targeted to a SOAP node if the SOAP
actor (if present) on the
block matches (see ) a role played by the SOAP node, or
in the case of a SOAP header block with no
actor attribute information item, if the SOAP node is
acting in the role of the ultimate SOAP receiver.
A SOAP Node that
acts in the role of the anonymous actor with
respect to a particular SOAP message becomes the ultimate recipient of that SOAP
message . Such a SOAP node is responsible for processing all parts of th e
message intended for the anonymous actor, including the body , according to the
rules described in this section . The SOAP message
path for that message ends at the ultimate recipient. However,
the ultimate recipient may delegate all or part of its responsibility to other
entities. The ultimate recipient may happen to use distinct SOAP message exchanges
to interact with such entities. Nevertheless, responsibility for the processing
of parts of a SOAP message targetted at the anonymous actor rests with the
ultimate recipient of that message
It is likely that specifications for a wide variety of header functions will be developed over time, and that some SOAP nodes MAY include the software necessary to implement one or more such extensions. A SOAP header block is said to be understood by a SOAP node if the software at that SOAP node has been written to fully conform to and implement the semantics conveyed by the combination of local name and namespace name of the outer-most element information item of that block.
SOAP header blocks
information items (see 4.2.3 SOAP mustUnderstand
Attribute). When the value of such an attribute information item
is "true" or "1", the SOAP block is said to be mandatory.
For every mandatory
SOAP header block targeted to a node, that node MUST either process the block
to the semantics conveyed by the combination of local name and namespace name
of the outer-most element information item of that block; or not
process the SOAP message at all, and instead generate a fault (see 2.6 Processing SOAP Messages and 4.4 SOAP Fault).
Mandatory blocks MUST be presumed to somehow modify the semantics of other headers or body elements. Tagging SOAP blocks as mandatory thus assures that such changes in semantics will not be silently (and, presumably, erroneously) ignored.
information item is not intended as a mechanism for detecting errors in
routing, misidentification of nodes, failure of a node to serve in its intended
role(s), etc., any of which may result in a failure to even attempt processing
and the subsequent removal, of a given SOAP header block from a
SOAP envelope. This specification therefore does not require any fault to be
generated based on the presence or value of this attribute on a SOAP header
block not targeted at the current processing node, for example when it is
suspected that such a block has survived erronously due to a routing or
targeting error at a preceeding intermediairy. In particular, it is not an
error for a mandatory header block targeted to a role other than the ones
assumed by the ultimate SOAP receiver to reach that node without having been
A SOAP body consists
of zero or more namespace qualified element information items, which
are the immediate children of the
information item. The ultimate SOAP receiver MUST correctly process such body elements. However, Part 1 of this specification (this
document) mandates no particular structure or interpretation of such elements,
and provides no standard means for specifying the processing to be done.
When multiple body
elements are present, such elements MAY represent a single unit of work to be
performed, MAY represent multiple separate processing steps, possibly but not
necessarily in order, MAY represent data or metadata, MAY convey a mixture of
work units and data, etc. The ultimate SOAP recipient MAY use the local name(s)
and namespace name(s), on any or all body elements, to determine the processing
to be performed. Indeed, the SOAP RPC convention (see Using SOAP
for RPC ) uses just such a method. Conversely, other
information in the body and/or headers MAY be used to make such a
This section sets out the rules by which SOAP messages are processed. Unless otherwise stated, processing must be semantically equivalent to performing the following steps separately, and in the order given. Note however that nothing in this specification should be taken to prevent the use of optimistic concurrency, roll back, or other techniques that might provide increased flexibility in processing order as long as all SOAP messages, SOAP faults and application-level side effects are equivalent to those that would be obtained by direct implementation of the following rules in the order shown below.
1. Determine the set of roles in which the node is to act. The contents of the SOAP envelope, including header blocks and the body, MAY be inspected in making such determination.
2. Identify all header blocks targeted at the node that are mandatory.
If one or more of the header blocks identified in the
preceding step are not understood by the node then generate a single SOAP
MustUnderstand fault (see 4.4.6 MustUnderstand Faults).
If such a fault is generated, any further processing MUST NOT be done.
relating to the existence or contents of the body MUST NOT be generated in this
4. Process all header blocks targeted at the node and, in the case of the ultimate SOAP recipient, the SOAP body. A SOAP node MUST process all SOAP header blocks targeted at it. A SOAP node MAY choose to ignore the processing implied by non-mandatory SOAP header blocks targeted at it.
In the case of a SOAP intermediary,
the message is to be forwarded further along the message path, remove all SOAP
header blocks targeted at the node, and possibly insert new SOAP header blocks.
In all cases where a SOAP header block is processed, the SOAP node must understand the SOAP block and must do such processing in a manner fully conformant with the specification for that block. The ultimate recipient MUST process the SOAP body, in a manner consistent with 2.5 Structure and Interpretation of SOAP Bodies.
If processing is unsuccessful, exactly one fault MUST be generated by the node. Header-related faults other than mustUnderstand faults (see 4.4 SOAP Fault) MUST be SOAP Sender or DataEncodingUnknown faults (see 4.4.5 SOAP Fault Codes) and MUST conform to the specification for the corresponding SOAP header block. Faults relating to the body MUST be SOAP Sender or DataEncodingUnknown faults (see 4.4.5 SOAP Fault Codes).
SOAP nodes can make reference to any information in the SOAP envelope when processing a SOAP block. For example, a caching function can cache the entire SOAP message, if desired.
The processing of particular SOAP header block MAY control or determine the order of processing for other SOAP header blocks and/or the SOAP body. For example, one could create a SOAP header block to force processing of other SOAP header blocks in lexical order. In the absence of such a controlling block, the order of header and body processing is at the discretion of the SOAP node; header blocks MAY be processed in arbitrary order, and such processing MAY precede, be interleaved with, or MAY follow processing of the body. For example, a "begin transaction" header block would typically precede, a "commit transaction" would likely follow, and a "logging" function might run concurrently with body processing.
If the SOAP node is a SOAP intermediary, the SOAP message pattern and results of processing (e.g. no fault generated) MAY require that the SOAP message be sent further along the SOAP message path. Such relayed SOAP messages MUST contain all SOAP header blocks and the SOAP body from the original SOAP message, in the original order, except that SOAP header blocks targeted at the SOAP intermediary MUST be removed (such SOAP blocks are removed regardless of whether they were processed or ignored). Additional SOAP header blocks MAY be inserted at any point in the SOAP message, and such inserted SOAP header blocks MAY be indistinguishable from one or more just removed (effectively leaving them in place, but emphasizing the need to reinterpret at each SOAP node along the SOAP message path.)
The above rules
apply to processing at a single node. SOAP
extensions MAY be designed to ensure that mandatory (and other) headers are
processed in an appropriate order, as the message moves along the message path
towards the ultimate recipient. Specifically, such extensions might specify that a (Sender) fault is generated if some SOAP
header blocks have inadvertently survied past some intended point in the
message path. Such extensions MAY depend on the presence or value of the
information item in the surviving headers when determining whether an
error has occurred.