Value/weight added by WSRF

[David Hull <dmh@tibco.com>]

Apart from the issue of subscription termination, WSN makes more basic use of WSRF: the various resources are meant to follow WSRF in the getting and setting of properties, as in "MUST also support the required message exchanges defined in the WS-ResourceProperties specification and MAY support the optional message exchanges defined in the WS-ResourceProperties specification."

As I understand it, this means that WSN MUST support access to these properties through a get and a getMultiple message, and MAY also support

• Update of single or multiple properties
  
• Insertion of properties
• Deletion of properties

WSN itself then enumerates what the properties are for the various resources.

What it doesn't enumerate is what it might mean to set, delete or re-insert these properties, or to insert additional properties.  Indeed, at first blush it would appear that many or most of these properties are meant to be set on instantiation and left alone.  Further, I think that there is a strong argument that WSBN should not even try to specify an administrative interface for, say, changing a NotificationProducer's list of topics.

In any case, the spec as it stands essentially says "Here are the properties you can inspect.  You MAY also be able to modify them arbitrarily, remove them or add new ones.  We don't say what effects any of this may have on future or existing subscriptions."  This seems significantly underspecified.  To cure this, we need to classify properties as

• Immutable -- if you want a different value, you need a different parent object.
• Possibly mutable, but outside scope.  E.g., the topic list.  This means that the value may change from query to query, but we don't specify a means of changing it.
• Mutable and in scope.  We specify a means of changing the value, along with any restrictions.  This could include the termination time of a subscription under scheduled termination.

I don't see any meaningful use cases for deleting or inserting properties.

In addition, we need to say what happens in cases like a topic being removed from the topic list while subscriptions  to it are still extant.

I'm convinced that by the time we specify all this, the general "MAY support the optional message exchanges" passage will hinder more than help.  Without it, the spec will basically say "These parameters are immutable.  You may perform the following operations to modify a subscription.  The administrative interface for modifying the parameters of a Producer are not specified here.  Subscriptions [do/do not] spontaneously change to reflect the current state of the NotificationProducer that spawned them.

With it, the spec would basically say "You can try to set any combination of these parameters.  You can try to remove them or add new ones, but it won't work.  These parameters are immutable . . . "  I don't see what this adds.  It does, however, add to the implementor's burden.  A server implementation must be sure to flag inappropriate WSRF usages and to interpret legitimate set messages in terms of their real semantics.

If instead there is a small set of specified methods that can affect the state of a resource, then the implementor knows exactly what to handle.  There is no question of ignoring or rejecting a request to remove the topic list property because no one will be able to ask such a thing.

Put another way, we will have to specify a set of legitimate operations in any case.  Given that, it seems better to represent them directly in the spec than to cast them into a framework in which anything MAY go but actually won't.