Re: [wsn] Draft of WS-BN decoupled from WS-RF

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

David,

Thanks for sending the alternate WS-BN. I think this is a step in the 
right direction -- allowing WS-N to be used without having to implement 
WS-RF, at the same time allowing WS-N to be used in conjunction with 
WS-RF (if so desired).

-Anish
--

David Hull wrote:

> As part of the ongoing discussion of WS-BaseNotification and its 
> relation to WS-RF, I have put together a very rough draft of an 
> alternate WS-BN spec which allows use of, but does not directly require 
> WS-RF.  That is, NotificationProducers and Subscriptions MAY be 
> presented as WS-RF resources, with the full set of message exchanges 
> that implies, but they do not need to.
> 
> As I understand it, this is consistent with WS-RF itself, which allows 
> resources to support message exchanges outside the WS-RF interfaces.  
> The draft defines a (small) set of get/set messages which are to be 
> implemented directly.  It also describes what the Resource Properties 
> document should look like (it looks like it always did) and mandates 
> that, e.g., /set /messages that don't make sense MUST fault.
> 
> Note that this can be done with /any/ stateful resource that uses WS.  
> The draft just nails down specifically how to do this for 
> NotificationProducers and Subscribers, leveraging the work that has 
> already been done.  Sections 4.4 and 5.6 could be left out entirely 
> while still preserving the core functionality.
> 
> The main changes in the draft (not all of which are essential to the 
> decoupling) are
> 
>     * Explicitly describing the use of Endpoint References in the spec
>       and the possible dependencies on other WS-specifications.
>     * Removing the "must follow the implied resource pattern"
>       boilerplate and clarifying the role of the ResourceProperties
>       element in the endpoint references.
>     * Removing language that suggests that the NotificationProducer MUST
>       produce notifications and making it clear that it can delegate. 
>       This suggests that "NotificationProducer" may not be the best name
>       for this entity, but that's a separate issue.
>     * Removing language that suggests that a NotificationConsumer must
>       be described in a WSDL.
>     * Renaming SubscriptionManager to Subscription, reflecting the fact
>       that you send, e.g., PauseSubscription to a particular
>       subscription and not PauseSubscription(subscription ID) to a
>       general SubscriptionManager.
>     * Adding an explicit DestroySubscription message and making use of
>       WS-ResourceLifetime optional.
>     * Giving Precondition and Selector their own types, for the same
>       reason that TopicExpression has its own type.
>     * Several other minor edits.
> 
> I've made one proofreading pass through the body of the spec and it 
> reads reasonably well.  I would recommend reading the version without 
> highlighted changes before delving into the highlighted version.  The 
> structure of the draft essentially the same as the original (that's the 
> whole point), but the minor changes are pervasive enough to make the 
> highlighted version difficult to read.
> 
> I have not updated the WSDL or XSD (yet).  They should not require major 
> changes.
>