Re: FW: Last Call Working Draft Transition: Web ServicesAddressing 1.0 - Metadata

Bob Freund wrote:
I also posted a PR comment against WS Make Connection spec, which refers 
to this comment
on WS Addressing metadata from WS Policy. 
http://lists.oasis-open.org/archives/ws-rx/200702/msg00051.html

The rational shows, by example, that we can have composition with new 
services with different types of response mechanisms, by
defining appropriate policy expressions , (with enough alternatives) to 
satisfy the use cases of an endpoint.

Tom Rutt


>
> ------------------------------------------------------------------------
> *From:* Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> *Sent:* Fri 2/23/2007 11:26 AM
> *To:* Bob Freund; www-ws-desc@w3.org
> *Cc:* public-ws-policy@w3.org
> *Subject:* Last Call Working Draft Transition: Web ServicesAddressing 
> 1.0 - Metadata
>
>
> 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_ 
> <mailto: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
>
>
>
>
>
>
>
>
>


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Friday, 23 February 2007 21:43:44 UTC