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

Inline
-Jacques

-----Original Message-----
From: Pim van der Eijk [mailto:]
Sent: 
Thursday, November 13, 2008 8:26 AM
To: 

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