Could you work through in detail how this would happen?
I believe we're up against an egg-unscrambling problem here. On the
one hand, there will be cases when the NP knows exactly which updates
came after which snapshot. A common case would be an NP which locks
the database for updates during a snapshot. It will be able to tell
which updates came in before the lock and which came after. It can
therefore easily send the snapshot to the consumer, followed by exactly
the right updates.
Here are the problems I see under the current setup:
- There is no way to get a snapshot, per se. If the updates are
incremental, which they may legitimately be, then "last message" and
"current state" are two different things. If I understand your
proposal, you're saying that there could be parallel sets of "current
state" and "update" topics. Fair enough.
- The result of getCurrentMessage goes to the subscriber,
not to the consumer. The behavior we want is for the consumer to get
the snapshot followed by (all and only) the relevant updates. Under
the current setup, either the subscriber would have to forward the
result to the subscriber, or the consumer would have to make the
getCurrentMessage call directly (perhaps having learned the NPs address
from a previous update, assuming one has come in).
- It is decidedly non-trivial to handle races between the snapshot
and the update stream. At the minimum, both need to be tagged with
timestamps (or better, sequence numbers). But even this doesn't seem
sufficient, particularly since I don't know whether the snapshot is in
sync with the updates until I actually get an update, which could be
arbitrarily long.
In short, we need a way of explicitly associating the snapshot request
with the request for updates and making sure they both go to the same
endpoint, in the right order. We would like to do this in a way that
requires no processing by the consumer. One of the key
features of WSN is that consumers can be dumb. The consumer should not
have to buffer updates and check sequence numbers. It should not have
to make the update subscription itself. And, as far as I can tell,
there is no need for it to do so, at least in the plausible case that
the NP already knows how to provide exactly the right information.
Samuel Meder wrote:
Another way of doing this that does not require WSRF-RP is to model your
topics in a way that allows for this: A top level topic for the whole
document (which you can call getCurrentMessage() on) and sub-topic for
fields in the document (which you would subscribe to), or even just a
single "update" sub-topic. That in combination with appropriate use of
timestamps should be able to address your problem.
/Sam
On Tue, 2004-11-23 at 16:43 -0500, David Hull wrote:
Steve Graham wrote:
David Hull <dmh@tibco.com> wrote on 11/22/2004 04:48:34 PM:
One useful pub/sub paradigm involves the concept of notifications
as updates to
some collection of state.
Indeed, this is what WSRF-Resource Properties suggests.
In such cases, it is useful to be able to take a
snapshot of the state, then be notified of updates to that state.
Agreed. GetResourcePropertyDocument, followed by a subscribe
operation specifying
which Resource properties (bits of state) the consumer should
receive value change
notifications.
Minus whatever changes happened between the get and the subscribe. Or
plus whatever changes happened between the subscribe and the get. In
any case, we want to be able to cover snapshot/update scenarios where
the state is not presented as a WS-Resource. Or at least I would like
that.
|