ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: strawman proposal for delivery assurance in policy for RM
- From: Christopher B Ferris <chrisfer@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Thu, 7 Dec 2006 16:35:13 -0500
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]