Deployed services need to be tuned for performance,
managed, and administered in order to meet SLA requirements. Service
custodians are typically responsible for managing services through these
post-implementation lifecycles.
Administration
Address and binding
information are decoupled from a service and stored in the application
configuration file. Setting up and maintaining these settings is
typically an administrative task. WCF provides two types of related
APIs:
By default, WCF
installs several granular performance counters that capture metrics at
the service level, operation level, and service endpoint level. These
performance counters are extensible, allowing for the creation of custom
variations.
All management tools for
Windows, including IBM Tivoli, Microsoft MOM, and HP OpenView, work
through Windows Management Instrumentation (WMI). WCF includes a WMI
provider. Administrators need to switch on this WMI provider for the
service in the configuration file in order to make the service visible
in the management tool. The management tool then allows you to examine
which services are running and query exposed endpoints.
Troubleshooting
WCF provides tracing
support, which can facilitate message tracking and general debugging.
Tracing metrics rely on application instrumentation and diagnostics data
used for fault monitoring. WCF traces can also be used across all
services within a given service composition in order to provide an
end-to-end view of message paths.
When tracing is enabled, WCF
emits data for operation calls, exceptions, and other significant
processing events across all services. WCF tracing is based on the use
of System.Diagnostics for which we need
to define trace listeners in the configuration file. This form of
tracing is not enabled by default, and requires that a trace listener be
created in the application’s configuration file, as shown here:
Example 1.
<system.diagnostics>
<sources>
<source name="System.IO.Log" switchValue="Verbose">
<listeners>
<add name="xmlListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "c:\traceLogs\" />
</listeners>
</source>
</sources>
</system.diagnostics>
|
In the preceding example, the XmlWriterTracelListener
is used to emit XML. Since the trace output is an XML file, the
location where the XML file must be deposited is specified using the initializeData setting. Each source can have any number of listeners associated with it.
The switchValue
setting controls the trace level, which is the level of detail for
messages emitted to the listener. Trace levels available in WCF are
listed in Table 1.
Table 1. A list of WCF trace levels.
| Trace Level | Level of Detail |
|---|
| off | no data is emitted |
| critical | only unhandled exceptions that result in stopping the application are logged |
| error | all exceptions are logged even if the service is up and running |
| warning | a problem occurred or may occur but the service is up and functioning correctly |
| information | all important and successful events are logged |
| verbose | all successful events are logged |
Logging Messages
Messages
passed between the services and their consumers are not logged
automatically. Message logging must be enabled in the configuration file
and, similar to the trace listeners, message logging also requires that
a listener be created, as follows:
Example 2.
<system.diagnostics>
<sources>
<source name="System.ServiceModel.MessageLogging">
<listeners>
<add name="LogMessages"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="c:\logs\messages" />
</listeners>
</source>
</sources>
</system.diagnostics>
|
This listener logs all messages as text to the folder c:\logs\messages. The following messageLogging setting is used to filter and manage logged messages.
Example 3.
<diagnostics>
<messageLogging
logEntireMessage="true"
logMalformedMessages="true"
logMessagesAtServiceLevel="true"
logMessagesAtTransportLevel="true"
maxMessagesToLog="300"
maxSizeOfMessageToLog="200" />
</diagnostics>
