By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,214 Members | 2,066 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,214 IT Pros & Developers. It's quick & easy.

Axis Web Service, .Net Client - Interop issue with SOAP Header

P: n/a
Hello:

I have a Axis Web Service that sets the sessionid in the SOAP header for
persisting the session. The client is a .Net client that processes the header
as an Unknown Header. It sets the session id received from the Service
request on subsequent requests to the service. However the Axis Web service
does not process the SOAP header received from the .Net client and creates a
new session id for each request from the .Net client. Below are the SOAP
header captured from request and responses using tcpmon:
Axis Response: SOAP header sent by server
<soapenv:Header>
<ns1:sessionID soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next"
soapenv:mustUnderstand="0"
xmlns:ns1="http://xml.apache.org/axis/session">884521262653014708</ns1:sessionID>
</soapenv:Header>

SOAP Header sent by .Net client:
<soap:Header><ns1:sessionID
soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next"
soapenv:mustUnderstand="0" xmlns:ns1="http://xml.apache.org/axis/session"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">884521262653014708</ns1:sessionID></soap:Header>

If you examine these headers closely, these are not exactly the same. The
..Net client is adding a namespace "soapenv". I believe this is the reason the
Axis service is not able to understand the header. How can I modify the
client to use the "soap" namesapce instead of defining a new "soapenv"
namespace?

When I test the service using an axis client, the header from the client is
exactly the same as the header sent by the server and the server is able to
process the header and maintain the session.

Any help is much appreciated.

Thanks.

--
VT
Mar 20 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
That won't matter... think of the soapenv and soap as being the
variable names-- they can be elephant or donkey if you declare it.

However... the VALUE of these "variables" are different. That would be
a problem. I'm not seeing the soap namespace being declared in the
first. soapenv is being declared in the second...

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

You can read that basically as... the variable soapend has the value of
http://schemas.xmlsoap.org/soap/envelope/... though it's a namespace,
not a variable (two mixed concepts).

Mar 22 '06 #2

P: n/a
You are right, these are "variable" names.

My problem was in the deployment of the service. Thanks for the explanation.
--
VT
"ag******@gmail.com" wrote:
That won't matter... think of the soapenv and soap as being the
variable names-- they can be elephant or donkey if you declare it.

However... the VALUE of these "variables" are different. That would be
a problem. I'm not seeing the soap namespace being declared in the
first. soapenv is being declared in the second...

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

You can read that basically as... the variable soapend has the value of
http://schemas.xmlsoap.org/soap/envelope/... though it's a namespace,
not a variable (two mixed concepts).

Mar 22 '06 #3

P: n/a
Hello,

i'm desperately searching for an example of a .net-client sending custom
elements via the soap header as unknown soap headers. Would you please
be so kind to post yours?

thanks in advance,
Thomas

*** Sent via Developersdex http://www.developersdex.com ***
Mar 27 '06 #4

P: n/a
q
What is the end result you are looking for?

Mar 28 '06 #5

P: n/a
i'm looking for sample code of a .net client sending a request with
unkown soap headers (not defined in the webservice's wsdl).

The first posting of this thread indicated that it is possible, as i
think.

with best regards,
Thomas

*** Sent via Developersdex http://www.developersdex.com ***
Mar 28 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.