Dale:
We would also like to be able to say that
only SOAP intermediaries are necessary. We know that new addressing and routing
capabilities have been added since ebMS2 e.g. with WS-Addressing.
But when making our proposal, we
considered the following cases that seem to need more:
-
ebMS MEP
semantics need be preserved across a SOAP intermediary (Pull MEP, Request-reply
MEP) meaning the node must know when to keep an underlying connection open for
a synchronous response. That does not apply though when doing One-way Push MEP
only.
-
Some intermediary
may need to do routing based on ebMS header content (e.g. based on party info,
or service/action, or other properties.)
-
Cases where
intermediaries just log / check e.g. for audit before forwarding. Such logging
may need be selective based on ebms header content.
The above cases do require some intermediaries
to understand the ebms header. A unique soap actor/role (that we call "ebms")
for the eb:Messaging header that targets every MSH on the way, supports this. (
"ultimateMSH" not necessary for ebms header unlike in ebMS2).
Even without MSH intermediaries, we
would still need an explicit role (and "ebms" also works here) in case
the ultimate MSH is forwarding to another (non-MSH) SOAP node.
Same for the new security and reliability
headers that we consider parts of an ebMS message: they need be clearly
targeted to an MSH (to distinguish from other such headers that could be there in
the message but for other purpose than ebMS, i.e. added and consumed by other
nodes than MSH)
We thought that the complexity is very
modest compared to the use cases covered.
Some proposed lines of discussion to make
progress on this:
- use cases that we really want to cover,
and what should be addressed in Part 1 vs. Part 2.
- conformance profiles that may or may not
need such actors / use cases.
Thanks,
Jacques
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.