Subscription termination and batched subscription

[David Hull <dmh@tibco.com>]

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.