Ramnivas Laddad

Like any new and exciting technology, AOP has generated its fair share of buzz, and also its fair share of myths and misunderstandings. After following AOP coverage on the Web and listening to the questions asked at conferences, I started to see some common themes (or myths) that deserve to be cleared up.

Metadata is a way to express additional information about program elements. The new metadata facility in the Java programming language enables the use of typed annotations. Using metadata is quite simple, although consuming it brings up many choices. Aspect-oriented programming presents itself as a principled consumer of metadata. The join point model augmented with metadata makes AOP accessible by facilitating simpler pointcuts for crosscutting concerns that would not be so easily specified by stable signature-based pointcuts.

As enterprise systems evolve from concept to code, an otherwise clean design can become downright, well, messy, as the practical plumbing of logging, caching, transactions, and more infiltrates modules. Wouldn't it be better if, say, logging were just another module? Enter aspect-oriented programming.

Refactoring, a process and a set of techniques to reorganize code while preserving the external behavior, has gained popularity due to its practical value in creating agile code. Recently, aspect-oriented programming (AOP) has received increased attention due to its power in encapsulating crosscutting concerns in a system through use of a new unit of modularity called an aspect. Aspect-oriented refactoring (AO refactoring) synergistically combines these two techniques to refactor crosscutting elements. In this two-part series, we will examine the fundamentals of AO refactoring, the steps involved in the process, and a few common techniques.

Software engineers arealways looking for ways to improve modularity in software. Recently, aspect-oriented programming emerged as a new modularity technique that aims to cleanly separatethe implementation of crosscutting concerns(requirements and design elements that affect multiple modules). Several characteristics of AOP work together to improve software quality.

Most software systems consist of several concerns that crosscut multiple modules. Object-oriented techniques for implementing such concerns result in systems that are invasive to implement, tough to understand, and difficult to evolve. The new aspect-oriented programming (AOP) methodology facilitates modularization of crosscutting concerns. Using AOP, you can create implementations that are easier to design, understand, and maintain. Further, AOP promises higher productivity, improved quality, and better ability to implement newer features. This article, the first in a three-part series, introduces the AOP concept and the problems it attempts to solve.

AspectJ simplifies the logging task by modularizing its implementation and obviating the need to change many source files when requirements change. AspectJ not only saves a ton of code, but also establishes centralized control, consistency, and efficiency. Implementing logging with AspectJ--a safe and relatively simple task--is a good way to learn AOP and AspectJ and to introduce it into your organization. The next time you encounter some unexpected problem that occurs infrequently, you can use AspectJ-based logging to easily monitor the operation log and isolate the problem. Once the problem is fixed, you can just as easily remove logging. In this article, we demonstrate how you'd use AspectJ in implementing logging. The solution presented here builds on the standard logging APIs.

Most Web applications require the presentation of database-generated information. XML, because of its ability to separate content from presentation, is fast becoming an industry standard for data exchange. Most XML tools work with either the SAX or DOM API. This article presents a way to blend the power of a database with the features of XML. It also provides a simple, pure Java implementation of XML APIs for databases that works with any JDBC data source. With this approach, XML tools can treat a database as a virtual XML document.

Adding support for user-defined scripting to software tools greatly enhances their usability, resulting in higher user satisfaction. With the scripting facility, tool users can customize the tool to suit their needs, ease their routine tasks, and extend added functionality beyond the level intended by the tool vendor. This article presents a way to add scripting support to Java applications and provides required drivers for four scripting languages: JavaScript, Python, Tcl, and Scheme. It also presents a framework that enables support for new scripting languages without any changes to the core application. Finally, it shows how to add scripting support to those Java applications designed without consideration for scripting extensions.

Top-level nested classes (static inner classes) act like top-level classes except they use the enclosing class as a namespace. This tip suggests designing supporting classes as top-level nested classes inside the primary class. This approach makes the coupling between the primary and the supporting classes clear and leads to an implementation that is easier to understand, use, and maintain.

This paper discusses the publish-subscribe communication model for smart, interactive devices in distributed real-time environment and proposes extensions to Java Messaging Service (JMS) API to make it suitable for real-time systems.