An instance provider is what WCF uses to create a service object, so it makes sense to start there.  The IInstanceProvider interface defines two methods: GetInstance() (+1 overload) and ReleaseInstance(). We need to implement these so that our instance provider is MEF-aware and delegates the creation of the service object to MEF allowing it to satisfy all of the object’s import requirements through composition. Let’s begin then, by creating a new ComposedInstanceProvider class:

public class ComposedInstanceProvider : IInstanceProvider
{
   private readonly Type _serviceType;
   private readonly CompositionContainer _container;

   public ComposedInstanceProvider(Type serviceType, CompositionContainer container)
   {
      _serviceType = serviceType;
      _container = container;
   }

   public object GetInstance(InstanceContext context)
   {
      Export export = GetServiceExport();

      if (export == null)
         throw new InvalidOperationException();

      return export.Value;
   }

   public object GetInstance(InstanceContext context, Message message)
   {
      return GetInstance(context);
   }

   public void ReleaseInstance(InstanceContext context, object instance)
   {
      var disposable = instance as IDisposable;

      if (disposable != null)
         disposeable.Dispose();
   }

   private Export GetServiceExport()
   {
      var importDefinition
      = new ContractBasedImportDefinition(AttributedModelServices.GetContractName(_serviceType),
                                          AttributedModelServices.GetTypeIdentity(_serviceType),
                                          null,
                                          ImportCardinality.ZeroOrMore,
                                          true,
                                          true,
                                          CreationPolicy.Any);

      return _container.GetExports(importDefinition).FirstOrDefault();
   }
}

This is essentially the core to making WCF service compose-able. The GetInstance() implementations that are invoked by WCF simply use a supplied CompositionContainer object to get an implementation of the service type. So far so good. However, we need to plug our custom instance provider into WCF, and that means implementing a few other WCF pieces. First we need a custom service behaviour (implementing IServiceBehavior), that allows us to extend the service with our compose-able behaviour. It does this by replacing the default instance provider with a ComposedInstanceProvider. I tend to think of service behaviours as aspects or cross-cutting features that are applied across the entire service, and compose-ability fits in nicely with this metaphor. We’ll also need a custom service host (a class derived from ServiceHost), that will apply the service behaviour to the service that it is hosting.

If we want to use .svc files to host our services in IIS, then we will also need to implement a custom service host factory (a class derived from ServiceHostFactory) which is responsible for creating instances of our derived ServiceHost class. Since we started in the middle of the stack with our custom instance provider, let’s move up a level and implement the custom service behaviour:

public class ComposedServiceBehavior : IServiceBehavior
{
   private readonly IInstanceProvider _instanceProvider;

   public ComposedServiceBehavior(Type serviceType, CompositionContainer container)
   {
      _instanceProvider = new ComposedInstanceProvider(serviceType, container);
   }

   public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
   { }

   public void AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase,
                                    Collection<ServiceEndpoint> endpoints, BindingParameterCollection bindingParameters)
   { }

   public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
   {
      foreach (ChannelDispatcherBase dispatcher in serviceHostBase.ChannelDispatchers)
      {
         var channelDispatcher = dispatcher as ChannelDispatcher;

         if (channelDispatcher == null)
            continue;

         foreach (EndpointDispatcher endpointDispatcher in channelDispatcher.Endpoints)
         {
            endpointDispatcher.DispatchRuntime.InstanceProvider = _instanceProvider;
         }
      }
   }
}

The behaviour implementation is again very simple. It creates a new ComposedInstanceProvider object using the supplied service type and CompositionContainer objects, and then replaces it with the default one in the endpoint dispatcher. Whenever WCF requires a service object to be created, it will now be using our own MEF-aware instance provider.

Next, we need a custom service host that will apply our behaviour. Again, this class is very simple:

public class ComposedServiceHost : ServiceHost
{
   private readonly Type _serviceType;
   private readonly CompositionContainer _container;

   public ComposedServiceHost(Type serviceType, CompositionContainer container, params Uri[] baseAddresses)
      : base(serviceType, baseAddresses)
   {
      _serviceType = serviceType;
      _container = container;
   }

   protected override void OnOpening()
   {
      if (Description.Behaviors.Find<ComposedServiceBehavior>() == null)
      {
         Description.Behaviors.Add(new ComposedServiceBehavior(_serviceType, _container));
      }

      base.OnOpening();
   }
}

Our custom service host simply adds our ComposedServiceBehavior implementation to the service description if it has not already been done so. If you’re self-hosting your services in a Windows Service for example, then that’s all you need to do. Instead of creating a ServiceHost object when your application starts, you simply create a new ComposedServiceHost and pass in the CompositionContainer that it should use to satisfy the imports.

If you use .svc files to host your WCF services in IIS, then you’ll need to use a custom service host factory that knows how to create ComposedServiceHost objects. Once you’ve implemented the custom service host factory as shown below:

public class ComposedServiceHostFactory : ServiceHostFactory
{
   protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
   {
      CompositionContainer container = ComposedServiceHosts.CompositionContainer;

      if (container == null)
         throw new InvalidOperationException();

      return CreateComposedServiceHost(serviceType, baseAddresses, container);
   }

   protected virtual ComposedServiceHost CreateComposedServiceHost(Type serviceType, Uri[] baseAddresses, CompositionContainer container)
   {
      return new ComposedServiceHost(serviceType, container, baseAddresses);
   }
}

you can then modify the .svc file so that it uses it in the Factory attribute:

<% @ServiceHost Service="FooService" Factory="ComposedServiceHostFactory" %>

The factory is created by the WCF hosting runtime, which prevents us from passing in the CompositionContainer we need to compose our WCF services. To get around this, we’ll need a utility that provides this for us when the WCF runtime invokes the factory. You can see being used in the overridden CreateServiceHost() method above where it obtains the container from a ComposedServiceHosts utility class.

public static class ComposedServiceHosts
{
   private static CompositionContainer _container = null;

   internal static CompositionContainer CompositionContainer
   {
      get { return _container; }
   }

   public static void SetCompositionContainer(CompositionContainer container)
   {
      _container = container;
   }
}

We can then create our CompositionContainer in the Global.asax file (as we would normally do for any web-based project), and set-up the ComposedServiceHosts utility class so that it is used for all our composed service operations:

protected void Application_Start(object sender, EventArgs e)
{
   var catalogs
   = new AggregateCatalog(new[]
     {
        new AssemblyCatalog(typeof(FooService).Assembly),
        new AssemblyCatalog(GetType().Assembly)
     });

   ComposedServiceHosts.SetCompositionContainer(new CompositionContainer(catalogs));
}

When used in web-projects (either web-forms or MVC based), we will sometimes have the requirement to scope exported parts based on either the lifetime of a HTTP request, or an associated session. For example, we would like to be able to write code along the lines of this:

[Export(typeof(IFoo))]
[WebPartCreationPolicy(WebCreationPolicy.Session)]
public class SessionFoo : IFoo
{ }

Obviously the [WebPartCreationPolicy] attribute is something new, and in this example we’re aiming for one SessionFoo object to exist for the lifetime of the HTTP session. Likewise, we could use the value WebCreationPolicy.Request to indicate that an export exists for the lifetime of the current HTTP request. The good news is that MEF is highly extensible, and our web-scoped lifetime requirements can be easily implemented as a new catalog which simply transforms the part definitions found in another catalog through composition.

The code for this post can be found on my private fork of the MefContrib project (found at GitHub). In this fork I’ve introduced a new project called MefContrib.Web to support these (and other) web-specifc features.

Implementing a new WebScopedCatalog

Once the exports have been marked up with a [WebPartCreationPolicy] attribute, we need to do three things:

1. Use an existing catalog to include the exported parts in the eventual CompositionContainer. For example, we could use a DirectoryCatalog or an AssemblyCatalog
2. Pass the catalog into a newly created WebScopedCatalog
3. Pass the WebScopedCatalog into our CompositionContainer

In web projects, we typically setup our CompositionContainer in the Global.asax. In the following example, we’ll use MVC:

public class MvcApplication : HttpApplication
{
    protected void Application_Start()
    {
       AreaRegistration.RegisterAllAreas();

        RegisterRoutes(RouteTable.Routes);

        var catalog = new WebScopedCatalog(new DirectoryCatalog(Server.MapPath("~\\bin")));
        var container = new CompositionContainer(catalog);

        ControllerBuilder.Current.SetControllerFactory(new CompositionControllerFactory(container));
    }
}

It’s important to note that you can also pass an AggregateCatalog into a new WebScopedCatalog allowing exports from a collection of underlying catalogs to be adorned with web-scoped lifetime semantics. In the above example we then give the CompositionContainer object to an MVC controller factory that knows how to create composed controllers. The WebScopedCatalog queries the parts of the underlying catalog and for any part definition which has a WebCreationPolicy metadata value, creates a new WebScopedComposablePartDefinition object in its place. It then stores a list of these parts unioned with those that didn’t so that it can return them when queried by MEF. Basically it transforms the underlying list of composable part definitions so that where one has a web-creation policy, the ComposablePartDefinition is replaced with the new WebScopedComposablePartDefinition object instead:

public class WebScopedCatalog : ComposablePartCatalog
{
    private readonly IQueryable<ComposablePartDefinition> _parts;

    public WebScopedCatalog(ComposablePartCatalog partCatalog)
    {
        if (partCatalog == null)
            throw new ArgumentNullException("partCatalog");

        var webScopedParts
            = from part in partCatalog.Parts
                let exportDef = part.ExportDefinitions.First()
              where exportDef.Metadata.ContainsKey("WebCreationPolicy")
              select part;

        var nonScopedParts = partCatalog.Parts.Except(webScopedParts);

        _parts
            = webScopedParts.Select(p => new WebScopedComposablePartDefinition(p))
                .Union(nonScopedParts)
                .AsQueryable();
    }

    public override IQueryable<ComposablePartDefinition> Parts
    {
        get { return _parts; }
    }
}

When MEF requires access to the part, the WebScopedComposablePartDefinition object simply inspects the value of the WebCreationPolicy metadata value, and then returns either a WebRequestScopedComposablePart or a WebSessionScopedComposablePart object based on that value:

public class WebScopedComposablePartDefinition : ComposablePartDefinition
{
    private readonly ComposablePartDefinition _partDefinition;

    internal WebScopedComposablePartDefinition(ComposablePartDefinition partDefinition)
    {
        _partDefinition = partDefinition;
    }

    public override ComposablePart CreatePart()
    {
        var policy = (WebCreationPolicy)_partDefinition.ExportDefinitions.First().Metadata["WebCreationPolicy"];

        if (policy == WebCreationPolicy.Request)
            return new WebRequestScopedComposablePart(_partDefinition.CreatePart());
        else
            return new WebSessionScopedComposablePart(_partDefinition.CreatePart());
    }

    ...
}

The implementation of these web-scoped aware composable parts look in either the HTTPContext object’s session or current items dictionaries for a created object and returns the object if one is found. If one isn’t found, it delegates to the underlying ComposablePart to create the object before storing it in the associated dictionary thereby caching the exported object at either the request or session boundary. For example, the WebSessionScopedComposablePart is defined as follows:

public class WebSessionScopedComposablePart : WebScopedComposablePart
{
    internal WebSessionScopedComposablePart(ComposablePart composablePart)
        : base(composablePart)
    { }

    public override object GetExportedValue(ExportDefinition definition)
    {
        string sessionKey = string.Format("__Session_{0}", Key);

        var obj = CurrentHttpContext.Session[sessionKey];

        if (obj != null)
            return obj;

        obj = CreatePart();

        CurrentHttpContext.Session[sessionKey] = obj;

        return obj;
    }
}

using (var scope = new TransactionScope())
{
   using (var connection = new SqlConnection(...)
   {
      // Update the DB using connection
   }
   scope.Complete();
}

or have made use of the OperationContext object in WCF for example, then you too have also been making use of  ambient context. When I say ambient context as a pattern has been around for a while, I mean it has been for at least two or three years. I’ve found a few good blog posts from around that time that do a good job in describing the ambient context pattern. The Wandering Glitch has even gone as far as documenting ambient context in pattern language format and highlights several of its benefits, including the ability to define scopes, and also its use in providing cross cutting capabilities without having to introduce static variables or additional parameters into your method signatures. Mark Seemann also has a fantastic blog post on his old MSDN blog site which talks about using ambient context when implementing cross cutting aspects of code. 

If you’re looking for an example then Lars Corneliussen has documented one of his implementationsand has also made the source code available. What’s interesting about Lars’ implementation is his introduction of a ThreadVariable<T> class which encapsulates the core of his ambient context implementation. Typical ambient context implementations use a static variable (marked with the ThreadStatic attribute) to represent the context. Lars’ approach wraps this detail up and hides it which is something that I’ll probably borrow from in my future implementations. Ambient context typically also makes use of a disposable scope class to define the context. This can be seen in the example shown above with the TransactionScope class. While the scope object is in “scope”, the underlying context is valid. When the scope class is disposed of then the context is also disposed of. 

I’ve been using ambient context quite a lot recently with some work that I have been doing with AutoMapper. I’ve been mapping a common data model into various other forms, including other outward bound data models and also dictionaries (which are then serialized into streams as INI files). That’s right, you’ve guessed it; I’ve been interfacing with very old legacy applications. As part of this work I have been implementing custom type converters which are simply objects that implement an interface and are then plugged into the AutoMapper mapping infrastructure through a .ConvertUsing() method call. Although AutoMapper is a fantastic utility it’s quite difficult to pass extrinsic data into the mapping process. I guess the assumption is that you should have everything you need from the source data model. Despite this, combining ambient context with AutoMapper, I have been able to pass external data and other objects into my custom type converters by writing code like this: 

using (new MappingContextScope())
{
   MappingContext.Current.Formatter = new FooStreamFormatter();

   var iniStream = Mapper.Map<FooDataModel, Stream>(dataModel);
   SaveStream(iniStream, streamPath);
}

The custom type converters that may or may not be used in this mapping operation will also have access to the MappingContext by accessing MappingContext.Current. In this example, I need to apply some custom formatting within the stream being generated from a FooDataModel object (for example, dates, times, decimal point formatting and so on). Ambient context made this easy to implement and its structure lends itself well in helping to keep the code clean.

So, let me begin (again):

This is the second time that I’ve run a blog at timjroberts.com. The first one is long gone now so let’s not dwell on it, but please, feel free to drop a comment on this post and explain the virtues of backing up your data to me. I really will appreciate it. Going forward, this will become my little space on the web where I can drop my thoughts on life as a professional Developer, the things that I’m working on in the moment which will become a reference for myself (and others who might read it), and anything else that might take my fancy along the way. This blog is an open house, you’re welcome back anytime and you’re free to drop me comments. Disagree with something I said, or have an opinion yourself? Let me know. I love a good banter.