- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Tue, 20 Feb 2007 15:52:01 -0800
- To: <public-ws-policy@w3.org>
- Message-ID: <2BA6015847F82645A9BB31C7F9D641650372D414@uspale20.pal.sap.corp>
Dear Wg Members,
We reviewed the WS-Addressing Metadata draft [1] and prepared the
following text as the working group response to WS-Addressing wg.
We note that our wg needs to open new issues for our specifications to
update the examples in the Primer, Guidelines and Attachment to reflect
changes in the WS-A Metadata draft. Concretely, this is:
s,<wsa:UsingAddressing />,<wsa:Addressing>...</wsa:Addressing,g (note
use of ',' instead of '/' because of the '/' in the expression)
Cheers,
--umit, chris, asir, tom, dan, maryann (The Review TaskForce)
[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 meaninful.
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.
<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>
B) The problematic semantics expressed above makes the utilization of
the intersection algorithm provided by WS-Policy framework practically
useless. Given that the nested assertions express "support"s semantics,
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.
Specifically, 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, 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:
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."
----------------------
Dr. Umit Yalcinalp
Research Scientist
SAP Labs, LLC
Email: umit.yalcinalp@sap.com Tel: (650) 320-3095
SDN: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238
--------
"Nearly all men can stand adversity, but if you want to test a man's
character, give him power." Abraham Lincoln.
Received on Tuesday, 20 February 2007 23:49:55 UTC