OASIS ebXML Messaging Services TC

  • 1.  Groups - Multi-hop Section Draft 0.18 (ebMS3-Multihop V18-Nov07.doc) uploaded

    Posted 11-11-2008 00:11
    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
    


  • 2.  RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.18 (ebMS3-Multihop V18-Nov07.doc) uploaded

    Posted 11-13-2008 16:26
     
    
    Hello,
    
    Here are some comments on this draft, up to and including section 1.5. 
    (Line numbers refer to "Final" view, not "Final Showing Markup").
    
    General:  
    This document is not about just any type of multihop messaging as we
    focussed on a specific type of multihop messaging: "transparent" multihop. I
    think we should be clearer about this, e.g. have a more specific title (and
    leave open the option of future additional profiles that may be designed for
    other requirements so that may not be "transparent"). Is there any reason
    why section 1.4 (which roughly describes these requirements) does not use
    the term "transparent"?  
    
    General: 
    The document starts at 1.1 and ends at 1.11.  I don't think there will be a
    second, third chapter at some point in this profile?  If not, we should
    reorganize the text in a smaller number of main chapters.
    
    General: 
    People asked for some text/examples about intermediary routing to explain
    the benefits of intermediaries and I provided some text some time ago, but
    it was never discussed.  It is illustrative, not part of the technical
    specification, but could still add value as an appendix. 
    http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?document
    _id=28981 
    
    Line 4-9, alludes to "additional services" that intermediaries can provide.
    The document talks about routing later, but other such services could be
    referenced, such as business activity monitoring or message archiving.
    Again, not necessary for the technical spec, but it helps explain the value
    of multihop. 
    
    Line 30, "An Endpoint MSH can not act as an Intermediary MSH":  but some
    MSHs will be endpoints for some messages and intermediaries for others
    (discussed in 58-60).  The decision whether to forward (to next MSH) or
    deliver (locally) is a kind of "routing" function in itself. Similarly, some
    nodes could be "edge hops" for some messages and I-Cloud hops for others.
    The original goal for "transparency" was that an MSH does not need to know
    if the next hop it is talking to is an endpoint or another intermediary, so
    that networks can be reorganized without impacting the endpoints.
    
    Line 175-178, Pmodes versus routing function.   I'm still not sure this
    distinction is the best terminology or the best way to describe
    configuration in a multihop network.   Any message exchange involves a huge
    number of parameters, some of which are only relevant between adjacent nodes
    (such as MEP Binding, URL, SSL) and others are end-to-end parameters related
    to partner agreements / service contracts (such as MEP, service, action,
    security, reliability etc.).  With multihop, the next-hop parameters are no
    longer "partner agreement" parameters.  Instead, these next-hop parameters
    apply to any hop, whether between end points in point-to-point, between
    endpoints and edge intermediaries, or between intermediaries not connected
    directly to endpoints.  
    
    Section 1.5.2.1
    
    The way you've described the MEP bindings and MEP bridging is an improvement
    and more similar to the way I've described this over a year ago in the
    requirements document posted at:
    http://lists.oasis-open.org/archives/ebxml-msg-comment/200709/msg00000.html
    A difference is that that description also differentiated the cases based on
    whether the intermediaries are (the I-Cloud is) "synchronous" (Dale
    preferred "waiting") or not. 
    
    Line 216-225:  Case 1  can then be split in two cases:
    Sub-case 1 (Push, Sync, Push): with synchronous/waiting intermediaries, the
    HTTP back-channel can be used to route back protocol responses such as
    eb:Receipts, eb:Errors and WS-ReliableMessaging responses. 
    
    Sub-case 2 (Push, ASync, Push): with asynchronous intermediaries, we have
    the same options/questions as for business responses in Two Way MEPs for
    reverse routing eb:Receipts and similar messages.  
    
    Question: how does a non-addressable MSH that only Sends (One Way Push) via
    an asynchronous intermediary receive Signals sent by the Receiver?   The
    only option would be to use Pull.  This requires an errata for Core v3.0 to
    allow Pulling of Signals.  If we do that, what is the MPC on the Edge
    Intermediary that the MSH pulls from?  It could be the default MPC, or do we
    want to define (as part of this profile) a dedicated special MPC that
    intermediaries provide just for pulling Signals?  Or use the MPC name used
    for the user message?
    
    Line 227: Case 2, this inherently assumes Asynchronous intermediaries.
    
    Section 1.5.2.2
    
    In my earlier terminology, Case 3 would be called "Pull, IntSync, Pull" and
    Case 4 would be "Pull, IntAsync, Pull".
    
    Line 284-287:
    This would be "Pull, IntAsync, Push".
    
    Section 1.5.3.1 
    
    Case 1: Push-and-Push 2xIntermediary  Push-and-Push  
    
    This actually covers four sub-cases: the intermediary can be synchronous or
    asynchronous in either of the two legs.
    The main impact is Signal Messages and WS-ReliableMessaging response
    messages.
    
    Case 2: Push-and-Pull, Pull-and-Push
    
    Here the intermediary is always asynchronous.
    
    Section 1.5.3.2 
    
    This covers the cases where the last hop is synchronous and the first is
    synchronous or asynchronous.  
    
    Case 3: Push-and-Pull, IntAsync, Sync
    
    Case 4: Sync, IntSync, Sync
    
    Some other options with a synchronous receiver not in your description yet:
    
    Push-and-Push, IntAsync, Sync
    Pull-and-Push, IntAsync, Sync
    Pull-and-Pull, IntAsync, Sync
    
    There is another set of options, where the first hop is synchronous and the
    last is not.  In this scenario, the first intermediary must keep the
    connection open and wait for a response message to arrive through the
    I-Cloud.  This does not require that all other hops are synchronous
    ("waiting"), only that the first intermediary is able to correlate a
    response arriving from the Receiver and forward these on backchannel of the
    incoming connection.  This obviously assumes such a response arrives within
    the timeout interval of the first connection. I agree that this is
    nice-to-have but synchronous clients for read-only or idempotent operations
    (see 
    http://lists.oasis-open.org/archives/ebxml-msg/200807/msg00002.html) are
    very popular.
    
    Pim
    
    
    
     
    
    


  • 3.  RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.18 (ebMS3-Multihop V18-Nov07.doc) uploaded

    Posted 11-19-2008 04:35
    
    
    
    
    

    Inline
    -Jacques



    mailto:pvde@sonnenglanz.net]
    Sent: Thursday, November 13, 2008 8:26 AM
    To: ebxml-msg@lists.oasis-open.org
    Subject: RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.18 (ebMS3-Multihop V18-Nov07.doc) uploaded



    Hello,

    Here are some comments on this draft, up to and including section 1.5.
    (Line numbers refer to "Final" view, not "Final Showing Markup").

    General: 
    This document is not about just any type of multihop messaging as we focussed on a specific type of multihop messaging: "transparent" multihop. I think we should be clearer about this, e.g. have a more specific title (and leave open the option of future additional profiles that may be designed for other requirements so that may not be "transparent"). Is there any reason why section 1.4 (which roughly describes these requirements) does not use the term "transparent"? 

    added this in "Assumptions" and also mentioned in 1.4.1.


    General:
    The document starts at 1.1 and ends at 1.11.  I don't think there will be a second, third chapter at some point in this profile?  If not, we should reorganize the text in a smaller number of main chapters.

    Right - for next revision...

     


    General:
    People asked for some text/examples about intermediary routing to explain the benefits of intermediaries and I provided some text some time ago, but it was never discussed.  It is illustrative, not part of the technical specification, but could still add value as an appendix.
    http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?document
    _id=28981

    Line 4-9, alludes to "additional services" that intermediaries can provide.
    The document talks about routing later, but other such services could be referenced, such as business activity monitoring or message archiving.
    Again, not necessary for the technical spec, but it helps explain the value of multihop.

    will look into this.

     
     


    Line 30, "An Endpoint MSH can not act as an Intermediary MSH":  but some MSHs will be endpoints for some messages and intermediaries for others (discussed in 58-60).  The decision whether to forward (to next MSH) or deliver (locally) is a kind of "routing" function in itself. Similarly, some nodes could be "edge hops" for some messages and I-Cloud hops for others.
    The original goal for "transparency" was that an MSH does not need to know if the next hop it is talking to is an endpoint or another intermediary, so that networks can be reorganized without impacting the endpoints.

    Right - improved on this new update.


    Line 175-178, Pmodes versus routing function.   I'm still not sure this
    distinction is the best terminology or the best way to describe
    configuration in a multihop network.   Any message exchange involves a huge
    number of parameters, some of which are only relevant between adjacent nodes (such as MEP Binding, URL, SSL) and others are end-to-end parameters related to partner agreements / service contracts (such as MEP, service, action, security, reliability etc.).  With multihop, the next-hop parameters are no longer "partner agreement" parameters.  Instead, these next-hop parameters apply to any hop, whether between end points in point-to-point, between endpoints and edge intermediaries, or between intermediaries not connected directly to endpoints. 

     

    Do the changes in this new update help this?

     

    Will look into the remaining comments for the next rev. I believe several of tehse are addressed in this new update I just posted, answering comments from Sander.

    -Jacques

    Section 1.5.2.1

    The way you've described the MEP bindings and MEP bridging is an improvement and more similar to the way I've described this over a year ago in the requirements document posted at:
    http://lists.oasis-open.org/archives/ebxml-msg-comment/200709/msg00000.html
    A difference is that that description also differentiated the cases based on whether the intermediaries are (the I-Cloud is) "synchronous" (Dale preferred "waiting") or not.

    Line 216-225:  Case 1  can then be split in two cases:
    Sub-case 1 (Push, Sync, Push): with synchronous/waiting intermediaries, the HTTP back-channel can be used to route back protocol responses such as eb:Receipts, eb:Errors and WS-ReliableMessaging responses.

    Sub-case 2 (Push, ASync, Push): with asynchronous intermediaries, we have the same options/questions as for business responses in Two Way MEPs for reverse routing eb:Receipts and similar messages. 

    Question: how does a non-addressable MSH that only Sends (One Way Push) via
    an asynchronous intermediary receive Signals sent by the Receiver?   The
    only option would be to use Pull.  This requires an errata for Core v3.0 to allow Pulling of Signals.  If we do that, what is the MPC on the Edge Intermediary that the MSH pulls from?  It could be the default MPC, or do we want to define (as part of this profile) a dedicated special MPC that intermediaries provide just for pulling Signals?  Or use the MPC name used for the user message?

    Line 227: Case 2, this inherently assumes Asynchronous intermediaries.

    Section 1.5.2.2

    In my earlier terminology, Case 3 would be called "Pull, IntSync, Pull" and Case 4 would be "Pull, IntAsync, Pull".

    Line 284-287:
    This would be "Pull, IntAsync, Push".

    Section 1.5.3.1

    Case 1: Push-and-Push 2xIntermediary  Push-and-Push 

    This actually covers four sub-cases: the intermediary can be synchronous or asynchronous in either of the two legs.
    The main impact is Signal Messages and WS-ReliableMessaging response messages.

    Case 2: Push-and-Pull, Pull-and-Push

    Here the intermediary is always asynchronous.

    Section 1.5.3.2

    This covers the cases where the last hop is synchronous and the first is synchronous or asynchronous. 

    Case 3: Push-and-Pull, IntAsync, Sync

    Case 4: Sync, IntSync, Sync

    Some other options with a synchronous receiver not in your description yet:

    Push-and-Push, IntAsync, Sync
    Pull-and-Push, IntAsync, Sync
    Pull-and-Pull, IntAsync, Sync

    There is another set of options, where the first hop is synchronous and the last is not.  In this scenario, the first intermediary must keep the connection open and wait for a response message to arrive through the I-Cloud.  This does not require that all other hops are synchronous ("waiting"), only that the first intermediary is able to correlate a response arriving from the Receiver and forward these on backchannel of the incoming connection.  This obviously assumes such a response arrives within the timeout interval of the first connection. I agree that this is nice-to-have but synchronous clients for read-only or idempotent operations (see
    http://lists.oasis-open.org/archives/ebxml-msg/200807/msg00002.html) are very popular.

    Pim






    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



  • 4.  Re: [ebxml-msg] Groups - Multi-hop Section Draft 0.18 (ebMS3-Multihop V18-Nov07.doc) uploaded

    Posted 11-18-2008 08:12
    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:

    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



  • 5.  RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.18 (ebMS3-Multihop V18-Nov07.doc) uploaded

    Posted 11-19-2008 04:26
    
    
    
    
    
    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

    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 , jdurand@us.fujitsu.com 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