Re: [wsn] Subscription termination and batched subscription

[David Hull <dmh@tibco.com>]

Steve Graham wrote:

>
> another approach is for the NP to describe (using Ws-Policy) some 
> notion of typical or maximal (or minimal) subscription duration.
>
> with respect to lease renegotiation dominating message traffic, that 
> is true if the duration of subscriptions was on the order of minutes. 
>  If this is typical, then this is a surprising policy choice and one 
> that I personally would not recommend.  Do you often see subscription 
> durations of this small a period of time in your customer scenarios?

With, say, 10,000 subscriptions, 10,000 refreshes is four orders of 
magnitude more than one.

This may be why there /is/ no concept of subscription leasing in our 
customer scenarios.

>
> sgg
>
> ++++++++
> Steve Graham
> (919)254-0615 (T/L 444)
> STSM, On Demand Architecture
> Member, IBM Academy of Technology
> <Soli Deo Gloria/>
> ++++++++
>
>
>
>
> 	*David Hull <dmh@tibco.com>*
>
> 05/21/2004 03:06 PM
>
> 	       
>         To:        wsn@lists.oasis-open.org, Amelia A Lewis 
> <alewis@tibco.com>, Shivajee Samdarshi <shivajee@tibco.com>, Don 
> Mullen <donmullen@tibco.com>
>         cc:        
>         Subject:        [wsn] Subscription termination and batched 
> subscription
>
>
>
>
> Consider a use case wherein a Subscriber wishes to make a large number
> of subscriptions with a given NotificationProducer.  The subscriber
> wishes to keep these open indefinitely, but the producer may or may not
> wish to grant an indefinite lease.
>
> From the WS-BN and WS-RL specs, it appears the best approach for the
> subscriber here is to give an initialTerminationTime of xsi:nil for each
> subscription and hope for a hint in any resulting fault messages as to
> what really to use.  The subscriber then keeps a priority queue of
> imminent expirations and tries to send and process renewal requests in
> time for each one.  Depending on the number of subscriptions, the volume
> of message traffic on them, and the lease time for each one, this
> refresh traffic could dominate the actual message traffic.
>
> This would appear to be a special case of batching properties across a
> large number of subscriptions.  One could imagine any number of QOS or
> security properties, for example, that could be constant across a large
> number of subscriptions.  Most of these would only matter at subscribe
> time, but the termination time property requires continual maintenance
> through the lifetime of the subscription.
>
> An obvious approach here would be to define a Session object, with its
> own lifecycle,  holding properties which could be overridden by
> individual subscriptions.  The subscriptions would have to be dependent
> objects of the session, garbage collected when the session goes away.
>
>