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:
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.
There are three public implementations for the IExtension<T> interface in WCF:
There is one public implementation of IExtensionCollection<T> 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.
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.
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.
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.
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.
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.
Now the code which creates the proxy needs to be updated to add the extension to it.
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.
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.
With all pieces in place, we can now change our main method to create many proxies and test the system.
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.
We’ll go back to the WCF runtime, with the instance context provider.
[Code in this post]
[Back to the index]