[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] PR issue 09
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]