[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] strawman proposal for delivery assurance in policy for RM
With all due respect to the submitters of PR009 and PR035, I think they are mistaken in assuming that, because WS-RM doesn't say *how* to implement things like duplicate elimination, message ordering, etc., they can't use WS-RM to meet those requirements. The TC had a long, hard time figuring out the nuances of the relationship between the WS-RM protocol and DAs and I think we have got it right. I think the only problem we have is that our spec doesn't contain any language that directly addresses the relationship between the WS-RM protocol and the implementation of delivery assurances. We need to make it clear that: 1.) the information provided by the WS-RM protocol can be used to implement "at least once" and "exactly once" semantics with ordered and non-ordered variations of each. 2.) delivery assurances are treated as a private contract between the AD and the RMD and are not covered by the spec 3.) the WS-RM protocol works in the same manner regardless of the delivery assurance in effect for a particular sequence - gp > -----Original Message----- > From: Paul Fremantle [mailto:paul@wso2.com] > Sent: Wednesday, December 13, 2006 1:08 AM > To: Gilbert Pilz > Cc: Christopher B Ferris; ws-rx@lists.oasis-open.org > Subject: Re: [ws-rx] strawman proposal for delivery assurance > in policy for RM > > Gil > > The feedback I'm getting is that we do need this. We also > have a number of PR issues that state this is a requirement. > I think that Chris's proposal makes this valid using WS-Policy. > > Paul > > Gilbert Pilz wrote: > > I don't know. You convinced me when you said (I'm > paraphrasing) that > > there was no legitimate use case wherein a client would > select from a > > number of nearly identical services but discriminate on the > basis of > > which DA(s) the services supported. DAs are closely related to > > application semantics. A service supports/requires "in order" (for > > example) based on the semantics of the service itself. In > this sense > > "the service knows best" and there is no need to expose this > > implementation detail to the client. > > > > This strawman seems to be a way of doing something that > doesn't need > > to be done but in a less harmful way than was previously possible > > (before the wsp:Ignorable attribute). I'd argue that, regardless of > > wsp:Ignorable, a job that doesn't need to be done shouldn't be done > > regardless of how nicely you can do it. > > > > - gp > > > > > -------------------------------------------------------------- > ---------- > > *From:* Christopher B Ferris [mailto:chrisfer@us.ibm.com] > > *Sent:* Thursday, December 07, 2006 1:35 PM > > *To:* ws-rx@lists.oasis-open.org > > *Subject:* [ws-rx] strawman proposal for delivery assurance in > > policy for RM > > > > > > Previous to the LC draft of the WS-Policy 1.5 - Framework spec, > > there was no means by which > > you could include an assertion that had no client impact and/or > > on-the-wire manifestation. All assertions > > had to be both understood and would manifest themselves in the > > interactions between the two > > parties. > > > > However, in the LC draft, the WS-Policy WG introduced a new > > attribute: wsp:Ignorable, of type boolean, > > that could be added to an assertion to indicate that at > the policy > > consumer's discretion, that assertion > > could be omitted from consideration in the intersetcion > algorithm. > > Thus, a service provider that > > wanted to advertise a QoS capability of the service, sich as a > > delivery assurance, that in fact placed > > no requirements on the part of the client, such that the client > > could choose to ignore it if it didn't > > understand that assertion. Effectively, it is a means for the > > service prvider to advertise in its policy > > "here is an assertion, but you don't need to do > anything about it, > > or even understand it and you can > > still interoperate with me". > > > > One of the concerns that we had previously with regards to > > delivery assurances (DA) was that regardless > > of what DA was, or was not inforce, the protocol was exactly the > > same in all cases. Thus, prior to the > > changes introduced in the WS-Policy LC draft, there was > really no > > means of defining a policy assertion > > that could advertise a DA and also provide a means by which the > > client could choose whether it > > wanted to consider it in the intersection. > > > > Given that WS-Policy now has this new feature, and given the > > concerns that have been raised by > > FIX and others, perhaps we might consider addition of policy > > assertions that reflected the semantics > > of the DAs we previously had in the input specification, with a > > strong recommendation that service > > providers leverage the wsp:Ignorable='true' attribute > to allow for > > a client to omit the assertion from > > consideration in the intersection algorithm. > > > > e.g. > > > > <wsrmp:ExactlyOnceDelivery wsrmp:InOrder='true|false' > > wsp:Ignorable='true'/> > > <wsrmp:AtMostOnceDelivery wsrmp:InOrder='true|false' > > wsp:Ignorable='true'/> > > <wsrmp:AtLeastOnceDelivery wsrmp:InOrder='true|false' > > wsp:Ignorable='true'/> > > > > This approach would give the client (RMS) the choice as > to whether > > to engage with the service > > as it could use the policy intersection mode of > 'strict' to ensure > > that it only interacted with > > a service provider that supported RM and offered the DA it > > required. Alternatively, a client > > that didn't care what the DA was at the service > provider could use > > the lax mode of intersection > > to omit the assertion from the intersection algorithm. > > > > Considerations: > > - only ONE DA could be advertised per service endpoint, as there > > is nothing in the message > > that would indicate which was in play since the > protocol operates > > the same in all cases. There is nothing > > in WS-Policy that can enforce such a constraint (that > an assertion > > be exclusive of others in any > > alternatives in the policy statement). We would need to have a > > constraint like: > > > > A Policy statement MUST NOT contain more than one of the > > DA assertions in its collective > > alternatives. A Policy statement MAY include the same DA > > assertion in more than one alternative. > > > > - Should probably provide guidance on use of the wsp:Ignorable > > attribute (e.g. SHOULD be used > > unless the service is being deployed with knowledge that all > > consumers of the service will > > both understand that assertion and be willing to > include it in the > > policy intersection) > > > > Thoughts? > > > > Christopher Ferris > > STSM, Software Group Standards Strategy > > email: chrisfer@us.ibm.com > > blog: http://www.ibm.com/developerworks/blogs/page/chrisferris > > phone: +1 508 377 9295 > > > > -- > 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]