| The Windows Communication Foundation provides these tools for administering software services: A configuration system for deployment and for post-deployment control and tuning A configuration editor Configurable auditing of security events Message logging The tracing of internal activities and of sequences of activities across nodes A Trace Viewer designed for following sequences of activities across nodes Performance counters for key operational, security, reliability, and transaction statistics for services; the various endpoints of a service; and the individual operations of an endpoint A Windows Management Instrumentation (WMI) provider for querying and modifying the properties of running services
The Configuration System Windows Communication Foundation services are defined by an address that specifies where they are located, a binding that specifies how to communicate with them, and a contract that specifies what they can do. The internal operations of Windows Communication Foundation services and clients can be controlled through properties called behaviors. Although one can write code to specify the addresses, bindings, and contracts of services, and to modify the behaviors of services and clients, the Windows Communication Foundation allows one to instead specify addresses, bindings, and contracts and to modify behaviors in configuration files. That allows system administrators to control how services behave without requiring programming modifications. Indeed, using configuration files to specify addresses, bindings, and contracts is preferred to using code. The Windows Communication Foundation's configuration system simply extends that of Microsoft .NET. Therefore, it should be familiar to any administrator of .NET applications. The language of the Windows Communication Foundation's configuration system is defined in the file \Program Files\Microsoft Visual Studio 8\Xml\Schemas\DotNetConfig.xsd, on the disc where Visual Studio 2005 resides, after the Visual Studio 2005 Extensions for WinFX have been installed. The Configuration Editor A configuration editor is provided to ease, and give guidance for, the task of editing configuration files. This tool is one of the most rapidly evolving components of the Windows Communication Foundation. The Windows Communication Foundation's Service Model had to be completed before coding of the tools for using it could proceed in earnest, and after initial versions of the tools were released, refinements to them have followed quickly. Indeed, the configuration editor is being superseded by a configuration wizard, a prototype of which was being shown internally at Microsoft in early January 2006. Consequently, details on the use of the tools in these pages are very likely to have been made obsolete by changes in how the tools work in subsequent releases. So do not read these details to see exactly how to use the tools, but rather to see that even in early versions, the tools are intuitive to use and they work. Because future versions will be even more intuitive to use, adapting the details that follow to those subsequent versions should be quite straightforward. The Configuration Editor is SvcConfigEditor.exe. It should be found in the folder \Program Files\Microsoft SDKs\Windows\v1.0\Bin, assuming a complete and normal installation of the Microsoft Windows SDK for the December 2005 WinFX CTP. Configuring the Trade Recording Service with the Configuration Editor Recall that the trade recording service of the trading service solution is a service for recording the purchase of derivatives. That service is not currently in a working state. To confirm that, do the following: Right-click on the trade recording service host project of the trading service solution in Visual Studio 2005, and choose Debug, Start New Instance from the context menu. An exception should be thrown with this error message: "Service has zero application (non-infrastructure) endpoints, [which] might be because no configuration file was found for your application, or because there was a problem with the type in the configuration file." The message is quite accurate: The service cannot start because no endpoints have been defined for it. There is indeed no configuration file with endpoint definitions. Stop debugging.
Follow these steps to use the Configuration Editor to configure an endpoint for the trade recording service: 1. | Execute \Program Files\Microsoft SDKs\Windows\v1.0\Bin\SvcConfigEditor.exe.
| | | 2. | Choose File, Open, Executable from the menus, as shown in Figure 12.2.
Figure 12.2. Selecting an executable. 
| | | 3. | Select the trade recording service's host assembly C:\WCFHandsOn\Management\TradeRecordingServiceHost\bin\Debug\TradeRecordingServiceHost.exe, as shown in Figure 12.3.
Figure 12.3. Selecting the trade recording service's host assembly. 
| | | 4. | On the Services tab, click on the New button shown in Figure 12.4.
Figure 12.4. The Services tab. 
| | | 5. | A service is configured by identifying the service type and defining its endpoints. To select the service type from the General tab of the Service Editor, shown in Figure 12.5, click on the ellipsis button opposite the ServiceType label.
Figure 12.5. The General tab of the Service Editor. 
| | | 6. | The service type of the trade recording service is in the assembly built from the trade recording service project: C:\WCFHandsOn\Management\TradeRecordingServiceHost\bin\Debug\TradeRecordingService.dll. Select that assembly, as shown in Figure 12.6, and click on the Open button.
Figure 12.6. Selecting an assembly. 
| 7. | Choose the Fabrikam.TradingRecorder service type from within the assembly, as shown in Figure 12.7, and click on the Open button.
Figure 12.7. The Service Type Browser. 
| | | 8. | The General tab of the Service Editor should now show Fabrikam.TradeRecorder as the service type, as shown in Figure 12.8. Click OK to return to the main screen of the Configuration Editor, which should now appear as shown in Figure 12.9.
Figure 12.8. The selected service type. 
Figure 12.9. Service configured with a service type. 
| | | 9. | Select the Bindings tab, and then choose netMsmqBinding from the list of binding types as shown in Figure 12.10.
Figure 12.10. Selecting a binding. 
| | | 10. | Click on the New button, and then configure a netMsmqBinding with the name QueuedBinding, as shown in Figure 12.11.
Figure 12.11. Configuring a binding. 
| | | 11. | Select the Security tab, and select None from the list of security modes, as shown in Figure 12.12.
Figure 12.12. Configuring the security of a binding. 
| 12. | Click OK, and the Bindings tab should appear as shown in Figure 12.13.
Figure 12.13. A configured binding. 
| | | 13. | Now that a suitable binding configuration has been created, an endpoint with that binding can be added to the service. Select the Services tab again, and click on the Edit button, depicted in Figure 12.14.
Figure 12.14. Preparing to configure the endpoints of a service. 
| 14. | Select the Endpoints tab of the Service Editor represented in Figure 12.15.
Figure 12.15. The Endpoints tab of the Service Editor. 
| | | 15. | Specify the address of the endpoint as shown in Figure 12.16.
Figure 12.16. Specifying the address of an endpoint. 
| | | 16. | Select netMsmqBinding from the list of bindings, as shown in Figure 12.17.
Figure 12.17. Specifying the binding of an endpoint. 
| | | 17. | Select the QueuedBinding binding configuration, which was defined in the preceding steps, from the list of available binding configurations, as shown in Figure 12.18.
Figure 12.18. Configuring the binding of an endpoint. 
| | | 18. | To identify the contract exposed at the endpoint, click on the ContractType ellipsis button shown in Figure 12.19.
Figure 12.19. Preparing to identify the contract of an endpoint. 
| | | 19. | Select the Fabrikam.ITradeRecorder service contract in the assembly C:\WCFHandsOn\Management\TradeRecordingServiceHost\bin\Debug\TradeRecordingService.dll, as shown in Figure 12.20, and click on the Open button.
Figure 12.20. Identifying the contract of an endpoint. 
| | | 20. | The endpoint configuration should now appear as shown in Figure 12.21. Click on the OK button to return to the Endpoints tab of the Service Editor.
Figure 12.21. The endpoint configuration in the Service Endpoint Editor. 
| | | 21. | The Endpoints tab of the Service Editor should now appear as depicted in Figure 12.22, showing the address and the binding of the endpoint. Click on the OK button to return to the main screen of the Configuration Editor.
Figure 12.22. The endpoint configuration in the Service Editor. 
| | | 22. | Choose File, Save from the Configuration Editor menus, as shown in Figure 12.23.
Figure 12.23. Saving the service configuration. 
|
Confirm that whereas the trade recording service was not initially in a working state, it now is able to work because it has been properly configured using the Windows Communication Foundation's configuration editor: Right-click on the trade recording service host project of the trading service solution in Visual Studio 2005, and choose Debug, Start New Instance from the context menu. After a few seconds, the console application window of the trade recording service host should appear, confirming that the service is available. Stop debugging.
Configuring a Client Application with the Configuration Editor Follow these steps to configure the client risk management application to communicate with the trading service, which, in turn, uses the trade recording service to record derivatives purchases. The trading service has an endpoint at the address http://localhost:8000/ TradingService. That endpoint uses the Windows Communication Foundation's standard WSHttpBinding. The WSHttpBinding is customized to include information about the state of transactions within messages, and to ensure that the messages are delivered exactly once, and in order: 1. | Choose File, Open, Executable from the Configuration Editor's menus, as shown in Figure 12.24.
Figure 12.24. Selecting an executable. 
| | | 2. | Select C:\WCFHandsOn\Management\Client\bin\Debug\Client.exe, as shown in Figure 12.25.
Figure 12.25. Selecting the client executable. 
| | | 3. | Select the Bindings tab, as shown in Figure 12.26.
Figure 12.26. The Bindings tab. 
| | | 4. | Select wsHttpBinding from the list of bindings, and then click on the New button to create a new configuration of that standard binding, as shown in Figure 12.27.
Figure 12.27. Selecting the binding. 
| | | 5. | As shown in Figure 12.28, give the binding configuration the name ReliableHttpBinding, set the value of the TRansactionFlow property to TRue, and, under the ReliableSession Properties heading, set the values of the Enabled and Ordered properties to true.
Figure 12.28. Configuring the binding. 
| | | 6. | Click OK, and the Bindings tab should appear as shown in Figure 12.29.
Figure 12.29. A configured binding. 
| | | 7. | Now that a suitable binding configuration has been created, the service endpoint to be addressed by the client application can be defined. Select the Client tab, and click on the Edit button, depicted in Figure 12.30.
Figure 12.30. The Client tab. 
| | | 8. | Enter tradingService as the name of the endpoint configuration, and http://localhost:8000/TradingService as the address of the service endpoint, as shown in Figure 12.31.
Figure 12.31. Specifying an endpoint address. 
| | | 9. | Choose wsHttpBinding from the list of bindings, as indicated in Figure 12.32.
Figure 12.32. Selecting a binding. 
| | | 10. | Select ReliableHttpBinding from the list of binding configurations, as indicated in Figure 12.33.
Figure 12.33. Configuring a binding. 
| | | 11. | To identify the contract exposed at the endpoint, click on the ContractType ellipsis button shown in Figure 12.34.
Figure 12.34. Preparing to identify the contract of an endpoint. 
| | | 12. | The contract is defined in the client assembly, so select the C:\WCFHandsOn\Management\Client\bin\Debug\Client.exe assembly, as shown in Figure 12.35, and click on the Open button.
Figure 12.35. Selecting the assembly containing the contract. 
| | | 13. | Select the Client.ITradingService service contract as shown in Figure 12.36, and click on the Open button.
Figure 12.36. Selecting a service contract. 
| | | 14. | The endpoint configuration should now appear as shown in Figure 12.37. Select the Identity tab.
Figure 12.37. The endpoint configuration in the Channel Endpoint Editor. 
| | | 15. | Enter the current user's principal name in the format domain\name as the value of the UserPrincipalName property, as shown in Figure 12.38, but substituting the current user's principal name for the name shown. Click on the OK button to return to the Client tab of the Service Editor.
Figure 12.38. Setting the UserPrincipalName property of the identity. 
| | | 16. | The client configuration should now appear as shown in Figure 12.39. Choose File, Save from the Configuration Editor's menus, as shown in Figure 12.40.
Figure 12.39. The client configuration. 
Figure 12.40. Saving the client configuration. 
| 17. | Choose File, Exit from the menus to close the Configuration Editor.
|
Test the newly configured solution by following these steps: | | 1. | In Visual Studio 2005, right-click on the solution at the top of the tree in the Solution Explorer, and choose Set Startup Projects from the context menu. Confirm that the Startup Project properties are configured as shown in Figure 12.41
Figure 12.41. Startup Project properties. 
| | | 2. | Choose Debug, Start Debugging from the menus.
| 3. | When there is activity in the console application windows of the trade recording service host and the trading service host, confirming that the services they host are ready, enter a keystroke into the console application window of the client application.
After a few moments, activity should start to appear in the console application window of the trading service host, as the client risk management system begins pricing and purchasing a derivative. There may be a pause as the trading service loads the Microsoft Distributed Transactions Coordinator for the first time. Then the pricing and purchasing of primary and hedging derivatives purchases should proceed.
| 4. | Stop debugging.
|
Configurable Auditing of Security Events The Windows Communication Foundation records security events in the Windows event log. That facility is one of the Windows Communication Foundation's many behaviors, and it is configurable. To see how to configure it, follow these steps: 1. | Execute \Program Files\Microsoft SDKs\Windows\v1.0\Bin\SvcConfigEditor.exe.
| | | 2. | Choose File, Open, Executable from the menus, as shown in Figure 12.42, and open the assembly C:\WCFHandsOn\Management\TradingServiceHost\bin\Debug\TradingServiceHost.exe.
Figure 12.42. Selecting an executable. 
| 3. | Select the Behaviors tab, and click on the New button, as shown in Figure 12.43.
Figure 12.43. The Behaviors tab. 
| | | 4. | In the Behavior Editor, provide the name TRadingService for the behavior, as shown in Figure 12.44.
Figure 12.44. The Behavior Editor. 
| 5. | Click on the Add button in the Elements section.
| 6. | Select serviceSecurityAudit from the list of behaviors meant to be configured by an administrator, as shown in Figure 12.45. The ServiceSecurityAudit behavior is the behavior by which the Windows Communication Foundation's auditing of security events can be controlled.
Figure 12.45. Selecting the ServiceSecurityAudit behavior. 
| | | 7. | Click on the Add button.
| 8. | Back in the main screen of the Behavior Editor, select serviceSecurityAudit, which now appears in the list in the Elements section, as shown in Figure 12.46, and click on the Properties button.
Figure 12.46. Preparing to configure the ServiceSecurityAudit behavior. 
| | | 9. | In the property editor for the ServiceSecurityAudit behavior, select Application as the AuditLogLocation, as shown in Figure 12.47.
Figure 12.47. Selecting the audit log location. 
| | | 10. | Choose SuccessOrFailure as the value for the MessageAuthenticationAuditLevel, as shown in Figure 12.48.
Figure 12.48. Setting the message authentication audit level. 
| | | 11. | Choose SuccessOrFailure as the value for the ServiceAuthenticationAuditLevel, as shown in Figure 12.49.
Figure 12.49. Setting the service authentication audit level. 
| 12. | Click on the OK button to return to the Behavior Editor.
| 13. | Click OK to return to the main screen of the Configuration Editor.
Now a behavior configuration including the ServiceSecurityAuditBehavior has been created. That behavior configuration will now be associated with the trading service.
| | | 14. | Select the Services tab, and select Fabrikam.TradingSystem in the list of services, as shown in Figure 12.50, and click on the Edit button.
Figure 12.50. Preparing to configure the service with the behavior. 
| | | 15. | Select the tradingService behavior configuration from the list of behavior configurations, as shown in Figure 12.51.
Figure 12.51. Applying a behavior configuration to a service. 
| 16. | Click the OK button to return to the main screen of the Configuration Editor.
| | | 17. | Choose File, Save from the menus, as shown in Figure 12.52.
Figure 12.52. Saving a configuration. 
| 18. | Select File, Exit from the menus to close the Configuration Editor.
|
Follow these steps to test the new configuration of the security auditing behavior: 1. | In Visual Studio 2005, in the trading service solution, Choose Debug, Start Debugging from the menus.
| 2. | When there is activity in the console application windows of the trade recording service host and the trading service host, confirming that the services they host are ready, enter a keystroke into the console application window of the client application.
| 3. | After seeing activity in the console application windows of the trading service host and the client as they price and purchase derivatives, stop debugging.
| 4. | Open the Windows Event viewer.
| 5. | Refresh the application log.
| | | 6. | Locate and examine events with the source ServiceModel Audit. Those are the Windows Communication Foundation's security audit events. They should look like the event shown in Figure 12.53.
Figure 12.53. Windows Communication Foundation security audit event. 
|
Message Logging Windows Communication Foundation applications can be configured to log incoming and outgoing messages. Messages can be logged not only at the point at which they are transported, but also as they proceed through the Channel Layer. The message logging facility is implemented using the trace listening mechanism already incorporated in .NET, in the System.Diagnostics namespace. A trace listener is a class that knows how to output diagnostic information to a particular destination, such as an event log, or file of a particular format. When particular categories of diagnostic information are directed to a trace listener, the information in that category is dispatched to the destination to which the trace listener sends its output. The same diagnostic information can be recorded in various ways when information is directed to multiple trace listeners. Message logging is a particular type of diagnostic information that can be sent to a trace listener for recording. By providing message logging via trace listeners, the Windows Communication Foundation not only uses a mechanism with which .NET developers will already be familiar, but also allows developers, enterprises, and other software vendors that may have developed custom trace listeners to use those for logging messages. To see how to log messages, follow these steps: 1. | Execute \Program Files\Microsoft SDKs\Windows\v1.0\Bin\SvcConfigEditor.exe.
| 2. | Start the Configuration Editor; choose File, Open, Executable from the menus, and open the assembly C:\WCFHandsOn\Management\TradingServiceHost\bin\Debug\TradingServiceHost.exe.
| | | 3. | Select the Diagnostics tab as shown in Figure 12.54.
Figure 12.54. The Diagnostics tab. 
| 4. | Click on the Logging button to access the Message Logging Editor shown in Figure 12.55.
Figure 12.55. The Message Logging Editor. 
| | | 5. | Select the Logging tab, shown in Figure 12.56, and set the values of the LogEntireMessage, LogMessagesAtServiceLevel, and LogMessagesAtTransportLevel properties to true.
Figure 12.56. The Logging tab. 
| 6. | Select the Listeners tab, shown in Figure 12.57, and click on the Create button. Doing that serves to direct the message logs to a custom trace listener.
Figure 12.57. The Listeners tab. 
| | | 7. | Use the Save Log As dialog, shown in Figure 12.58, to specify that the trace listener is to record the message log in the file C:\WCFHandsOn\Management\TradingServiceHost_messages.e2e.
Figure 12.58. Selecting a message logging location. 
| 8. | The Message Logging Editor should now appear as shown in Figure 12.59. Click on the OK button.
Figure 12.59. The message logging configuration. 
| | | 9. | Choose File, Save from the Configuration Editor menus to save the configuration, as shown in Figure 12.60.
Figure 12.60. Saving the configuration. 
| 10. | Select File, Exit from the menus to close the Configuration Editor.
|
To see messages being logged, do the following: In Visual Studio 2005, in the trading service solution, choose Debug, Start Debugging from the menus. When there is activity in the console application windows of the trade recording service host and the trading service host, confirming that the services they host are ready, enter a keystroke into the console application window of the client application. Wait until the console application window of the client application confirms that it is done pricing and purchasing derivatives. Enter a keystroke into each console application window. Execute the Windows Communication Foundation's Trace Viewer, which is SvcTraceViewer.exe. It should be found at C:\Program Files\Microsoft SDKs\Windows\v1.0\Bin, assuming a complete and normal installation of the Microsoft Windows SDK for the December 2005 WinFX CTP. The Trace Viewer is shown in Figure 12.61. Figure 12.61. The Trace Viewer.  Choose File, Open from the menus, and open the file C:\WCFHandsOn\Management\TradingServiceHost_messages.e2e, which is the file in which the trace listener was to record the message logs. Select the first entry in the activity list on the left of the Trace Viewer; then select the XML tab on the lower right, and scroll through the entry on that tab. It contains a record of a message, as shown in Figure 12.62. Figure 12.62. A logged message. 
Traces Wikipedia defines a trace as "a detailed record of the steps a computer program executes during its execution, used as an aid in debugging" (Wikipedia 2006). The Windows Communication Foundation generates traces for internal processing milestones, events, exceptions, and warnings. The traces are intended to enable administrators to see how an application is behaving and understand why it may be misbehaving without having to resort to using a debugger. In fact, the members of the Windows Communication Foundation development team are encouraged to diagnose unexpected conditions they might encounter using the traces rather than a debugger, and to file a bug report demanding additional traces if the existing traces are not sufficient to allow them to render a diagnosis. The Microsoft .NET Framework Class Library 2.0 provides an enhanced tracing infrastructure in the form of classes that have been added to the System.Diagnostics namespace, and the Windows Communication Foundation leverages those new classes. The most important of them is the traceSource class that allows one to generate traces associated with a named source: private static TraceSource source = new TraceSource("ANamedSource"); source.TraceEvent(TraceEventType.Error,1,"Trace error message.");
Given a named source of traces, one can configure trace listeners to listen for traces from that particular source: <configuration> <system.diagnostics> <sources> <source name="ANamedSource" switchValue="Warning" <listeners> <add name="AListener"/> <remove name="Default"/> </listeners> </source> </sources> <sharedListeners> <add name="AListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="myListener.log"> <filter type="System.Diagnostics.EventTypeFilter" initializeData="Error"/> </add> </sharedListeners> </system.diagnostics> </configuration>
The name of the source of traces emitted by the Windows Communication Foundation's Service Model is System.ServiceModel. Thus, one might configure a trace listener to listen for traces emitted by the Service Model in this way: <configuration> <system.diagnostics> <sources> <source name="System.ServiceModel" switchValue="Verbose" <listeners> <add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="ClientTraces.e2e" /> </listeners> </source> </sources> </system.diagnostics> </configuration>
Traces emitted by the Windows Communication Foundation's own XML serializer, XmlFormatter, originate from a source named System.Runtime.Serialization, whereas traces from XSI have a source with the name System.SecurityAuthorization. Trace sources have a Switch property for filtering traces emanating from that source according to their level of importance. Traces emitted by the Windows Communication Foundation can be filtered by six levels of importance, as shown, in descending order, in Table 12.1. Filtering a source for traces with a given level of importance will exclude traces with a lower level of importance, and include any traces of which the level of importance is the specified level or higher. Table 12.1. Windows Communication Foundation Trace LevelsLevel | Description |
|---|
Critical | Traces of catastrophic errors that cause an application to cease functioning | Error | Traces of exceptions | Warning | Traces of conditions that may subsequently cause an exception, such as a limit having been reached or credentials having been rejected | Information | Traces of milestones significant for monitoring and diagnosis | Verbose | Traces of processing milestones interesting to developers for diagnosis and optimization | ActivityTracing | Traces of activity boundaries |
The Windows Communication Foundation does not emit traces by default. Activating tracing is easily done using the Configuration Editor: From the Diagnostics pane, click on the Tracing button shown in Figure 12.63. Figure 12.63. The Tracing button.  In the Diagnostics Tracing dialog, shown in Figure 12.64, click on the Create button to configure a trace listener. Figure 12.64. The Diagnostics Tracing dialog.  Specify where the tracing information is to be written, as shown in Figure 12.65. Figure 12.65. Specifying a destination for traces.  After traces have been recorded, they can be examined using the Trace Viewer, C:\Program Files\Microsoft SDKs\Windows\v1.0\Bin\SvcTraceViewer.exe. An example of what might be seen is displayed in Figure 12.66. Figure 12.66. Viewing traces. 
The Trace Viewer The Windows Communication Foundation's Trace Viewer has already been introduced. As can be seen in Figure 12.66, the Trace Viewer displays a list of activities in a pane on the left, and all the traces pertaining to a selected activity in the pane on the upper right. The lower-right pane shows the details of a particular trace. As shown in Figure 12.62, the Trace Viewer can also be used to view logs of messages. The most impressive capability of the Trace Viewer, though, is in allowing one to examine the flow of an activity across network nodes. Windows Communication Foundation traces have a globally unique identifier, and whenever a Windows Communication Foundation application is configured to emit traces, the activity identifiers are included in any messages it sends. To see the significance of that, follow these steps: 1. | Open the Trace Viewer, C:\Program Files\Microsoft SDKs\Windows\v1.0\Bin\SvcTraceViewer.exe.
| | | 2. | Choose File, Open from the menus, as shown in Figure 12.67.
Figure 12.67. Opening Traces. 
| | | 3. | In the File Open dialog, select all the trace files in the folder C:\WCFHandsOn\Management\Traces, as shown in Figure 12.68, and click on the Open button.
Figure 12.68. Selecting trace files. 
| | | 4. | Click the OK button on the File Partial Loading dialog shown in Figure 12.69.
Figure 12.69. File Partial Loading dialog. 
| | | 5. | Select an activity from the list in the pane on the left, as shown in Figure 12.70.
Figure 12.70. Selecting an activity. 
| | | 6. | Select the Graph tab, shown in Figure 12.71.
Figure 12.71. The Graph tab. 
|
The Trace Viewer is able to show transfers of activity between the endpoints of a system! That feature allows one to follow an activity from a client to a service and back. For instance, one can select any step in the sequence depicted in the graphical view to see details of the traces emitted in that step in the panes on the right. Performance Counters The Windows Communication Foundation provides a rich variety of performance counters for the monitoring, diagnosis, and optimization of applications. There are performance counters for monitoring services, the individual endpoints of a service, and the individual operations exposed at an endpoint. To examine the performance counters, follow these steps: 1. | Start the Configuration Editor, and choose File, Open, Executable from the menus, and open the assembly C:\WCFHandsOn\Management\TradingRecordingServiceHost\bin\Debug\TradingRecordingServiceHost.exe.
| 2. | Select the Diagnostics tab.
| | | 3. | Check the box labeled Enable Performance Counters, as shown in Figure 12.72.
Figure 12.72. Enabling performance counters. 
| 4. | Choose File, Save from the Configuration Editor menus to save the configuration.
| 5. | Select File, Exit from the menus to close the Configuration Editor.
| 6. | In Visual Studio 2005, in the trading service solution, choose Debug, Start Debugging from the menus.
| 7. | Wait until there is activity in the console window of the trade recording service host.
| | | 8. | Choose Run from the Windows Start menu; then enter
perfmon
and click OK.
| 9. | In the Performance console, right-click on the graph on the right side, and choose Add Counters from the context menu, as shown in Figure 12.73.
Figure 12.73. Adding performance counters to the Performance console. 
| | | 10. | Select ServiceModelService from the Performance object list, as shown in Figure 12.74.
Figure 12.74. Selecting a Windows Communication Foundation performance counter category. 
ServiceModelService is the name of the category of Windows Communication Foundation performance counters at the service level. Note that there are also categories for performance counters at the level of both endpoints and operations. When the ServiceModelService category is selected, the trade recording service shows up in the list of instances on the right, as shown in Figure 12.74, because that is a service for which performance counters have been enabled.
| 11. | Scroll through the extensive list of performance counters in the ServiceModelService category, as shown in Figure 12.75.
Figure 12.75. Examining the Windows Communication Foundation performance counters. 
| | | 12. | Click on the Close button.
| 13. | Choose File, Exit from the Performance Console's menus to close it.
| 14. | In Visual Studio 2005, stop debugging the trading service solution.
|
WMI Provider WMI is Microsoft's implementation of the Web-Based Enterprise Management architecture defined by the Desktop Management Task Force. The purpose of the architecture is to define a unified infrastructure for managing both computer hardware and software. WMI is now built into Windows operating systems, and since its introduction as an add-on for Windows NT version 4.0, not only has it become very familiar to Windows systems administrators, but it also is the foundation for many computer management products. If a piece of software can be examined and manipulated via WMI, system administrators will be able to monitor and adjust it using their preferred computer management tools. The Windows Communication Foundation takes advantage of that situation, incorporating a WMI provider by which Windows Communication Foundation applications become accessible via WMI. Follow these steps to observe its effects: 1. | Start the Configuration Editor; choose File, Open, Executable from the menus, and open the assembly C:\WCFHandsOn\Management\TradingRecordingServiceHost\bin\Debug\TradingRecordingServiceHost.exe.
| 2. | Select the Diagnostics tab.
| 3. | Check the box labeled Enable WMI, as shown in Figure 12.76, to activate the WMI provider.
Figure 12.76. Activating the WMI provider. 
| | | 4. | Choose File, Save from the Configuration Editor menus to save the configuration.
| 5. | Select File, Exit from the menus to close the Configuration Editor.
| 6. | Download the WMI Administrative Tools from http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=6430F853-1120-48DB-8CC5-F2ABDC3ED314.
| 7. | Install the WMI Administrative Tools.
| 8. | In Visual Studio 2005, in the trading service solution, choose Debug, Start Debugging from the menus.
| 9. | Wait until there is activity in the console window of the trade recording service host.
| 10. | Choose WMI Tools, WMI CIM Studio from the Windows Start menu.
| 11. | Enter root\ServiceModel into the Connect to Namespace dialog that appears, as illustrated in Figure 12.77. root\ServiceModel is the namespace of the classes that the Windows Communication Foundation exposes to WMI.
Figure 12.77. Connecting to the root\ServiceModel namespace. 
| | | 12. | Click OK on the WMI CIM Studio Login dialog, depicted in Figure 12.78, to log in as the current user.
Figure 12.78. Logging in to the WMI CIM Studio. 
| 13. | The classes that the Windows Communication Foundation exposes to WMI are enumerated in the pane on the left. Select ServiceEndpoint, as shown in Figure 12.79.
Figure 12.79. Selecting a class. 
| | | 14. | Click on the Instances button, which is the fourth button from the left in the row of buttons at the top of the righthand pane. Information is displayed for each endpoint of any running Windows Communication Foundation application for which the WMI provider is enabled, as shown in Figure 12.80. The WMI CIM Studio is retrieving that information via WMI, which, in turn, retrieves it using the Windows Communication Foundation's WMI provider.
Figure 12.80. Viewing data retrieved via WMI. 
| | | 15. | Select the AppDomainInfo class in the pane on the right. As illustrated in Figure 12.81, one can modify properties of that class, such as the LogMessagesAtServiceLevel property, which configures message logging for a service. This facility allows one to configure properties of services while they are executing. Any modifications made in this way are made to the running instances only and are not persisted in any configuration file. To persist configuration elements in configuration files, use the Configuration Editor.
Figure 12.81. Configuring running services. 
| 16. | Choose File, Close to close the WMI CIM Studio.
| 17. | In Visual Studio 2005, stop debugging the trading service solution.
|
|
