[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]