[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
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----- > 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 > > > --------------------------------------------------------------------- > 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]