axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yampolsky, Robert" <>
Subject RE: soapAction and .NET interoperability
Date Wed, 11 May 2005 15:00:31 GMT
I don't know for sure that .NET clients don't set SOAPAction.  So far,
I've only tested my Axis client talking to my Axis service.  But the
orgainization that's defining the service I'm implementing gave me the
WSDL, and it was created by .NET tools with the following line in it:
 <soap:operation soapAction="" style="document" />
I was unable to get my Axis client to connect to the server until I put
a MyService#MyOperation string in place of the null string for
soapAction.  Actually, Axis accepted connections with just #MyOperation
- it seems to ignore the first part.
I haven't actually tested with the .NET client yet.  I was just assuming
that because their WSDL generated a non-working Axis client, that the
.NET client would also generat a null string in the SOAPAction header.
Microsoft documentation says this is legal - in this case, the URI is
supposed to be used to locate the service.  At least, that's what the
guy who's implementing his end with .NET said when I warned him that
this was going to cause a problem.  And Samisa seems to be saying this
is a known issue.
I did find an article on the web that implies (as you say) that it's
Axis that doesn't need SoapAction, whereas .NET requires it.  But when I
built my Axis client with SoapAction set to a null string, the Axis
server gave me a "not allowed to invoke" error.  I couldn't get it to
work until I specified SOAPAction as above.
Also, the stuff I brought up on Google about setting SOAPAction in .NET
just shows examples with the service URI  
    e.g.     SOAPAction:
which doesn't include the #Operation suffix that Axis seems to want.  So
even if .NET sets SOAPAction, it may not set it in a way that Axis is
willing to accept.  I guess I just need to get the guys who are building
with .NET to try to connect, see what they send and see what happens.

From: John Hawkins [] 
Sent: Wednesday, May 11, 2005 3:27 AM
To: Apache AXIS C User List
Subject: RE: soapAction and .NET interoperability

I'm confused by the .NET client not setting SOAPAction as this is
default requirement for .NET server (as I understood it) 

"Samisa Abeysinghe" <> wrote on 11/05/2005

> > Does anybody know of a workaround for this?  Either a way to define
> > service to not require soapAction or a way to 
> > get a .NET client to provide the method name in the soapAction
> There is no way in Axis C++ to define the service not to require the
> SOAPAction as of now. (But we wish to implement such kind of a
> - there is a Jira issue raised on this)
> Hence I think you have to figure out how to set the SOAPAction with
> client. I am not sure how to do this exactly but
> Topic.asp may lead to a clue.
> Thanks,
> Samisa...
> -----Original Message-----
> From: Yampolsky, Robert [] 
> Sent: Wednesday, May 11, 2005 2:39 AM
> To: Apache AXIS C User List
> Subject: soapAction and .NET interoperability
> I've seen posted here that Axis services don't work with soapAction
> to "".  I can verify that that's the case.  With no soapAction, I get
> "Soap method is not allowed to invoke" exception, but when I put it
> I'm able to access the service.  As a matter of fact, it seems to only
> require the method (i.e.  soapAction="#METHOD" works just as well as
> soapAction="SERVICE#METHOD").
> My problem is that I need to interoperate with .NET clients, and they
> don't seem to set soapAction (at least by default).
> Does anybody know of a workaround for this?  Either a way to define my
> service to not require soapAction or a way to 
> get a .NET client to provide the method name in the soapAction header?
> Thanks,
> Rob

View raw message