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 00:24:57 UTC