When building WCF services you'll eventually need to integrate common logic that may be applied across a number of services, contracts, endpoints, or operations. Examples include logging, security, error handling, and message or parameter manipulation. Since this kind of logic cuts across all of these concerns and must often be executed somewhere between the submission of a message from a client to the service, we are presented with an interesting design and programming challenge. Fortunately, WCF provides a feature called Custom Behaviors that lets us inject common and "cross-cutting" logic into the WCF runtime either at the proxy (i.e., the client) or dispatcher (i.e., the service) to achieve such ends.

The WCF Architecture for Extensibility
The WCF architecture is amazingly extensible. Figure 1 provides an overview that we can use to orient ourselves before delving into how the WCF runtime can be extended.

I'll assume that you're familiar with how to write WCF services and consume them from the client, so I won't address the client or service code. The channel stacks are where messages are prepared for transmission across the selected transport on both the client and service sides; this is the layer where your WCF bindings are applied. The middle layer in Figure 1 may be referred to as the Service Model Layer. It's responsible for sending and receiving messages to or from the channels, and invoking the appropriate methods in the client and service side code. This is where custom behaviors can be injected, and is the layer that I'll focus on in this article.

When working with custom behaviors you'll have to become familiar with a set of interface classes in two namespaces. The System.Model.Dispatcher namespace provides interfaces that you can implement on your own custom classes to write "interception logic"; these are the classes where you'll code your common logic. I refer to these as being interceptors because when they're loaded they'll intercept the normal flow of execution on either the proxy or dispatcher side to invoke your custom logic at pre-designated times. Figure 2 illustrates the sequence in which classes that implement these interfaces will be called on in the proxy and dispatcher pipelines, and Table 1 lists a few sample scenarios where you might want to use these interfaces.

The second namespace you'll need to become aware of is System.ServiceModel.Description. This namespace includes interfaces that, when implemented on your custom classes, assist in the loading of interceptors into various collections so their logic can be executed as part of the WCF runtime. Classes that implement these interfaces must be added into Behaviors collections prior to opening either the ServiceHost on the service side or the ChannelFactory on the client side. These collections are found in an in-memory representation of the entire service known as the Description Tree. The ServiceDescription class, pictured as the root of the hierarchy in Figure 3, provides access to this tree and is constructed at runtime on the dispatcher side. The same structure is available on the proxy side; the key difference is that the tree created there starts with the ServiceEndpoint class.

In Figure 3 you can infer that the interceptors (see Table 1) loaded by behaviors are applicable across several scopes. If, for example, we add a class that implements IServiceBehavior at the ServiceDescription level then the interceptors added via that behavior might apply to the service and all of its endpoints, contracts, and operations. If we add an IEndpointBehavior to a ServiceEndpoint then the interception logic injected by that behavior could apply not only to the endpoint, but also to its contracts and their operations. When IContractBehaviors are added to a ContractDescription then interception may occur for that contract and its operations. Finally, individual operations can be targeted for interception when IOperationBehaviors are added at the OperationDescription level.

One generally has three options to choose from when considering how to add behaviors to the description tree. You may add these behaviors programmatically before executing ServiceHost.Open or ChannelFactory.Open, you may use attributes, or you may opt to use configuration files. This article focuses on the last two approaches. Table 2 summarizes how classes that implement these interfaces can be added to the description tree, and it also shows where these interfaces can be applied.

If you choose to use attributes or configuration files to add behavior classes to the description tree, then the WCF runtime will detect these directives just before the ServiceHost or ChannelFactory is actually opened, and will load the corresponding classes into either the dispatcher or proxy trees respectively.

At this point you may be wondering when you should choose to add a behavior through configuration files, attributes, or programmatic means. Here are a few rules-of-thumb I would suggest. You might choose configuration files when the interceptors to be added are optional and you want the flexibility to add or remove them after the service or corresponding proxies have been deployed. Attributes should be used when you want to inject an interceptor. These types of interceptors might be required logic that should never be removed after deployment. Lastly, you might consider adding behaviors and their corresponding interceptors programmatically when you need to optionally load them depending on some conditional logic that is evaluated at runtime.

Now that we've covered the key architectural aspects of WCF that allow for the injection of interception logic through custom behaviors, let's dig into some code.

How To Log Messages Received at the Service
In this section I'll show you how to use a Message Inspector (IDispatchMessageInspector) and a configured Service Behavior (IServiceBehavior) to create a common "cross-cutting" behavior that logs messages. The service in this example is hosted in IIS, so you won't see any calls to ServiceHost. Additionally, while we could implement these interfaces on separate classes, I've chosen to implement both the interceptor and behavior interfaces on the same class. Such an approach may or may not make sense for your particular needs. You may, for example, want to implement interceptors in separate classes so your behavior class can load more than one interceptor.

Before I go any further I should also point out that the following example is primarily intended to hint at the possibilities for using message inspectors. Regarding the specific need to log messages, we could also use the WCF trace facility enabled via the MessageLoggingElement class in the System.ServiceModel.Configuration namespace. With that approach, you can alter a configuration setting in your Web or app config file and view the logged messages via the ServiceTraceViewer.exe tool. The following approach essentially captures the same information, but would give you more control over how the intercepted request message might be handled. For example, you could choose to send all outputs from a Web farm to one central location. Now that I've gotten that out of the way, let's look at some code.

In Listing 1 you'll see a partial listing for a class named InsertLogging that inherits from BehaviorExtensionElement. This class also implements the IDispatchMessageInspector and IServiceBehavior interfaces.

The most appropriate interception interface to use when you need to modify, capture, or inspect messages on the service side is IDispatchMessageInspector. With this interface we can add our common logic into the AfterReceiveRequest and BeforeSendReply methods. The former is used to intercept messages and process them after they've been received from the channel and before they're sent on to the service code. The latter is used to process reply messages prior to sending them back to the clients. In Listing 1 you can see that I'm using Microsoft's Enterprise Library Logging Application Block to write the entire request message to some location. You can configure the Logging Block to write such entries to the event log, a database, a message queue, a text file, or other locations. Let's move on to see how this interception logic is loaded.

Listing 2 shows how the IServiceBehavior interface is implemented on the InsertLogging class. Here you can see that the only method into which I have added code is ApplyDispatchBehavior; the remaining two methods, Validate and AddBindingParameters, aren't relevant to this topic.

In Listing 2 you'll see that I iterate through each of the ChannelDispatchers associated with the ServiceHost, and then loop through all of the EndpointDispatchers that are found on each ChannelDispatcher. From this you can surmise that a service has one or many channel dispatchers, and each channel dispatcher could have one or many endpoint dispatchers. Since I want to intercept all messages flowing into each and every operation that a service exposes on each of its endpoints, I can add a reference to my interceptor at this point. You can see that after a reference to an EndpointDispatcher is acquired, a reference to the IDispatchMessageInspector class (i.e., the InsertLogging class) is added to endpoint dispatcher's MessageInspectors collection.