Re: [wsn] Subscribe and GetCurrentMessage

[Steve Graham <sggraham@us.ibm.com>]

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.

>  For example, the
> snapshot may include everything known about a financial instrument
(its name, the 
> latest relevant financial data from its governing regulatory body,
the current 
> price, the current trading volume, etc.).  Or a snapshot might
be the largish 
> result of a database query, while updates would be insertions, modifications
or 
> deletions involving small numbers of rows.
Indeed, this variability is precisely why we have
a diverse range of "get" MEPS
in WSRF-RP.

> 
> In both cases, some information changes frequently, but most changes
seldom or 
> remains constant.  Significant bandwidth and computation can
be saved by sending 
> only change information in the updates, instead of a replica of what
the current 
> snapshot would be.  In order for this to work smoothly, we would
like the consumer 
> to receive a snapshot, followed immediately by all and only all updates
occurring 
> after the snapshot was taken.
We (a different we perhaps) would prefer this to be
a wsrf-rp:GetXXX followed by
a subscribe for value change on resource properties.

> 
> We currently can't handle this situation.
Agreed. But WSRF in combination with WSN can.

>  First, GetCurrentMessage is defined as
> simply returning the last message for a given topic.  This is
the latest update, 
> not the latest snapshot (but see comment below).
Yep. Snapshot of a piece of state is handled within
the realm of the TC that is
responsible for defining the notion of accessing stateful
resources using Web services
ie WSRF.

> Second, there is currently no way
> to guarantee that the subscription receives all and only all relevant
updates.
Very true.  Ability to detect each value change
situation is a very large burden
and should not be assumed.

>  I 
> think the best we can do on that front right now would be to stipulate
that, if 
> GetCurrentMessage and Subscribe are both wrapped in the same transaction
(using 
> whatever definition of transaction), then they are intended to be
handled in the 
> manner described above.  That requires the NotificationProducer
to figure out what 
> lies in the same transaction, examine the topics and determine identity.
 It 
> requires us to specify what happens if, say, more than one GetCurrentMessage
> appears within the same transaction, or if a GetCurrentMessage for
a single topic 
> overlaps a wildcard subscription, and so forth.
I am not sure this level of specificity is required.

> 
> An alternative would be to add two boolean attributes to subscribe,
say "wsn:
> snapshot" (default, false) and "wsn:update" (default,
true).
> Update = true, snapshot = false is the present
Subscribe semantics
> Update = false, snapshot = true is the present
GetCurrentMessage semantics (or 
> probably close enough -- see below)
> Update = true, snapshot = true means send the
current snapshot, followed by all and
> only the relevant updates
> both false is a nop, and should probably fault
> Doing things this way makes the intent explicit
in a single message, allowing a 
> producer that can support it the ability to expose the transactionality
it 
> naturally has, without requiring fully general transaction support.
-1, this functionality can be achieved by appropriate
combination of specs, there
is no reason to add this functionality to WS-BaseN.

> 
> Only the first variant should be required.  A NotificationProducer
MAY support the 
> other two (and SHOULD advertise just exactly what it supports).
> 
> I say "probably" above, because in the use cases where GetCurrentMessage
currently 
> makes sense, there is probably no distinction between snapshots and
updates.  E.g.,
> if I want hurricane updates (which come every few hours), the "snapshot"
is just 
> the latest "update".  If anything more complicated
is required, we're into queuing,
> replay, etc., which GetCurrentMessage isn't intended to support.
> 
> For what it's worth, this also takes care of the question of faults.
 With 
> GetCurrentMessage and Subscribe subsumed by the same message, there
is by 
> definition only one set of faults.  Not a big deal, but the near-identity
of faults
> is probably a significant clue that the two operations are different
sides of the same coin.