[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsn] Subscription leasing, garbage collection and scalability
From the service point of view, this is a GC, and it's a matter of policy. But I think time-scheduled termination from the requester is about the control, not really about GC policy. I need "event based" lifetime control both from the service provider's point of view and from the requester's point of view, such as "subscription can be terminated when ..." . well, you can see the timed termination is an event as well. I was directed to WS-DM for more complicated lifetime management on the WS-R, which I haven't looked yet. Perhaps this policy matter and scheduled termination can borrow some ideas from (or directed to) WS-DM if more than a simple initialTerminationTime is needed ? --Alex David Hull wrote: > I find this all somewhat dissatisfying. > > As far as I can tell, what we're really doing here is determining a > policy for GC. Scheduled termination may or may not be directly > relevant. I would rather address the issue at policy level. I can see > several possible policies: > > * Implicit: We are gatewaying to some underlying facility with its > own mechanism. > * Subscriber lifetime: Subscriptions die when the subscriber dies > (this in turn could be done through scheduled termination or > implicitly) > * Consumer lifetime: Subscriptions die when the consumer dies > (same remarks apply) > * Scheduled termination at the subscription level > > Only in the last is the initialTerminationTime parameter relevant. > > Also, at the risk of reopening a closed discussion, it seems that > there are arguments for scheduling termination using either absolute > or relative time (expire at this time vs. expire this long from now). > This would fit easily within the policy framework. With the current > approach initialTerminationTime becomes overloaded, being either a > time or a duration. > > Steve Graham wrote: > >> >> Hi David: >> ok so lets examine a scenario. >> >> The scenario is that the NP does not wish to particpate in scheduled >> termination (leasing, for whatever reason, is something it simply >> doesn't want to get involved with). So, in this case, the NP will >> rely on some other means to destroy subscriptions, either the good >> graces of the subscribers to let the NP know when they are done, or >> some other means that results in the equivalent of the destroy >> message being processed on a subscription WS-Resource. >> >> So, this would then boil down to the subscribe request including an >> initial termination time of xsi:nil (If the value is xsi:nil, then >> the intent of the service requestor is to specify there is no >> scheduled termination time for the WS-Resource.). This would be the >> only value of InitialTerminationTime that the NP would accept. Any >> other value would cause the subscription request message to be >> rejected and a fault response generated. >> >> Now, how the heck does the subscriber know to do this? Darn good >> question. Perhaps if we consider the following additional >> resourceProperty, we may have a solution? >> >> - add the following to BaseN (resource Properties for the NP): >> <xsd:element name=”UsesScheduledTermination” type=”xsd:boolean” >> minOccurs=”1” maxOccurs=”1” default="true" /> >> >> and the following normative text: >> /wsnt:UsesScheduledTermination >> >> Indicates if the NotificationProducer uses the ScheduledTermination >> time mechanism for subscription WS-Resource lifetime management. If >> the value of this resource property is "true", then the subscriber >> MUST include a time value for the InitialTerminationTime component in >> any Subscribe request message (xsi:nil is not accepted). If the value >> of this resource property is "false" then the only value of >> InitialTerminationTime that will be accepted on the Subscribe request >> is xsi:nil. >> >> Some policy assertion or type-specific extension of the interface >> could indicate to the requestor the "other" mechanism of subscription >> resource management. >> >> thoughts? >> >> (btw, I am out of the office as of 05/24/04 and will not be back >> until 06/01/04). I will weigh in on this email thread when I am back >> on line. >> >> 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/24/2004 09:26 AM >> >> >> To: Steve Graham/Raleigh/IBM@IBMUS >> cc: wsn@lists.oasis-open.org, wsrf@lists.oasis-open.org >> Subject: Re: [wsn] Subscription leasing, garbage >> collection and scalability >> >> >> >> >> Steve Graham wrote: >> >> David: >> ok, make a proposal. Perhaps we should consider incorporating any >> proposal here back into WSRL. Potentially, the solution you suggest >> may be more broadly applicable than just subscriptions? >> My thinking was that WS-RL would be the place to talk more >> specifically about other solutions. Sessions imply some means of >> tracking object dependencies, so that when the managed object >> (session) goes away, the dependent objects (subscriptions) go away >> too. Definitely bigger than a breadbox. >> >> Similarly, WS-RF may want to deal with the concept of a parent object >> carrying default values for properties of dependent objects. Being >> able to deal with this generically might be a good argument for the >> proprieties-based approach. >> >> For WS-BN, the more important consideration is to stay out of the way >> so that whatever emerges from WS-RL can be leveraged, and that >> existing systems that already provide GC functionality will play >> seamlessly. >> >> For the latter, all we need is to make sure leasing is optional. As >> we discussed in Chicago, it is effectively optional now, but in an >> indirect way. Perhaps a better approach is >> >> * Make the initialTerminationTime element optional. If it is >> absent, GC is to be handled by some other (unspecified) means. >> * If the producer requires leasing, it should fault if the >> initialTerminationTime is missing >> * Similarly, if the producer does not support leasing, it should >> fault if the initialTerminationTime is present. >> * Otherwise, follow the existing semantics. >> >> >> 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>_* <mailto:dmh@tibco.com> >> >> 05/24/2004 08:52 AM >> >> >> To: _wsn@lists.oasis-open.org_ >> <mailto:wsn@lists.oasis-open.org> >> cc: >> Subject: [wsn] Subscription leasing, garbage collection >> and scalability >> >> >> >> >> >> I believe the upshot of the previous exchange is, if you expect a >> subscriber to make a lot of subscriptions, the lease time had better be >> long or indefinite. In fact, from the producer's point of view, if you >> expect there to be a lot of subscriptions, period, the lease time had >> better be long or indefinite. >> >> In other words, the only method that WS-BN provides for garbage >> collection of subscriptions should be effectively disabled precisely >> when it is most likely to matter. >> >> I think the problem here is that WS-BN addresses subscription leasing >> and not garbage collection per se. This doesn't mean that it should try >> to provide all possible means of garbage collection, only that it should >> specifically point out a need, allow for as wide a range of solutions as >> is feasible, and point to subscription leasing (a la WS-RL) as one >> solution. This is essentially the same road we went down with topics. >> >> The more I consider leasing of individual subscriptions, the more >> potential technical issues I see. Obviously, none of them is >> insurmountable -- they have all been addressed and solved in other >> contexts. But each carries weight for the potential implementor. I'm >> willing to drill down on these a bit if needed, but I'm hoping we can >> avoid this and take a higher-level decision that leasing of individual >> subscriptions, while useful in some contexts, should not be required or >> be the only possible GC mechanism. >> >> With that provisional assumption, the immediate question becomes how can >> we allow for session-based garbage collection without adding undue >> weight to the WS-BN framework. Sessions have their own technical issues >> and implementation weight. >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]