RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.4 (ebMS3-Multihop V04.doc) uploaded

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

Inline <JD>

-----Original Message-----
From: Sander Fieten [mailto:sander@fieten-it.com]
Sent: Wednesday, June 18, 2008 1:10 PM
To: Durand, Jacques R.
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Groups - Multi-hop Section Draft 0.4 (ebMS3-Multihop V04.doc) uploaded

Jacques,

below are my comments on the new text.

Sander


Line 138-143:
In this paragraph you define the forwarding function in terms of MSH roles as defined in the core spec and state that an intermediary acts both as a sending and as a receiving MSH. The core spec states that an MSH acting in the sending role supports the abstract operations Submit, Send and Notify and the receiving role the operations Receive, Notify and Deliver. Because the intermediary isn't bound to a Consumer, like endpoint MSH's, there seems to be no need to support all these abstract operations. The only operations an intermediary will support are Receive, Notify and Send. So I would think we should define the intermediary as a separate role with support for these three abstract operations.

<JD> Right.

Is it an idea to define MEP bridging, i.e. using different MEP for the Receive and Send operation, as a separate function of an intermediary?

<JD> OK.

Line 145-148:
As I wrote before I would favor the label "address information" for the information contained in the message that defines the destination of the message and use "routing information" as the information that is configured in the intermediary and that defines a mapping from an address to a next hop.

<JD> how about:
- information contained in the message = "routing input" (since it is what will be fed to the routing function configured in the Intermediary)
- information that is configured in the intermediary = "routing rules" (a set of these defines the routing function. This name allows to break it up in smaller parts - the rules, that may need to be updated independently. Also subparts of the Input - Service, Action, ToParty... - will be used by different rules.)

Otherwise address information is confusing: the routing input might be very remotely related to an address, e.g. in some Intermediary, could just be "Service/Action" value. Hardly address information (the address information is actually what teh routing function is generating).

 I feel that the difference between these two types of information is made clearer, but it's more a matter of personal taste.

On line 146 however it is stated that different parts of the ebms header are used by intermediaries. Shouldn't that be different part of the ebms message as routing information can be in the ebms header but also in WS-A headers?

<JD> not necessarily: you could have Intermediary X that uses ToParty info, then Intermediary Y that uses Service/Action (for the same party). Both are present in eb:UserMessage element, regardless if this element is in eb:Messaging or in a wsa ref parameter header.

Line 155-213 Details of the Routing Function:
I still think that using the same (named) element in both the ebMS message and the WS-A header is confusing, certainly because the WS-A header will be attached to non ebMS user messages. Using eb:UserMessage leads to non ebMS user messages and even non ebMS messages containing an eb:UserMessage element.

<JD> this is mostly for parsing convenience: ideally the routing function (routing rules) should use the same element  as "routing input" regardless how it is packaged in the message (as an wsa ref parameter or as an eb:Messaging child). I think in our case its OK that non-ebMS messages use such an element: after all, these non-ebms messages are still candidate for "ebMS routing": the presence of an ebms-namespaced element is what qualifies them for ebms (intermediary) processing. It is actually expected that some app-dependent namespaces be found in ref parameters. See example in http://www.w3.org/TR/ws-addr-soap :

<wsa:EndpointReference
     ...     xmlns:fabrikam="http://example.com/fabrikam"
     >
   <wsa:Address>http://example.com/fabrikam/acct</wsa:Address>
   <wsa:Metadata>
       <wsaw:InterfaceName>fabrikam:Inventory</wsaw:InterfaceName>
   </wsa:Metadata>
   <wsa:ReferenceParameters>
       <fabrikam:CustomerKey>123456789</fabrikam:CustomerKey>
       <fabrikam:ShoppingCart>ABCDEFG</fabrikam:ShoppingCart>
   </wsa:ReferenceParameters>
</wsa:EndpointReference>

On 17 jun 2008, at 09:01, jdurand@us.fujitsu.com wrote:

> V0.4: incremental update from V0.3.
> - section 1.5 (Intermediary Role) rewritten, though not complete yet.
> (diff
> with 0.3 visible). For review.
>
>
> -- Mr Jacques Durand
>
> The document revision named Multi-hop Section Draft 0.4 (ebMS3-
> Multihop
> V04.doc) has been submitted by Mr Jacques Durand to the OASIS ebXML
> Messaging Services TC document repository.  This document is revision
> #2 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)
>
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?do
> cument_id=28566
>
> Download Document:
> http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/28
> 566/ebMS3-Multihop%20V04.doc
>
> Revision:
> This document is revision #2 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