13.8 Using a TCP Trace Utility

Have you wondered how you can view the HTTP headers going back and forth between Flash Remoting and your client movie? Or how you can view the AMF data that Flash Remoting uses to communicate? Or how to see the SOAP packets that are going back and forth from Flash Remoting to a web service? A TCP trace utility can be a good debugging tool when you are building applications that access web services or when you are having problems with client/server communication.

Basically, a TCP trace tool listens to a port and outputs any activity to a window so that you can examine it or save it to a file. For example, if you are sending a request to a web service and receiving a response that is inaccurate, you can examine the SOAP packet directly using a TCP trace utility.

TCP trace utilities can be used on the client and on the server. If your local machine is acting as client and server during debugging, you can open up two different sessions in the TCP trace utility and examine the requests and responses to HTTP requests .

We examine some of the popular TCP trace utilities in the following sections.

13.8.1 SOAP Trace Utility

Microsoft offers a SOAP toolkit that contains a trace utility called MSSOAPT.exe . You can find it at:

http://msdn.microsoft.com/downloads

Its usefulness as a tool does not stop with SOAP, however. It can also be used to examine your AMF headers to and from the Flash Remoting gateway, or any other HTTP packets.

There are other utilities that work in a similar fashion, like the TCPTunnel utility that comes with the Apache SOAP Java package (http://xml.apache.org/soap), but the Microsoft tool is easy to set up and use. If you are on a Macintosh, you might consider using the TCPTunnel utility in place of the MSSoapT tool.

The TCP trace tool must be able to intercept the HTTP call and then pass the call on to its final destination. To use it, set up a dummy port number, such as 81, and then pass the request to 81 rather than the actual destination. The trace utility then intercepts the call and outputs the text and/or binary code to the screen.

13.8.2 Testing Client Calls

To use MSSoapT to test the client-side code of a Flash Remoting application, set it up on the client machine (from which the movie is played ) and run it. You will have to create a new Trace session using MSSoapT's File New command. The Unformatted Trace is a better option to see the exact content that is being passed from the client to the server and back again. After choosing Formatted Trace or Unformatted Trace from the File menu, you'll have to set up the ports and the host address where the trace will be referred, as shown in Figure 13-11.

Figure 13-11. The MSSoapT TCP trace utility requires the port and host to be set up

The "Local port #" should be set to a free port on the local machine. This allows the TCP trace utility to listen to the port. If the port is in use by another service, the trace utility will not be able to open a session.

The "Destination host" should be set to the IP address of the service that you are tracing. For example, if you want to trace the AMF headers going to the Flash Remoting gateway, put the IP address of the Flash Remoting gateway here.

The "Destination port" should be set to the port number of the service you are tracing. To test a Flash Remoting call to a server, this is the port number of the Flash Remoting gateway.

The last step is to set the IP address in your Flash movie for the Flash Remoting gateway to the IP address of the client machine.

For a typical example, let's say that the Flash Remoting gateway is at http://192.168.0.15:8500/flashservices/gateway . The local machine has a different IP address; in other words, you are building a Flash application on a machine other than the server you are calling. The local port number for the trace session could be set to 8080, assuming that port is not in use by something else. Any arbitrary port number will do (81, 82, etc). The destination host would be set to 192.168.0.15. The destination port would be set to 8500.

The Flash movie should be modified so that the Flash Remoting gateway URL is now http://127.0.0.1/flashservices/gateway . (This URL does not exist on the local machine but will force the Flash Remoting call to go through the TCP trace utility.) If you run the movie, the trace utility should display the call to the service and the result as well. You'll see the AMF headers and any other information that was passed in the HTTP call, as shown in Figure 13-12.

Figure 13-12. The MSSoapT utility displaying information from a Flash Remoting call

13.8.3 Tracing a Web Service

Web services can also be traced, and the MSSoapT trace utility will show you the SOAP headers going back and forth from client to server. In the case of web services, the client is the Flash Remoting adapter on the server. In other words, the client for the web service resides on the application server machine. For this reason, the tracing needs to take place entirely on the server.

Tracing a web service generally requires you to modify the .wsdl file so that the URL points to your trace utility rather than the service. The technique is the same: you point your URL in the trace utility (the destination host) to the actual web service URL and set your port numbers accordingly . If the .wsdl file resides at a remote location, download the file to the server machine and save it in the web directory. Change the <wsdlsoap:address> tag so that the IP address and port number match your local machine and the port of the trace utility.

To demonstrate , we'll do a simple trace on the web service at:

http://www.communitymx.com/services/cmxfeed.wsdl

Assuming that you have the MSSoapT utility running on the same machine as your Flash Remoting adapter, the first step is to download the .wsdl file and save it to your local web root. Save the file as cmxfeed.wsdl .

Next, find the <wsdlsoap:address> tag in the file. Copy the address, because you'll need it in the trace utility. Change the IP address to your local .wsdl file (probably at http://localhost:86/cmxfeed.wsdl ). The tag should now read like this:

 <wsdlsoap:address location="http://localhost:86/services/cmxfeed.cfc" /> 

Notice that the path stays the same; only the IP address and port number change. Save the file.

Open the communitymx.fla file from Chapter 10. You will need to change the service path so that it matches the location of your new .wsdl file. Change the service path from:

 var servicePath = "http://www.communitymx.com/services/cmxfeed.wsdl"; 

to:

 var servicePath = "http://localhost:86/cmxfeed.wsdl"; 

Open up a new trace session and set the ports and host as follows :

Local port #: 86

Destination host: www.communitymx.com

Destination port: 80

Run the Flash movie, and you should see the SOAP packets on the server in the MSSoapT window, which will look very similar to the display shown in Figure 13-12.

This can be handy when building Flash interfaces to web services, because the Flash debuggers may not give you any indication of what might be going wrong with the call to the SOAP web service. The MSSoapT trace utility will show you the SOAP packets so that you can compare the results to the .wsdl file code and decide on a course of action.