20 messages in org.oasis-open.lists.wsnRe: [wsn] Subscribe and GetCurrentMes...| From | Sent On | Attachments |
|---|---|---|
| David Hull | Nov 22, 2004 1:48 pm | |
| Steve Graham | Nov 23, 2004 12:52 pm | |
| David Hull | Nov 23, 2004 1:42 pm | |
| Patil, Sanjay | Nov 23, 2004 2:12 pm | |
| Samuel Meder | Nov 29, 2004 5:17 am | |
| David Hull | Nov 29, 2004 8:35 am | |
| Samuel Meder | Nov 30, 2004 10:10 am | |
| David Hull | Nov 30, 2004 10:37 am | |
| Samuel Meder | Nov 30, 2004 11:17 am | |
| David Hull | Nov 30, 2004 11:28 am | |
| David Hull | Nov 30, 2004 1:15 pm | |
| Samuel Meder | Nov 30, 2004 1:53 pm | |
| David Hull | Dec 1, 2004 9:58 am | |
| Lily Liu | Dec 3, 2004 12:11 pm | |
| Martin Chapman | Dec 3, 2004 12:27 pm | |
| Peter Niblett | Dec 6, 2004 7:14 am | |
| chri...@bt.com | Dec 6, 2004 7:52 am | |
| David Hull | Dec 6, 2004 8:10 am | |
| David Hull | Dec 6, 2004 8:23 am | |
| Samuel Meder | Dec 6, 2004 9:29 am |
| Subject: | Re: [wsn] Subscribe and GetCurrentMessage | |
|---|---|---|
| From: | Samuel Meder (med...@mcs.anl.gov) | |
| Date: | Nov 30, 2004 10:10:39 am | |
| List: | org.oasis-open.lists.wsn | |
On Mon, 2004-11-29 at 11:35 -0500, David Hull wrote:
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).
As far as I can tell there are multiple ways of doing this:
1) Make use of the WS-Addressing Reply-To feature to redirect the result of a getCurrentMessage to the consumer 2) As you mention, the consumer could obtain the NP address via some (out-of-band?) means 3) You could make the semantics of the "current state" topic such that a subscription to it will trigger a single notification of the current state (ok, I admit that this is really stretching it).
* 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.
One way to deal with this is to subscribe for updates and then get the snapshot (I am assuming that the snapshot kept by the NP is always up to date wrt to updates, otherwise this whole thing would not be workable unless you had some way to pull past updates as well).
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.
I think that consumers at some level (and this may be at the framework level) will have to worry about sequencing in any scenario that involves updates and asynchronous messaging.
/Sam
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 <dm...@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.