Comments on WS-RA WS-Eventing draft

[Antoine Mensch <antoine.mensch@odonata.fr>]

Hi,

the following is a first set of comments on the WS-RA WS-Eventing draft.

Comments on new features:

I. Section 2.2 (relates to issue WSDD-6):
This section addresses the issue of non-addressable event sinks, by 
mentioning the possible use of WS-MakeConnection.
However, it fails to specify a number of important aspects that could 
lead to interoperability issues:
(a) To which endpoint should the <MC> request be sent: the event source 
(as the sender of notifications)? The subscription manager (as would 
seem to indicate this section)?
(b) What is the policy assertion used to specify available/required 
support for WSMC in an event source? The use of <MCSupported> normally 
means that the SubscribeResponse will be sent using WSMC, not the 
notifications. The notifyTo EPR validity check that is recommended in 
section 4.1 would probably result in a non-MC-aware event source 
accepting the URI as a valid http: URI. Does this mean that we need to 
define an additional SOAP header with mustUnderstand="true" to properly 
identify event sources that support this feature, as suggested in 
section 3.2?
(c) Although we could assume that the normal subscription life cycle 
applies, it could be useful to clarify some aspects, e.g. what happens 
if a <MC> request is sent after the expiration of the subscription?

My understanding is that the specification intends to leave the complete 
definition of the mechanism to another spec. However, I am not sure that 
in its current state, the WS-Eventing spec can be composed with the 
WS-MakeConnection spec in a non-ambiguous manner.

II. Section 9
WS-Eventing Policy Assertions mentioned but not defined in section 9.

III. Appendix A
The draft replaces the previous mechanism for advertising event sources 
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. The proposed mechanisms fail to 
capture two aspects that could be described with the previous one:
a) Association of events with a given portType: when using a 
late-binding mechanism such as WS-Discovery, which allows endpoints to 
be retrieved based on metadata information such as a portType, it is 
important that clients be programmed using information available in the 
abstract part of the WSDL (i.e. types, messages and portTypes). This was 
possible in the previous version, but does not seem to be in the new 
version, as there is no specified way of associating any of the two 
proposed mechanisms to a portType. In addition, some policy attachment 
would be required to specify that a given portType supports the 
subscribe operation.
b) Use of solicit/response operations: although I am not sure this 
feature was actually used, it was nevertheless possible to specify this 
type of interactions in the previous version, but not any more (at least 
using the Event Description syntax).


Editorial comments / requests for clarification:

The following is a list of mostly editorial comments, which in some 
cases were applicable to the previous version.

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

Cheers

Antoine