RE: [wsn] Use cases: Durable Subscription

[Lily Liu <lily.liu@webmethods.com>]

Excellent points. Please find my two cents inline.

> -----Original Message-----
> From: David A. Chappell [mailto:chappell@sonicsoftware.com]
> Sent: Wednesday, January 12, 2005 3:04 PM
> To: Rick Cobb; wsn-oasis (E-mail)
> Subject: RE: [wsn] Use cases: Durable Subscription
> 
> 
> 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. 
<lily>
Yes, these cover some typical durability cases and are enough to get us
started.
</lily>

>    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?
<lily>
For prolonged outages, it is much easier to establish a new connection
session rather than trying to restore an existing one. It is extremely
important to keep messages beyond the current session.
</lily>

> 
> 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?
<lily>
It seems more straightforward to make durability a property of a
subscription. Should we allow users to change it during the lifetime of the
subscription?
</lily>

<
> - What do we call this thing?  JMS calls it a durable subscription.
> Should we adopt that terminology or create something new?
<lily>
The JMS term is a good choice since it is widely accepted.
</lily>

> - 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.  
<lily>
It can make things easier if the durability of the subscription is the same
as the lifetime of the subscription. Message expiration is a separate
concept. Do we have a concept of message lifetime in WSN? Should we discuss
that too?
</lily>

> - 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.
<lily>
Agreed. I believe JMS says that too.
</lily>

> - 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?
<lily>
Does this topic expression contain enough information to identify the
subscription? If so, I think it will be fine.
</lily>

> - 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.
<lily>
I agree. I think in-order delivery should be a QOS of the subscription
regardless whether it is durable or not.
</lily>


> - 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.
<lily>
Yeah, RM is supposed to. On the other hand, whoever interacts with WSRM can
advertise an in-order delivery as a QOS of the subscription.
</lily>

Lily

> -----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
> 
>