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: Fri, 13 Feb 2009 21:24:52 -0500
Message-ID: <AF617D365219034E8B3044252E73F84402564BAA@usphle1c.phl.sap.corp>
To: "Gilbert Pilz" <gilbert.pilz@oracle.com>
Cc: "Rogers, Tony" <Tony.Rogers@ca.com>, <ashok.malhotra@oracle.com>, "Anish Karmarkar" <Anish.Karmarkar@oracle.com>, "Rama Pulavarthi" <Rama.Pulavarthi@Sun.COM>, "Monica Martin" <momartin@microsoft.com>, "Bob Freund" <Bob.Freund@hitachisoftware.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>, "Fabian Ritzmann" <Fabian.Ritzmann@Sun.COM>
Given that we have established the WS-Policy perspective and thanks to
Anish, the occurance of this issue despite non-parametric assertions
(which leads to domain-specific handling), it seems to me that this
issue should be addressed by the WS-Addressing wg. I would agree with
Fabian there, since the semantics, attachment and the types are defined
by WS-Addressing, so would the conflict avoidance or resolution, there
of belong to WS-A. 
 
My two cents, 
 
--umit
 

________________________________

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
Sent: Friday, February 13, 2009 3:56 PM
To: Yalcinalp, Umit
Cc: Rogers, Tony; ashok.malhotra@oracle.com; Anish Karmarkar; Rama
Pulavarthi; 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)


The problem is that the business case driving this issue is precisely
about conflicting policies. I want to be able to say "all the operations
in this binding MUST be synchronous except for this one operation which
MUST be asynchronous". Hard to see how you can address this without some
way of resolving the conflicts.

- gp

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 Saturday, 14 February 2009 02:25:58 GMT

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