RE: issue 6401: proposal for advertising WS-Eventing Notification types

Hi Gil,
We have some comments on this proposal for Issue 6401.

General comments:
We are in general agreement with the direction here and want to thank you for your work in creating this proposal.  We agree that it is acceptable to have a separate Notification WSDL to support definition of notifications and that this WSDL should use Input Only.  We also agree that it is acceptable to use Policy statements to hint locations of the Notification WSDL.

We do have some specific comments on the details of the proposal and would like to work with you and the WG to overcome these issues and work towards a proposal that will satisfy everyone.

Specific Comments:


A)  The proposal does NOT provide any justification as to why a new policy attachment mechanism (WS-PAPER) is required. The WS-MetadataExchange Section 7 [1] provides a general-purpose mechanism to embed metadata in an endpoint reference. Is that inadequate?  If so, why?


[1] http://www.w3.org/TR/2009/WD-ws-metadata-exchange-20090317/#Metadata-in-Endpoint-References



>"The lack of a wsp:Policy or wsp:PolicyReference in the wse:Metadata element of a wsa:NotifyTo EPR indicates a willingness/ability on the part of the Event Sink to support any of the policy alternatives in the Notification WSDL"


B)  The proposal does NOT provide any basis for the above conclusion.

The absence of policy expressions, for example, in a WSDL document or an EPR does NOT indicate ANYTHING about the capabilities and requirements of a service. A policy aware Web Services stack should not conclude anything about the absence of policy expressions.



In addition, the Web Services Addressing 1.0 - Core does NOT say that absence of policy expressions in an EPR/[metadata] property is equal to an EPR's willingness to support any behavior at a sender's discretion (where a sender could be an event source).


Does this mean the proposal puts new conformance requirements on a Web Service that is addressable by an EPR?  No implementations of WS-Addressing are currently required to exhibit these new requirements.


>"wsep:NotificationWSDL wsp:Ignorable="true""


C)  The proposal introduces a nested policy assertion to link an Event Source WSDL to an Event Sink (or Notification) WSDL. The link appears to carry additional useful information for engaging the WS-Eventing protocol behavior indicated by the WS-Eventing policy assertion. Should the link be represented as a nested policy assertion or a policy assertion parameter? We would recommend using a parameter - see [2] for discussion.



[2] http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/#parameterized-assertions



D)  The proposal appears to define a new app infrastructure-level policy negotiation mechanism using examples in pages 7-8. The mechanism makes a few assumptions:



o   An Event Sink (or Notification) WSDL is associated with an Event Source WSDL (one-to-one mapping)

o   Only endpoint policy subjects are (or must be) used

o   Absence of policy expressions indicates willingness to support any policy alternatives supported by an Event Source



Do you think WS-Eventing requires a WS-Policy negotiation mechanism?

If a policy negotiation mechanism is required shouldn't that be a general-purpose mechanism rather than WS-Eventing specific?

Best Regards,
Geoff


From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Gilbert Pilz
Sent: Friday, March 27, 2009 12:50 PM
To: public-ws-resource-access@w3.org
Subject: issue 6401: proposal for advertising WS-Eventing Notification types

As per ACTION-48<http://www.w3.org/2002/ws/ra/tracker/actions/48>, attached is my proposal for advertising WS-Eventing Notification types.

- gp