Use cases: Durable Subscription

["Rick Cobb" <rcobb@KnowNow.com>]

Thought I'd get the ball rolling on this with some small, perhaps a little unusual, cases.

Consumers that can not tolerate missed notifications in the case of (sometimes prolonged) network or system failure need durable subscriptions.  

Consider a notification producer (say, an RFID reader) which provides inventory change events (item foo walked out the door, item bar went on the shelf).  A consumer managing the state of inventory (there are 7 items with bar's SKU# on that shelf) can not maintain an accurate count unless it receives all notifications.  If the network fails, the producer (or an intermediate broker) must maintain enough state to replay any messages that happened while the consumer is unreachable.

This may be solvable with 'just' reliable messaging -- however, the time and overhead horizon can be large, and the consumer's actual addressing may change upon reconnection. For example:

Some applications which aggregate state (say a stock quote trend on a spreadsheet) are only occasionally connected.  Imagine the case where you regularly analyze stock trading trends on your laptop.  You want every bid and ask for a particular instrument to analyze the volatility of that instrument.  Now you get on an airplane, and play with your analyzation formulae while you're in the air.  When you land, you don't log in till the following morning, and you log in from your hotel.  You still want to receive all of the individual updates at this time to build your new trend state.

Now take a nice long holiday.  When you return, the notification producer (or broker) is unlikely to have retained all updates.  In this case, we have reached the point where the 'GetCurrentMessage and then updates' pattern would need to be applied (or, one would hope, someone might migrate to a better aggregator than Excel :-).

In the second case, the application can know when it is going to be off-line, and use pause/resume semantics.  In the first, network outages or system outages cause the fundamental inability to deliver the notification, so no pause/resume can be generated or expected.

-- ReC