Updates for SOAP actor / mustunderstand sections

[Jacques Durand <JDurand@us.fujitsu.com>]

Proposed updates for SOAP Actor sections (5.1.3.9 / 5.1.3.10 ) and SOAP mustUnderstand section (5.1.3.8) (by Jacques & Hamid):

 

- Section 5.1.3.8 on SOAP mustUnderstand reads too much like a tutorial.

Reword it by simply stating that this attribute is required on eb:Messaging header,

and must have value "1".

 

- sections (5.1.3.9 / 5.1.3.10 ):

Propose to remove and replace with a single section titled:

5.1.3.9: ebXML SOAP Actors

 

Short summary of the content for this new consolidated section:

-          "NextMSH" and "ToPartyMSH" actors are "removed. Instead, we use "ebms" and "ebmsfinal", which do not have quite same semantics as the removed actors.

-          The eb:Messaging header (or ebms header) has always its actor attribute set to "ebms" regardless of its position (intermediary or ultimate). Any MSH always acts in ebms role.

-          Other headers subject to MSH processing (reliability, security) must have "ebms" actor if the next MSH must process them. If instead reliability or security is end-to-end, they must have "ebmsfinal" actor value. The ultimate MSH knows that it also acts in ebmsfinal role.

-          If reliability or (some) security headers have no actor or have actors with other values, that means they are not intended for MSH processing.

 

Detailed content for this section (not pretending to be editorial-ready) is drafted below. Note that it was necessary to investigate a little the "multi-hop" schemes in order to make a decision on above actor values, although multi-hop and hub topologies are to be developed in Part II.

 

 

An MSH can be deployed either as an "intermediary" or "ultimate" MSH. In the intermediary role, the MSH is not the last MSH. In the ultimate role, the MSH is the last MSH on a message path. [Note: nothing prevents an implementation to adjust these roles depending on messages: an MSH can be ultimate for a class of messages and intermediary for others. For the sake of simplicity in this section, these roles will be considered static for a deployment and not depending on messages.] A more detailed description of these roles is provided in Part II, multi-hop section. When an MSH is deployed in the ultimate role (being the last MSH), it could also be the last SOAP node or it could still be an intermediary SOAP node. Hence there are three basic deployment roles for an MSH ( "deployment role" means here "position" of an MSH within a given deployment topology, over a message path):

- intermediary MSH

- ultimate MSH that is also the ultimate SOAP node

- ultimate MSH that is a SOAP intermediary.

 

An MSH makes a decision to process the message headers depending on its deployment role, and on the header "actor" attribute.

 

Case of the "ebms" header:

 

The eb:Messaging header must be understood by any MSH on a message path (see multi-hop section in Part II for more details): the ultimate MSH will process it, while an intermediary MSH still needs to understand part of it in order to maintain the semantics of MEPs such as One-way Pull and Request-Reply. When processed by an MSH intermediary, the latter must not remove the eb:Messaging header from the SOAP message - only the ultimate MSH must do this. In order to allow for both processing, the eb:Messaging header must always have its actor attribute set to "ebms".

 

Case of security and reliability headers:

 

There could be several wss:Security elements within a SOAP message. A wss:Security header could be destined either to an intermediary MSH and/or to the ultimate MSH only. A security element that must be processed by an intermediary MSH must have an actor="ebms" in order for the MSH to figure out which security elements it can process. If a security element is destined to only the ultimate MSH, it must have an actor="ebmsfinal". If the actor of a security element is either absent or has a value that is neither "ebms" nor "ebmsfinal", such a security element will not be processed by any MSH on the path (it may be destined to a SOAP node beyond the ultimate MSH or some SOAP node between two intermediary MSHs).

The same applies for reliability headers. The only difference is that there must be only one reliability header within a SOAP message.

Once an intermediary MSH has processed a reliability header, this header must not appear anymore in the forwarded message.