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 00:34:47 UTC