Re: [wsn] WSN and WSRF

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

+1
I'm sold just on the 'separation of concern' argument.

-Anish
--


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.
> 
> 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.
> 
>     * *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.
> 
> 
>       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.
> 
>     * *Separation of concerns.  *Notification can be used in contexts
>       outside WS-RF, and so should independent of it.
> 
>     * *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.
> 
>     * *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."
>