views:

276

answers:

4

Is there a tool to see the message sent to webservice hosted on an IIS server? I have a webservice written in .Net and our ColdFusion people are having trouble building a "complex" parameter. This problem is described from a ColdFusion perspective at:

adobe forum question

It runs when called from a .net client. While hosted on a server inside our LAN, I put it out on a public server so the WSDL could be viewed: please take a quick look at this WSDL here

When the CF developer runs her code, she gets:

java.lang.IllegalArgumentException: argument type mismatch

...and I am wondering if there is a tool I could run on the server that hosts my webservice to see if it is even entering the WS or is being rejected by Java code that CF uses and is not really even getting to my webservice.

A: 

If you were running WCF, you could just turn on tracing. As it stands, there's nothing trivial to do.

John Saunders
Thanks. I am only running ASMX because my webservice has to call a vendor's ASMX webservice that requires WSE 3.0. I am pretty sure whatever Java proxies are used for ColdFusion somehow see a mismatch and my webservice code is never even hit.
John Galt
WCF is compatible with almost everything that WSE can do. One of the few exceptions is that DIME is not supported. For anything else, WCF should "just work". And I hope your vendor understands the status of WSE. "Obsolete" is a polite term for it.
John Saunders
A: 

I notice in the post on the Adobe Forums that you have a couple of lines for authentication:

ws = CreateObject("webservice",  "http://64.8.203.115/fileservice.asmx");
ws.setUsername("ourdomain\someuser");
ws.setPassword("password");

Are you able to try without authentication?

Additionally, are you able to try with CF8 or the CF9 beta? There may have been AXIS upgrades that could assist.

I'd also point you to this blog post in case you haven't seen it yet: Passing an Array to a .NET Webservice - Mark Kruger is an absolute CF guru

Antony
Bless you for answering like you have and looking into the post I made on Adobe's forum. I studied the Kruger post and have passed to our ColdFusion developer. We are now hopeful. Regarding your other questions: We cannot try without authentication (it is required); also, we cannot try with CF8 or 9 because our government client is locked onto (i.e. stuck) on CF7.
John Galt
Hi John - I suggest trying cf8 or 9 as a troubleshooting step - maybe you'll get a different error, or more details. Good luck
Antony
A: 

I wasn't able to look at the WSDL (and I realize this question is months old now), but I will say that I've had similar problems using Coldfusion to consume .net webservices which use complex object parameters. I assume that the problem stems from incompatibilities between the way .net and Axis serialize objects.

One thing I've occasionally done to solve problems like this is used to consume the webservice and construct the request by hand, rather than using the CreateObject("webservice") feature. Obviously this is sub-optimal but it has occasionally been helpful.

I'm curious whether you were able to solve the problem and how.

davidcl
A: 

I know this is an older question, but I've dealt with a lot of these issues in the past, so I'm posting this in case anyone is still looking for help.

There are 2 great tools included in CF to help you figure out what's not working when developing against web services. They're both in \ColdFusionXXX\runtime\bin.

First is "wsdl2java". It takes in a wsdl and auto-generates the equvalent java classes. You can open up the source it generates to get a better idea of the structure the web service expects. Usually the java object structure can pretty much be converted 1-to-1 to CF code.

The second tool is "sniffer". Sniffer allows you to set up a local proxy. So you can set up the proxy to listen to a local IP and port, and forward to the server that hosts the web service. Then you just call the webservice using the local IP and port instead of the remote one. The request and response can be viewed in sniffer.

Roland C.