OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsn message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsn] Simultaneity and the semantics of setting subscriptionproperties


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:
  1. 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.
  2. 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
  3. This only makes sense if the original subscription had exactlyOnce semantics.
  4. 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]