OASIS ebXML Messaging Services TC

 View Only

  • 1.  Groups - Multi-hop Section Draft 0.16 (ebMS3-Multihop V16-Oct10.doc) uploaded

    Posted 10-13-2008 12:44 
    V0.16:
- more complete section 1.8
- figures added in MEP section, explicit model separating ICloud hops from
"peripheral hops".

 -- Mr Jacques Durand

The document revision named Multi-hop Section Draft 0.16 (ebMS3-Multihop
V16-Oct10.doc) has been submitted by Mr Jacques Durand to the OASIS ebXML
Messaging Services TC document repository.  This document is revision #14
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".

View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=29637

Download Document:  
http://www.oasis-open.org/committees/download.php/29637/ebMS3-Multihop%20V16-Oct10.doc

Revision:
This document is revision #14 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.16 (ebMS3-Multihop V16-Oct10.doc) uploaded

    Posted 10-21-2008 19:20 
    Jacques,

you propose not to change the MEP bindings when migrating from point- 
to-point to multi-hop but to automaticly convert the bindings. If we  
do so, is there still a need to define the multi-hop MEP bindings? I  
think ths might make things unneccessary complex. However I do think  
it might be better not to do an automated conversion and make the  
migration explicit. The PMode must always be changed because of the WS- 
A reference parameter, so why not make the multi-hop communication  
explicit by also changing the MEP binding? This gives the opportunity  
to describe the expected behavior of an endpoint MSH more explicitly  
(based on the value of the MEP binding).

Sander

On Oct 13, 2008, at 14:47 , jdurand@us.fujitsu.com wrote:

> V0.16:
> - more complete section 1.8
> - figures added in MEP section, explicit model separating ICloud  
> hops from
> "peripheral hops".
>
> -- Mr Jacques Durand
>
> The document revision named Multi-hop Section Draft 0.16 (ebMS3- 
> Multihop
> V16-Oct10.doc) has been submitted by Mr Jacques Durand to the OASIS  
> ebXML
> Messaging Services TC document repository.  This document is  
> revision #14
> 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".
>
> View Document Details:
> http://www.oasis-open.org/committees/document.php?document_id=29637
>
> Download Document:
> http://www.oasis-open.org/committees/download.php/29637/ebMS3-Multihop%20V16-Oct10.doc
>
> Revision:
> This document is revision #14 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] Groups - Multi-hop Section Draft 0.16 (ebMS3-Multihop V16-Oct10.doc) uploaded

    Posted 10-22-2008 13:37 
    Sander:

From the two alternatives you mention:

(a) not bother with the new multi-hop MEP binding lengthy names, since
they are "emulated" by combinations of conventional p-2-p MEP bindings
already defined in Core V3.

(b) the opposite: require that the new multi-hop MEP bindings (which
actually specify only the bidings on the "peripheral hops") be used in
the P-Modes on each side when migrating to multi-hop.

I would still prefer (a). 
Of course MEPs are likely to be modified anyway in both cases. But in
(a):
-  the Pmode.MEPbinding parameter gives you a clear idea about what kind
of communication you'll get with the first (or last) intermediary, in
the same way you would describe your interaction with an endpoint MSH. 
- Also Pmode.MEPbinding will not change in case you want the same
communication pattern with your Intermediary as you had with your p-2-p
partner endpoint. 
- So in fact, in several cases the Pmode may have to change on the
Sender side but may not have to on the Receiver side.

So the definition of new multi-hop MEP binding names in the previous
draft was mostly a way to give a name end-to-end combinations of
peripheral bindings (sender side + receiver side), and not intended to
be used in the Pmode.MEPbinding. But that in itself may be confusing, I
agree: we should either go with option (a) or (b), not in-between. 

The only reason I could see to support (b) is if we want to reduce the
supported binding combinations on both ends. The merit of the mapping
rules at the end of section 1.8.1, is that each multihop MEP binding
clearly spells out the valid combinations on each side.

Another reason could be to associate well-defined properties to the
multihop MEP, including (implicit?) reply patterns for various signals
(RM signals, eb:Receipts and eb:Errors) with these MEP bindings. But not
sure that is a real benefit. 

Jacques






    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 4.  Re: [ebxml-msg] Groups - Multi-hop Section Draft 0.16 (ebMS3-Multihop V16-Oct10.doc) uploaded

    Posted 10-22-2008 20:51 
    Jacques,

I agree with you that the PMode.MEPBinding on the endpoint should only  
specify the communication of the pherical hop. Therefor I earlier  
proposed to introduces just three new multi-hop MEPBindings, for push,  
pull and synchronous communication on that peripheral hop. Using these  
new bindings the PMode.MEPBinding parameter will explicitly indicate  
that the endpoint is involved in a multi-hop transfer.

You say that in some cases only the PMode on the Sender side has to  
change. Is this really the case? Can't there always be ebMS Signal  
messages which need special handling (WS-A headers) in the multi-hop  
situation?

You also write that option (b) limits the possible binding  
combinations. But when we use the MEPBindings like proposed above i.e.  
only for the peripheral hops this doesn't limit the possible  
combinations, does it?

I think that using the explicit multi-hop MEPBinding enables us to  
describe more clearly the expected behavior of endpoint MSH's when  
involved in a multi-hop communication.

Sander




On Oct 22, 2008, at 15:40 , Durand, Jacques R. wrote:

> Sander:
>
> From the two alternatives you mention:
>
> (a) not bother with the new multi-hop MEP binding lengthy names, since
> they are "emulated" by combinations of conventional p-2-p MEP bindings
> already defined in Core V3.
>
> (b) the opposite: require that the new multi-hop MEP bindings (which
> actually specify only the bidings on the "peripheral hops") be used in
> the P-Modes on each side when migrating to multi-hop.
>
> I would still prefer (a).
> Of course MEPs are likely to be modified anyway in both cases. But in
> (a):
> -  the Pmode.MEPbinding parameter gives you a clear idea about what  
> kind
> of communication you'll get with the first (or last) intermediary, in
> the same way you would describe your interaction with an endpoint MSH.
> - Also Pmode.MEPbinding will not change in case you want the same
> communication pattern with your Intermediary as you had with your  
> p-2-p
> partner endpoint.
> - So in fact, in several cases the Pmode may have to change on the
> Sender side but may not have to on the Receiver side.
>
> So the definition of new multi-hop MEP binding names in the previous
> draft was mostly a way to give a name end-to-end combinations of
> peripheral bindings (sender side + receiver side), and not intended to
> be used in the Pmode.MEPbinding. But that in itself may be  
> confusing, I
> agree: we should either go with option (a) or (b), not in-between.
>
> The only reason I could see to support (b) is if we want to reduce the
> supported binding combinations on both ends. The merit of the mapping
> rules at the end of section 1.8.1, is that each multihop MEP binding
> clearly spells out the valid combinations on each side.
>
> Another reason could be to associate well-defined properties to the
> multihop MEP, including (implicit?) reply patterns for various signals
> (RM signals, eb:Receipts and eb:Errors) with these MEP bindings. But  
> not
> sure that is a real benefit.
>
> Jacques
>
>
>
>
>
> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


Related Content