I would like to consider whether all
intermediaries can be just SOAP intermediaries, and there be no ebXML MSH
intermediary.
That is, ebXML traffic when it needs to
make use of intermediaries can simply drop down to use capabilities defined in
the XMLP SOAP specifications.
This would simplify MSH and would permit
the elimination of nextMSH and its successor notion.
Thanks
Dale Moberg
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.