[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] PR issue 09
concern (b) can be addressed by the referencing header block (with mustUnderstand), I believe. So this can control whether each individual extension may be ignored or not. In that case not much change needed in the core spec. It could be worth defining a generic container header block for controlling extensions, within wsrm namespace (the extension referencing element would be a child, and possibly have a different namespace) > "Send an extended CreateSequence message, if you get an extended > CreateSequenceResponse then the RMD understood" That would also work, but some DA parameters may also have to flow over a CSR. Jacques -----Original Message----- From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] Sent: Wednesday, November 08, 2006 2:16 PM To: Paul Fremantle Cc: Durand, Jacques R.; ws-rx@lists.oasis-open.org Subject: RE: [ws-rx] PR issue 09 But if we mandate that all extensions are mustUnderstand we remove the ability of a later-version RM handler to say "I'd like to use this extension but if the other side doesn't understand it I'm willing to continue using the base protocol." Actually we don't *remove* this ability but we do make it more difficult. Compare "Send an extended CreateSequence message, if you catch an exception caused by a mustUnderstand fault then retry with a standard CreateSequence message" with "Send an extended CreateSequence message, if you get an extended CreateSequenceResponse then the RMD understood". - gp > -----Original Message----- > From: Paul Fremantle [mailto:paul@wso2.com] > Sent: Wednesday, November 08, 2006 11:12 AM > To: Gilbert Pilz > Cc: Durand, Jacques R.; BAYES_00 > Subject: Re: [ws-rx] PR issue 09 > > We did agree that. However, that doesn't answer the problem > raised by the PR issue as raised by Jacques. > The concern he is raising is that *if* people use extensions > - for example to acheive a given DA - then those extensions > may reduce interoperability. Since we have not mandated in > any way how companies extend the protocol, we cannot ensure > that this is not the case. > > On the other hand if we make all extensions mustUnderstand, > then it is clear to both sides whether a given extension > (such as a DA) is actually working in place. > > Paul > > Gilbert Pilz wrote: > > I thought that we had agreed that, if you wanted to mark a > particular > > extension as mustUnderstand, that you needed to add a unique SOAP > > header that refered to that extension and mark the SOAP header as > > mustUnderstand? > > > > - gp > > > > > >> -----Original Message----- > >> From: Paul Fremantle [mailto:paul@wso2.com] > >> Sent: Tuesday, November 07, 2006 1:32 PM > >> To: Durand, Jacques R. > >> Cc: BAYES_00 > >> Subject: Re: [ws-rx] PR issue 09 > >> > >> Jacques > >> > >> Rather than a mustSupport option or mustUnderstand marker on > >> extensions, I was proposing simply that ALL extensions are > considered > >> mustUnderstand. > >> Althought that may seem too restrictive on extension > builders, but I > >> don't really think so. After all, you can make sure that > support for > >> the extension is present when you do the CreateSequence > (by adding an > >> appropriate extension). > >> > >> I guess it might make sense to add a specific fault if an > extension > >> is not understood containing the extension's xpath in the fault > >> detail. > >> > >> Paul > >> > >> > >> Durand, Jacques R. wrote: > >> > >>> Paul: > >>> > >>> 2 levels of concern here, one of them I think needs and can be > >>> addressed by this TC: > >>> > >>> (a)- a minimal set of DAs, their representation and how they are > >>> communicated. We know this will be needed, whether > >>> > >> specified in or out > >> > >>> of the TC. This would define QoS-level interoperability. > >>> > >>> (b)- in case these DAs and/or their parameters are > communicated via > >>> extensibility points, support in the protocol to at least > >>> > >> signal the > >> > >>> expected behavior of the other RM module - in particular if not > >>> understood. > >>> > >>> So (b) seems to be within reach, see inline <JD>. > >>> > >>> Thanks, > >>> Jacques > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Paul Fremantle [mailto:paul@wso2.com] > >>> Sent: Monday, October 30, 2006 11:04 PM > >>> To: Durand, Jacques R. > >>> Cc: BAYES_00 > >>> Subject: Re: [ws-rx] PR issue 09 > >>> > >>> Jacques > >>> > >>> Let us take a concrete example. Suppose there was a third-party > >>> defined an extension to CreateSequence that specified > >>> > >> InOrderExactlyOnce. > >> > >>> If the RMD specifies this, as we know from extensive > >>> > >> discussion, there > >> > >>> is no change to the wire protocol. Therefore there cannot > >>> > >> be interop > >> > >>> problems even if the client doesn't understand the extension. > >>> > >>> <JD> agree. > >>> > >>> If the specifier wants the RMS to be able to force this, > then they > >>> need to specify the extension correctly. In general we do > not have > >>> client-side policies, so the extension would need to be > >>> > >> specified so > >> > >>> that the RMD responded to say it had accepted that model. > >>> > >> If the RMD > >> > >>> didn't understand the extension, it won't respond. > >>> > >>> <JD> works for messages received by RMD - note that we have > >>> > >> extensible > >> > >>> elements going the other way too. > >>> > >>> At one point we discussed making any extensions of CS > >>> > >> mustUnderstand. > >> > >>> Would that help allay the concerns of this group? > >>> > >>> <JD> I remember that and the problem was something that > >>> > >> looked like an > >> > >>> extension of the current mustUnderstand SOAP model in a way that > >>> presented difficulties for several of us, (if I remember: > >>> > >> interaction > >> > >>> with SOAP model, extensions may be not just elements but > attributes, > >>> etc.) Maybe that needs be revisited - On our side, we considered > >>> another general alternative where a single element (e.g. called > >>> "mustSupport") could be added to either body or headers, > >>> > >> that contains > >> > >>> a list of XPaths on elements/attributes that must be > >>> > >> supported (either > >> > >>> in extensibility points but not restricted to... also possibly > >>> targeting a subset of their values), and return a > specific fault if > >>> not. Powerful, though a bit more costly to process. I am > >>> > >> willing to > >> > >>> spend more time on this problem with interested folks. > >>> > >>> > >>> Paul > >>> > >>> Durand, Jacques R. wrote: > >>> > >>> > >>>> Paul: > >>>> > >>>> Let me reword one of the concerns I see in the eAC comment: > >>>> > >>>> - because DAs are not specified - although often > expected, as our > >>>> charter recognizes - some WS-RM implementers may be led to > >>>> > >> establish > >> > >>>> a proprietary way to do it that requires use of > >>>> > >> extensibility points > >> > >>>> in the RM protocol, for signaling these DAs or parameters > >>>> > >> of these DAs. > >> > >>>> This way could become a de-facto standard for a > significant part of > >>>> > >>>> > >>> the > >>> > >>> > >>>> market (just an hypothesis, but quite possible). > >>>> > >>>> - if this happens, there would be interop issues with other RM > >>>> > >>>> > >>> endpoints > >>> > >>> > >>>> that may not support these extensions, when you look at > the bigger > >>>> picture (RM protocol + DAs) even though you may still have > >>>> interoperability at RM protocol level alone, since an RMD/RMS may > >>>> > >>>> > >>> ignore > >>> > >>> > >>>> any extension. In case these other implementations want to > >>>> > >> align with > >> > >>>> the practice, besides the trouble in upgrading already deployed > >>>> products, there might be unexpected IP issues. > >>>> > >>>> So the worst interoperability scenario for those who need to > >>>> > >>>> > >>> communicate > >>> > >>> > >>>> DA data, would be if sometime later this comes to affect > >>>> > >>>> > >>> implementations > >>> > >>> > >>>> of the lower protocol layer - RMS/RMD. > >>>> > >>>> Short of specifying DAs somewhere (and the way to > >>>> > >> communicate them) I > >> > >>>> see no good solution for preventing this scenario except > >>>> > >> getting rid > >> > >>>> > >>>> > >>> of > >>> > >>> > >>>> extensibility points... > >>>> > >>>> Jacques > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Paul Fremantle [mailto:paul@wso2.com] > >>>> Sent: Thursday, October 26, 2006 4:23 PM > >>>> To: Durand, Jacques R.; ws-rx@lists.oasis-open.org > >>>> Subject: Re: [ws-rx] PR issue 09 > >>>> > >>>> Jacques > >>>> > >>>> I understand what you are saying. I'm trying to understand how we > >>>> > >>>> > >>> would > >>> > >>> > >>>> prove something so obvious :-) > >>>> > >>>> Our protocol ensures that the messages are correctly > transmitted to > >>>> > >>>> > >>> the > >>> > >>> > >>>> RMD together with a message number, which increases by one. > >>>> > >>>> So even if we did define this in our specification, the > text would > >>>> > >>>> > >>> sound > >>> > >>> > >>>> pretty lame: > >>>> > >>>> i.e. > >>>> "To achieve the "ordered delivery" delivery assurance, the > >>>> > >> RMD must > >> > >>>> deliver the messages in the order of the MessageNumbers." > >>>> "To achieve the AtMostOnce delivery assurance, the RMD must only > >>>> > >>>> > >>> deliver > >>> > >>> > >>>> one message with a given MessageNumber" > >>>> "To achieve the AtLeastOnce delivery assurance, the RMD > must ensure > >>>> > >>>> > >>> that > >>> > >>> > >>>> it delivers each transmitted message with a given MessageNumber." > >>>> > >>>> As regards your second point, I have some sympathy for that. > >>>> > >>>> Paul > >>>> > >>>> > >>>> Durand, Jacques R. wrote: > >>>> > >>>> > >>>> > >>>>> I think the issue is not so much "how can I implement my > >>>>> > >> DAs on top > >> > >>>>> > >>>>> > >>> of > >>> > >>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>>> this protocol" . Many folks in eAC are quite > experimented with RM > >>>>> and > >>>>> > >>>>> > >>> > >>> > >>>>> have known sequence numbers way before WS-RX started. > >>>>> > >>>>> But without going as far as bringing back the DAs, at a > >>>>> > >> minimum it > >> > >>>>> would be helpful to demonstrate the following, either > in the spec > >>>>> (appendix) or in a companion doc: > >>>>> > >>>>> - whatever DAs (among most popular ones) are defined on > >>>>> > >> top of this > >> > >>>>> protocol, and assuming both sides are aware of which DA > is being > >>>>> used > >>>>> > >>>>> > >>> > >>> > >>>>> (communicated out of band), then the protocol as defined is > >>>>> > >>>>> > >>> sufficient > >>> > >>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>>> to *enable* the DAs and does not need additional > interoperability > >>>>> tightening or extensions when actual DAs are > implemented. Were it > >>>>> otherwise, it would mean that proprietary extensions to > >>>>> > >> the protocol > >> > >>>>> are needed that would introduce both interop and IP issues. > >>>>> > >>>>> Now that probably isn't enough to make everyone happy. > >>>>> > >> Standard DAs > >> > >>>>> > >>>>> > >>> to > >>> > >>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>>> choose from, along with their parameters, are still > expected from > >>>>> > >>>>> > >>> some > >>> > >>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>>> users and are considered as part of the interop equation. But > >>>>> > >>>>> > >>> wherever > >>> > >>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>>> these are defined - either wsrmp or elsewhere - it is > >>>>> > >> important to > >> > >>>>> show first that this has no bearing on the wsrm > protocol layer and > >>>>> > >>>>> > >>> its > >>> > >>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>>> implementations, i.e. this layer can be considered stable. > >>>>> > >>>>> -Jacques > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >> -- > >> Paul Fremantle > >> VP/Technology and Partnerships, WSO2 > >> OASIS WS-RX TC Co-chair > >> > >> http://bloglines.com/blog/paulfremantle > >> paul@wso2.com > >> (646) 290 8050 > >> > >> "Oxygenating the Web Service Platform", www.wso2.com > >> > >> > >> > >> > > > > > > -- > Paul Fremantle > VP/Technology and Partnerships, WSO2 > OASIS WS-RX TC Co-chair > > http://bloglines.com/blog/paulfremantle > paul@wso2.com > (646) 290 8050 > > "Oxygenating the Web Service Platform", www.wso2.com > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]