I want my AOP!, Part 1
Tutorial Details:
I want my AOP!, Part 1
I want my AOP!, Part 1
By: By Ramnivas Laddad
Separate software concerns with aspect-oriented programming
concern is a particular goal, concept, or area of interest. In technology terms, a typical software system comprises several core and system-level concerns. For example, a credit card processing system's core concern would process payments, while its system-level concerns would handle logging, transaction integrity, authentication, security, performance, and so on. Many such concerns -- known as crosscutting concerns -- tend to affect multiple implementation modules. Using current programming methodologies, crosscutting concerns span over multiple modules, resulting in systems that are harder to design, understand, implement, and evolve.
Read the whole "I Want My AOP" series:
Part 1. Separate software concerns with aspect-oriented programming
Part 2. Learn AspectJ to better understand aspect-oriented programming
Part 3. Use AspectJ to modularize crosscutting concerns in real-world problems
Aspect-oriented programming (AOP) better separates concerns than previous methodologies, thereby providing modularization of crosscutting concerns.
In this article, the first of three covering AOP, I first explain problems caused by crosscutting concerns in any even moderately complex software system. I then introduce AOP core concepts and show how AOP can solve problems with crosscutting concerns.
The second article in the series will present a tutorial on AspectJ, a free AOP implementation for Java from Xerox PARC. The last article will present several AspectJ examples to illustrate AOP in creating software systems that are easier to understand, implement, and evolve.
Evolution of software programming methodology
In the early days of computer science, developers wrote programs by means of direct machine-level coding. Unfortunately, programmers spent more time thinking about a particular machine's instruction set than the problem at hand. Slowly, we migrated to higher-level languages that allowed some abstraction of the underlying machine. Then came structured languages; we could now decompose our problems in terms of the procedures necessary to perform our tasks. However, as complexity grew, we needed better techniques. Object-oriented programming (OOP) let us view a system as a set of collaborating objects. Classes allow us to hide implementation details beneath interfaces. Polymorphism provided a common behavior and interface for related concepts, and allowed more specialized components to change a particular behavior without needing access to the implementation of base concepts.
Programming methodologies and languages define the way we communicate with machines. Each new methodology presents new ways to decompose problems: machine code, machine-independent code, procedures, classes, and so on. Each new methodology allowed a more natural mapping of system requirements to programming constructs. Evolution of these programming methodologies let us create systems with ever increasing complexity. The converse of this fact may be equally true: we allowed the existence of ever more complex systems because these techniques permitted us to deal with that complexity.
Currently, OOP serves as the methodology of choice for most new software development projects. Indeed, OOP has shown its strength when it comes to modeling common behavior. However, as we will see shortly, and as you may have already experienced, OOP does not adequately address behaviors that span over many -- often unrelated -- modules. In contrast, AOP methodology fills this void. AOP quite possibly represents the next big step in the evolution of programming methodologies.
View the system as a set of concerns
We can view a complex software system as a combined implementation of multiple concerns. A typical system may consist of several kinds of concerns, including business logic, performance, data persistence, logging and debugging, authentication, security, multithread safety, error checking, and so on. You'll also encounter development-process concerns, such as comprehensibility, maintainability, traceability, and evolution ease . Figure 1 illustrates a system as a set of concerns implemented by various modules.
Figure 1. Implementation modules as a set of concerns
Figure 2 presents a set of requirements as a light beam passing through a prism. We pass a requirements light beam through a concern-identifier prism, which separates each concern. The same view also extends towards development-process concerns.
Figure 2. Concern decomposition: The prism analogy
Crosscutting concerns in a system
A developer creates a system as a response to multiple requirements. We can broadly classify these requirements as core module-level requirements and system-level requirements. Many system-level requirements tend to be orthogonal (mutually independent) to each other and to the module-level requirements. System-level requirements also tend to crosscut many core modules. For example, a typical enterprise application comprises crosscutting concerns such as authentication, logging, resource pooling, administration, performance, and storage management. Each crosscuts several subsystems. For example, a storage-management concern affects every stateful business object.
Let's consider a simple, but more concrete, example. Consider a skeleton implementation of a class encapsulating some business logic:
public class SomeBusinessClass extends OtherBusinessClass {
// Core data members
// Other data members: Log stream, data-consistency flag
// Override methods in the base class
public void performSomeOperation(OperationInformation info) {
// Ensure authentication
// Ensure info satisfies contracts
// Lock the object to ensure data-consistency in case other
// threads access it
// Ensure the cache is up to date
// Log the start of operation
// ==== Perform the core operation ====
// Log the completion of operation
// Unlock the object
}
// More operations similar to above
public void save(PersitanceStorage ps) {
}
public void load(PersitanceStorage ps) {
}
}
In the code above, we must consider at least three issues. First, other data members do not belong to this class's core concern. Second, implementation of performSomeOperation() seems to do more than perform the core operation ; it seems to handle the peripheral logging, authentication, multithread safety, contract validation, and cache management concerns. In addition, many of these peripheral concerns would likewise apply to other classes. Third, it is not clear if save() and load() performing persistence management should form the core part of the class.
Crosscutting concern problems
Although crosscutting concerns span over many modules, current implementation techniques tend to implement these requirements using one-dimensional methodologies, forcing implementation mapping for the requirements along a single dimension. That single dimension tends to be the core module-level implementation. The remaining requirements are tagged along this dominant dimension. In other words, the requirement space is an n -dimensional space, whereas the implementation space is one-dimensional. Such a mismatch results in an awkward requirements-to-implementation map.
Symptoms
A few symptoms can indicate a problematic implementation of crosscutting concerns using current methodologies. We can broadly classify those symptoms into two categories:
Code tangling: Modules in a software system may simultaneously interact with several requirements. For example, oftentimes developers simultaneously think about business logic, performance, synchronization, logging, and security. Such a multitude of requirements results in the simultaneous presence of elements from each concern's implementation, resulting in code tangling.
Code scattering: Since crosscutting concerns, by definition, spread over many modules, related implementations also spread over all those modules. For example, in a system using a database, performance concerns may affect all the modules accessing the database.
Implications
Combined, code tangling and code scattering affect software design and developments in many ways:
Poor traceability: Simultaneously implementing several concerns obscures the correspondence between a concern and its implementation, resulting in a poor mapping between the two.
Lower productivity: Simultaneous implementation of multiple concerns shifts the developer's focus from the main concern to the peripheral concerns, leading to lower productivity.
Less code reuse: Since, under these circumstances, a module implements multiple concerns, other systems requiring similar functionality may not be able to readily use the module, further lowering productivity.
Poor code quality: Code tangling produces code with hidden problems. Moreover, by targeting too many concerns at once, one or more of those concerns will not receive enough attention.
More difficult evolution: A limited view and constrained resources often produce a design that addresses only current concerns. Addressing future requirements often requires reworking the implementation. Since the implementation is not modularized, that means touching many modules. Modifying each subsystem for such changes can lead to inconsistencies. It also requires considerable testing effort to ensure that such implementation changes have not caused bugs.
The current response
Since most systems include crosscutting concerns, it's no surprise that a few techniques have emerged to modularize their implementation. Such techniques include mix-in classes, design patterns, and domain-specific solutions.
With mix-in classes, for example, you can defer a concern's final implementation. The primary class contains a mix-in class instance and allows the system's other parts to set that instance. For example, in a credit card processing example, the class implem
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: I want my AOP!, Part 1
View Tutorial: I want my AOP!, Part 1
Related
Tutorials:
 Opening up new
ports to Java
with javax.comm
- JavaWorld -
September 1998
Opening up new
ports to Java
with javax.comm
- JavaWorld -
September 1998
|
Printing in
Java, Part 5 - JavaWorld March
2001
Printing in
Java, Part 5 - JavaWorld March
2001
|
Clean up your wire protocol with SOAP, Part 2 - JavaWorld April 2001
Clean up your wire protocol with SOAP, Part 2 - JavaWorld April 2001
|
Clean up your wire protocol with SOAP, Part 3 - JavaWorld June
2001
Clean up your wire protocol with SOAP, Part 3 - JavaWorld June
2001
|
Access the world's biggest database with Web DataBase Connectivity -
JavaWorld March 2001
Access the world's biggest database with Web DataBase Connectivity -
JavaWorld March 2001
|
Master the Jxta shell,
Part 1
Master the Jxta shell,
Part 1
|
I want my AOP!, Part 1
I want my AOP!, Part 1
|
I want my AOP!,
Part 2
I want my AOP!,
Part 2
|
I want my AOP!, Part 3
I want my AOP!, Part 3
|
Get the inside
track on J2EE architect certification
Get the inside
track on J2EE architect certification
|
Good, but
obsolete
Good, but
obsolete
|
Use AOP to maintain legacy Java applications
Use AOP to maintain legacy Java applications
This artical shows you how to use aspect-oriented programming (AOP) to gain an unprecedented view into the inner workings of even the most opaque of legacy applications.
Please note that this article assume
|
Object-relation mapping without the container
If you follow the latest developer buzz then you\\\\\'ve likely heard of IOC (Inversion of Control) containers and AOP (aspect-oriented programming).
|
Second-generation aspect-oriented
programming
Second-generation aspect-oriented
programming
|
Aspect-Oriented Annotations
Aspect-Oriented Annotations
Annotations are one of the new language features in J2SE 5.0, and allow you to attach metadata onto any Java construct. Meanwhile, Aspect-Oriented Programming (AOP) is a fairly new technology that makes it easier for you to en
|
jGuard v0.60 released!
jGuard v0.60 released!
i am pleased to announce a new major release(v0.60) of the java security library called jGuard(http://sourceforge.net/projects/jguard/).
this library is build on top of jaas, for J2EE web applications.
his goal is to provide f
|
Aspect-Oriented Programming in Java
This article is divided into three parts: The first part explaines the concepts of AOP, the second introduces AspectJ(TM), an implementation of the AOP concepts in Java, and part three compares the AOP approach to metalevel programming.
|
Migrating from Windows to Linux, Part 1: Preparation
Want to switch to Linux, but don't know where to begin? In Part I of Migrating from Windows to Linux, THG will help you prepare for the big move. Step-by-step instructions and printable checklists will ensure your happy and safe journey into Linux.
|
The Things I Wish I Learned in Engineering School: A Conversation with Sun Microsystems Distinguished Engineer Rick Catt
Sun Microsystems' Rick Cattell discusses why innovative software often never sees the light of day and how to remedy this problem.
|
USB FAQ
FAQ topics include recommended USB patches for the Solaris OS, the USBA 1.0 Framework, libusb support, and more.
|
|
|
|
