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