Monday, December 19, 2005

Initial impressions after my first contact with Spring AOP

I have been looking into Aspect Oriented Programming(AOP) and following some HelloWorld AOP examples from OnJava. My interest stems from my current investigations into using the Spring Framework.

AOP suffers from being very densely populated with specialised terminology. Often times the terms are defined using further dense terminology which has the effect of placing an impenetrable barrier in front of the precise meaning. For example, I found the following definition typical in a AOP glossary of terms:

Weaving
The process of coordinating aspects and non-aspects. In a language like AspectJ, one part of weaving is ensuring that advice executes at the appropriate dynamic join points. Weaving can be done explicitly or implicitly, and can be done at a variety of times ranging from by-hand weaving when code is written, through compile-time, post-compile time and load time, up to runtime.

Yeah, that makes lots more sense now... obvious really, what was I thinking? Thanks for clearing that up for me... ;>)
Roll on, AOP for Dummies.

It seems that Spring concentrates on implementing a single aspect of AOP (pardon the pun), the method interceptor (which implements org.aopalliance.intercept.MethodInterceptor) . Spring advocates the use of full-blown AOP frameworks such as AspectJ to conduct more complex AOP if this becomes necessary.

Spring performs method interception in a way that is analogous to a Servlet filter. You can even specify regular expressions in order to filter which methods to match. There is also something of the Listener/Observer design pattern about method interception, if you assume that the "event" it listens out for is a method call.

It seems you can add AOP enabled method interception in a way that is transparent to the rest of the logic. This seems fine if you are doing something that is not really integral to the primary aims of the code where it makes sense to do things in parallel such as logging, tracing and profiling. I am slightly concerned at the appropriateness of using AOP methods to do things that probably should be part of the natural flow of the program, like transaction support and to some extent caching. Running these aspects in parallel means you can turn them on and off for debugging purposes but because they are running in parallel to the core code it may be more difficult to trace what is actually going on.

In many ways Caching seems an ideal candidate for the AOP approach. It is interesting to see members of the Spring community providing plugin support for several alternate caching mechanisms (such as Memory HashMap, EHCache, OSCache (which is clusterable), SwarmCache and potentially Prevayler). I must admit I found it a little confusing that Spring implements a EHCache factory bean to make EHCache configuration easier and this is completely unconnected with the use of Caching in an AOP context. In an AOP context, what you are essentially caching is the responses to method calls and this *could* easily be subtly different to caching specific content and therefore may not be want you really want.

Spring's BeanFactory enables me to write loosely coupled code and I'm starting to see why this might be a good thing. However, I'm still waiting for the AOP penny to drop, I expect I need a bit more weaving practice.

0 comments: