Cross-Cutting Concerns with Spring 2.0 AOP
A recent JavaWorld article by demonstrates aspect-oriented development with Spring 2.0's AOP framework. The article shows how to move cross-cutting concerns from mainline application code into their own POJOs, and use Spring 2.0's configuration files to apply those aspects to business logic.
Aspect-oriented programming, or AOP, excited much interest a few years ago, but to date relatively few developers have coded applications in an AOP style. One of AOP's key promises is that it allows functionality that impacts many parts of an application, such as logging, security, or transactionality, to be removed from mainline application code into their own classes. A small AOP glue code can then be used to apply such cross-cutting concerns to business logic at the appropriate time.
Such AOP glue, however, required that developers either rely on programming language extensions, such as AspectJ, or some other external configuration files, both of which could potentially reduce the portability of code across application servers.
With AOP as one of its cornerstone features from the outset, Spring 2.0 may be the most effective way to benefit from AOP in enterprise applications, according to a recent JavaWorld article by Ganesh Ghag, Implement crosscutting concerns using Spring 2.0 AOP.
Ghag starts out by illustrating how Spring AOP allows moving cross-cutting concerns into their own POJOs, leading to cleaner and more focused code. A typical method may start out mixing logging, security, and transactionality, for instance:
public String doSomething(String input) {
//Logging
System.out.println("entering business method with:"+input);
//Security check for authorization of action (business-method)
//transactionality
try {
//Start new session and transaction
//Some business logic
//Commit transaction
}
catch(Exception e) {
//Rollback transaction
}
finally {
//Close session
}
//Logging
System.out.println("exiting business method with:"+input);
return input;
}
Ghag shows that the above method can be written to focus on just the business logic, moving the cross-cutting concerns into their own POJOs:
public String doSomething(String input) {
//some business logic
return input;
}
The price of factoring out cross-cutting functionality is a small amount of XML configuration data required by Spring 2.0 AOP. To implement logging, for instance, Ghag defines a logging aspect as follows:
public class MyLoggingAspect {
public Object log(ProceedingJoinPoint call) throws Throwable {
System.out.println("from logging aspect: entering method [" + call.toShortString()
+"] with param:"+call.getArgs()[0] );
Object point = call.proceed();
System.out.println("from logging aspect: exiting method [" + call.toShortString()
+ "with return as:" +point);
return point;
}
}
The following XML configuration will apply this aspect to the business logic:
...
...
...
What do you think of Spring 2.0's AOP framework?