[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Updates for SOAP actor / mustunderstand sections
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.
From: Dale Moberg
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.
Proposed updates for SOAP Actor sections (18.104.22.168 / 22.214.171.124 ) and SOAP mustUnderstand section (126.96.36.199) (by Jacques & Hamid):
- Section 188.8.131.52 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 (184.108.40.206 / 220.127.116.11 ):
Propose to remove and replace with a single section titled:
18.104.22.168: 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.