W3C home > Mailing lists > Public > public-ws-addressing@w3.org > February 2009

RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Mon, 16 Feb 2009 12:08:33 -0500
Message-ID: <AF617D365219034E8B3044252E73F84402564F56@usphle1c.phl.sap.corp>
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>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:20 GMT