+1
I
would however suggest avoiding the word "delivery" in the description of the
different QoS types. The QoS issues of our current interest are regarding change
of Subscription properties, which are related to the "processing of
notifications" and are generally independent of the actual delivery QoS.
By "processing of the notifications" I mean everything on
the producer side from the point the producer becomes aware of a new
notification to the point of initiating delivery of the
notification.
For
example, an "exactly once" QoS regarding change of Subscription
properties can only guarantee that a notification is processed exactly
once, according to either the old or new property settings. Now, this same
notification which is processed "exactly once" may be delivered on a channel
with "best effort" QoS and in reality may not reach the consumer at
all.
Thanks,
Sanjay
Following the
original is a draft rewording, with footnotes.
WSN2.20: QoS regarding change of Subscription properties
Section 5.1 says: " If the
SubscriptionManager also accepts the SetResourceProperties request message
as defined in WS-ResourceProperties, the following properties MAY be
modified by the requestor:
/wsnt:ConsumerReference
and /wsnt:TopicExpression and /wsnt:UseNotify and /wsnt:Precondition and
/wsnt:Selector and /wsnt:SubscriptionPolicy" If the
SubscriptionManager also accepts the SetResourceProperties request message,
the following properties MAY be modifiable [1] by the requestor:
- /wsnt:ConsumerReference
- /wsnt:TopicExpression
- /wsnt:UseNotify
- /wsnt:Precondition
- /wsnt:Selector
- /wsnt:SubscriptionPolicy
Any property change implies two streams
of notifications, one according to the original property setting, and one
according to the new setting. For each modifiable property [2], the
subscription policy may specify one of the following levels of continuity
between these streams:
- bestEffort: There is no guarantee of continuity. The
unmodified stream may overlap the modified stream, or messages may be
dropped entirely. This is essentially equivalent to creating a
subscription with the new property value and canceling the old.
- atLeastOnce: Every message will be delivered at least once.
Some messages may be delivered according to both the old and new property
values
- atMostOnce: No message will be delivered twice. Some may
not be delivered at all.
- exactlyOnce: Every message will be delivered exactly once,
according to either the old are new property setting. All messages
before some point will be delivered according to the old parameters, and all
subsequent messages will be delivered according to the new parameters.
[3]
Implementations MAY allow for more detailed specification of
the timing of property changes, including whether particular changes of
multiple properties can be expected to take place simultaneously [4].
Notes:
- I've changed "MAY be modified" to "MAY be modifiable". The
first wording may imply that all of the properties are modifiable by the
SetResourceProperties message. Hopefully this is less ambiguous.
- At the very least, the ConsumerReference property may support a weaker
continuity guarantee than the rest. On the other hand, it seems
burdensome to require all of them to be specified. There are at least
two possibilities, either to specify a default of, say "bestEffort" for
ConsumerReference and "exactlyOnce" for the rest, in the hopes that will
cover typical usage, and/or to allow the policies to be set globally and
possibly overridden
- This only makes sense if the original subscription had
exactlyOnce semantics.
- I originally had "In addition, if modifiable parameters support
exactlyOnce continuity, policy may specify whether multiple changes
take place simultaneously," but this opens up a tricky issue without
completely solving it.
|