- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Wed, 21 Feb 2007 18:45:57 -0500
- To: public-ws-policy@w3.org
- Message-ID: <OF4756F51D.2455A51A-ON85257289.00816F2B-85257289.00828D03@us.ibm.com>
I've revised this proposal based on the discussion on the call today. Note
that Tom has actually come up with
two more alternate approaches, each of which, I believe, would resolve our
concerns and yet allow the WS-A
Metadata to compose with WS-P and with the WS-RM MakeConnection. I'll let
him make those proposals to the
WG himself.
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 task force assigned to review the WS-Addressing Metadata draft [1]
proposes the following
feedback be submitted to the WS-Addressing WG. The TF participants
included Asir, Umit, Chris, Dan, Maryann,
Tom Rutt.
[1] http://www.w3.org/TR/2007/WD-ws-addr-metadata-20070202
----------------------------------------------------------------------------
WS-Addressing Metadata 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.?
[1]
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
Received on Wednesday, 21 February 2007 23:46:35 UTC