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


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]