1. Windows Communication
Foundation (WCF) Extensions

2. 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)

3. 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.

4. WCF Runtime Architecture diagram

5. 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.

6. Proxy (Client) Extensions diagram

7. 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.

8. Dispatcher (Service) Extensions diagram

9. 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.

10. 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 Called to perform serialization
IClientFormatter and deserialization.
Message Inspection IDispatchMessageInspector Called before send or after
IClientMessageInspector receive to inspect and replace
message contents.
Operation Selection IDispatchOperationSelector Called to select the operation to
IClientOperationSelector invoke for the given message.
Operation Invoker IOperationInvoker Called to invoke the operation.

11. 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.

12. Behavior Interface Methods
Method Description
Validate 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.

13. 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

14. 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.

15. 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.

16. 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.

17. Adding Behaviors to the Runtime

18. 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());

19. 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.

20. 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).

21. 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.

22. 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>

23. Behavior Configuration Options
Behavior Type Configuration Options
Attribute Configuration Explicit
Service X X X
Endpoint X X
Contract X X
Operation X X