RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.18 (ebMS3-Multihop V18-Nov07.doc) uploaded

["Pim van der Eijk" <pvde@sonnenglanz.net>]

Hello,

Here are some comments on this draft, up to and including section 1.5. 
(Line numbers refer to "Final" view, not "Final Showing Markup").

General:  
This document is not about just any type of multihop messaging as we
focussed on a specific type of multihop messaging: "transparent" multihop. I
think we should be clearer about this, e.g. have a more specific title (and
leave open the option of future additional profiles that may be designed for
other requirements so that may not be "transparent"). Is there any reason
why section 1.4 (which roughly describes these requirements) does not use
the term "transparent"?  

General: 
The document starts at 1.1 and ends at 1.11.  I don't think there will be a
second, third chapter at some point in this profile?  If not, we should
reorganize the text in a smaller number of main chapters.

General: 
People asked for some text/examples about intermediary routing to explain
the benefits of intermediaries and I provided some text some time ago, but
it was never discussed.  It is illustrative, not part of the technical
specification, but could still add value as an appendix. 
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?document
_id=28981 

Line 4-9, alludes to "additional services" that intermediaries can provide.
The document talks about routing later, but other such services could be
referenced, such as business activity monitoring or message archiving.
Again, not necessary for the technical spec, but it helps explain the value
of multihop. 

Line 30, "An Endpoint MSH can not act as an Intermediary MSH":  but some
MSHs will be endpoints for some messages and intermediaries for others
(discussed in 58-60).  The decision whether to forward (to next MSH) or
deliver (locally) is a kind of "routing" function in itself. Similarly, some
nodes could be "edge hops" for some messages and I-Cloud hops for others.
The original goal for "transparency" was that an MSH does not need to know
if the next hop it is talking to is an endpoint or another intermediary, so
that networks can be reorganized without impacting the endpoints.

Line 175-178, Pmodes versus routing function.   I'm still not sure this
distinction is the best terminology or the best way to describe
configuration in a multihop network.   Any message exchange involves a huge
number of parameters, some of which are only relevant between adjacent nodes
(such as MEP Binding, URL, SSL) and others are end-to-end parameters related
to partner agreements / service contracts (such as MEP, service, action,
security, reliability etc.).  With multihop, the next-hop parameters are no
longer "partner agreement" parameters.  Instead, these next-hop parameters
apply to any hop, whether between end points in point-to-point, between
endpoints and edge intermediaries, or between intermediaries not connected
directly to endpoints.  

Section 1.5.2.1

The way you've described the MEP bindings and MEP bridging is an improvement
and more similar to the way I've described this over a year ago in the
requirements document posted at:
http://lists.oasis-open.org/archives/ebxml-msg-comment/200709/msg00000.html
A difference is that that description also differentiated the cases based on
whether the intermediaries are (the I-Cloud is) "synchronous" (Dale
preferred "waiting") or not. 

Line 216-225:  Case 1  can then be split in two cases:
Sub-case 1 (Push, Sync, Push): with synchronous/waiting intermediaries, the
HTTP back-channel can be used to route back protocol responses such as
eb:Receipts, eb:Errors and WS-ReliableMessaging responses. 

Sub-case 2 (Push, ASync, Push): with asynchronous intermediaries, we have
the same options/questions as for business responses in Two Way MEPs for
reverse routing eb:Receipts and similar messages.  

Question: how does a non-addressable MSH that only Sends (One Way Push) via
an asynchronous intermediary receive Signals sent by the Receiver?   The
only option would be to use Pull.  This requires an errata for Core v3.0 to
allow Pulling of Signals.  If we do that, what is the MPC on the Edge
Intermediary that the MSH pulls from?  It could be the default MPC, or do we
want to define (as part of this profile) a dedicated special MPC that
intermediaries provide just for pulling Signals?  Or use the MPC name used
for the user message?

Line 227: Case 2, this inherently assumes Asynchronous intermediaries.

Section 1.5.2.2

In my earlier terminology, Case 3 would be called "Pull, IntSync, Pull" and
Case 4 would be "Pull, IntAsync, Pull".

Line 284-287:
This would be "Pull, IntAsync, Push".

Section 1.5.3.1 

Case 1: Push-and-Push 2xIntermediary  Push-and-Push  

This actually covers four sub-cases: the intermediary can be synchronous or
asynchronous in either of the two legs.
The main impact is Signal Messages and WS-ReliableMessaging response
messages.

Case 2: Push-and-Pull, Pull-and-Push

Here the intermediary is always asynchronous.

Section 1.5.3.2 

This covers the cases where the last hop is synchronous and the first is
synchronous or asynchronous.  

Case 3: Push-and-Pull, IntAsync, Sync

Case 4: Sync, IntSync, Sync

Some other options with a synchronous receiver not in your description yet:

Push-and-Push, IntAsync, Sync
Pull-and-Push, IntAsync, Sync
Pull-and-Pull, IntAsync, Sync

There is another set of options, where the first hop is synchronous and the
last is not.  In this scenario, the first intermediary must keep the
connection open and wait for a response message to arrive through the
I-Cloud.  This does not require that all other hops are synchronous
("waiting"), only that the first intermediary is able to correlate a
response arriving from the Receiver and forward these on backchannel of the
incoming connection.  This obviously assumes such a response arrives within
the timeout interval of the first connection. I agree that this is
nice-to-have but synchronous clients for read-only or idempotent operations
(see 
http://lists.oasis-open.org/archives/ebxml-msg/200807/msg00002.html) are
very popular.

Pim