views:

1488

answers:

2

Currently we have a java webservice that we are trying to connect to via a .NET client. This is all done over SSL. Are there any well known gotchas as this seems to be a problem that has come up again and again. What are the most well known gotchas I should be looking for?

The java web service is a SOAP/WSDL. There are no WS-* extensions like WS-Security.

Ok, here is the exact problem I am looking to solve: We were given a java webservice to call from a C# client. I've tracked the problem down to the fact that the java webservice is expecting some modified xml that the C# client is not producing. The java webservice is expecting something along these lines:

<?xml version="1.0" encoding="UTF-8" ?> <iAttr:MyObject1 xmlns="iAttr" xmlns:iAttr="http://www.foo.com/WS"> <iAttr:MyObject2 xmlns="isum" xmlns:isum="http://www.foo.com/WS"> <iAttr:OrderId>1001027892 </isum:OrderId>

The problem is, that the xml/SOAP stuff that my client is generating is like this:

<?xml version="1.0" encoding="UTF-8" ?> <iAttr:MyObject1 xmlns="iAttr" xmlns:iAttr="http://www.foo.com/WS"> <MyObject2> <OrderId>1001027892</OrderId>

note: the lack of "iAttr" in the C# version.

Question: How do I add the attributes problematically in C# to match what the java WS is expecting?

A: 

Well, if you wrote your service the "right" way, then there shouldn't be any problems, at least not problems of language interop.

Charles Graham
How likely is it that he chose to write the service and the client, but chose different languages for each? Slightly less likely than he is writing the client and has no control over the server I would venture. In that context it seems a touch harsh to criticise him for the way the service was written.
Modan
+1  A: 

I didn't write the service. Here is the weird thing: a java client making the same webservice call works perfectly. However a .NET client making the exact same webservice call breaks.

eviljack
Ergo, the requests are different.
Alexander