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:
<wsa:ReferenceParameters>
<ebint:ebmsrouting>
<eb:UserMessage>
.... (with only the header elements values that are "invariant" for this PMode,
i.e. common to all messages for the PMode)
</eb:UserMessage>
</ebint:ebmsrouting>
</wsa:ReferenceParameters>
That
will translate in such SOAP header
as:
<S:Header>
...
<ebint:ebmsrouting
wsa:IsReferenceParameter='true'>
<eb:UserMessage>...</eb:UserMessage>
</ebint:ebmsrouting>
...
</S:Header>
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)
Jacques