Multihop MOU

Multihop MOU from F2F meeting:

(with embedded "comments (JD)" from Jacques)

 

----------------- 
Intermediary transparency -------------------

 

1. ebMS intermediaries: they will be totally 
"transparent" in the sense they will not

modify or extend the ebMS messages as well as other 
signal messages (RM signals, faults, etc.).

Intermediaries will only be preoccupied with 
routing. Two options here:

 

1.a: the intermediary must parse/ understand the eb 
header,

 

1.b: the intermediary only looks at wsa reference 
parameters, in case routing

info is already extracted as wsa reference 
parameters.

 

- Comment (JD): ebMS MSH Intermediaries will still 
need to understand ebMS MEPs: in particular, those

intermediaries that participate into the first or 
last hop, must be able to support Pulling. E.g.:

"[1-way] / Push-and-last-Pull" channel binding. So 
the forwarding / routing of a message may look like:

post a received pushed message (on the "incoming 
MPC" xyz) to the "outgoing" MPC xyz that is configured for Pull.

If the MPC is part of ref parameters, that still 
may not require parsing the eb header.

Such intermediaries need be configured with PMode 
info though (e.g. which MPC is for pull, which for push)

 

- Comment (JD): in some routing option below, the 
SOAP header may be extended by intermediaries

with wsa ref parameters. (Is that still transparent 
enough? normally these should be signed too.)

 

-------------------- 
endpoint MSH conformance ------------------

 

2. Endpoint MSHs may act as initial Sender or 
ultimate Receiver in a multihop exchange, without

requiring more "ebms" features than those specified 
in Core V3. However they must now support WS-addressing

(which was not explcitly required in Core 
V3).

 

------------------------ Routing of User Messages 
-----------------------

 

3. Routing of User Messages: from the start these 
have all routing info in their eb header (eb:UserMessage).

Three major routing options: 

 

(3.a) the routing info is always in 
eb:Messaging/eb:UserMessage header data  
(possibly any business header data)? 

 

(3.b) the routing info is always in wsa reference 
parameters added in the SOAP header,

like expected for other signals such as RM 
CreateSequence? 

 

(3.c) = "if not (3.b) then (3.a)" (defaulting on 
eb:Messaging/eb:UserMessage if ref params are absent)

 

- Comment (JD): during F2F, the effect on bundling 
(possibly several User Message units in same eb:Messaging)

was discussed. Also, the tolerance of different 
options to routing functions not always up-to-date.

While it is reasonable to expect all user messages 
in a bundle to be destined to the same 

MSH, it may be restrictive to rely on the "first eb 
header in the bundle" (as option (a) would require). 

First, an MSH may be the ultimate dstination for 
some User Messages in the bundle, and still an intermediary for others.

Also, using option (b) or (c) allows to be more 
specific as what routing info should be used, in case

there is some uncertainty, e.g. in case no routing 
function exists yet for some recent update. E.g. 

a new eb:ToParty is a spun off of an existing Party 
- e.g. a business unit xyz becomes a separate B2B party, 

while formerly under Party 123).

New purchase orders will be sent for ToParty=xyz, 
and could be given the same ref parameters as for ToParty=123

for proper routing in case the routing function not 
updated yet.

 

- COmment (JD): In case the intermediary must 
understand the eb:Messaging header (as in options (a) or (c))

then it may have to generate an eb:Error (e.g. due 
to failed parsing). 

The reporting of this error may be 
problematic.

An advantage of routing based on ref parameters is 
that this reduces/eliminates the opportunities for eb Errors 

in the intermediary. Else, an advantage of carrying 
reverse routing info (e.g. in eb:ReplyTo, or in ref params)

as in option 5.a below, is that the intermediary 
knows where to report.

 

----------------------- Routing RM signals 
------------------------

 

4. Reliable messaging support:

 

4.1. Routing of RM forward signals (CreateSequence, 
terminateSequence). This will make use of wsa ref parameters

added based on PMode info (like option (b) in 
"Question 3.a" above).

 

4.2. Reverse routing of RM backward signals 
(CreateSequenceResponse, TSR, RM Acks). As long as these

are routed to the same destination, the AcksTo 
element in previous CreateSequence message, will specify

the wsa EPR and proper wsa ref parameters for this 
reverse routing, for all these 
signals.

Should we require that ebMS multihop always use the 
same destination for these response signals,

as the Sending MSH that initiated the forward 
signal (e.g. CS)?

 

- Comment (JD): we still need to consider the case 
where the initial Sender MSH is not addressable:

In such a case, either (a) the endpoint MSH will 
have to use MakeConnection to "pull" these signals,

or (b) these signals could be posted on a Pull 
channel (MPC) witha dummy eb header (see default eb:Service

value, section 5.2.2)

 

-------------------------- Routing of eb Signal Messages 
-----------------------

 

5. Routing of eb Signal Messages: here, only of 
"response" signals: eb:Receipt, eb:Error.

Two major options (5.a or 5.b):

 

5.a: the routing is correlation-driven: at least 
the last intermediary is able to correlate the response message 
with

the related request message based on (a) 
wsa:MessageId and wsa:RelatesTo, (b) based on eb:MessageId and

eb:RefToMessageId or eb:RefToMessageInError, (c) 
based on the use of same (HTTP) connection, when the response

is supposed to be sent synchronously on the last 
hop. 

In all these options, the intermediary must store 
the routing info associated

with the request message, and add it to the 
response header, most likely in form of wsa ref params (not of

dummy eb header). 

The routing info may either come from (a) the 
eb:UserMessage element, or (b) from the wsa ref parameters 

of the Request message (these could contain 
explicit reverse routing info, e.g. "from").

 

- COmment (JD): 5.a option has the drawback of 
altering the message, and weakening security (all headers

supposed to be signed).

 

5.b: the routing is based on wsa ref parameters 
like for RM signals in (4), inserted by the ultimate endpoint MSH

based on (a) (b) eb:ReplyTo EPR content, (b) PMode 
info. 

 

- COmment (JD): In 5.b case, the intermediaries 
remain fully stateless.