Section 17.4. IMPLEMENTATION

17.4. IMPLEMENTATION

The initial focus of AOSD on the implementation level has resulted in a range of programming approaches. AspectJ [5] is an aspect language for Java. It supports formulation of the aspect code separately from Java class code. The aspect code is written with reference to join points in the dynamic object call graph. An aspect weaver composes the aspects and the classes, and there is additional development support in the form of IDE (integrated development environment) extensions. AOP extensions to other languages have also been developed. AspectS [40], for example, is an aspect language for Smalltalk, while AspectC [4] is an AspectJ-like AOP extension to C.

The composition filters approach [8] extends an object with input and output filters. These filters can be of various types (e.g., dispatch filters for delegating messages and wait filters for buffering messages) and are used to localize non-functional code. JAC (Java aspect components framework) [64] employs reflection and wrappers to support dynamic aspect composition in Java (see Section 17.5). Several other frameworks support dynamic aspect composition, such as AspectWerkz [12] and JBoss [44] (see Section 17.5).

Adaptive programming [58] is a special case of AOP, where one of the building blocks is expressible in terms of graphs. The other building blocks refer to the graphs using traversal strategies. A traversal strategy can be viewed as a partial specification of a class diagram. This traversal strategy crosscuts the class graphs. Instead of hard-wiring structural knowledge paths within the classes, this knowledge is separated.

Hyper/J [61], the programming tool supporting the hyperspaces approach [79], introduces the notion of multi-dimensional separation of concerns at the implementation level by capturing each concern as a partial object model in a hyperslice. The hyperslices are composed into hypermodules by means of declarative composition rules. This permits the clean separation of multiple, potentially overlapping and interacting concerns simultaneously with support for on-demand remodularization to encapsulate new concerns at any time.

Figure 17-1 shows the process of identifying a suitable aspect-oriented programming technique when implementing an application. Most aspect-oriented programming techniques support one or more base programming languages. For example, aspect languages are available for separation of crosscutting concerns in Java (AspectJ), C (AspectC), and Smalltalk (AspectS). The Hyper/J tool supports multi-dimensional separation of concerns in Java using the hyperspaces approach. The composition filters approach, on the other hand, has been implemented for Java, C++, and Smalltalk. Therefore, the first natural step in the choice of a suitable technique is to reduce the available set of techniques to those that support the base programming language to be employed in application development. If no suitable technique is available for the base programming language, then a custom language and weaver need to be implemented, as for the SADES object database evolution system [67].

Figure 17-1. Process of choosing a suitable aspect-oriented programming technique.

The second step in the identification of a suitable programming technique is not as simple as the first. It is composed of the dynamics of three different factors (Figure 17-1): the nature of the concern being modularized, the system requirements, and decisions made at the design stage. All these factors need to be considered in conjunction with each other; only then can the set of available techniques be reduced to the ones most suitable for the application.

The nature of the concern being modularized can often strongly influence the choice of aspect-oriented programming technique. This is because, although the various techniques tend to be complementary, one can be more suitable for implementing a particular concern. Adaptive programming, for instance, is highly suitable for expressing concerns that involve separation of behavior from object structure. It is very effective in situations where the behavior may be written against a partial specification of a class diagram or a generic specification of the structure of objects (not relating to information specific to individual instances). Examples of such generic specifications include traversal strategies for change propagation and referential integrity semantics in an object-oriented system [66]. These strategies need to know the types of relationships or manipulation operations but do not need to be aware of the information specific to individual relationship instances.

Composition Filters are very effective in implementing concerns involving message interception and execution of actions before and after executing a method. Their key characteristic is the ability to operate at instance granularity and attachment on a per-instance basis. For example, when modularizing relationships in an object-oriented system, a dispatch filter for handling a relationship can be attached to an instance when the relationship is established [66]. If message interception is not required on a per-instance basis, then mechanisms similar to advices in aspect languages (e.g., AspectJ), which operate on the extent of a class, are more suitable than composition filters.

Aspect languages are also very suitable in implementing concerns that need to be explicitly represented using linguistic constructs. Expression of such concerns can be simplified if the aspect language is declarative in nature. An example of such a declarative aspect language is the one employed for specifying instance adaptation behavior in SADES (see Chapter 29, "Aspect-Oriented Programming for Database Systems").

Other techniques have their strengths. For example, Hyper/J is very effective in situations involving remodularization of a legacy application. The reflective architecture of JAC, on the other hand, makes it highly suitable for developing generic aspects that can be reused across different applications. However, as mentioned earlier, the choice of a technique is also constrained by the system requirements and the chosen design. Dynamic aspects as in JAC (or frameworks such as AspectWerkz and JBoss) are only suitable for situations where an aspect needs to be adapted and recomposed at runtime. If an aspect does not need any customization at runtime, then for performance optimization, it is better to employ a technique where aspects do not live beyond compile time or are merely reified for some degree of run-time introspection [69], as in AspectJ. The design decisions can also have a similar impact on the choice of a suitable technique. For example, in the SADES implementation, the design decision to separate information about links among entities into relationship objects dictated that these relationship objects be attached to their participating entities on a per-instance basis and, hence, led to the choice of Composition Filters.