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 3

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.

Activities and Correlation
A WCF activity is a logical subset of functionality used to group traces for ease of identification and monitoring. An example is the processing of a call into a service endpoint. Although activities are independently useful, effective monitoring requires a mechanism to track flow between multiple activities.

Correlation is the concept of associating multiple activities to create a logical sequence of flow in a distributed application. Correlation is performed via transfers, linking activities within an endpoint, and propagation, linking activities across multiple endpoints.

Activities are correlated by the interchange of an identifier called the activity ID. This identifier, a GUID, is generated by the System.Diagnostics.CorrelationManager class. CorrelationManager is associated with a trace and can be retrieved via the static property System.Diagnostics.Trace.CorrelationManager. It has two primary methods, StartLogicalOperation() and StopLogicalOperation(), used to link associated actions into a logical unit for tracing purposes.

Enabling Tracing
Tracing is disabled by default and can be enabled by configuring a trace source to emit information and trace listeners to process and save the final trace details.

Here are the relevant portions of the SelfHost App.config file configured for tracing:

    <system.serviceModel ... />
      <source name="System.ServiceModel" 
        <add type="System.Diagnostics.DefaultTraceListener" 
         <filter type="" />
        <add initializeData="app_tracelog.svclog" 
           name="tracelog" traceOutputOptions="Timestamp">
         <filter type="" />
In the preceding code, the <source> node references the System.ServiceModel trace source, which is the source used by WCF to emit tracing details. In the <listeners> node, we can add one or more trace listeners to process those details. The type property indicates the listener class to invoke and the initializeData contains arguments to that listener, such as a file location. An XmlWriterTraceListener is configured to write details to the app_tracelog.svlog file.

Author's Note: Service Configuration Editor—To avoid having abstractions hide the mechanics of WCF diagnostics, we're enabling tracing and message logging by manually specifying settings in the respective App.config files. Later in this chapter, we'll show how to use the Service Configuration Editor to quickly and accurately make such changes without editing the configuration files directly. The trace source has a switchValue property that is used to specify the level of detail that should be captured. Table 1 shows the possible values for the switchValue property when configuring the trace source.

Table 1: Tracing Source switchValue Attribute Options
Option Purpose
Off Disables the trace source.
Critical Tracks the most serious application and environmental failures, such as a service failing, or a service being unable to start.
Error Issues with application logic or the environment—for example, an unrecoverable exception.
Warning Scenarios that may result in an exception or failure in the future, or notifications that the application recovered from an exception.
Information Details about system events that may be helpful for debugging, simple auditing, and overall monitoring.
Verbose Full information at each processing step. Useful for pinpointing sources of issues.
ActivityTracing Uses correlation to track flow between logically connected components of the distributed application.

Note that ActivityTracing can be combined with a verbosity selector (for example, switchValue="Warning, ActivityTracing").

Verbosity Recommendations
Using the more verbose options for tracing can quickly lead to large amounts of traced information, which can add to system overhead and increase the challenge of separating the relevant data from extraneous data. When diagnosing an issue, we recommend that you begin tracing at the Warning level.

When operating under normal production conditions, consider leaving tracing off or at Critical or Error until conditions require further information for diagnostics or monitoring.

Message Logging
Tracing is used to record the flow and individual actions of the various components of a distributed application. Another feature, message logging, is used to record the contents of the messages from or to clients and services. Message logging can be configured to capture messages at the service level, the transport level, and to record messages that are malformed. The data captured via message logging can be useful for a variety of situations, from diagnostics to creating audit trails of service utilization.

Enabling Message Logging
Like tracing, message logging is based on System.Diagnostics and is disabled by default. It can be enabled first by adding a trace listener (for example, XMLWriterTraceListener) to process messages from the System.ServiceModel.MessageLogging trace source.

Here's the SelfHost application configuration, configured for message logging:

     <services ... />
     <behaviors ... />
      <source name="System.ServiceModel.MessageLogging">
        <add name="messages"
          initializeData="messages.svclog" />

The <system.diagnostics> section looks similar to that used for enabling tracing. We have added a source using System.ServiceModel.MessageLogging, the mechanism through which messages are emitted for logging, and are processing that source with the same listener class, XmlWriterTraceListener, used earlier for tracing.

Unlike tracing, however, the format and verbosity of messages emitted by the MessageLogging source is specified in a <messageLogging> element added to the <system.serviceModel><diagnostics> configuration node. Table 2 shows the messageLogging options along with descriptions of their purposes. Any number of these options may be specified in configuration, and those that are not will use the default values shown in Table 2.

Table 9.2messageLogging Element Attributes and Values
Option Default Purpose
logEntireMessage False If true, both the message header and body are logged. If false, only the message header will be logged.
logMalformedMessages False Logs incorrectly formatted messages.
logMessagesAtServiceLevel False Logs messages as received or sent by the service itself.
logMessagesAtTransportLevel False Logs messages either just before encoding for transport or directly after being received from transport.
maxMessagesToLog 10,000 Number of logged messages after which further logging will be suspended.
maxSizeOfMessageToLog 262,144 Maximum message size, in bytes, that will be logged. If a message exceeds this limit, it will be ignored and a warning trace will be emitted.

Note that messages logged at the transport level may be encrypted, depending on the binding or configuration options you have selected.

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