Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

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

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.


advertisement
Additional Configuration Options
The previous sections described basic approaches for configuring logging and tracing. In this section, we'll describe several other options that you should be aware of for configuring your WCF application.

Shared Listeners
The previous examples have used dedicated listeners for each of the sources (messages and tracing). You may choose to configure a shared listener and assign multiple sources, unifying the output to a single item, such as an XML file. The code below shows how to configure both tracing and message logging to use the same output file:

<configuration> <system.serviceModel ... /> <system.diagnostics> <sources> <source name="System.ServiceModel" propagateActivity="true" switchValue="Warning,ActivityTracing"> <listeners> <add name="diagnostics" /> </listeners> </b> </source> <source name="System.ServiceModel.MessageLogging"> <b><listeners> <add name="diagnostics" /> </listeners> </source> </sources> <sharedListeners> <add name="diagnostics" type="System.Diagnostics.XmlWriterTraceListener" initializeData="diagnostics.svclog" /> </sharedListeners> </system.diagnostics> </configuration>

For each source, the code ads add a listener whose name matches the name of one of the shared listeners. In this case, we're matching the "diagnostics" listener, which will write traces and messages to the same diagnostics.svclog file.

Message Filters
By default, all messages appropriate for the level specified in the <messageLogging> configuration element are logged. However, to reduce the overhead associated with logging and to decrease the size of log files, you might want to include only messages that match a set of rules you configure.

Message filters are XPath expressions that must be satisfied before a message will be logged. Messages that do not match the XPath queries are excluded, except for malformed messages, which are not affected by filters.

Specify the filters by adding a <filters> node to the <messageLogging> element:

<configuration> <system.serviceModel> <services ... /> <behaviors ... /> <diagnostics> <messageLogging logMalformedMessages="true" logMessagesAtTransportLevel="true"> <filters> <add nodeQuota="1000" xmlns:s12="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa10="http://www.w3.org/2005/08/addressing"> /s12:Envelope/s12:Header/wsa10:Action[ starts-with(text(), 'http://Microsoft.ServiceModel.Samples/ICalculator')] </add> </filters> </messageLogging> </diagnostics> </system.serviceModel> <system.diagnostics ... /> </configuration>

This example may seem complex, but the bulk of it defines the namespaces used in the XPath expression. Those namespaces are for the SOAP envelope and addressing schemas. The expression checks the header of each message to ensure it is directed to one of the ICalculator services defined in our SelfHost example. Messages for other services are ignored.

Trace Source Auto Flushing
If you want each tracing or message logging operation to automatically complete (write to disk) after each trace, enable auto flushing in the <trace> element of the <system.diagnostics> configuration node as shown below:



<configuration> <system.serviceModel ... /> <system.diagnostics> <sources ... /> <trace autoflush="true" /> </system.diagnostics> </configuration>

Trace auto flushing is off by default. Before enabling auto flushing in production scenarios, be certain to measure the impact in a test environment because it can add overhead, especially as message traffic increases.

Performance Counters
Three sets of WCF-related performance counters are installed with the .NET Framework 3.0. In Performance Monitor, you can see these counters under ServiceModelService, ServiceModelEndpoint, and ServiceModelOperation. You can choose to enable these for your application via configuration as follows:

<configuration> <system.serviceModel> <diagnostics performanceCounters="ServiceOnly"> <messageLogging logMalformedMessages="true" logMessagesAtTransportLevel="true" /> </diagnostics> </system.serviceModel> </configuration>

Enable performance counters by including the performanceCounters attribute in the <system.serviceModel><diagnostics> node. Valid settings are Off (the default), ServiceOnly, and All. Enabling all performance counters is recommended for development and diagnostic purposes, but because performance counters do come with some cost of overhead, ServiceOnly is recommended for normal production operations, which will enable only those in the ServiceModelService category.

Author's Note: Observing Performance Counters—You need a running instance of a WCF service or client to add performance counters in the Performance Monitor application. Ensure performance counters are enabled in configuration and start your service, then add the counters you want to observe, and then run your client application.

Windows Management Instrumentation (WMI)
WCF supports the capability to expose settings and status via Windows Management Instrumentation, or WMI. Many popular application administration and management applications, such as Microsoft Operations Manager and HP OpenView, use WMI to access various systems across an enterprise. Windows PowerShell also has native WMI capabilities, enabling you to write custom scripts for specific management and monitor scenarios.

You can enable the WMI provider for your WCF application in configuration like this:

<configuration> <system.serviceModel> <diagnostics wmiProviderEnabled="true"> <messageLogging logMalformedMessages="true" logMessagesAtTransportLevel="true" /> </diagnostics> </system.serviceModel> </configuration>

Enabling WMI is similar to enabling performance counters. Add the wmiProviderEnabled attribute to the <system.serviceModel><diagnostics> node. After it is enabled, administration applications will be able to monitor and manage your WCF application.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

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