W3C home > Mailing lists > Public > public-ws-addressing@w3.org > October 2005

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

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Mon, 10 Oct 2005 13:39:38 -0700
Message-ID: <434AD18A.5070400@oracle.com>
To: Katy Warr <katy_warr@uk.ibm.com>
CC: Jonathan Marsh <jmarsh@microsoft.com>, public-ws-addressing@w3.org

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:09 GMT