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/>
++++++++
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/>
++++++++
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.
|