Re: [wsn] Subscription termination and batched subscription

[Steve Graham <sggraham@us.ibm.com>]

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?

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.