[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 forRM
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]