[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
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:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]