Subscribe and GetCurrentMessage

[David Hull <dmh@tibco.com>]

One useful pub/sub paradigm involves the concept of notifications as updates to some collection of state.  In such cases, it is useful to be able to take a snapshot of the state, then be notified of updates to that state.  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.

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 currently can't handle this situation.  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).  Second, there is currently no way to guarantee that the subscription receives all and only all relevant updates.  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.

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.

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.