WSE Tracing Tools

Debug Your WSE-enabled Web Services Using Two Convenient Methods




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.


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.


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.


Mike Taulty s WSE 2.0 Tracing Utility

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.


Figure 3: Mike Taulty s WSE tracing utility is an excellent real-time tracing tool that works best for development.


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


Mike Taulty s WSE 2.0 Tracing Utility


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,, to 100% ASP.NET with C#. Readers can contact him at [email protected].




Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.