RE: New Issue: What to do when SOAPAction and Default Action Pattern conflict? it

Jonathan
I don't think it's sufficient because:
- Folk may not wish/be in a position to refresh their WSDL with the 
wsaw:Action
- Why mandate the duplication of the same piece of information in the 
service description when we can deduce it?
I don't think that this complicates things - for users of WS-Addressing it 
should make things easier. 
Katy




"Jonathan Marsh" <jmarsh@microsoft.com> 
10/10/2005 18:46

To
Katy Warr/UK/IBM@IBMGB, <public-ws-addressing@w3.org>
cc

Subject
RE: New Issue: What to do when SOAPAction and Default Action Pattern 
conflict? it






The currently available solution is to add wsaw:Action explicitly whenever 
you have a soapAction.  Isn?t that a sufficient answer?  Perhaps we could 
simply remind people of this solution.  Complicating our action defaulting 
algorithm further (by making it depend on information in another 
namespace) seems to me to likely be more confusing in the long run.
 

From: public-ws-addressing-request@w3.org 
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Katy Warr
Sent: Monday, October 10, 2005 8:57 AM
To: public-ws-addressing@w3.org
Subject: New Issue: What to do when SOAPAction and Default Action Pattern 
conflict?
 

I'd like to raise this as an issue. thanks 

----- Forwarded by Katy Warr/UK/IBM on 10/10/2005 16:56 ----- 

Pete Hendry <peter.hendry@capeclear.com> 
Sent by: public-ws-addressing-request@w3.org 
08/10/2005 04:58 


To
Katy Warr/UK/IBM@IBMGB 
cc
public-ws-addressing@w3.org 
Subject
Re: What to do when SOAPAction and Default Action Pattern conflict?
 


 
 




We have already seen this problem where the requirement is to take an 
already existing service and allow asynchronous calls against 
request-response operations (actually, we already did async in a 
proprietary config-file type way and now want to use WS-Addressing to 
achieve the same thing with old WSDLs).

I would agree with Katy that defaulting the input wsa:Action to the 
SOAPAction if present would solve this problem. The output and fault 
actions could keep their current defaults (I assume it is only the input 
wsa:Action that has to match SOAPAction).

Pete


Katy Warr wrote: 

What is the correct behaviour for gen'ing wsa:Action in the client when 
the HTTP 1.1 SOAPAction is set ( i.e. not "") and there is no wsaw:Action 
explicitly specified in the WSDL?   

The problem is that, the default action pattern for wsa:Action cannot be 
gauranteed to generate a wsa:action to match SOAPAction. 

Here is an example to illustrate: 

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> 
 <soap:binding style="document" transport="
http://schemas.xmlsoap.org/soap/http" /> 
 <wsaw:UsingAddressing wsdl:required="true" /> 
 <operation name="GetLastTradePrice"> 
   <soap:operation soapAction="http://example.com/GetLastTradePrice" /> 
   <input> 
     <soap:body use="literal" /> 
   </input> 
   <output> 
     <soap:body use="literal" /> 
   </output> 
 </operation> 
</binding> 

If we use the default action pattern to generate the wsa:Action, this is 
the result for the input operation 
http://example.com/StockQuotePortType/GetLastTradePriceInput 
As this is not  the same as the SOAPAction, this will cause 
non-compliance.  The WSDL in this case is implicitly inconsistent with the 
wsa spec - a problem which will occur in every existing WSDL 1.1 in which 
the values of SOAPAction have not been constructed according to the 
default action pattern. 

A possible solution is to set the wsa:Action header to SOAPAction (if 
SOAPAction =! "") in preference to using the default action pattern (if 
the wsa:Action is not specified explicitly). 

This would means a change something like this in the wsdl spec: 

4.3 Default Action  Pattern for WSDL 1.1 
In the absence of the wsa:Action attribute.... 
==>When using the SOAP 1.1 HTTP binding, if the SOAPAction is set, the 
action for inputs and outputs MUST be the same as this and the default 
action pattern is not used. <==