Add a JAC to your toolshed

JAC offers an alternative for Web-based distributed applications

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.

Figure 1. JAC components are pure Java objects
Figure 2. Crosscutting concerns are woven at runtime

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.

JAC is well suited for constrained environments such as application servers. Unlike AspectJ, which provides a language to separate concerns at a syntactical level, JAC provides a set of properties to program distributed and adaptable containers. First, you can add or remove aspects dynamically with JAC (while the application is running). This is useful during development but also for maintenance. You can, for example, modify your objects' consistency or synchronization characteristics without restarting your server. Moreover, JAC automatically distributes the aspects on distant servers. This allows JAC's aspects to handle concerns like deployment, data consistency, fault tolerance, or scalability. Coupled with dynamic adaptability, JAC's distribution capabilities let programmers build very flexible architectural schemes.

Second, to facilitate JAC's use, the framework proposes two levels of granularity. The first level is the development level. This is the AspectJ level, which allows you to program new aspects. This level requires strong AOP skills. The second level is the configuration level (the same level as XML-based configuration in J2EE environments). At this level, developers can configure existing aspects to fit to their applications. This level requires no particular AOP skills and can be easily used by any Java developer. These two levels of granularity combine the best J2EE environment elements with new AOP concepts.

Finally, JAC is not a new language with new grammar to express aspects. Aspects are written in pure Java, dodging the necessity to introduce another compiler and learn a new syntax. AspectJ and JAC characteristics are compared in the table below.

AspectJ and JAC head to head

Java language extension.AOP framework, application server.
New grammar to express aspects.Aspects written in pure Java.
Uses source code. Each modification requires recompiling.Uses byte code. Allows you to dynamically add, remove, or modify aspects.
Doesn't handle distribution.Automatically distributes aspects on distant servers.
Only allows aspects development.Allows you to develop aspects or reuse them through configuration.
IDE support for Eclipse, Emacs, Sun ONE Studio, and JBuilder.UML IDE supports aspects.
No predeveloped aspects.Set of predeveloped configurable aspects.
Open source Mozilla public license.LGPL license.

JAC development in a nutshell

JAC differs from a J2EE application server in many ways. Ready-to-use aspects replace the J2EE container's technical services. Moreover, several other crosscutting concerns not usually proposed in current application servers are provided in JAC aspects (e.g., graphical user interface (GUI) configuration, access-rights checking, workflow support). All these aspects can be configured to fit your application. With AOP technology, the application's business logic remains fully independent from these crosscutting concerns, even within the source code. Furthermore, the JAC container does not use the EJB component model. It works with pure business logic Java classes (plain old Java objects). These characteristics make JAC quite easy to learn compared to typical J2EE application servers.

I next describe the major JAC development steps:

  1. Model your business logic using JAC's Unified Modeling Language (UML) IDE. It generates the right code to be executed into JAC's container (pure Java classes similar to JavaBeans). Figure 3 shows the UML diagram of an online store. As you can see, the model is reduced to its pure functional expression (i.e., the classes and some business treatments (Java methods) such as Item.addToShoppingCart(int quantity) or ShoppingCart.order()). Note you can use your favorite IDE to write the business model (JavaBeans support would be fine).
  2. Figure 3. Modeling an online store with a pure business UML diagram. Click on thumbnail to view full-size image.
  3. Still using JAC's IDE (or your favorite editor), configure the crosscutting aspects. Figure 4 shows all aspects you can use to build an online store. Figure 5 focuses on the profiles' configuration and on the access rights (the user aspect). These access rights have direct impact on the user's GUI (configured in the gui aspect).
  4. Figure 4. Configured crosscutting aspects for the e-commerce application (JAC IDE dialog)
    Figure 5. The profile and access-rights ( user ) aspect configuration (JAC IDE dialog)
  5. You can program new technical or business-oriented aspects. For example, your application may need to handle stock management or data flow management (e.g., manage consistency between clients and suppliers' orders). These business logic concerns often spread across many different objects and are very interesting to "aspectualize."
  6. Run the application on a JAC container. If a GUI aspect is configured, the application can be accessed through an automatically constructed Web GUI (the JAC container integrates Jetty) or through an automatically constructed Swing client. Figure 6 shows the Web online store example for an administrator (a user profile would not have access to all the features, as defined in the user aspect).
Figure 6. The generated GUI (from gui and user aspect configurations)

Integrate JAC: Architecture examples

JAC proposes—or will propose in the near future—a set of communication layers: Remote Method Invocation (RMI), Simple Object Access Protocol (SOAP)/XML, and CORBA/Internet Inter-ORB Protocol (IIOP) that interoperate with Java and Microsoft operating systems that support Java/RMI, or heterogeneous environments (e.g., with SOAP, JAC can interoperate with .Net). In complex enterprise infrastructures, software is generally split into front-office and back-office parts. The front office typically involves all presentation servers, which the clients directly access. The back office includes servers accessed by the front office, such as business object servers and databases that manage and store the application's data. Depending on what aspects are used and how they are configured, JAC can be a front-office solution as well as a heavy back-office solution providing load balancing and scalability. Any hybrid architecture can be investigated.

The basic architecture

When programming fully aspect-oriented applications, a complete JAC solution can be employed, and the architect can benefit from AOP separation of concern capabilities and put business, presentation, and technical concerns on the same server.

Figure 7 shows a sample architecture using a JAC application server. Business logic Java components are plain old Java objects, which can be automatically generated from the UML diagram under JAC's IDE. Regarding the aspect configurations, the GUI allows you to parameterize the Swing client's view and the Web client's GUI (other client support can be programmed). The persistence aspect implements container-managed persistence (CMP). Its configuration lets you choose between file system storage or any relational database management system (RDBMS) storage via Java Database Connectivity (JDBC); it also parameterizes life cycles and objects' load strategies.

Figure 7. A typical architecture sample using JAC as an application server. Click on thumbnail to view full-size image.

Scalability and fault tolerance

With the power and simplicity of JAC's technical services, you can quickly build complex architectures integrating fault tolerance, load balancing, and consistency.

For fault tolerance, the persistence aspect can be configured to use a JDBC driver that allows RDBMS clustering. This kind of driver broadcasts data modifications so that several consistent data sources can be used at the same time for data redundancy.

For scalability, the presentation layer can be separated from the business logic by programming pure presentation JAC components. These presentation components generate Web GUIs that can act as replicated front ends (accessed by clients through a load balancer). This separation is performed without any reengineering, simply by configuring some distributed aspects.

Interoperability: Using JAC with other technologies

JAC cooperates with other technologies. For instance, JAC can work as a presentation server. In this case, JAC objects are presentation objects that access (via any communication layer) backend application servers where the actual business logic is defined. For example, it is easy to couple JAC with a J2EE server such as JBoss or Jonas. These architectures then rely on standard, reliable, and well-known technologies (Java Data Objects (JDO), Java Transaction API (JTA), and so on). From the front office point of view, the presentation objects can be configured with JAC presentation, authentication, and access-right checking aspects, to add more business-level concerns.

Get to know JAC

In this article, I presented a quick overview of JAC and how it can benefit your development efforts. JAC is an interesting alternative to J2EE-based solutions, but it is also a complementary tool.

However, JAC is a new solution that needs to be more thoroughly tested. The first real-world JAC applications are still being developed. But these practical applications tend to prove that, by solving the problem of crosscutting concerns, aspect-oriented programming technology leads to simplicity of design, maintainability, and reusability.

Renaud Pawlak holds a PhD in computer science. His main focus is on separation of concerns (SoC) in software engineering and AOP. He developed an original programming model that is directly applicable to distributed environments (the Aspect Component Model). In January 2000, he cofounded the AOPSYS company, with the primary goal of supporting the use of AOP and SoC-related techniques in the industry. He is the founder and main programmer of the JAC framework, currently being used by AOPSYS to develop projects for various customers.

Learn more about this topic