Ok have some interesting findings here. For the sake of arguments image a ws with 2 operations create & delete and with corresponding soap actions.
1. With HTTP if there are conflicting SOAP actions the are caught - i.e. HTTP SOAPAction & WSA-SoapAction 2. If I specify a HTTP SOAP Action of create but the body of the soap request corresponds to a deleteRequest my create operation invoked is invoked! 3. If I specify a WSA SOAP Action of create but the body of the soap request corresponds to a deleteRequest my delete operation is invoked! What is the expected be behaviour here? I spotted this over JMS first - a client send in a request with a SOAPAction on the JMS headers that was at odds with wsa-soap action. I know that the SOAPAction as a header for JMS is not part of the spec, but the CXF client was population the JMS string property SOAPAction. So in this case it seems that there is a difference in behavior! Btw this is with CXF 2.1.3 On Tue, Feb 3, 2009 at 6:12 PM, Daniel Kulp <[email protected]> wrote: > On Mon February 2 2009 7:01:26 am Adrian C wrote: > > Hi, > > > > Can someone clarify how CXF works with WS-A? I had some unexpected > results > > where a client was calling our web services with two different SOAP > actions > > (one on the transport headers, http in this case, the other in the WSA > > headers). > > Hmm... That's not good. I checked the WS-Addressing code and the > validateIncomingMAPs method should be checking that the two actions are > equal > and throwing a fault if they aren't. > > Any chance you can hook up a debugger and make sure that method is getting > called? > > > > The WS-A header as it turned out was incorrect however the > > correct operation was called? How can this be? I would have though the > the > > following would happen: > > > > 1. Check for ws-a headers & soap action there > > Technically, this SHOULD be irrelevant as the two actions should be > identical. > The check in MAPAggregator.validateIncomingMAPs should guarantee that. > The > first step is to make sure that is called. > > Dan > > > > 2. If no ws-a headers & soap action check for SOAP action in the > transport > > headers > > 3. If no action present use the contents of the SOAP:Body to determine > what > > operation to invoke. > > > > So can anyone clarify? > > > > Thanks. > > -- > Daniel Kulp > [email protected] > http://www.dankulp.com/blog >
