Resources, lifetimes and notifications

[David Hull <dmh@tibco.com>]

In trying to reply to Samuel and Steve's concerns, I would like to step back from a point-by-point debate and try to understand the underlying issues.  Clearly both approaches are aimed at preventing redundant work, and each has an intuitive appeal.

WS-RF as I understand it is an attempt to abstract out the common behavior of stateful, distributed resources.  It is based on a model of inspecting and modifying resources, which is certainly a valid and well-researched model, but not the only one.  I'm afraid that going any further here could result in an endless debate over architecture, and I suspect we may at some point need to draw a line in the sand one way or the other.  For the benefit of the easily amused, I've appended my own rant on the subject below.

Leaving aside the issue of whether a parameter-centric approach is appropriate, I think the more important question is what functionality are we proposing to leverage?  I believe this must be more than "a resource is created, has things happen to it, and is destroyed."  From Samuel's note and Steve's point-by-point, I think the important addition is lifetime management.  That is, the ability to renew or curtail a subscription (or other resource), and implicitly be able to garbage-collect a subscription without an explicit destroy message from a subscriber that might have died or otherwise be indisposed.

I think this is a legitimate concern, and perhaps the immediate takeaway is to concentrate more on WS-ResourceLifetime than WS-RF as a whole.

I'll point out though, that in at least some existing/traditional/classic/whatever systems there is no explicit concept of a resource lifetime.  Indeed, this is one of the major novelties of both WS- incarnations of the concept.  I tend to think that subscription lifetimes are not essential functionality.  If subscriptions are associated with a subscriber, then it's enough to know when the subscriber goes away.

If the subscriber is done with a subscription, it'll let us know.  If it falls over, we'll find out through other means.  There are a number of ways to know if the subscriber has gone away.  They all amount to heartbeating, which amounts to lifetime management, but the question is what is actually explicitly exposed.

I hope that helps clarify the situation.

<rant>

For the record, I tend to think that set* methods give a dangerous false sense of simplicity.  In a real airplane, you don't want to set the position of the rudder and set the throttle on the engines and set the position of the flaps; you want to turn the plane.  Recasting "turn the plane" as "set the destination direction" seems counterintuitive on the face of it, but worse, implies that there is a single "direction" parameter.  Technically, setting parameters is really only simple and direct when the state space is the cartesian product of the parameter spaces.  Which it never is.  In particular, "set destination direction" and "get destination direction" are nowhere near as symmetrical as the parametric approach suggests.

Folding all set* methods up into a single "set parameter" method compounds the situation by erasing useful distinctions between the parameters and working against instead of with standard typing mechanisms.  If I have a "set destination direction" method, at least I know by looking at the interface that there is such a thing as a direction and what its type is.  If all I have is "set parameter" I then have to use yet another metadata system to understand that there is a "destination direction" parameter and what its type is.  Taking this to its logical conclusion, why not just have a single "Object" class and a single "Do operation" method, push the semantics into the operation descriptions and be done with it?  The result would be isomorphic to, but incompatible with, the existing system of interfaces and methods.

</rant>