Abstract
Abstractions have been very popular in Software development. Different types of programming techniques like Procedure-oriented programming and Object-oriented programming have raised the levels of abstraction over the past several years. So raising the level of abstraction brings the solution more close to the problem enabling the developers to focus more on the higher levels of programming and design.
Aspect-oriented Programming separates concerns like security, transaction, persistence etc. and applies them to code that is not prepared in any way to receive these concerns. So programmers can focus on the design and development of these concerns and let the AOP system apply it to other code. This is a very useful abstraction.
Even though Object-oriented languages have interfaces and abstract classes and several design patterns to abstract ideas there are problems that OO does not solve cleanly. OO classes are coupled with each other in some way or other. There is no way to decouple a concern completely. These are drawbacks of OO that a new paradigm called Aspect-oriented programming solves.
Introduction
Object-oriented programming usually deals with orthogonal concerns along with the main concerns. If we consider that the main concern is a rich domain model that solves the business problem, then issues like persistence are orthogonal and should be isolated. AOP refers to these issues as crosscutting concerns. So OO does not localize crosscutting concerns very effectively.
This white paper deals with software development as a set of concerns and explains through Use cases how AOP solves the problems that OO is not capable of solving. We present a set of Use cases along with problems posed by Object-oriented programming and Aspect-Oriented Programming solutions. All our Use cases are working examples.
We use AspectJ. AspectJ is an Aspect-oriented Programming (AOP) language. An extension of the Java language and compatible with it, AspectJ originated in the Palo Alto Research Center (PARC). Now it is part of the eclipse.org projects. We only briefly explain AspectJ itself in this white paper. Readers should refer to the AspectJ guides. In this paper we use AspectJ and AOP interchangeably.
AspectJ Tooling
AspectJ programs can be compiled either using the command-line compiler ajc, which is included in the AspectJ distribution, or by using better tooling support in the form of AspectJ Development Tools for Eclipse (AJDT). All of the benefits of an Integrated Development Environment like Eclipse are now also available for AspectJ projects. We used the latest versions of Eclipse and AJDT to compile these examples, which, as of the writing of this paper, were Eclipse 3.1.1 and AJDT 1.2.
Brief explanation of AspectJ
We will see examples of all these in our Usecases.
Aspects
An “aspect” is similar to a java class and is a keyword in AspectJ. A Java class contains data members, methods etc. Similarly an aspect contains the following programming constructs. An aspect has .aj extension and can also be written as a Java class by using JDK 5.0 annotations.
Our first code example shows how to do this.
Joinpoints
A joinpoint is a well-defined point in the Java programs that we write. This is where aspects interact with the rest of the software. How do they interact ? They interact by applying advices that we define.
Advice
This means that at a particular joinpoint we apply our own code. So we write code and instruct AspectJ to include that code at certain points(joinpoint) in our Java programs.
Pointcuts
A pointcut is written to pick out joinpoints. “pointcut” is a keyword in the construct.
Weaving
This is done by the AspectJ system in various ways. The ajc compiler can weave code based on our aspects during compile-time. This paper does not describe the other weaving methods. We have used compile-time weaving for all the code examples.
Limitations of OO
The main limitation of Object-oriented programming is its inability to raise the level of abstraction by modularizing crosscutting concerns. Even patterns like the Chain of Responsibility pattern explained below does not avoid dependency between different parts. It also requires the programmer to prepare the code by declaring interfaces or abstract classes and do all the grunt work. Moreover composition and decomposition facilities are limited.
Code Tangling and Code Scattering are two of the major concerns with Object-oriented programming that Aspect-oriented programming techniques alleviate.
Code Tangling
This means that when we mix orthogonal concerns like persistence with a domain model, they start interacting in complex ways. The domain model view and the persistence view or transaction view mix inseparably. Changes are hard to make because concerns are mixed. This is called code tangling. Object-oriented languages address this to some extent but Aspect-oriented languages are more effective. They ensure that these two views are separated and weaved by the compiler or classloader. Weaving is the mixing of code that deals with separate concerns. The programmer does not have to manually combine the code by using Object-oriented patterns. AOP does that for us.
Code Scattering
Since Object-oriented programming does not cleanly separate concerns, persistence code is scattered throughout the domain model code. Inheritance hierarchies and decoupling techniques that OO enables are not very effective for complex designs. AOP avoids code scattering by localizing code.
Code Smells and AspectJ
AspectJ enables us to compose programs in ways that are impossible using an OO language like Java. So AOP improves our normal OO coding techniques by untangling and localizing scattered code. So code smells (Fowler and Beck ) found in tangled and scattered code can be removed.
Programmers take years to understand OO programming. Most often programmers who use OO still use procedural programming techniques. Now the shift to AOP requires that the AOP programmers stop thinking too much about OO programming techniques. That means that they have to learn to write AOP code avoiding OO code smells. This is part of the evolution.
Implicit Invocation
In Object-oriented programs, this means that the programmer should have knowledge of how the programs are constructed to invoke them. Aspect-oriented programming does not require this.The weaving mechanism handles his for us. We just need to identify the joinpoints and write
the pointcuts.
What are aspects ? How does AOP modularize crosscutting concerns?
Let us consider a simple GUI problem. It is the convention in all GUI application screens to show a status message at the bottom. This status indicates the current task that has been fired. It could show that the user has clicked on a particular menu item or that a complex algorithm is being computed.
OO programming techniques require us to either code this status display logic
- Everywhere we need to display the status or
- move it one level up to a superclass
In the first case above, code is scattered everywhere and any change has to be duplicated. Code is not localized. In the second case, code is localized but still an inheritance hierarchy is imposed.
If we have a JLabel like this to show the status
private static JLabel status = new JLabel(" ");
then the code shown below is scattered throughout our application
public static JLabel getStatus( String text ) {
status.setText( text ) ;
}
The concern of showing the status is not the same concern that our application addresses. Obviously, we are not coding an application that shows different types of status to the user. Our application has a business goal and that is its concern. So we separate that concern.
AOP helps us separate it into a first-class aspect like the one shown below.
/*
*
* @author Mohan Radhakrishnan
*/
package com.blueprint.top.view.aspect;
import java.awt.Graphics2D;
import java.lang.reflect.Method;
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.aspectj.lang.annotation.Pointcut;
import com.blueprint.top.view.BluePrint;
import com.blueprint.top.view.PaperSheet;
import com.blueprint.util.annotation.StatusShow;
@Aspect
public class StatusReportAspect {
@Pointcut(“execution(@com.blueprint.util.annotation.StatusShow * *..*(..))”)
void statusMethods(){};
@Before(“statusMethods()”)
public void before( final JoinPoint jp ) {
try{
Class<PaperSheet> clazz = PaperSheet.class;
Method method = clazz.getMethod( jp.getSignature().getName(),
Graphics2D.class);
if( method.isAnnotationPresent( StatusShow.class )){
BluePrint.getStatus().
setText( method.getAnnotation( StatusShow.class ).
message() );
}
}catch( Throwable t ){
t.printStackTrace();
//This is benign. Just ignore.
}
}
}
This means that any method that wants to show the status in the status bar has to be annotated with the annotation @ StatusShow(“Complex encryption algorithm is running”) . We pick up the text within braces and show that in the status bar of the UI.
Now we will present a set of Usecases that focus on certain concerns and their isolation using Aspect-oriented programming.
Loose Coupling as a concern
Loose coupling means reducing the coupling or dependency between different parts of object-oriented classes. Since we are dealing with software micro architecture here we do not describe coupling between anything other than classes like subsystems etc.
Object-oriented systems promote loose coupling in different degrees. Interfaces and abstract classes are used in many patterns to reduce the dependencies. A loosely coupled system is reusable and more modular. A change in one class does not affect another if we program to the Interface.
The object-oriented paradigm has introduced many design patterns that use loosely coupled classes. Let us look at the class diagram of one such pattern.
The coupling is reduced here because the client does not know the receiver. One receiver does not know which other receiver is going to handle the request next. This is as good as any other Object-oriented design pattern that enables loose coupling.
These types of patterns are not good enough for designing domain-driven objects though. A domain-driven object is a simple POJO that distills the way the business works. It has to be thoroughly isolated from infrastructure code. The importance of such a domain model is being increasingly realized in the software industry.
So here we see the layered architecture that shows the domain model and the persistence layer.
Assume that PersonalDetail.java, shown below is part of the domain model and needs to be persisted. We have to set the AddressDAO reference when PersonalDetail is created to enable it to be persisted without writing extra code that pollutes the domain layer.
AOP can inject this dependency for us by segregating the persistence concern. This separation of concerns keeps the domain model completely separate. Object-oriented programming techniques do not have a way to ensure this kind of complete separation of concerns.
So again we have seen how OO falls short of the increased expectations. We show the example class below.
package com.paper.domain.model;
import com.paper.domain.aspect.Entity;
public class PersonalDetail {
static String s;
private String firstName = null;
private String lastName = null;
private String addr = null;
private String phone = null;
private String email = null;
private AddressDAO dao;
public PersonalDetail(){
}
public void setDao( AddressDAO dao) {
this.dao = dao;
}
public String getAddr() {
return addr;
}
public void setAddr(String addr) {
this.addr = addr;
}
public String getEmail() {
return email;
}
public void setEmail(String email) {
this.email = email;
}
public String getFirstName() {
return firstName;
}
public void setFirstName(String firstName) {
this.firstName = firstName;
}
public String getLastName() {
return lastName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
public String getPhone() {
return phone;
}
public void setPhone(String phone) {
this.phone = phone;
}
}
This is the aspect definition.
/*
*
* @author Mohan Radhakrishnan
*/
package com.paper.domain.aspect;
import com.paper.domain.model.*;
public aspect LooseCoupling {
/**
* Execution of a public constructor
*/
after( PersonalDetail p ) : execution ( public PersonalDetail .new(..) )
&& this( p ){
System.out.println(thisJoinPoint.getSignature().toString());
p.setDao( DAOFactory.getDAOFactory( 2 ).getAddressDAO() );
}
}
The following UML diagram can show this non-invasive procedure. So we can see that the dependency between the domain layer and the infrastructure layer in the UML diagram shown earlier has changed to <<merge>>
Security as a concern
This example is based on Ron Bodkin’s PPT presentation.
Java Authentication and Authorization Service is a pluggable architecture that enables security in applications based on who is authenticated or authorized. So it depends on the Subject who is the user and his credential which is some type of login and password.
This Usecase utilizes a basic JAAS setup using the JAASRealm in Tomcat. JAASRealm combines, Tomcat’s Container Managed Authentication(CMA) with JAAS. This paper does not describe JAAS itself.
The diagram below shows the flow of the JAAS Login mechanism written for this paper. Refer. to the next Usecase for an example of Container Managed Authentication(CMA) setup.
We have used a filter described in the Servlet specification to intercept the requests before it reaches the Servlet. This is done to obtain the Subject after the combination of JAAS and Tomcat’s CMA finish authenticating the user. SecurityFilter.java has already been stripped of the concern that we are trying to isolate. This is shown in the aspect Authentication.aj.
The lines shown in italics in Authentication.aj authenticate the user again by invoking the JAAS mechanism. Why is this done ? We mentioned above that the JAASRealm and CMA have already authenticated the user but the Subject cannot be obtained from the container after authentication. This Subject is needed to write privileged blocks for authorization. Privileged blocks are explained below. So the filter authenticates the user again to obtain a reference to the Subject. We store the reference to the Subject in the HttpSession so that we can write privileged blocks anywhere in the application after retrieving the Subject.
The following code is the authentication filter. This filter is configured in web.xml
/*
*
* @author Mohan Radhakrishnan
*/
package com.paper.security.filter;
import java.io.IOException;
import javax.security.auth.login.LoginContext;
import javax.security.auth.login.LoginException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import org.apache.log4j.Logger;
public class SecurityFilter implements Filter {
private FilterConfig filterConfig = null;
Logger logger = Logger.getLogger(“SecurityFilter”);
public void destroy() {
this.filterConfig = null;
}
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException,
ServletException {
chain.doFilter(request, response);
}
public void init(FilterConfig filterConfig) throws ServletException {
this.filterConfig = filterConfig;
}
}
This code is the aspect definition.
/*
*
* @author Mohan Radhakrishnan
*/
package com.paper.security.aspect;
import javax.servlet.http.*;
import javax.servlet.*;
import javax.security.auth.login.LoginContext;
import javax.security.auth.Subject;
import javax.security.auth.login.LoginException;
import com.paper.security.filter.*;
import org.apache.log4j.Logger;
import java.net.*;
import java.util.*;
import java.security.*;
public aspect Authentication {
private pointcut request(ServletRequest req,
ServletResponse res,
FilterChain chain ) :
execution(* com.paper.security.filter.
SecurityFilter.doFilter(..))
&& args( req,res,chain);
void around( final ServletRequest req,
final ServletResponse res,
final FilterChain chain) : request( req,res,chain ){
Logger logger = ((SecurityFilter)thisJoinPoint.getThis()).logger;
try{
final SecurityManager sm;
if (System.getSecurityManager() == null) {
sm = new SecurityManager();
} else {
sm = System.getSecurityManager();
}
HttpServletRequest httpReq = (HttpServletRequest) req;
final java.security.Permission p = PermissionFactory.getInstance().
getPermission(httpReq.getRequestURI());
LoginContext lc = new LoginContext(“WhitePaper”,
new WhitePaperCallbackHandler(
httpReq.getRemoteUser(),
“javatech” ));
logger.info( “Authenticating [” + httpReq.getRequestURI() );
lc.login();
logger.info( “Authenticated” );
Subject s = lc.getSubject();
httpReq.getSession().setAttribute(“SUBJECT_KEY”, s );
Subject.doAsPrivileged(s, new PrivilegedExceptionAction() {
public Object run() {
AccessController.checkPermission(p);
//sm.checkPermission(p);
proceed( req,res,chain );
return null;
}
},null);
} catch (LoginException le) {
logger.info( “Cannot create LoginContext. ” + le.getMessage());
le.printStackTrace();
} catch (SecurityException se) {
logger.info(“Cannot create LoginContext. ” + se.getMessage());
se.printStackTrace();
} catch (Exception e) {
logger.info(“Login failed: ” + e);
}
}
}
After isolating the privileged block code as a separate concern and thereby modularizing the security concern our original sequence diagram is reduced to the one shown below. This diagram clearly shows how our aspect has become reusable. We have pulled the code out of the filter.
Programmers might miss security concerns or they might not understand them enough. So they cannot be expected to always invoke the permission check(privileged block). As has been pointed out earlier, AOP enables quantification and “Implicit Invocation” that enable us to weave concerns into an unprepared codebase. This has isolated the security code so that those who have better awareness of security issues can deal with this concern separately and weave it into existing code.
Privileged block and execution stack
As we can see, the filter wraps the entire request in a privileged block. In the Java 2 security architecture if code is marked as privileged and has the necessary permissions then the previous classes in the thread’s stack are not checked for permission.
So the easier way is to wrap particular blocks of code like this
Subject.doAs(s, new PrivilegedAction() {
public Object run() {
proceed( req,res,chain );
return null;
}
});
We see here that the entire web application request is wrapped in a block. Wrapping the entire request means that all libraries and code in the execution stack are wrapped. But it is difficult to grant all the permissions required by all the code wrapped by this block. The permissions can be granted by a policy file to a particular Principal. An example is shown below.
grant Principal com.paper.security.filter "mohan" {
permission com.xor.auth.perm.URLPermission "/test.jsp";
};
There is another way of doing this. We can place only those pieces of code that required a privileged action in this kind of block wherever needed, instead of wrapping an entire request like this.
Now we can see that this problem is not easily solved by Object-oriented programming because the code is scattered throughout the codebase. How do we add this privilege block in code comprising hundreds of classes in a big application ?
Now we have identified another drawback of Object-oriented programming and another crosscutting concern. We can solve this by writing an aspect with a pointcut like this.
/*
*
* @author Mohan Radhakrishnan
*/
package com.paper.security.aspect;
import com.paper.application.*;
import javax.security.auth.Subject;
import java.security.*;
public aspect Permission {
private pointcut permit() :
execution(public void
com.paper.application.RegistrationAction.test(..));
void around() : permit(){
Subject.doAs( ((RegistrationAction)thisJoinPoint.getThis()).s,
new PrivilegedAction() {
public Object run() {
proceed();
return null;
}
});
}
}
Now our authentication concern is neatly localized.
Authorization as a concern in Java Server Pages
AspectJ can be used in enterprise JEE environments. The following is a JSP problem that we have attempted to solve using AspectJ to prove the power and flexibility of AOP ideas.
Our problem in this section is authorization. This is not JAAS related authorization but one that we frequently encounter.
How do we restrict portions of a JSP based on the role of the login user ?
This example is based on Ron Bodkin’s PPT presentation
In web applications we frequently filter the UI based on the role of the authenticated user. The following is the web.xml for setting up Container Managed Authentication (CMA). We again use Tomcat for this Usecase.
<security-constraint>
<web-resource-collection>
<web-resource-name>White Paper</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<realm-name>White Paper Realm</realm-name>
<form-login-config>
<form-login-page>/pages/login.jsp</form-login-page>
<form-error-page>/pages/login_error.jsp</form-error-page>
</form-login-config>
</login-config>
<security-role>
<description>
Role required to see admin pages.
</description>
<role-name>admin</role-name>
</security-role>
This XML file sets up FORM-based authentication allowing any user with the admin role to access pages specified by the URL pattern.
After authentication the role of the logged-in user can be obtained by calling request.getUserInRole(). The role information returned by this method is used to filter the UI so that the some JSP’s or part of a JSP can be viewed by a particular role. The following diagram shows the flow.
As we can see from the problem statement above, the request.getUserInRole() method is called and code has to be written to wrap portions of the UI. An example would be:
if( request.getUserInRole(rolename){
//filter JSP
}
We do not use Java code in the JSP because as it is finding joinpoints to weave advice in the generated servlets is a complex task. The generated servlet class is complicated. So we use Struts tag handlers.
Now our example has changed to the following code.
<logic:notPresent role="admin">
<tr>
<th align="left">
<bean:message key="registrationForm.email.displayname"/>
</th>
<td align="left">
<html:text property="email" size="60" maxlength="60"/>
</td>
</tr>
</logic:notPresent>
So if we wish to weave into JSP’s, we have first refactor our logic into custom tag handlers which make our task easier. The generated servlet is easier to manage because it is simpler to locate joinpoints and write pointcuts.
Since we need the source code of the generated servlet, we precompile our sample JSP using ANT.
<jasper2
validateXml="false"
uriroot="${webapp.path}"
webXmlFragment="${webapp.path}/WEB-INF/generated_web.xml"
outputDir="${webapp.src.dir}" />
This section of our ANT build file is shown to explain one of the precompiling steps involved in our weaving task. After JSP’s are precompiled into servlets, we have generated_web.xml that contains sections like the following.
<servlet>
<servlet-name>org.apache.jsp.pages.registration_jsp</servlet-name>
<servlet-class>org.apache.jsp.pages.registration_jsp</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>org.apache.jsp.pages.registration_jsp</servlet-name>
<url-pattern>/pages/registration.jsp</url-pattern>
</servlet-mapping>
We have to include these sections in our original web.xml. This is how the container knows the locations and file names of the generated servlets. Our JSP is registration_jsp.
RoleAspect.aj is our aspect. It looks complicated because it includes a method that we introduce. This method contains mostly boilerplate code for generating HTML and tag handler logic. The addRoleTag and destroyRoleTag pointcuts are used to weave the logic that initializes _jspx_tagPool_logic_notPresent_role from a tag handler pool provided by Tomcat and releases it back to the pool.
This particular line introduces the new variable _jspx_tagPool_logic_notPresent_role. See the section on inter-type declarations at the beginning of the paper.
public org.apache.jasper.runtime.TagHandlerPool
registration_jsp._jspx_tagPool_logic_notPresent_role;
The main logic that checks if the logged in user has a particular role or not is contained
within the method _jspx_meth_logic_notPresent_0. So we introduce the entire method to our JSP.
We do not explain the tag handler login in the method but this particular method in turn calls
_jspx_meth_bean_message_9 and _jspx_meth_html_text_6 to display
<bean:message key="registrationForm.email.displayname"/>
and
<html:text property="email" size="60" maxlength="60"/>
only if the role is “admin”.
package org.apache.jsp.pages;
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.PageContext;
import javax.servlet.*;
import org.apache.jsp.pages.*;
public aspect RoleAspect{
public org.apache.jasper.runtime.TagHandlerPool
registration_jsp._jspx_tagPool_logic_notPresent_role;
public boolean registration_jsp.
_jspx_meth_logic_notPresent_0(
javax.servlet.jsp.tagext.JspTag _jspx_th_html_form_0,
PageContext _jspx_page_context) throws Throwable {
PageContext pageContext = _jspx_page_context;
JspWriter out = _jspx_page_context.getOut();
//logic:notPresent
org.apache.struts.taglib.logic.
NotPresentTag _jspx_th_logic_notPresent_0 =
(org.apache.struts.taglib.logic.NotPresentTag)
_jspx_tagPool_logic_notPresent_role.get(
org.apache.struts.taglib.logic.NotPresentTag.class);
_jspx_th_logic_notPresent_0.setPageContext(_jspx_page_context);
_jspx_th_logic_notPresent_0.
setParent((javax.servlet.jsp.tagext.Tag)_jspx_th_html_form_0);
_jspx_th_logic_notPresent_0.setRole(“admin”);
int _jspx_eval_logic_notPresent_0 =
_jspx_th_logic_notPresent_0.doStartTag();
if (_jspx_eval_logic_notPresent_0 !=
javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
do {
out.write(“\r\n <tr>\r\n <th align=\”left\”>\r\n “);
if (_jspx_meth_bean_message_9(
_jspx_th_logic_notPresent_0,
_jspx_page_context))
return true;
out.write(“\r\n </th>\r\n <td align=\”left\”>\r\n “);
if (_jspx_meth_html_text_6(
_jspx_th_logic_notPresent_0,
_jspx_page_context))
return true;
out.write(“\r\n </td>\r\n </tr>\r\n “);
int evalDoAfterBody =
_jspx_th_logic_notPresent_0.doAfterBody();
if (evalDoAfterBody !=
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN)
break;
} while (true);
}
if (_jspx_th_logic_notPresent_0.doEndTag() ==
javax.servlet.jsp.tagext.Tag.SKIP_PAGE) {
_jspx_tagPool_logic_notPresent_role.
reuse(_jspx_th_logic_notPresent_0);
return true;
}
_jspx_tagPool_logic_notPresent_role.
reuse(_jspx_th_logic_notPresent_0);
return false;
}
public ServletConfig registration_jsp.getConfig(){
return getServletConfig();
}
private pointcut addRoleTag() :
execution( public void registration_jsp._jspInit() );
private pointcut destroyRoleTag() :
execution( public void registration_jsp._jspDestroy() );
void around() : addRoleTag(){
registration_jsp jsp =
(registration_jsp)thisJoinPoint.getThis();
jsp._jspx_tagPool_logic_notPresent_role =
org.apache.jasper.runtime.TagHandlerPool.
getTagHandlerPool(jsp.getConfig());
proceed();
}
void around() : destroyRoleTag(){
((registration_jsp)thisJoinPoint.getThis()).
_jspx_tagPool_logic_notPresent_role.release();
proceed();
}
}
RoleAspect.aj makes it possible to weave this logic into as many JSP’s as we need to implement this role-based UI filtering. It is obvious that Object-oriented programming would have introduced needless complication into this Usecase.
This proves that Enterprise JEE environments can also use AOP or AspectJ or any other Aspect-oriented language and benefit from it.
Conclusion
In this white paper we have explored some practical Usecases related to JSE and JEE environments and proved that Aspect-oriented Software Development is a new paradigm and the language AspectJ, is highly recommended for concern-based programming. AOP maps the design ideas to code directly thereby preventing the ideas from scattering throughout the codebase. Maintenance, modularity and reusability are some of the hallmarks of this type of programming.
Aspect-oriented programming or for that matter, Object-oriented programming is not a silver bullet. AOP plugs some loopholes and complements OO techniques.
Unless the core concerns of the system are identified AOP will not help. AOP is not a way of identifying concerns. It enables us to isolate crosscutting concerns in a way that POP or OOP cannot. OOP did not abandon POP. AOP does not abandon OOP. It enhances and complements it. Procedure-oriented programming had various constructs like routines or subroutines to isolate logic to make them reusable. Object-oriented programming had abstract classes, interfaces, polymorphism etc. So now Aspect-oriented programming has introduced Aspects, pointcuts, joinpoints and advice enabling us to raise the level of abstraction further.
References
- An introduction to the Eclipse tools for AspectJ development by the AspectJ Development Tools for Eclipse(AJDT) contributors.
- AspectJ
- AspectJ in action – Ramnivas Laddad
- October 2001/Vol. 44. No. 10 COMMUNICATIONS OF THE ACM
- Java Authentication and Authorization specification.
- http://www.newaspects.com
MindSpace 
