Re: WS-Eventing optionality analysis

Gilbert Pilz <gilbert.pilz@oracle.com> wrote on 10/04/2010 07:06:25 PM:
> I think that the problem with both the current spec and your 
> comments below is that the way the terms "expire", "expiration" etc.
> are used is conflating two separate concepts. One of them (which you
> refer to as the "expiry feature") concerns the resource management 
> strategy employed by the subscription manager to manage the 
> resources associated with a subscription; the idea that every 
> subscription will be automatically cleaned up a specific, known time
> etc. The other concerns the existence (or lack thereof) of an agreement
> between the subscriber and the subscription manager as to if/when 
> the subscription will be automatically deleted. This conflation of 
> these two ideas is causing problems.

Do you purposely say "automatically cleaned up" in one spot and 
"automatically deleted" in another?  I'm just curious if they
mean the same thing or not.  To me they do so I'll assume they do
to you too.

To me you can't separate these two as part of the protocol.  W/o the 
"automatic cleanup" due to a timeout feature, you have no need for the 
Expires element at all.  Said, another way, if Subscriptions were never
"automatically cleaned-up" due to time, and people had to call 
Unsubscribe,
there wouldn't be the need for this negotiation at all.

> First, there is no reason for a subscriber to want or need to know 
> anything about the resource management strategies used by the 
> subscription manager. Any attempt to communicate this information 
> represents a hole in our abstraction of a subscription manager - a 
> hole that can only cause misunderstandings and interoperability 
> problems. 

The only reason to not communicate this information is if it doesn't
matter.  But knowing when a Subscription will be "automatically 
cleaned-up" could be vital to a subscriber otherwise they'll never 
know when to call Renew. 

Your first sentence is very confusing to me.  If we accept the notion
that Expires in some form needs to remain (which I think everyone will
agree to), then how can a subscriber not want/need to know what the
resource management strategy is?  At least w.r.t. this notion of
"automatic cleanup" due to time.  That's really all Expires is about. 
Remove the desire to explain _when_ this "automatic cleanup" will happen
and you remove the need for Expires.  Unless you don't consider
"automatic cleanup" due to tie to be part of the "resource management 
strategy".
(I discuss this "part of" notion a bit later on)

> For an example, consider the disconnects around the use of
> the phrase "indefinite" and the value "PT0S". Some people seem to 
> think it means "never", others "a really, really long time" and 
> others simply "you don't know". The idea of an "indefinite 
> expiration" is both useless and dangerous.

Aside from some of our private IMs, I've never heard anyone refer to it
as "you don't know".  And "never" and "a really, really long time" are, 
for
our purposes, the same thing.  If there are words in the spec to imply
that PT0S/indefinite means "dunno" then we need to fix that because that
level of uncertainy is asking for an interop problem.  Can you show me 
where in the spec "dunno" might be implied?  I find text like this:
  If this element does not appear, then the subscription will not 
  expire. That is, the subscription has an indefinite lifetime. Likewise,
  a value of PT0S indicates that the subscription will not expire. 
Which is pretty clear to me that its not "dunno".

> Secondly, we have to keep in mind that there are many different ways
> to manage the resources associated with a subscription. One strategy
> could be to simply monitor the level of various critical resources 
> and, when these reach a low water mark, start deleting subscriptions
> on a least recently used basis. A subscription manager that 
> implements this strategy can not tell you when, or even if, it is 
> going to "expire" a subscription - whoever implemented it probably 
> wasn't even thinking in those terms. It's simply not true to say 
> that "all subscription managers implicitly support the notion of 
expiry".

This is mixing topics.  While a Subscription Manager may choose to
have this kind of resource management code, this is separate from the
"automatic cleanup" code that is tied to the Expires element.  And
it would be a mistake to call this kind of cleaning up "subscription
expiring" - at least per the current spec's use of the term.  Today,
the Expires element and the notion of "expiry" are all based on time.
Yes there may be other factors when determining when to "automatically
cleanup" a subscription, but those are out of scope of the spec and 
the expiry feature (and therefore the Expires element).

It seems to me that the real issue coming from this "low water mark" 
type of example is whether or not it triggers the EndTo processing,
not how its related to Expires/expiry/timeout.  Think of it this way...
there are potentially many ways a Subscription could be deleted.
Unsubscribe and "expiry" are just two of them.  Each of these are
well defined in terms of what the protocol elements mean w.r.t.
this part of the resource mgmt code.  This doesn't mean there couldn't
be other aspects of the resource mgmt code - it just means we're not
touching on them in the spec.  Section 4 of the spec include this:
  In addition, the Event Source/Subscription Manager MAY cancel a 
  subscription at any time, as necessary. 
I think your "low water mark" example falls into that category. I
just don't know if it is considered "unexpectedly" and should
trigger the EndTo processing - or not.  Perhaps the spec needs to
clear that part up?  I'm leaning towards saying it should trigger
it since its deleting the Subscription for reasons that are not
covered by the spec, but if some extension defines it in such a way
as to make this trigger "expected" to a Subscriber then we're back
to not triggering EndTo. Sigh.

> I think that, to be of any use at all, we need to narrow down the 
> definition of "expiration" to refer to "the agreement between the 
> subscriber and the subscription manager on when then subscription 
> will be automatically terminated". 

To me it already means this and I'm still not clear on where in the
spec it implies anything else.

> We might even want to change all 
> occurrences of the English word "expiration" to "subscription 
> expiration". This is analogous to the stock trading term "stock 
> option". In English, the word "option" means very loosely "the 
> right/ability to do something", but in context of equity trading a 
> "stock option" refers to an explicit, legally binding agreement 
> between two parties. We need the term "subscription expiration" to 
> have the same flavor.
>
> Finally, we need to reduce the number of ways that the WS-Eventing 
> protocol signals the existence (or lack thereof) of subscription 
> expiration agreement. 

I'm not following this.  The presence or absence of the Expires element
has no impact on whether there is an agreement around expiration.
Per the spec today, the absence of the Expires element implies PT0S.
  If this element is not present, the implied default expiration time 
  is indefinite. A value of PT0S indicates a request for an indefinite 
  expiration time. 
This means that it has the same semantics as Expires+PT0S.  While this
does mean that there are two ways of saying the same thing, I don't
think this it introduces any confusion around the expiry feature.
We can remove the optionality of the Expires element if that helps, but
to me it was always just a handy short-hand notation.

Likewise, we have similar text for GrantedExpires.  Its absence is
equivalent to its presence+PT0S.
  If this element does not appear, then the subscription will not 
  expire. That is, the subscription has an indefinite lifetime. Likewise, 
  a value of PT0S indicates that the subscription will not expire. 

It may be confusing to some people that the text we use in each of
these cases is slightly different:
  will not expire
  indefinite lifetime
  indefinite expiration time
  expiration time is indefinite
and we can be more consistent if that helps.

> I think the following should apply:
> 
> 1. If the subscriber has no interest in whether/if the subscription 
> will be automatically deleted, it does not include the Expires 
> element in the Subscribe request. In such cases the subscription 
> manager MUST NOT include the GrantedExpires element in the 
> SubscribeResponse. The end result will always be that there is no 
> subscription expiration. If EndTo was specified, the subscription 
> manager MUST send a SubscriptionEnd message if/when it automatically
> deletes the message since there was no way for the subscriber to 
> know if/when this was going to happen.

I'm not in favor of introducing the notion of a subscriber having
"no interest in whether/if the subscription will be automatically
deleted".  Back in our MEX discussions we argued to remove the "whateva"
dialect - I'm not in favor of adding a "whateva" Expires time in 
WS-Eventing. :-)   In this case, as silly as it may sound, someone
can choose to make all "whateva" subscriptions exactly 1 second long
and be spec compliant.  I have no idea what Subscriber would ever
actually ask for this kind of randomness.  As you say later on,
if they really don't have a preferred timeout then they can use
@BestEffort with some Expires time.

> 2. If the subscriber needs to know whether/if the subscription will 
> be automatically deleted, but doesn't wish to "bid" a particular 
> time, it includes the Expires element with a value of "PT0S". If the
> subscription manager knows or can figure out if/when the 
> subscription will be automatically deleted, and it wishes to share 
> this information with the subscriber (i.e. it supports the 
> negotiation of a subscription expiration), it accepts the request 
> and indicates that time via the GrantedExpires element in the 
> SubscribeResponse. 

Now you're introducing quite a bit of ambiguity.  You've made PT0S mean
"don't care" and "live forever".  You've also introduced this notion
of "wishing to share" - this should never be an option.  Short hand
notations is one thing - but saying "dunno" is something very different 
and
not something we have in the spec today and I'm not infavor of adding it.

> GrantedExpires MUST NOT use the value PT0S, as 
> that doesn't tell the subscriber anything useful. 

I disagree that GrantedExpires/PT0S isn't useful.  Its very clear that
the Suscription will not expire.  This says nothing about other
subscription mgmt logic - it just touches on the timeout part of it.

> If the 
> subscription manager either can not or will not tell the subscriber 
> when the subscription will be automatically deleted (i.e. it does 
> not support the negotiation of a subscription expiration) it 
> generates the wse:ExpiresNotSupported fault.

Disagree with this too.  We're asking for an interop problem if
the two sides are not clear on when a subscription will be deleted
due to this timeout/expiry logic.  Even if its to say "it won't be".

Overall I disagree that anything in the spec today introduces the 
concept of not caring about this timeout stuff, or not negotiating it.
And I think it would be a mistake to introduce it now. Even missing 
elements that imply "never expire" are still negotiating are
communicating the agreed to values of the timeout.

It would really help me if we could back this discussion up and
you could point out the parts of the spec that are unclear or
introduce the ambiguity you're concerned about.  I don't see
where it says "no Expires", or PT0S, means "dunno". 

As I said above, if the terms we use in some spots need to be
tweaked then we should do so - but regardless of the wording 
we're using I think the intent was that the absence of the
Expires/GrantedExpires elements (and PT0S) means "will not be 
deleted due to time".

-Doug