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/#CalculatingEffectivyPolicywithWSDL1.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.html 
>>>>
>>>> [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-multiple-policy-subjects, 
>>>> http://www.w3.org/TR/2007/NOTE-ws-policy-primer-20071112/#versioning-policy-language, 
>>>> http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/#CalculatingEffectivyPolicywithWSDL1.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/#versioning-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 Thursday, 12 February 2009 23:31:08 UTC