The Inquisitive Coder - Davy Brion's Blog » Aspect Oriented Programming

Protecting Your Application From Remote Problems

Davy Brion — Sun, 05 Jul 2009 19:45:41 +0000

If you have a web application which communicates with a remote service, it’s important to protect that web application from any problems the remote service might be dealing with. For instance, if the remote service goes down (for whatever reason) you really don’t want your application to keep making calls to this service. These failing calls increase the load on the service, which is already having problems, and will also block your threads which takes away resources from your application to deal with other requests. One pattern which is very suitable to reduce the problems for this situation is the Circuit Breaker (read that unless you’re familiar with the circuit breaker).

The biggest issue i have with my previous implementation is that it required you to call it manually to protect potentially risky calls. I don’t like having to call my circuit breaker whenever i want to make a service call because as a consumer of a service proxy, i shouldn’t even know about the circuit breaker. I also don’t want any coupling between my service proxy and the actual circuit breaker. Sounds like a good candidate for some AOP magic, right?

We’re going to use Castle Windsor’s Interceptors to make this work. First, the implementation of the CircuitBreaker class:




    public class CircuitBreaker : IInterceptor
    {
        private readonly object monitor = new object();
        private CircuitBreakerState state;
        private int failures;
        private int threshold;
        private TimeSpan timeout;
 
        public CircuitBreaker(int threshold, TimeSpan timeout)
        {
            this.threshold = threshold;
            this.timeout = timeout;
            MoveToClosedState();
        }
 
        public void Intercept(IInvocation invocation)
        {
            using (TimedLock.Lock(monitor))
            {
                state.ProtectedCodeIsAboutToBeCalled();
            }
 
            try
            {
                invocation.Proceed();
            }
            catch (Exception e)
            {
                using (TimedLock.Lock(monitor))
                {
                    failures++;
                    state.ActUponException(e);
                }
                throw;
            }
 
            using (TimedLock.Lock(monitor))
            {
                state.ProtectedCodeHasBeenCalled();
            }
        }
 
        private void MoveToClosedState()
        {
            state = new ClosedState(this);
        }
 
        private void MoveToOpenState()
        {
            state = new OpenState(this);
        }
 
        private void MoveToHalfOpenState()
        {
            state = new HalfOpenState(this);
        }
 
        private void ResetFailureCount()
        {
            failures = 0;
        }
 
        private bool ThresholdReached()
        {
            return failures >= threshold;
        }
 
        private abstract class CircuitBreakerState
        {
            protected readonly CircuitBreaker circuitBreaker;
 
            protected CircuitBreakerState(CircuitBreaker circuitBreaker)
            {
                this.circuitBreaker = circuitBreaker;
            }
 
            public virtual void ProtectedCodeIsAboutToBeCalled() { }
            public virtual void ProtectedCodeHasBeenCalled() { }
            public virtual void ActUponException(Exception e) { }
        }
 
        private class ClosedState : CircuitBreakerState
        {
            public ClosedState(CircuitBreaker circuitBreaker)
                : base(circuitBreaker)
            {
                circuitBreaker.ResetFailureCount();
            }
 
            public override void ActUponException(Exception e)
            {
                if (circuitBreaker.ThresholdReached()) circuitBreaker.MoveToOpenState();
            }
        }
 
        private class OpenState : CircuitBreakerState
        {
            private readonly Timer timer;
 
            public OpenState(CircuitBreaker circuitBreaker)
                : base(circuitBreaker)
            {
                timer = new Timer(circuitBreaker.timeout.TotalMilliseconds);
                timer.Elapsed += TimeoutHasBeenReached;
                timer.AutoReset = false;
                timer.Start();
            }
 
            private void TimeoutHasBeenReached(object sender, ElapsedEventArgs e)
            {
                circuitBreaker.MoveToHalfOpenState();
            }
 
            public override void ProtectedCodeIsAboutToBeCalled()
            {
                throw new OpenCircuitException();
            }
        }
 
        private class HalfOpenState : CircuitBreakerState
        {
            public HalfOpenState(CircuitBreaker circuitBreaker) : base(circuitBreaker) { }
 
            public override void ActUponException(Exception e)
            {
                circuitBreaker.MoveToOpenState();
            }
 
            public override void ProtectedCodeHasBeenCalled()
            {
                circuitBreaker.MoveToClosedState();
            }
        }
    }

Notice how the CircuitBreaker class implements Windsor’s IInterceptor interface. The Intercept method will be called by Windsor whenever we try to call a method from a protected component. Within the Intercept method we can add the necessary logic to apply the Circuit Breaker pattern to the code that was originally called.

Now we just need to configure the Windsor IOC container to apply this bit of AOP magic for us.

First, we register the CircuitBreaker with the container:




            container.Register(Component.For<CircuitBreaker>().LifeStyle.Singleton
                                   .Named("serviceProxyCircuitBreaker")
                                   .DependsOn(new Hashtable { { "threshold", 5 }, { "timeout", TimeSpan.FromMinutes(5) } }));

Notice that we register the CircuitBreaker implementation with a Singleton lifestyle, a custom name and the required constructor parameters to create an instance of the CircuitBreaker.

Then we register our service proxy:




            container.Register(Component.For<IServiceProxy>().ImplementedBy<ServiceProxy>().LifeStyle.Transient
                                .Interceptors(InterceptorReference.ForKey("serviceProxyCircuitBreaker")).Anywhere);

Notice how we registered the service proxy as a transient component, while referencing the singleton CircuitBreaker interceptor. This means that each resolved instance of our service proxy will be protected by the same CircuitBreaker instance. If you have multiple services that you want to protect, simply register multiple CircuitBreakers with different keys and link each service you want to protect with the correct CircuitBreaker key.

WCF Exception Handling with PostSharp

Davy Brion — Fri, 23 May 2008 09:37:55 +0000

In your WCF service methods, you should always provide proper exception handling. The exception handling code is almost always the same, so it’s usually just copy/pasted in each method. Here’s an example of a typical service method:



        public void PersistOrder(Order order)
        {
            try
            {
                Container.Resolve<IPersistOrderHandler>().Handle(order);
            }
            catch (BusinessException b)
            {
                throw new FaultException<BusinessExceptionInformation>(new BusinessExceptionInformation(b), 
                    new FaultReason(b.Message));   
            }
            catch (FaultException)
            {
                throw;
            }
            catch (Exception e)
            {
                Container.Resolve<ILogger>().LogException(e);
                throw new FaultException(new FaultReason(e.Message));
            }
        }

That’s a lot of code, even though only ONE line will differ from the other service methods in this service. Let’s clean up this mess, shall we? Exception handling is a cross cutting concern so we might as well put it in one place (at least, one place for each different kind of exception handling that you need). We’ll use PostSharp to define an ApplyServiceExceptionHandling aspect:



    [Serializable]
    public class ApplyServiceExceptionHandling : OnExceptionAspect
    {
        public override void OnException(MethodExecutionEventArgs eventArgs)
        {
            if (eventArgs.Exception is BusinessException)
            {
                throw new FaultException<BusinessExceptionInformation>(
                    new BusinessExceptionInformation(eventArgs.Exception as BusinessException),
                    new FaultReason(eventArgs.Exception.Message));
            }
            else if (eventArgs.Exception is FaultException)
            {
                eventArgs.FlowBehavior = FlowBehavior.RethrowException;
            }
            else
            {
                Container.Resolve<ILogger>().LogException(eventArgs.Exception);
                throw new FaultException(new FaultReason(eventArgs.Exception.Message));
            }
        }
    }

And now we can modify the earlier service method to this:



        [ApplyServiceExceptionHandling]
        public void PersistOrder(Order order)
        {
            Container.Resolve<IPersistOrderHandler>().Handle(order);
        }

That’s a lot cleaner than the previous version right? Actually, this service has more than one service method so we’re better off moving the ApplyServiceExceptionHandling attribute to the class level instead of the method level:



    [ApplyServiceExceptionHandling]
    public class OrderManagementService : IOrderManagementService

now we can get rid of all of the exception handling code in each service method, but each one will have exception handling applied to it because the exception handling aspect is applied to the class, and thus, to each method of that class. And if you need to modify your exception handling (to handle TargetInvocationExceptions with BusinessExceptions as InnerExceptions for instance?) you’d only have to do this in one place.

Btw, i’m aware of WCF’s IErrorHandler interface (which allows you to handle exceptions in a general manner as well)… i just don’t like it

Adding Behavior With PostSharp

Davy Brion — Wed, 21 May 2008 20:12:41 +0000

A little while ago, i talked about adding behavior to components using Windsor’s Interceptors. I wanted to try something similar with PostSharp, which is a very powerful Aspect Oriented Programming framework for the .NET world. Discussing everything PostSharp can do (which is a lot) is way beyond the scope of this post, so we’ll just focus on what i’m trying to do, and how PostSharp helps us with that.

In the previous post, i used a logging example… i didn’t want logging code mixed up with my real code, so i used a Windsor Interceptor to intercept calls to classes that i had configured to be logged. The interceptor would then log before and after the method calls were executed. In this post we’ll do something very similar, but a bit more advanced. We’re gonna write some tracing logic that will write a trace statement when the method is entered, along with the parameter values for each of its parameters. Then after the original method has executed, we’ll write a trace statement to indicate that we have left the method, and we’ll display the return value of the method as well, if there is one. That kind of tracing information can be very valuable, but writing that code is extremely tedious work. Nobody wants to do that, right? I sure as hell don’t.

We’ll use the following simple class as an example:



    public class Calculator
    {
        public int Add(int firstValue, int secondValue)
        {
            return firstValue + secondValue;
        }
 
        public int Subtract(int firstValue, int secondValue)
        {
            return firstValue - secondValue;
        }
    }

This calculator has a pretty limited feature-set, but we don’t need anything more for this example. Ok, so how do we add the tracing code without actually adding it to this code? We can just compile the code, and then we can have PostSharp inject some extra code to the compiled code. Sounds pretty hard, right? It is. But PostSharp Laos is a small framework that runs on top of PostSharp and it takes care of the hard work for you. PostSharp Laos offers some base classes which make it really easy for you to write your aspects (if you don’t understand that term, you should have clicked on the aspect oriented programming link earlier in the post ). There are a couple of approaches you can choose between, and they all have their pro’s and con’s. A nice overview of the different kinds of aspects you can inherit from can be found here. For this example, we’ll use the OnMethodInvocationAspect base class. This basically intercepts calls to methods and allows you to add some logic.

So what would our tracing aspect look like? How about this:



    [Serializable]
    public class TraceAspect : OnMethodInvocationAspect
    {
        public override void OnInvocation(MethodInvocationEventArgs eventArgs)
        {
            string methodName = GetFullMethodName(eventArgs);
            WriteOutput(String.Format("Entering {0}", methodName));
            WriteParameterInfo(eventArgs.Delegate.Method.GetParameters(), eventArgs.GetArgumentArray());
            base.OnInvocation(eventArgs); // calls the original method
            WriteOutput(String.Format("Leaving {0}", methodName));
            WriteReturnValueInfo(eventArgs.Delegate.Method.ReturnType, eventArgs.ReturnValue);
        }
 
        private static void WriteParameterInfo(ParameterInfo[] parameterInfos, object[] parameters)
        {
            if (parameterInfos == null || parameterInfos.Length == 0)
            {
                return;
            }
 
            WriteOutput("With the following parameters: ");
 
            for (int i = 0; i < parameterInfos.Length; i++)
            {
                WriteOutput(string.Format("{0} = {1}", parameterInfos[i].Name, parameters[i]));
            }
        }
 
        private static void WriteReturnValueInfo(Type returnType, object returnValue)
        {
            if (returnType == typeof(void))
            {
                return;
            }
 
            WriteOutput(string.Format("Return Value: {0}", returnValue));    
        }
 
        private static string GetFullMethodName(MethodInvocationEventArgs args)
        {
            return args.Delegate.Target.GetType().FullName + "." + args.Delegate.Method.Name;
        }
 
        private static void WriteOutput(string line)
        {
            Trace.WriteLine(DateTime.Now.TimeOfDay + " " + line);
        }
    }

So now we have a trace aspect which shows some valuable information about method calls… it shows when the method is entered, which parameters were passed in, when we leave the method and what the return value is.

So how do we apply this aspect to our code? We modify the definition of the Calculator class like this:



    [TraceAspect]
    public class Calculator

And then we compile… Well actually you have to add something to your project file so PostSharp can modify the compiled code, but since that’s covered nicely in the PostSharp documentation we’ll skip that step in this post. Anyways, when you compile this, you’ll get the following build output:


------ Build started: Project: UsingPostSharp, Configuration: Debug Any CPU ------

C:\WINDOWS\Microsoft.NET\Framework\v3.5\Csc.exe /noconfig /nowarn:1701,1702 /errorreport:prompt /warn:4 /define:POSTSHARP;DEBUG;TRACE /reference:..\Libs\postsharp\PostSharp.Laos.dll /reference:..\Libs\postsharp\PostSharp.Public.dll /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll" /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Data.DataSetExtensions.dll" /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Xml.Linq.dll" /debug+ /debug:full /filealign:512 /optimize- /out:obj\Debug\UsingPostSharp.exe /target:exe Program.cs Properties\AssemblyInfo.cs TraceAspect.cs
Compile complete -- 0 errors, 0 warnings

"C:\mydocs\src\dbr\Experiments\UsingPostSharp\Libs\postsharp\PostSharp.exe"  "C:\mydocs\src\dbr\Experiments\UsingPostSharp\Libs\postsharp\Default.psproj" "C:\mydocs\src\dbr\Experiments\UsingPostSharp\UsingPostSharp\obj\Debug\UsingPostSharp.exe" "/P:Output=obj\Debug\PostSharp\UsingPostSharp.exe " "/P:ReferenceDirectory=C:\mydocs\src\dbr\Experiments\UsingPostSharp\UsingPostSharp " "/P:Configuration=Debug " "/P:Platform=AnyCPU " "/P:SearchPath=bin\Debug\, " "/P:IntermediateDirectory=obj\Debug\PostSharp " "/P:CleanIntermediate=False " "/P:MSBuildProjectFullPath=C:\mydocs\src\dbr\Experiments\UsingPostSharp\UsingPostSharp\UsingPostSharp.csproj " "/P:SignAssembly=False " "/P:PrivateKeyLocation= "

PostSharp 1.0 [1.0.9.365] - Copyright (c) Gael Fraiteur, 2005-2008.

info PS0035: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ilasm.exe "C:\mydocs\src\dbr\Experiments\UsingPostSharp\UsingPostSharp\obj\Debug\PostSharp\UsingPostSharp.il" /QUIET /EXE /PDB "/RESOURCE=C:\mydocs\src\dbr\Experiments\UsingPostSharp\UsingPostSharp\obj\Debug\PostSharp\UsingPostSharp.res" "/OUTPUT=C:\mydocs\src\dbr\Experiments\UsingPostSharp\UsingPostSharp\obj\Debug\PostSharp\UsingPostSharp.exe" /SUBSYSTEM=3 /FLAGS=1 /BASE=4194304 /STACK=1048576 /ALIGNMENT=512 /MDV=v2.0.50727

UsingPostSharp -> C:\mydocs\src\dbr\Experiments\UsingPostSharp\UsingPostSharp\bin\Debug\UsingPostSharp.exe

========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

If we use the calculator class like this:



            var calculator = new Calculator();
            calculator.Add(10, 15);
            calculator.Subtract(10, 15);

We’ll get the following trace output:


21:48:49.9414848 Entering UsingPostSharp.Calculator.~Add

21:48:49.9615136 With the following parameters:

21:48:49.9615136 firstValue = 10

21:48:49.9615136 secondValue = 15

21:48:49.9615136 Leaving UsingPostSharp.Calculator.~Add

21:48:49.9615136 Return Value: 25

21:48:49.9615136 Entering UsingPostSharp.Calculator.~Subtract

21:48:49.9615136 With the following parameters:

21:48:49.9615136 firstValue = 10

21:48:49.9615136 secondValue = 15

21:48:49.9615136 Leaving UsingPostSharp.Calculator.~Subtract

21:48:49.9615136 Return Value: -5

How nice is that? With some exception handling, better formatting and some clever indenting, this tracing aspect could be the only tracing code you’ll ever need from now on

So how does it work? Well, we can look at the compiled code in reflector for that. Here’s how the Add method looks like after PostSharp modified the code:


    private int ~Add(int firstValue, int secondValue)

    {

        return (firstValue + secondValue);

    }
    [DebuggerNonUserCode, CompilerGenerated]

    public int Add(int firstValue, int secondValue)

    {

        Delegate delegateInstance = new ~PostSharp~Laos~Implementation.~delegate~0(this.~Add);

        object[] arguments = new object[] { firstValue, secondValue };

        MethodInvocationEventArgs eventArgs = new MethodInvocationEventArgs(delegateInstance, arguments);

        ~PostSharp~Laos~Implementation.TraceAspect~1.OnInvocation(eventArgs);

        return (int) eventArgs.ReturnValue;

    }

As you can see, it’s renamed our Add method to ~Add, and it added another Add method which calls the OnInvocation method of our TraceAspect class with the correct MethodInvocationEventArgs. Pretty cool stuff IMO. Oh and btw, if you’re debugging this code in Visual Studio, you still only see your own code, with the original method name. While you step through it, the code runs just like it normally would, and the applied aspects are also executed. Very impressive.

If you use the OnMethodBoundaryAspect instead of the OnMethodInvocationAspect, you’ll see that the modified code doesn’t replace your method like it did here. But it will add a lot of extra code to it as well. All in all, there are a lot of possibilities here. If i’m not mistaken, i can now even use our TraceAspect and use it on classes in other assemblies, even if i don’t have access to them. We’ll look into that in a future post

Anyway, PostSharp is an extremely impressive piece of software which provides a whole lot of power and flexibility. You should definitely check it out and play around with it… i know i’m gonna be experimenting with it more often to see what kind of weird and cool stuff we can make it do

Adding behavior without modifying existing code with Windsor

Davy Brion — Sun, 04 May 2008 20:18:27 +0000

The Windsor container makes it quite easy to add behavior to components, without having to modify their implementation. This could be useful in many scenario’s. Suppose you need to log whenever a method from our OrderRepository class is called. But we should be able to turn the logging on and off whenever we want. Preferably, without having to modify the code all the time. Now, you could easily write a logger class that checks for a configuration setting and only logs when needed. This approach would definitely work. But then there’s logging code all over the OrderRepository class and in most cases, it’s not even necessary since they only want to be able to log under certain circumstances. Should the OrderRepository class really care about the logging? Why litter the code with logging statements?

If you’re using the Windsor container, you could easily add logging behavior to the OrderRepository class without having to change any of the existing code. Windsor has this concept of Interceptors. Basically you can assign an interceptor to any component and you can plug in your custom behavior when the component is called. Lets get into an example… Since logging is such a common requirement, we decided to put it in one class instead of littering our entire code base with logging statements. So we wrote the following class:

    public class LoggingInterceptor : Castle.Core.Interceptor.IInterceptor
    {
        private readonly ILogger logger;
 
        public LoggingInterceptor(ILogger logger)
        {
            this.logger = logger;
        }
 
        public void Intercept(IInvocation invocation)
        {
            string methodName = 
                invocation.TargetType.FullName + “.” + invocation.GetConcreteMethod().Name;
            Log(“Entering method: “ + methodName);
            invocation.Proceed();
            Log(“Leaving mehod: “ + methodName);
        }
 
        private void Log(string line)
        {
            logger.WriteLine(DateTime.Now.TimeOfDay + ” “ + line);
        }
    }

This class implements the IInterceptor interface by implementing the Intercept method. When that method is called we simply construct the full method name, log when we enter the method, call the original method and then we log again when we leave the method. Nothing more, nothing less. Also notice how the LoggingInterceptor has a dependency on an ILogger instance. That instance will be injected by the container as well.

So first of all, we need to define the ILogger and LoggingInterceptor components:

      <component id=“ILogger“ service=“Components.ILogger, Components“ 
                 type=“Components.Logger, Components“ />
 
      <component id=“LoggingInterceptor“ service=“Components.LoggingInterceptor, Components“
                 type=“Components.LoggingInterceptor, Components“
                 lifestyle=“transient“ />

Right… so now we need to add this behavior to the OrderRepository class. This only requires modifying the registration of the IOrderRepository component:

      <component id=“IOrderRepository“
                 service=“Components.IOrderRepository, Components“
                 type=“Components.OrderRepository, Components“>
 
        <interceptors>
          <interceptor>${LoggingInterceptor}interceptor>
        interceptors>
 
      component>

What we basically did was tell Windsor that whenever an IOrderRepository is requested, we should return an instance of OrderRepository and each time a method of that instance is called, it needs to be intercepted by our LoggingInterceptor.

So if we simply call the IOrderRepository methods like this (obviously these are dummy calls without real parameters and we’re also ignoring return values):

            var repository = Container.Resolve<IOrderRepository>();
 
            repository.GetAll();
            repository.FindOne(new Criteria());
            repository.FindMany(new Criteria());
            repository.GetById(Guid.Empty);
            repository.Store(null);

The following output is logged:

21:53:42.6942016 Entering method: Components.OrderRepository.GetAll
21:53:42.6942016 Leaving mehod: Components.OrderRepository.GetAll
21:53:42.6942016 Entering method: Components.OrderRepository.FindOne
21:53:42.6942016 Leaving mehod: Components.OrderRepository.FindOne
21:53:42.6942016 Entering method: Components.OrderRepository.FindMany
21:53:42.6942016 Leaving mehod: Components.OrderRepository.FindMany
21:53:42.7042160 Entering method: Components.OrderRepository.GetById
21:53:42.7042160 Leaving mehod: Components.OrderRepository.GetById
21:53:42.7042160 Entering method: Components.OrderRepository.Store
21:53:42.7042160 Leaving mehod: Components.OrderRepository.Store

And we didn’t have to change the OrderRepository implementation. In fact, we can use our LoggingInterceptor wherever we like, as long as the component to be logged is registered with Windsor. And we can easily switch between logging or no logging by switching config files.

Obviously, this was just a really simple example but i hope you realize how powerful this technique is and how far you can go with this.