[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.16 (ebMS3-Multihop V16-Oct10.doc) uploaded
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----- From: Sander Fieten [mailto:sander@fieten-it.com] Sent: Tuesday, October 21, 2008 12:20 PM To: ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Groups - Multi-hop Section Draft 0.16 (ebMS3-Multihop V16-Oct10.doc) uploaded 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 --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]