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

["Gilbert Pilz" <gpilz@bea.com>]

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

smime.p7s