OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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.

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?

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. 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?

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.




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?document_id=28566
>
> Download Document:
> http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/28566/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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]