- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Mon, 16 Feb 2009 12:08:33 -0500
- To: "Gilbert Pilz" <gilbert.pilz@oracle.com>, "Bob Freund" <Bob.Freund@hitachisoftware.com>
- Cc: "Fabian Ritzmann" <Fabian.Ritzmann@Sun.COM>, "Anish Karmarkar" <Anish.Karmarkar@oracle.com>, "Rogers, Tony" <Tony.Rogers@ca.com>, <ashok.malhotra@oracle.com>, "Rama Pulavarthi" <Rama.Pulavarthi@Sun.COM>, "Monica Martin" <momartin@microsoft.com>, <ylafon@w3.org>, <public-ws-addressing@w3.org>, <Jitendra.Kotamraju@Sun.COM>, "Ram Jeyaraman" <Ram.Jeyaraman@microsoft.com>, <wsi_wsbasic@mp.ws-i.org>
- Message-ID: <AF617D365219034E8B3044252E73F84402564F56@usphle1c.phl.sap.corp>
Looks like the perfect thing that an "errata" process should handle.
--umit
________________________________
From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
Sent: Saturday, February 14, 2009 4:16 PM
To: Bob Freund
Cc: Fabian Ritzmann; Anish Karmarkar; Yalcinalp, Umit; Rogers, Tony;
ashok.malhotra@oracle.com; Rama Pulavarthi; Monica Martin;
ylafon@w3.org; public-ws-addressing@w3.org; Jitendra.Kotamraju@Sun.COM;
Ram Jeyaraman; wsi_wsbasic@mp.ws-i.org
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
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"
<http://www.wstf.org/docs/scenarios/sc003>
. . .
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
<http://www.w3.org/2007/05/addressing/metadata>
xmlns:wsp="http://www.w3.org/ns/ws-policy"
<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"
<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.
Received on Monday, 16 February 2009 17:10:00 UTC