ASARTI Workshop 2003
Axon — Dynamic AOP through Runtime Inspection and Monitoring Swen Aussmann, Michael Haupt Software Technology Group, Computer Science Department Darmstadt University of Technology
[email protected],
[email protected]
April 25, 2003 Abstract This paper introduces Axon, a dynamic AOP approach for the Sun JVM. Axon uses run-time monitoring via the JVMDI (Java Virtual Machine Debug Interface) to join software with aspects that are meant to decorate it (weaving) and run-time inspection to get information needed by the aspects. It was influenced by ECA rules and other AOP approaches, especially AspectJ.
1
Introduction
Like object oriented programming, aspect oriented programming (AOP) was invented to help software developers to modularise their software. Nowaday’s huge software systems are only feasible with proper modularisation and programming paradigms supporting it. Although OOP is widely accepted in this regard it does not help in all circumstances. Often there are concerns which will not fit in functionally decomposed software modules. These concerns tend to be scattered all over the software modules. Moreover, code belonging to such concerns is often closely intertwined with code forming totally different functionality (tangled). This kind of concerns is called cross-cutting concerns. AOP aims at cleanly capturing cross-cutting concerns in separate modules (called aspects) and thereby achieving better modularisation. With cross-cutting concerns modeled as aspects it is also easier to decompose the software in a mainly functional manner, which leads to a more simple software structure in general. When software is decomposed mainly functional and cross-cutting concerns are captured in aspects there is the problem of joining these two dimensions together again
1
(this process is called weaving). There are several approaches to how and when weaving is done. On the one hand, cross-cutting functionality can be added to source code or to already compiled code (e. g., byte code, if Java is used as a programming language). On the other hand, an application can be augmented with cross-cutting functionality by monitoring its execution and intercepting it at appropriate points. The AspectJ system [1, 2] was, until recently, an example for a source code modifying system. Since its version 1.1, it operates on bytecode as well. JAC [7, 10] modifies byte code at load-time of the respective classes. Systems that monitor execution are, for example, the first generation of PROSE [11, 12], EAOP [5, 4] and the Axon system that is the main topic of this paper. The EAOP system modifies source code to add code for monitoring the execution of an application. But Axon, as we will see, does not modify source code or byte code but uses the JVMDI [8] for monitoring. Since Axon does not modify the decorated software at all, the information needed by aspects deployed in Axon is gathered by run-time inspection via the JMVDI and JNI. The remainder of this paper is organised as follows. In section 2, we will present the goals of Axon and its main sources of inspiration. Section 3 gives a survey over the Axon architecture, its way of working and its usage. The last section briefly discusses Axon and gives a short outlook.
2
Axon’s Origins
The following goals were leading in the design of Axon. First of all, the system should provide dynamic AOP (i. e., run-time activation and deactivation of aspects) for Java while still offering many features of existing static AOP approaches like AspectJ. Axon is intended to be a platform for further experiments in the field of dynamic AOP using an execution monitoring approach. Another major goal in the design of Axon was to decouple (a) the decorated software and the aspects that decorate it and (b) the definition of aspect functionality (advice code) and weaving descriptions (pointcuts) as much as possible. The first point allows for a non-invasive decoration of running applications with aspect functionality: no code should actually be modified. The second point avoids a too close coupling of aspects and the application they decorate.
2.1
Static vs. Dynamic AOP
AspectJ does not provide dynamic AOP: it statically changes the source (or byte) code of the software it decorates with aspectual behaviour. Nevertheless, its join point and pointcut models have strongly influenced the design of Axon. Dynamic AOP can be achieved regarding a running application as a series of events that signal the occurrence of join points (method calls, field accesses, . . . ), monitoring them [4, 6] and intercepting execution where appropriate. The EAOP system was the
2
1 2 3
before (): call (∗ toString ()) // Event && cflow(call(∗ ExampleApp.∗(..))) // Condition { System.out. println (” ...” ); } // Action Listing 1: ECA rules and AOP
first dynamic AOP system to adopt this approach. However, it changes source code to insert monitoring support which conflicts with the idea of non-invasiveness. Other tools for dynamic AOP in Java are JAC and PROSE. Like EAOP, these two need aspects to be implemented as Java classes that include their own weaving descriptions. We consider this a disadvantage since this class has to be recompiled whenever the weaving description changes, which in turn means that first a compiler has to be available and the AOP system must reload recompiled classes if it wants to apply weaving changes at run-time. Another disadvantage of EAOP and PROSE is that the weaving description is not cleanly separated from the aspect’s functionality. In our view this leads to a stronger coupling between an aspect and a particular software. Axon was deliberately designed to not suffer from these disadvantages.
2.2
ECA Rules
An important source of inspiration for the aspect model that underlies Axon are ECA rules (Event-Condition-Action rules) [3, 9], a concept stemming from the field of active databases. An active database provides, in addition to normal database functionality, the ability to react to events, like insert, delete or update operations as well as, for example, method invocations (in object-oriented databases), temporal and transaction control events. Active behaviour is defined using ECA rules. Such rules consist of events, conditions and actions. Upon the occurrence of the rule’s event the rule’s condition is evaluated. If it evaluates to true, the corresponding action is executed. ECA rules normally are first-class objects of the system that can be selectively activated, deactivated, created and destroyed while the database is running. When a running application is regarded as a sequence of events, ECA rules can be used to describe aspectual behaviour. Pointcuts can be described in terms of events (join points) and conditions, while the corresponding advice can be seen as an action associated with the events and conditions. Figure 1 shows a snippet of AspectJ code containing advice functionality along with a weaving description. The advice in the code is meant to be executed before the method toString () is called on an instance of an arbitrary class, but only if the call to toString () is originated in the control flow of any method of the class ExampleApp. In terms of ECA rules, the piece of advice code (line 3) forms the action part of such a rule that reacts to a toString () METHOD ENTRY event (line 1), but only if the condition holds that the event occurs due to a method call from a specific class (line 2).
3
Figure 1: Basic abstractions
3
Presentation of Axon
Axon works very similar to the way we described the workings of ECA rules. It is implemented as a plugin to Sun’s Java Virtual Machine and utilises the VM’s debugging facilities. Monitoring events are generated by the JVM, the conditions are checked by Axon via run-time inspection with JVMDI and JNI and the actions in Axon are Java methods. In figure 1 we see the basic abstractions in Axon. Aspects, pointcuts and advisory units are each represented by corresponding classes. Pointcuts describe an event at runtime (conditions are not yet part of Axon) and advisory units describe what actions have to be taken. Note that, unlike advice in AspectJ, advisory units do not contain advice functionality but entry points to methods that represent advice entry points, and definitions for passing parameters to these entry points. Actual advice functionality is implemented in a plain Java method in an arbitrary class. While pointcuts with their advisory units are seen as rules, aspects are seen as named sets of such rules. Aspects are used to group certain pointcuts and advisory units together so that they can be activated and deactivated as one. The registry is used for activation and deactivation of aspects. The dispatcher is only used by Axon itself: events generated by the JVM are passed to the dispatcher which in turn signals this event to all registered pointcuts interested in it. In figures 2 to 4 we see a simple example of how Axon can be used. Figure 2 contains a small application class with a field anAttribute and a method justDoIt (). Assume that we want to log anAttribute and the method parameter anInt if this method is called. The logging functionality itself is implemented in the Logger class (see Fig. 3). The weaving description is shown in figure 4. Before the application is actually run, an aspect is registered. To achieve this, the singleton AxonFactory which is used to create
4
1 2 3 4 5 6 7
public class Application { private int anAttribute = 0; public void justDoIt (int anInt){ // justDoIt } ... }
1 2 3 4 5
public class Logger{ public void log(int i1 , int i2){ // log these two ints } } Listing 3: Functionality for logging
Listing 2: A simple Application
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
public void main(String [] args){ try{ AxonFactory factory = AxonFactory.getAxonFactory(); Aspect logging = factory . createAspect(”Logger”); PointCut willDoIt = factory .createMethodEntryPC(”Application”, ”justDoIt”, ”(int)void”); AdvisoryUnit logIt = factory .createDynamicAdvisoryUnit(new Logger(), ”log”, ” ( int , int )void”); logit . appendCalleeFieldGetter (”anAttribute”, ”int” , false ); logit .appendCalleeMethodParamGetter(0); logging . associate ( willDoIt , logIt ); factory . getRegistry (). register ( logging ); } catch(AxonException e) {} Application anApp = new Application(); anApp.justDoIt(42); } Listing 4: Aspect creation and deployment
all kinds of Axon objects is obtained and an empty aspect is created. Next, in lines 5 and 6, a pointcut and an advisory unit are created. The pointcut is meant to react to method entries of the desired kind; the factory method is passed the class and method name as well as the signature of the method calls to which are to be intercepted. The advisory unit created in lines 7 to 10 has to call the aforementioned log () method in the passed instance of Logger. The parameters passed are the value of the anAttribute field in the object on which the pointcut was detected, and the first parameter of the called method. In lines 11 and 12, the created pointcut and advisory unit are first associated as parts of the created aspect, and that aspect is registered. From this time on, it is active. At run-time, a METHOD ENTRY event is created as soon as the call to anApp.justDoIt() is performed, but before a line of the called method is executed. The VM signals this event to the dispatcher which in turn notifies the registered PointCut instance of its occurrence. It is then checked if the event occurred in the method Application . justDoIt (),
5
which is the case. Therefore it triggers its advisory unit which gathers the information needed (the field and method parameter) via JVMDI and JNI. Since this information is available it calls the specified method with these parameters. After the advice method returns, the method originally called is executed. At the moment, Axon supports method entry/exit, exception throw/catch and field read/write pointcuts. The available advice entry points are static or non-static method calls. In the case that non-static method calls are used as advice entry points, it is possible to decide if the same object should be used with every activation of the advisory unit, or if there should be one instance of the advice class for each object wherein a pointcut is detected (resembling AspectJ’s perthis semantics). It is possible to pass a wide variety of parameter values to advice entry point methods. Both the callee and caller object or their classes, respectively, can be passed. Moreover, specific fields from callee and caller object can be read and passed to the advice. In the case of a field write join point, the new and old field value can be passed. Exception instances and classes can be passed if an exception was thrown or caught. Finally, it is possible to pass literal values.
4
Discussion and Summary
There is a number of features that will be added in future versions of Axon. This includes e. g., allowing pointcuts to be activated for subclasses of a specified class. It would be also nice to be able to specify conditions for pointcuts similar to how it is done with PROSE’s specialisers. Earlier in this paper, we have said that it was a disadvantage to describe a weaving description as a Java class. The example shows that Axon weaving descriptions are not classes but a sequence of API calls, which could change dynamically. Assume that an external parser module reads weaving descriptions and transforms them into the appropriate calls to the Axon API. No recompilation of weaving description classes would then be necessary. Such a parser is currently being developed, along with an XML-based weaving language. Exploiting the similarities of ECA rules and AOP leads to an intuitive approach and an easy to use API for creating, weaving and unweaving of aspects. Moreover, adopting ECA rule concepts leads to a more natural to comprehend support for dynamic AOP in general. However, the ECA rules-inspired model has also its drawbacks. For example, AspectJ’s around advice which can replace the called method with advice functionality, are not easily feasible when, like with Axon, an approach is chosen that is solely based on interception at join points. Implementing Axon as a debugger-based VM plugin was comparatively easy as no VM-internal logic had to be changed. However, Axon is quite slow as the debugger imposes a certain overhead on the execution of applications.
6
References [1] AspectJ Home Page. http://eclipse.org/aspectj. [2] AspectJ Team. The AspectJ programming guide. February 2002. [3] U. Dayal, A. P. Buchmann, and D. R. McCarthy. Rules are Objects Too: A Knowledge Model for an Active, Object-Oriented Database System. In K. R. Dittrich, editor, Advances in Object-Oriented Database Systems, 2nd International Workshop on Object-Oriented Database Systems, volume 334 of Lecture Notes In Computer Science, pages 129–143. Springer, 1988. [4] Remi Douence, Olivier Motelet, and Mario Sudholt. A formal definition of crosscuts. In Proceedings of the Third International Conference on Metalevel Architectures and Separation of Crosscutting Concerns (Reflection 2001), volume 2192 of Lecture Notes in Computer Science, pages 170–186, Berlin, Heidelberg, and New York, September 2001. Springer-Verlag. [5] EAOP Home Page. http://www.emn.fr/x-info/eaop/. [6] R. E. Filman and K. Havelund. Source-Code Instrumentation and Quantification of Events. In G. T. Leavens and R. Cytron, editors, FOAL 2002 Proceedings: Foundations of Aspect-Oriented Languages Workshop at AOSD 2002, Twente, The Netherlands, pages 45–49, Ames, Iowa 50011-1040, USA, 2002. Department of Computer Science, Iowa State University. [7] JAC Home Page. http://jac.aopsys.com/. [8] Java Platform Debugger Architecture Home Page. http://java.sun.com/j2se/ 1.4.1/docs/guide/jpda/index.html. [9] N. W. Paton and O. D´ıaz. Introduction. In N. W. Paton, editor, Active Rules in Database Systems, chapter 1, pages 3–27. Springer Verlag New York Inc., 1999. [10] Renaud Pawlak, Laurence Duchien, Generad Florin, Fabrice Legond-Aubry, Lionel Seinturier, and Laurent Martelli. JAC: An aspect-based distributed dynamic framework. Dez 2002. [11] A. Popovici, T. Gross, and G. Alonso. Dynamic Weaving for Aspect-Oriented Programming. In G. Kiczales, editor, AOSD 2002. 1st International Conference on Aspect-Oriented Software Development. ACM Press, 2002. [12] Prose Home Page. http://prose.ethz.ch/Wiki.jsp?page=AboutProse.
7
