Re: [wsn] WSN and WSRF

[Samuel Meder <meder@mcs.anl.gov>]

On Fri, 2004-05-14 at 15:55, David Hull wrote:
> This is issue 2.2 in the issues list.
> 
> The WSN documents currently contain statements of the form "A [WSN
> component] MUST support the required message exchanges defined in the
> WS-ResourceProperties specification ...".  While there is certainly a
> prima facie case for presenting entities with state and life cycles in
> a framework specifically designed for such entities, there are also
> several concerns with this approach.  A natural alternative is simply
> to describe what message exchanges the components must support, drop
> any normative reference to WS-RF, and optionally add non-normative
> language describing how these operations map to WS-RF concepts.

The problem I have with that is that it leaves large pieces of
functionality underspecified and will I believe make it harder to build
interoperable implementations. I think a better approach to take might
be to see if some of the functionality can not be made optional (but if
the option is taken it should require WSRF based message exchanges) and
to work with the WSRF TC to make sure that the WSRF specs allow for
light weight implementations.

> At this point, I would like to reiterate the arguments I'm aware of
> for this separation.  I'm not sure what is the best process to use
> here, but I would like to get some idea of what level of agreement or
> disagreement there is with each of these arguments, and also what
> degree of importance they may be thought to have.
> 
> 
> Pragmatic Arguments
>       * Entry barrier for WSN.  The lighter weight WSN is, the more
>         likely it is to be adopted.  Pulling in WS-RF appears to add
>         significantly to this weight, particularly at the BaseNT
>         level.  WS-RF is not just a set of message exchanges, but a
>         full conceptual model which appears orthogonal to the concept
>         of notification.  While this may be mostly a problem of
>         perception, perceptions do influence adoption.

It all comes down to the view on what a subscription is. Too me it
certainly looks like a piece of state that requires operations for
lifetime management and inspection, so I don't think that WSRF is that
orthogonal to notification. Again, I think that if the WSRF approaches
to these problems are too heavy weight then we should work with the WSRF
TC to make sure they can be as lightweight as we need them to be.

>       * Barrier to reconciliation with WS-Eventing.  WS-E is
>         completely independent of WS-RF, but covers largely the same
>         concepts as WS-BaseNT.  Take WS-RF out of the equation and the
>         reconciliation becomes much more straightforward.  WS-E also
>         provides a simple proof-by-example that Notification as a
>         concept does not depend on WS-RF.

The fact that it doesn't depend of WSRF doesn't mean that it shouldn't
;)

> Structural arguments
> 
>       * Coupling. With WSN bound to WS-RF, potential changes to WS-RF
>         become potential changes to WSN.  Similarly, any semantic
>         subtleties in WS-RF are brought over to WSN, whether they
>         directly apply to the Notification pattern or not.
>       * Circularity.  WS-RF intends to use WSN as a mechanism for
>         signaling state changes in resources, while WSN in turn uses
>         WS-RF to describe subscriptions etc.

I don't recall any normative language in the WSRF specs requiring WS
Notifications (but my memory is notoriously poor), but I agree that
there certainly is some preferred treatment of WSN.

>       * Separation of concerns.  Notification can be used in contexts
>         outside WS-RF, and so should independent of it.

[see argument under first pragmatic bullet]

>       * Action orientation vs. resource orientation.  This may be a
>         more philosophical point, but it can be argued that "renew
>         subscription" is a more direct and accurate analysis than "set
>         the lifetime of the subscription resource."  There may be even
>         sharper examples.

So you fundamentally disagree that the pattern outlined in WS-Lifetime
is worth standardizing? 

>       * Inappropriate generality.  WS-RF is evidently aimed at a
>         generic resource whose properties are not necessarily known
>         beforehand and may even change dynamically.  WSN is a
>         standard, whose properties are by definition fixed.  It seems
>         inappropriate to say "get me the value of the endpoint 
>         property of this subscription resource" as opposed to just
>         "get the endpoint of this subscription."

I don't think you disagree with the statement that the subscription
manager porttype manages state, correct? Do you agree that it is worth
standardizing on a set of operations for state inspection and state
lifetime management? If you answer yes to the above to I don't see how
you can maintain the position that the 3 WSRF operations WS-N uses are a
bad thing? WS-N does after all not use the full WSRF framework. The WSRF
methods you have to implement are actually fairly trivial IMO.

Also, would you rather have:

* get property for subscription

or 

* get consumer endpoint for subscription
* get lifetime of subscription
* get topic expression of subscription
* get use notify of subscription
* get precondition of subscription 
* get selector of subscription
* get subscription policy of subscription
* get creation time of subscription


To me it seems that the interface becomes a lot less cluttered with "get
property for subscription".

/Sam 

-- 
Sam Meder <meder@mcs.anl.gov>
The Globus Alliance - University of Chicago
630-252-1752