Comments on WS-Eventing Working Draft

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

Received on Tuesday, 13 October 2009 21:20:11 UTC