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.
|