Calling a Java Web Service From C#

B

bjmarte

Our client has a web service that we need to call to return us information about their customers. We pass in state and customer account number and it returns customer information in XML as a string. Their web service is a web service written in Java and expects a soap packet with tags formatted like <soapenv:Envelope>. When I add a web reference in C# by pointing to their WSDL the web service call fails and when I add code to trap the soap packet and write it out to a file I see that the generated C# code is sending a soap packed with tags formatted like <soap:Envelope>. Is there any way to tell the web reference to send the soap in the Java format

Thanks
Bret
(e-mail address removed)
 
J

Jan Tielens

Web services should work the same for Java and .NET...

What server and library are you using on the java side? Is it possible to
post the wsdl?

--
Greetz,
Jan
________________________
Read my weblog: http://weblogs.asp.net/jan

bjmarte said:
Our client has a web service that we need to call to return us information
about their customers. We pass in state and customer account number and it
returns customer information in XML as a string. Their web service is a web
service written in Java and expects a soap packet with tags formatted like
<soapenv:Envelope>. When I add a web reference in C# by pointing to their
WSDL the web service call fails and when I add code to trap the soap packet
and write it out to a file I see that the generated C# code is sending a
 
D

Dino Chiesa [Microsoft]

bjmarte, To answer your original question, There are ways to adjust and
tweak the XML / SOAP that is generated by .NET (C#) clients. These are
attributes, but they are usually generated by the wsdl.exe tool that you use
to generate the client proxy or server skeleton.

You also said, originally, that the java client generates <soapenv:Envelope>
while C# generates <soap:Envelope>. This, in itself is not an indication
that the SOAP is different. soapenv: and soap: are namespace "prefixes"
which are defined in the XML itself. They are each defined to the same
thing, and so are equivalent. Eg:

in the Java side
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
....>

and in the C# side,
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" ... >

So soapenv: and soap: refer to the same namespace. They are the same.

But, there are meaningful differences in the XML generated by the .NET side
and the Java side, though. For one thing, the namespace for the getCustInfo
request is
"http://subdomain2.client.com:8000/GetCustInfo" in the Java side, and is
"https://clientwebsite.com/GetCustInfo" on the .NET side. These are
different and the difference is important. (note, in the Java side this
namespace is associated to prefix ns1 and in .NET it is associated with
prefix q1. The difference in prefix names is not meaningful) I cannot
imagine how your Java client is getting a totally different namespace here.
The WSDL you enclosed does not mention that namespace.

When I try to generate a proxy from the WSDL you sent, first, the WSDL isn't
valid. I guess because of the cleanup you tried to do. If I fix it up a
little, though, I get a valid C# proxy class, and I can also generate a
server skeleton. The client generates the same SOAP your .NET client
generates.

Another significant difference is the Java side obviously has some
additional logic to add in site-specific SOAP Header info. Those extensions
to the SOAP header are not described in the WSDL you enclosed. Not sure if
they are important, though, since it is app-specific. Could be the app
tolerates the omission of such header info.

-Dino

bjmarte said:
It isn't working the same for me.

WSDL (modified for client privacy):
<?xml version="1.0" encoding="UTF-8" ?><wsdl:definitions targetNamespace="https://clientwebsite.com/GetCustInfo"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:intf="https://clientwebsite.com/GetCustInfo"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><wsdl:message
name="getCustInfoRequest"><wsdl:part name="in0" type="xsd:string"
/><wsdl:part name="in1" type="xsd:string" /></wsdl:message><wsdl:message
name="getCustInfoResponse"><wsdl:part name="getCSRReturn" type="xsd:string"
/></wsdl:message><wsdl:portType name="CustomerInfoManager"><wsdl:eek:peration
name="getCustInfo" parameterOrder="in0 in1"><wsdl:input
message="intf:getCustInfoRequest" name="getCustInfoRequest" /><wsdl:eek:utput
message="intf:getCustInfoResponse" name="getCustInfoResponse"
/></wsdl:eek:peration></wsdl:portType><wsdl:binding
name="GetCustInfoSoapBinding" type="intf:CustInfoManager"><wsdlsoap:binding
style="rpc" transport="http://schemas.xmlsoap.org/soap/http"
/><wsdl:eek:peration name="getCustInfo"><wsdlsoap:eek:peration soapAction=""
/><wsdl:input name="getCustInfoRequest"><wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="https://clientwebsite.com/getCustInfo" use="encoded"
/></wsdl:input><wsdl:eek:utput name="getCustInfoResponse"><wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="https://clientwebsite.com/getCustInfo" use="encoded"
/></wsdl:eek:utput></wsdl:eek:peration></wsdl:binding><wsdl:service
name="CustInfoManagerService"><wsdl:port
binding="intf:GetCustInfoSoapBinding" name="GetCustInfo"><wsdlsoap:address
location="https://clientwebsite.com/GetClientInfo"
/> said:
Soap Expected by the Web Service:
<?xml version="1.0" encoding="UTF-8" ?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Header><x:app
id soapenv:actor="" soapenv:mustUnderstand="0"
xmlns:x="http://subdomain.clientwebsite.com">MyCompanyCustInfo</x:appid><i:s
ubdomain soapenv:actor="" soapenv:mustUnderstand="0"
xmlns:i="http://subdomain.clientwebsite.com"/><v:Version soapenv:actor=""
soapenv:mustUnderstand="0"
xmlns:v="http://subdomain.clientwebsite.com">1</v:Version><call:callcontrol
soapenv:actor="" soapenv:mustUnderstand="0"
xmlns:call="http://subdomain.clientwebsite.com"><call:calltype>synchronous</
call:calltype><call:transactionid></call:transactionid></call:callcontrol></
soapenv:Header><soapenv:Body><ns1:getCSR
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="http://subdomain2.client.com:8000/GetCustInfo"><in0
xsi:type="xsd:string"></in0><in1
xsi:type="xsd:string">111111111 said:
Soap actually being sent by C#:
<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="https://clientwebsite.com/GetCustInfo"
xmlns:types="https://clientwebsite.com/GetCustInfo/encodedTypes"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><q1:getCustIn
fo xmlns:q1="https://clientwebsite.com/GetCustInfo"><in0
xsi:type="xsd:string" /><in1
xsi:type="xsd:string">111111111</in1></q1:getCustInfo></soap:Body></soap:Env
elope>
 
D

Dino Chiesa [Microsoft]

What I am saying is that the "SOAP expected by the webservice" you gave us
is not consistent with the WSDL you provided.
The C# proxy generates the proper XML for the WSDL you provided. In other
words, given the WSDL you provided, the "SOAP actually being sent by C#"
looks correct.

Is it possible that the WSDL is not the actual used by the service, or is
not the WSDL used to generate the Java client proxy?

This could happen if:
- the WSDL and server-side Java implementation were independently
constructed (eg, one was not generated from the other)
- the WSDL was generated from the server-side Java implementation, but the
tool used to generate the WSDL is broken
- the server-side Java implementation was generated from the WSDL you
provided, but the tool is broken.
- the WSDL was somehow modified from what the server-side Java
implementation uses. A synchronization problem.
- maybe some other way, too.

------------

As I said, the soap vs soapenv is not important. It is a xml namespace
prefix, and the Java and C# soap envelopes are equivalent. They both refer
to "http://schemas.xmlsoap.org/soap/envelope/", which is what you want. The
C# client could use <HomerSimpson:envelope>, and if HomerSimpson was mapped
to "http://schemas.xmlsoap.org/soap/envelope/", then it would still be fine.
So soap-vs-soapenv is not your problem.

Your problem is that there is a namespace that disagrees. The C# client is
using a namespace of
"https://clientwebsite.com/GetCustInfo" , which is the namespace mentioned
in the WSDL document. The Java client uses a namespace of
"http://subdomain2.client.com:8000/GetCustInfo" , which is nowhere in the
wSDL document.
These two namespaces are not equivalent.

You need to understand why they are different. The C# client is using the
namespace in the WSDL provided. So if the WSDL is correct, the C# client
(and the "SOAP actually being sent by C#") is correct.

If the Java client works, then it is talking to a web services that does not
match the WSDL you provided.

-Dino



bjmarte said:
Thanks for the info Dino. It sounds like you are saying the WSDL provided
by the client doesn't describe the web service enough for C# to generate a
proxy that generates the XML correctly.
Do you know what the attributes are that will cause the soap to be
generated in the <soapenv:Envelope> style. If I knew that I could add the
attribute manually and I think I could figure out how to tweak the rest on
my own.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,969
Messages
2,570,161
Members
46,710
Latest member
bernietqt

Latest Threads

Top