Microsoft SOAP Trace Tool

ToolKit

Languages: C#

ASP.NET Versions: 1.0 | 1.1

Microsoft SOAP Trace Tool

Easily inspect your ASP.NET Web service's raw SOAPmessages.

By Ken McNamee

The .NET Framework greatly simplifies the creation andconsumption of SOAP messages in a distributed computing environment. VisualStudio .NET goes even further in facilitating this process by quicklygenerating the proxy classes for the remote methods, so the developer doesn'teven need to know that he or she is invoking code executing on an entirely differentmachine. However, although all of this abstraction is great for mostdevelopers, there are still occasions where you need to have more control overthe SOAP requests and responses that are being passed across the wire duringthis communication.

It might come as a surprise to some developers withoutextensive Web services experience that the .NET Framework allows very finecontrol over almost every aspect of the SOAP creation and consumption process.The first step in assuming this control is to know exactly what your SOAP lookslike. That's where the Microsoft SOAP Trace Tool (MSSOAPT) comes into play. Youaren't going to find this tool or its equivalent in the .NET Framework SDK orany version of Visual Studio .NET - which I found a little surprising. You'llhave to download and install the Microsoft SOAP Toolkit, which is a holdoverfrom the early days when COM components were used to create and consume Webservices with tools such as Visual Basic 6.0. You can download the Toolkit fromhttp://msdn.microsoft.com/downloads/list/websrv.asp.

Start the Trace

You can start MSSOAPT by clicking the "Trace Utility" itemin your Windows Start menu after you've downloaded and installed the SOAPToolkit. Under the File menu, start a new Formatted Trace. You should bepresented with the Trace Setup dialog box, as displayed in Figure 1. If you areworking local and using port 80 for the local Web site that contains the Webservice, you probably won't need to change any of these values. Once you clickOK, MSSOAPT will start listening for any network traffic on the port that youspecified. It's worth mentioning at this point that this tool is not limited tolistening for SOAP-based traffic. Any bytes that are sent to the port that it'slistening on will be displayed - whether they are human-readable or not.

Figure 1. The Trace Setup dialog boxallows you to customize the port that the Trace Tool should listen on and thehost name and port to which it should forward SOAP requests.

One of the few drawbacks to this tracing tool is thenecessity to temporarily modify your Web service proxy class so that it pointsto the proxy port. However, this is only a minor inconvenience. A moresignificant inconvenience in my opinion is the lack of a real logging feature,but there is a work-around to this as MSSOAPT stores all of the information itgenerates in your logged-in user's temporary folder. Simply root around in thatfolder for the newly created files after each Web service call. It's not anideal solution but - as my former boss used to say about my code - it's betterthan nothing.

Each request you make to the trace port will generate anentry in the tool's treeview menu on the left. As shown in Figure 2, clickingon the message in the treeview will display the SOAP request in the upper-rightpane and the SOAP response in the lower-right pane. These panes are actuallyembedded HTML controls so you can right-click and choose View Source to saveoff the messages as a logging alternative to finding the right document in yourtemporary folder.

Figure 2. One-click access to theactual SOAP messages that were transferred during the Web service conversationcan be a real timesaver during the debugging process.

As seen in Figure 3, another useful feature is theHTTPHeaders item in the treeview. A misconfigured in therequest headers is a common source of cross-platform Web services problems. Youmight also take note of the and headers as points of weakness when problems arise.

Figure 3. The HTTPHeaders are acommon source for problems in cross-platform Web service calls.

Build It Yourself

I'm one of those people who always looks at software andthinks, "I bet I could recreate that!" Then after I spend eight hours on theproject I finally decide that - while I could finish it if I wanted to - itwould be more cost effective to just buy the software. However, a SOAP tracingtool is actually very easy to create yourself. The simplest SOAP inspectionmethod is to log requests and responses to a file by using a SoapExtension,which is a .NET Framework class that allows you to extend the built-in Webservices architecture. If you go to the overview page for the SoapExtensionclass in the MSDN Library documentation you'll even find the code you need toaccomplish this task: a custom class called TraceExtension. Understanding howthis class works is also a useful exercise in understanding what goes on underthe hood of every Web service call.

You might be thinking that you've never really had anyproblems arise concerning the format of SOAP messages and therefore don't see aneed to use a tracing tool. Consider yourself lucky. SOAP formatting issues aremost likely to pop up when you or another company try to consume a .NET Webservice from another Web services platform. For example, I was recently askedto create a proof of concept regarding a .NET Web service that had to allowconsumption from ASP.NET, classic ASP, PHP, Java, Perl, Cold Fusion, andPython. Needless to say, this was a very frustrating - yet instructive -development exercise.

Even though SOAP Web services promise greater ease withregard to cross-platform interoperation, there are still many challenges thatmust be overcome. SOAP tracing is one technique you should take advantage of tohelp facilitate your Web services development.

Resources

SOAP Toolkit: http://msdn.microsoft.com/downloads/list/websrv.asp

ProxyTrace: http://www.pocketsoap.com/tcptrace/pt.aspx

TraceExtension: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwebservicesprotocolssoapextensionclasstopic.asp

The sample code in thisarticle is available for download.

Ken McNamee is an independent consultant who works withcompanies in need of highly scalable data-driven Web applications. And whodoesn't need one of those these days? Prior to this, he led a team ofdevelopers in re-architecting the Home Shopping Network's e-commerce site,HSN.com, to 100% ASP.NET with C#. Readers can contact him at [email protected].