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

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

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

smime.p7s