Introduction

Sometimes your WebApp just doesn't behave as it should. Sometimes your WebService client throws strange errors and you not sure why. It's at times like these that I reach for a little known tool called TCPMonitor which can show you the actual conversation going on between client and server.

Here I show you how to get it, how to set it up and just what it's capable of.

Getting TCPMonitor

TCPMonitor is a utility shipped as part of the Apache Axis project and therefore you need to get a copy of that projects distribution. Apache Axis can be downloaded from http://ws.apache.org/axis/releases.html. It doesn't matter which version you download, I still use the version from 1.0 and it works fine.

Once you have the distributions ZIP file you need to extract it into a directory. From now on <AXIS_HOME> will refer to this installation directory

Starting TCPMon

TCPMon is included in <AXIS_HOME>/lib/axis.jar. In order to run it, use the command:

java -classpath <AXIS_HOME>/lib/axis.jar org.apache.axis.utils.tcpmon

When it's running you'll see a screen like this:

TCPMonitor Modes

TCPMonitor can run in two modes:

As a listener
In this mode you specify a local listening port as well as a remote host and port. Any information received on the listening port is display in TCPMonitor and forwarded on to the remote host and vice versa. The target host has no idea that TCPMonitor was involved in the conversation.

As a Proxy Server
In this mode TCPMonitor acts as a traditional HTTP Proxy server, the difference being that it displays all information in the conversation that passes through it.

Starting a Listener

The following steps show how to start TCPMonitor in Listener mode:

• Enter a Listen Port, for example 8080
• Click on the Listener radio button
• Enter a target hostname, for example www.macromedia.com
• Enter a target port, for example 80
• Click Add

Once you click add, you'll see the new listener appear as a tab:

Using a Listener

To test the Listener all you need to do is specify http://localhost:8080 in your browser. The browser will connect to the listener and the listener will connect to Macromedia. If you click on the listeners tab in TCPMonitor you'll be able to see a summary of the HTTP conversation taking place, as well as the actual contents of the requests and response packets.

In the image below you can see all the headers and responses from the Macromedia conversation.

Debugging WebServices

Debugging a standard browser conversation is only one use for this fantastic tool. The main use I have for it (and probably the reason it was written in the first place), is to debug WebService conversations.

In order to debug WebService conversations, you really need to run TCPMonitor in proxy server mode. The reason for this is that the WSDL (WebService Description Language) file, which describes the WebService interface, has the endpoint address defined in it. If you wanted to use the listener mode you'd have to modify the endpoint address before the method invocation, and whilst this can certainly be done with clients such as the Weblogic client, it can get a little messy. Much better to run TCPMonitor in proxy mode.

With TCPMonitor setup in proxy mode on port 8080 you would view the WebService conversation between ColdFusion and a Stock Quote service using:

<cfinvoke webservice="http://ws.cdyne.com/delayedstockquote/delayedstockquote.asmx?wsdl"
          method="GetQuote"
          returnvariable="StockQuote"
          proxyServer="localhost"
          proxyPort="8080">
          
          <cfinvokeargument name="StockSymbol" value="BEAS"/>
          <cfinvokeargument name="LicenseKey" value="0"/>
</cfinvoke> 

The following image shows the SOAP conversation with the StockQuote Service. Notice that I've also ticked the XML Format check box so that TCPMonitor formats the request/response in an easier to read format.

Proxying Weblogic WebService Client Requests

For information on how to proxy WebService calls from WebLogic clients please see the following links:

• Weblogic WebServices : http://e-docs.bea.com/wls/docs81/webserv/client.html#1077879

Conclusion

That's all there is to it really, it's a very simple, easy to use tool, but VERY helpful at locating issues in HTTP Conversations. In BEA Support I've use this tool numerous times to help locate the cause of difficult issues.