Introduction to ColdSpring AOP
Aspect Oriented Programming is a fairly new programming model that assists in handling far reaching services, like logging, security, transactions and object caching, in your model. Services like these are beginning to be referred to as ‘crosscutting concerns’, because they are applied broadly across your application. In order to add a service such as logging to an application, you typically find yourself applying very similar code all throughout your model, which when scrutinized, probably has nothing to do with the actual functionality of your components. AOP allows you to insulate these types of crosscutting concerns from the rest of you application, and apply them broadly based on certain policies that you as the developer define.
Using AOP is basically a process of looking at the types of concerns in your application and then breaking them apart into primary concerns, like your managing your shopping cart or navigating through and administering your product catalog, your application’s primary business logic, and crosscutting, generalized concerns, such as logging and security. These crosscutting concerns become what are known as ‘aspects’, and with AOP can be written singularly focused on the issues they solve, becoming more portable and reusable. These aspects are then applied to your model according to policies that you define, through a process known as ‘weaving’, which is performed by the AOP framework.
Defining policies is a matter of identifying ‘join points’ in your model, specific areas where you would like to apply the ‘advice’ of your aspects, meaning the specific action that you would like to take place at a certain time in your application. Join points are created using ‘pointcuts’ which are defined with wildcards or regular expressions to identify methods in your objects. Don’t get too worried about the terminology here; the primary concept is that you already have objects with methods in them that you want to add functionality to. You do this through advice. There are three types of advice available in ColdSpring AOP, before, after, and around advice. Before advice is run before the join point will be performed; after advice will be run after the join point. Around advice is like a combination of both. Around advice is actually quite powerful because it is given full control of the execution of the join point and it has the ability to advise errors through try/catch blocks.
The final concepts to understand in AOP are ‘target’ and ‘proxy’ objects. The target object is object in your model that you want to apply your aspects to. Through the process of weaving, the AOP framework will use the policies you defined via pointcuts to build a new proxy object containing the configured advice, which, and here’s the most important part, appears to be one in the same as the target object to the rest of your application. Now I know a lot of this is sounding confusing and a bit difficult, but it’s important to understand that most of the work is actually done for you. You will primary concern yourself with creating the advice objects themselves. Pointcuts are defined through configuration and ColdSpring AOP handles the rest. In the context of ColdSpring, the configuration is done through an xml file, and the proxy object can be swapped out for the target object with minimal effort.
I’ll post some actual examples after I get a chance to run through them at the conference and get some feedback. Hopefully I’ll get a chance to meet a few people who just may have read some of this there!
Using AOP is basically a process of looking at the types of concerns in your application and then breaking them apart into primary concerns, like your managing your shopping cart or navigating through and administering your product catalog, your application’s primary business logic, and crosscutting, generalized concerns, such as logging and security. These crosscutting concerns become what are known as ‘aspects’, and with AOP can be written singularly focused on the issues they solve, becoming more portable and reusable. These aspects are then applied to your model according to policies that you define, through a process known as ‘weaving’, which is performed by the AOP framework.
Defining policies is a matter of identifying ‘join points’ in your model, specific areas where you would like to apply the ‘advice’ of your aspects, meaning the specific action that you would like to take place at a certain time in your application. Join points are created using ‘pointcuts’ which are defined with wildcards or regular expressions to identify methods in your objects. Don’t get too worried about the terminology here; the primary concept is that you already have objects with methods in them that you want to add functionality to. You do this through advice. There are three types of advice available in ColdSpring AOP, before, after, and around advice. Before advice is run before the join point will be performed; after advice will be run after the join point. Around advice is like a combination of both. Around advice is actually quite powerful because it is given full control of the execution of the join point and it has the ability to advise errors through try/catch blocks.
The final concepts to understand in AOP are ‘target’ and ‘proxy’ objects. The target object is object in your model that you want to apply your aspects to. Through the process of weaving, the AOP framework will use the policies you defined via pointcuts to build a new proxy object containing the configured advice, which, and here’s the most important part, appears to be one in the same as the target object to the rest of your application. Now I know a lot of this is sounding confusing and a bit difficult, but it’s important to understand that most of the work is actually done for you. You will primary concern yourself with creating the advice objects themselves. Pointcuts are defined through configuration and ColdSpring AOP handles the rest. In the context of ColdSpring, the configuration is done through an xml file, and the proxy object can be swapped out for the target object with minimal effort.
I’ll post some actual examples after I get a chance to run through them at the conference and get some feedback. Hopefully I’ll get a chance to meet a few people who just may have read some of this there!
3 Comments:
Good stuff, keep it coming. :)
's funny how ppl take a jaundiced view of AOP (http://www.mail-archive.com/cfcdev@cfczone.org/msg06046.html) when really it's just another useful tool if you need it. Perhaps AOP itself (not specifically ColdSpring's implementation) has been as a band-aid fix as a last resort, instead of designing a well thought out system.
Hopefully Coldspring's AOP usage will allow ppl to realise that's it's worthwhile for it's own sake.
(footnote: we didn't get Aspectwerks' AOP in to help with our grief: we developed another bolt-on system that won't be as good in the long run. If we'd started with coldSpring a year ago things might be very different...)
I think once we get this out and people can get a feel for working with aop, they're going to find it pretty simple. I don't know about using aop as a band-aid solution, aop is an architectural shift. It's not about adding complexity to a system by any means. It should definitely be doing the opposite. There's a reason why wikipidia calls logging the 'prototypical crosscutting concern', it's the perfect example of using aop to remove complexity and unnecessary functionality from your model components.
Post a Comment
<< Home