ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] strawman proposal for delivery assurance in policy for RM
- From: "Durand, Jacques R." <JDurand@us.fujitsu.com>
- To: "Christopher B Ferris" <chrisfer@us.ibm.com>, <ws-rx@lists.oasis-open.org>
- Date: Wed, 3 Jan 2007 13:08:35 -0800
Sorry for being late on this - Chris proposal below
(Dec 7) appears OK to me, at least for DAs expressed within the scope of policy
assertions. Here is some proposed defs for the minimal set of DAs being
considered:
AtLeastOnceDelivery: When sending a message under this DA,
one of the two following outcomes
shall occur: either (1) the RMD has
received the message and successfully delivered it to the AD, or (2) either
the AS or the AD is made aware of a delivery
failure.
(note: under
which conditions the AS vs. the AD is notified, is left to futher tuning - also
the meaning of delivery failure notification is left to
implementations)
AtMostOnceDelivery: When sent under this
DA, a message shall not be delivered more than once by
the RMD to the AD. Message duplicates are identified by their Sequence ID and
Sequence number.
(note: should we
tolerate duplicate delivery provided a failure notification is done? I would
prefer not, I think the spec provides the means for an implementation to NEVER
deliver duplicates)
InOrder: When sent under this DA, messages from the same sequence shall be
delivered by the RMD in the same order they
have been submitted to an RMS.
(note: the above def
of InOrder allows for gaps in the delivery - different flavors of what kind of
ordered delivery is tolerated can be defined on top of
that)
Jacques
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]