Fwd: Comments on WS-Eventing Working Draft

fwd ro public comments list

Begin forwarded message:

> Resent-From: public-ws-resource-access@w3.org
> From: Antoine Mensch <antoine.mensch@odonata.fr>
> Date: October 13, 2009 2:19:38 PM PDT
> To: public-ws-resource-access@w3.org
> Subject: Comments on WS-Eventing Working Draft
> Reply-To: antoine.mensch@odonata.fr
>
> Dear colleagues,
>
> please find below some comments on the WS-Eventing Working Draft (http://www.w3.org/TR/2009/WD-ws-eventing-20090924 
> ).
> *
> 1) A mechanism to advertise the set of bindings supported by an  
> event source/subscription manager to send notifications would be  
> useful, along with a mechanism to select the appropriate binding  
> based on the notifyTo EPR.
> *
> In a context where an Event Source may use more than one mechanism  
> to send notifications to subscribers (e.g. a SOAP1.2 + WS-Addressing  
> binding along with a WS-MakeConnection binding), it would be useful  
> to specify a basic negotiation mechanism between event sources and  
> subscribers to help selecting the appropriate binding.
>
> a) The first question is how a list of supported bindings can be  
> exposed by an event source/subscription manager: the new  
> Notification WSDL mechanism would seem a good way of doing so (it  
> may include a binding in addition to a portType), however it is  
> defined as "A Notification WSDL describes the interface that the  
> Event Sink is required to implement to receive and process the  
> Notifications that might result from a successful Subscribe request  
> that used a particular Format URI". This means that if one were to  
> add several bindings for the same portType in the same Notification  
> WSDL, the semantics would be that the sink needs to support ALL of  
> them, and not AT LEAST ONE of them. By adjusting this definition,  
> the approach would support the advertisement of several bindings and  
> their policies. It could support in particular a binding supporting   
> WS-MakeConnection (although the semantics of the MCSupported  
> assertion would have to be a little bit tweaked for use in  
> Notification WSDLs).
>
> b) The second question is how a subscriber can select the  
> appropriate binding for receiving notifications: a first possible  
> approach would be to define new extension elements in the Subscribe  
> request to carry the selection criteria, but this would not be very  
> interoperable. Another solution could be to use the "notifyTo" EPR  
> extensibility to include in a standard way the selection criteria,  
> for instance using embedded metadata such as policies as specified  
> in section 7 of WS-Mex. Note that the use of metadata would not be  
> systematically required, as there are some cases where the binding  
> selection could be made by just looking at the "notifyTo" EPR  
> address (e.g. use of SMTP or WS-MakeConnection).
>
> 3) *Clarify whether notifications are sent by the subscription  
> manager or by the event source.
> *
> Section 3.4 Terminology says "Event Source: A Web service that sends  
> notifications and accepts requests to create subscriptions. ".  
> Section 2.2 Delivery says "A subscription manager MAY choose to  
> support mechanisms, such as the WS-MakeConnection specification, to  
> enable delivery of Notifications to non-addressable endpoints".  
> While in push mode it is not very important (except maybe in  
> security scenarios) to precisely know which endpoint is actually  
> sending the notifications, in WS-MakeConnection and other pull mode  
> scenarios, the subscriber must know where to go to get its  
> notifications. As the subscription manager mechanism provides  
> greater flexibility for the implementation, it should probably be  
> explicitly identified as the endpoint (or Web service) sending the  
> notifications.
>
>
> Best regards,
>
> Antoine Mensch
>