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:

<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