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

Ok, so the issue really is to allow people to use existing WSDLs with 
WSA 1.0 enabled (clients somehow figure out through non-WSDL mechanisms 
that WSA 1.0 is enabled/supported). In the case of non-empty soapAction, 
per the specs, right now this is just not possible.

So if we change the rules as you suggest then,
1) if wsaw:Action is explicitly specified then that is the value of 
wsa:Action
2) if wsaw:Action is not-explicitly specified then
a) the (current) default rules apply unless the binding rules override 
that default.
3) for soap binding, if the soapAction attribute is specified and is 
non-empty then the value of the soapAction is used as the value of 
wsa:Action for all the messages in that operation.

Makes things a little complicated. I guess we should decide about how 
important it is to support existing WSDLs. If it is, then it makes sense 
to go down the path that you suggest.

-Anish
--

Katy Warr wrote:
> 
> 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. <==
>

Received on Monday, 10 October 2005 20:39:48 UTC