New version of SAPIT available

Well, it's been a long while since my latest blog entry, so I figured it was about time to do something about it.

I have just uploaded a cleaned up version of SAPIT (sapit.codeplex.com) for anyone to play with. There are a few breaking changes to be aware of: I have deleted the parametrized attribute constructors, so they can only be called with named parameters. I think this is more readabled since some of the attributes take 4 parameters, and now you're forced to name each parameter.

If you hang out in the Copenhagen area, you can come and hear me give a talk on AOP and SAPIT at the Copenhagen .NET User Group (CNUG) event on October 4th: http://www.eventbrite.com/event/2105414351/eorg

 Also, I'm working on a few extra blog entries about books I've been reading lately ... stay tuned :-)

On adding support for StructureMap to Sapit

I got a request for adding support for StructureMap to Sapit, and being the challenge-loving type, of course I set out to implement it. I thought, how hard could it be? As it turned out, quite hard!

What separates StructureMap from Unity, Windsor and PostSharp that Sapit already supports, is that StructureMap does not by itself provide a means to do method interception, which is what Sapit is all about. To apply for instance caching to a method, Sapit needs to intercept the calls to the method, invoke some caching logic, let the method call proceed, and then pick up the return value, cache it and return it to the caller. Without a means to intercept the method call, Sapit has no value.

So what to do? Well, after trying to find a way to intercept the call by manually generating a generic proxy (via the .NET 4 DynamicObject class), I got the idea to use Castle DynamicProxy instead. A lot of third party libraries use DynamicProxy under the covers, because it really is a great tool to gain full control over your objects.

However, so far I've not been able to get it to do, what I want. What I want is to use DynamicProxy within a StructureMap type instantiation interceptor to generate a dynamic proxy object with all the right features. The proxy object should wrap the "real" object, expose the same exact interfac as the real object, and have the same set of attributes applied to each method. Until now, I can make DynamicProxy generate a proxy object, but it does not expose the right interface.

If anybody out there has some documentation on how to use DynamicProxy, or perhaps some sample code demonstrating how to use it, I would really appreciate a hint. Meanwhile I will continue to try implementing StructureMap support in Sapit, and I will keep you informed on any progress.

Sapit - now with Retry functionality added

New functionality

I have just checked in an updated version of Sapit (Codeplex). Included now is the Retry attribute, that automatically retries failed method calls.

How to use Sapit

I figured i was about time I threw in a little documentation on how to apply Sapit to your code. The table below describes each of the 5 attributes and their parameters.

Atrtibute	Parameter	Meaning
Cache	Caches the result of the method call.
	CacheSeconds	The number of seconds to cache the result
CircuitBreaker	Monitors the method for exceptions, and if too many consecutive calls fails, it shuts off the method for a period of time.
	MaxConsecutive-Failures	The maximum number of consecutive failures before the method is shut off
	ShutOffPeriodSeconds	The number of seconds to leave the method shut off
	BehaviorWhen-ShutOff	How to react to method calls when shut off, return af default value or throw an exception
	ShutOffReturnValue	The default value (or exception message) to return
ResponseTimeThrottle	Throttles away calls to a method when the response time rises above a given threshold
	ThrottleThreshold-Milliseconds	The maximum response time before throttling sets in
	SkipCallsWhen-Throttling	How many calls to throttle away when throttling
	BehaviorWhen-Throttling	How to react to method calls when throttling, return af default value or throw an exception
	ThrottleReturnValue	Caches the result of the method callThe default value (or exception message) to return
Retry	Retries failed method calls up to a given number of times before giving up.
	TimesToRetry	The maximum number of times to retry the metod call before giving up
Timeout	Aborts method calls taking longer than a given limit.
	TimeoutMilliseconds	The number of milliseconds before aborting the method call

Each of the above attributes are defined in each of the assemblies Sapit.PostSharp.dll, Sapit.Unity.dll and Sapit.Windsor.dll, and they functionality in the assembly Sapit.dll. This means, that when you wish to include Sapit in your project, you only need to add a reference to Sapit.dll and to Sapit.<your IoC>.dll, where <your IoC> is your IoC of choice, PostSharp, Unity or Windsor. After adding these two references, you just apply the appropriate attributes to the methods you want. The only thing left is to configure your IoC (this is only true of Unity and Windsor, since PostSharp simply alters the MSIL after compilation).

Configure your IoC to use Sapit

Unity
Use the following code to configure Unity to use Sapit, where IMyInterface is the interface for the class MyImplementation:
IUnityContainer container = new UnityContainer();
ServiceProvider.IUC = container;
container.AddNewExtension<Interception>();
container.RegisterType<IMyInterface, MyImplementation>();
container.Configure<Interception>().SetInterceptorFor<IMyInterface>(new TransparentProxyInterceptor());

Windsor
Use the following code to configure Windsor to use Sapit, where IMyInterface is the interface for the class MyImplementation:
WindsorContainer ioc = new WindsorContainer();
ServiceProvider.IWC = ioc;
ioc.Register(Component.For<CacheInterceptor<string>>());
ioc.Register(Component.For<CircuitBreakerInterceptor>());
ioc.Register(Component.For<ResponseTimeThrottleInterceptor>());
ioc.Register(Component.For<TimeoutInterceptor>());
ioc.Register(Component.For<RetryInterceptor>());
ioc.Register(Component.For<IMyInterface>()
.ImplementedBy<MyImplementation>()
    .Interceptors<CacheInterceptor<string>>()
    .Interceptors<CircuitBreakerInterceptor>()
    .Interceptors<ResponseTimeThrottleInterceptor>()
    .Interceptors<TimeoutInterceptor>()
    .Interceptors<RetryInterceptor>());

Feedback?

Please let me know if you find bugs in the code, errors in the above documentation, or if there is something unclear.
Also, I am very open to suggestions and requests for improvements and more features.
Enjoy :-)

How the deal with external systems?

The problem

When developing solutions today, we almost always have to connect to external systems. These connections come in all shapes and sizes, from accessing a file system or connecting to a database, to transferring files to or from an FTP server, or to call a web service or an enterprise service bus.

When connecting to external systems, we are exposing our own system to risks. And I am not talking about security risks like vira, malware, evil hackers and the likes, but I am talking about the risks of performance degradation, scalability issues, dependencies upon the status of the external systems, poor user experience and more. If we are not very careful when we design our solutions, all bets are off when the external systems slow down, become unstable or even shut down. If we fail to take such situations under consideration, the state of the external system dependencies dictate the state of our system – if just one external system is down or unstable, our system will be down or unstable too. So when building large systems with many external dependencies, making sure our system keeps running, can become a real nightmare.

Ways to deal with external dependencies

In his excellent book “Release IT!”, Michael T. Nygard writes a lot of good advice on how to deal with external dependencies. He describes several patterns and techniques that are useful for lowering the risks of external systems damaging the performance and stability of our system. Other great minds have further elaborated on the topic in books, blogs and presentations, and we now have an arsenal of patterns and techniques at our disposal. I will briefly sum up four of these here:

Caching is a technique where you hold on to a result from a call to an external system for a while, and reuse this result instead of making subsequent calls to the external system.

Circuit Breaker is a pattern where you keep tabs on whether the calls to an external system fail or succeed. If the calls begin to fail, you register the external system as being down and stop making calls to the external system. After a while you try passing a few calls on to the external system to see if it is up and running again.

Response Time Throttling is a technique where you monitor the time each call to an external system takes, and if the response time rises above a certain threshold, you filter off some of the calls to the external system. Thereby your system does not put additional strain on the external system, and hopefully the external system will eventually come up to speed again.

Timeout is a technique where you stop waiting for response from an external system when a certain response time threshold is reached. You basically abandon your request and return an error message back to the caller saying that the timeout has expired.

The standard solution

Usually some or all of the above patterns and techniques are being built into our systems, but very often people are reinventing the wheel over and over again. There are so many different ways to include these techniques in the interaction with external systems, and the result of this is more often than not a bit messy. As an example, take a look at the following code:

public class ItemServiceGateway
{
   private static Dictionary<int, Tuple<List<Item>, DateTime>> _Cache = new Dictionary<int, Tuple<List<Item>, DateTime>>();
   private static int _SecondsToCacheResult = 30;

   public List<Item> GetItemsInCategory(int categoryId)
   {
      List<Item> results = GetResultsFromCache(categoryId);
      if (results != null)
      {
         return results;
      }
      else
      {
         results = GetResultsFromExternalSystem(categoryId);
         AddResultsToCache(categoryId, results);
         return results;
      }
   }

   private List<Item> GetResultsFromCache(int categoryId)
   {
      if (_Cache.ContainsKey(categoryId))
      {
         if (_Cache[categoryId].Item2.AddSeconds(_SecondsToCacheResult) > DateTime.Now)
         {
            return _Cache[categoryId].Item1;
         }
         else
         {
            _Cache.Remove(categoryId);
            return null;
         }
      }
      else
      {
         return null;
      }
   }

   private List<Item> GetResultsFromExternalSystem(int categoryId)
   {
      List<Item> results = null;
      // Make call to external system to get the results.
      return results;
   }

   private void AddResultsToCache(int categoryId, List<Item> results)
   {
      if (_Cache.ContainsKey(categoryId))
      {
         _Cache.Remove(categoryId);
      }
      _Cache.Add(categoryId, new Tuple<List<Item>, DateTime>(results, DateTime.Now));
   }
}

The above code is a simplified but very realistic way of implementing a cache around a single call to an external system. Now multiply the above code by the number of external system calls your system makes … And yes, I am aware that this implementation is not thread safe, but this just amplifies my point: It takes a lot of time and effort to include these techniques and to make them work correctly and robust.

The problems with the standard solution

From the above code it is obvious that implementing your own cache for every external system call is not a very efficient way to go. Your system will end up being 90% plumbing code and 10% actual value-adding code. The development costs will be very high, the maintenance costs will be very high, and the potential for errors will be very high.
One of the biggest problems, in my opinion anyway, is that the above code obscures the intent of the code. You can’t really see the forest for the trees. In fact, the call to the external system is buried in one of the private helper methods, so if will take longer to grasp what really goes on, when a call to GetItemsInCategory is made.

Wouldn’t it be nice, if the code looked something like this instead?

   public class ItemServiceGateway
   {
      [Cache(30)]
      public List<Item> GetItemsInCategory(int categoryId)
      {
         List<Item> results = null;
         // Make call to external system to get the results.
         return results;
      }
   }

Well, that is my goal with Sapit!

Sapit to the rescue

I am working in my precious spare time to make the above code work like you would expect it to: Keep a cache of results from the external system, each with a validity period of 30 seconds, and avoid calling the external system, if we already have the results in the cache.

I have built Sapit (Small And Powerful Integration Toolkit) and put it on Codeplex. Included in the source code is a small WinForms project, that demonstrates the use of each of the currently supported features.

Sapit uses Aspect Oriented Programming (AOP) to intercept calls to methods and it includes all four of the above mentioned patterns and techniques, Cache, Circuit Breaker, Response Time Throttle and Timeout. This means that all you have to do to apply, say, the Circuit Breaker pattern to a method, is to apply the following attribute to the method:

[CircuitBreaker(3, 20, Behavior.ThrowException, "Service is down")]

The meanings of the parameters are:

• number of consecutive calls to throw exceptions before we shut off the external system (3 calls),
• the minimum time to wait before we try to call the external system again (20 seconds),
• the behavior when the external system is shut off (throw an exception / return a hard-coded value),
• the value to return or exception message to use when the external system is shut off (“Service is down”)

Sapit is quite self-explanatory, and I have not yet written any documentation for it, but I encourage you to have a look at the source code for the client application included, as it demonstrates how to apply the different attributes.

At the time of writing, Sapit comes with a few limitations.
.NET only – Even though I have a very distant background in the java realm, I have been a .NET developer for a decade now, so Sapit is written in C#.
Thread safety – Sapit does not have this yet. I am working on it currently.
IoC containers – You have to use either Castle Windsor, PostSharp or the Unity Application Block to instantiate the classes you decorate with Sapit attributes, and depending on which IoC container you use the steps to follow differ a bit. It is fairly easy to add support for other IoC containers, so please let me know you use a different one.
Multiple attributes on a single method – I have not tested this at all. Some combinations might work, some might wreak havoc. I am currently working on making Sapit robust in this area.

Next steps

So where do I go from here? Actually, I am hoping for some feedback from you guys. Should I include some more patterns and techniques (which ones?), should I add support for other IoC containers (which ones?), or is Sapit applicable in it’s current form?

I am counting on you guys here!
Please have a look at Sapit, try applying some of the attributes to your own code, and enjoy the cleanliness of code that (hopefully) emerges.
And please, let me know what you think about Sapit, thanks :-)

Inspirational reading material

I've been reading a lot of books during the last few years ... it feels like I've stumpled upon a huge pile of books, that all seem really important for me to read. Every time I finish a book, the backlog of books in front of me has grown with 3-5 books, that I simply must read. Articles as well are piling up, and it sometimes strikes me, that maybe I am not going to catch up - maybe I am going to have to filter some of the books or articles away ... sigh ...

Anyway, I find all kinds of litterature a great source of inspiration, and therefore I spend a lot of time reading. Surprisingly (to me at least) most of the books I've read recently have turned out to be really great books. Books that made me think a lot about how I work and write software, books that have actually changed my ways of doing these things. When I experience these books having such an effect on me, it is hard for me to resist the temptation to share the knowledge I've attained.

So have made two lists for You to have a look at:

A few of the books I've enjoyed reading and

A few of the books I'm looking forward to reading

Currently I am reading Andy Hunts book Pragmatic Thinking and Learning, a very interesting book about how our minds work, how to improve our brainfunction, and how to attain higher levels of expertice. I hope to finish reading it in about a week, and then I'll post a more thorough review of it here.

How much time do we have?

To night I saw a movie called School Of Life, featuring Ryan Reynolds as an off-the-charts charismatic school teacher. The movie was "above average", but the thing that stuck with me afterwards was this motto Ryan had in the movie. He asked his pupils rhetorically: "How much time do we have?", and he answered the question: "Not a lot!" His point was, that with only a limited time in this life, you better really make every moment count.

Now how does this relate to software development?

Well, my thoughts were along the lines of: Take pride in your work, and make sure you produce high quality software every day.

While this makes sense, I suddenly realized that this motto can be seen as a recommendation of agile development: With only a limited time before the deadline of the project, make sure you spend you time working on the most important things at all times.

This is part of the definition of most agile methodologies, and in my humble opinion, the most significant one. The fact that the customer knows, that we as developers always focus on the customer's top priority tasks, is what it's all about!

That is how we get the customer to buy into the agile way of running projects.

That is how we make sure, that the customer ends up with a system, that works the way the customer wants, and that the end users will enjoy using.

That is how we as vendors will gain customer satisfaction, repeat business and success in the market.

So if you are using a non-agile methodology, I'd say it's about time to begin looking into topics like agile, Scrum, TDD / BDD, etc.

We don't have much time, so we better make it count!

Working Effectively with Legacy Code - part 2

One of the biggest challenges, when it comes to adding tests to legacy code systems, is dependencies between different parts of the system. Dependencies comes in lots of different flavours, some of which are: Constructor parameters that must be supplied, properties that must be set, globals being referenced from anywhere, external libraries being used, framework APIs being used, databases, and also all kinds of physical devices like discs, printers, etc.

The problem with dependencies are, that if you want to test a class in a way, that isolates that class from anything else, so you can easily detect changes in functionality, the dependencies must be taken out of the picture. If not, a potential failure could be caused not only by the code we touched, but also by anything that code depends upon. You need to be able to construct an object of the class under test in an way, where you are able to control the object's environment completely.

So how do you remove dependencies? Well, it depends ... (pun fully intended)

In the book "Working Effectively with Legacy Code", Michael Feathers includes a wealth of techniques for breaking dependencies - in fact, about the last third of the book is dedicated to this very topic. And the really great thing is, not only does he teach us a lot of techniques, he also attempts to bestowe within us, the wisdom to choose the optimal technique for any specific type of problem and dependency. Let me just give a very few highlights about constructor parameter dependencies here:

• If you control the source code for the parameter classes, you should be able to inherit those classes to make fakes, and just use those during tests.
• If you don't control the source code, you could create a new class, that wraps the parameter object (a proxy if you will), refactor the constructor to use this new class instead of the parameter class, and have it behave differently during test than when in production.
• A third technique could be to use mocking to abstract away the dependencies.

A few highlights about references to globals too:

• You could wrap your globals in a static class, that exposes those through static properties, and making the properties behave differently during test than when in production.
• You could try to remove the global all together by injecting the value as a constructor parameter or as a property.

These techniques and many more are explained in the book in crystal clear details, and with example code to match. As I read through the book, I can't help but thinking, that I should have read this book back in 2005, when it was published, because it would have saved me so much pain and anguish by now ... well, in this case, the phrase "better late than never" is very appropriate: These techniques will continue to be valuable for a long time. So no excuses left - Read the book!