RE: [wsn] "despite some wording in the introduction"

["David A. Chappell" <chappell@sonicsoftware.com>]

+1.  I agree with the third pattern, but was not in favor of the
proposed text that stated "The NotificationProducer arranges for the
proper notifications to reach the NotificationConsumer...".  The
"arranges for" implies that the producer has the smarts to do that kind
of thing.  That may be a valid implementation, but it makes more sense
for that delegation to be more transparent to the producer.
Dave

> -----Original Message-----
> From: Peter Niblett [mailto:peter_niblett@uk.ibm.com] 
> Sent: Monday, July 19, 2004 10:05 AM
> To: David Hull
> Cc: wsn@lists.oasis-open.org
> Subject: Re: [wsn] "despite some wording in the introduction"
> 
> 
> 
> 
> 
> David
> 
> I suggest that the issue be called "Indirect Notification 
> Pattern", and that it goes in chapter 1 of the issues list - 
> i.e. WSN 1.6, but as you point out it also has a bearing on 
> BaseNotification.
> 
> How about...
> 
> WSN:1.6 Indirect Notification Pattern
> 
> The WS-Notification specifications call out two distict 
> notification patterns,
> 
> 1. "direct notification"  where a subscriber places a 
> subscribe request against a specific NotificationProducer, 
> and the NotificationProducer delivers notfication messages to 
> the nomininated NotificationConsumer
> 
> 2. "brokered notification" where a subscriber places a 
> subscribe request against a NotificationBroker, and the 
> NotificationBroker forwards notification messages to the 
> nominated NotificationConsumer; these notification messages 
> originate from other source(s).
> 
> However there is a third pattern:
> 
> 3."indirect notification", This third pattern combines 
> elements of the previous two. A subscriber places a subscribe 
> request against a specific NotificationProducer and that 
> NotificationProducer delegates the job of delivering the 
> Notification messages to the nominated NotificationConsumer 
> (and possibly managing the subscriptions) to another 
> intermediary service.
> 
> This issue states that this third pattern should be 
> explicitly called out as valid, and that any wording in the 
> various specifications that states that it is invalid should 
> be corrected.
> 
> Specifications
> 
> -  WS-Notification whitepaper
> -  WS-BaseNotification
> 
> Peter Niblett
> IBM Senior Technical Staff Member
> 
> 
> 
> 
>                                                               
>              
>              David Hull                                       
>              
>              <dmh@tibco.com>                                  
>              
>                                                               
>           To 
>              18/06/2004 21:56          
> wsn@lists.oasis-open.org            
>                                                               
>           cc 
>                                                               
>              
>                                                               
>      Subject 
>                                        [wsn] "despite some 
> wording in the  
>                                        introduction"          
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
>                                                               
>              
> 
> 
> 
> 
> Lines 105-110 of the 17 June draft read:
> 
> 
>       The NotificationProducer maintains a list of subscriptions (each
>       subscription entry contains the Topic(s), a reference to the
>       NotificationConsumer and possibly additional 
> information). When it
>       has a notification to distribute, the 
> NotificationProducer matches
>       the notification against the interest registered in 
> each Subscription
>       known to it. If it identifies a match it issues the 
> Notification to
>       the NotificationConsumer associated with that Subscription.
> 
> 
> First, technically the NotificationProducer would maintain a 
> set of subscriptions, not a list (list implies ordering and 
> allows duplication, set is unordered and without duplication, 
> albeit subscriptions can be identical in everything but their 
> unique ID).
> 
> More importantly, my understanding is that the interactions 
> defined in WSBN are common to all delivery methods, whether 
> direct, brokered, gatewayed or whatever else.  If I want to 
> make a subscription, I subscribe, and it's up to the rest of 
> the system to decide how the notifications reach the consumer.
> 
> Similarly, lines 114-117 strongly imply that WSBN covers only 
> the direct scenario, and that direct and brokered are the 
> only games in town:
>       The configuration where a NotificationConsumer is 
> subscribed directly
>       to the NotificationProducer is referred to as the "direct" or
>       "point-to-point" notification pattern. There are other 
> variations of
>       the Notification pattern, where the NotificationConsumer is
>       subscribed to an intermediary NotificationBroker 
> service. These are
>       covered by the [WS-Brokered Notification] specification.
> I would propose to strike 114-117 entirely, and replace the 
> passage from 105-110 with "The NotificationProducer arranges 
> for the proper notifications to reach the 
> NotificationConsumer, whether by notifying the 
> NotificationConsumer directly or by delegating to some other 
> facility."
> 
> 
>