David A. Chappell wrote:
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
This is a bit tricky to explain, but the answer is "no".
The continuity I'm talking about is essentially within the NP
(or more accurately, within the encapsulation it provides), not between
the NP and consumer. If I change a subscription for topic A to a
subscription for topic A and topic B, the NP may choose to do this by
simply canceling the old subscription and making a new one (but keeping
the SM EPR the same). In this case, even if there is a reliable
connection between the NP and consumer, it doesn't help because the NP
will not send any messages generated on topic A in the interim at all.
That is, they never reach the head end of the reliable connection. The
RM layer can only number and reliably deliver messages that it sees,
and it would never see the missing messages at all.
Maybe it would help to do a timeline of the two cases:
Continuous case:
Subscriber makes subscription for topic A.
Events are generated on topic A and sent to the consumer.
Subscriber (or anyone else with access to the SM endpoint) changes the
subscription to "topic A and topic B"
*Change becomes effective*
Events for topic A continue to be sent, and events for topic B
generated after the change becomes effective are also sent
Discontinuous case:
Subscriber makes subscription for topic A.
Events are generated on topic A and sent to the consumer.
Subscriber (or anyone else with access to the SM endpoint) changes the
subscription to "topic A and topic B"
*NP cancels subscription internally*
Events are generated on topic A, but not sent to the consumer.
*NP creates new internal subscription for A and B*
Events for topic A are sent again, events for topic B are also sent.
As an aside, I believe we need to establish a rigorous definition of
"sent". I'll follow up with one, based on WS-ReliableMessaging (or is
it WS-Reliability?). In any case, the starred steps are critical. You
can consider the continuous case as the discontinuous case with a
guarantee of (internal) atomicity, in the sense that every event is
considered to occur either before or after the two steps and never
between them. Without at least the possibility of this guarantee,
setting subscription properties is just a convenient shortcut for
cancel/resubscribe. With it, it provides functionality that
cancel/resubscribe can't, even in principle and even with absolutely
reliable connections between NP and Consumer.
The discontinuous case allows NPs not to worry about the relationship
between an old topic set and a new one. Implementing the continuous
case means understanding when the old and new topic sets overlap. This
may not be such a problem if the NP is itself generating the events,
but could be a problem if the NP is aggregating traffic from other
sources, which may not even be WSN. The point of the continuity policy
is to allow NPs to be clear as to whether they guarantee continuity or
not.
The point about message numbers is that if they are available,
continuity can be provided outside the NP, as was discussed on
the list a while ago. This is messy in several ways, however, and if
the consumer is concerned about continuity, it's better to know that
the NP is providing it directly.
The subscriber should be able to request continuity if it's available,
and the NP should be able to refuse this request. An aggregator might
have enough resources to track serial numbers on a limited number of
aggregated subscriptions and thus be able to guarantee continuity for a
limited number of subscriptions. If the NP refuses to guarantee
continuity, it could at least tag outgoing Notify messages with a
serial number. Note that in the aggregated case serial numbers
probably have to ultimately come from the original source of
notifications, as opposed to being generated by the NP. In other
words, they would have to mean "this is the nth message that the
underlying source sent" not "this is the nth message that I the NP
received from the underlying source." I'm hoping that's clear enough I
don't have to go into further detail, but I'm probably not explaining
it well.
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.
|