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/.
|