Policy assertion for continuity in face of property changes

[David Hull <dmh@tibco.com>]

Description

Subscriptions properties may be dynamically updated via that SubscriptionManager interface.  Such a change may be regarded as a terminating the existing subscription and creating a new one with the new properties.  Depending on the exact implementation, it may not even be possible to assert a timeline in which the new subscription takes place after the termination of the old.  For example, in a loosely coupled federation where the old and new versions are handled by different nodes, there would not necessarily be any synchronization between the two.

Such a lack of synchronization may or may not be detectable to an outside observer, depending on the exact set of subscriptions made.  In general, it will be detectable when there is overlap among subscriptions.  For example, suppose subscription 1 and subscription 2 are for the single topic T1.  Normally, the same notifications will be produced for both subscriptions.  Now suppose that subscription 1's filter is changed to include both topic T1 and topic T2.  If this is done by terminating and re-subscribing, any notifications on T1 between termination and resubscription will be produced for subscription 2 but not subscription 1.

In many cases the SubscriptionManager can offer stronger assurances.  For example, if the NotificationProducer is actually the source of the events in question, it may be easy to assure that a change in subscription properties so that, in our example, all notifications on T1 are produced for both subscriptions.  The "subscription continuity" assertions allow NotificationProducers to advertise, and Subscribers to request, assurance of continuity in the face of subscription property changes.

Options

The "SubscriptionContinuityPolicy" element has the following pseudo-schema:

<SubscriptionContinuityPolicy ...>
 <Property>QName</Property>*
 <Continuity>AtLeastOnce|AtMostOnce|ExactlyOnce</Continuity>
</NotificationTransformPolicy>*

The SubscriptionContinuityPolicy element may appear multiple times.  Each occurrence associates one or more properties with a continuity, asserting that the given continuity is guaranteed when the given property is changed.  The properties are named as in section 6.4.1, namely wsnt:ConsumerReference, wsnt:Filter and wsnt:SubscriptionPolicy (wsnt:CreationTime is immutable).

Note: The designations AtLeast/AtMost/ExactlyOnce are also used in describing reliable delivery.  Reliable delivery also includes "in order" semantics, but this orthogonal consideration does not apply here.

Note: With this mechanism we can assert that changing the SubscriptionPolicy or Filter property as a whole will not disrupt production, but not that changing the policy in any particular way (for example, narrowing a subscription filter) will have any given effect.  The notation above can be extended by introducing a finer-grained alternative to the <Property> element.

Note: Distinct ConsumerReferences may refer to the same physical endpoint or to endpoints connected in some logical way.  Because of this, continuity may be important even in the face of a changed consumer reference.

Context

Support for this policy is advertised by the notification producer by use of one or more SubscriptionContinuityPolicy elements.

This policy is invoked by the subscriber by placing one or more SubscriptionContinuityPolicy elements as direct children of the SubscriptionPolicy element in the Subscribe message.