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

Geoff, you said ...
"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?"

WS-PAEPER was written because WS-Policy did not provide a mechanism for 
embedding metadata within an EPR.
It uses the <metadata> element, defined as a child of EPR by 
WS-Addressing, to contain metadata. Section 7 of WS-MEX recommends the 
same mechanism but with one curious change -- there is an explicit 
<policy> element defined as the child of the EPR. Why separate <policy> 
from other metadata?

If we remove the <policy> element from within the EPR then the two 
mechanisms are identical.
I'm inclined to raise an issue for this.

All the best, Ashok


Geoff Bullen wrote:
>
> 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
>

Received on Tuesday, 28 April 2009 13:02:57 UTC