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

[Marc Goodner <mgoodner@microsoft.com>]

+1

As the DA is between the RMD/AD and RMS/AS then any RMS can talk to any RMD regardless of DA. An RMS that chooses to interact only with DAs that match its local DA, or some other DA(s) it cares about, can. Thus wsp:Ignorable isn't needed for a DA assertion.

-----Original Message-----
From: Paul Fremantle [mailto:paul@wso2.com]
Sent: Tuesday, January 09, 2007 5:27 AM
To: Christopher B Ferris
Cc: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] strawman proposal for delivery assurance in policy for RM

Chris

I think this proposal has had sufficient review to move on to the stage
where we need a concrete proposal.

There was some discussion on the call whether we needed to say anything
about wsp:Ignorable. Obviously if we can leave this out and describe the
semantics we mean by ourselves, then we will not have a dependency on a
WS-P draft.

Anish also made the point that it is only ignorable when published
against the RMD (i.e. in operations).

It seems clear (to me at least), that the state of policy intersection
for these assertions is that any valid RMS can satisfy *any* of these
policies against *any* RMD.

Paul

Christopher B Ferris wrote:
>
> 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