inline
-Jacques
From: Sander Fieten
[mailto:]
Sent: Tuesday, November 18, 2008 12:12
AM
To:
Cc:
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 , 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
