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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Monica Martin (MS OPEN TECH)

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
[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



Reply | Threaded
Open this post in threaded view
|

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

Gilbert Pilz-3
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.

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.
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 <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/2007/NOTE-
ws-policy-guidelines-20071112/#versioning-policy-assertions">http://www.w3.org/TR/2007/NOTE-ws-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.
  

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Rama Pulavarthi
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
[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.
  

Reply | Threaded
Open this post in threaded view
|

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

Anish Karmarkar

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

Reply | Threaded
Open this post in threaded view
|

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

Ashok Malhotra

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

Reply | Threaded
Open this post in threaded view
|

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

Yalcinalp, Umit

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: [hidden email]
[mailto:[hidden email]] 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;
[hidden email]; [hidden email]; [hidden email];
Ram Jeyaraman; [hidden email]; 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.
>>>>  
>>
>


Reply | Threaded
Open this post in threaded view
|

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

Ashok Malhotra

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: [hidden email]
> [mailto:[hidden email]] 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;
> [hidden email]; [hidden email]; [hidden email];
> Ram Jeyaraman; [hidden email]; 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.
>>>>>  
>>>>>          
>
>
>  

Reply | Threaded
Open this post in threaded view
|

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

Rogers, Tony

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
[hidden email]

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] 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; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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: [hidden email]
> [mailto:[hidden email]] 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;
> [hidden email]; [hidden email];
[hidden email];
> Ram Jeyaraman; [hidden email]; 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.
>>>>>  
>>>>>          
>
>
>  



Reply | Threaded
Open this post in threaded view
|

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

Yalcinalp, Umit

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:[hidden email]]
Sent: Thursday, February 12, 2009 4:34 PM
To: [hidden email]; Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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
[hidden email]

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] 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; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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: [hidden email]
> [mailto:[hidden email]] 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;
> [hidden email]; [hidden email];
[hidden email];
> Ram Jeyaraman; [hidden email]; 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.
>>>>>  
>>>>>          
>
>
>  



Reply | Threaded
Open this post in threaded view
|

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

Anish Karmarkar

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:[hidden email]]
> Sent: Thursday, February 12, 2009 4:34 PM
> To: [hidden email]; Yalcinalp, Umit
> Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
> Freund; [hidden email]; [hidden email];
> [hidden email]; Ram Jeyaraman; [hidden email];
> 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
> [hidden email]
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] 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; [hidden email]; [hidden email];
> [hidden email]; Ram Jeyaraman; [hidden email];
> 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: [hidden email]
>> [mailto:[hidden email]] 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;
>> [hidden email]; [hidden email];
> [hidden email];
>> Ram Jeyaraman; [hidden email]; 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.
>>>>>>  
>>>>>>          
>>
>>  
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Fabian Ritzmann-3

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:[hidden email]] Sent: Thursday,  
>> February 12, 2009 4:34 PM
>> To: [hidden email]; Yalcinalp, Umit
>> Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin;  
>> Bob
>> Freund; [hidden email]; [hidden email];
>> [hidden email]; Ram Jeyaraman; [hidden email];
>> 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
>> [hidden email]
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] 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; [hidden email]; [hidden email];
>> [hidden email]; Ram Jeyaraman; [hidden email];
>> 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: [hidden email]
>>> [mailto:[hidden email]] 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;
>>> [hidden email]; [hidden email];
>> [hidden email];
>>> Ram Jeyaraman; [hidden email]; 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.
>>>>>>>

Reply | Threaded
Open this post in threaded view
|

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

Gilbert Pilz-3
In reply to this post by Yalcinalp, Umit
The problem is that the business case driving this issue is precisely about conflicting policies. I want to be able to say "all the operations in this binding MUST be synchronous except for this one operation which MUST be asynchronous". Hard to see how you can address this without some way of resolving the conflicts.

- gp

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 [[hidden email]] 
Sent: Thursday, February 12, 2009 4:34 PM
To: [hidden email]; Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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
[hidden email]

-----Original Message-----
From: [hidden email]
[[hidden email]] 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; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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: [hidden email]
[[hidden email]] 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;
[hidden email]; [hidden email];
    
[hidden email];
  
Ram Jeyaraman; [hidden email]; 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.
  
          
            
  
    



  

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Yalcinalp, Umit
Given that we have established the WS-Policy perspective and thanks to Anish, the occurance of this issue despite non-parametric assertions (which leads to domain-specific handling), it seems to me that this issue should be addressed by the WS-Addressing wg. I would agree with Fabian there, since the semantics, attachment and the types are defined by WS-Addressing, so would the conflict avoidance or resolution, there of belong to WS-A.
 
My two cents,
 
--umit
 


From: Gilbert Pilz [mailto:[hidden email]]
Sent: Friday, February 13, 2009 3:56 PM
To: Yalcinalp, Umit
Cc: Rogers, Tony; [hidden email]; Anish Karmarkar; Rama Pulavarthi; Monica Martin; Bob Freund; [hidden email]; [hidden email]; [hidden email]; Ram Jeyaraman; [hidden email]; Fabian Ritzmann
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)

The problem is that the business case driving this issue is precisely about conflicting policies. I want to be able to say "all the operations in this binding MUST be synchronous except for this one operation which MUST be asynchronous". Hard to see how you can address this without some way of resolving the conflicts.

- gp

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 [[hidden email]] 
Sent: Thursday, February 12, 2009 4:34 PM
To: [hidden email]; Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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
[hidden email]

-----Original Message-----
From: [hidden email]
[[hidden email]] 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; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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: [hidden email]
[[hidden email]] 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;
[hidden email]; [hidden email];
    
[hidden email];
  
Ram Jeyaraman; [hidden email]; 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.
  
          
            
  
    



  
Reply | Threaded
Open this post in threaded view
|

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

Monica Martin (MS OPEN TECH)

[dropping WS-I mailing list]

 

Thanks to everyone for their information on use of and intent around WS-AddressingMetadata policy assertions. The ownership of this substantive issue should be addressed by the WS-Addressing WG. mo

 

 

From: Yalcinalp, Umit [mailto:[hidden email]]
Sent: Friday, February 13, 2009 6:25 PM
To: Gilbert Pilz
Cc: Rogers, Tony; [hidden email]; Anish Karmarkar; Rama Pulavarthi; Monica Martin; Bob Freund; [hidden email]; [hidden email]; [hidden email]; Ram Jeyaraman; [hidden email]; Fabian Ritzmann
Subject: RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)

 

Given that we have established the WS-Policy perspective and thanks to Anish, the occurance of this issue despite non-parametric assertions (which leads to domain-specific handling), it seems to me that this issue should be addressed by the WS-Addressing wg. I would agree with Fabian there, since the semantics, attachment and the types are defined by WS-Addressing, so would the conflict avoidance or resolution, there of belong to WS-A.

 

My two cents,

 

--umit

 

…continued

 

 
Reply | Threaded
Open this post in threaded view
|

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

Bob Freund-Hitachi
In reply to this post by Fabian Ritzmann-3
In WS-Addressing metadata 1.0 section 3.1.3 it says that
"The wsam:NonAnonymousResponses policy assertion MUST NOT be used in  
the same policy alternative as the wsam:AnonymousResponses policy  
assertion."

So, is the issue what happens when that conflict occurs?
Is the issue that no fault is identified?
With respect to fault transmission, should it be desired, where might  
it be sent unless there existed some non-conflicting policy?
-bob


On Feb 13, 2009, at 4:04 AM, Fabian Ritzmann wrote:

> 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:[hidden email]] Sent: Thursday,  
>>> February 12, 2009 4:34 PM
>>> To: [hidden email]; Yalcinalp, Umit
>>> Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin;  
>>> Bob
>>> Freund; [hidden email]; [hidden email];
>>> [hidden email]; Ram Jeyaraman; [hidden email];
>>> 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
>>> [hidden email]
>>> -----Original Message-----
>>> From: [hidden email]
>>> [mailto:[hidden email]] 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; [hidden email]; [hidden email];
>>> [hidden email]; Ram Jeyaraman; [hidden email];
>>> 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: [hidden email]
>>>> [mailto:[hidden email]] 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;
>>>> [hidden email]; [hidden email];
>>> [hidden email];
>>>> Ram Jeyaraman; [hidden email]; 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.
>>>>>>>>


Reply | Threaded
Open this post in threaded view
|

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

Gilbert Pilz-3
In reply to this post by Yalcinalp, Umit
Asking the WS-Addressing Working Group to resolve this is like asking Thomas Jefferson and James Madison to weigh in on the interpretation of the 2nd amendment and the issue of gun rights. While it's clear that they are probably the top authorities on the matter they, like the WS-Addressing Working Group, are dead. We've no choice but to try and work it out for ourselves . . .

- gp

Yalcinalp, Umit wrote:
Given that we have established the WS-Policy perspective and thanks to Anish, the occurance of this issue despite non-parametric assertions (which leads to domain-specific handling), it seems to me that this issue should be addressed by the WS-Addressing wg. I would agree with Fabian there, since the semantics, attachment and the types are defined by WS-Addressing, so would the conflict avoidance or resolution, there of belong to WS-A.
 
My two cents,
 
--umit
 


From: Gilbert Pilz [[hidden email]]
Sent: Friday, February 13, 2009 3:56 PM
To: Yalcinalp, Umit
Cc: Rogers, Tony; [hidden email]; Anish Karmarkar; Rama Pulavarthi; Monica Martin; Bob Freund; [hidden email]; [hidden email]; [hidden email]; Ram Jeyaraman; [hidden email]; Fabian Ritzmann
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)

The problem is that the business case driving this issue is precisely about conflicting policies. I want to be able to say "all the operations in this binding MUST be synchronous except for this one operation which MUST be asynchronous". Hard to see how you can address this without some way of resolving the conflicts.

- gp

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 [[hidden email]] 
Sent: Thursday, February 12, 2009 4:34 PM
To: [hidden email]; Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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
[hidden email]

-----Original Message-----
From: [hidden email]
[[hidden email]] 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; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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: [hidden email]
[[hidden email]] 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;
[hidden email]; [hidden email];
    
[hidden email];
  
Ram Jeyaraman; [hidden email]; 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.
  
          
            
  
    



  

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Gilbert Pilz-3
In reply to this post by Bob Freund-Hitachi
You don't need the two nested assertions to occur in the same policy alternative for there to be a conflict. Take a look at the following WSDL, it has two wsam:Addressing policies that are attached where WS-AM 1.0 currently says you can attach them, yet there is a conflict.

<wsdl:definitions targetNamespace="http://www.wstf.org/docs/scenarios/sc003"
                  . . .
                  xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
                  xmlns:wsp="http://www.w3.org/ns/ws-policy">
  . . .
  <wsdl:binding name="sc003SOAP12Binding" type="tns:sc003Port">
    <wsp:Policy>
      <wsam:Addressing>
        <wsp:Policy>
          <wsam:NonAnonymousResponses/>
        </wsp:Policy>
      </wsam:Addressing>
    </wsp:Policy>
    . . .
  </wsdl:binding>

  <wsdl:service name="sc003Service">
    <wsdl:port name="soap12port" binding="tns:sc003SOAP12Binding">
      <wsp:Policy>
        <wsam:Addressing>
          <wsp:Policy>
            <wsam:AnonymousResponses/>
          </wsp:Policy>
        </wsam:Addressing>
      </wsp:Policy>
      <soap12:address location="http://www.wstf.org/sc003/sc003SOAP12"/>
    </wsdl:port>
  </wsdl:service>

</wsdl:definitions>

The knowledge necessary to resolve this conflict is no less domain-specific than the knowledge necessary to figure out what to do when, for example, a binding is marked as non-anon but a specific operations is marked as supporting anon.

- gp

Bob Freund wrote:
In WS-Addressing metadata 1.0 section 3.1.3 it says that
"The wsam:NonAnonymousResponses policy assertion MUST NOT be used in the same policy alternative as the wsam:AnonymousResponses policy assertion."

So, is the issue what happens when that conflict occurs?
Is the issue that no fault is identified?
With respect to fault transmission, should it be desired, where might it be sent unless there existed some non-conflicting policy?
-bob


On Feb 13, 2009, at 4:04 AM, Fabian Ritzmann wrote:

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 [[hidden email]] Sent: Thursday, February 12, 2009 4:34 PM
To: [hidden email]; Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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
[hidden email]
-----Original Message-----
From: [hidden email]
[[hidden email]] 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; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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: [hidden email]
[[hidden email]] 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;
[hidden email]; [hidden email];
[hidden email];
Ram Jeyaraman; [hidden email]; 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.



smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Yalcinalp, Umit
Looks like the perfect thing that an "errata" process should handle.
 
--umit
 


From: Gilbert Pilz [mailto:[hidden email]]
Sent: Saturday, February 14, 2009 4:16 PM
To: Bob Freund
Cc: Fabian Ritzmann; Anish Karmarkar; Yalcinalp, Umit; Rogers, Tony; [hidden email]; Rama Pulavarthi; Monica Martin; [hidden email]; [hidden email]; [hidden email]; Ram Jeyaraman; [hidden email]
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)

You don't need the two nested assertions to occur in the same policy alternative for there to be a conflict. Take a look at the following WSDL, it has two wsam:Addressing policies that are attached where WS-AM 1.0 currently says you can attach them, yet there is a conflict.

<wsdl:definitions targetNamespace="http://www.wstf.org/docs/scenarios/sc003"
                  . . .
                  xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
                  xmlns:wsp="http://www.w3.org/ns/ws-policy">
  . . .
  <wsdl:binding name="sc003SOAP12Binding" type="tns:sc003Port">
    <wsp:Policy>
      <wsam:Addressing>
        <wsp:Policy>
          <wsam:NonAnonymousResponses/>
        </wsp:Policy>
      </wsam:Addressing>
    </wsp:Policy>
    . . .
  </wsdl:binding>

  <wsdl:service name="sc003Service">
    <wsdl:port name="soap12port" binding="tns:sc003SOAP12Binding">
      <wsp:Policy>
        <wsam:Addressing>
          <wsp:Policy>
            <wsam:AnonymousResponses/>
          </wsp:Policy>
        </wsam:Addressing>
      </wsp:Policy>
      <soap12:address location="http://www.wstf.org/sc003/sc003SOAP12"/>
    </wsdl:port>
  </wsdl:service>

</wsdl:definitions>

The knowledge necessary to resolve this conflict is no less domain-specific than the knowledge necessary to figure out what to do when, for example, a binding is marked as non-anon but a specific operations is marked as supporting anon.

- gp

Bob Freund wrote:
In WS-Addressing metadata 1.0 section 3.1.3 it says that
"The wsam:NonAnonymousResponses policy assertion MUST NOT be used in the same policy alternative as the wsam:AnonymousResponses policy assertion."

So, is the issue what happens when that conflict occurs?
Is the issue that no fault is identified?
With respect to fault transmission, should it be desired, where might it be sent unless there existed some non-conflicting policy?
-bob


On Feb 13, 2009, at 4:04 AM, Fabian Ritzmann wrote:

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 [[hidden email]] Sent: Thursday, February 12, 2009 4:34 PM
To: [hidden email]; Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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
[hidden email]
-----Original Message-----
From: [hidden email]
[[hidden email]] 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; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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: [hidden email]
[[hidden email]] 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;
[hidden email]; [hidden email];
[hidden email];
Ram Jeyaraman; [hidden email]; 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.


Reply | Threaded
Open this post in threaded view
|

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

Bob Freund-Hitachi
Draft insertion as part of the errata process:

When presented with conflicting policies, endpoints or services are expected to make do with what they have, since these assertions do not present demands but describe some acceptable forms of addresses, potentially amongst others, that might be accepted.  By making do with what it has, the service or end point is to collect all the various bits of policy assertions it has at its disposal and may consider them all to be potentially usable policy alternatives.  Implementations are encouraged to respond with a non-anonymous form if presented or an anonymous form if not.

Irrational behavior such as locking up completely, or electronically spitting the dummy by throwing faults that nobody is listening for and might not be received anyway especially since you can't determine what address form is acceptable, is not to be tolerated and will result in a free membership to the WS-Policy Working Group with the Complements of WS-Addressing.  

-bob

On Feb 16, 2009, at 12:08 PM, Yalcinalp, Umit wrote:

Looks like the perfect thing that an "errata" process should handle.
 
--umit
 


From: Gilbert Pilz [[hidden email]]
Sent: Saturday, February 14, 2009 4:16 PM
To: Bob Freund
Cc: Fabian Ritzmann; Anish Karmarkar; Yalcinalp, Umit; Rogers, Tony; [hidden email]; Rama Pulavarthi; Monica Martin; [hidden email]; [hidden email]; [hidden email]; Ram Jeyaraman; [hidden email]
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)

You don't need the two nested assertions to occur in the same policy alternative for there to be a conflict. Take a look at the following WSDL, it has two wsam:Addressing policies that are attached where WS-AM 1.0 currently says you can attach them, yet there is a conflict.

<wsdl:definitions targetNamespace="http://www.wstf.org/docs/scenarios/sc003"
                  . . .
                  xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
                  xmlns:wsp="http://www.w3.org/ns/ws-policy">
  . . .
  <wsdl:binding name="sc003SOAP12Binding" type="tns:sc003Port">
    <wsp:Policy>
      <wsam:Addressing>
        <wsp:Policy>
          <wsam:NonAnonymousResponses/>
        </wsp:Policy>
      </wsam:Addressing>
    </wsp:Policy>
    . . .
  </wsdl:binding>

  <wsdl:service name="sc003Service">
    <wsdl:port name="soap12port" binding="tns:sc003SOAP12Binding">
      <wsp:Policy>
        <wsam:Addressing>
          <wsp:Policy>
            <wsam:AnonymousResponses/>
          </wsp:Policy>
        </wsam:Addressing>
      </wsp:Policy>
      <soap12:address location="http://www.wstf.org/sc003/sc003SOAP12"/>
    </wsdl:port>
  </wsdl:service>

</wsdl:definitions>

The knowledge necessary to resolve this conflict is no less domain-specific than the knowledge necessary to figure out what to do when, for example, a binding is marked as non-anon but a specific operations is marked as supporting anon.

- gp

Bob Freund wrote:
In WS-Addressing metadata 1.0 section 3.1.3 it says that
"The wsam:NonAnonymousResponses policy assertion MUST NOT be used in the same policy alternative as the wsam:AnonymousResponses policy assertion."

So, is the issue what happens when that conflict occurs?
Is the issue that no fault is identified?
With respect to fault transmission, should it be desired, where might it be sent unless there existed some non-conflicting policy?
-bob


On Feb 13, 2009, at 4:04 AM, Fabian Ritzmann wrote:

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 [[hidden email]] Sent: Thursday, February 12, 2009 4:34 PM
To: [hidden email]; Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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
[hidden email]
-----Original Message-----
From: [hidden email]
[[hidden email]] 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; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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: [hidden email]
[[hidden email]] 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;
[hidden email]; [hidden email];
[hidden email];
Ram Jeyaraman; [hidden email]; 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.



Reply | Threaded
Open this post in threaded view
|

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

Gilbert Pilz-3
Excuse me, Bob, but what "errata process" are you referring to?

- gp

Bob Freund wrote:
Draft insertion as part of the errata process:

When presented with conflicting policies, endpoints or services are expected to make do with what they have, since these assertions do not present demands but describe some acceptable forms of addresses, potentially amongst others, that might be accepted.  By making do with what it has, the service or end point is to collect all the various bits of policy assertions it has at its disposal and may consider them all to be potentially usable policy alternatives.  Implementations are encouraged to respond with a non-anonymous form if presented or an anonymous form if not.

Irrational behavior such as locking up completely, or electronically spitting the dummy by throwing faults that nobody is listening for and might not be received anyway especially since you can't determine what address form is acceptable, is not to be tolerated and will result in a free membership to the WS-Policy Working Group with the Complements of WS-Addressing.  

-bob

On Feb 16, 2009, at 12:08 PM, Yalcinalp, Umit wrote:

Looks like the perfect thing that an "errata" process should handle.
 
--umit
 


From: Gilbert Pilz [[hidden email]]
Sent: Saturday, February 14, 2009 4:16 PM
To: Bob Freund
Cc: Fabian Ritzmann; Anish Karmarkar; Yalcinalp, Umit; Rogers, Tony; [hidden email]; Rama Pulavarthi; Monica Martin; [hidden email]; [hidden email]; [hidden email]; Ram Jeyaraman; [hidden email]
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)

You don't need the two nested assertions to occur in the same policy alternative for there to be a conflict. Take a look at the following WSDL, it has two wsam:Addressing policies that are attached where WS-AM 1.0 currently says you can attach them, yet there is a conflict.

<wsdl:definitions targetNamespace="http://www.wstf.org/docs/scenarios/sc003"
                  . . .
                  xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
                  xmlns:wsp="http://www.w3.org/ns/ws-policy">
  . . .
  <wsdl:binding name="sc003SOAP12Binding" type="tns:sc003Port">
    <wsp:Policy>
      <wsam:Addressing>
        <wsp:Policy>
          <wsam:NonAnonymousResponses/>
        </wsp:Policy>
      </wsam:Addressing>
    </wsp:Policy>
    . . .
  </wsdl:binding>

  <wsdl:service name="sc003Service">
    <wsdl:port name="soap12port" binding="tns:sc003SOAP12Binding">
      <wsp:Policy>
        <wsam:Addressing>
          <wsp:Policy>
            <wsam:AnonymousResponses/>
          </wsp:Policy>
        </wsam:Addressing>
      </wsp:Policy>
      <soap12:address location="http://www.wstf.org/sc003/sc003SOAP12"/>
    </wsdl:port>
  </wsdl:service>

</wsdl:definitions>

The knowledge necessary to resolve this conflict is no less domain-specific than the knowledge necessary to figure out what to do when, for example, a binding is marked as non-anon but a specific operations is marked as supporting anon.

- gp

Bob Freund wrote:
In WS-Addressing metadata 1.0 section 3.1.3 it says that
"The wsam:NonAnonymousResponses policy assertion MUST NOT be used in the same policy alternative as the wsam:AnonymousResponses policy assertion."

So, is the issue what happens when that conflict occurs?
Is the issue that no fault is identified?
With respect to fault transmission, should it be desired, where might it be sent unless there existed some non-conflicting policy?
-bob


On Feb 13, 2009, at 4:04 AM, Fabian Ritzmann wrote:

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 [[hidden email]] Sent: Thursday, February 12, 2009 4:34 PM
To: [hidden email]; Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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
[hidden email]
-----Original Message-----
From: [hidden email]
[[hidden email]] 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; [hidden email]; [hidden email];
[hidden email]; Ram Jeyaraman; [hidden email];
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: [hidden email]
[[hidden email]] 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;
[hidden email]; [hidden email];
[hidden email];
Ram Jeyaraman; [hidden email]; 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.




smime.p7s (4K) Download Attachment
12