RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Book Excerpt: Essential Windows Communication Foundation (WCF) for .NET Framework 3.5 : Page 2

This revamped book covers developing with the latest release of WCF in Visual Studio 2008 on the .NET Framework 3.5, giving practical advice, numerous examples, tips and tricks, and ways to avoid the "pain points" of WCF development. Chapter 9 covers WCF Diagnostics.

s you've seen in the previous chapters, WCF offers numerous options for configuring your distributed applications and for extending WCF with custom code. Combine that with the complexities of cross-machine and even cross-company interactions and you have many places to look for sources of unexpected behavior.

Debugging distributed applications can be a challenging prospect. Even if you do have access to the processes and symbol tables necessary for stepping through flow across service call boundaries, remote logic might have been created by a different team with different coding and execution practices. There is also the difficulty of filtering diagnostic information to isolate a particular flow of execution—for example, a single user's session across multiple services and machines.

However, the challenge of any distributed system is not only its initial development, but ensuring ease of maintenance as that application is utilized in production scenarios. IT administrators need efficient means for finding root causes of issues so that the responsible company and development team can be notified.

Fortunately, WCF has a number of built-in features and tools for diagnosing causes of issues, often without much more effort than electing to enable those features in your configuration files. As you'll see in this chapter, WCF utilizes and builds on the native tracing and diagnostics features of the .NET Framework. This allows you to leverage your existing knowledge, and it enables integration of WCF applications' diagnostics with those of other applications.

In this chapter, we describe how to use tracing facilities to capture WCF events and logging to capture details of exchanged messages. Trace listeners are described, along with examples that show how to configure the settings for different events. The Service Trace Viewer, a powerful tool that is included with WCF, is also described, which enables you to inspect activities across service call boundaries.

Sample WCF Application
This chapter uses the SelfHost sample application that is included with the Windows SDK. Details on obtaining, configuring, and running the sample can be found on MSDN at http://msdn2.microsoft.com/en-us/library/ms750530.aspx. If you have the SDK installed, you'll find the SelfHost application under Basic\Service\Hosting\SelfHost\ with both C# and VB.NET versions available.

SelfHost is an introductory sample consisting of simple service and client Windows console projects. The client console application makes several calls to the WCF service, and results are displayed on both the client and service consoles.

The core diagnostics capabilities of WCF build on the existing tracing facilities provided by the .NET Framework itself. The System.Diagnostics namespace includes classes that enable applications to easily emit tracing information and store those details in a variety of formats and locations.

System.Diagnostics features tracing capabilities organized around the concepts of trace sources and trace listeners. Trace sources are configured using the System.Diagnostics.TraceSource class and enable applications to emit details of execution, such as data or events. The traces emitted by a trace source can be received and processed by one or more trace listeners, classes derived from the abstract base class System.Diagnostics.TraceListener.

WCF natively utilizes these features to emit details about the actions occurring during the processing of service calls and responses. No custom code is required to create these details and the developer or IT administrator need only add configuration to enable the source and listener, as described next. However, developers are free to add their own tracing calls to emit additional details as desired.

End-to-End Tracing
A central feature for monitoring WCF applications is called end-to-end (E2E) tracing. This concept utilizes System.Diagnostics features of the .NET Framework to pass identifiers between the various entities of a distributed application so that their actions can be correlated into a logical flow. Using E2E tracing, it is possible to follow a sequence of actions across service and machine boundaries—for example, from request origination on the client through the business logic invoked by the target service.

E2E tracing uses a specific XML schema to persist details of processing across logical boundaries. The XML is created by registering an instance of the System.Diagnostics.XMLWriterTraceListener, which processes trace information into the E2E XML format (defined at http://schemas.microsoft.com/2004/06/E2ETraceEvent).

The code below shows an abridged E2E trace XML fragment:

   <E2ETraceEvent xmlns=."..">
    <System xmlns=."..">
     <TimeCreated SystemTime=
       "2007-05-06T15:28:11.4178040Z" />
     <Source Name="System.ServiceModel" />
     <Correlation ActivityID=
       "{7175a87f-b796-4f8a-a416-f2b284d4df39}" />
     <Execution ProcessName="Host.vshost" 
   ProcessID="533" ThreadID="5"/>
      <Description>Activity boundary.</Description>
      <ActivityName>Construct ServiceHost 
Note in particular the Correlation node and the ActivityID property. These are the keys to combining individual trace fragments from a variety of sources into a unified logical flow. The concepts behind correlation are described next.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date