You don't need the two nested assertions to occur
in the same policy alternative for there to be a conflict. Take a look
at the following WSDL, it has two wsam:Addressing policies that are
attached where WS-AM 1.0 currently says you can attach them, yet there
is a conflict.
<wsdl:definitions
targetNamespace="http://www.wstf.org/docs/scenarios/sc003"
. . .
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
xmlns:wsp="http://www.w3.org/ns/ws-policy">
. . .
<wsdl:binding name="sc003SOAP12Binding" type="tns:sc003Port">
<wsp:Policy>
<wsam:Addressing>
<wsp:Policy>
<wsam:NonAnonymousResponses/>
</wsp:Policy>
</wsam:Addressing>
</wsp:Policy>
. . .
</wsdl:binding>
<wsdl:service name="sc003Service">
<wsdl:port name="soap12port" binding="tns:sc003SOAP12Binding">
<wsp:Policy>
<wsam:Addressing>
<wsp:Policy>
<wsam:AnonymousResponses/>
</wsp:Policy>
</wsam:Addressing>
</wsp:Policy>
<soap12:address
location="http://www.wstf.org/sc003/sc003SOAP12"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
The knowledge necessary to resolve this conflict is no
less domain-specific than the knowledge necessary to figure out what to
do when, for example, a binding is marked as non-anon but a specific
operations is marked as supporting anon.
- gp
Bob Freund wrote:
In WS-Addressing metadata 1.0 section 3.1.3 it says that
"The wsam:NonAnonymousResponses policy assertion MUST NOT be used in
the same policy alternative as the wsam:AnonymousResponses policy
assertion."
So, is the issue what happens when that conflict occurs?
Is the issue that no fault is identified?
With respect to fault transmission, should it be desired, where might
it be sent unless there existed some non-conflicting policy?
-bob
On Feb 13, 2009, at 4:04 AM, Fabian Ritzmann wrote:
On 13. Feb 2009, at 08:40, Anish Karmarkar
wrote:
In this particular case, how would one know
that wsam:AnonymousResponse conflicts with wsam:NonAnonymousResponse
unless you have some domain-specific information. These are two
different QNames.
Based on the responses and the spec, it seems that the following three
scenarios are identical:
1) NonAnon on binding and Anon on port
2) A policy on binding (or port) that says: <wsp:All>Anon +
NonAnon</wsp:All>
3) NonAnon on binding and Anon on binding/operation (if this were to be
allowed)
So, I don't quite see why allowing addressing assertion on
binding/operation makes things any more problematic than it already is
(as far as this specific issue is concerned).
It seems that we have established that there may be conflicting
addressing policies and those conflicts can only be detected and
resolved in a domain-specific manner. Apparently that issue had been
ignored or not recognized by the WS-Addressing WG earlier. I believe
that the WS-Addressing WG would need to address that issue. The
proposal has highlighted this issue and addressing it would remove one
major concern with the proposal.
Fabian
Yalcinalp, Umit wrote:
I go away and look what happens :-) Read
Section 4.5 carefully, mate.
Not all compatibility is domain specific. If you do not have assertion
params, you have the Qnames to go with for compatibility. The whole
idea
is to rely on the types as much as possible and make the exceptions an
exception, not a norm, so that one could rely on a program, not a human
to make the determination of compatibility, whether it is lax or
strict.
Thus, compatibility is well defined in a domain-independent world. This
is why parametric assertions of the past became the nested assertions
of
today. But, I will sign off for now. Have fun! HTH, --umit
-----Original Message-----
From: Rogers, Tony [mailto:Tony.Rogers@ca.com] Sent: Thursday, February
12, 2009 4:34 PM
To: ashok.malhotra@oracle.com; Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@w3.org; public-ws-addressing@w3.org;
Jitendra.Kotamraju@Sun.COM; Ram Jeyaraman; wsi_wsbasic@mp.ws-i.org;
Fabian Ritzmann
Subject: RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
I thought the "explanation" was that policy compatibility was
domain-dependent, and could not be stated in a general way?
But yes, something of a diversion from topic.
Tony Rogers
tony.rogers@ca.com
-----Original Message-----
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of ashok
malhotra
Sent: Friday, 13 February 2009 11:23
To: Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@w3.org; public-ws-addressing@w3.org;
Jitendra.Kotamraju@Sun.COM; Ram Jeyaraman; wsi_wsbasic@mp.ws-i.org;
Fabian Ritzmann
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
Hi Umit, good to hear from you!
Unfortunately, this is like a eleventh commandment -- Thou shalt not
attach incompatible policies
It does not say how incompatible policies can be detected, nor does it
say what to do when you find incompatible policies
But I think we are getting away from the original topic.
All the best, Ashok
Yalcinalp, Umit wrote:
Did we duck or actually say the
following in section 4.1?
{It is RECOMMENDED that, where specific policy assertions associated
with one policy subject are only compatible with specific policy
assertions on another policy subject in the same hierarchical chain,
the
policies containing these assertions
should be attached within a
single
WSDL binding hierarchy.
For any given port, the policy alternatives for each policy subject
type
SHOULD be compatible with each of the
policy alternatives at each of
the
policy subjects parent and child policy
subjects, such that choices
between policy alternatives at each level are independent of each
other.}
We did not address what should happen when conflicts arise, but the
recommendation is not to create conflicts in the first place...
--umit
-----Original Message-----
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of ashok
malhotra
Sent: Thursday, February 12, 2009 3:29
PM
To: Anish Karmarkar
Cc: Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob Freund;
ylafon@w3.org; public-ws-addressing@w3.org;
Jitendra.Kotamraju@Sun.COM;
Ram Jeyaraman; wsi_wsbasic@mp.ws-i.org;
Fabian Ritzmann
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance
Issue:
(re: [wsi_wsbasic] BP 20133: proposal
1)
Unfortunately, WS-Policy ducked this question. There are many
situations where you can attach conflicting policies and there is no
guidance as to what should be done. Note that, in general, it can be
difficult to tell if policies are in conflict.
All the best, Ashok
Anish Karmarkar wrote:
Good question.
Shouldn't the answer be the same as what would happen if the
operation
specific policy was instead attached
to the port? This would give you
conflicting policies on binding and port and would have to be merged.
These attachment points are currently allowed by the spec.
-Anish
--
Rama Pulavarthi wrote:
Some questions on the proposal.
Gilbert Pilz wrote:
As the authors of the proposal in
question, Oracle feels obliged to
refute the inaccuracies in the arguments presented by our
colleagues
from Microsoft and Sun as well as
present our case with regards to the proposal.
With regards to the particular points:
1.) What this point fails to mention is that WS-Adressing 1.0 -
Metadata (WS-AM 1.0) *already* states that the wsam:Addressing
assertion can be attached to the wsdl11:port or wsd11l:binding. Our
proposal *extends* the existing specification to allow this assertion
to be attached to wsdl11:binding/wsdl11:operation and applies this
extension to the Operation Policy Subject. Our
proposal
does not alter the structure or
the semantics of the
wsam:Addressing
assertion.
What if conflicting policies are attached at the Endpoint policy
subject and Operation policy subject.
For example, on wsdl:binding it is specified as
<wsp:Policy>
<wsam:Addressing>
<wsp:Policy>
<wsam:NonAnonymousResponses/>
</wsp:Policy>
</wsam:Addressing>
and on the </wsp:Policy>
and on |wsdl11:binding/wsdl11:operation
|
<wsp:Policy>
<wsam:Addressing>
<wsp:Policy>
<wsam:AnonymousResponses/>
</wsp:Policy>
</wsam:Addressing>
and on the </wsp:Policy>
Which one should be used?, How is the effective policy for that
operation calculated?
Its not precedence but a merge of these policies that is used to
calculate the effective policy as per
http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/#merge.
Is BP going to specify all the Addressing domain specific rules to
handle merging of conflicting policies?
2.) The assertion that this
proposal conflicts with WS-Policy best practices is false. Reference
[3] below includes the following
text:
When the assertion's semantics
do not change to invalidate any
of
the original policy subjects
but new policy subjects need to be
added, it may be possible to use the same assertion to
designate
the additional policy subjects
without a namespace change. For
example, a policy assertion for a protocol that is originally
designed for endpoint policy subject may add message policy
subject to indicate finer granularity in the attachment
provided
that endpoint policy subject is
also retained in its design.
When
new policy subjects are added
it is incumbent on the authors to
retain the semantic of the policy assertion
Since our proposal includes this text:
When the WS-Addressing policy assertion occurs on the
wsdl11:binding/wsdl11:operation element, it applies to the
operation policy subject. Nevertheless, it should always be the
case that if one operation of an endpoint supports or requires
WS-Addressing, then all operations must support or require
WS-Addressing (although, potentially, with different
restrictions)
and the following requirement:
Ryyyy: /In a /*DESCRIPTION*/, if any operation of a WSDL 1.1
endpoint supports or requires WS-Addressing, then all the
operations of that endpoint MUST support or require
WS-Addressing./
/As I understand, This goes against
the policy scopes/ and effective
policy calculation as defined in
http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/#CalculatingEffe
ctivyPolicywithWSDL1.1
How can a policy specified at
Operation policy subject affect the effective policy at the Endpoint
policy subject? The policy specified at Operation scope can add more
non conflicting requirements to the policy specified at a higher level
that will be effective only for that operation.
thanks,
Rama Pulavarthi
it is clear that the semantics of
the wsam:Addressing policy assertion are being retained and thus we are
adhering to the guidelines described in [3].
3.) The claim that our proposal "disregards the existing structure of
the WS-AM policy assertions" and jeopardizes backwards compatibility is
false. As stated previously, our proposal does nothing to change the
structure or the semantics of the wsam:Addressing assertion, it simply
extends where such assertions can be attached. Furthermore, since it is
an extension, our
proposal
logically cannot affect backwards
compatibility. The
implementations
that interoperated at [5] should,
baring any unrelated changes, continue to interoperate under the same
test scenarios.
4.) The assertion that this change is "substantive" is subjective. The
notion that this extension conflicts with the existing wsam:Addressing
semantics has been addressed above.
The case for this proposal is straightforward: The current
WS-Addressing 1.0 - Metadata specification is technically
deficient.
It does not allow you to describe
an interface that contains both synchronous and asynchronous
operations. Input from our customers indicates that this is a common
and important use case. The Web Services Test Forum provides an example
of this in its Purchase Order Service scenario
(http://www.wstf.org/docs/scenarios/sc009/sc009.xml). Although
there
are workarounds for this problem,
they have side-effects that undermine the simplicity and utility of the
interface description.
One of the reasons Oracle raised this issue is the fact that this
technical deficiency is the result of an oversight by the W3C
Addressing Working Group, not the result of a deliberate decision. In
the WS-Addressing 1.0 - WSDL Binding specification, the wsaw:Anonymous
element extended the wsd11:binding/wsdl11:operation element thus
allowing you to specify that a particular operation
was
either synchronous or
asynchronous. As the WSDL Binding specification evolved into the
Metadata specification, the wsam:AnonymousResponses and
wsam:NonAnonymousResponses assertions (which each express a distinct
value of what was wsaw:Anonymous) were folded into nested assertions
beneath the top-level wsam:Addressing assertion. Although this change
was, in itself, technically correct, it had the side-effect of removing
the ability
to specify synchronous/asynchronous behavior at the operation level
since , as we have discussed, wsam:Addressing can currently only be
attached to the wsdl11:port or wsdl11:binding and has Endpoint Policy
Subject. Our proposal seeks to correct this flaw in a way that
preserves the semantics of wsam:Addressing.
Finally, we brought this issue to the WS-I Basic Profiles Working Group
because the W3C WS-Addressing Working Group is closed. Although there
have been some discussions about creating a group to
maintain the WS-Addressing specifications within the W3C it seems
unlikely, at this time, that such a group will be created. Since
correcting profiled specifications has some precedent in WS-I and the
Basic Profile Working Group, it seems to be the best place to attempt
to fix this problem.
Gilbert Pilz | SOA/WS Technologist | Middleware Standards | Oracle
Corporation
Monica Martin wrote:
An issue has been filed in the
WS-I Basic Profile WG that belongs to WS-Addressing WG with possible
assistance from the WS-Policy
WG.
The issue was filed in WS-I
Basic Profile WG because the WS-Addressing WG was closed. The issue
seeks to overturn a fundamental concept and constraint in
WS-Addressing-Metadata 1.0 and could conflict with WS-Policy best
practices. We've
paraphrased
the features sought,
requirements requested and potential conflict
it presents for existing implementations of WS-Addressing Metadata
1.0. As a WS-A Core schema change was handled in late July 2008
by
W3C on behalf of the
WS-Addressing WG [1], can you assist us in clarifying and resolving
this issue?
The proposed changes:
1. Overturn a WS-AM 1.0 restriction that wsam:Addressing be
limited
to an endpoint policy subject
[2]: Mandates these assertions be attached to a WSDL 1.1 port, binding
or
wsdl11:binding/wsdl:operation.
2. Could conflict with
WS-Policy best practices on altering semantics of existing assertions
for a policy subject: Allows a policy assertion to be used across
different policy subjects without versioning or a clear indication how
to differentiate semantics for assertion implementers. [3]
3. Disregards the existing structure of WS-AM policy assertions that
can support such a Description without this change and
without
jeopardizing backward
compatibility [4]: This proposal affects interoperable implementations
that tested in July 2007 into non-conforming implementations. [5]
4. Introduces a substantive change or new conflicting feature to WS-AM.
Can you also advise what is the maintenance plan for the WS-Addressing
WG? Can you comment or act on this substantive WS-AM
change? Are you in agreement to such a change in WS-I? [6]
Your prompt attention would be appreciated. Responses can be directed
to the chair of the WS-I Basic Profile WG. Thanks.
Jitendra Kotamraju, Sun Microsystems
Monica J. Martin, Microsoft Corporation
[1] IBM request resolution:
http://lists.w3.org/Archives/Public/public-ws-addressing/2008Jul/0001.ht
ml
[2] The same approach was also
taken by SOAP/XMLP for MTOM.
[3] The wsam:Addressing policy assertion is applied on multiple policy
subjects with differing semantics - No versioning is use.
No
mechanism is provided for
existing implementations to be backward compatible. Clients may be
unable to find a compatible policy.
http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/#supporting
-new-policy-subjects,
http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/#bp-WSDL-mu
ltiple-policy-subjects,
http://www.w3.org/TR/2007/NOTE-ws-policy-primer-20071112/#versioning-pol
icy-language,
http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/#CalculatingEffe
ctivyPolicywithWSDL1.1
and
http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/#versioning
-policy-assertions
<http://www.w3.org/TR/2007/NOTE-%0Aws-policy-guidelines-20071112/#versio
ning-policy-assertions>
[4] A portType can be separated
into two separate ones, one which contains one type of operations and
the other which targets
another
type. This description supports
interface related features sought by tools as was envisioned by W3C.
[5] http://dev.w3.org/2004/ws/addressing/testsuitewsdl/report/
[6] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-modify and
http://www.w3.org/2005/10/Process-20051014/tr.html#correction-classes
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary,
copyrighted and/or legally
privileged, and is intended solely for
the use of the individual or entity named in this message. If you are
not the intended recipient, and have received this message in error,
please immediately return this by email and then delete it.