Re: [wsn] WSN and WSRF

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

Hi David:
I respect that you have concerns here.
 But I fail to see the benefit of "duplicating" functionality
offered by WS-RF.  Having duplicate capabilities makes WSN harder
to implement.  

It seems we have 3 approaches here:
a) status quo with respect to WS-N reusing
functionality hardened by WS-RF
b) decouple the specs by repeating the
normative message exchanges from WS-RF in WS-N
c) duplicate the functionality required
to retrieve properties of various enties in WS-N and renew subscriptions.

Clearly a) seems to offer the best net
benefits of reuse, parsimony of definition etc.  We know this approach
works, we had an interop fest in mid-April.

With b), my question is, why duplicate
the description of the required functionality?  This seems to make
joint co-iteration of WSRF and WSN harder to do.  As it stands now,
the statement allows WSRF to evolve without having to repeatedly update
the normative message exchange statements in WSN.  Now, what are we
looking at here, a couple of examples:
WS-BaseN's NotificationProducer MUST
support GetResourceProperty and MAY support the other WS-ResourceProperties
operations.
Similarly, SubscriptionManager has the
same dependency on Ws-ResourceProperties and includes message exchanges
for the destruction (softstate and explicit destroy).

With c), I struggle to understand why
the WSRF approach is such a burden?  These are simple message exchanges,
and the functionality they represent is very important to WS-BaseN.  We
*could* duplicate these signatures, making it much more complicated for
applications that use WSRF and WSN together (duplicate functionality).
 This boils down to a trade-off here, duplicating functionality or
reusing existing (or in this case with WSRF, emerging) standards.  I
don't see the net benefit of duplication.

So, to your specific arguments, please
see <sgg>comments</sgg>:

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.

<sgg>I
seriously doubt that GetResourceProperty message exchange and the two destroy
operations add significant heft to Ws-BaseN.  I counter-argue that
having duplicate message exchanges defined specifically in WS-BASEN increase
its complexity (more message exchanges) and weaken the case for joint WSRF
and WSN implementations (less reuse)</sgg>

• 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.

<sgg>Do
you think WSRF is the most significant impediment to WS-E, Ws-BaseN reconciliation?
 There are separate namespaces for the messages for one, that strike
me as a bigger issue.  I have no doubt that it is possible to build
Notification without WS-RF, however, I don't see the reason to duplicate
the functionality when we have work underway to standardize that functionality.
 Why should softstate lifetime management on my subscriptions, for
example, be any different than the other resources I am trying to manage
lifetime on?</sgg>
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.

<sgg>You
are missing the re-use argument that is associated with the coupling.  furthermore,
the semantic subtleties are related to stateful resource management, those
certainly apply in WS-BaseN.</sgg>

• 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.

<sgg>So,
this circularity poses a problem to customers how?  Is this an aesthetic
concern or a tooling concern or a runtime concern?  Would you prefer
that WSRF *not* reuse WS-N and instead define its own idiosyncratic means
of notification?  Circularity exists.  For example, consider
Ws-Policy.  WS-Security Policy uses WS-Policy to describe metadata
about endpoint capabilities related to security.  Does Ws-Policy not
use Ws-Security for various encryption etc. to secure policy?</sgg>

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

<sgg>understood,
so the WSRF related tie ins will look like message exchanges to the requestor.
 Driving a GetREsourceProperty("Topics") operation doesn't
force the requestor to be intimate about WSRF.  Similarly, managing
a Subscribe::Renew() operation or  a SetTerminationTime operation
on the SubscribeManager seems to be equivalent to the requestor.  So,
the WSRF-aware requestor can reuse a lot of facilities to manage Subscription
resources and other resources.  One that is not aware of WSRF would
have to have some sort of Renew management function.  Why not reuse
WS-ResourceLifetime?</sgg>

• 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.

<sgg>Well,
why does a subscription not qualify as a WS-Resource?  It is a stateful
thing, accessed by Web services.  Further, if there are sharper examples,
please describe them.</sgg>

• 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.

<sgg>It
seems we have failed to properly position WS-RF.  I don't imagine
that WS-RF is positioned for "generic resources whose properties are
not necessarily known beforehand".  On the contrary, we imagine
that the schema of many Resource Properties documents will be well fixed
at design time by various standards bodies.  With respect to your
last sentence, I am not following you.  Getting information about
the value of a resource property of a subscription resource is a valid
but totally different question from the (also valid) question, get me the
EPR of this subscription.</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> 05/14/2004 04:55 PM

To:        wsn@lists.oasis-open.org         cc:                 Subject:        [wsn] WSN and WSRF

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."