The January/February 2001 issue of the MIT Technology Review identified aspect-oriented programming as one of ten "emerging areas of technology that will soon have a profound impact on the economy and on how we live and work." It is pleasant to contemplate the prospect of this prediction; evidence for it can be found in applications built on aspect technology. However, currently most aspect-utilizing applications are research prototypesa critical stage in technology maturation, but not a marker of a mature technology. In this section, we present several such applications. These chapters serve two purposes: both to inspire readers who view themselves as system builders in the way that AO technology can be applied to system construction, and to anchor those readers that view themselves as developers of aspect technology in the reality of its application.
HARNESSING THE C3
Explicit support for modularizing crosscutting concerns (C3) is the key strength of aspect-orientation. The desired syntax and semantics of both modularizing and composing crosscutting concerns is the central theme of any aspect-oriented proposition. We refer to this critical issue as "harnessing the C3." Crosscutting concerns are inherent complexities of problem domains; they cannot be completely avoided. This means that for many software systems, there is no way to structure the system to avoid crosscutting complexity. The best we can do is to apply appropriate technology to mitigate the problem. Applications with a variety of crosscutting concerns are always going to be difficult. The prediction is that harnessing the C3 is significant enough to make a profound impact on the engineering of those applications. The choice an application developer must make is between a system with scattered crosscutting concerns and a system with modular crosscutting concerns.
What improves applications? This field has progressed from calling itself "aspect-oriented programming" to "aspect-oriented software development." This reflects the recognition that aspect orientation must be supported not only at the programming level but also throughout the application lifecycle. Applications benefit from the ability to trace from requirements to a modular implementation of those requirements. The software engineering mechanisms discussed in Part 2 aim to ease aspect-based application construction, serving as steps toward fulfilling the Technology Review prediction. However, the real test of this idea is to be found in applications. As of the writing of this chapter, there are no "killer" aspect-oriented applications. Rather, there are research prototypes that hint at the potential of the technology.
Harnessing the C3 is achieved by providing new modularization and composition techniques that take advantage of the quantification and obliviousness of AOSD technology. Part 1 surveyed a variety of current languages that differ on their realization of these two properties. While each language may seem to be simply a choice in the design space, in many cases application requirements, such as a need for dynamic adaptability of aspects, distribution, or persistence, drives the implementation technology. Applications that require, say, dynamic adaptability of aspects add this requirement to the technology chosen for the implementation of these applications. This in turn forces the technology or the specific language to reevaluate its bindings between advice and pointcuts. Current innovation may point to the fine-tuning of these two properties to exhibit the "right" degree of power of expression simultaneously with the "right" degree of safety. Harnessing the C3 in practice is not as simple as it looks in pure theory. Real life applications require compromises. There is a mutual impact of AOSD applications and AOSD's attempt to shape itself toward maturity.
HARNESSING QUANTIFICATION
Quantification allows systematizing properties across an application, but it has the danger of complicating the semantics of componentsif we are unsure where an aspect can be applied, we are less certain about the specific behavior of any construct. Real applications need to balance such expressive power with the pragmatics of systems development, either through the use of AOP technology that contains mechanisms for limiting quantification (for example, restricting aspect application to certain regions) or through coding conventions that (less reliably though perhaps more comprehensibly) prescribe when and how to use quantification.
HARNESSING OBLIVIOUSNESS
Ideally, loose coupling between the core and aspects and among aspects themselves is desirable. Obliviousness allows unanticipated changes to a software system to take place without invasive changes to the implementation. Some classes of applications, such as safety-critical systems and medical devices, raise concerns about applicability of obliviousness. A designer of a piece of safety-critical software might feel reluctant to have it "aspectorized" later on. This is true to a lesser degree for all systems. Real applications require compromises. The principle here is that the responsibility for the correctness of a composition between a core and aspects is at the point of making this composition. Unfortunately, this correctness depends on the properties of the core, the aspect, and the desired outcome. This implies that the core cannot be completely oblivious to potential adaptation but at least might need to express some form of abstract requirements, guarantees, or contracts with any potential extensional aspect. The same applies to aspects and interactions between them.
THE CHAPTERS
At the time of this writing, no major AOP application has "a profound impact on the economy and on how we live and work." Our best indication of the potential impact comes from a look at the current set of proto-applications. This section contains chapters that report on different domains for AOSD applications, evaluate the use of the particular AOSD technologies, and suggest future improvements on current technology to support particular application domains. These reports are valuable both for their guidance of the application of AOSD technology and for the feedback they provide to the development of that technology.
The first chapter in this part, Chapter 27, is "Developing Secure Applications Through Aspect-Oriented Programming," by Bart De Win, Wouter Joosen, and Frank Piessens. The paper reports on using AspectJ to develop security components for distributed applications. The paper focuses on the engineering of application-level security requirements such as authentication, auditing, authorization, confidentiality, integrity, and non-repudiation. Modularization of these is difficult to achieve without relying on AOSD technology. At the same time, good modularization is essential for non-invasive adaptation of these requirements. Unanticipated threats to security continue to emerge during the lifetime of system software because initial analyses are often incomplete, because new threats emerge, and because the environment in which the software operates changes. The paper discusses limitations of AspectJ, such as the mechanism to select join points, as well as some essential restrictions in the generalization phase towards the framework. We classify the first as a quantification semantics issue and the second as an obliviousness and semantics issue.
Chapter 28, "Structuring Operating System Aspects," by Yvonne Coady, Gregor Kiczales, Mike Feeley, Norm Hutchinson, and Joon Suan Ong, explores the use of aspects in operating systems. The authors use aspects to implement different variations of prefetching in the FreeBSD v3.3 operating system. The authors note that the original implementation of prefetching displays code tangling and that the implementation of the prefetching concern is not modularized. This results in a system where it is difficult to see the coordination of prefetching activities. The primary functionality of the page fault handling and file-system read-path becomes complicated. To modularize these crosscutting concerns, the authors extended the C language used by the operating system to include aspect-oriented capabilities. The extended language, AspectC, was used to reimplement the prefetching code. The two implementations are compared; the new system exhibits a clear coordination of the virtual machine and file system. The authors speculate that the use of aspect orientation has potential for improving modularity of operating systems structure in general.
In Chapter 29, "Aspect-Oriented Programming for Database Systems," Awais Rashid applies aspect-oriented programming to existing database systems. Domains such as databases for telecommunication and banking systems exhibit both a high degree of crosscutting concerns and a great demand for organization-specific customizations. Such customizations are difficult and expensive when done invasively. Using aspects enables modularizing those concerns, making the overall customization tasks achievable. Aspect orientation also supports manageable evolution of those systems. The chapter outlines how existing database systems may be incrementally evolved to incorporate aspect-oriented technology. Two levels of database crosscutting concerns are explored. The first is the database management system (DBMS) level, and the second is the database itself. For each of these levels, the author implements the modularization of a crosscutting concern typical to that level. Comparisons with non-AOP implementations of these examples demonstrate the advantages of the approach. The chapter concludes that aspect-oriented concepts hold a great promise for database systems and will be embraced by future systems.
Chapter 30 is "Two-Level Aspect Weaving to Support Evolution in Model-Driven Synthesis" by Jeff Gray, Janos Sztipanovits, Douglas C. Schmit, Ted Bapty, Sandeep Neema, and Aniruddha S. Gokhale. This application discusses the effect of applying AOSD techniques to domain-specific modeling and program synthesis. The authors are concerned with computer-aided tools for developing physical systems and devices. Their aspect-oriented domain modeling employs two levels of weaving. The top level is the constraint specification weaver. It is applied to a high-level abstraction of the system. The lower level of weaving is done during model interpretation. Crosscutting concerns can be modularized at the modeling level rather than only at the programming level. Their approach involves three concepts:
Model constraints. These modularize the mutual restrictions of the elements of the model. This contrasts with the traditional implementation of constraint descriptions, where the constraints are scattered throughout the model.
Model pointcuts. Model pointcuts capture quantification capabilities.
Strategies. Strategies define a collection of interchangeable heuristics.
The approach is illustrated by a model weaving of Eager-Lazy Evaluation Constraints. The chapter concludes by evaluating the benefits of using aspect-oriented domain modeling for exploring different design alternatives in domain specific models.
Our final chapter, Chapter 31, "Dynamic Aspect-Oriented Infrastructure," by Andrei Popovici, Gustavo Alonso, and Thomas Gross, presents the use of aspect orientation to implement "application awareness" for distributed applications. Application awareness is characterized by two main requirements: that the computing environment know of all running applications and their properties, and that it provide those applications with the necessary adaptations to local conditions. The variety of adaptations the system may have to deal with creates a fertile environment for aspect technology. Existing platforms lack the support for dynamically applying crosscutting concerns. With a conventional application design, the ability to react to changes is encoded in each appliance before it is deployed. This scattered implementation limits the application to coordinate and orchestrate the desired environment awareness. The authors have developed an AOP tool called PROSE, and they illustrate its use with an application involving the control of distributed robots. Of particular relevance to the development of AOSD is the discussion of the tradeoffs between stub weavers and advice weavers. The chapter demonstrates that with dynamic aspect orientation, one can implement adaptation by weaving aspects through mobile devices when they enter and leave a network. The newly established relationship between application awareness and dynamic aspect orientation has the potential for a productive coupling.
