OASIS ebXML Messaging Services TC

 View Only
  • 1.  Groups - Multi-hop Section Draft 0.13 (ebMS3-Multihop V13-JD.doc) uploaded

    Posted 09-24-2008 04:23
    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)
    
     -- Mr Jacques Durand
    
    The document revision named Multi-hop Section Draft 0.13 (ebMS3-Multihop
    V13-JD.doc) has been submitted by Mr Jacques Durand to the OASIS ebXML
    Messaging Services TC document repository.  This document is revision #11
    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.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)
    
    View Document Details:
    http://www.oasis-open.org/committees/download.php?document_id=29435
    
    Download Document:  
    http://www.oasis-open.org/committees/download.php/29435/ebMS3-Multihop%20V13-JD.doc
    
    Revision:
    This document is revision #11 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.  Multi-hop MEP channel bindings

    Posted 09-24-2008 17:13
    Jacques,
    
    in the section on MEP channel bindings you define the bindings for all  
    legs of the path including both the first and last leg. Doesn't the  
    use of such kind of channel bindings imply that two endpoints involved  
    in the same MEP know of each other how they communicate with the I- 
    Cloud (i.e. the intermediary they are connected to) ? I think it would  
    be better that endpoints don't know about the binding used on other  
    legs of the path. I.m.o. the important thing of having other bindings  
    than the ones defined in the core spec should be that the new multi- 
    hop bindings trigger different behavior with respect to non ebMS user  
    messages. This way only three multi-hop bindings would be required:  
    multi-push, multi-pull and multi-sync.
    
    Sander
    
    On Sep 24, 2008, at 6:24 , jdurand@us.fujitsu.com wrote:
    
    > 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)
    >
    > -- Mr Jacques Durand
    >
    > The document revision named Multi-hop Section Draft 0.13 (ebMS3- 
    > Multihop
    > V13-JD.doc) has been submitted by Mr Jacques Durand to the OASIS ebXML
    > Messaging Services TC document repository.  This document is  
    > revision #11
    > 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.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)
    >
    > View Document Details:
    > http://www.oasis-open.org/committees/download.php?document_id=29435
    >
    > Download Document:
    > http://www.oasis-open.org/committees/download.php/29435/ebMS3-Multihop%20V13-JD.doc
    >
    > Revision:
    > This document is revision #11 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
    
    


  • 3.  RE: [ebxml-msg] Multi-hop MEP channel bindings

    Posted 10-01-2008 19:57
    Working on reflecting Sander's remark in the next draft.
    
    To summarize:
    As an alternative to the "multihop extension Pmode block" that I
    suggested, we could consider a Pmode update where:
    (a)- the MEP binding for each endpoint can be decoupled (default is the
    one specified "at the top of the Pmode" that applies to both endpoints
    as of today).
    (b)- the parameters that specify a "reply mode" for all kinds of
    messages (errors, Acks, Receipts...) can also be decoupled (default is
    the ones we have today that apply to an end-to-end transfer, which still
    makes sense in cases such as an "all sync" 2-hop across a Hub.
    (c) there is still a need - in most cases - for additional multihop
    parameters such as routing info. These also should be decoupled between
    the 2 endpoints concerned by the Pmode.
    
    Is that a fair summary of what to explore, in order to minimize the
    impact of migrating from peer-to-peer to a multihop context, in terms of
    Pmode deployment?
    
    Jacques