[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.18 (ebMS3-Multihop V18-Nov07.doc) uploaded
|
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 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:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]