From: Durand, Jacques
R. [mailto:JDurand@us.fujitsu.com]
Sent: Wednesday, January 03, 2007
1:09 PM
To: Christopher
B Ferris; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] strawman
proposal for delivery assurance in policy for RM
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)
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