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

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).

-Anish
--

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 Friday, 13 February 2009 06:41:29 UTC