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

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

Inline
-Jacques

-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Thursday, November 13, 2008 8:26 AM
To: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.18 (ebMS3-Multihop V18-Nov07.doc) uploaded



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"? 

added this in "Assumptions" and also mentioned in 1.4.1.

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.

Right - for next revision...

 

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.

will look into this.

 

 

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.

Right - improved on this new update.

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. 

 

Do the changes in this new update help this?

 

Will look into the remaining comments for the next rev. I believe several of tehse are addressed in this new update I just posted, answering comments from Sander.

-Jacques

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






---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php