0

Here is the situation. I have received a WSDL (and included XSD) from someone that is generated by an Apache/Tomcat server (Java). The company i do a project for, prefers .NET so i used wsdl.exe to generate a partial class and created the webservice.

Then I created a .NET client (in this case I am using VB.NET) that has a web reference to the java wsdl. This works fine. Then I change the url using code and make it point to my newly created .NET service but i cannot seem to get it to work. Doing it the other way round, also doesnt seem to work.

Been fiddling a bit with the namespaces and the service name but can't seem to crack it. Keeps giving me an error about HTTP header unable to find . as a method. This indicates a transport problem.

I really do not want to revert to plan B, being the creation of a Java Webservice and then linking this to the .NET environment. I know this will work since you will never have to change the urls.

Any suggestions ?

ZorbaSan
  • 3
  • 2
  • Please do some more research (or ask some questions to 'someone'). Tomcat cannot generate any wsdl files. Frameworks like axis, axis2, cfengine, metro . . . do that. What is the soap version used (1.1 or 1.2)? Which encoding is used (rpc/encoded, document/literal . . .)? Last but not least: Be more specific when it comes to 'errors'. People here don't like making random guesses that much . . . – MartinK Jun 19 '12 at 12:38
  • The question is pretty specific: is it possible to have 1 client stubs linked to a java generated (probably axis2) AND a .NET (C# version 2 or higher) without re-generating the stibs but by simply changing the url. It does not matter what soap version is being used since .NET client supports both you mention. I am interested in the fact if there might be any issues regarding the name for the asmx file or namespace or operation name. – ZorbaSan Jun 19 '12 at 12:53
  • The exact error you get when connecting to the .net web service: System.Web.Services.Protocols.SoapException: Server did not recognize the value of HTTP Header SOAPAction: . at System.Web.Services.Protocols.Soap11ServerProtocolHelper.RouteRequest() at System.Web.Services.Protocols.SoapServerProtocol.RouteRequest(SoapServerMessage message) at System.Web.Services.Protocols.SoapServerProtocol.Initialize() at System.Web.Services.Protocols.ServerProtocol.SetContext(Type type, HttpContext context, HttpRequest request, HttpResponse response) at System.Web.Se...... – ZorbaSan Jun 19 '12 at 12:57
  • I've had a problem with JAX-WS and soap action header - is it JAX-WS you're using to make the call? – davidfrancis Jun 19 '12 at 13:27
  • no, i am using a .NET client. The java server (I checked) is JAX_WS. – ZorbaSan Jun 19 '12 at 13:30

2 Answers2

1

So to summarise you have:
SERVER SIDE: java, WSDL: java generated
.NET client -> java server - WORKS .NET client -> .NET server -> FAILS

If thats the case this has not much to do with Java!
But I do know as I aluded to earlier that .NET servers are fussy about the soap action header.
Is there a soapAction in your WSDL?
If so, you need to send that value, but I don't know how to do this in .NET (Google would be your friend here).
If not, check out the comments in this question for how to determine the required soap action header value: stackoverflow.com/questions/2262781/soap-action-wsdl

davidfrancis
  • 3,734
  • 2
  • 24
  • 21
  • thanks. Your answer gave me a different angle in searching. Not the answer but very helpfull. Would like to give you some credits - if only for answering normally as opposed to others - but no clue on how to go about accepting the answer. – ZorbaSan Jun 28 '12 at 14:21
  • No problems, thanks also. Well done for finding the solution, looks like a quirk of .NET? – davidfrancis Jun 29 '12 at 12:01
0

After a bit of searching through the devine knowledge base (Google), i have managed to get this fixed.

In addition to being very carefull in specifying the portnames (the default ones are not always what is requested so you need to override it) but most importantly, i found that adding

as part of the asm class header solved my problem. Now all I need to do is find out why?

But trust me, it works...

I found the solution here

ZorbaSan
  • 3
  • 2