Re: issue 7970: new proposal

Oracle supports this proposal. We feel that it is important to allow for 
implementations in which multiple SOAP nodes transmit Notifications for 
the same Subscription.

- gp

On 11/3/2009 2:04 PM, Doug Davis wrote:
>
> After some talks with Ram about this one, we came up with a new 
> proposal that should allow the usecase I'm concerned about to work 
> while still allowing for the event source to be the one to send out 
> notifications:
> - - - - - -
> *Event Source *
> A Web service that accepts requests to create subscriptions.
> *
> Notification *
> A one-way message sent to indicate that an event, or events, have 
> occurred. Notifications MAY be sent by any endpoint including the 
> event source.
> - - - - - - -
>
> Also, as I was reviewing ws-eventing I noticed some other places where 
> we talk about the event source being the one to send notifications - 
> we should change those too:
>
> During that time, notifications are delivered by the event source to 
> the requested event sink...
> -- s/by the event source//
>
> the event source sends only notifications that match the requested filter
> -- change to: only notifications that match the requested filter are sent
> -- actually, we should change "notifications" to "events" too since we 
> don't filter notifications, we filter events
>
> The event source sends notifications until ...
> -- change to: Notifications are sent until...
>
> This specification defines a method for transmitting notifications 
> from the event source to the event sink through the use of the 
> wse:NotifyTo element.
> -- s/from the event source//
>
> I don't think these changes any have normative impact on the spec or 
> coding changes.  It just avoid any confusion that they might cause.
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
> The more I'm around some people, the more I like my dog.