The Trace Filters

We’ll start our look at the filters that WSE gives us by looking at the Trace filters. These aren’t part of the GXA architecture, but they fill a massive gap in the initial .NET Web services implementation.

Note

The Trace filters provide an ideal debugging tool even if you’re not building a WSE-enabled application. Simply turn off all of the filters except the Trace filters, and you’ll have instant debugging of the messages that are entering and leaving your client or service. In most cases this beats using the trace utility provided with the Microsoft SOAP Toolkit!

As we pointed out earlier, in the current release of WSE the Trace filters are enabled by default but need some additional configuration before they’ll actually trace the input and output SOAP messages.

Within the <microsoft.web.services> configuration element, you simply add a <diagnostics> element that contains a <trace> element. Within the trace element, you specify whether the trace is enabled and the filenames of the input and output traces:

<diagnostics>   <trace enabled="true" input="input.xml" output="output.xml" /> </diagnostics>

The application that’s running, whether it’s the ASP.NET process or a client application, must have permission to write to the location you’ve specified. Once you enable tracing, the input and output Trace filters are enabled, and they start writing what they’re receiving and sending to the files you’ve specified. The only way you can trace one without the other is to physically remove the Trace filter from the pipeline. If you don’t specify the input and output filenames, the defaults of inputTrace.webinfo and outputTrace.webinfo are used, respectively.

You can see the messages that are traced by launching and running the DiagnosticsClient application from the chapter’s code samples. This simple example calls the MakeMyDay method of the Diagnostics Web service located at http://localhost/wscr/13/ diagnosticsws.asmx. This method simply returns a string. There’s nothing in this code you haven’t already seen, but it’s the action of the Trace filters we’re interested in this time.

When the call is made to the Web service, the output.xml file is written to disk, as shown in Figure 13-5.

Figure 13-5: The SOAP envelope sent to the MakeMyDay method

The SOAP envelope that is output from the client is sent to the Web service. If you were to look at the input filter on the server, you’d see that exactly the same SOAP envelope arrives at the server.

The return from the call, the input to the client application, is shown in Figure 13-6. The <MakeMyDayResult> element in the SOAP body is returned, as expected, but a <wsu:Timestamp> element is also returned in the SOAP header. This is added by TimestampOutputFilter. (We’ll look at this shortly.) If you were to look on the server, you’d see that the identical SOAP envelope was sent from the Web service.

Figure 13-6: The SOAP envelope returned from the MakeMyDay method

There isn’t a lot more to say about the Trace filters. You simply turn on the filters and specify the filenames of where you want the filters to go. When a call is made, the input and output filters are updated with a new <soap:Envelope> element that contains the relevant SOAP message.

As you’ll soon see, however, there’s one situation in which the Trace filters, which provide very good debugging facilities for the SOAP envelope, might not fulfil all your debugging requirements.