Mike's Blog
Sunday, August 08, 2004
Aspect Oriented Programming (AOP)

AOP has recently emerged as a programming paradigm that, many believe, will become main-stream in near future. It is indeed an interesting approach to designing systems. There are numerous tutorials on this subject available on the internet, but most of them primarily focus on the usage of specific frameworks/aspect-oriented-languages. There is not much coverage of AOP as a programming paradigm from historical perspective, so I thought I would attempt to write one and contribute to AOP in my small way.

This blog entry is not intended to be a tutorial on AOP and it does not cover any AOP framework or language in great detail. It aims to examine the evolution of AOP and tries to understand where it might go from here.

What is AOP: AOP is a way of programming where one:
1) Identifies pieces of code addressing a specific concern/aspect that are scattered throughout the system.
2) Extracts those pieces of code and moves them to one central place called Aspect.
3) Repeats this process for different concerns (transaction, security, caching, object pooling, logging, remoteness, replication etc.) creating one aspect per concern.

For example, in a typical object-oriented database application there is likely to be transaction code scattered throughout the system. You can use AOP to extract all transaction handling code and move it to an Aspect.

Aspect is to AOP what Class is to OOP: Think of Aspect as a container of code pertaining to a specific concern.

AOP Languages and Frameworks: You can use AOP in your projects by using an AOP framework or by using an AOP language:
1) AOP languages, such as AspectJ, add language constructs (e.g. Aspect) to existing languages. For example, AspectJ adds some language constructs to Java to support AOP. In other words, AspectJ is a superset of Java, or AspectJ is to Java what C++ is to C.
2) AOP frameworks do not add any language constructs to existing languages. They use configuration files, mostly XML, to define aspect related information. Examples of this approach are JBossAOP, Spring, AspectWorkz, Nanning, DynaAOP etc.

As you can see there are many more AOP frameworks than AOP languages:
1) It is less difficult to create a framework than it is to enhance a language.
2) AOP languages can be hard to work with without proper IDE support.

Some examples of AOP:

Code Readability: In AOP programs, there is more to code than meets the eye. Consider the following line of code:


In Java, based on this line of code, it is easy to determine what the next line of execution would be. It is the addCourse method of Student class.

In AOP, it is not so easy to determine what the next line of execution would be. It is possible that addCourse method is intercepted by an Aspect.

Presence of aspects in AOP makes it harder to understand code.

But with good tools support this problem could be mitigated. For example, eclipse has good support for AspectJ and it highlights lines of code affected by aspects.


AOP use and AOP abuse: Identifying and extracting independent concerns into separate aspects is easier said than done. Except for some well understood system concerns like transactions, security, pooling etc. it is hard to apply AOP to divide a system into a set of aspects each handling an independent concern.

1) IMHO, system level concerns would be aspectized by specialists and would be made available as frameworks to application programmers. In other words, most usages of AOP would be by framework developers and not by application programmers. Spring/JBoss appear to be moving in that direction.

2) Some applications would need aspects not handled by available frameworks but IMHO they would be exceptions rather than the norm.

3) Most common usage of aspects by application developers would be for logging, system monitoring etc.

4) For pure business logic code, AOP usage would be extremely rare. It is hard, though possible in rare scenarios, to aspectized business logic code.

AOP in historical perspective: If we look at the history of programming languages, one clear trend is that of increasingly greater expressibility. Newer programming languages allow us to express more and more complex ideas allowing us to solve increasingly difficult problems in shorter timeframes. AOP is certainly a move in that direction. It attempts to divide software into a variety of aspects so that each aspect could be developed by specialists, leading to higher quality software. How much aspectization could be achieved remains to be seen.

EJB (more generally, IoC containers) is conceptually similar to AOP. They take the business logic code provided by application developers and effectively add a wrapper around it to provide remoteness, failover, transaction, security, pooling, caching etc. It is interesting to note that JBoss’s implementation of EJB is based on interceptors using Dynamic Proxy of Java. Interceptors using dynamic proxy is now the foundation of quite a few AOP frameworks in Java, most notably Spring, Nannning and DynaAOP.

Also interestingly, in our own team, Brent used interceptors using dynamic proxy to support transactions in at least one project.

It is important to point out that not all AOP frameworks are based on interceptors, though conceptually they all behave in that manner. Many AOP frameworks, for example JBossAOP and AspectWorkz, modify application classes at runtime to insert aspect code (this process is called aspect weaving). Other AOP frameworks, for example AspectJ, perform aspect weaving at compile time.

It is clear that, conceptually, aspectization of software, in order to enable development of system concerns by specialists, has been going on for a long time. What AOP movement has done is, it has formalized this kind of software modularization by identifying recurring concepts like aspect, advice, point-cut, join-point etc. and thus formalizing a new programming paradigm. This new paradigm has lead to a competitive world of AOP frameworks and languages that only focus on perfecting an extremely generic infrastructure to enable software modularization in terms of aspects.

(1) Is AOP going to replace OOP?
No, AOP complements OOP.
(2) Does AOP degrade performance?
In theory, yes because of extra calls added by interception, but in most cases there would not be a perceptible degradation.

Resume Oriented Programming (ROP)

It is always dangerous to make sweeping statements about a group of people. History tells us that consequences of such remarks vary from peaceful condemnations to acts of violence, yet knowledge of this fact does not stop me from making the following observation.

Programmers, Java programmers in particular, disappoint me. Their lack of skepticism for new frameworks and products is shocking. Their dishonesty at work by engaging in Resume Oriented Programming is repulsive. It disgusts me to see that they use a lot of technologies just so they can say they have used them.

The following observations corroborate these claims.

A few years back when NASDAQ was still going up, programmers played foosball at work and office was a place for beer and barbeque, the EJB specification came out, and sure enough books followed to explain how to use this new specification. One author, in particular, became a rock star among Java programmers. So much so that Fifth Amendment did not cover speaking against him. Well, I guess I will take my chances.

EJB is the best tool to reveal what is wrong with many programmers. I will go through some of the EJB (stateless session beans, more specifically) features to make my point. I will explain how so many programmers use EJB even when it is not necessary. Sometimes it is because of ROP and other times it is because of their lack of skepticism and inability to think rationally and independently.

Transaction: Among many things, EJB provides a declarative means of specifying transaction boundaries. That enables a piece of code to run under different transaction contexts without requiring the programmer to sprinkle transaction code into business logic code. One benefit of this approach is greater code clarity. Another benefit is that you can change your transaction boundaries without changing you code.

The problem is, most systems have very simple transactional requirements that can easily be met by commit and rollback methods of JDBC API.

If enquired why they are using EJB to manage transactions, programmers recite the powerful transactional capabilities of EJB with complete disregard to whether they are required by their project. They answer as if they were writing a certification exam for EJB.

Security: A lot of programmers site security as a reason why they are using EJB. When, in fact, it is very unlikely that they are really using this feature of EJB in their project. Most applications handle security by not displaying the pages/page fragments/links that user does not have privileges for. If the EJB layer needs to handle security then more often than not a custom solution has to be developed because EJB specification’s security model is rarely good enough. I am not saying programmers do not use security feature of EJB. What I am saying is, if they do then most likely it is because they can say they have used it. It is always possible to come up with a use case to show how EJB security can be used to handle security but the point still remains that EJB security model does not address the security requirements typical of most real life applications.

Pooling: This has to be the strongest evidence of programmers’ inability of independent thinking. Most programmers learnt EJB by reading one of the two popular books. Both of them explain stateless session beans are pooled by the container in order to increase scalability. Most programmers are infatuated with the terms pooling and scalability. They think knowledge of these terms gives them membership rights to the elite club of server-side programmers. And so they religiously use stateless session beans in their projects because the container would take care of pooling and make their applications more scalable. They never bother to ask why the container needs to pool objects that are stateless and hence very lightweight. Iin a typical call to a stateless session bean, there would be so many application objects created (apart from countless many objects created by the container) that the cost savings gained by pooling stateless session beans are bound to be negligible. It stands to reason that stateless session bean pooling is a case of premature optimization that would almost never pay off. It is indeed strange that many programmers site stateless session bean pooling as one of the priceless services EJB container performs.

Remoteness: EJB container makes stateless session beans remotely accessible. But most of the times, they are accessed by JSP/Servlets running in the same container so this feature is rarely used.

Just to be clear, I am not saying all programmers are bad or EJB is a waste. All I am saying is, more often than not EJB is used for all the wrong reasons. EJB is not the only technology that is (ab/mis)used this way. The same is true of many other new technologies. I think the reason we hear less about this phenomenon is that it serves product vendors well. Most of the job interviews are designed to promote ROP, so companies also share some of the blame.

Powered by Blogger