ToolKit
LANGUAGES: ALL
ASP.NET VERSIONS: ALL
WSE Tracing Tools
Debug Your WSE-enabled Web Services Using Two Convenient Methods
By Ken McNamee
Web services are becoming increasingly utilized as the de facto standard for inter-Web site, inter-server, and inter-business communication. At my day job I rarely come across a project these days that doesn t use Web services to some degree. To get the most out of these Web services, I always use Microsoft s add-on for the .NET Framework: Web Services Enhancements (WSE). Now at version 2.0, WSE provides developers with ever-increasing functionality and the ability to expose complex, yet secure and reliable, Web services that adhere to the most up-to-date cross-platform standards like WS-Security, WS-Policy, and many others.
However, the problem with Web services is that they can be a little difficult to debug. One of the best debugging methods currently in use is to trace the SOAP request and SOAP response to see exactly what data is getting passed across the wire. A little more than a year ago, I introduced you to the Microsoft SOAP Trace Tool in the SOAP Toolkit. Although that tool can still be used with WSE-enabled Web services, it is not really optimized for it and has definitely become dated. So in this article I m going to introduce you to a couple of new, free tools that perform WSE tracing in very different ways.
Simon Guest s WSE 2.0 Trace Tool
The first tool in this article is definitely the simpler of the two. In fact, simplicity is the main goal that Simon Guest was trying to achieve and this is its biggest selling point. This tool depends completely on the tracing feature inherent in WSE. Simply add the configuration code from Figure 1 into your web.config file and the contents of every SOAP request and response will be saved into the input and output files. To be honest, it s probably a misnomer to even call this a tracing tool because it doesn t actually perform any tracing itself. It s more of a WSE trace file viewer.
output="OutputTrace.webinfo" /> Figure 1: This configuration
text in the web.config file instructs ASP.NET to save all the information about
every SOAP request and response to the input and output files. What makes this tool so darn useful is that it is simply a
single executable file that needs no installation. You can simply drop it on a
server, point it at the location of the WSE trace files, and get an
easy-to-read display of all the SOAP calls in the viewer panes, as displayed in
Figure 2. However, this is not a perfect tool by any means. The tool
doesn t display incoming SOAP calls in real time, and I find that I need to
click between the tabs to make it refresh itself. Also, although the WSE trace
files are very useful, it appears that ASP.NET puts a filesystem lock on these
files and it becomes necessary to restart the worker process to turn the
tracing off. That being said, if you need a better trace file viewer than
Notepad, this is the one to use. Unlike the Simon Guest tool, Mike Taulty s tracing tool is
not only a file viewer, but a real-time WSE tracing application. It works by
telling WSE to send a copy of all SOAP calls to a port on which the tool is
listening. It s actually pretty ingenious. As SOAP requests come in to the Web services,
and SOAP responses go out, the details of each call are displayed in real time
in the tool, as you can see in Figure 3. I don t profess to know exactly how this tool does its
thing. As best as I can tell, it installs a SOAP filter into the GAC. You must
then add the information in Figure 4 to the web.config file, which inserts the
filter into the SOAP pipeline. As each SOAP request and response is processed,
a copy of the SOAP envelope is sent to the Mike Taulty tool. As you can see,
simplicity is not one of its advantages, but it is very, very good at real-time
WSE SOAP tracing. Figure 4: This
configuration text in the web.config file tells the SOAP pipeline to send a
copy of each request and response to the Mike Taulty tracing tool in real time. Which tool is better for tracing WSE calls? Well, that
depends. The information they display is exactly the same. I find that I use
them both, but for different reasons. The Simon Guest tool I use when trying to
diagnose problems on a development, test, or even production server. If a
client is having a Web services issue we might turn on tracing for a period of
time and then use this tool to see exactly what was being passed back and
forth. I find that this tool works very well in this diagnostic capacity.
However, because it lacks a real-time mode, it doesn t work as well for
development. The Mike Taulty tool is the inverse of the Simon Guest
tool. Because of its need to be installed and remain running while tracing
calls, and its lack of a save feature, it doesn t work as well for diagnosing
issues on a remote server. However, I find that it is excellent for tracing my
SOAP calls on my development machine as I m developing. Everything is displayed
in real time and I can see exactly how my code was translated into SOAP. So,
each tool has its place in my toolbox and I suspect that they can find a
place in yours, as well. Simon Guest s WSE 2.0 Trace Tool http://blogs.msdn.com/smguest/archive/2004/08/19/217394.aspx Mike Taulty s WSE 2.0 Tracing Utility http://mtaulty.com/blog/archive/2004/05/25/433.aspx Ken McNamee is a
Senior Software Developer with Vertigo Software, Inc., a leading provider of
software development and consulting services on the Microsoft platform. Prior
to this, he led a team of developers in re-architecting the Home Shopping
Network s e-commerce site, http://www.HSN.com,
to 100% ASP.NET with C#. Readers can contact him at [email protected]. 
Figure 2: Simon Guest s WSE Trace
tool is a very simple application that provides a significantly easier-to-read
interface for viewing the WSE trace files and diagnosing problems. Mike Taulty s WSE 2.0 Tracing Utility
Figure 3: Mike Taulty s WSE tracing utility
is an excellent real-time tracing tool that works best for development. Conclusion
References
