Featured White Papers

• Java Web Hosting | DailyRazor.com - Over 10yrs Of Java Web Hosting Exp!

Sponsored Links

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Add a JAC to your toolshed

JAC offers an alternative for Web-based distributed applications

By Renaud Pawlak, JavaWorld.com, 03/07/03

Java 2 Platform, Enterprise Edition (J2EE) applications simplify complex application programming by providing hardcoded technical services such as data persistence and session management. Enterprise JavaBeans (EJB) containers can be configured during the deployment phase using XML files. These configurations allow programmers to directly integrate predeveloped technical services. In traditional development, these references to a given API crosscut a set of business components.

When using J2EE, programmers reduce the effects of crosscutting concerns and reach better modularity (thanks to persistent XML files). However, depending on the actual container implementation, programmers may reach the J2EE architecture's limits. For instance, some transactional persistence features may be better supported manually, rather than by XML configurations. Moreover, the programmer can encounter crosscutting concerns not configurable in XML files (e.g., access rights, depending on the user's profile, and presentation issues, depending on a workflow state). These crosscutting concerns are more business-oriented and must be manually integrated. They also often necessitate the use and integration of specialized frameworks, further complicating the programmer's task.

Thus, in practical situations, business logic EJB components must often include extra references to a set of business and/or technical APIs. As a consequence, the EJB components' business-related code soon becomes polluted by several calls to these services. These programming methodologies with crosscutting concerns spanning multiple modules result in systems that are harder to design, understand, implement, and evolve (see Ramnivas Laddad's JavaWorld series, "I Want My AOP").

Aspect-oriented programming (AOP) is a programming paradigm providing generic means for modularization of crosscutting concerns. It allows the developer to clearly separate the business logic from crosscutting concerns such as data persistence, logging, performance, transactions, debugging, presentation, access rights, and more.

Java Aspect Components (JAC) is an AOP application server. It uses AOP technology to modularize an application's various concerns (see Figure 1). Just as in a J2EE environment, JAC provides predeveloped technical services: the aspects. As shown in Figure 2, aspects weave into business logic at runtime following rules defined for each aspect's well-separated configuration files. Unlike J2EE application servers, aspects can modularize classic technical concerns (such as persistence) and any other crosscutting concerns. Indeed, since aspects are part of the programming framework, programmers can add their own aspects specific to their technical or business needs.

Two AOP approaches: AspectJ and JAC

The most well-known AOP project is AspectJ, a free implementation for Java from Xerox PARC (Palo Alto Research Center). AspectJ is a language specification as well as an AOP language implementation. The language specification defines various constructs and their semantics to support aspect-oriented concepts. The language implementation offers tools for compiling, debugging, and documenting code. AspectJ's language constructs extend the Java programming language. The AspectJ compiler produces class files that comply with Java byte code specifications, enabling any compliant JVM to interpret the produced classfiles.