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: http://tempuri.org/Add
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.
Thanks,
Rob
From: John Hawkins
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 11, 2005 3:27 AM
To: Apache AXIS C User List
Subject: RE: soapAction and .NET interoperability
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" <[EMAIL PROTECTED]> wrote on 11/05/2005 05:02:58:
> > 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?
>
> 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 mechanism
> - there is a Jira issue raised on this)
>
> Hence I think you have to figure out how to set the SOAPAction with .net
> client. I am not sure how to do this exactly but
> http://msdn.microsoft.com/library/default.asp?url="">> tml/frlrfSystemRuntimeRemotingMetadataSoapMethodAttributeClassSoapAction
> Topic.asp may lead to a clue.
>
> Thanks,
> Samisa...
>
> -----Original Message-----
> From: Yampolsky, Robert [mailto:[EMAIL PROTECTED]
> 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 set
> to "". I can verify that that's the case. With no soapAction, I get a
> "Soap method is not allowed to invoke" exception, but when I put it in,
> 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
