Soap - 'soapenv:' versus 'soap:'

colr__ used Ask the Experts™
I've got a .NET web service that I have to connect to using Java. The .NET service specifies the following as an example SOAP call:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="" xmlns:xsd="" xmlns:soap="">
    <EchoString xmlns="">

We are using an API developed by one of our (long gone) developers for connecting to the web service, which makes the following SOAP call. This API definetaly works, as it is used in practice in numerous places, and I can in fact connect to the web service.

<?xml version="1.0" encoding="UTF-8"?>
             <call:EchoString xmlns:call="">

As you can see, they are both the same except for the use of 'soapenv' instead of 'soap'.

Now we have got this working with a helloworld example - the java connects to the helloworld web service and retrieves a text based response. The only problem is that when we try and input a String into another web service, called EchoText, it doesnt seem to get the string, and just returns its response w/o the text I supplied (its supposed to return some text appended to the text I supplied). So, the web service is connecting and getting a response, but the input String is not being recieved (although it is clearly visible in the SOAP request above).

I just wanted to eliminate the use of 'soapenv' instead of 'soap' as the problem (im not all that familiar with SOAP, so I didnt know if this'd make a difference?) as thats the only difference as far as I can see.
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Information Architect
Top Expert 2006
the prefix for the namespace is a random string and of no consequence.
It doesn't matter at all whether that is "soap" or "soapEnv" as long as they are pointing to the same namespace... which they do
(and as long as you don't have a poor webservice set up... it could be that your long gone developer has hardcoded the prefix in the code,
this is uncorrect but I have seen this happening a lot in the past)

I see a possible issue with the namespace of the load
EchoString is NOT in the same namespace in the two examples
one is in the default tempuri namespace, the other is in the namespace
try changin the second example into
<call:EchoString xmlns:call="">
instead of
<call:EchoString xmlns:call="">
and it should work


Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial