Multihop MOU

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

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.