SOAP : More Details

Scenario
Consider a scenario in which SOAP message goes from sender to receiver via many intermediaries 

Intermediaries in a SOAP message path must not modify the application-specific contents of the SOAP Body element, but they may, and often do, manipulate the SOAP header blocks.

two relatively simple header blocks: message-id and processed-by. The processed-by header block keeps a record of the SOAP applications (nodes) that process a SOAP message on its way from the initial sender to the ultimate receiver. Like the message-id header, the processed-by header block is useful in debugging and logging

<?xml version="1.0" encoding="UTF-8"?>

<soap:Envelope

 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

 xmlns:mi="http://www.Monson-Haefel.com/jwsbook/message-id"

 xmlns:proc="http://www.Monson-Haefel.com/jwsbook/processed-by">

  <soap:Header>

    <mi:message-id>11d1def534ea:b1c5fa:f3bfb4dcd7:-8000</mi:message-id>

    <proc:processed-by>

      <node>

        <time-in-millis>1013694680000</time-in-millis>

        <identity>http://www.customer.com</identity>

      </node>

      <node>

        <time-in-millis>1013694680010</time-in-millis>

        <identity>http://www.Monson-Haefel.com/sales</identity>

      </node>

      <node>

        <time-in-millis>1013694680020</time-in-millis>

        <identity>http://www.Monson-Haefel.com/AR</identity>

      </node>

      <node>

        <time-in-millis>1013694680030</time-in-millis>

        <identity>http://www.Monson-Haefel.com/inventory</identity>

      </node>

      <node>

        <time-in-millis>1013694680040</time-in-millis>

        <identity>http://www.Monson-Haefel.com/shipping</identity>

      </node>

    </proc:processed-by>

  </soap:Header>

  <soap:Body>

      <!-- Application-specific data goes here -->

  </soap:Body>

</soap:Envelope>

actor attribute

You use an actor attribute to identify a function to be performed by a particular node.

Just as a person can perform one or more roles in a stage play, a node can play one or more roles in a SOAP message path. Unfortunately, the designers of SOAP 1.1 confused the words "actor" and "role"; they specified that you must identify the roles a node will play by declaring an actor attribute. They've recognized their mistake, and in SOAP 1.2 this attribute has been renamed role.

The actor attribute is used in combination with the XML namespaces to determine which code module will process a particular header block. Conceptually, the receiving node will first determine whether it plays the role designated by the actor attribute, and then choose the correct code module to process the header block, based on the XML namespace of the header block. Therefore, the receiving node must recognize the role designated by the actor attribute assigned to a header block, as well as the XML namespace associated with the header block

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:mi="http://www.Monson-Haefel.com/jwsbook/message-id"
 xmlns:proc="http://www.Monson-Haefel.com/jwsbook/processed-by">
  <soap:Header>
    <mi:message-id soap:actor="http://www.Monson-Haefel.com/logger" >
      11d1def534ea:b1c5fa:f3bfb4dcd7:-8000
    </mi:message-id>
    <proc:processed-by>
      <node>
        <time-in-millis>1013694680000</time-in-millis>
        <identity>http://www.customer.com</identity>
      </node>
    </proc:processed-by>
  </soap:Header>
  <soap:Body>
      <!-- Application-specific data goes here -->
  </soap:Body>
</soap:Envelope>

Only those nodes in the message path that identify themselves with the actor value "http://www.Monson-Haefel.com/logger" will process the message-id header block; all other nodes will ignore it

The actor attribute may have values like

1. 1.       custom URIs like "http://www.Monson-Haefel.com/logger",
2. 2.       two standard roles for the actor attribute: next
3. 3.       and ultimate receiver.

The next role indicates that the next node in the message path must process the header. The next role has a designated URI, which must be used as the value of the actor attribute: "http://schemas.xmlsoap.org/soap/actor/next".

The ultimate receiver role indicates that only the ultimate receiver of the message should process the header block. The protocol doesn't specify an explicit URI for this purpose; it's the absence of an actor attribute in the header block that signals that the role is ultimate receiver

must understand attribute

In many cases we may not know the exact message path or the capabilities of all the nodes in a message path, which means we don't always know whether nodes can process header blocks correctly.  For example, the processed-by header block is targeted at the next role, which means the next node to receive it should process it. But what if the next node doesn't recognize that kind of header block?

The mustUnderstand attribute can have the value of either "1" or "0", to represent true and false, respectively. 0 is default.

The "understand" in mustUnderstand means that the node must recognize the header block by its XML structure and namespace, and know how to process it.

If a node doesn't understand a mandatory header block, it must generate a SOAP fault (similar to a remote exception in Java) and discard the message; it must not forward the message to the next node in the message path

Whether or not a fault is sent back to the sender depends on whether the messaging exchange pattern (MEP) is One-Way or Request/Response.

If the mustUnderstand attribute is "0", the processing requirements specified by SOAP are very different. If a node performs the role declared by a non-mandatory header block, and an application fails to understand the header (it doesn't recognize the XML structure or the namespace), it must remove the header block.

In other words, receivers should not attempt to determine whether a message was successfully processed by previous nodes in the path based on which header blocks are present

Note :- header element is optional but body is mandatory.

Neither SOAP 1.1 nor the BP explicitly prohibits intermediaries from modifying the contents of the Body element. As a result, the ultimate receiver has no way of knowing if the application-specific data has changed somewhere along the message path. SOAP 1.2 reduces this uncertainty by explicitly prohibiting certain intermediaries, called forwarding intermediaries, from changing the contents of the Body element and recommending that all other intermediaries, called active intermediaries, use a header block to document any changes to the Body element.

ok