Disclaimer: I am neither an expert in TopShelf nor Quartz, this is just me trying to plug them together with Ninject.

The fist thing we need to have in order to use Quartz is to create a job that will be executed. We will call ours the VerifyEmailServerJob.

public class VerifyEmailServerJob : IJob
{
    #region Implementation of IJob

    public void Execute( JobExecutionContext context )
    {
        // TODO: Verify the email server is working correctly...
    }

    #endregion
}

Now that we have a job to run, we will create a windows service that will create the job details and schedule the job. The windows service essentially acts as a host for the jobs.

public interface IWindowsService
{
    void Start();
    void Stop();
}

public partial class MonitoringService : ServiceBase, IWindowsService
{
    private readonly JobManager _jobManager;
    private readonly List<IScheduler> _schedulers = new List<IScheduler>();

    public MonitoringService( JobManager jobManager )
    {
        _jobManager = jobManager;
        InitializeComponent();
    }

    public void Start()
    {
        // TODO: Pull from config file.
        var trigger = new CronTrigger( "name", "group", "0 0 4/8 * * MON-FRI" );
        IScheduler scheduler = _jobManager.Add<VerifyEmailServerJob>( trigger );
        _schedulers.Add( scheduler );
    }

    protected override void OnStop()
    {
        _schedulers.ForEach( scheduler => scheduler.Shutdown( false ) );
        _schedulers.Clear();
    }
}

In order to inject our services into the jobs, we need to take control of the job activation pipeline. Quartz allows us to do this by using a implementation of IJobFactory. In my example I am injecting a creation callback function that will use the Ninject kernel to activate the job and add any dependencies without the IJobFactory knowing of the kernel. I am also throwing in my own JobManager to cut down on the amount of code I need to write to add a job. But note that we have to tell the scheduler which JobFactory to use when activating.

public class JobFactory : IJobFactory
{
    private readonly Func<Type, IJob> _creationCallback;

    public JobFactory( Func<Type, IJob> creationCallback )
    {
        _creationCallback = creationCallback;
    }

    #region Implementation of IJobFactory

    public IJob NewJob( TriggerFiredBundle bundle )
    {
        JobDetail jobDetail = bundle.JobDetail;
        Type jobType = jobDetail.JobType;
        var job = _creationCallback( jobType );
        return job;
    }

    #endregion
}

public class JobManager
{
    private readonly IJobFactory _jobFactory;
    private readonly ISchedulerFactory _schedulerFactory;

    public JobManager( ISchedulerFactory schedulerFactory, IJobFactory jobFactory )
    {
        _schedulerFactory = schedulerFactory;
        _jobFactory = jobFactory;
    }

    public IScheduler Add<T>( Trigger trigger ) where T : IJob
    {
        IScheduler scheduler = _schedulerFactory.GetScheduler();
        scheduler.JobFactory = _jobFactory;
        scheduler.Start();
        var jobDetail = new JobDetail( typeof (T).Name, typeof (T) );
        scheduler.ScheduleJob( jobDetail, trigger );
        return scheduler;
    }
}

Now with out jobs, triggers, and service foundation, all we need to do is configure TopShelf to run our service and configure our kernel to inject our dependencies.

internal static class Program
{
    private static void Main( string[] args )
    {
        using ( IKernel kernel = CreateKernel() )
        {
            RunConfiguration cfg =
                RunnerConfigurator.New(
                    x =>
                    {
                        x.SetDisplayName( "Monitoring Service" );
                        x.SetServiceName( "Monitor" );
                        x.SetDescription( "Monitoring Service" );
                        x.ConfigureService<MonitoringService>( kernel );
                        x.RunAsLocalSystem();
                    } );

            Runner.Host( cfg, args );
        }
    }

    private static IKernel CreateKernel()
    {
        var kernel = new StandardKernel();
        kernel.Bind<IJobFactory>().To<JobFactory>();
        kernel.Bind<Func<Type, IJob>>().ToConstant( type => (IJob) kernel.Get( type ) );
        kernel.Bind<ISchedulerFactory>().To<StdSchedulerFactory>();
        kernel.Bind<JobManager>().ToSelf().InSingletonScope();
        kernel.Bind<IWindowsService>().To<MonitoringService>();
        return kernel;
    }
}

public static class SyntaxExtensions
{
    public static void ConfigureService<T>( this IRunnerConfigurator runnerConfigurator, IKernel kernel )
        where T : ServiceBase, IWindowsService
    {
        runnerConfigurator.ConfigureService<T>(
            c =>
            {
                c.HowToBuildService( serviceName => kernel.Get<T>() );
                c.Named( typeof (T).Name );
                c.WhenStopped( s => s.Stop() );
                c.WhenStarted( s => s.Start() );
            } );
    }
}

That about does it! We have a service configured and controlled by TopShelf, running scheduled jobs using Quartz, and dependencies and jobs created by Ninject.

I was testing out TopShelf and here is an example I put together in order to have Ninject activate the services and their dependencies:

#region Using Directives

using System;
using System.ServiceProcess;
using YourCorp.Services;
using Ninject;
using Topshelf;
using Topshelf.Configuration;
using Topshelf.Configuration.Dsl;

#endregion

namespace YourCorp
{
    internal static class Program
    {
        private static void Main( string[] args )
        {
            using ( IKernel kernel = CreateKernel() )
            {
                RunConfiguration cfg =
                    RunnerConfigurator.New(
                        x =>
                        {
                            x.SetDisplayName( "Your Service" );
                            x.SetServiceName( "YourService" );
                            x.SetDescription( "Your Service" );
                            x.ConfigureService<MonitoringService>( kernel );
                            x.ConfigureService<ReportingService>( kernel );
                            x.RunAsLocalSystem();
                        } );

                Runner.Host( cfg, args );
            }
        }

        private static IKernel CreateKernel()
        {
            var kernel = new StandardKernel();
            kernel.Bind<IWindowsService>().To<MonitoringService>();
            kernel.Bind<IWindowsService>().To<ReportingService>();
            return kernel;
        }
    }

    public static class SyntaxExtensions
    {
        public static void ConfigureService<T>( this IRunnerConfigurator runnerConfigurator, IKernel kernel )
            where T : ServiceBase, IWindowsService
        {
            runnerConfigurator.ConfigureService<T>(
                c =>
                {
                    c.HowToBuildService( serviceName => kernel.Get<T>() );
                    c.Named( typeof (T).Name );
                    c.WhenStopped( s => s.Stop() );
                    c.WhenStarted( s => s.Start() );
                } );
        }
    }

    public interface IWindowsService
    {
        void Start();
        void Stop();
    }
}

$:>call begin-rant

I am impeded and embittered by the current state of builds systems. I need to get ready to make Windows Phone 7 and Silverlight 4 builds, but the tooling doesn’t have support for them. On a side note, why the heck did I have to install VS2010 Express in order to get the WP7 SDK? #MSFAIL! It is hard to justify staying with builds systems based in XML that are manually edited and impossible to debug. In the short term, I am probably going to create my WP7 and SL4 builds by hand – I do not say this lightly, I feel sick doing so, but the level of effort to get something working properly is too high for the amount of time I have at the moment.

Disclaimer, below is still a rant, but less so than above.

The state of build systems is incredibly sad at the moment. Open source projects have no choice but to use some open source build tool adding friction to the development of the project – not because they are open source, but rather because they are poor tools. What choices do we really have – XML, Ruby, PowerShell, and a UI wrapping one of them; you can name others, but there is no traction on them so far as I can tell. Along with each is a constant ridicule by a particular group touting the magnificence of their own choice in tooling. The UI tools have the added hatred in that they are not free and the disdain of point and click.

Just to make it clear, I am biased, I love FinalBuilder – a non free UI build tool; but I can’t use it for open source and the extension model is a pain. I do not want to learn yet another language in order to write my builds scripts, and I absolutely do not want to write XML. This eliminates all of my needs, so I have to sacrifice one of my requirements in order to get the job done.

Below is a list of the major tools available as I currently see them. I know there are many others, but they aren’t important to me.

• Language based
  • psake (PowerShell Build Automation Tool)
  • Rake (Ruby Make)
  • Fake (F# Make)
  • BooBs (Boo Build System)
• XML Based
  • NAnt  (.NET Build Tool)
  • MSBuild
• Visual Editor
  • FinalBuilder
  • VisualBuild

PowerShell, I wanted to love you, but found you just frustrating to use. I love that you can access .NET libraries, but your debugging and editing sucks. In discussions I have had with others, Ruby’s niche seems to be rails and DSLs. With PowerShell and Ruby, you have to have their runtime on your machine. Many developers I know won’t install Ruby on their computers, and I really don’t want to force users of my open source software to install PowerShell or Ruby – it feels like a significant failure on my part were I to do so. On the other hand, do users really need to be making builds? Can they just use VS? MSBuild and NAnt, you are dead to me. The nightmares of past attempts to ‘debug’ XML haunt me.

I am still in a lose-lose situation. I realize that I am trying to deal with two separate issues that seem to be the root of the problem. First, trying to stay in a .NET environment and not requiring yet another external dependency. Second, the poor tooling. I have been very tempted to write an open source version of FinalBuilder, but most .NET developers I have mentioned it to have asked “What is FinalBuilder?” – which doesn’t inspire me to invest my time.

Right now, I see two front runners that will emerge: Visual Tools (FinalBuilder, VisualBuild), and Ruby (IronRuby). I think that the aversion to Ruby will push .NET developers to use IronRuby specifically (but this is still an extra install ). If I am going to use something other than FinalBuilder, I want it to be a real part of my product. I don’t want a second class build tool. I want something that goes under the same scrutiny as my production code. I want to make my scripts a full part of my work: to refactor, test, debug, review, and version control my build scripts.

Right now, I think I need to learn Ruby, in-depth, and see what can be done. The Albacore rake tasks seem to be a good start, so I will have to see where it leads to. One interesting thing I picked up when evaluating current systems and looking to build my own is that they are really all just consumers of a common data model. If you could create a detailed model of the options available for a particular task, you should theoretically be able to generate psake, rake, fake, build files from the data model.

It was pointed out that the sequence generator could be written as an infinite sequence to allow .Skip(), .Take(), .ElementAt(), etc. Here is the infinite sequence version.

public static class Fibonacci
{
	public static IEnumerable<BigInteger> Generate()
	{
		yield return 1;
		yield return 1;

		BigInteger n1 = 1, n2 = 1;
		while(true)
		{
			BigInteger n3 = n1 + n2;
			n1 = n2;
			n2 = n3;
			yield return n3;
		}
	}
}

If you ever happen to be writing a device driver and you want to have WinDbg configured to run a set of scripts, this configuration for WINDBG.INI may be of help. If it doesn’t mean anything to you, don’t worry, nothing to see here other than pain. Replace anything in {} with your own paths and file names. This is configured for kernel debugging over 1394.

[WinDbg Location]
C:\Program Files\Debugging Tools for Windows (x86)\windbg.exe
[WinDbg CmdLines]
-T "Initial WinDbg Line" -c "SQE;BL"
-T "Default" -Q -QY -y http://msdl.microsoft.com/download/symbols;C:\{PathToBinFiles} -k 1394:channel=44,symlink=Channel -c "SQE;BL;.kdfiles -m \Systemroot\system32\DRIVERS\{YourDriver1}.sys C:\{PathToBinFiles}\{YourDriver1}.sys;.kdfiles -m \Systemroot\system32\DRIVERS\{YourDriver2}.sys C:\{PathToBinFiles}\{YourDriver2}.sys;.kdfiles"

About

I brushed off some old benchmarking code used in my clustering application and decided to see what I can do using today’s multi-core hardware. When writing computationally intensive algorithms, we have a number of considerations to evaluate. The best (IMHO) algorithms to parallelize are data parallel algorithms without loop carried dependencies.

You may think nothing is special about matrix multiplication, but it actually points out a couple of performance implications when writing CLR applications. I originally wrote seven different implementations of matrix multiplication in C# – that’s right, seven.

• Dumb
• Standard
• Single
• Unsafe Single
• Jagged
• Jagged from C++
• Stack Allocated

Dumb: double[N,N], real type: float64[0...,0...]

The easiest way to do matrix multiplication is with a .NET multidimensional array with i,j,k ordering in the loops. The problems are twofold. First, the i,j.k ordering accesses memory in a hectic fashion causing data in varied locations to be pulled in. Second, it is using a multidimensional array. Yes, the .NET multidimensional array is convenient, but it is very slow. Let’s look at the C# and IL

C#:

C[i, j] += A[i, k] * B[k, j];

IL of C#:

ldloc.s i
ldloc.s jcall instance float64& float64[0...,0...]::Address(int32, int32)
dup
ldobj float64
ldloc.1
ldloc.s i
ldloc.s k
call instance float64 float64[0...,0...]::Get(int32, int32)
ldloc.2
ldloc.s k
ldloc.s j
call instance float64 float64[0...,0...]::Get(int32, int32)
mul
add
stobj float64

If you notice the ::Address and ::Get parts, these are method calls! Yes, when you use a multidimensional array, you are using a class instance. So every access, assignment, and read incurs the cost of a method call. When you are dealing with and N^3 algorithm, that is N^3 method calls making this implementation much slower than other methods.

Standard: double[N,N], real type float64[0...,0...]

This implementation rearranges the loop ordering to i,k,j in order to optimize memory access to the arrays. No other changes are made from the dumb implementation. The Standard implementation is what is used for the base of all other multidimensional implementations.

Single: double[N * N], real type float64[]

Instead of creating a multidimensional array, we create a single block of memory. The float64[] type is a block of memory instead of a class. Downside here is that we have to calculate all offsets manually.

Unsafe Single, real type float64[]

This method is the same as the single dimensional array, except that the pointers to the arrays are fixed and pointers are used in unsafe C#.

Jagged, double[N][N], real type float64[][]

This is the same implementation as standard, except that we use arrays of arrays instead of a multidimensional array. It takes an extra step to initialize, but it is a series of blocks to raw memory eliminating the method call overhead. It is typically 30% faster that the multidimensional array.

Jagged from C++, double[N][N], real type float64[][]

This is a bit more difficult. When writing these algorithms, we let the JIT compiler optimize for us. The C++ compiler is unfortunately a lot better, but it isn’t real-time. I ported the code from the jagged implementation to C++/CLI and enabled heavy optimization. Once compiled, I disassembled the dll and converted the IL to C#. The result is this implementation which is harder to read, but it is really fast.

Stack Allocated, stackalloc double[N * N], real type float64*

This implementation utilizes the rarely used stackalloc keyword. Using this implementation is very problematic as you may get a StackOverflowException depending on your current stack usage.

Enough, what does it mean?!

Because of the way matrix multiplication works, we can multiply a row without impacting the result of other row multiplications. That’s right, we have a data parallel algorithm! We need to identify the chucks of work to parallelize.

We can go about this in a couple different ways. First, manual threading. Second, using the ThreadPool. Third, using the new task parallel library. In this post I am going to use the third option as it makes things very nice for us. We don’t want to deal with scheduling or synchronization ourselves.

Partitioning

We can do a couple of different schemes. We can use ParallelFor and add each rows multiplication to the list of work to be done. This is very easy

for ( int i = 0; i < N; i++ )
{
	for ( int k = 0; k < N; k++ )
	{
		for ( int j = 0; j < N; j++ )
		{
			double[] Ci = C[i];
			Ci[j] = ( A[i][k] * B[k][j] ) + Ci[j];
		}
	}
}

Becomes:

Parallel.For( 0, N, i =>
					{
						for ( int k = 0; k < N; k++ )
						{
							for ( int j = 0; j < N; j++ )
							{
								double[] Ci = C[i];
								Ci[j] = ( A[i][k] * B[k][j] ) + Ci[j];
							}
						}
					} );

The bad news is that this can be too granular. Another way to look at it is over parallelization. The overhead of scheduling and threading hurts our performance. This method does give us the smallest synchronization time. In the worst case, all rows are calculated except for one, which is started at the completion of the penultimate calculation. So the worst case is we wait for a single row.

If we are willing to put in more work, we can optimize the row striping to group the calculations into groups of rows in order to minimize synchronization and threading overhead. Looking at the number of processors available, we can make the number of chunks relative to the number of processors.

IEnumerable<Tuple<int, double[][]>> PartitionData( int N, double[][] A )
{
	int pieces = ( ( N % ChunkFactor ) == 0 )
					 ? N / ChunkFactor
					 : ( (int) ( ( N ) / ( (float) ChunkFactor ) ) + 1 );

	int remaining = N;
	int currentRow = 0;

	while ( remaining > 0 )
	{
		if ( remaining < ChunkFactor )
		{
			ChunkFactor = remaining;
		}

		remaining = remaining - ChunkFactor;
		var ai = new double[ChunkFactor][];
		for ( int i = 0; i < ChunkFactor; i++ )
		{
			ai[i] = A[currentRow + i];
		}

		int oldRow = currentRow;
		currentRow += ChunkFactor;
		yield return new Tuple<int, double[][]>( oldRow, ai );
	}
}

Here we partner the row to start on in the result matrix C with the pointer to the head of the row of A to start on. We could use the jagged implementation, but for pure speed, I am sticking with the fastest implementation I have:

void Multiply( Tuple<int, double[][]> A, double[][] B, double[][] C )
{
	int size = A.Item2.GetLength( 0 );
	int cols = B[0].Length;
	double[][] ai = A.Item2;

	int i = 0;
	int offset = A.Item1;
	do
	{
		int k = 0;
		do
		{
			int j = 0;
			do
			{
				double[] ci = C[offset];
				ci[j] = ( ai[i][k] * B[k][j] ) + ci[j];
				j++;
			} while ( j < cols );
			k++;
		} while ( k < cols );
		i++;
		offset++;
	} while ( i < size );
}

It is a little more complicated to write this heavily optimized version, but it pays off. To actually do the multiplication is very simple now using the TPL:

Parallel.ForEach( PartitionData( N, A ), item => Multiply( item, B, C ) );

Enough! Show me the numbers!

OK. You have patiently waited and I will give you the results. The parallel numbers are for my quad core machine with 4GB RAM. The Y-Axis is millions of algorithmic steps per second. The X-Axis is the matrix size.

First, we can look at the performance of the various single-threaded implementations. As you can see, there is a 5x difference between the easiest way and my most optimized implementation that does not use unsafe code. So if you need to multiply matrices – use jagged arrays!

Single Threaded Matrix Multiplication Performance

The bulge you see on the left when the matrix size is small is the result of the Cache Memory Swap Die (CMSD) envelope. When the data size is small, the system leverages cache which is the fastest. When the data becomes to large, it has to store the data in main memory which is still pretty fast. What you don’t see is the swap and die levels. When the data set becomes very large, the system must use the swap file and store data on disk which is levels of magnitude slower than memory. When the data set becomes too large, the hard drive thrashes and you are constantly paging data in. At this point, your performance dies.

There is a problem with the chunking. Depending on how many pieces, the load of the processors, and the worst case job completion, the performance can vary for the chunking implementation. Below you can see the relative performance of the optimized chunking implementation against the simple parallelization and my heuristic.

I ran the chunking algorithm with many different granule sizes and recorded the best and worst values to give a performance range. The overlap between actual and max is the CPU being used by other processes out of my control – one of the issues with granule calculation is that you can’t predict the future. One possible thing we could do is to utilize coroutines to adjust the granule size as time goes on in oder to adjust to machine load.

Parallel Matrix Multiplication Performance Comparison

At best, we are calculating over 4x faster than the best single-threaded implementation. Yes, better than 4x with 4 cores. We are taking advantage of caching when we row stripe the data. This performance becomes even more significant when running this code across a cluster – you can get over 5x with 4 machines. Unfortunately, I never had the chance to work with four quad core machines in a cluster to test out a massively parallel implementation.

Parallel vs Single Threaded Matrix Multiplication

Summary

As you can see, small changes in algorithm implementation can have quite adverse effects on performance. Also, parallelizing data parallel algorithms can be incredibly simple and provide a great performance boost with very little effort.

I would love to do some work showing the parallelization of wavefront, four square, and other data dependency schemes and their effect on performance and the effort needed to parallelize them, but we will see how much time I have. Another fun problem might be a massively parallel N-queens or Knights tour solver.

You can find all of the source code for these benchmarks on my blog’s GitHub page.

I have just pushed new binaries and tagged the release on GitHub. There was confusion on how to deal with automatic module loading with the release that contained both proxy modules – every mailing list question pertained to this confusion, so it needed to be resolved. I have removed this release in favor of having the user download the extension with the dynamic proxy implementation of their choice.

There are two new projects: Ninject.Extensions.Interception.LinFu and Ninject.Extensions.Interception.DynamicProxy2 that contain the necessary classes for each dynamic proxy implementation.

This update also introduces LinFu.DynamicProxy for Silverlight 3.0 support.

You can download the latest release 2.0.1.0 from the GitHub project downloads page.

Overview

In Part 1 we covered the basics of the extension and introduced the IInterceptor interface. Now we can move more in depth and look at the interceptor system composed of

• Custom Interceptors
• Interception via Attributes

With these, we can define a rich set of interception capabilities in our applications.

Custom Interceptors

The base of the binding interception is the very simple IInterceptor interface:

public interface IInterceptor
{
	/// <summary>
	/// Intercepts the specified invocation.
	/// </summary>
	/// <param name="invocation">The invocation to intercept.</param>
	void Intercept( IInvocation invocation );
}

The idea behind and IInterceptor is to take the place of some kind of action. This is very simple and makes creating an custom interceptor very easy. In order to do it properly, however, you must use the IInvocation object you are given. Below is the most basic interceptor that you can create which resumes execution of the real method.

public class MinimalInterceptor : IInterceptor
{
    public void Intercept( IInvocation invocation )
    {
        invocation.Proceed();
    }
}

The invocation.Proceed() call is crucial! Since a call can have multiple interceptors, we need a way to hand off execution to the next downstream interceptor. The Proceed() call will either invoke the next interceptor in the chain, or invoke the target intercepted method if their are no more interceptors.

The extension currently ships with three interceptors

• SimpleInterceptor
• ActionInterceptor
• AutoNotifyPropertyChangedInterceptor (covered in IANPC post)

SimpleInterceptor

The SimpleInterceptor provides before and after execution hooks that you can override. We can create a simple timing interceptor by overriding the hooks and writing to the Trace object:

public class TimingInterceptor : SimpleInterceptor
{
	readonly Stopwatch _stopwatch = new Stopwatch();

	protected override void BeforeInvoke(IInvocation invocation)
	{
		_stopwatch.Start();
	}

	protected override void AfterInvoke(IInvocation invocation)
	{
		_stopwatch.Stop();
		string message = string.Format( "Execution of {0} took {1}.",
										invocation.Request.Method,
										_stopwatch.Elapsed );
		Trace.WriteLine(message);
		_stopwatch.Reset();
	}
}

There is a lot more that can be done with the IInvocation object. You should really take a minute to look over the interface and see some of the information available. I have also included IProxyRequest as there is a lot of good information there accessible from IInvocation:

public interface IInvocation
{
    /// <summary>
    /// Gets the request, which describes the method call.
    /// </summary>
    IProxyRequest Request { get; }

    /// <summary>
    /// Gets the chain of interceptors that will be executed before the target method is called.
    /// </summary>
    IEnumerable<IInterceptor> Interceptors { get; }

    /// <summary>
    /// Gets or sets the return value for the method.
    /// </summary>
    object ReturnValue { get; set; }

    /// <summary>
    /// Continues the invocation, either by invoking the next interceptor in the chain, or
    /// if there are no more interceptors, calling the target method.
    /// </summary>
    void Proceed();
}

public interface IProxyRequest
{
    /// <summary>
    /// Gets the kernel that created the target instance.
    /// </summary>
    IKernel Kernel { get; }

    /// <summary>
    /// Gets the context in which the target instance was activated.
    /// </summary>
    IContext Context { get; }

    /// <summary>
    /// Gets or sets the proxy instance.
    /// </summary>
    object Proxy { get; set; }

    /// <summary>
    /// Gets the target instance.
    /// </summary>
    object Target { get; }

    /// <summary>
    /// Gets the method that will be called on the target instance.
    /// </summary>
    MethodInfo Method { get; }

    /// <summary>
    /// Gets the arguments to the method.
    /// </summary>
    object[] Arguments { get; }

    /// <summary>
    /// Gets the generic type arguments for the method.
    /// </summary>
    Type[] GenericArguments { get; }

    /// <summary>
    /// Gets a value indicating whether the request has generic arguments.
    /// </summary>
    bool HasGenericArguments { get; }
}

Given this information you can implement simple or more complex interceptors capable of utilizing a large amount of information to do the job.

ActionInterceptor

The ActionInterceptor takes an Action<IInvocation> in its .ctor

ActionInterceptor interceptor =
    new ActionInterceptor( invocation => Console.WriteLine("Executing {0}.", invocation.Request.Method) );

If you want a quick spike and don’t want to define a full interceptor, the ActionInterceptor is very handy.

Multiple Interceptors

You have seen how to attach interceptors via a static registry (IKernel extensions for specific methods) and attaching them using bindings. Now, what may have not been obvious, is that you can attach multiple interceptors to a given binding.

[Fact]
public void CanAttachMultipleInterceptors()
{
    using (StandardKernel kernel = CreateDefaultInterceptionKernel())
    {
        var binding = kernel.Bind<FooImpl>().ToSelf();
        binding.Intercept().With<FlagInterceptor>();
        binding.Intercept().With<CountInterceptor>();

        var foo = kernel.Get<FooImpl>();

        Assert.False(FlagInterceptor.WasCalled);
        Assert.Equal(0, CountInterceptor.Count);

        foo.Foo(); // call method to invoke interceptors

        Assert.True(FlagInterceptor.WasCalled);
        Assert.Equal(1, CountInterceptor.Count);
    }
}

We can also change the order in which the interceptors are executed:

[Fact]
public void CanAttachMultipleInterceptors()
{
    using (StandardKernel kernel = CreateDefaultInterceptionKernel())
    {
        var binding = kernel.Bind<FooImpl>().ToSelf();
        binding.Intercept().With<FlagInterceptor>().InOrder(2);
        binding.Intercept().With<CountInterceptor>().InOrder(1);
        binding.Intercept().With<TimingInterceptor>().InOrder(3);
        // ...
    }
}

Interception via Attributes

If you do not want to use the binding syntax to specify interceptors, you can use attributes to mark specific classes for interception. The [Intercept] attribute is an abstract attribute for you to extend and use on classes and methods. When a derived attribute is applied on a class, it will register interception on all virtual methods of that class. If you wish to disable interception for a particular method, you can apply the [DoNotIntercept] attribute. If you only want to intercept a particular method in a class, just apply the derived attribute to that single method.

You must extend the base [Intercept] attribute as it needs to know what interceptor to attach. You specify this by overriding the CreateInterceptor method. We can use the TimingInterceptor used previously to create a  attribute and apply it to a simple class.

public class TimeAttribute : InterceptAttribute
{
    public override IInterceptor CreateInterceptor( IProxyRequest request )
    {
        return request.Context.Kernel.Get<TimingInterceptor>();
    }
}

public class ObjectWithMethodInterceptor
{
    [Time] // intercepted
    public virtual void Foo()
    {
    }

    // not intercepted
    public virtual void Bar()
    {
    }
}

[Time]
public class ObjectWithClassInterceptor
{
    // intercepted
    public virtual void Foo()
    {
    }

    [DoNotIntercept] // not intercepted
    public virtual void Bar()
    {
    }

    // not intercepted - method is not virtual
    public void Baz()
    {
    }
}

There is one other part of the interception attributes that is also supported from the binding configuration: Order. When you attach interception attributes, you can specify the order of the interceptor. You do not need to specify this in your custom attributes; it is handled by the injection system. All you have to do is specify the order in the attribute usage.

[Count(Order = 1)]
public class ObjectWithOrderedInterceptors
{
    [Flag(Order = 0)]
    public virtual void Foo()
    {
    }

    public virtual void Baz()
    {
    }
}

One thing you may have noticed is that I used two different interceptor types. This is perfectly valid. All virtual calls of ObjectWithOrderedInterceptors will be counted. In addition, calls to Foo will also set a flag and the flag will be set before the count interceptor has a chance to run.

This can be important if you are trying to time calls with an interceptor; yes, the interception system is going to skew your results either way, but the amount you are over can vary drastically if your timing interceptor is first or last in the chain.

Conclusion

That pretty much covers the Ninject.Extensions.Interception interceptors. Using this foundation, you can create just about any type of interception scheme you can think of.

About the Extension

The Ninject interception extension relies on the DynamicProxy implementations of Castle and LinFu to generate proxy instances. The interception extension is essentially an abstraction of the proxying components leveraging Ninject’s feature set along with interception utilities.

Enabling the Extension

There are two ways to enable the extension. The easiest way is to use Ninject’s automatic extension loading mechanism. By default Ninject will load all modules from assemblies that match the pattern Ninject.Extensions.*.dll in the same directory as the Ninject assembly. This works fine except that we have multiple options for the DynamicProxy implementation.

The .NET 3.5 release contains both the LinFuModule and the DynamicProxy2Module. If you have automatic extension loading enabled, it will load both modules. To make it easier, there are two other .NET 3.5 releases that either contain the LinFuModule, or the DynamicProxy2Module. All other platform releases only have one module: Mono->LinFu, Silverlight 3->Castle.

If you have automatic extension loading disabled, there is no need to worry, you can simply pass one of the modules into the kernel .ctor as usual. Now that we have the extension loaded, it is time to start using the extension.

Extensibility Provided

There are three main ways that that you can use the extension:

1. Interception on the Binding
2. Method Interception
3. Facilities Provided by the Extension

All of the binding capability of the extension are based on extension methods on IKernel and IBindingSyntax. The extensions for IKernel provide method interception where you can intercept very specific calls when instances of a type are requested. The IBindingSyntax extensions provide class level interception using a specific IInterceptor implementation.

*** Important Note ***

Your methods/properties to be intercepted must be virtual! The DynamicProxy implementations are still bound by inheritance rules. If you look at all examples in this series, all intercepted members are virtual.

Interception on the Binding

The base of the binding interception is the very simple IInterceptor interface:

    public interface IInterceptor
    {
        /// <summary>
        /// Intercepts the specified invocation.
        /// </summary>
        /// <param name="invocation">The invocation to intercept.</param>
        void Intercept( IInvocation invocation );
    }

In order to provide class level interception, you must create a binding.

kernel.Bind<ViewModel>().ToSelf().Intercept().With<FlagInterceptor>();

The Intercept() extension creates a hint inside the kernel that when this binding is used, that we need to look into the proxying strategies. The With<T>() call declares the IInterceptor to apply with this binding. You can also supply an instance in the With<T>() call in order to pass it a configured interceptor.

ActionInterceptor interceptor =
    new ActionInterceptor( invocation => Console.WriteLine("Executing!") );
kernel.Bind<ViewModel>().ToSelf().Intercept().With( interceptor );

Method Interception

Using method interception, for a given method or property, you can replace, wrap, prepend, or append functionality. Remember, these are provided as extension methods on IKernel giving you the following calls from an IKernel instance:

IAdviceTargetSyntax Intercept( Predicate<IProxyRequest> predicate )

void AddMethodInterceptor( MethodInfo method, Action<IInvocation> action )

void InterceptReplace<T>( Expression<Action<T>> methodExpr,
        Action<IInvocation> action )

void InterceptAround<T>( Expression<Action<T>> methodExpr,
       Action<IInvocation> beforeAction,
       Action<IInvocation> afterAction )

void InterceptBefore<T>( Expression<Action<T>> methodExpr,
       Action<IInvocation> action )

void InterceptAfter<T>( Expression<Action<T>> methodExpr,
       Action<IInvocation> action )

void InterceptReplaceGet<T>( Expression<Func<T, object>> propertyExpr,
       Action<IInvocation> action )

void InterceptAroundGet<T>( Expression<Func<T, object>> propertyExpr,
       Action<IInvocation> beforeAction,
       Action<IInvocation> afterAction )

void InterceptBeforeGet<T>( Expression<Func<T, object>> propertyExpr,
        Action<IInvocation> action )

void InterceptAfterGet<T>( Expression<Func<T, object>> propertyExpr,
        Action<IInvocation> action )

void InterceptReplaceSet<T>( Expression<Func<T, object>> propertyExpr,
        Action<IInvocation> action )

void InterceptAroundSet<T>( Expression<Func<T, object>> propertyExpr,
        Action<IInvocation> beforeAction,
        Action<IInvocation> afterAction )

void InterceptBeforeSet<T>( Expression<Func<T, object>> propertyExpr,
        Action<IInvocation> action )

void InterceptAfterSet<T>( Expression<Func<T, object>> propertyExpr,
        Action<IInvocation> action )

For example:

public class Foo : IFoo
{
    public virtual void ThrowsAnError()
    {
        throw new Exception();
    }
}

public class MethodTests
{
    public void NoOpASingleMethod()
    {
        Kernel.Bind<Foo>().ToSelf();
        Kernel.InterceptReplace<Foo>(foo => foo.ThrowsAnError(), invocation => {} );
        var foo = Kernel.Get<Foo>();
        foo.ThrowsAnError(); // Nothing happens
    }
}

One key to note is that the interception is for the implementing type, not for the service that the bindings are configured for. For example, there will be no interceptor attached when we configure the interception on the interface:

public void NoInterceptionPerformed()
{
    Kernel.Bind<IFoo>().To<Foo>();
    Kernel.InterceptReplace<IFoo>(foo => foo.ThrowsAnError(), invocation => {} );
    var foo = Kernel.Get<IFoo>();
    foo.ThrowsAnError(); // exception is thrown as usual
}

Facilities Provided by the Extension

The extension provides a couple of utility mechanisms to aid programmers. As mention the a previous blog post, the extension supplies an automatic INotifyPropertyChanged implementation for your view model classes.

If you also take a look back to the block posts on weak proxies and weak proxy factories, this functionality is currently being worked into the extension and will be presented in a future blog post.

Conclusion

Now that we have covered the basics with the interception extension, we can move into more advanced topics such at attaching multiple proxies, proxy ordering, and writing custom interceptors in the next post.

I have been playing with the Ninject conventions binding extension syntax and usage model. It was originally based on the StructureMap assembly scanner, but I want to use the API in a different fashion.

I have been working on making the API more like LINQ in the way you think and use it. Here is a sampling of the new API that I am testing. Remember, you would never bind like this, ideally you would set up a few different scans to bind everything the way you want it.

IKernel kernel = new StandardKernel();
kernel.Scan(
	x =>
	{
		// set up the source collection of types to process
		x.FromCallingAssembly();
		x.From( from assembly in AppDomain.CurrentDomain.GetAssemblies()
				from type in assembly.GetExportedTypes()
				select type );
		x.FromAssemblyContaining<IGenericView>();
		x.FromAssembliesInPath( "." );
		x.FomAssembliesMatching( "*.Model.dll" );
		x.FromAssemblyContaining(new[] {typeof (IGenericView), typeof (StringView)});

		// Filter out what you want
		x.Where( type => !type.IsAbstract );
		x.WhereTypeIsInNamespace( "Base.Model" );
		x.WhereTypeIsInNamespaceOf<StringView>();
		x.WhereTypeIsNotInNamespace( "Base.Test" );
		x.WhereTypeIsNotInNamespaceOf<StandardKernel>();
		x.WhereTypeInheritsFrom<IGenericView>();

		// Exclude items even if they match your Where criteria
		x.Excluding<INinjectSettings>();
		x.Excluding( new[] {typeof (IServiceProvider), typeof (IInitializable)} );

		// Include items whether or not they match your Where criteria
		x.Including<DefaultView>();

		// Tell the scanner how to determine bindings
		x.BindWithDefaultConventions();

		// Declare the binding scope for scanned members
		x.InTransientScope();
	} );

Some API calls will not be available on all platforms due to security restrictions of course.