OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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]