Patil, Sanjay
wrote:
During the London F2F, I took an
action item for proposing text for the three issues that would
substitute the issue WSN2.2 (dependency on WSRF). Please
review.
This is basically good. Further
comments inline.
Thanks,
Sanjay
WSN2.23: Is Subscription a WS Resource?
Consequences of modeling Subscription as a WS Resource include
-
a>
Additional
Subscription Manager interface, separate from
Notification Producer
b>
Control messages
(pause/resume a subscription) are addressed to Subscription Manager and
reference to the actual subscription is implied.
Issue: Is this the right model? It is an architectural
issue.
There is the separate issue of the names here. I would prefer, say,
"SubscriptionFactory" (or perhaps "SubscriptionManager") for "The thing the
Subscriber uses to create subscriptions" and "Subscription" for "The thing you
send 'get*', 'pause,' 'resume' and 'terminate' messages to."
In particular, the term "SubscriptionManager" implies (to me) that
the endpoint is associated with some collection of subscriptions (i.e., the
subscriptions it is managing) instead of just one.
<Sanjay> How about --
Consequences of modeling Subscription as a WS
Resource include -
a> Additional interface for
managing the Subscription (SubscriptionManager), that is separate
from the Subscription factory (NotificationProducer)
b> Messages invoking the interface
for managing the Subscription (SubscriptionManager) have implicit
reference to the actual subscription
Issue: Is this
the right model? It is an architectural issue.
</Sanjay>
Specifications
Proposed Recommendations
Notes
This is the first out of the three issues substituting issue
WSN2.2
Status: Open
Contact:
David
Hull
Cross Reference:
Previous issue: WSN2.2
WSN2.24: Use of term -- Implied Resource Pattern
In several places in the specifications, references are made to IRP
and how its use is mandated.
Issue: The precise semantics of IRP is unclear and currently
being worked on by WS-RF.
Specifications
Proposed Recommendations
WSN
specifications to be updated based on the IRP revision under
WSRF.
Notes
This is the second out of the three issues substituting issue
WSN2.2
Status: Open
Contact:
David
Hull
Cross Reference:
Previous issue: WSN2.2
WSN2.25: Indirection via WSRP and WSRL
Instead of bespoke methods with explicit semantics, we utilize
WSRP and WSRL mechanisms to the same effect. For example, instead of
a method getTopic(), we say get resource property named topic. Another
example is termination of a subscription.
Indirection via WSRP and WSRL puts the burden on the specification to
not just specify the allowed operations but also clearly
spell out the operations that are prohibited.
Indirection also makes the spec harder to read, and gives more room for
ambiguity and misinterpretation. E.g., as it stands, it is not clear
when set* messages are valid and if so, what their effects are. We have
to define what exactly it may mean to (say) set the topic of an existing
subscription, so we should define this directly, in this case in terms of
SetTopic.
<Sanjay> I thought describing the semantics of each
update to a Subscription is essential, irrespective of whether the update is
done by invoking a bespoke method or by calling a
setProperty. Another issue you raised in the past - WSN2.20 (QoS
regarding change of subscription properties) may be representing this
concern. Do you agree?
</Sanjay>
Further, it's still TBD
whether setting properties is the best way to describe the actions involved in
subscription.
Specifications
Proposed Recommendations
Proposed Recommendations:
Define the core semantics in terms of
bespoke methods. Allow WSRP/WSRF methods, with their semantics defined
in terms of the bespoke methods. See "decoupled" draft for details.
<Sanjay> I will include this Proposed Recommendation in the
revised text </Sanjay>
Notes
This is the third out of the three issues substituting issue
WSN2.2
Status: Open
Contact:
David
Hull
Cross Reference:
Previous issue:
WSN2.2