Re: [wsn] Value/weight added by WSRF

[Steve Graham <sggraham@us.ibm.com>]

Hi David:
As currently stated, the WSRF WS-ResourceProperties
message exchanges WSBN MUST support is GetResourceProperties. Your statement
that WSN MUST support GetMultipleResourceProperties is incorrect.

With respect to WSBN supporting the
other, optional WSRF WS-ResourceProperties message exchanges, these are
optional.  If there is some need for the WSBN NotificationProducer
to support GetMultipleResourceProperties and QueryResourceProperties, then
the semantics of these are pretty straight forward.  With respect
to SetResourceProperties, I understand your reluctance here to specify
some sort of Admin semantics for NotificationProducer.  With respect
to the ResourceProperties on Notification Producer, Topics, FixedTopicSet
and TopicExpressionDialects are all likely to be marked as "read=only".
 There is a WSRF issue (Issue
WSRF10: Need mechanism to express metadata on properties such as ‘read-only’)
that should result in a way to specify that SetResourceProperties should
not be used on the RPs defined for NotificationProducer.  Note, however,
that NotificationProducer may be "mixed in" with other domain-specific
RPs that allow SetResourceProperties modification.

Note, however, that Topics can be added
and removed to this list by implementation private API.  If the FixedTopicSet
is marked as "false", then the set of Topics supported by the
NP may change over time.  

Note also, that on SubscriptionManager
portType, the RP values on individual subscription WS-Resources MAY be
changed using SetResourceProperties, this provides a very interesting "change
subscription" possibility. 

So, regardless of whether we specify
the semantics explicitly in BaseN as separate operations or as constraints/restrictions
on the ResourceProperties, the work is pretty much the same.  My position
is that I would prefer to reuse WSRF for as much of this as makes sense.

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> 06/07/2004 01:31 AM

To:        wsn@lists.oasis-open.org         cc:                 Subject:        [wsn] Value/weight added by WSRF

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.