Read this article now - Try Goliath Business News - FREE!   
You can view this article PLUS...

• Over 5 million business articles
• Hundreds of the most trusted magazines, newswires, and journals (see list)
• Premium business information that is timely and relevant
• Unlimited Access

Tell Me More   Terms and Conditions

Purchase this article for $4.95

...developer conferences, growing number companies are using AOP to build production applications. In this paper we first introduce AOP and the benefits it brings and then look at the AOP language Aspect J **. (2) AspectJ is an open-source project initiated by PARC and now led by IBM. The AspectJ Development Tools (AJDT) project (3) is a related open-source project, also led by IBM, that provides IDE (integrated development environment) support for programming with AspectJ within the Eclipse IDE. (4) After introducing the language and tools, we discuss the adoption of AspectJ within IBM. The paper concludes by considering the role that open source has played both in the development of AspectJ and AJDT and in IBM's involvement in that process.

WHAT IS AOP?

AOP is a term used to describe a programming technique and a way of thinking about the construction of software applications that complements the forms of expression found in object-oriented programming. The goal of AOP is to improve the modularity of software applications, making them easier to develop, test, and maintain. Aspect-oriented programs comprise of a mixture of objects and aspects. Both encapsulate state and behavior, but whereas the behavior in an object is executed only when explicit calls are made to the object's methods, the behavior in an aspect can also execute at points in the runtime of the program determined by the aspect's specification.

This simple idea turns out to be enormously powerful at modularizing the implementation of certain types of application features and functions. For example, given the requirement to issue a change notification to any registered listeners when the state of any one of a set of model objects changes, an object-based implementation requires the addition of a call to notifyListeners( ) (or some similar method) after each state-changing operation. An aspect-based implementation can simply code (in one module known as an aspect) the following, "After the state of any model object changes, call notifyListeners( )." As another example, consider the use of a persistence service that requires all updates to the persistent state of an application to occur within the scope of a session or transaction. An object-based implementation requires the insertion of logic to start a session before every interaction with the persistence service and to close it again afterwards--managing any exceptions that may be generated by the service along the way. An illustration of this example using the Hibernate (5) persistence framework for session and transaction management is shown in the following listing:

try { Session session = sessionFactory.openSession( ); Transaction tx = null; try { tx = session.beginTransaction( ); //perform updates to persistent state //here ... tx.commit( ); } catch (HibernateException hEx) { if (tx !=null) tx.rollback( ); throw hEx; } finally { session.dose( ); } } catch (HibernateException hEx) { //handle exception }

An aspect-based implementation of the same requirement can be coded once in an encapsulated module, "Before updating the persistent state of the application start a session, and after the update has been completed, close it again." Although the application may involve many interactions with the persistence service, the aspect-based implementation will need to be written only once.

Both the change notification and session-management requirements are examples of what the AOP community has termed a crosscutting concern. A crosscutting concern is a single concern in the design or implementation of a system that impacts multiple places in the static structure of the system or in its runtime control flow. Aspects modularize crosscutting concerns, allowing the implementation of a single (crosscutting) concern in a single module, and therefore eliminating violations of the DRY (don't repeat yourself) principle. (6) Instead of the same fragment of code being repeated in many places throughout...

NOTE: All illustrations and photos have been removed from this article.



More articles from IBM Systems Journal
Supporting aspect-oriented software development with the Concern Manip..., July 01, 2005
Providing Linux 2.6 support for the zSeries platform., July 01, 2005

Looking for additional articles?
Search our database of over 3 million articles.

Looking for more in-depth information on this industry?
Search our complete database of Industry & Market reports by text, subject, publication name or publication date.

About Goliath
Whether you're looking for sales prospects, competitive information, company analysis or best practices in managing your organization, Goliath can help you meet your business needs.

Our extensive business information databases empower business professionals with both the breadth and depth of credible, authoritative information they need to support their business goals. Whether it be strategic planning, sales prospecting, company research or defining management best practices - Goliath is your leading source for accurate information.