By Greg McGuffey - 6/29/2007
I working with a web service for the first time and I'm having trouble getting it to work. The web service was built by someone else, in java and the server is remote and I don't have access to the source to try to have it local.
I really need to see what the raw soap message being sent to the web service is. However, I can't figure out how to do this. Any ideas on how to do this?
Any other tricks/tips on building clients for web services would be appreciated (including how SF could be leveraged) would be appreciated.
Thanks!
|
By StrataFrame Team - 7/2/2007
If you need to see the raw SOAP message, then you're best bet would be to create a quick little program that will read it and dump it to a file on disk. Something like this:Private Sub GetAndSaveResponse()
Dim request As HttpWebRequest = DirectCast(WebRequest.Create("some url to the web service"), HttpWebRequest)
Dim response As HttpWebResponse = DirectCast(request.GetResponse(), HttpWebResponse)
Dim input As Stream = response.GetResponseStream()
Dim buffer As Byte(response.ContentLength - 1)
input.Read(buffer, 0, response.ContentLength)
File.WriteAllBytes("C:\output.txt", buffer)
End Sub You'll of course, need to import System.IO and System.Net and I think that's all... It's pretty quick and dirty, but it should get you a start 
|
By StrataFrame Team - 7/2/2007
For some reason I remember that in VB, you can only put the dimensions on an array declaration on the variable name or the type... don't remember which one off hand, so the:Dim buffer As Byte(response.ContentLength - 1) might need to be: Dim buffer(response.ContentLength - 1) As Byte
|
By Greg McGuffey - 7/2/2007
Thanks for the reply Ben.
Will this work with a proxy class? I.e. I'm using a proxy class to call the web service and I'd like to know what the SOAP message the proxy is generating is (because the darned thing ain't workin). The web service is somebody else's and is a java web service.
Thanks again!
|
By StrataFrame Team - 7/3/2007
Yes, when you create the HttpWebRequest object, you can set any of the properties you need before you make the call to GetResponse(), which is what actually sends the request and gets the response. One of the properties you can set before sending the request is the Proxy property which accepts a System.Net.IProxy object... don't worry, though, there's already an implementation of that interface in the System.Net.WebProxy class. Just create a new WebProxy object, give it the address, port, username, password, etc. for the proxy and set that object to the Proxy property on your HttpWebRequest object. Now, if you want to see what the proxy is passing on to the web service, you'll have to set up a packet sniffer between the proxy and the web server, which could prove to be difficult.
|
By Greg McGuffey - 7/3/2007
Thanks Ben! I'll need to chew on this for a bit, but it is heading me in the correct direction I'm sure.
|
By Greg McGuffey - 7/9/2007
Well, I've chewed and I'm choking... 
Let me get this straight. I have a proxy class that will end up generating a soap message (which is just a plain text, xml string) and the only way I can see what is being generated is by setting up a proxy class and using a bloody port sniffer? They couldn't just have an option to show the bloody message? #@#%^#@
Somebody at MS needs to be shot!
OK, enough of the rant. Is this really the only way to see what is being sent? (I realize this might be easy to you, but I know next to nothing about port sniffers and proxies...so I'm looking at another bloody steep hill to climb...sigh...starting to rant again). I'm getting a bad header and need to know what I'm doing wrong.
Thanks!
|
By Trent L. Taylor - 7/9/2007
Is this really the only way to see what is being sent? LOL....I understand. Really if you want to get a true view of what is going on, then the port sniffer is the best way to go. We have learned all sorts of junk through the port sniffers 
|
By Greg McGuffey - 7/9/2007
Sigh....OK, I'll bite the bullet and learn to sniff...
|
By Greg McGuffey - 7/12/2007
I so totally don't get this, at almost every level 
I d/l a tool called tcpTrace. It was recommened for just this sort of thing. See this article, the second tip.
http://www.ondotnet.com/pub/a/dotnet/2002/10/07/webservices.html
What I don't get is how to setup the proxy class, and/or tcpTrace to actually view the requests/responses.
I tried by setting the destination to my remote URL (the one with the web service), port 80 and the local to 'localhost', port 8080.
I then tried to setup the proxy on 'localhost:8080'. Finally, I called my web service, replacing the remote IP with 'localhost:8080'. The proxy was on the web service proxy class.
So, question:
- what the heck does the WebProxy class do?
- what IP/host name would you set the proxy to to get the port listener to actually listen?
- how do I test if I have thing setup correctly, like with a web browser?
Any info would be really helpful. I'm starting to loose my mind...
|
By StrataFrame Team - 7/13/2007
Hehe, let's start with a quick word about proxies Basically a proxy is a rerouter of sorts. You need to send a request to HostA, but your network security or the layout of the network will not let you reach HostA directly, so, you have to route your web request through a computer that can reach HostA. So, you have HostB which is a server that can reach HostA and you configure a proxy server on it. The proxy server is a separate piece of software, like Microsoft ISA or something and allows hosts to reroute their requests through it. On your computer, since you know you cannot reach HostA, you create a web request with HostA as your target address and configure that request to use a proxy server of HostB. So, when you think you're sending your request to HostA, your computer actually forwards it to HostB with a message asking HostB to forward it on to HostA. HostA receives the request from HostB (and doesnt' know it was sent from your computer) and responds to HostB. HostB receives the response and sends it back to your computer. So, while your web request thinks it was talking to HostA, it was actually talking to HostB the whole time because your request was proxied.OK, so, there are a couple of places where this could go wrong. First, when you send a request, it might be improperly formatted when you send it from your computer (when it's sent to HostB). Now, .NET doesn't have a way for you to see the raw bytes that are hitting the network stream because, quite frankly, they've unit tested the heck out of it and they know it's going to format the request properly, so why allow you to see it? So, if the request is leaving your computer properly, then it could be that the proxy server (HostB) is receiving your request and when it wraps the request it's corrupting it before it sends it to HostA. This option is highly unlikely if you're using a viable commercial proxy solution like some Linux distro with a good proxy server or Microsoft ISA or something. Once again, they've probably unit tested the heck out of it. The other option is that the HostA is just not processing the request properly. It might be reaching it fine, but throwing up when it tries to process it. Now, debugging this is quite a chore, because as a developer, you probably don't have access to HostA or HostB, you just have access to your computer. If you're wondering whether the request is leaving your computer properly, then you can configure your sniffer to capture all traffic on your network card and when you've sent the request, stop the capture and examine the packets. You'll be able to get the raw data that was sent from your computer to HostB (most sniffers have a filter that allows you to filter the traffic by destination address... in thic case HostB). Once you've determined that you're sending the correct request, you'll want to test whether the proxy is sending the request properly. Now this one will cause some heartache. Mainly because you want to see the proxied request, meaning you have to set up your computer as the final destination of the request... through the proxy. Since you're not in control of the proxy and you can't just put the packet sniffer on it, you'll have to have 2 computers at your location. One to send the request, and one to receive the request (I don't think you can use the same computer for both because the OS will realize that the source and destination are the same and will send the traffic across the network stack before ever reaching the actual ethernet... but with a proxy this might not be the case... not sure). So, you'll want to change your HostA target for the request to the other computer and send the request and when the request is received by your second computer, sniff the packets. Now, when I say sniff the packets, you're going to get the raw bytes of the request. Including the HTTP/1.1 GET - Content-Length: mime-type: headers and everything. So, I'm not sure what's garbling the request, but maybe that gives you a little more insight into figuring it out
|
|