OASIS ebXML Messaging Services TC

V0.18:
- remodeling of section 1.5, especially 1.5.2 and 1.5.3, with missing cases
and new figures.
- some figures migrated from 1.5 to 1.6
-section 1.7 on endpoint requirements, reorganized, with an addition on how
to interpret wsa:ReplyTo (1.7.3).
- edits in 1.8, with main addition 1.8.3 on how to control other aspects of
multihop edges binding (not complete yet)
- also see the proposed introduction of the "I-Cloud" IRI for use in wsa
EPRs, i.e. when the destination URL is unknown, such an IRI would be used
to indicate that routing must rely on ref parameters.

 -- Mr Jacques Durand

The document revision named Multi-hop Section Draft 0.18 (ebMS3-Multihop
V18-Nov07.doc) has been submitted by Mr Jacques Durand to the OASIS ebXML
Messaging Services TC document repository.  This document is revision #16
of ebMS3-Multihop.doc.

Document Description:
Draft of the multi-hop section.
V0.3:
- a few updates in the definition section (editorial)
- added a commented Flow diagram (section 1.7.1) on RM sequence
establishment. To review.
V0.4:
- section 1.5 (Intermediary Role) rewritten, though not complete yet.
(diff with 0.3 visible)
V0,5:
- section 1.5 updated based on feedback and extended for response
messages.
V0.14:
- Section 1.5 redefines multihop MEPs in terms of first hop + last hop. It
does not include the routing inside the I-Cloud which is relevant to the
routing function.
- Section 1.5.4: Two options for multi-hop pulling ... and probably one too
many.... Need to define multihop pulling.
- Section 1.6.3 on routing function has been edited.
- Section 1.8 on PModes has been deeply redesigned based on what was said
prior

V0.6:
- Added text to section 1.5 on streaming and store-and-forward models for
implementing intermediaries
V0.7:
- Changed the text describing the streaming model to include two sub cases,
asynchronous and synchronous streaming.
V0.8:
- a few updates / corrections (diffs visible)
- fleshed out the "routing of Acks" multihop subsection at the
end.
V0.9:
- Updated definition of routing function and mep bridging
- Changes to section on details of the routing function. The changes here
are mostly textual. Changes shouldn't have impact on spec itself.
V0.10:
- Moved section 1.4.3 Endpoints requirements to 1.6 where requirements can
be more explicitly formulated
- Reformatted handling of routing input by intermediary
- New section 1.6 on Endpoints requirements, includes introduction of
RefParam PMode feature
- Added section 1.7 to specify definition of WS-A reference parameter
V0.11:
- Added text to section 1.4.6 on specific MEP bindings for multi-hop
V0.12:
- added missing flow diagrams (not yet fully comented)
- inserted text for Section 1.8.
- added several comments ([jacques]) and complement text (diffs visible)
V0.13:
- more complete draft of the MEP section 1.5, with multihop channel
bindings.
- added a new section on PModes for multihop (1.8)
- minor changes in 1.7
- expanded on the Error handling section (1.4.5)
V0.15:
- Section 1.5 redefines multihop MEPs in terms of first hop + last hop. It
does not include the routing inside the I-Cloud which is relevant to the
routing function.
- Section 1.5.4: Two options for multi-hop pulling ... and probably one too
many.... Need to define multihop pulling.
- Section 1.6.3 on routing function has been edited.
- Section 1.8 on PModes has been deeply redesigned based on what was said
prior
V0.16:
- more complete section 1.8
- figures added in MEP section, explicit model separating ICloud hops from
"peripheral hops".
V0.17:
- sharpening of terminology in earlier sections
- Section 1.5 largely rewritten, with updated figures (for terminology)
- still some clean-up to do in 1.5 and also 1.8
V0.18:
- remodeling of section 1.5, especially 1.5.2 and 1.5.3, with missing cases
and new figures.
- some figures migrated from 1.5 to 1.6
-section 1.7 on endpoint requirements, reorganized, with an addition on how
to interpret wsa:ReplyTo (1.7.3).
- edits in 1.8, with main addition 1.8.3 on how to control other aspects of
multihop edges binding (not complete yet)

View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=29971

Download Document:  
http://www.oasis-open.org/committees/download.php/29971/ebMS3-Multihop%20V18-Nov07.doc

Revision:
This document is revision #16 of ebMS3-Multihop.doc.  The document details
page referenced above will show the complete revision history.


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration

 

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



 

Inline
-Jacques



                                                

					
                                                    

        
                                                
				

                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                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

Jacques,

here are my remarks up to section 1.7.1. 

Regards,
Sander


line 13: 
The new role for MSH's is introduced here and called "intermediairy". There is also a reference to the already existing roles in the core spec, which are "Sending" and "Receiving".     On line 285 where the Intermediary role is further defined the new messaging function is called "Forwarding". Wouldn't it be more appropiate to use this term on line 13 when the intermediary is introduced because an intermediary is an MSH that implements the "forwarding" function?

line 32:
says about endpoint MSH: "it is in general only compliant with the Core ebMS V3 specification". Because of the WS-A requirements that the multi-hop situation imposes on the endpoints this statement might be too strong as there's no need for WS-A support in an MSH to be able to comply with the core spec. 

lines 31-32 and 36-37:
"A multi-hop topology usually comprises Endpoint MSHs on its periphery, although it does not have to: for example, in a ring topology all MSHs are Intermediaries." looks inconsistent with "An Endpoint MSH can not act as an Intermediary MSH" on lines 31-32. 


Section 1.3.1 (lines 43-63):
Are all these assumptions critical to define the topologies of sections 1.3.2 - 1.3.4 ? As far I can judge only the first assumption is important as the topologies only consider ebMS MSH's, i.e. nodes that act on the headers defined in this spec or the core spec. I propose to just have an overview of the [main] topologies and move the assumptions to section 1.4.1. 

line 49: 
The text now states that other types of intermediaries like SOAP intermediaries and http proxies are not required to understand the ebMS headers. But what about the WS-A headers that are required by this specification? Shouldn't it be more general that other intermediairies are intermediaries that do not act on the headers as defined in this specification? This could be done by changing "they are not required to understand any of the ebMS headers" to "they are not required to understand any of the ebMS meta data available in the headers and are not supposed to act on this data."

line 55-56:
I'm not sure about the meaning of this sentence. I assume this means that intermediaries may support pulling by endpoints, right?

line 59-62:
From this assumption I understand that one MSH can act both as an intermediary and endpoint MSH. This conflicts with the statement on line 31-32 that "An Endpoint MSH can not act as an Intermediary MSH". I think there might be use cases where one would like to have an MSH act in both roles, but I'm not sure if the current text allows this. The distinction between P-Mode and routing function make it complex to both roles integrated into one MSH, at least when accessed through one address.

Sections 1.3.2 - 1.3.4 (lines 64-85) :
In these sections addressability is a much used term without a clear definition of what that is. I think here addressability is meant whether the MSH has a publicly known static (is this required to be static?) IP-address or hostname and not about the possibility to identify the endpoint on the ebMS level using the meta data available in the message header.

Section 1.4.2:
I think addressability should be defined explicitly i.e., that it defines the addressability on the transport layer and not the ebMS layer. The endpoint is addressable by the meta data available in the message header, but might not be addressable by an IP address or hostname. 

line 108:
I think "This implies that Intermediaries do not modify ebMS messages" should be "This implies that Intermediaries do not modify messages" as intermediaries shouldn't change any message that is part of a end-to-end conversation.

line 120:
It looks there're some words missing after "and some subset of PModes may need be configured on"

line 176:
I propose to talk about endpoints here like: "Edge hops: controlled by PMode deployed on the connected endpoint MSH"

line 177:
Does (part of) the PMode have to be deployed on the intermediary? Shouldn't the required info not be part of the result of the routing function or is this what you meant here?

line 228:
"This edge-binding applies when both Sender and Receiver endpoints are not addressable". This case can also apply to an addressable Sender.

Section 1.5.2.2
The pulling from the Sender as described here also seems to require pulling by the Receiver because the intermediaries do not generate PullRequest signals. As noted at the end of the sections it is however possible to only pull on the Sender edge hop and use push on the received edge hop. To make this possibility more explicit I propose to use this situation as case 4.

Section 1.5.3.1
Also mention the [common] case where the Sender endpoint uses MEP binding "Two-way / Push-and-Push" and the Responder "Two-way / Pull-and-Push" ?

line 356:
In "... and will pull the reply message over the same ..." I propose to change "pull" to "get" to prevent confusion with pulling messages. 

Would it be usefull to add a remark on end-to-end synchronous communication, like this:
"Although both endpoints in this case use synchronous communication with their respective intermediaries there is no guarantee that the response message is communicated synchronously end-to-end as the I-Cloud hops might use asynchronous communication. When an I-Cloud uses synchronous communication on the I-Cloud hops to enable end-to-end synchronous communication this may be very resource intensive on the intermediaries because of all open connections."

line 526:
I propose to use "Initiating Message" instead of "Request Message". In a two-way MEP the request message is the first ebMS user message sent, but here it is just the first message. Therefore I think it is better to use initiating message instead of request message.


On Nov 11, 2008, at 1:10 , jdurand@us.fujitsu.com wrote:

V0.18:
- remodeling of section 1.5, especially 1.5.2 and 1.5.3, with missing cases
and new figures.
- some figures migrated from 1.5 to 1.6
-section 1.7 on endpoint requirements, reorganized, with an addition on how
to interpret wsa:ReplyTo (1.7.3).
- edits in 1.8, with main addition 1.8.3 on how to control other aspects of
multihop edges binding (not complete yet)
- also see the proposed introduction of the "I-Cloud" IRI for use in wsa
EPRs, i.e. when the destination URL is unknown, such an IRI would be used
to indicate that routing must rely on ref parameters.

 -- Mr Jacques Durand

The document revision named Multi-hop Section Draft 0.18 (ebMS3-Multihop
V18-Nov07.doc) has been submitted by Mr Jacques Durand to the OASIS ebXML
Messaging Services TC document repository.  This document is revision #16
of ebMS3-Multihop.doc.

Document Description:
Draft of the multi-hop section.
V0.3:
- a few updates in the definition section (editorial)
- added a commented Flow diagram (section 1.7.1) on RM sequence
establishment. To review.
V0.4:
- section 1.5 (Intermediary Role) rewritten, though not complete yet.
(diff with 0.3 visible)
V0,5:
- section 1.5 updated based on feedback and extended for response
messages.
V0.14:
- Section 1.5 redefines multihop MEPs in terms of first hop + last hop. It
does not include the routing inside the I-Cloud which is relevant to the
routing function.
- Section 1.5.4: Two options for multi-hop pulling ... and probably one too
many.... Need to define multihop pulling.
- Section 1.6.3 on routing function has been edited.
- Section 1.8 on PModes has been deeply redesigned based on what was said
prior

V0.6:
- Added text to section 1.5 on streaming and store-and-forward models for
implementing intermediaries
V0.7:
- Changed the text describing the streaming model to include two sub cases,
asynchronous and synchronous streaming.
V0.8:
- a few updates / corrections (diffs visible)
- fleshed out the "routing of Acks" multihop subsection at the
end.
V0.9:
- Updated definition of routing function and mep bridging
- Changes to section on details of the routing function. The changes here
are mostly textual. Changes shouldn't have impact on spec itself.
V0.10:
- Moved section 1.4.3 Endpoints requirements to 1.6 where requirements can
be more explicitly formulated
- Reformatted handling of routing input by intermediary
- New section 1.6 on Endpoints requirements, includes introduction of
RefParam PMode feature
- Added section 1.7 to specify definition of WS-A reference parameter
V0.11:
- Added text to section 1.4.6 on specific MEP bindings for multi-hop
V0.12:
- added missing flow diagrams (not yet fully comented)
- inserted text for Section 1.8.
- added several comments ([jacques]) and complement text (diffs visible)
V0.13:
- more complete draft of the MEP section 1.5, with multihop channel
bindings.
- added a new section on PModes for multihop (1.8)
- minor changes in 1.7
- expanded on the Error handling section (1.4.5)
V0.15:
- Section 1.5 redefines multihop MEPs in terms of first hop + last hop. It
does not include the routing inside the I-Cloud which is relevant to the
routing function.
- Section 1.5.4: Two options for multi-hop pulling ... and probably one too
many.... Need to define multihop pulling.
- Section 1.6.3 on routing function has been edited.
- Section 1.8 on PModes has been deeply redesigned based on what was said
prior
V0.16:
- more complete section 1.8
- figures added in MEP section, explicit model separating ICloud hops from
"peripheral hops".
V0.17:
- sharpening of terminology in earlier sections
- Section 1.5 largely rewritten, with updated figures (for terminology)
- still some clean-up to do in 1.5 and also 1.8
V0.18:
- remodeling of section 1.5, especially 1.5.2 and 1.5.3, with missing cases
and new figures.
- some figures migrated from 1.5 to 1.6
-section 1.7 on endpoint requirements, reorganized, with an addition on how
to interpret wsa:ReplyTo (1.7.3).
- edits in 1.8, with main addition 1.8.3 on how to control other aspects of
multihop edges binding (not complete yet)

View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=29971

Download Document:  
http://www.oasis-open.org/committees/download.php/29971/ebMS3-Multihop%20V18-Nov07.doc

Revision:
This document is revision #16 of ebMS3-Multihop.doc.  The document details
page referenced above will show the complete revision history.


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration

inline 
 
-Jacques




From: Sander Fieten 
[mailto:sander@fieten-it.com]
Sent: Tuesday, November 18, 2008 12:12 
AM
To: ebxml-msg@lists.oasis-open.org
Cc: 
ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Groups - 
Multi-hop Section Draft 0.18 (ebMS3-Multihop V18-Nov07.doc) 
uploaded


Jacques, 


here are my remarks up to section 1.7.1. 


Regards,
Sander




line 13: 
The new role for MSH's is introduced here and called "intermediairy". There 
is also a reference to the already existing roles in the core spec, which are 
"Sending" and "Receiving".     On line 285 where the Intermediary role 
is further defined the new messaging function is called "Forwarding". Wouldn't 
it be more appropiate to use this term on line 13 when the intermediary is 
introduced because an intermediary is an MSH that implements the "forwarding" 
function? 
 
OK 


line 32:
says about endpoint MSH: "it is in general only compliant with the Core 
ebMS V3 specification". Because of the WS-A requirements that the multi-hop 
situation imposes on the endpoints this statement might be too strong as there's 
no need for WS-A support in an MSH to be able to comply with the core 
spec. 
 
OK
 


lines 31-32 and 36-37:
"A multi-hop topology usually comprises Endpoint MSHs on its periphery, 
although it does not have to: for example, in a ring topology all MSHs are 
Intermediaries." looks inconsistent with "An Endpoint MSH can not act as an 
Intermediary MSH" on lines 31-32. 


O K 

Section 1.3.1 (lines 43-63):
Are all these assumptions critical to define the topologies of sections 
1.3.2 - 1.3.4 ? As far I can judge only the first assumption is important as the 
topologies only consider ebMS MSH's, i.e. nodes that act on the headers defined 
in this spec or the core spec. I propose to just have an overview of the [main] 
topologies and move the assumptions to section 1.4.1.  
 
modified 1.3.1 and put it at the end of 1.3. Should not be in 1.4 because 
these assumptions are not all requirements. May be just there for convenience of 
the specification. 



line 49: 
The text now states that other types of intermediaries like SOAP 
intermediaries and http proxies are not required to understand the ebMS headers. 
But what about the WS-A headers that are required by this specification? 
Shouldn't it be more general that other intermediairies are intermediaries that 
do not act on the headers as defined in this specification? This could be done 
by changing "they are not required to understand any of the ebMS headers" to 
"they are not required to understand any of the ebMS meta data available in the 
headers and are not supposed to act on this data." 
 
OK 


line 55-56:
I'm not sure about the meaning of this sentence. I assume this means that 
intermediaries may support pulling by endpoints, right?
 
removed


line 59-62:
From this assumption I understand that one MSH can act both as an 
intermediary and endpoint MSH. This conflicts with the statement on line 31-32 
that "An Endpoint MSH can not act as an Intermediary MSH". I think there might 
be use cases where one would like to have an MSH act in both roles, but I'm not 
sure if the current text allows this.  
 
fixed
 
 The distinction between P-Mode 
and routing function make it complex to both roles integrated into one MSH, at 
least when accessed through one address.
 
I 
tried to nuance this distinction in update on 1.5.1.


Sections 1.3.2 - 1.3.4 (lines 64-85) :
In these sections addressability is a much used term without a clear 
definition of what that is. I think here addressability is meant whether the MSH 
has a publicly known static (is this required to be static?) IP-address or 
hostname and not about the possibility to identify the endpoint on the ebMS 
level using the meta data available in the message header.
 
removed.


Section 1.4.2:
I think addressability should be defined explicitly i.e., that it defines 
the addressability on the transport layer and not the ebMS layer. The endpoint 
is addressable by the meta data available in the message header, but might not 
be addressable by an IP address or hostname.  
 
added 
a definition in 1.4.2 


line 108:
I think "This implies that Intermediaries do not modify ebMS messages" 
should be "This implies that Intermediaries do not modify messages" as 
intermediaries shouldn't change any message that is part of a end-to-end 
conversation.
 
OK


line 120:
It looks there're some words missing after "and some subset of PModes may 
need be configured on"
 
fixed


line 176:
I propose to talk about endpoints here like: "Edge hops: 
controlled by PMode deployed on the connected endpoint MSH"
 
OK


line 177:
Does (part of) the PMode have to be deployed on the intermediary? Shouldn't 
the required info not be part of the result of the routing function or is this 
what you meant here?
 
removed.
 


line 228:
"This edge-binding applies when both Sender and Receiver endpoints are not 
addressable". This case can also apply to an addressable Sender.
 
fixed.
 


Section 1.5.2.2
The pulling from the Sender as described here also seems to require pulling 
by the Receiver because the intermediaries do not generate PullRequest signals. 
As noted at the end of the sections it is however possible to only pull on the 
Sender edge hop and use push on the received edge hop. To make this possibility 
more explicit I propose to use this situation as case 4. 
 
In described case 4, Intermediaries can be configured to generate 
PullRequest signals: this is part of a forwarding mode... The only thnig they never generate, are User Messages (and 
eb:Receipts). They also can generate eb:Error 
meessages.
Adding 
a Case 5 for what you describe above.


Section 1.5.3.1
Also mention the [common] case where the Sender endpoint uses MEP binding 
"Two-way / Push-and-Push" and the Responder "Two-way / Pull-and-Push" ?
 
Added 
mention of the case.
 


line 356:
In "... and will pull the reply message over the same ..." 
I propose to change "pull" to "get" to prevent confusion with pulling 
messages. 
 
OK


Would it be usefull to add a remark on end-to-end synchronous 
communication, like this:
"Although both endpoints in this case use synchronous communication with 
their respective intermediaries there is no guarantee that the response message 
is communicated synchronously end-to-end as the I-Cloud hops might use 
asynchronous communication. When an I-Cloud uses synchronous communication on 
the I-Cloud hops to enable end-to-end synchronous communication this may be very 
resource intensive on the intermediaries because of all open connections."
 
OK


line 526:
I propose to use "Initiating Message" instead of "Request Message". In a 
two-way MEP the request message is the first ebMS user message sent, but here it 
is just the first message. Therefore I think it is better to use initiating 
message instead of request message.
 
OK





On Nov 11, 2008, at 1:10 , jdurand@us.fujitsu.com wrote:



  
V0.18:
- remodeling of section 1.5, especially 1.5.2 and 1.5.3, with 
  missing cases
and new figures.
- some figures migrated from 1.5 to 
  1.6
-section 1.7 on endpoint requirements, reorganized, with an addition on 
  how
to interpret wsa:ReplyTo (1.7.3).
- edits in 1.8, with main addition 
  1.8.3 on how to control other aspects of
multihop edges binding (not 
  complete yet)
- also see the proposed introduction of the "I-Cloud" IRI for 
  use in wsa
EPRs, i.e. when the destination URL is unknown, such an IRI 
  would be used
to indicate that routing must rely on ref 
  parameters.

-- Mr Jacques Durand

The document revision named 
  Multi-hop Section Draft 0.18 (ebMS3-Multihop
V18-Nov07.doc) has been 
  submitted by Mr Jacques Durand to the OASIS ebXML
Messaging Services TC 
  document repository.  This document is revision #16
of 
  ebMS3-Multihop.doc.

Document Description:
Draft of the multi-hop 
  section.
V0.3:
- a few updates in the definition section 
  (editorial)
- added a commented Flow diagram (section 1.7.1) on RM 
  sequence
establishment. To review.
V0.4:
- section 1.5 (Intermediary 
  Role) rewritten, though not complete yet.
(diff with 0.3 
  visible)
V0,5:
- section 1.5 updated based on feedback and extended for 
  response
messages.
V0.14:
- Section 1.5 redefines multihop MEPs in 
  terms of first hop + last hop. It
does not include the routing inside the 
  I-Cloud which is relevant to the
routing function.
- Section 1.5.4: Two 
  options for multi-hop pulling ... and probably one too
many.... Need to 
  define multihop pulling.
- Section 1.6.3 on routing function has been 
  edited.
- Section 1.8 on PModes has been deeply redesigned based on what 
  was said
prior

V0.6:
- Added text to section 1.5 on streaming and 
  store-and-forward models for
implementing intermediaries
V0.7:
- 
  Changed the text describing the streaming model to include two sub 
  cases,
asynchronous and synchronous streaming.
V0.8:
- a few updates 
  / corrections (diffs visible)
- fleshed out the "routing of 
  Acks" multihop subsection at the
end.
V0.9:
- Updated 
  definition of routing function and mep bridging
- Changes to section on 
  details of the routing function. The changes here
are mostly textual. 
  Changes shouldn't have impact on spec itself.
V0.10:
- Moved section 
  1.4.3 Endpoints requirements to 1.6 where requirements can
be more 
  explicitly formulated
- Reformatted handling of routing input by 
  intermediary
- New section 1.6 on Endpoints requirements, includes 
  introduction of
RefParam PMode feature
- Added section 1.7 to specify 
  definition of WS-A reference parameter
V0.11:
- Added text to section 
  1.4.6 on specific MEP bindings for multi-hop
V0.12:
- added missing flow 
  diagrams (not yet fully comented)
- inserted text for Section 1.8.
- 
  added several comments ([jacques]) and complement text (diffs 
  visible)
V0.13:
- more complete draft of the MEP section 1.5, with 
  multihop channel
bindings.
- added a new section on PModes for multihop 
  (1.8)
- minor changes in 1.7
- expanded on the Error handling section 
  (1.4.5)
V0.15:
- Section 1.5 redefines multihop MEPs in terms of first 
  hop + last hop. It
does not include the routing inside the I-Cloud which is 
  relevant to the
routing function.
- Section 1.5.4: Two options for 
  multi-hop pulling ... and probably one too
many.... Need to define multihop 
  pulling.
- Section 1.6.3 on routing function has been edited.
- Section 
  1.8 on PModes has been deeply redesigned based on what was 
  said
prior
V0.16:
- more complete section 1.8
- figures added in 
  MEP section, explicit model separating ICloud hops 
  from
"peripheral hops".
V0.17:
- sharpening of 
  terminology in earlier sections
- Section 1.5 largely rewritten, with 
  updated figures (for terminology)
- still some clean-up to do in 1.5 and 
  also 1.8
V0.18:
- remodeling of section 1.5, especially 1.5.2 and 1.5.3, 
  with missing cases
and new figures.
- some figures migrated from 1.5 to 
  1.6
-section 1.7 on endpoint requirements, reorganized, with an addition on 
  how
to interpret wsa:ReplyTo (1.7.3).
- edits in 1.8, with main addition 
  1.8.3 on how to control other aspects of
multihop edges binding (not 
  complete yet)

View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=29971

Download 
  Document: 
   
http://www.oasis-open.org/committees/download.php/29971/ebMS3-Multihop%20V18-Nov07.doc

Revision:
This 
  document is revision #16 of ebMS3-Multihop.doc.  The document 
  details
page referenced above will show the complete revision 
  history.


PLEASE NOTE:  If the above links do not work for you, 
  your email application
may be breaking the link into two pieces.  You 
  may be able to copy and paste
the entire link address into the address 
  field of your web browser.

-OASIS Open 
Administration