OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-dd message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Reformulation of comments on WS-RA WS-Eventing draft


Hi,

following the last TC audio, I try here to prioritize my comments on WS-Eventing, starting with the highest priority. Although they address the same concerns, some of them have been rewritten to hopefully make them clearer.

Cheers

Antoine

--------------------------- WS-Eventing issues -------------------------------------------------------------------------

1) A mechanism to relate the portType(s) of an event source Web Service to the abstract description of the events it can produce is needed. This mechanism cannot be solely based on WS-Mex, as this information may be needed by clients at design time, before any service endpoints is available.

The draft replaces the previous mechanism for advertising events produced by a source, based on a portType extension (using both the wse:EventSource attribute and notification and solicit/response operations), by two new mechanisms, one introducing a new language (Event Descriptions), the second one using a WSDL definition for the sink. Both mechanisms provide an abstract description of the events, but no mechanisms to relate them to the portType of the event source. Rather, it is suggested to use new WS-Eventing dialects in conjunction with WS-Mex to retrieve the descriptions at runtime.

A proposal to solve this issue could be:
a) For Event Descriptions:
- Introduce the Event Description language as a standard extension to WSDL 1.1, thus allowing Event Descriptions to be embedded in the local WSDL or imported from another WSDL.
- Optionally, introduce a new EventSet or EventInterface element in the Event Description language. This element would allow grouping of eventTypes in a single element, thus making external reference easier (much like a portType groups several operations).
- Introduce a new wse:EventSet (or wse:EventInterface) attribute, holding a QName, that could be used in WSDL portTypes to reference the EventSet element representing the list of events that can be produced by the portType. Alternatively, if the EventSet element is not introduced, introduce a new wse:EventTypes attribute, holding a list of QNames, that could be used in WSDL portTypes to reference the list of eventTypes representing the list of events that can be produced by the portType.

b) For Notification WSDLs:
It is simpler, as the Notification WSDL could be directly inserted in the event source WSDL, or imported by it. The only extension required would be a new wse:NotificationPortType attribute that could be used in WSDL portTypes to reference the Notification Port type, which defines (although looking at them from the sink perspective) the set of events that can be produced by the portType.

2) A mechanism to advertise the set of bindings supported by an event source/subscription manager to send notifications is needed, along with a mechanism to select the appropriate binding based on the notifyTo EPR.

This problem is not new and was already present in the version referenced by DPWS. For DPWS per se we don't really have a problem, as we assume the DPWS binding (SOAP1.2 over HTTP + WS-Addressing) by default. However, in many cases other bindings may be required: Basic Profile 1.1, WS-MakeConnection, SMTP, WS-Security+WS-RM, etc... Note that the proposal outlined below is a little bit complex, so may indeed have to be profiled out by DPWS if it is taken into consideration.
 
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 we 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. 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. A better 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 even WS-MakeConnection).

3) Clarify that notifications are sent by the subscription manager, and not 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.

4) Minor comments / requests for clarification

* 4.4 Unsubscribe: the text references faults defined for Renew, mentioning that they are also applicable to Unsubscribe. However, the only fault defined in Renew is UnableToRenew, which does not seem applicable to Unsubscribe.

* Renew/Unsubscribe: the status of the subscription after the processing of either request failed could be clarified.

* 5. Notifications: Uses of XPath expression /s:Envelope/s:Body/wse:Subscribe/wse:NotifyTo/ should be replaced by /s:Envelope/s:Body/wse:Subscribe/wse:Delivery/wse:NotifyTo/.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]