RE: [ws-rx] strawman proposal for delivery assurance in policy forRM

[Marc Goodner <mgoodner@microsoft.com>]

This proposal references the W3C version of Policy. That seems like it would require significant delay in getting RM done as Policy won't be at REC for a while.

-----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