As Scott Colestock announced last week, a new release of QuickCounters was put up for download on the project's CodePlex site. This release includes the following new features for WCF instrumentation:

• Instrumentation of WCF client-side proxies: This part is done by configuring the InstrumentedClientBehavior as an endpoint behavior at the client side. It can be done either through code or through the configuration file. Here's an example of configuring it through code:

ClientProxy client = new ClientProxy(new BasicHttpBinding(), SVC_URI);
// apply behavior
client.Endpoint.Behaviors.Add(new InstrumentedClientBehavior("TestClient"));

• Instrumenting unmatched message handlers in WCF services. I've spoken a bit about this in the past.

QuickCounters, Windows Communication Foundation

One pretty cool feature in WCF Service Contracts are Unmatched Message Handlers, which can catch any call made to an operation with an arbitrary SOAPAction value not already handled explicitly by other operations in the contract. An unmatched message handler is defined by specifying the SOAP Action for the operation with the value "*", like this:

[OperationContract(Action="*")]

Unfortunately, the current release of the WCF support in QuickCounters doesn't quite work with unmatched message handlers. I really want to correct this and support this, so I thought I'd share what the issues are and how I'm working to fix them; I'm hoping you guys like the proposed solutions, and if not, I'm open to hearing proposals . There are two different problems I've identified so far:

Instrumentation

The first problem is with the instrumentation itself. When our IDispatchMessageInspector implementation is created, we build a map of the operations in the service contract matching SOAP Action with the actual operation name. What happens right now is that if you have an unmatched message handler in the contract then an entry gets created in the map matching "*" to the name of the operation. This is not only wrong, it's useless because when the inspector gets the actual request message, it fails to find the operation in the map (since the action will contain an arbitrary value) and will fault.

Fixing this issue is fortunately very easy. What I'm doing right now is that when building the operation map I take note of the unmatched message handler operation, and then when the actual request message is received if the SOAP Action in the message is not found in the operations map, I just use the unmatched message handler operation found before.

Metadata

The second problem is somewhat uglier. The current QuickCounters release has two different ways to generate the QuickCounters configuration XML for a WCF service: one is an external tool (QCFromWsdl.exe) and the other is the built in metadata (<uri>/qc) endpoint.

Both mechanism work internally the same, producing the QC XML from the service's WSDL. The problem here is that an unmatched message handler operation will never show up (for obvious reasons) in the service description (WSDL), so the current tools just leave out that operation and the corresponding <RequestType/> entry is not generated. The big problem with this is that even with the first problem fixed, if the request type is not in the configuration XML, then the corresponding performance counter never gets created and again, we fault at runtime. Not pretty.

Obviously, one could argue that this could be fixed by hand by the developer by manually changing the QC configuration XML, but that's a bad solution and defeats the purpose of generating it automatically. So here's how I'm hoping to fix this in both tools:

1. For the external QCFromWsdl.exe tool, I plan on adding a new command line argument: /umh:<Name> which will make the tool introduce a new <RequestType/> entry with the given name. This does mean you need to feed one extra parameter to the tool and make sure that whatever value you pass matches the actual operation name in the ServiceContract, but there's not much we can do to figure it out on our own just from the WSDL file.
2. For the built-in metadata endpoint, things are a bit different, and I'm hoping here to be able to do the same automatically by figuring out the proper name for the unmatched message handler operation from the internal ContractDescription object. This is a much better solution because it should require no manual intervention from the developer to support.

The Client Side?

The things described above should take care of the server-side issues. I'm still trying to figure out exactly what we'd do on the client side as I haven't looked too deep into the issue yet (although the basic client-side proxy instrumentation support is already done and working on normal operations just fine).

Windows Communication Foundation, WCF, QuickCounters

A while ago I talked a bit about Windows Communication Foundation's IParameterInspector extensibility and how it was affected by One-Way operations on the server and client side. Just so you're aware, the IClientMessageInspector has the same issues as IParameterInspector on the client side; that is, the AfterReceiveReply() method will never be called for OneWay methods.

I'm working currently on implementing client-side proxy instrumentation in WCF for QuickCounters, and to work around this limitation, here's what I'm currently doing:

1. While constructing my IClientMessageInspector implementation, I build a map of operations from the endpoint ContractDescription (which I get from the IEndpointBehavior implementation). Here I take note of which operations are OneWay.
2. When BeforeSendRequest() is called, I check the operations map, and if it is a message for a OneWay operation, then I immediate free the necessary resources, to avoid leaking them because AfterReceiveReply() won't be called.

This does imply that instrumentation for one-way operations on the client side will be a little weaker (certainly more so than for the server side), but it will stll be useful and reduced functionality was expected anyway because the client side has no way to detect faults, for example.

Windows Communication Foundation, WCF, WCF Extensibility, QuickCounters

Scott Colestock broke the news earlier today about his QuickCounters project. QuickCounters is a great library (and associated tools) for instrumenting applications using Windows NT performance counters in a simple way. It not only does the bulk of the work of dealing with the performance counter API (both for deployment as well as runtime), but it also has a simple and easy to use UI Client you can use to read the performance counters for your application.

A while ago I mentioned I was experimenting with creating custom Windows Communication Foundation extensions to instrument WCF services. A little after that, Scott approached me and told me about QuickCounters and I immediately recognized that his stuff was way better than the very basic stuff I had, and agreed to modify my extensions to build on top of QuickCounters. Thanks to the very easy to use API in QC, it was a breeze to do. Scott also allowed me to integrate my extensions into the QuickCounters project in CodePlex, in the QuickCounters.Wcf assembly, so it should be available to anyone wanting to use them.

Instrumenting WCF Services

The WCF extensions are very simple right now. What we have is a custom service behavior which injects an IDispatchMessageInspector, which internally calls the QC API to instrument the service calls. I've mentioned in the past why I switched from my original implementation using an IParameterInspector implementation.

Applying the extensions can be done either through code or through configuration. Code-based instrumentation is done by applying the [InstrumentedService] attribute to your WCF service implementation class, like this:

[InstrumentedService]
public class VoucherService : IVoucherService

If you want to instrument the service through configuration, you can do this like this:

<extensions>

   <behaviorExtensions>

       <add name="instrumentedService" type="QuickCounters.Wcf.Configuration.InstrumentedServiceElement, 

         QuickCounters.Wcf, Version=1.0.0.0, Culture=neutral, PublicKeyToken=401c7ea1618cbd56"

         />

   </behaviorExtensions>

</extensions>

...

<serviceBehaviors>

   <behavior name="ServiceBehaviors" >

       <instrumentedService 

          service="MyService"

          enableHttpGet="true"

          address="qc"

          applicationName="MyApplication"

       />

   </behavior>

</serviceBehaviors>

QC Metadata

If you've read the project documentation, you'll know that besides adding the attribute/behavior in WCF to enable the instrumentation, you also need to configure your performance counters through QuickCounters. For this, you need a simple metadata XML file that tells QuickCounters what your service is called and what types of requests it contains. While the schema is extremely simple, it can be cumbersome to create.

Fortunately, creating the metadata XML is trivial to do using tools. The QuickCounters project offers two alternatives for this: The first one is a standalone command line tool called QCFromWSDL.exe, which will use your service WSDL file and generate the corresponding QC XML file.

The second one, however, is far more interesting, and it's the result of all the work I've talked about before on publishing arbitrary metadata endpoints for a WCF Service. So here's how it works. The QuickCounters.Wcf behavior contains an enableHttpGet boolean property. If it is set to true, and your service is exposed via HTTP, then the behavior will automatically inject a new endpoint at the <service base address>/<address_property_value> URI that can be retrieved using an HTTP GET operation.

So, for example, if your service is published at the http://localhost/VoucherService/VoucherService.svc URL, and the value of the "address" property for your InstrumentedService behavior/attribute is set to the value "qc", this new endpoint will be published at http://localhost/VouchedService/VoucherService.svc/qc.

[Note: All this properties are available both for the code-based attribute as well as the config file tag].

When you navigate to this endpoint using your browser (or the QuickCounters tooling), you'll get an auto-generated QuickCounters XML metadata file you can use right away.

Oh and by the way, the "ApplicationName" and "Service" properties allow you to override the InstrumentedApplication/Name and Component/Name fields in the generated XML.

Future Plans

I hope people find these extensions useful. The QuickCounters library is a great tool that I will be using quite a bit in future projects, and I rather like using it alongside with the WCF extensions over (or rather as a complement to) the built-in performance instrumentation in WCF.

I will also be extending this to support new use cases. In particular, I hope to add a new behavior to instrument client-side proxies, and eventually hope to be able to instrument callback contracts on the server as well. If you find any problems, bugs or have any suggestions, we'd sure appreciate them as we hope to make this as useful and trouble-free as possible! Enjoy!

WCF, QuickCounters, Instrumentation