• No results found

Classification of Current AOP Frameworks 50

CHAPTER 2   LITERATURE REVIEW 8

2.4   Current state of Aspect Oriented Programming (AOP) 40

2.4.2   Classification of Current AOP Frameworks 50

Current AOP research projects can be classified into two categories: heavyweight AOP and lightweight AOP. Heavyweight AOP is usually characterised where the actual language itself has AO concepts built in, such as AspectJ [60]. Lightweight AOP uses existing OO or other methods to implement Aspects with minimal disruption to the existing language or approach. Lightweight AOP is often found in Enterprise frameworks such as Spring [80], JBoss [74] or even within standalone development like AspectWerkz [59] and is usually based on configuration files defining the Aspects that are to be woven into an unchanged language such as Java or C#.

2.4.2.1 Popular Heavyweight AOP Frameworks

AspectJ

AspectJ [60][92] is the most popular and mature aspect-oriented Java implementation, which was developed specifically to popularize the idea of aspect oriented programming in the Java community. AspectJ is now

51

available as an Eclipse Foundation open-source project [62], both stand- alone and integrated into Eclipse.

AspectJ is a heavyweight AOP implementation. It uses Java-like syntax and has included IDE integrations for displaying crosscutting structure since its initial public release in 2001. AspectJ introduces new keywords to the Java language for defining Aspects and join points. Tightly integrated with Java, the major advantage of AspectJ is the expressiveness of its “pointcut” language, which can be used to describe the pointcuts and advices clearly. The pointcut language describes the condition on which the corresponding Aspect advice is executed. This means that the developer must learn additional language syntax and use the AspectJ compiler in order to build any code written with AspectJ. In AspectJ, developers do not need to modify the client code because all Aspects, pointcuts, advices, etc. are saved in separate source files.

AspectJ uses static weaving at compile time, although the most recent version of AspectJ does provide some initial support for weaving to be performed at class load time. In all cases, the AspectJ program is transformed into a valid standard Java program running in a Java virtual machine. All classes affected by Aspects are binary-compatible with the unaffected classes.

However, AspectJ also has its weakness [99][137][152] as shown below:  High coupling: most of the current pointcut designators explicitly

specify their target locations by naming these classes/methods. These explicit references obviously introduce a high coupling between the original system and the Aspects, making Aspect reuse harder. AspectJ does not allow the specification for a crosscutting concern to be written as a separate entity from the Aspect itself, therefore the developer must have a full understanding of the Aspect

52

code and thus cannot use or reuse the Aspect in a black box manner [107]. AspectJ offers wild-cards to reduce coupling. However, this introduces a new problem as the wild-cards are not checked by the compiler. As a result, programmers have to be very careful with their pointcuts to avoid wrong or missed matches.

 Complicated syntax: although very powerful, the language is now full of complicated, semantically challenged constructions that are added to standard Java syntax.

 Debugging: one of the greatest problems for AspectJ is debugging. While at the syntactic level AspectJ program code appears separate, at run-time it is not. Therefore, after weaving, the execution of the final system can become unpredictable.

AspectC++

AspectC++ [71][133] extends the AspectJ approach to C/C++. It is a set of C++ language extensions to facilitate aspect-oriented programming with C/C++. While being strongly influenced by the AspectJ language model, AspectC++ claims that it supports all additional concepts that are unique to the C++ domain. This ranges from global functions, operators, and multiple inheritance up to weaving in template code and join point-specific instantiation of templates [105].

aoPHP

aoPHP [70] is an addition to PHP that allows the use of Aspect-Oriented programming in web based applications.

aoPHP was originally developed in Java 1.5. It relied on a PHP script and Apache's mod_rewrite module to properly redirect incoming calls to PHP Scripts. The calls to PHP Scripts were redirected to the aoPHP weaver where Aspects were woven at run-time on the server. The resulting code,

53

which was the output of aoPHP weaver, was then passed to Apache PHP engine to be executed and displayed.

The current versions of aoPHP (version: 4.0) works in a very similar way to the original version. It still relies on a PHP script to call the weaver. However the weaver is now written in C++ with full support for Regular Expressions. Therefore, the new weaver provides a good improvement in both performance and speed of the parser and weaver.

2.4.2.2 Popular Lightweight AOP Frameworks

AspectWerkz

AspectWerkz [59] is a lightweight AOP framework without modifying the Java language in any way. This means that there is no new syntax for a developer to learn. It is capable of compile time, load-time, and run-time weaving.

AspectWerkz also supports annotations. That is, join points can be marked through Java annotations. This is a powerful mechanism that can alleviate some of the concerns caused by having the Aspects completely separate from the implementation. Now, Aspect oriented features can be declared as annotations.

Spring AOP

Spring AOP [80] is implemented in pure Java. There is no need for a special compilation process. Spring AOP does not need to control the class loader hierarchy, and is thus suitable for use in a J2EE web container or application server.

54

Spring AOP currently supports only method execution join points (advising the execution of methods on Spring beans). Field interception is not implemented, although support for field interception could be added without breaking the core Spring AOP APIs.

Spring AOP's approach to AOP differs from that of most other AOP frameworks. The aim is not to provide the most complete AOP implementation; therefore Spring AOP does not compete with AspectJ to provide a comprehensive AOP solution. Spring AOP tries to provide a close integration between AOP implementation and to help solve common problems in enterprise applications.

AOP in JBoss

The JBoss AOP is an alternative to the AspectJ Java implementation. JBoss AOP [68] is a pure Java Aspect Oriented Framework. JBoss AOP is not only a framework, but also a pre-packaged set of Aspects that are applied via annotations, pointcut expressions, or dynamically at runtime such as caching, transactions, security, etc. The JBoss AOP Framework, although available as a separate library, is also heavily used by the latest version of the JBoss application server.