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