|
WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
|
|
Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
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 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.
|
|
Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
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.
|
|
Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
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.
>>>
>
|
|
Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
Unfortunately, WS-Policy ducked this question. There are many
situations where you can attach conflicting policies and there is no
guidance as to what should be done. Note that, in general, it can be
difficult to tell if policies are in conflict.
All the best, Ashok
Anish Karmarkar wrote:
>
> Good question.
>
> Shouldn't the answer be the same as what would happen if the operation
> specific policy was instead attached to the port? This would give you
> conflicting policies on binding and port and would have to be merged.
> These attachment points are currently allowed by the spec.
>
> -Anish
> --
>
> Rama Pulavarthi wrote:
>> Some questions on the proposal.
>>
>> Gilbert Pilz wrote:
>>> As the authors of the proposal in question, Oracle feels obliged to
>>> refute the inaccuracies in the arguments presented by our colleagues
>>> from Microsoft and Sun as well as present our case with regards to
>>> the proposal.
>>>
>>> With regards to the particular points:
>>>
>>> 1.) What this point fails to mention is that WS-Adressing 1.0 -
>>> Metadata (WS-AM 1.0) *already* states that the wsam:Addressing
>>> assertion can be attached to the wsdl11:port or wsd11l:binding. Our
>>> proposal *extends* the existing specification to allow this
>>> assertion to be attached to wsdl11:binding/wsdl11:operation and
>>> applies this extension to the Operation Policy Subject. Our proposal
>>> does not alter the structure or the semantics of the wsam:Addressing
>>> assertion.
>> What if conflicting policies are attached at the Endpoint policy
>> subject and Operation policy subject.
>> For example, on wsdl:binding it is specified as
>>
>> <wsp:Policy>
>> <wsam:Addressing>
>> <wsp:Policy>
>> <wsam:NonAnonymousResponses/>
>> </wsp:Policy>
>> </wsam:Addressing>
>> and on the </wsp:Policy>
>>
>> and on |wsdl11:binding/wsdl11:operation
>> |
>>
>> <wsp:Policy>
>> <wsam:Addressing>
>> <wsp:Policy>
>> <wsam:AnonymousResponses/>
>> </wsp:Policy>
>> </wsam:Addressing>
>> and on the </wsp:Policy>
>>
>> Which one should be used?, How is the effective policy for that
>> operation calculated?
>> Its not precedence but a merge of these policies that is used to
>> calculate the effective policy as per
>> http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/#merge.
>>
>> Is BP going to specify all the Addressing domain specific rules to
>> handle merging of conflicting policies?
>>>
>>> 2.) The assertion that this proposal conflicts with WS-Policy best
>>> practices is false. Reference [3] below includes the following text:
>>>
>>> When the assertion's semantics do not change to invalidate any of
>>> the original policy subjects but new policy subjects need to be
>>> added, it may be possible to use the same assertion to designate
>>> the additional policy subjects without a namespace change. For
>>> example, a policy assertion for a protocol that is originally
>>> designed for endpoint policy subject may add message policy
>>> subject to indicate finer granularity in the attachment provided
>>> that endpoint policy subject is also retained in its design. When
>>> new policy subjects are added it is incumbent on the authors to
>>> retain the semantic of the policy assertion
>>>
>>> Since our proposal includes this text:
>>>
>>> When the WS-Addressing policy assertion occurs on the
>>> wsdl11:binding/wsdl11:operation element, it applies to the
>>> operation policy subject. Nevertheless, it should always be the
>>> case that if one operation of an endpoint supports or requires
>>> WS-Addressing, then all operations must support or require
>>> WS-Addressing (although, potentially, with different restrictions)
>>> and the following requirement:
>>>
>>> Ryyyy: /In a /*DESCRIPTION*/, if any operation of a WSDL 1.1
>>> endpoint supports or requires WS-Addressing, then all the
>>> operations of that endpoint MUST support or require WS-Addressing./
>>>
>> /As I understand, This goes against the policy scopes/ and effective
>> policy calculation as defined in
>> http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/#CalculatingEffectivyPolicywithWSDL1.1
>>
>> How can a policy specified at Operation policy subject affect the
>> effective policy at the Endpoint policy subject? The policy
>> specified at Operation scope can add more non conflicting
>> requirements to the policy specified at a higher level that will be
>> effective only for that operation.
>>
>>
>> thanks,
>> Rama Pulavarthi
>>>
>>> it is clear that the semantics of the wsam:Addressing policy
>>> assertion are being retained and thus we are adhering to the
>>> guidelines described in [3].
>>>
>>> 3.) The claim that our proposal "disregards the existing structure
>>> of the WS-AM policy assertions" and jeopardizes backwards
>>> compatibility is false. As stated previously, our proposal does
>>> nothing to change the structure or the semantics of the
>>> wsam:Addressing assertion, it simply extends where such assertions
>>> can be attached. Furthermore, since it is an extension, our proposal
>>> logically cannot affect backwards compatibility. The implementations
>>> that interoperated at [5] should, baring any unrelated changes,
>>> continue to interoperate under the same test scenarios.
>>>
>>> 4.) The assertion that this change is "substantive" is subjective.
>>> The notion that this extension conflicts with the existing
>>> wsam:Addressing semantics has been addressed above.
>>>
>>> The case for this proposal is straightforward: The current
>>> WS-Addressing 1.0 - Metadata specification is technically deficient.
>>> It does not allow you to describe an interface that contains both
>>> synchronous and asynchronous operations. Input from our customers
>>> indicates that this is a common and important use case. The Web
>>> Services Test Forum provides an example of this in its Purchase
>>> Order Service scenario
>>> ( http://www.wstf.org/docs/scenarios/sc009/sc009.xml). Although there
>>> are workarounds for this problem, they have side-effects that
>>> undermine the simplicity and utility of the interface description.
>>>
>>> One of the reasons Oracle raised this issue is the fact that this
>>> technical deficiency is the result of an oversight by the W3C
>>> Addressing Working Group, not the result of a deliberate decision.
>>> In the WS-Addressing 1.0 - WSDL Binding specification, the
>>> wsaw:Anonymous element extended the wsd11:binding/wsdl11:operation
>>> element thus allowing you to specify that a particular operation was
>>> either synchronous or asynchronous. As the WSDL Binding
>>> specification evolved into the Metadata specification, the
>>> wsam:AnonymousResponses and wsam:NonAnonymousResponses assertions
>>> (which each express a distinct value of what was wsaw:Anonymous)
>>> were folded into nested assertions beneath the top-level
>>> wsam:Addressing assertion. Although this change was, in itself,
>>> technically correct, it had the side-effect of removing the ability
>>> to specify synchronous/asynchronous behavior at the operation level
>>> since , as we have discussed, wsam:Addressing can currently only be
>>> attached to the wsdl11:port or wsdl11:binding and has Endpoint
>>> Policy Subject. Our proposal seeks to correct this flaw in a way
>>> that preserves the semantics of wsam:Addressing.
>>>
>>> Finally, we brought this issue to the WS-I Basic Profiles Working
>>> Group because the W3C WS-Addressing Working Group is closed.
>>> Although there have been some discussions about creating a group to
>>> maintain the WS-Addressing specifications within the W3C it seems
>>> unlikely, at this time, that such a group will be created. Since
>>> correcting profiled specifications has some precedent in WS-I and
>>> the Basic Profile Working Group, it seems to be the best place to
>>> attempt to fix this problem.
>>>
>>> Gilbert Pilz | SOA/WS Technologist | Middleware Standards | Oracle
>>> Corporation
>>>
>>> Monica Martin wrote:
>>>> An issue has been filed in the WS-I Basic Profile WG that belongs
>>>> to WS-Addressing WG with possible assistance from the WS-Policy WG.
>>>> The issue was filed in WS-I Basic Profile WG because the
>>>> WS-Addressing WG was closed. The issue seeks to overturn a
>>>> fundamental concept and constraint in WS-Addressing-Metadata 1.0
>>>> and could conflict with WS-Policy best practices. We've paraphrased
>>>> the features sought, requirements requested and potential conflict
>>>> it presents for existing implementations of WS-Addressing Metadata
>>>> 1.0. As a WS-A Core schema change was handled in late July 2008 by
>>>> W3C on behalf of the WS-Addressing WG [1], can you assist us in
>>>> clarifying and resolving this issue?
>>>>
>>>> The proposed changes:
>>>> 1. Overturn a WS-AM 1.0 restriction that wsam:Addressing be limited
>>>> to an endpoint policy subject [2]: Mandates these assertions be
>>>> attached to a WSDL 1.1 port, binding or wsdl11:binding/wsdl:operation.
>>>> 2. Could conflict with WS-Policy best practices on altering
>>>> semantics of existing assertions for a policy subject: Allows a
>>>> policy assertion to be used across different policy subjects
>>>> without versioning or a clear indication how to differentiate
>>>> semantics for assertion implementers. [3]
>>>> 3. Disregards the existing structure of WS-AM policy assertions
>>>> that can support such a Description without this change and without
>>>> jeopardizing backward compatibility [4]: This proposal affects
>>>> interoperable implementations that tested in July 2007 into
>>>> non-conforming implementations. [5]
>>>> 4. Introduces a substantive change or new conflicting feature to
>>>> WS-AM.
>>>>
>>>> Can you also advise what is the maintenance plan for the
>>>> WS-Addressing WG? Can you comment or act on this substantive WS-AM
>>>> change? Are you in agreement to such a change in WS-I? [6]
>>>>
>>>> Your prompt attention would be appreciated. Responses can be
>>>> directed to the chair of the WS-I Basic Profile WG. Thanks.
>>>>
>>>> Jitendra Kotamraju, Sun Microsystems
>>>> Monica J. Martin, Microsoft Corporation
>>>>
>>>> [1] IBM request resolution:
>>>> http://lists.w3.org/Archives/Public/public-ws-addressing/2008Jul/0001.html
>>>>
>>>> [2] The same approach was also taken by SOAP/XMLP for MTOM.
>>>> [3] The wsam:Addressing policy assertion is applied on multiple
>>>> policy subjects with differing semantics - No versioning is use. No
>>>> mechanism is provided for existing implementations to be backward
>>>> compatible. Clients may be unable to find a compatible policy.
>>>> http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/#supporting-new-policy-subjects,
>>>> http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/#bp-WSDL-multiple-policy-subjects,
>>>> http://www.w3.org/TR/2007/NOTE-ws-policy-primer-20071112/#versioning-policy-language,
>>>> http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/#CalculatingEffectivyPolicywithWSDL1.1
>>>> and
>>>> http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/#versioning-policy-assertions
>>>> < http://www.w3.org/TR/2007/NOTE-%0Aws-policy-guidelines-20071112/#versioning-policy-assertions>
>>>>
>>>> [4] A portType can be separated into two separate ones, one which
>>>> contains one type of operations and the other which targets another
>>>> type. This description supports interface related features sought
>>>> by tools as was envisioned by W3C. [5]
>>>> http://dev.w3.org/2004/ws/addressing/testsuitewsdl/report/>>>> [6] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-modify
>>>> and
>>>> http://www.w3.org/2005/10/Process-20051014/tr.html#correction-classes>>>>
>>>>
>>>>
>>>>
>>>> Notice: This email message, together with any attachments, may
>>>> contain information of BEA Systems, Inc., its subsidiaries
>>>> and affiliated entities, that may be confidential, proprietary,
>>>> copyrighted and/or legally privileged, and is intended solely for
>>>> the use of the individual or entity named in this message. If you
>>>> are not the intended recipient, and have received this message in
>>>> error, please immediately return this by email and then delete it.
>>>>
>>
>
|
|
RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
Did we duck or actually say the following in section 4.1?
{It is RECOMMENDED that, where specific policy assertions associated
with one policy subject are only compatible with specific policy
assertions on another policy subject in the same hierarchical chain, the
policies containing these assertions should be attached within a single
WSDL binding hierarchy.
For any given port, the policy alternatives for each policy subject type
SHOULD be compatible with each of the policy alternatives at each of the
policy subjects parent and child policy subjects, such that choices
between policy alternatives at each level are independent of each
other.}
We did not address what should happen when conflicts arise, but the
recommendation is not to create conflicts in the first place...
--umit
-----Original Message-----
From: public-ws-addressing-request@...
[mailto: public-ws-addressing-request@...] On Behalf Of ashok malhotra
Sent: Thursday, February 12, 2009 3:29 PM
To: Anish Karmarkar
Cc: Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob Freund;
ylafon@...; public-ws-addressing@...; Jitendra.Kotamraju@...;
Ram Jeyaraman; wsi_wsbasic@...; 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/#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.
>>>>
>>
>
|
|
Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
Hi Umit, good to hear from you!
Unfortunately, this is like a eleventh commandment -- Thou shalt not
attach incompatible policies
It does not say how incompatible policies can be detected, nor does it
say what to do when you find incompatible policies
But I think we are getting away from the original topic.
All the best, Ashok
Yalcinalp, Umit wrote:
> Did we duck or actually say the following in section 4.1?
>
> {It is RECOMMENDED that, where specific policy assertions associated
> with one policy subject are only compatible with specific policy
> assertions on another policy subject in the same hierarchical chain, the
> policies containing these assertions should be attached within a single
> WSDL binding hierarchy.
>
> For any given port, the policy alternatives for each policy subject type
> SHOULD be compatible with each of the policy alternatives at each of the
> policy subjects parent and child policy subjects, such that choices
> between policy alternatives at each level are independent of each
> other.}
>
> We did not address what should happen when conflicts arise, but the
> recommendation is not to create conflicts in the first place...
>
> --umit
>
>
> -----Original Message-----
> From: public-ws-addressing-request@...
> [mailto: public-ws-addressing-request@...] On Behalf Of ashok malhotra
> Sent: Thursday, February 12, 2009 3:29 PM
> To: Anish Karmarkar
> Cc: Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob Freund;
> ylafon@...; public-ws-addressing@...; Jitendra.Kotamraju@...;
> Ram Jeyaraman; wsi_wsbasic@...; 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.
>>>>>
>>>>>
>
>
>
|
|
RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
I thought the "explanation" was that policy compatibility was
domain-dependent, and could not be stated in a general way?
But yes, something of a diversion from topic.
Tony Rogers
tony.rogers@...
-----Original Message-----
From: public-ws-addressing-request@...
[mailto: public-ws-addressing-request@...] On Behalf Of ashok malhotra
Sent: Friday, 13 February 2009 11:23
To: Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
Hi Umit, good to hear from you!
Unfortunately, this is like a eleventh commandment -- Thou shalt not
attach incompatible policies
It does not say how incompatible policies can be detected, nor does it
say what to do when you find incompatible policies
But I think we are getting away from the original topic.
All the best, Ashok
Yalcinalp, Umit wrote:
> Did we duck or actually say the following in section 4.1?
>
> {It is RECOMMENDED that, where specific policy assertions associated
> with one policy subject are only compatible with specific policy
> assertions on another policy subject in the same hierarchical chain,
the
> policies containing these assertions should be attached within a
single
> WSDL binding hierarchy.
>
> For any given port, the policy alternatives for each policy subject
type
> SHOULD be compatible with each of the policy alternatives at each of
the
> policy subjects parent and child policy subjects, such that choices
> between policy alternatives at each level are independent of each
> other.}
>
> We did not address what should happen when conflicts arise, but the
> recommendation is not to create conflicts in the first place...
>
> --umit
>
>
> -----Original Message-----
> From: public-ws-addressing-request@...
> [mailto: public-ws-addressing-request@...] On Behalf Of ashok
malhotra
> Sent: Thursday, February 12, 2009 3:29 PM
> To: Anish Karmarkar
> Cc: Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob Freund;
> ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...;
> Ram Jeyaraman; wsi_wsbasic@...; 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
>>>>> 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.
>>>>>
>>>>>
>
>
>
|
|
RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
I go away and look what happens :-) Read Section 4.5 carefully, mate.
Not all compatibility is domain specific. If you do not have assertion
params, you have the Qnames to go with for compatibility. The whole idea
is to rely on the types as much as possible and make the exceptions an
exception, not a norm, so that one could rely on a program, not a human
to make the determination of compatibility, whether it is lax or strict.
Thus, compatibility is well defined in a domain-independent world. This
is why parametric assertions of the past became the nested assertions of
today.
But, I will sign off for now. Have fun!
HTH,
--umit
-----Original Message-----
From: Rogers, Tony [mailto: Tony.Rogers@...]
Sent: Thursday, February 12, 2009 4:34 PM
To: ashok.malhotra@...; Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
I thought the "explanation" was that policy compatibility was
domain-dependent, and could not be stated in a general way?
But yes, something of a diversion from topic.
Tony Rogers
tony.rogers@...
-----Original Message-----
From: public-ws-addressing-request@...
[mailto: public-ws-addressing-request@...] On Behalf Of ashok malhotra
Sent: Friday, 13 February 2009 11:23
To: Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
Hi Umit, good to hear from you!
Unfortunately, this is like a eleventh commandment -- Thou shalt not
attach incompatible policies
It does not say how incompatible policies can be detected, nor does it
say what to do when you find incompatible policies
But I think we are getting away from the original topic.
All the best, Ashok
Yalcinalp, Umit wrote:
> Did we duck or actually say the following in section 4.1?
>
> {It is RECOMMENDED that, where specific policy assertions associated
> with one policy subject are only compatible with specific policy
> assertions on another policy subject in the same hierarchical chain,
the
> policies containing these assertions should be attached within a
single
> WSDL binding hierarchy.
>
> For any given port, the policy alternatives for each policy subject
type
> SHOULD be compatible with each of the policy alternatives at each of
the
> policy subjects parent and child policy subjects, such that choices
> between policy alternatives at each level are independent of each
> other.}
>
> We did not address what should happen when conflicts arise, but the
> recommendation is not to create conflicts in the first place...
>
> --umit
>
>
> -----Original Message-----
> From: public-ws-addressing-request@...
> [mailto: public-ws-addressing-request@...] On Behalf Of ashok
malhotra
> Sent: Thursday, February 12, 2009 3:29 PM
> To: Anish Karmarkar
> Cc: Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob Freund;
> ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...;
> Ram Jeyaraman; wsi_wsbasic@...; 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
>>>>> 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.
>>>>>
>>>>>
>
>
>
|
|
Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
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: Tony.Rogers@...]
> Sent: Thursday, February 12, 2009 4:34 PM
> To: ashok.malhotra@...; Yalcinalp, Umit
> Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
> Freund; ylafon@...; public-ws-addressing@...;
> Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
> Fabian Ritzmann
> Subject: RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
> (re: [wsi_wsbasic] BP 20133: proposal 1)
>
> I thought the "explanation" was that policy compatibility was
> domain-dependent, and could not be stated in a general way?
>
> But yes, something of a diversion from topic.
>
> Tony Rogers
> tony.rogers@...
>
> -----Original Message-----
> From: public-ws-addressing-request@...
> [mailto: public-ws-addressing-request@...] On Behalf Of ashok malhotra
> Sent: Friday, 13 February 2009 11:23
> To: Yalcinalp, Umit
> Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
> Freund; ylafon@...; public-ws-addressing@...;
> Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
> Fabian Ritzmann
> Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
> (re: [wsi_wsbasic] BP 20133: proposal 1)
>
>
> Hi Umit, good to hear from you!
>
> Unfortunately, this is like a eleventh commandment -- Thou shalt not
> attach incompatible policies
> It does not say how incompatible policies can be detected, nor does it
> say what to do when you find incompatible policies
>
> But I think we are getting away from the original topic.
>
> All the best, Ashok
>
>
> Yalcinalp, Umit wrote:
>> Did we duck or actually say the following in section 4.1?
>>
>> {It is RECOMMENDED that, where specific policy assertions associated
>> with one policy subject are only compatible with specific policy
>> assertions on another policy subject in the same hierarchical chain,
> the
>> policies containing these assertions should be attached within a
> single
>> WSDL binding hierarchy.
>>
>> For any given port, the policy alternatives for each policy subject
> type
>> SHOULD be compatible with each of the policy alternatives at each of
> the
>> policy subjects parent and child policy subjects, such that choices
>> between policy alternatives at each level are independent of each
>> other.}
>>
>> We did not address what should happen when conflicts arise, but the
>> recommendation is not to create conflicts in the first place...
>>
>> --umit
>>
>>
>> -----Original Message-----
>> From: public-ws-addressing-request@...
>> [mailto: public-ws-addressing-request@...] On Behalf Of ashok
> malhotra
>> Sent: Thursday, February 12, 2009 3:29 PM
>> To: Anish Karmarkar
>> Cc: Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob Freund;
>> ylafon@...; public-ws-addressing@...;
> Jitendra.Kotamraju@...;
>> Ram Jeyaraman; wsi_wsbasic@...; 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.
>>>>>>
>>>>>>
>>
>>
>
>
>
|
|
Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
On 13. Feb 2009, at 08:40, Anish Karmarkar wrote:
> In this particular case, how would one know that
> wsam:AnonymousResponse conflicts with wsam:NonAnonymousResponse
> unless you have some domain-specific information. These are two
> different QNames.
>
> Based on the responses and the spec, it seems that the following
> three scenarios are identical:
> 1) NonAnon on binding and Anon on port
> 2) A policy on binding (or port) that says: <wsp:All>Anon + NonAnon</
> wsp:All>
> 3) NonAnon on binding and Anon on binding/operation (if this were to
> be allowed)
>
> So, I don't quite see why allowing addressing assertion on binding/
> operation makes things any more problematic than it already is (as
> far as this specific issue is concerned).
It seems that we have established that there may be conflicting
addressing policies and those conflicts can only be detected and
resolved in a domain-specific manner. Apparently that issue had been
ignored or not recognized by the WS-Addressing WG earlier. I believe
that the WS-Addressing WG would need to address that issue. The
proposal has highlighted this issue and addressing it would remove one
major concern with the proposal.
Fabian
> Yalcinalp, Umit wrote:
>> I go away and look what happens :-) Read Section 4.5 carefully, mate.
>> Not all compatibility is domain specific. If you do not have
>> assertion
>> params, you have the Qnames to go with for compatibility. The whole
>> idea
>> is to rely on the types as much as possible and make the exceptions
>> an
>> exception, not a norm, so that one could rely on a program, not a
>> human
>> to make the determination of compatibility, whether it is lax or
>> strict.
>> Thus, compatibility is well defined in a domain-independent world.
>> This
>> is why parametric assertions of the past became the nested
>> assertions of
>> today. But, I will sign off for now. Have fun! HTH, --umit
>> -----Original Message-----
>> From: Rogers, Tony [mailto: Tony.Rogers@...] Sent: Thursday,
>> February 12, 2009 4:34 PM
>> To: ashok.malhotra@...; Yalcinalp, Umit
>> Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin;
>> Bob
>> Freund; ylafon@...; public-ws-addressing@...;
>> Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
>> Fabian Ritzmann
>> Subject: RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance
>> Issue:
>> (re: [wsi_wsbasic] BP 20133: proposal 1)
>> I thought the "explanation" was that policy compatibility was
>> domain-dependent, and could not be stated in a general way?
>> But yes, something of a diversion from topic.
>> Tony Rogers
>> tony.rogers@...
>> -----Original Message-----
>> From: public-ws-addressing-request@...
>> [mailto: public-ws-addressing-request@...] On Behalf Of ashok
>> malhotra
>> Sent: Friday, 13 February 2009 11:23
>> To: Yalcinalp, Umit
>> Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin;
>> Bob
>> Freund; ylafon@...; public-ws-addressing@...;
>> Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
>> Fabian Ritzmann
>> Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance
>> Issue:
>> (re: [wsi_wsbasic] BP 20133: proposal 1)
>> Hi Umit, good to hear from you!
>> Unfortunately, this is like a eleventh commandment -- Thou shalt
>> not attach incompatible policies
>> It does not say how incompatible policies can be detected, nor does
>> it say what to do when you find incompatible policies
>> But I think we are getting away from the original topic.
>> All the best, Ashok
>> Yalcinalp, Umit wrote:
>>> Did we duck or actually say the following in section 4.1?
>>>
>>> {It is RECOMMENDED that, where specific policy assertions associated
>>> with one policy subject are only compatible with specific policy
>>> assertions on another policy subject in the same hierarchical chain,
>> the
>>> policies containing these assertions should be attached within a
>> single
>>> WSDL binding hierarchy.
>>>
>>> For any given port, the policy alternatives for each policy subject
>> type
>>> SHOULD be compatible with each of the policy alternatives at each of
>> the
>>> policy subjects parent and child policy subjects, such that choices
>>> between policy alternatives at each level are independent of each
>>> other.}
>>>
>>> We did not address what should happen when conflicts arise, but the
>>> recommendation is not to create conflicts in the first place...
>>>
>>> --umit
>>>
>>>
>>> -----Original Message-----
>>> From: public-ws-addressing-request@...
>>> [mailto: public-ws-addressing-request@...] On Behalf Of ashok
>> malhotra
>>> Sent: Thursday, February 12, 2009 3:29 PM
>>> To: Anish Karmarkar
>>> Cc: Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob Freund;
>>> ylafon@...; public-ws-addressing@...;
>> Jitendra.Kotamraju@...;
>>> Ram Jeyaraman; wsi_wsbasic@...; 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.
>>>>>>>
|
|
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 [Tony.Rogers@...]
Sent: Thursday, February 12, 2009 4:34 PM
To: ashok.malhotra@...; Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
I thought the "explanation" was that policy compatibility was
domain-dependent, and could not be stated in a general way?
But yes, something of a diversion from topic.
Tony Rogers
tony.rogers@...
-----Original Message-----
From: public-ws-addressing-request@...
[public-ws-addressing-request@...] On Behalf Of ashok malhotra
Sent: Friday, 13 February 2009 11:23
To: Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
Hi Umit, good to hear from you!
Unfortunately, this is like a eleventh commandment -- Thou shalt not
attach incompatible policies
It does not say how incompatible policies can be detected, nor does it
say what to do when you find incompatible policies
But I think we are getting away from the original topic.
All the best, Ashok
Yalcinalp, Umit wrote:
Did we duck or actually say the following in section 4.1?
{It is RECOMMENDED that, where specific policy assertions associated
with one policy subject are only compatible with specific policy
assertions on another policy subject in the same hierarchical chain,
the
policies containing these assertions should be attached within a
single
WSDL binding hierarchy.
For any given port, the policy alternatives for each policy subject
type
SHOULD be compatible with each of the policy alternatives at each of
the
policy subjects parent and child policy subjects, such that choices
between policy alternatives at each level are independent of each
other.}
We did not address what should happen when conflicts arise, but the
recommendation is not to create conflicts in the first place...
--umit
-----Original Message-----
From: public-ws-addressing-request@...
[public-ws-addressing-request@...] On Behalf Of ashok
malhotra
Sent: Thursday, February 12, 2009 3:29 PM
To: Anish Karmarkar
Cc: Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob Freund;
ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...;
Ram Jeyaraman; wsi_wsbasic@...; 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.
|
|
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
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 [Tony.Rogers@...]
Sent: Thursday, February 12, 2009 4:34 PM
To: ashok.malhotra@...; Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
I thought the "explanation" was that policy compatibility was
domain-dependent, and could not be stated in a general way?
But yes, something of a diversion from topic.
Tony Rogers
tony.rogers@...
-----Original Message-----
From: public-ws-addressing-request@...
[public-ws-addressing-request@...] On Behalf Of ashok malhotra
Sent: Friday, 13 February 2009 11:23
To: Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
Hi Umit, good to hear from you!
Unfortunately, this is like a eleventh commandment -- Thou shalt not
attach incompatible policies
It does not say how incompatible policies can be detected, nor does it
say what to do when you find incompatible policies
But I think we are getting away from the original topic.
All the best, Ashok
Yalcinalp, Umit wrote:
Did we duck or actually say the following in section 4.1?
{It is RECOMMENDED that, where specific policy assertions associated
with one policy subject are only compatible with specific policy
assertions on another policy subject in the same hierarchical chain,
the
policies containing these assertions should be attached within a
single
WSDL binding hierarchy.
For any given port, the policy alternatives for each policy subject
type
SHOULD be compatible with each of the policy alternatives at each of
the
policy subjects parent and child policy subjects, such that choices
between policy alternatives at each level are independent of each
other.}
We did not address what should happen when conflicts arise, but the
recommendation is not to create conflicts in the first place...
--umit
-----Original Message-----
From: public-ws-addressing-request@...
[public-ws-addressing-request@...] On Behalf Of ashok
malhotra
Sent: Thursday, February 12, 2009 3:29 PM
To: Anish Karmarkar
Cc: Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob Freund;
ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...;
Ram Jeyaraman; wsi_wsbasic@...; 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.
|
|
RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
Some parts of this message have been removed.
Learn more about Nabble's security policy.
[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
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
|
|
Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
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: Tony.Rogers@...] Sent: Thursday,
>>> February 12, 2009 4:34 PM
>>> To: ashok.malhotra@...; Yalcinalp, Umit
>>> Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin;
>>> Bob
>>> Freund; ylafon@...; public-ws-addressing@...;
>>> Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
>>> Fabian Ritzmann
>>> Subject: RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance
>>> Issue:
>>> (re: [wsi_wsbasic] BP 20133: proposal 1)
>>> I thought the "explanation" was that policy compatibility was
>>> domain-dependent, and could not be stated in a general way?
>>> But yes, something of a diversion from topic.
>>> Tony Rogers
>>> tony.rogers@...
>>> -----Original Message-----
>>> From: public-ws-addressing-request@...
>>> [mailto: public-ws-addressing-request@...] On Behalf Of ashok
>>> malhotra
>>> Sent: Friday, 13 February 2009 11:23
>>> To: Yalcinalp, Umit
>>> Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin;
>>> Bob
>>> Freund; ylafon@...; public-ws-addressing@...;
>>> Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
>>> Fabian Ritzmann
>>> Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance
>>> Issue:
>>> (re: [wsi_wsbasic] BP 20133: proposal 1)
>>> Hi Umit, good to hear from you!
>>> Unfortunately, this is like a eleventh commandment -- Thou shalt
>>> not attach incompatible policies
>>> It does not say how incompatible policies can be detected, nor
>>> does it say what to do when you find incompatible policies
>>> But I think we are getting away from the original topic.
>>> All the best, Ashok
>>> Yalcinalp, Umit wrote:
>>>> Did we duck or actually say the following in section 4.1?
>>>>
>>>> {It is RECOMMENDED that, where specific policy assertions
>>>> associated
>>>> with one policy subject are only compatible with specific policy
>>>> assertions on another policy subject in the same hierarchical
>>>> chain,
>>> the
>>>> policies containing these assertions should be attached within a
>>> single
>>>> WSDL binding hierarchy.
>>>>
>>>> For any given port, the policy alternatives for each policy subject
>>> type
>>>> SHOULD be compatible with each of the policy alternatives at each
>>>> of
>>> the
>>>> policy subjects parent and child policy subjects, such that choices
>>>> between policy alternatives at each level are independent of each
>>>> other.}
>>>>
>>>> We did not address what should happen when conflicts arise, but the
>>>> recommendation is not to create conflicts in the first place...
>>>>
>>>> --umit
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: public-ws-addressing-request@...
>>>> [mailto: public-ws-addressing-request@...] On Behalf Of ashok
>>> malhotra
>>>> Sent: Thursday, February 12, 2009 3:29 PM
>>>> To: Anish Karmarkar
>>>> Cc: Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob Freund;
>>>> ylafon@...; public-ws-addressing@...;
>>> Jitendra.Kotamraju@...;
>>>> Ram Jeyaraman; wsi_wsbasic@...; 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.
>>>>>>>>
|
|
Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
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
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 [Tony.Rogers@...]
Sent: Thursday, February 12, 2009 4:34 PM
To: ashok.malhotra@...; Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
I thought the "explanation" was that policy compatibility was
domain-dependent, and could not be stated in a general way?
But yes, something of a diversion from topic.
Tony Rogers
tony.rogers@...
-----Original Message-----
From: public-ws-addressing-request@...
[public-ws-addressing-request@...] On Behalf Of ashok malhotra
Sent: Friday, 13 February 2009 11:23
To: Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
Hi Umit, good to hear from you!
Unfortunately, this is like a eleventh commandment -- Thou shalt not
attach incompatible policies
It does not say how incompatible policies can be detected, nor does it
say what to do when you find incompatible policies
But I think we are getting away from the original topic.
All the best, Ashok
Yalcinalp, Umit wrote:
Did we duck or actually say the following in section 4.1?
{It is RECOMMENDED that, where specific policy assertions associated
with one policy subject are only compatible with specific policy
assertions on another policy subject in the same hierarchical chain,
the
policies containing these assertions should be attached within a
single
WSDL binding hierarchy.
For any given port, the policy alternatives for each policy subject
type
SHOULD be compatible with each of the policy alternatives at each of
the
policy subjects parent and child policy subjects, such that choices
between policy alternatives at each level are independent of each
other.}
We did not address what should happen when conflicts arise, but the
recommendation is not to create conflicts in the first place...
--umit
-----Original Message-----
From: public-ws-addressing-request@...
[public-ws-addressing-request@...] On Behalf Of ashok
malhotra
Sent: Thursday, February 12, 2009 3:29 PM
To: Anish Karmarkar
Cc: Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob Freund;
ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...;
Ram Jeyaraman; wsi_wsbasic@...; 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.
|
|
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 [Tony.Rogers@...] Sent: Thursday, February
12, 2009 4:34 PM
To: ashok.malhotra@...; Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
I thought the "explanation" was that policy compatibility was
domain-dependent, and could not be stated in a general way?
But yes, something of a diversion from topic.
Tony Rogers
tony.rogers@...
-----Original Message-----
From: public-ws-addressing-request@...
[public-ws-addressing-request@...] On Behalf Of ashok
malhotra
Sent: Friday, 13 February 2009 11:23
To: Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
Hi Umit, good to hear from you!
Unfortunately, this is like a eleventh commandment -- Thou shalt not
attach incompatible policies
It does not say how incompatible policies can be detected, nor does it
say what to do when you find incompatible policies
But I think we are getting away from the original topic.
All the best, Ashok
Yalcinalp, Umit wrote:
Did we duck or actually say the
following in section 4.1?
{It is RECOMMENDED that, where specific policy assertions associated
with one policy subject are only compatible with specific policy
assertions on another policy subject in the same hierarchical chain,
the
policies containing these assertions
should be attached within a
single
WSDL binding hierarchy.
For any given port, the policy alternatives for each policy subject
type
SHOULD be compatible with each of the
policy alternatives at each of
the
policy subjects parent and child policy
subjects, such that choices
between policy alternatives at each level are independent of each
other.}
We did not address what should happen when conflicts arise, but the
recommendation is not to create conflicts in the first place...
--umit
-----Original Message-----
From: public-ws-addressing-request@...
[public-ws-addressing-request@...] On Behalf Of ashok
malhotra
Sent: Thursday, February 12, 2009 3:29
PM
To: Anish Karmarkar
Cc: Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob Freund;
ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...;
Ram Jeyaraman; wsi_wsbasic@...;
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.
|
|
RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
Looks like the perfect thing that an "errata" process
should handle.
--umit
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 [Tony.Rogers@...] Sent:
Thursday, February 12, 2009 4:34 PM
To: ashok.malhotra@...;
Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz;
Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...;
Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: RE: [wsi_wsbasic] Re:
WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP
20133: proposal 1)
I thought the "explanation" was that policy
compatibility was
domain-dependent, and could not be stated in a
general way?
But yes, something of a diversion from topic.
Tony
Rogers
tony.rogers@...
-----Original Message-----
From: public-ws-addressing-request@...
[public-ws-addressing-request@...]
On Behalf Of ashok malhotra
Sent: Friday, 13 February 2009 11:23
To: Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi;
Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...;
Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: Re: [wsi_wsbasic] Re:
WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP
20133: proposal 1)
Hi Umit, good to hear from you!
Unfortunately, this is like a eleventh commandment -- Thou shalt not
attach incompatible policies
It does not say how incompatible
policies can be detected, nor does it say what to do when you find
incompatible policies
But I think we are getting away from the
original topic.
All the best, Ashok
Yalcinalp, Umit wrote:
Did we duck or actually say the following in
section 4.1?
{It is RECOMMENDED that, where specific policy
assertions associated
with one policy subject are only compatible
with specific policy
assertions on another policy subject in the
same hierarchical chain,
the
policies containing these assertions should be
attached within a
single
WSDL binding hierarchy.
For any given
port, the policy alternatives for each policy subject
type
SHOULD be compatible with each of the policy
alternatives at each of
the
policy subjects parent and child policy
subjects, such that choices
between policy alternatives at each
level are independent of each
other.}
We did not address
what should happen when conflicts arise, but the
recommendation is
not to create conflicts in the first place...
--umit
-----Original Message-----
From: public-ws-addressing-request@...
[public-ws-addressing-request@...]
On Behalf Of ashok
malhotra
Sent: Thursday, February 12, 2009 3:29 PM
To: Anish Karmarkar
Cc: Rama Pulavarthi; Gilbert Pilz; Monica
Martin; Bob Freund;
ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...;
Ram Jeyaraman; wsi_wsbasic@...;
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.
|
|
Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
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 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 [Tony.Rogers@...] Sent: Thursday, February 12, 2009 4:34 PM
To: ashok.malhotra@...; Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
I thought the "explanation" was that policy compatibility was
domain-dependent, and could not be stated in a general way?
But yes, something of a diversion from topic.
Tony Rogers
tony.rogers@...
-----Original Message-----
From: public-ws-addressing-request@...
[public-ws-addressing-request@...] On Behalf Of ashok malhotra
Sent: Friday, 13 February 2009 11:23
To: Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...; Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
Hi Umit, good to hear from you!
Unfortunately, this is like a eleventh commandment -- Thou shalt not attach incompatible policies
It does not say how incompatible policies can be detected, nor does it say what to do when you find incompatible policies
But I think we are getting away from the original topic.
All the best, Ashok
Yalcinalp, Umit wrote:
Did we duck or actually say the following in section 4.1?
{It is RECOMMENDED that, where specific policy assertions associated
with one policy subject are only compatible with specific policy
assertions on another policy subject in the same hierarchical chain,
the
policies containing these assertions should be attached within a
single
WSDL binding hierarchy.
For any given port, the policy alternatives for each policy subject
type
SHOULD be compatible with each of the policy alternatives at each of
the
policy subjects parent and child policy subjects, such that choices
between policy alternatives at each level are independent of each
other.}
We did not address what should happen when conflicts arise, but the
recommendation is not to create conflicts in the first place...
--umit
-----Original Message-----
From: public-ws-addressing-request@...
[public-ws-addressing-request@...] On Behalf Of ashok
malhotra
Sent: Thursday, February 12, 2009 3:29 PM
To: Anish Karmarkar
Cc: Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob Freund;
ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...;
Ram Jeyaraman; wsi_wsbasic@...; 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.
|
|
Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: (re: [wsi_wsbasic] BP 20133: proposal 1)
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
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 [Tony.Rogers@...]
Sent: Thursday, February 12, 2009 4:34 PM
To: ashok.malhotra@...;
Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...;
Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
I thought the "explanation" was that policy compatibility was
domain-dependent, and could not be stated in a general way?
But yes, something of a diversion from topic.
Tony Rogers
tony.rogers@...
-----Original Message-----
From: public-ws-addressing-request@...
[public-ws-addressing-request@...]
On Behalf Of ashok malhotra
Sent: Friday, 13 February 2009 11:23
To: Yalcinalp, Umit
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob
Freund; ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...;
Ram Jeyaraman; wsi_wsbasic@...;
Fabian Ritzmann
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:
(re: [wsi_wsbasic] BP 20133: proposal 1)
Hi Umit, good to hear from you!
Unfortunately, this is like a eleventh commandment -- Thou shalt not
attach incompatible policies
It does not say how incompatible policies can be detected, nor does it
say what to do when you find incompatible policies
But I think we are getting away from the original topic.
All the best, Ashok
Yalcinalp, Umit wrote:
Did we duck or actually say the
following in section 4.1?
{It is RECOMMENDED that, where specific policy assertions associated
with one policy subject are only compatible with specific policy
assertions on another policy subject in the same hierarchical chain,
the
policies containing these
assertions should be attached within a
single
WSDL binding hierarchy.
For any given port, the policy alternatives for each policy subject
type
SHOULD be compatible with each of
the policy alternatives at each of
the
policy subjects parent and child
policy subjects, such that choices
between policy alternatives at each level are independent of each
other.}
We did not address what should happen when conflicts arise, but the
recommendation is not to create conflicts in the first place...
--umit
-----Original Message-----
From: public-ws-addressing-request@...
[public-ws-addressing-request@...]
On Behalf Of ashok
malhotra
Sent: Thursday, February 12, 2009
3:29 PM
To: Anish Karmarkar
Cc: Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob Freund;
ylafon@...; public-ws-addressing@...;
Jitendra.Kotamraju@...;
Ram Jeyaraman; wsi_wsbasic@...;
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) 