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.