Introduction to AOP with Coldspring – Chris Scott

Notes from Chris Scotts talk on AOP at Frameworks 2007. For those reading back, you’ll know AOP is something I’ve been interested in for a while. Chris Scott has a series of articles on Aspect Oriented Programming.

The main purpose of it is to reduce code by creating code that is very loosely coupled with your business objects. Why should we use AOP? If you’re using OOP, you’ll have objects representing various people places and things that your application deals with. These are the concrete objects that do one thing and do them well. However some objects often need to take part in more abstract parts of your application such as transactions, security, caching and logging. These are abstract systems that are used by many parts of your application, dubbed “Cross Cutting Concerns”.

AOP gives you a way of applying the behavior. Chris shows some example code without AOP that has logging capability by adding logging functions to a specific cfc. For another object to implement this logging we’ll have to duplicated it elsewhere as well. Two central concepts to AOP: Interception and Introduction. Coldspring AOP is ONLY let you work with method interception.

Things like AspectJ in java allow for Introduction. We want to intercept methods when they’re called and either wrap code around them, before, after or in an error. These methods are called “Join Points”. The code we wrap around is known as “Advising” which is done by extended certain “Advice” methods. Chris goes over the various types of advice and their actual terms (BeforeAdvice, etc).

Advice are basically Decorators using the decorator pattern. These enhance functionality on the Join point, by calling that method on the wrapper advice object which will do it’s part then call that function on the object it’s extendig. AOP Proxies are like decorators but they do not add additional functionality. The advantage of this is you can have a proxy for an object or for a decorated object and it’ll work the same.

Advisers are used for interception, advice is used for introduction (i think i got that right?).

Adviser is a guy walking two dogs- a little rat dog and a big bulldog. The little rat dog finds the fire hidrent and the bulldog pees on it. Adviser is basically just a way of peeing on things. – Chris Scott (paraphrased)

To add logging to an existing component you’ll need a few things. Your LoggingService, which contains all your functions and knows nothing about Coldspring. Also your LoggingAdvice which extends coldsprings AOP advice. The loggingAdvice object when defined in Coldsring will take in the LoggingService reference. The advice will call methods on the logging service when needed.

The last object is the Advisor (the guy walking the dog) which is a native CS object defined completely in coldspring using something lke coldspring.aop.support.NamedMethodPointcutAdviser. You’ll need to pass in the cs reference to the LoggingService and the Advice. Now to actually add advice to something, like if you want to add logging whenever a comment to a blog system is created, you’ll add another adviser for comment (CommentAdvisor) with a target (method name, in this case whatever is used to create a coment) and interceptorNames (LoggingAdvisor, the adviser you want to use when this method is executed).

Abstracts are large systems, composed of many components or classes. AOP defines the way these can reused and applied to other objects without either system knowing about the other. You can add additional methods to a call besides the required ones.

This cs_log attribute can be accessed from your logging advisor and dynamically log based on that information. This offers a fine grained approach to applying advice using function metadata. Chris shows a caching adviser that caches all database calls. This enables the mysql server to be stopped and the application still function correctly for everything that was accessed while the cache was collecting information.

Instead of just caching everything, you need additional information about caching, such as the keys, the type, the name. These can be added to the service object in tag as metadata as well. Instead of adding just one interceptor (where we added loggingAdviser) we can add a second cacheAdviser and anything else. In the adviser cs declaration you can patch against a patterns.

Chris’s example caches everything that doesn’t begin with set*. New feature in Coldspring for creating template interceptorNames. Basically you can create one object that has all your interceptors (cache, log, security) and then when you want to use that, you’ll use the parent attribute in coldspring and reference that bean. Then you’ll only have to provide the target (the names of the methods you want to use that advice for) and you’re set.

This allows for not only a single place for your code (the advisor), but a single location to declare all advisors rather than adding them to each object. Coldspring security aspect that uses role based authentication and metadata. This is available in the current LitePost application now, but it will be moved into Coldspring (free code!). Instead of creating remote facades for using services with flex, you can create a coldspring.aop.framework.ProxyFactgoryBean and provide all the target, serviceName, relativePath, interceptorNames and remoteMethodNames allowed. Now you can create any proxy for flex automatically. Have to look into this a lot more. Related reading: Head First Design Patterns chapters on Adapters, Proxy and Decorators. Coldspring site . LitePost .