Re: [wsn] Proposed text for WSN2.2 substitutes

[David Hull <dmh@tibco.com>]

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.

Specifications

• WS-BaseNotification

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

• WS-BaseNotification

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.

Further, it's still TBD whether setting properties is the best way to describe the actions involved in subscription.

Specifications

• WS-BaseNotification

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.

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