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.