[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 Unfortunately you have the wrong problem. The submitters of PR035 know exactly *how* WSRM implements Exactly-Once InOrder. What they don't have is a clear definition of those *what* those concepts are so that they can point to it. Therefore they can only specify that particular DA by defining it themselves. Their (very reasonable) point is that the reason they want to refer to a reliable messaging spec is so they don't have to do that kind of thing. In fact they already have done that kind of thing in the binary FIX protocol and they don't want to do it again. They want *us* to do it. I suggest you re-read PR035 where the requirements are clearly espoused. Paul PS I presented WSRM once more today at Javapolis, and once again I was asked why we have a reliable messaging spec that doesn't define DAs. Gilbert Pilz wrote: > 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 >> >> >> >> >> -- 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]