Could you not rely on the sequence number
of the RM protocol being used? Are you asking for a separate
sequence number that is independent of the RM protocol? If we had a “supportsSubscriptionContinuity=yes”
setting, then would it be sufficient to rely on the RM processor?
Dave
From: David Hull [mailto:dmh@tibco.com]
Sent: Wednesday, January 12, 2005
1:07 PM
To: wsn-oasis
Subject: [wsn] Use case for
"advertising continuity support"
Some applications are more concerned about missing
messages than others. For those that cannot miss messages, various people
are standardizing reliable messaging protocols. These, however, only ensure
that (barring disaster) every message sent is delivered (or delivered at most
once, etc.). When subscription properties are modifiable, there is the
chance that messages may not be sent at all.
For example, if the topic expression for a subscription changes, there may be
messages that would be sent under either the old or the new rules.
However, a NotificationProducer may choose to implement a subscription property
change as a cancellation followed by a new subscription. In this case, messages
in the overlap between the old and new topic expressions may be lost.
Special care may be needed when the consumer endpoint changes: We would like to
know whether there is any guarantee that each message is received exactly once
by either the old endpoint or the new (and that all messages before a certain
point go to the old and all messages after that point go to the new).
In BaseN, we specify that the default guarantee is no guarantee at all, that
is, by default there is no difference between changing a subscription property
and canceling/resubscribing (except that the SM endpoint remains the same), but
we allow for policy utterances to promise more.
In some cases it would be feasible to build this sort of reliability on top of
the default semantics, provided that the underlying message traffic meets a few
relevant criteria, particularly that messages are tagged with a serial
number. An NP might be able to advertise that it does not make any
guarantees in the face of changing subscription properties, but does provide
serial numbers.
Back at the subject line, the use cases I see are:
- The consumer needs a guarantee of reliable
delivery, and the set of topics it's interested in may change over
time. We would like to know whether it's safe to modify subscription
properties dynamically. This would affect the decision to 1) make a
single subscription with a complex topic expression and change the topic
expression if interest changes, and 2) make a set of subscriptions and
create and cancel subscriptions as interest changes.
- The ultimate consumer needs a guarantee of
delivery and the set of topics it's interested in may change over time,
the NP does not provide that capability natively, but it does provide a
serial number. We would like to know how to extract that serial
number so that we can track messages and make overlapping subscriptions in
order to provide continuity. "We" here might be an
infrastructure layer used by the ultimate consumer, or a broker adding
value by providing reliability on top of an unreliable producer.