- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Fri, 23 Feb 2007 14:47:00 -0500
- To: bob@freunds.com, public-ws-addressing@w3.org
- Cc: public-ws-policy@w3.org
- Message-ID: <OF768C2B88.2936C203-ON8525728B.006C6EC0-8525728B.006CACBB@us.ibm.com>
On behalf of the WS-Policy WG, here is our feedback on the WS-Addressing Metadata specification. The document specifies a wsam:Addressing assertion that has two nested assertions wsam:AnonymousResponses and wsam:NonAnonymousResponses assertions. Although the use of the wsam:Addressing assertion indicates a requirement, the nested assertions do not express requirements, thus dependent behaviors. The nested assertions appear to express support of a capability. In our opinion, this duality poses several problems related to both understanding the intent of the assertion and to utilization of the WS-Policy 1.5 Framework for purposes of intersection. These problems are noted below, followed by our recommendations to address the problems we highlight. (A) The presence of either of the two nested assertions does not indicate a required behavior. Further, per the statements in Sections 3.1.2 and 3.1.3, their absence does not indicate lack of support either: "The absence of the XX policy assertion within a policy alternative does not indicate that the endpoint will not accept request messages with response endpoint EPRs that contain the anonymous URI as an address; it simply indicates the lack of any affirmation of support for XX URIs." Thus, we believe that neither the presence nor absence of wsam:AnonymousResponses or wsam:NonAnonymousResponses as nested policy assetions is meaningful. Without making the semantic change to the assertions, the expression exemplified below is meaningless. <wsam:Addressing> <wsp:Policy> <wsam:AnonymousResponses wsp:optional="true"/> </wsp:Policy> </wsam:Addressing> The equivalent normalized expression implies conflicting semantics. The normalized policy expression (see below) gives no indication which alternative can be used. The first alternative indicates support for anonymous responses, but does not indicate whether a client that does not support that behavior should not use this alternative (because absence of the wsam:NonAnonymousResponses nested assertion explicitly does NOT make any statement as to whether or not that feature is supported). Similarly, the second alternative makes no statement what-so-ever as regards the support (or lack there-of) of anon or non-anon responses. <wsp:ExactlyOne> <wsp:All> <wsam:Addressing> <wsp:Policy> <wsp:ExactlyOne> <wsp:All> <wsam:AnonymousResponses/> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> </wsam:Addressing> </wsp:All> <wsp:All> <wsam:Addressing> <wsp:Policy/> </wsam:Addressing> </wsp:All> </wsp:ExactlyOne> The problematic semantics expressed above makes the utilization of the intersection algorithm provided by WS-Policy framework practically useless. (B) Given that the nested assertions express "support"s semantics, and given that their omission says nothing about lack of support, it is not possible for an endpoint to advertise that it explicitly DOES NOT support one or the other. However, it is likely that some policy authors might be lead to believe that by simply including only one of the nested assertions, that a policy consumer would read that and infer that the other is not supported, despite the fact that the spec says that it makes no statement. Thus, we believe that it is not possible to intersect the behaviors of a consumer and a provider meaningfully to rely on the intersection algorithm alone to express required behaviors. (C) The advocation in section 3.1.6 of the use of wsp:Optional='true' to enable intersection of two policy expressions when one side chose to omit making any statement about its capabilities is itself problematic. Using the WS-Policy 1.5 Framework intersection, the following two policies would be compatible, despite the fact that the possible intent of the respective authors was meant to relate that ONLY the expressed nested assertion was supported (see (B)): Client: <wsam:Addressing> <wsp:Policy> <wsam:AnonymousResponses wsp:optional="true"/> </wsp:Policy> </wsam:Addressing> Server: <wsam:Addressing> <wsp:Policy> <wsam:NonAnonymousResponses wsp:optional="true"/> </wsp:Policy> </wsam:Addressing> This is because the normalized expressions would each have an alternative with an empty nested policy and the policy engine applying intersection would report that there was a compatible policy alternative(s): <wsam:Addressing> <wsp:Policy/> <wsam:Addressing> Our guidelines document [1] in Section 4.5.1 further clarifies the appropriate use of wsp:optional attribute to create alternatives to indicate required and supported behaviors. Based on our review, we recommend adoption of one of the two options that follow to resolve (A) and (B) above. In our view, it is important to align the semantics of the nested aqssertions with the WS-Policy 1.5 Framework processing semantics. 1. One recommended approach would be to change the semantic of the nested policy assertions to represent required behavior and use policy operators to convey the precise semantics. e.g. <wsam:Addressing> <!-- anon responses required, non-anon prohibited --> <wsp:Policy> <wsp:ExactlyOne> <wsp:All> <!-- anon responses required --> <wsam:AnonymousResponses/> </wsp:All> <wsp:ExactlyOne> </wsp:Policy> </wsam:Addressing> <wsam:Addressing> <wsp:Policy> <wsp:ExactlyOne> <wsp:All> <!-- non-anon responses required, anon prohibited --> <wsam:NonanonymousResponses/> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> </wsam:Addressing> <wsam:Addressing> <wsp:Policy> <wsp:ExactlyOne> <wsp:All> <!-- either anon and non-anon responses required--> <wsam:AnonymousResponses/> </wsp:All> <wsp:All> <wsam:NonanonymousResponses/> <wsp:All> </wsp:ExactlyOne> </wsp:Policy> </wsam:Addressing> Note with this last one, it might be necessary to clarify that the scope of the assertion applies to a single instance of an MEP, not to all instances of MEPs associated with the endpoint.... to allow the client to choose for each message exchange the appropriate type of response. Section 3.1.2 and 3.1.3 should be updated to convey that nested assertions indicate dependent behaviors by removing the quoted sections above. 2. Alternately, we believe that if the intent of the semantic to be conveyed is indeed purely informational (i.e. that an endpoint "supports" the capability) that a more appropriate means of expressing this would be to use assertion parameters rather than nested policy: e.g. <wsam:Addressing> <wsam:AnonymousResponses/> <wsam:NonAnonymousResponses/> </wsam:Addressing> Note that with this second approach, the use of assertion parameters would not effect policy intersection, yet the assertion parameters could be used by the policy consumer as information that it could use to determine appropriate use of addressing. If formal processing the assertion parameters is deemed to be necessary, then domain specific intersection processing would need to be designed. For more information on usage of nested vs. parametric assertions, please see Section 4.4 in our Guidelines document for details. (C) We note that the use of wsp:ignorable is not appropriate in this context. Whether the semantics of the nested policy imply required or "supported", we note that once the assertion (wsam:Addressing) is understood, that any nested policy or parameters would also be understood by the client (by definition). Thus, we believe that the WS-Addressing Metadata specification should not be making any recommendations as to the use of wsp:ignorable in section 3.1.6. (D) The WS-Addressing Metadata draft does not specify a policy subject, but implies one. Instead, the draft specifies attachment points. We recommend making the policy subject explicit. Please refer to our guideline in Section 4.6 in our Guidelines document, ?An assertion description should specify a policy subject. For instance, if a policy assertion is to be used with WSDL, an assertion description should specify a WSDL policy subject ? such as service, endpoint, operation and message.? (E) The WS-Addressing Metadata draft should rule out wsdl:portType and wsdl20:interface as possible attachment points. e.g, ?A policy expression containing the Addressing policy assertion MUST NOT be attached to a wsdl:portType or wsdl20:interface. The Addressing policy assertion specifies a concrete behavior whereas the wsdl:portType or wsdl20:interface is an abstract construct.? Cheers, Christopher Ferris STSM, Software Group Standards Strategy email: chrisfer@us.ibm.com blog: http://www.ibm.com/developerworks/blogs/page/chrisferris phone: +1 508 377 9295 __________________ The W3C WS-Addressing WG has published a Last Call Working Draft of Web Services Addressing 1.0 - Metadata specification. The deadline for comments is 23 February 2007. The document is available at http://www.w3.org/TR/2007/WD-ws-addr-metadata-20070202/ We look forward to receiving any comments your WG has on this Last Call Working Drafts. Comments on this document are invited and are to be sent to the public public-ws-addressing-comments@w3.org mailing list. We are interested in particular in comments from the Web Services Policy and Web Services Description Working Group. We are also interested in comments from OASIS technical committees, in particular the Web Services Reliable Exchange (WS-RX) TC. Please note that the document contains substantial changes compared to the previous version. In particular, the document does no longer define a WSDL extension element or a WSDL SOAP module. This new version defines WS-Policy assertions, based on the Web Services Policy 1.5 framework. If your Working Group is interested in reviewing these drafts, please let me know, especially if you think you need more than three weeks after publication for your review. The decision to move to Last Call was made on January 29, 2007 [1]. No formal objection has been reported. No patent disclosure has been reported. Thanks -bob W3C WS-Addressing WG chair [1] http://www.w3.org/2007/01/29-ws-addr-minutes.html Bob Freund, Hitachi, Ltd. 62 Peakham Road, Sudbury, Massachusetts 01776-2914 Tel: +1-978-440-8415, Fax: +1-978-443-2168
Received on Friday, 23 February 2007 19:47:28 UTC