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

I'll try to avoid spitting the dummy in this e-mail at least... ;-)

It does feel like this question is spiralling out of control... and I 
don't think it has to.

It is my assertion that the BP use cases could be satisfied by:
1. Allowing WS-A assertions to be attached to the binding operation if and 
only if no WS-Addressing assertions are attached at the endpoint subject
2. WS-A assertions must be present either on all binding operations of a 
given binding or none of them.

This:
1. Allows operation level control of WS-A sync/async
2. Satisfies the very good advice of WS-Policy 1.5 Attachment section 4.1
3. Retains the existing semantics of the WS-A assertions
4. Can be summed up in a couple of sentences (seems suited to BP...)
5. Provides a simple WSDL level conformance check (it's one place or the 
other.... seems suited to BP)

It does not:
1. Address what policy frameworks should do when they come across policy 
alternatives which are invalid per WS-A Metadata 3.1.3
        Personally, I expect most WS-A policy domain code to spit the 
dummy, but having written that code a couple of times, the processing 
happens at times when that's an appropriate thing to do.
2. Provide a concise 'override' format for WS-A Policy in WSDL...

David

David Illsley
MP211, IBM Hursley Park, SO21 2JN
+44 (0)1962 815049 (Int. 245049)
david.illsley@uk.ibm.com



From:
Bob Freund <Bob.Freund@hitachisoftware.com>
To:
"Yalcinalp, Umit" <umit.yalcinalp@sap.com>
Cc:
Gilbert Pilz <gilbert.pilz@oracle.com>, Fabian Ritzmann 
<Fabian.Ritzmann@Sun.COM>, Anish Karmarkar <Anish.Karmarkar@oracle.com>, 
"Rogers, Tony" <Tony.Rogers@ca.com>, ashok.malhotra@oracle.com, Rama 
Pulavarthi <Rama.Pulavarthi@Sun.COM>, Monica Martin 
<momartin@microsoft.com>, ylafon@w3.org, public-ws-addressing@w3.org, 
Jitendra.Kotamraju@Sun.COM, Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>, 
wsi_wsbasic@mp.ws-i.org
Date:
16/02/2009 18:05
Subject:
Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue:  (re: 
[wsi_wsbasic]  BP 20133: proposal 1)
Sent by:
public-ws-addressing-request@w3.org



Draft insertion as part of the errata process:

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

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

-bob

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

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

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
Sent: Saturday, February 14, 2009 4:16 PM
To: Bob Freund
Cc: Fabian Ritzmann; Anish Karmarkar; Yalcinalp, Umit; Rogers, Tony; 
ashok.malhotra@oracle.com; Rama Pulavarthi; Monica Martin; ylafon@w3.org; 
public-ws-addressing@w3.org; Jitendra.Kotamraju@Sun.COM; Ram Jeyaraman; 
wsi_wsbasic@mp.ws-i.org
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: 
(re: [wsi_wsbasic] BP 20133: proposal 1)

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

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

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

</wsdl:definitions>

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

- gp

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

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


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

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

In this particular case, how would one know that wsam:AnonymousResponse 
conflicts with wsam:NonAnonymousResponse unless you have some 
domain-specific information. These are two different QNames. 

Based on the responses and the spec, it seems that the following three 
scenarios are identical: 
1) NonAnon on binding and Anon on port 
2) A policy on binding (or port) that says: <wsp:All>Anon + 
NonAnon</wsp:All> 
3) NonAnon on binding and Anon on binding/operation (if this were to be 
allowed) 

So, I don't quite see why allowing addressing assertion on 
binding/operation makes things any more problematic than it already is (as 
far as this specific issue is concerned). 

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

Fabian 


Yalcinalp, Umit wrote: 
I go away and look what happens :-) Read Section 4.5 carefully, mate. 
Not all compatibility is domain specific. If you do not have assertion 
params, you have the Qnames to go with for compatibility. The whole idea 
is to rely on the types as much as possible and make the exceptions an 
exception, not a norm, so that one could rely on a program, not a human 
to make the determination of compatibility, whether it is lax or strict. 
Thus, compatibility is well defined in a domain-independent world. This 
is why parametric assertions of the past became the nested assertions of 
today. But, I will sign off for now. Have fun!   HTH, --umit 
-----Original Message----- 
From: Rogers, Tony [mailto:Tony.Rogers@ca.com] Sent: Thursday, February 
12, 2009 4:34 PM 
To: ashok.malhotra@oracle.com; Yalcinalp, Umit 
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob 
Freund; ylafon@w3.org; public-ws-addressing@w3.org; 
Jitendra.Kotamraju@Sun.COM; Ram Jeyaraman; wsi_wsbasic@mp.ws-i.org; 
Fabian Ritzmann 
Subject: RE: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: 
(re: [wsi_wsbasic] BP 20133: proposal 1) 
I thought the "explanation" was that policy compatibility was 
domain-dependent, and could not be stated in a general way? 
But yes, something of a diversion from topic. 
Tony Rogers 
tony.rogers@ca.com 
-----Original Message----- 
From: public-ws-addressing-request@w3.org 
[mailto:public-ws-addressing-request@w3.org] On Behalf Of ashok malhotra 
Sent: Friday, 13 February 2009 11:23 
To: Yalcinalp, Umit 
Cc: Anish Karmarkar; Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob 
Freund; ylafon@w3.org; public-ws-addressing@w3.org; 
Jitendra.Kotamraju@Sun.COM; Ram Jeyaraman; wsi_wsbasic@mp.ws-i.org; 
Fabian Ritzmann 
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance Issue: 
(re: [wsi_wsbasic] BP 20133: proposal 1) 
Hi Umit, good to hear from you! 
Unfortunately, this is like a eleventh commandment -- Thou shalt not 
attach incompatible policies 
It does not say how incompatible policies can be detected, nor does it say 
what to do when you find incompatible policies 
But I think we are getting away from the original topic. 
All the best, Ashok 
Yalcinalp, Umit wrote: 
Did we duck or actually say the following in section 4.1? 

{It is RECOMMENDED that, where specific policy assertions associated 
with one policy subject are only compatible with specific policy 
assertions on another policy subject in the same hierarchical chain, 
the 
policies containing these assertions should be attached within a 
single 
WSDL binding hierarchy. 

For any given port, the policy alternatives for each policy subject 
type 
SHOULD be compatible with each of the policy alternatives at each of 
the 
policy subjects parent and child policy subjects, such that choices 
between policy alternatives at each level are independent of each 
other.} 

We did not address what should happen when conflicts arise, but the 
recommendation is not to create conflicts in the first place... 

--umit 


-----Original Message----- 
From: public-ws-addressing-request@w3.org 
[mailto:public-ws-addressing-request@w3.org] On Behalf Of ashok 
malhotra 
Sent: Thursday, February 12, 2009 3:29 PM 
To: Anish Karmarkar 
Cc: Rama Pulavarthi; Gilbert Pilz; Monica Martin; Bob Freund; 
ylafon@w3.org; public-ws-addressing@w3.org; 
Jitendra.Kotamraju@Sun.COM; 
Ram Jeyaraman; wsi_wsbasic@mp.ws-i.org; Fabian Ritzmann 
Subject: Re: [wsi_wsbasic] Re: WS-AddressingMetadata Maintenance 
Issue: 
(re: [wsi_wsbasic] BP 20133: proposal 1) 


Unfortunately, WS-Policy ducked this question.  There are many situations 
where you can attach conflicting policies and there is no guidance as to 
what should be done.   Note that, in general, it can be 
difficult to tell if policies are in conflict. 
All the best, Ashok 


Anish Karmarkar wrote: 

Good question. 

Shouldn't the answer be the same as what would happen if the 
operation 


specific policy was instead attached to the port? This would give you 
conflicting policies on binding and port and would have to be merged. 
These attachment points are currently allowed by the spec. 

-Anish 
-- 

Rama Pulavarthi wrote: 

Some questions on the proposal. 

Gilbert Pilz wrote: 

As the authors of the proposal in question, Oracle feels obliged to 
refute the inaccuracies in the arguments presented by our 
colleagues 


from Microsoft and Sun as well as present our case with regards to the 
proposal. 

With regards to the particular points: 

1.) What this point fails to mention is that WS-Adressing 1.0 - Metadata 
(WS-AM 1.0) *already* states that the wsam:Addressing assertion can be 
attached to the wsdl11:port or wsd11l:binding. Our 
proposal *extends* the existing specification to allow this assertion to 
be attached to wsdl11:binding/wsdl11:operation and applies this extension 
to the Operation Policy Subject. Our 
proposal 


does not alter the structure or the semantics of the 
wsam:Addressing 


assertion. 

What if conflicting policies are attached at the Endpoint policy subject 
and Operation policy subject. 
For example, on wsdl:binding it is specified as 

<wsp:Policy> 
  <wsam:Addressing> 
      <wsp:Policy> 
          <wsam:NonAnonymousResponses/> 
      </wsp:Policy> 
  </wsam:Addressing> 
and on the </wsp:Policy> 

and on |wsdl11:binding/wsdl11:operation 
| 

<wsp:Policy> 
  <wsam:Addressing> 
      <wsp:Policy> 
          <wsam:AnonymousResponses/> 
      </wsp:Policy> 
  </wsam:Addressing> 
and on the </wsp:Policy> 

Which one should be used?, How is the effective policy for that operation 
calculated? 
Its not precedence but a merge of these policies that is used to calculate 
the effective policy as per 
http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/#merge. 

Is BP going to specify all the Addressing domain specific rules to handle 
merging of conflicting policies? 

2.) The assertion that this proposal conflicts with WS-Policy best 
practices is false. Reference [3] below includes the following 
text: 
  When the assertion's semantics do not change to invalidate any 

of 

  the original policy subjects but new policy subjects need to be 
  added, it may be possible to use the same assertion to 
designate 
  the additional policy subjects without a namespace change. For 
  example, a policy assertion for a protocol that is originally 
  designed for endpoint policy subject may add message policy 
  subject to indicate finer granularity in the attachment 
provided 
  that endpoint policy subject is also retained in its design. 

When 

  new policy subjects are added it is incumbent on the authors to 
  retain the semantic of the policy assertion 

Since our proposal includes this text: 

  When the WS-Addressing policy assertion occurs on the 
  wsdl11:binding/wsdl11:operation element, it applies to the 
  operation policy subject. Nevertheless, it should always be the 
  case that if one operation of an endpoint supports or requires 
  WS-Addressing, then all operations must support or require 
  WS-Addressing (although, potentially, with different 

restrictions) 

and the following requirement: 

  Ryyyy: /In a /*DESCRIPTION*/, if any operation of a WSDL 1.1 
  endpoint supports or requires WS-Addressing, then all the 
  operations of that endpoint MUST support or require 

WS-Addressing./ 

/As I understand, This goes against the policy scopes/ and effective 
policy calculation as defined in 

http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/#CalculatingEffe 
ctivyPolicywithWSDL1.1 
How can a policy specified at Operation policy subject affect the 
effective policy  at the Endpoint policy subject? The policy specified at 
Operation scope can add more non conflicting requirements to the policy 
specified at a higher level that will be effective only for that 
operation. 


thanks, 
Rama Pulavarthi 

it is clear that the semantics of the wsam:Addressing policy assertion are 
being retained and thus we are adhering to the guidelines described in 
[3]. 

3.) The claim that our proposal "disregards the existing structure of the 
WS-AM policy assertions" and jeopardizes backwards compatibility is false. 
As stated previously, our proposal does nothing to change the structure or 
the semantics of the wsam:Addressing assertion, it simply extends where 
such assertions can be attached. Furthermore, since it is an extension, 
our 
proposal 


logically cannot affect backwards compatibility. The 
implementations 


that interoperated at [5] should, baring any unrelated changes, continue 
to interoperate under the same test scenarios. 

4.) The assertion that this change is "substantive" is subjective. The 
notion that this extension conflicts with the existing wsam:Addressing 
semantics has been addressed above. 

The case for this proposal is straightforward: The current WS-Addressing 
1.0 - Metadata specification is technically 
deficient. 


It does not allow you to describe an interface that contains both 
synchronous and asynchronous operations. Input from our customers 
indicates that this is a common and important use case. The Web Services 
Test Forum provides an example of this in its Purchase Order Service 
scenario (http://www.wstf.org/docs/scenarios/sc009/sc009.xml). Although 
there 


are workarounds for this problem, they have side-effects that undermine 
the simplicity and utility of the interface description. 

One of the reasons Oracle raised this issue is the fact that this 
technical deficiency is the result of an oversight by the W3C Addressing 
Working Group, not the result of a deliberate decision. In the 
WS-Addressing 1.0 - WSDL Binding specification, the wsaw:Anonymous element 
extended the wsd11:binding/wsdl11:operation element thus allowing you to 
specify that a particular operation 
was 


either synchronous or asynchronous. As the WSDL Binding specification 
evolved into the Metadata specification, the wsam:AnonymousResponses and 
wsam:NonAnonymousResponses assertions (which each express a distinct value 
of what was wsaw:Anonymous) were folded into nested assertions beneath the 
top-level wsam:Addressing assertion. Although this change was, in itself, 
technically correct, it had the side-effect of removing the ability 
to specify synchronous/asynchronous behavior at the operation level 
since , as we have discussed, wsam:Addressing can currently only be 
attached to the wsdl11:port or wsdl11:binding and has Endpoint Policy 
Subject. Our proposal seeks to correct this flaw in a way that preserves 
the semantics of wsam:Addressing. 

Finally, we brought this issue to the WS-I Basic Profiles Working Group 
because the W3C WS-Addressing Working Group is closed. Although there have 
been some discussions about creating a group to 
maintain the WS-Addressing specifications within the W3C it seems 
unlikely, at this time, that such a group will be created. Since 
correcting profiled specifications has some precedent in WS-I and the 
Basic Profile Working Group, it seems to be the best place to attempt to 
fix this problem. 

Gilbert Pilz | SOA/WS Technologist | Middleware Standards | Oracle 
Corporation 

Monica Martin wrote: 

An issue has been filed in the WS-I Basic Profile WG that belongs to 
WS-Addressing WG with possible assistance from the WS-Policy 
WG. 


The issue was filed in WS-I Basic Profile WG because the WS-Addressing WG 
was closed. The issue seeks to overturn a fundamental concept and 
constraint in WS-Addressing-Metadata 1.0 and could conflict with WS-Policy 
best practices. We've 
paraphrased 


the features sought, requirements requested and potential conflict 
it presents for existing implementations of WS-Addressing Metadata 
1.0.  As a WS-A Core schema change was handled in late July 2008 
by 


W3C on behalf of the WS-Addressing WG [1], can you assist us in clarifying 
and resolving this issue? 

The proposed changes: 
1. Overturn a WS-AM 1.0 restriction that wsam:Addressing be 
limited 


to an endpoint policy subject [2]: Mandates these assertions be attached 
to a WSDL 1.1 port, binding or 

wsdl11:binding/wsdl:operation. 

2. Could conflict with WS-Policy best practices on altering semantics of 
existing assertions for a policy subject: Allows a policy assertion to be 
used across different policy subjects without versioning or a clear 
indication how to differentiate semantics for assertion implementers. [3] 
3. Disregards the existing structure of WS-AM policy assertions that can 
support such a Description without this change and 
without 


jeopardizing backward compatibility [4]: This proposal affects 
interoperable implementations that tested in July 2007 into non-conforming 
implementations. [5] 
4. Introduces a substantive change or new conflicting feature to WS-AM. 

Can you also advise what is the maintenance plan for the WS-Addressing WG? 
Can you comment or act on this substantive WS-AM 
change? Are you in agreement to such a change in WS-I? [6] 

Your prompt attention would be appreciated.  Responses can be directed to 
the chair of the WS-I Basic Profile WG. Thanks. 

Jitendra Kotamraju, Sun Microsystems 
Monica J. Martin, Microsoft Corporation 

[1] IBM request resolution: 

http://lists.w3.org/Archives/Public/public-ws-addressing/2008Jul/0001.ht 
ml 
[2] The same approach was also taken by SOAP/XMLP for MTOM. 
[3] The wsam:Addressing policy assertion is applied on multiple policy 
subjects with differing semantics - No versioning is use. 
No 


mechanism is provided for existing implementations to be backward 
compatible. Clients may be unable to find a compatible policy. 


http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/#supporting 
-new-policy-subjects, 
http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/#bp-WSDL-mu 
ltiple-policy-subjects, 
http://www.w3.org/TR/2007/NOTE-ws-policy-primer-20071112/#versioning-pol 
icy-language, 
http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/#CalculatingEffe 
ctivyPolicywithWSDL1.1 
and 

http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/#versioning 
-policy-assertions 
<http://www.w3.org/TR/2007/NOTE-%0Aws-policy-guidelines-20071112/#versio 
ning-policy-assertions> 
[4] A portType can be separated into two separate ones, one which contains 
one type of operations and the other which targets 
another 


type. This description supports interface related features sought by tools 
as was envisioned by W3C. [5] 
http://dev.w3.org/2004/ws/addressing/testsuitewsdl/report/ 
[6] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-modify and 

http://www.w3.org/2005/10/Process-20051014/tr.html#correction-classes 


Notice:  This email message, together with any attachments, may contain 
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
entities,  that may be confidential,  proprietary, 


copyrighted  and/or legally privileged, and is intended solely for 
the use of the individual or entity named in this message. If you are not 
the intended recipient, and have received this message in error, please 
immediately return this by email and then delete it. 










Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU