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: Jonathan Marsh <jmarsh@microsoft.com>
Date: Fri, 14 Oct 2005 13:53:47 -0700
Message-ID: <37D0366A39A9044286B2783EB4C3C4E868A92A@RED-MSG-10.redmond.corp.microsoft.com>
To: "Katy Warr" <katy_warr@uk.ibm.com>, <public-ws-addressing@w3.org>
If you can't change your WSDL, you can't use the wsa:UsingAddressing
extension, and it seems to me all bets are off.  Perhaps we could say
that, in the absence of wsa:UsingAddressing, implementations supporting
WS-Addressing SHOULD use the value of soapAction as the wsa:Action.  I
say SHOULD because I can't think of any way to enforce it.  (This
proposal is probably not as simple as it sounds.)

 

I agree duplicate information is a bummer, but over time I expect
soapAction use to decline and wsaw:Action use to flourish.  YMMV.  It
would also be a bummer if our algorithm was more complex than it needs
to be to support a case that becomes increasingly rare.

 

P.S. +1 to Anish's desire to think more about whether the tight linkage
between soapAction and wsa:Action is wise.

 

________________________________

From: Katy Warr [mailto:katy_warr@uk.ibm.com] 
Sent: Monday, October 10, 2005 1:06 PM
To: Jonathan Marsh; public-ws-addressing@w3.org
Subject: 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 <soap:binding>  style="document"
transport="http://schemas.xmlsoap.org/soap/http"
<http://schemas.xmlsoap.org/soap/http>  /> 
<wsaw:UsingAddressing wsdl:required="true" /> 
<operation name="GetLastTradePrice"> 
  <soap:operation <soap:operation>
soapAction="http://example.com/GetLastTradePrice"
<http://example.com/GetLastTradePrice>  /> 
  <input> 
    <soap:body <soap:body>  use="literal" /> 
  </input> 
  <output> 
    <soap:body <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
<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 Friday, 14 October 2005 20:54:00 GMT

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