I wrote this piece as part of my work….
Aspect Oriented Programming is one of the programming paradigms where secondary or supporting functions are separated from the main business logic. The major objective is to increase the modularity by separating the secondary functionalities as crosscutting concerns. The main driving force behind the AOP was Gregor Kiczales, who worked on AOP at Xerox Palo Alto Research Center (PARC) and developed AspectJ which is one of the most popular AOP packages available today.
Basic Concepts
The basic concepts involved in Aspect Oriented Programming are:
1) Cross Cutting Concern: This refers to the secondary functionality which needs to be separated from the main business logic. For example, logging needs to be performed by classes in our data access layer and also by classes within our UI layer. Even though the major functionality of classes in UI and data access layer is separate but the secondary concern (i.e. logging) is common to both. So, in this case logging functionality forms a cross-cutting concern (term cross-cutting is used as the functionality needs to be implemented in such a way that it cuts across the main functionality).
2) Advice: The additional code that needs to be implemented whenever a cross cutting concern is involved. For example, this can be the logging code which needs to be implemented.
3) Pointcut: The point of execution in the application where cross cutting concern needs to be applied. For example, pointcut is reached when we need to log information before entering a method and we need to log information after exiting out of method.
4) Aspect: Aspect is simply a combination of the pointcut and advice. So, if we continue with our logging example, then logging aspect involves the advice (logging code to be implemented) and pointcut (point where we need to execute our advice).
Support for AOP
AOP is supported by variety of frameworks, platforms and languages. As of now, nearly every major J2EE platform (JBOSS, Spring, Weblogic, Websphere) is supporting AOP. AspectJ and AspectWerkz are two most popular packages available for AOP for use with Java. Moving apart from Java/J2EE world, AOP is also supported by .NET framework (both C# and VB.NET), C, C++, Perl, Python etc.
Implementation
AOP can be implemented via a process called weaving, which involves the use of an aspect weaver reading the aspect oriented code and weaving it (or simply put as generating) appropriate object-oriented code with all the aspects integrated. The weaving methodology is language independent and the only factors which govern the choice of weaving are 1) implementation and 2) ease of deployment. Weaving process can be done in two ways:
1) Source-level weaving: Source level weaving can be implemented using preprocessors having access to modify source code files. For example, in case of Java programming language, source level weaving can be performed via bytecode weavers which can work directly on compiled .class files. Bytecode weavers can work during codebuild, or during class loading. However, this approach causes problems as some of the third party decompilers or debuggers are unable to process the woven code as they understand the code generated by Java compiler rather than the one generated by the aspect weaver. AspectJ uses source-level weaving to generated aspect oriented code.
2) Deploy-time weaving: In order to avoid the problem associated with source-level weaving, deploy-time weaving use post processing whereby instead of modifying the existing code, we subclass existing classes and any modification is carried out via method overriding. The existing code thus remains untouched. This approach is commonly implemented in Java EE application servers, such as Websphere by IBM.
Problems with AOP
The use of AOP involves proper understanding of crosscutting concerns which sometimes can be a difficult task involving clear knowledge of static as well as dynamic flow of a program. If a developer commits any logical error while implementing crosscutting, the effect may be widespread. Also, if joinpoints are modified again it might lead to breakdown across the application.
Great writeup MM!
useful info: If you are using spring 3.0.3, stick to AspectJ weaving, as spring aop has limited support to the various interceptors available by default.
~rohit.
Tip top stuff. I’ll expcet more now.
Woot, I will cretalniy put this to good use!
Hi RK,
Thanks for your comments.
That's implementation driven choice. I might not be using Spring still I might be implementing AOP in my code.
What I would like to stress over here is while designing applications one should be clear about the features/limitations of the API being used.
If I need limited support for my interceptors in Spring 3.0.3 and Spring AOP suits my purpose well, why I would go for AspectJ.
Back in school, I’m doing so much learning.
AspectJ can be easily replaced with the default injected Spring AOP. I would not limit myself to a subset what AspectJ deviced and that too with a newer different terminology.
Creates more chaos.
~rohit.
What’s it take to boemce a sublime expounder of prose like yourself?
Well, RK, it seems you reiterated the point I made:
"That's implementation driven choice".
If you can replace Spring AOP with AspectJ and vice versa, it means you're not being tied down with a specific implementation or API for AOP. If Aspectj is creatin chaos, fine go ahead use Spring AOP. It doesn't matter as to what is the API or the implementation. And by the way, the writeup was more of basic information about AOP, I'm still vetting out AspectJ vs. Spring AOP stuff. 🙂
Way to use the intnreet to help people solve problems!
We’ve arreivd at the end of the line and I have what I need!
I am not sure where you are getting your information, but good topic. I needs to spend some time learning much more or understanding more. Thanks for fantastic info I was looking for this information for my mission.