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

On 13. Feb 2009, at 08:40, Anish Karmarkar wrote:

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

It seems that we have established that there may be conflicting  
addressing policies and those conflicts can only be detected and  
resolved in a domain-specific manner. Apparently that issue had been  
ignored or not recognized by the WS-Addressing WG earlier. I believe  
that the WS-Addressing WG would need to address that issue. The  
proposal has highlighted this issue and addressing it would remove one  
major concern with the proposal.

Fabian


> 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 09:05:28 UTC