RE: [wsn] Use cases: Durable Subscription

["David A. Chappell" <chappell@sonicsoftware.com>]

These are some good use cases.  I'm sure there are more we could come up
with, but this is enough to call out some fundamental issues.    This is
where queuing/replay semantics come into play.  The reliable messaging
protocol my work most of the time, but that's really a session oriented
thing.  Should the durability and replay of a message outlive a point to
point session between two endpoints?

We need to identify the issues and describe some rules for behavior.
- How does one specify durability? It sounds like something you do in
the subscribe operation...are there other ways to do it?
- What do we call this thing?  JMS calls it a durable subscription.
Should we adopt that terminology or create something new?
- What is the duration of the durability?  (How long do saved messages
need to be saved?).  We could use the termination time of the message
and do it on a per message basis.  
- Should we be prescriptive on when and how stored messages are
discarded?  I think we should keep that open to interpretation.  For
example, depending on the implementation the messages might be cleaned
up periodically or they could even be discarded during the replay itself
which could lead to expired messages showing up occasionally in
management tools that browse the stored messages.  As long as we state
that expired messages should not be delivered I think we're OK.
- JMS identifies the "reconnected" subscriber by using a combination of
a connection id and a subscription name.  What should we use? An EPR + a
topic expression?
- Do we need to flag a message when it has been stored and replayed?  I
think we should.  It can provide a hint to the receiver that there may
be side affects such as out of order delivery.
- Come to think of it, are there out of order delivery issues that we
need to deal with. As messages are being replayed, freshly published
messages could also be arriving at the same time.  Is that something
that can be addressed with the underlying RM processor?  It is supposed
to be able to handle that kind of thing, but we should think about
whether we need to specify anything else over and above that.

Dave


-----Original Message-----
From: Rick Cobb [mailto:rcobb@KnowNow.com] 
Sent: Wednesday, December 15, 2004 7:36 PM
To: wsn-oasis (E-mail)
Subject: [wsn] Use cases: Durable Subscription

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