Windows Communication Foundation (WCF) Extensions

WCF Extensibility

• Windows Communication Foundation (WCF) provides numerous extensibility points that allow developers to customize the runtime behavior for service dispatching and client proxy invocation.

• There are countless extensibility points found throughout the WCF channel layer (basically the binding).

• WCF also provides a higher-level runtime that sits on top of the channel layer, targeted more at the application developer.

• Dispatcher (within the context of a service host)

• The proxy (within the context of a client)

WCF Runtime Architecture

• The higher-level runtime consists primarily of two components, the dispatcher/proxy combination serves to translate between WCF Message objects and .NET method calls.

• These components follow a well-defined sequence of steps to perform this process, and at each step along the way they provide extensibility points to implement a wide variety of custom behaviors including:

• Message or parameter validation, message logging, message transformations, custom serialization/deserialization formats, output caching, object pooling, error handling, and authorization, etc.

WCF Runtime Architecture diagram

Proxy (Client) Extensions

• The main responsibility of the proxy is to transform the caller-supplied objects (parameters) into a WCF Message object, which can then be supplied to the underlying channel stack for transmission on the wire.

1.Parameter Inspection: The first extensibility point available to you during this process allows you to perform custom parameter inspection.

2.Message Formatting: Next, the proxy leverages a serializer to transform the supplied parameters into a WCF Message object.

3.Message Inspection: Once the proxy has produced a Message object, it makes use of a final extensibility point for inspecting the resulting Message object before it's submitted to the channel stack.

Proxy (Client) Extensions diagram

Dispatcher (Service) Extensions

1.Message Inspection: The first extensibility point encountered is message inspection.

2.Operation Selector: Then the dispatcher must select an operation to invoke before it can continue—there's an extensibility point here for overriding the default operation selection behavior.

3.Message Formatting: Once the target operation has been identified, the dispatcher deserializes the message into objects that can be supplied as parameters when invoking the target method. At this point the dispatcher provides extensibility points for message formatting.

4.Parameter Inspection.

5.Operation Invoker: The final step for the dispatcher is to invoke the target method supplying the prepared parameters. You can even override this step by providing a custom operation invoker object.

Dispatcher (Service) Extensions diagram

Implementing Custom Extensions

• Each of the extensibility points described above is modeled by a .NET interface definition.

• Note that in some cases the same logical extension type requires a different interface between the dispatcher and proxy sides.

Dispatcher/Proxy Extension Summary

Stage Interceptor Interface

Description

Parameter Inspection IParameterInspector Called before and after invocation to inspect and modify parameter values.

Message Formatting IDispatchMessageFormatter IClientFormatter

Called to perform serialization and deserialization.

Message Inspection IDispatchMessageInspector IClientMessageInspector

Called before send or after receive to inspect and replace message contents.

Operation Selection IDispatchOperationSelector IClientOperationSelector

Called to select the operation to invoke for the given message.

Operation Invoker IOperationInvoker Called to invoke the operation.

Applying Custom Extensions with Behaviors

• A behavior is a special type of class that extends runtime behavior during the ServiceHost/ChannelFactory initialization process. There are four types of behaviors: service, endpoint, contract, and operation. Each type allows you to apply extensions at different scopes.

• Each type of behavior is also modeled by a different interface definition, but they all share the same set of methods

• One exception is that IServiceBehavior doesn't have an ApplyClientBehavior method because service behaviors can't be applied to clients.

Behavior Interface Methods

Method DescriptionValidate Called just before the runtime is built—

allows you to perform custom validation on the service description.

AddBindingParameters Called in the first step of building the runtime, before the underlying channel is constructed—allows you to add parameters to influence the underlying channel stack.

ApplyClientBehavior Allows behavior to inject proxy (client) extensions. Note that this method is not present on IServiceBehavior.

ApplyDispatchBehavior Allows behavior to inject dispatcher extensions.

Types of behaviors table

Scope Interface Potential Impact

Service Endpoint Contract Operation

Service IServiceBehavior X X X X

Endpoint IEndpointBehavior

X X X

Contract IContractBehavior

X X

Operation IOperationBehavior

X

Types of behaviors description

• Service behaviors are used for applying extensions across the entire service; you can apply them to the service itself or to specific endpoints, contracts, and operations.

• Endpoint behaviors, on the other hand, are used to apply extensions to a particular endpoint (or perhaps to the endpoint's contract or operations).

• Contract and operation behaviors are used to apply extensions to contracts and operations.

• Endpoint, contract, and operation behaviors can be applied to both services and clients, but service behaviors can only be applied to services.

Types of behaviors description (continue)

• Although the methods are the same for each behavior interface, the signatures are indeed different.

• They are tailored to provide the appropriate runtime objects for that particular scope.

• ApplyDispatchBehavior and ApplyClientBehavior are the core methods that allow you to apply custom extensions to the dispatcher and proxy, respectively.

• When the runtime calls these methods, it provides the DispatchRuntime, DispatchOperation, ClientRuntime, and ClientOperation objects to you for injecting your extensions.

Adding Behaviors to the Runtime

• When you construct a ServiceHost or client-side ChannelFactory, the runtime reflects over the service types, reads the configuration file, and starts building an in-memory description of the service.

• The ServiceDescription contains a full description of the service and each endpoint (ServiceEndpoint), including contracts (ContractDescription) and operations (OperationDescription).

• ServiceDescription provides a Behaviors property (a collection of type IServiceBehavior) that models a collection of service behaviors.

• EndpointDescription also has a Behaviors property (a collection of type IEndpointBehavior) that models the individual endpoint behaviors.

• Likewise, ContractDescription and OperationDescription each have an appropriate Behaviors property.

Adding Behaviors to the Runtime

Adding Behaviors to the Runtime sample

1- Service

ServiceHost host = new ServiceHost(typeof(ZipCodeService)); foreach (ServiceEndpoint se in host.Description.Endpoints)

se.Behaviors.Add(new ConsoleMessageTracing());

2- Client

ZipCodeServiceClient client = new ZipCodeServiceClient();client.ChannelFactory.Endpoint.Behaviors.Add( new

ConsoleMessageTracing());

Adding Behaviors with Attributes

• During the ServiceHost/ChannelFactory construction process, the runtime reflects over the service types and configuration file and automatically adds any behaviors it finds to the appropriate behavior collections in the ServiceDescription.

• The runtime first looks for .NET attributes on your service code that derive from one of the behavior interfaces. Whenever the runtime finds one of these attributes, it automatically adds that attribute to the appropriate collection.

Adding Behaviors with Attributes sample

[ServiceContract] public interface IZipCodeService {

[ZipCodeCaching] [ZipCodeValidation] [OperationContract] string Lookup(string zipcode);

}

[ConsoleMessageTracing] public class ZipCodeService : IZipCodeService { ... }

When I defined these behavior classes, make sure to derive them from

Attribute (in addition to IServiceBehavior and IOperationBehavior).

Adding Behaviors with Configuration

• After the reflection process is complete, the runtime also inspects the application configuration file and loads the information found in the <system.serviceModel>

• WCF provides a <behaviors> section for configuring service and endpoint behaviors. Any service/endpoint behaviors found in this section are automatically added to the ServiceDescription.

• In order to place custom behaviors within this configuration section, you must first write a class that derives from BehaviorElementExtension.

• Then you must register your BehaviorExtensionElement in the <extensions> section and map it to an element name. With that in place, you can use your registered element name within the <behaviors> section in order to configure the behavior.

Adding Behaviors with Configuration sample<configuration>

<system.serviceModel> <services> <service name="ZipCodeServiceLibrary.ZipCodeService"

behaviorConfiguration="Default"> <endpoint binding="basicHttpBinding"

contract="ZipCodeServiceLibrary.IZipCodeService"/> </service> </services> <behaviors>

<serviceBehaviors> <behavior name="Default"> <serviceMetadata httpGetEnabled="true"/> <consoleMessageTracing/> </behavior>

</serviceBehaviors> </behaviors>

<extensions> <behaviorExtensions>

<add name="consoleMessageTracing" type="Extensions. ConsoleMessageTracingElement, Extensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/> </behaviorExtensions>

</extensions> </system.serviceModel>

</configuration>

Behavior Configuration Options

Behavior Type Configuration Options

Attribute Configuration Explicit

Service X X X

Endpoint X X

Contract X X

Operation X X