11 April 2006 - 18:14Spring proxy-based AOP versus annotation-based AOP

One big difference between Spring’s proxy-based AOP implementation (referenced from now on as Spring AOP) and annotation-based AOP is the fact the Spring AOP declares the advices outside of the code while annotations declare the advice in the code. This causes some side effects:

1) Spring AOP lets you apply different behavior to the same class in different instances (actually you can do this in the same instance). It would be possible to download an open-source JEE application (such as a B2C shopping cart) and customize it without changing code resulting in different instances of the same app. For example, you would be able to declare that various steps in the checkout are transactional, apply different security requirements from instance to instance without changing the downloaded code.

2) The fact that annotation-based AOP binds behavior to code implies some development coupling: you have to develop or at least design the advice before you develop the class being advised. Ideally you would develop the advice independent of the code it gets applied to.

3) Annotation-based AOP creates horizontal relationships between classes that are very hard to change. All the classes sharing the same advice are tied together. Suppose that you have a Transaction annotation applied to you account manager, user signup manager and checkout manager. It would be very hard (and would require quite a lot of code-juggling) to change the app so that only your checkout process is transactional. These horizontal relationships (which as far as I know have not been integrated into modeling tools) should probably not exist at the code level, but at the application-deployment level. Cross-functional behavior should probably be applied at deployment time when the user’s requirements are ready to be implemented.

4) Annotations may degrade portability. One example would be the core EJB3 annotations for persistence. These annotations are platform independent since they are part of the EJB3 spec, however, these annotations are probably insufficient for real-life deployment because they do not allow for application tuning (such as data caching for example). In order to add caching to an EJB we would probably have to add server-specific annotations, and these server-specific annotations ruin the portability between application servers. With Spring AOP we could write an aspect that would piggy-back on the server-specific cache and advise the DAO with this aspect at deployment time. We could change the cache pretty easily by creating a new aspect for a different cache and advise the DAO with this aspect at deployment time.

5) Spring AOP creates a new role in the product’s life-cycle: the application assembler role. This role (probably best fulfilled by a business analyst which has a relation with the customer) would allow for making the application more flexible to customer’s requirements. A business analyst should be able to look at an application, determine what type of behavior should be attached to, or detached from its various parts and attach or detach that behavior. Supposing that this behavior doesn’t exist the business analyst should be able to have it developed in an advice that is independent of the overall application and advise various parts of the application with this advise.

I think that Spring’s proxy-based AOP is a better proposition that AOP thru annotations. Annotations promote relationships that are hard-coded and unless are specified by the domain problem they should be better implemented outside of code.