- 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
The SOAP Processing Model
Now we're ready to finish describing the SOAP 1.2 processing model. Here are the steps a processor must perform when it receives a SOAP message, as described in the spec:
Determine the set of roles in which the node is to act. The contents of the SOAP envelope, including any SOAP header blocks and the SOAP body, may be inspected in making such determination.
Identify all header blocks targeted at the node that are mandatory.
If one or more of the SOAP header blocks identified in step 2 aren't understood by the node, then generate a single SOAP fault with the value of Code set to env:mustUnderstand. If such a fault is generated, any further processing must not be done. Faults related to processing the contents of the SOAP body must not be generated in this step.
Process all mandatory SOAP header blocks targeted at the node and, in the case of an ultimate SOAP receiver, the SOAP body. A SOAP node may also choose to process nonmandatory SOAP header blocks targeted at it.
In the case of a SOAP intermediary, and where the SOAP message exchange pattern and results of processing (for example, no fault generated) require that the SOAP message be sent further along the SOAP message path, relay the message.
The processing model has been designed to let you use mustUnderstand headers to do anything you want. We could imagine a mustUnderstand header, for instance, that tells the processor at the next hop to process all headers and ignore the role attribute.