OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: status of current routing discussion: consensus?

Summary of some off-line discussion that seem to bring the following consensus about routing aspects:
1- An (eb) Intermediary must be able to route ebms User Messages based the header content eb:UserMessage, as agreed before. In addition, an Intermediary must also be able to understand wsa ref parameter named "ebmsrouting" (with namespace:ebint= http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/Intermediary). This element is just a container for an eb:UserMessage element.
2- Whenever the "ebint:ebmsrouting" ref parameter is present, an Intermediary must use it for routing (even if an eb:Messaging/eb:UserMessage is there). If not present, the Intermediary will use eb:Messaging/eb:UserMessage if present. If none of these are present, the Intermediary expects to see a wsa:To that will be used for routing (which assumes the destination URL is known in that case).
3- The Intermediary does not make an check on which messages such headers are piggybacked on: ebint:ebmsrouting could be on an RM signal message as well as on an ebms User message or on an ebms Signal message. Similarly, if a "dummy" eb:Messaging/eb:UserMessage is piggybacked on an RM signal (instead of  ebint:ebmsrouting) the Intermediary should still route.
- wsa EPRs may be defined in the PMode associated with an MEP, both for forward routing and backward routing. The ref parameters will look like:
            .... (with only the header elements values that are "invariant" for this PMode, i.e. common to all messages for the PMode)
That will translate in such SOAP header as:
     <ebint:ebmsrouting wsa:IsReferenceParameter='true'>
     </ebint:ebmsrouting>         ...
4- The EPR intended for the routing of response messages for this PMode, will be known from the initial Sender. It will also include a ref parameter as before that allows for routing these responses back. If appropriate, the response EPR may also mention directly the response address (or an Intermediary address) in the <wsa:Address> field of the EPR.
The response EPR should be indicated on the wire, in the wsa:ReplyTo (even if the destination has a copy of the PMode). This among other things enables an Intermediary to know where to send back eb:Errors related to routing failure.
5- The destination of all RM-related "response" signals (CSR, TSR, Acks...) is indicated in the wsrm:AcksTo element. This element used in the wsrm:CS must also be set to the response EPR specified in the PMode for all forward-going messages. In other words the destination of all response messages that result from the execution of forward-going messages: eb:Errors, eb:Receipts, various RM signals, is the same.
6- Note that if some endpoint MSH decides to just piggyback "dummy" eb:Messaging/eb:UserMessage header on their wsrm:CreateSequence, and not bother with wsa ref parameter <ebint:ebmsrouting> headers, they are still free to do so. This is not prohibited by V3 part 2. The routing must work. But they should have an out-of-band agreement with their endpoint partners that these dummy User messages are not to be delivered (or should be ignored if delivered), in case they need to set Service/Action to something else than the Core V3 "default" value (which in otherwise would guarantee non-delivery.)
7- An Intermediary is not supposed to have knowledge of PModes, except for the case where the Intermediary is connected to an endpoint that needs to do pulling, in which case at minimum the Intermediary needs to know (a) which MPCs are intended for pull, (b) what is the authorization data associated with these MPCs.
Still to be refined:
- Pulling cases (see Sander's) and also the pulling of eb:Receipts which may require at least the addition of @mpc to eb:SignalMessage (today only for eb:UserMessage).
- the special case of "sub-channels" allocated by an Intermediary (see use cases Pim & Jacques)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]