WCF Extensibility – IExtension and IExtensibleObject

Article
01/30/2012

This post is part of a series about WCF extensibility points. For a list of all previous posts and planned future ones, go to the index page .

And we’re back from the short detour to the world of WCF RIA Services, and the long “mini-series” about transport channels. We’ll go back to the WCF runtime to look at the extensible objects in WCF. Extensible objects are some objects in the WCF runtime which can be extended using the IExtensibleObject<T> pattern. The idea is that there are a few objects in WCF (the extensible objects) to which one can add extensions to it, and those extensions can, well, extend their functionality. That’s the “official” story, but extensible objects are simply a few classes in WCF which have a list where we can add the extensions, nothing fancier than that.

There are four extensible objects in WCF:

ServiceHostBase, the base class used for hosting WCF services
InstanceContext, the class which represents the running service, connecting the service class instance with the WCF runtime
OperationContext, the class which represents the operation information gathered by the runtime and passed (as a thread-local static variable)
IContextChannel, an interface which allows for the inspection of channels and proxies built by the WCF runtime.

The advantage of using the extensions is that those will have the same life time of the object to which they are attached. This way, one can, for example, add an extension to a context channel and have that extension flow along with the channel through the WCF pipeline, and somewhere in the stack retrieve that information. This will be shown in the example in this post. The example for the next post (on instance context providers) will also use an extension to track state for that.

Public implementations in WCF

There are three public implementations for the IExtension<T> interface in WCF:

System.ServiceModel.Activation.VirtualPathExtension: an extension for the ServiceHostBase class, which allows hosted applications to get data about the application path, site name and virtual path (the first two are new in 4.0; the last property is there since the original version).
System.ServiceModel.Description.ServiceMetadataExtension: another extension for the ServiceHostBase class, contains a property which contains the metadata for the service. This class also provides the implementation for the metadata publishing protocols, and is added to the service host when the ServiceMetadataBehavior is applied to it.
System.ServiceModel.Web.WebOperationContext (new in 3.5): an extension for the OperationContext, used to extend that context class with properties and methods to make the creation of WCF Web HTTP services easier.

There is one public implementation of IExtensionCollection<T> in WCF:

System.ServiceModel.ExtensionCollection<T>: a thread-safe implementation of the extension collection, which is used internally by the extensible objects in WCF.

As I mentioned before, there are four base public implementations of IExtensibleObject<T> in WCF: ServiceHostBase, InstanceContext, OperationContext and IContextChannel. Notice that all the classes (and interfaces) derived from those ones also are extensible objects themselves, such as ServiceHost / WebServiceHost, IClientChannel / IServiceChannel, and so on.

Interface definitions

public interface IExtension<T> where T : IExtensibleObject<T>
{
void Attach(T owner);
void Detach(T owner);
}
public interface IExtensibleObject<T> where T : IExtensibleObject<T>
{
IExtensionCollection<T> Extensions { get; }
}
public interface IExtensionCollection<T> : ICollection<IExtension<T>>, IEnumerable<IExtension<T>>, IEnumerable
where T : IExtensibleObject<T>
{
E Find<E>();
Collection<E> FindAll<E>();
}

The three interfaces which enable the extensible object pattern in WCF are quite simple. The extensible objects implement IExtensibleObject<T>, which exposes a collection of the extensions attached to it on its Extensions property, of type IExtensionCollection<T>. That interface type defines the methods Find<E> and FindAll<E> to return either an extension of a specific type or all extensions of that type which are stored in the object’s extensions.

Finally, IExtension<T> is the interface which the extensions need to implement. It defines two methods, Attach and Detach, that are called when the extension is added to or removed from an extensible object, but they’re actually not used that often (they can be used to do some validation, which is the case in the ServiceMetadataExtension, which checks that the object is only added to one service host).

One interesting thing to notice are all the interfaces have restrictions on them, but that’s just to guarantee that an extension for a certain extensible objects can only be used for that object. This way, if a class implements IExtension<InstanceContext> it cannot be added to the operation context extension list.

How to add an extension object

Extension objects can only be added via code, by accessing the Extensions property in any of the extensible objects in WCF. There isn’t any place where an extension is typically added, I’ve seen examples of them being added in behaviors (such as the ServiceMetadataExtension), in thread-local static properties (as is the case with the WebOperationContext), or in the normal flow of the code, as will be shown in the example below.

One more interesting thing to point is that the extensible object pattern doesn’t need to be restricted to WCF. This blog post shows how one can use the same pattern (and objects) in a WPF application to make controls more extensible. Not really in the topic for this series, but an interesting read nonetheless.

Real world scenario: flowing state through client proxies

This example came from Stack Overflow: the user wanted to get the information about the client binding on a channel returned by [Duplex]ChannelFactory. Those channels / proxies are normally cast as the service contract interface, but can also be cast to IClientChannel, which has a lot of information about the channel (local and remote address, sessions, and so on), but it didn’t have the information needed.

Well, the client channel itself doesn’t have it, but it’s one of the extensible objects in WCF so if we need that information later, we can add the information as we’re creating the channel, stuff it in its extension bag, then retrieve it when necessary. Notice that this can be used not only when you have an instance of the channel returned by the channel factory, but also in inspectors or other extensibility points which take the client channel as a parameter – in the example below I’ll add one of those as well.

So, let’s start with the usual calculator (simple enough not to take more than a second of attention out of the main topic). We also have a service which implement this contract with the expected operations, so I’ll skip this for now.

[ServiceContract]
public interface ICalculator
{
[OperationContract]
double Add(double x, double y);
[OperationContract]
double Subtract(double x, double y);
[OperationContract]
double Multiply(double x, double y);
[OperationContract]
double Divide(double x, double y);
}

Now we can start using it as in the code shown below. One can ask that, since the binding is on scope in that code, why not use it directly. That’s fair, but imagine that the function which will use the proxy is in a separate library, and it should support channels from different kinds of endpoints. That’s the behavior which I imagine was expected in the question from SO. To simulate this, we’re just passing the proxy to a separate method, as shown below.

ServiceHost host = new ServiceHost(typeof(CalculatorService), new Uri(baseAddressHttp), new Uri(baseAddressPipe));
host.AddServiceEndpoint(typeof(ICalculator), new BasicHttpBinding(), "");
host.AddServiceEndpoint(typeof(ICalculator), new NetNamedPipeBinding(NetNamedPipeSecurityMode.None), "");
host.Open();
Console.WriteLine("Host opened");
ChannelFactory<ICalculator> factory = new ChannelFactory<ICalculator>(new BasicHttpBinding(), new EndpointAddress(baseAddressHttp));
ICalculator proxy = factory.CreateChannel();
DoCalculations(proxy);
((IClientChannel)proxy).Close();
factory.Close();
host.Close();

The code shown above, however, doesn’t pass any information to the method, so we’ll need to update it a little to do that. But before continuing, it’s time for the usual disclaimer. This is a sample for illustrating the topic of this post, this is not production-ready code. I tested it for a few contracts and it worked, but I cannot guarantee that it will work for all scenarios (please let me know if you find a bug or something missing). Error checking is also kept to a minimum, to focus on the issue in this post. Back to the sample, let’s define our extension. We can define a few properties which will be used later on. The binding, as in the original SO question, and I’ll also add another property which will be checked in a message inspector down in the pipeline.

class MyChannelExtension : IExtension<IContextChannel>
{
public Binding Binding { get; set; }
public bool IntroduceErrors { get; set; }
// Not used in this scenario
public void Attach(IContextChannel owner) { }
public void Detach(IContextChannel owner) { }
}

Now the code which creates the proxy needs to be updated to add the extension to it.

static ICalculator CreateProxy(bool useHttp, bool addErrors = false)
{
Binding binding = useHttp ?
(Binding)new BasicHttpBinding() :
(Binding)new NetNamedPipeBinding(NetNamedPipeSecurityMode.None);
string address = useHttp ? baseAddressHttp : baseAddressPipe;
ChannelFactory<ICalculator> factory = new ChannelFactory<ICalculator>(binding, new EndpointAddress(address));
factory.Endpoint.Behaviors.Add(new MyInspector());
ICalculator result = factory.CreateChannel();
((IClientChannel)result).Closed += delegate { factory.Close(); };
((IClientChannel)result).Extensions.Add(new MyChannelExtension { Binding = binding, IntroduceErrors = addErrors });
return result;
}

Now we can go into the DoCalculations method. Nothing interesting here, but it shows that we can query the extensions in the proxy for the channel extension, and if that extension is there, it can get the information from the extension.

static void DoCalculations(ICalculator proxy)
{
MyChannelExtension extension = ((IContextChannel)proxy).Extensions.Find<MyChannelExtension>();
if (extension != null)
{
if (extension.Binding != null)
{
Console.WriteLine("Sending requests over {0}", extension.Binding.Scheme);
}
if (extension.IntroduceErrors)
{
Console.WriteLine("Errors will be introduced in the request");
}
}
// Call the Add service operation.
double value1 = 100.00D;
double value2 = 15.99D;
double result = proxy.Add(value1, value2);
Console.WriteLine("Add({0},{1}) = {2}", value1, value2, result);
// Call the Subtract service operation.
value1 = 145.00D;
value2 = 76.54D;
result = proxy.Subtract(value1, value2);
Console.WriteLine("Subtract({0},{1}) = {2}", value1, value2, result);
// Call the Multiply service operation.
value1 = 9.00D;
value2 = 81.25D;
result = proxy.Multiply(value1, value2);
Console.WriteLine("Multiply({0},{1}) = {2}", value1, value2, result);
// Call the Divide service operation.
value1 = 22.00D;
value2 = 7.00D;
result = proxy.Divide(value1, value2);
Console.WriteLine("Divide({0},{1}) = {2}", value1, value2, result);
Console.WriteLine();
}

Now let’s go to a client message inspector, which was added in the CreateProxy method, to see how the proxy can get information from the client. Again, this is a simple example, where I’m creating the inspector myself (so I could have passed the flag used in the inspector to its constructor directly), but you can think of a general inspector which is added to all applications in the system or one which is added by a behavior configured via configuration, so this is a simple way to pass data along the pipeline.

public void AfterReceiveReply(ref Message reply, object correlationState)
{
}
public object BeforeSendRequest(ref Message request, IClientChannel channel)
{
MyChannelExtension extension = channel.Extensions.Find<MyChannelExtension>();
if (extension != null && extension.IntroduceErrors)
{
this.IntroduceErrorToMessage(ref request);
}
return null;
}

With all pieces in place, we can now change our main method to create many proxies and test the system.

static void Main(string[] args)
{
ServiceHost host = new ServiceHost(typeof(CalculatorService), new Uri(baseAddressHttp), new Uri(baseAddressPipe));
host.AddServiceEndpoint(typeof(ICalculator), new BasicHttpBinding(), "");
host.AddServiceEndpoint(typeof(ICalculator), new NetNamedPipeBinding(NetNamedPipeSecurityMode.None), "");
host.Open();
Console.WriteLine("Host opened");
ICalculator httpProxy1 = CreateProxy(useHttp: true, addErrors: false);
DoCalculations(httpProxy1);
ICalculator httpProxy2 = CreateProxy(useHttp: true, addErrors: true);
DoCalculations(httpProxy2);
ICalculator netPipeProxy1 = CreateProxy(useHttp: false, addErrors: false);
DoCalculations(netPipeProxy1);
((IClientChannel)httpProxy1).Close();
((IClientChannel)httpProxy2).Close();
((IClientChannel)netPipeProxy1).Close();
host.Close();
}

That’s it. This example showed how we can use an extension to, well, extend the client channel with more information which can be used when the channel is available.

Coming up

We’ll go back to the WCF runtime, with the instance context provider.

[Code in this post]

[Back to the index]

Share via