CSC/ECE 517 Summer 2008/wiki1 5 bk

From Expertiza_Wiki
Jump to navigation Jump to search

Introduction

Hooks and aspect-oriented programming are two techniques which allow code to be modified on a large scale with minimal effort. Both approaches endeavour to provide a single point of modification in order to eliminate the need to make subtle changes throughout the code base. I will start by explaining these concepts in detail and then proceed to look at two implementations using aspect-oriented tools for both Ruby and Java. The example code will help to clarify certain points. I will also address how hooking is different from aspect-oriented programming as well as discuss the differences between AspectR and AspectJ, the AOP tools provided for Ruby and Java.

Hooking Concept

The hooking mechanism in Ruby allows events inside a running program to be identified while providing an action that will occur upon detection of the specified event. In this way, hooks serve as a detector of actions within the code, when event x is encountered, y will be performed. It is important to note that while hooking is possible in Ruby, it is not supported in Java. A few examples of where such a technique would prove useful include:

  • Recording when or how many times a method is called
  • Recording when an object is created
  • Debugging problematic code
  • Enhancing functionality of existing code [1]

Example of Hooking System Calls

The following is an example of a hook being inserted to perform an action when the program makes a system call. In order for this to occur, an alias must be created so that the original functionality can still be accessed. In this case, original_system is aliased to the unaltered system. Once this is done, we can freely modify the definition of system to perform just about any operation desired. This is similar to the way in which a nefarious hook, known as a rootkit, would work by still performing the intended operation of the code, but also appending something extra in the process... In our current non-malicious case, the system method has been modified to print the command being executed ("ls -al" in this case), the timestamp, and then finally executing the original instruction and sending the output to the command line [Thomas]. 

 module Kernel
   alias_method :original_system, :system
   def system(*args)
     puts "Your program executed the \"#{args.join(', ')}\" command." 
     puts "It was executed at: " + `date`
     puts "The command output the following: "
     original_system(*args)
   end
 end
 
 system("ls -al")

 Output:
 Your program executed the "ls -al" command.
 It was executed at: Mon Jun  2 21:19:27 EDT 2008
 The command output the following: 
 total 20
 drwxr-xr-x  2 brking brking 4096 2008-06-02 21:19 .
 drwxr-xr-x 18 brking brking 4096 2008-06-02 21:19 ..
 -rw-r--r--  1 brking brking  134 2008-06-01 22:01 fib.rb
 -rw-r--r--  1 brking brking  235 2008-06-02 20:29 hooking.rb
 -rw-r--r--  1 brking brking  287 2008-06-02 21:19 moreHooking.rb

Example of Hooking a Class Method

Similarly, a method could be hooked to perform additional tasks upon calling the method [Thomas]. The method would still carry out its original functionality, but the new instructions would precede or follow. In this example, the puts method of the IO class is hooked in order to print an additional statement to standard output every time puts is called. As in the previous example, the original method is aliased so that it can still be referenced after making enhancements. It is important to note that if you accidentally used :puts for the additional statement instead of :original_puts, you would create an infinite loop calling the modified puts [Thomas]. 

 class IO
   alias_method :original_puts, :puts
   def puts(*args)
     original_puts(*args)
     original_puts("You didn't ask for permission to speak!")
   end
 end

 puts "Hi there."

 Output:
 Hi there.
 You didn't ask for permission to speak!

Aspect-Oriented Programming Concept

Aspect-oriented programming deals with abstracting operations in code which are independent of the main purpose or function of the code. As an illustration, a program may have two completely unrelated classes, an automobile class and a plant class. Setting aside for a moment trying to conceive of an application where the two would reside together, there could potentially be similar data or operations desired from objects across both classes. For example, it might be worthwhile knowing the time in which each object gets instantiated, logging events on both objects, or even telling when they pass out of scope, These three commonalities are associated with each object of the class, but have nothing to do specifically with the functionality of the object. Clearly there are many other transcending operations that could be performed on either class.

In the aspect-oriented vernacular, this notion of functionality which transcends individual classes is known as a cross-cutting concern. In this way, it applies to multiple facets of the code, but does not specifically deal with the business or core concerns of the code. Jointpoints or pointcuts are the specific locations in the code where a cross-cutting of core concerns takes place. It is at these points, using aspect-oriented tools, that advice will be inserted. Advice is simply a function or group of functions for performing a task at this crossroads in the code. The aspect embodies the combination of the jointpoint and advice within the program. In the previous examples mentioned, there would be aspects for timestamps, event logging, and scope tracking [2]. It is important to note that the creation of aspects leaves the original underlying class intact and simply provides a wrapper which will encompass it. This ability to work on existing code without alteration has the added advantage of making it more adaptable to future changes and enhancement requests later in the application's life cycle. Aspect-orientation does not in any way undermine object-orientation. Aspect-oriented programming complements object-oriented programming in that OOP governs top-down relationships while AOP governs left-right relationships within the application [3].

Aspect-Oriented Programming Implementations

A non-aspect-oriented implementation of something as simple as logging would require logging statements to be manually inserted wherever needed. If you were looking for a return value of every method in every class to be output to a log file, this would become tedious, as a logging statement would have to be positioned prior to the return of each method call in the program. In addition to the insertion, if anything about the way logging was handled were changed, then each logging statement would have to also be changed individually in an error prone manner [4]. By identifying logging as a cross-cutting concern and assigning advice to address it, only the advice ever need be changed. The advice will reside completely separate from the original code which will keep the application from being riddled with logging statements. The primary aspect-oriented tools for Ruby and Java are AspectR and AspectJ respectively. Below are samples provided to illustrate the aspect-oriented approach for logging in both AspectR and AspectJ.

Example Using AspectR

The following is a sample implementation of AspectR used for logging [5]. AspectR integrates fairly cleanly with standard Ruby conventions. The aspect classes, in this case logger, are subclassed from the Aspect class. Within the user-defined aspect classes, the advice methods can be defined. The advice methods in this example are log_enter and log_exit. Advice methods in AspectR share the form: 

 def someAdviceMethod(method, object, exitstatus, *args)

Looking at each of the parameters, Method is the method to be wrapped (regular language expressions can be used here) and object is the object which will receive the method call. Exit status and additional arguments can also be specified [6] 

 require 'aspectr'
 include AspectR
 class Logger < Aspect
   def tick; "#{Time.now.strftime('%Y-%m-%d %X')}"; end
   def log_enter(method, object, exitstatus, *args)
     $stderr.puts "#{tick} #{self.class}##{method}: args = #{args.inspect}"
   end
   def log_exit(method, object, exitstatus, *args)
     $stderr.print "#{tick} #{self.class}##{method}: exited "
     if exitstatus.kind_of?(Array)
       $stderr.puts "normally returning #{exitstatus[0].inspect}"
     elsif exitstatus == true
       $stderr.puts "with exception '#{$!}'"
     else
       $stderr.puts "normally"
     end
   end
 end

Example Using AspectJ

The following is a sample implementation of AspectJ used for logging [7]. As in the AspectR example, upon closer examination it is fairly easy to follow what is taking place. Immediately within the TraceAspect aspect, the Java logger is initialized and the pointcut traceMethods are defined. The "!within(TraceAspect)" tells the code to not perform the logging trace within the aspect code since it will be performing it everywhere else as indicated by the wildcards. TraceMethods will reach every method and output the timestamp, class and method name, along with an indication that the method is being "entered." 

 import java.util.logging.*;
 import org.aspectj.lang.*;
 public aspect TraceAspect {
   private Logger _logger = Logger.getLogger("trace");
   pointcut traceMethods()
     : execution(* *.*(..)) && !within(TraceAspect);
   before() : traceMethods() {
     Signature sig = thisJoinPointStaticPart.getSignature();
     _logger.logp(Level.INFO, sig.getDeclaringType().getName(),
       sig.getName(), "Entering");
   }
 }

Notice the familiar class-like structure of the aspect as laid out in AspectJ. Appearances can be deceiving. While having much in common with classes, there are also differences as pointed out by the AspectJ developers.

Similarities include [8]:

  • Aspects have type
  • Aspects can extend classes and other aspects
  • Aspects can be abstract or concrete
  • Non-abstract aspects can be instantiated
  • Aspects can have static and non-static state and behavior
  • Aspects can have fields, methods, and types as members
  • The members of non-privileged aspects follow the same accessibility rules as those of classes

Differences include [9]:

  • Aspects can additionally include as members pointcuts, advice, and inter-type declarations;
  • Aspects can be qualified by specifying the context in which the non-static state is available
  • Aspects can't be used interchangeably with classes
  • Aspects don't have constructors or finalizers, and they cannot be created with the new operator; they are automatically available as needed.
  • Privileged aspects can access private members of other types

Conclusions

AspectR versus ApectJ

Basic Code Structure of AspectJ Aspect: 

 aspect theAspect {
   pointcut joinPoints() : within("ClassHere"); # Specify the class for the advice to be applied to 
   before() : joinPoints() {
     System.out.println("Jointpoint before triggering action in class."); # Statement printed before trigger
   }
   after() : joinPoints() {
     System.out.println("Jointpoint after triggering action in class"); # Statement printed after trigger
   }
 }

Basic Code Structure of AspectR Aspect: 

 class theAspect < AspectR::Aspect
   def before_jointPoint(method, object, exit, *args)
     puts "Jointpoint before triggering action in class." # Statement printed before trigger
   end
   def after_jointPoint(method, object, exit, *args)
     puts "Jointpoint after triggering action in class." # Statement printed after trigger
   end
 end

AspectR and AspectJ both facilitate the use of aspect-oriented programming in their respective languages. How they go about doing so does differ. The above code demonstrates the basic structure of the aspect definitions in AspectR and AspectJ [10][11]. Beneath the surface in AspectJ, the AOP code is preprocessed prior to being compiled into bytecode. So, essentially there are two compilations that must occur. In the case of AspectR, the AOP wrapping is performed dynamically at runtime, which does create additional overhead, but adds flexibility. In addition, as mentioned above, aspects in AspectR are truly classes while aspects in AspectJ are implemented as an extension of the language. By using native techniques, you can accomplish a great deal without having to learn additional syntax [12]. This demonstrates the power and dynamic nature of Ruby in that the AOP can be performed using its existing implementation, but the extended nature of AspectJ allows for optimizations which do not affect the performance of the underlying application [13]. In addition, when defining aspects, AspectR supports the use of regular expressions but AspectJ has its own specialized syntax.

Another important factor to consider is that AspectR is still in its infancy, as it is an alpha release, and is therefore not as well developed as AspectJ, at least at this point in time. The creators of AspectR admit that it is currently missing minor features present in AspectJ [14]. However, many of these minor shortcomings can be programmed around using the dynamic nature of Ruby [15]. It is important to note that while AspectR may be lacking in some of the features present in AspectJ, its code base is considerably smaller at around 300 lines [16]. General consensus among Ruby developers is that the somewhat slow development of AOP tools for Ruby is due to the ability of the language to implement a great deal of AOP functionality natively. The native structure of AspectR makes aspect-oriented programming far more convenient than with AspectJ.

Hooks versus Aspect-Oriented Programming Tools

Returning to the subject of hooking, given the nature of the aspect-oriented approach, it is easy to draw parallels with hooking techniques. In addition to interceptors [17] and mixins, Ruby hooks manage to cover a significant amount of what is present in separate AOP tools with the native Ruby object-oriented implementation [18]. Hooking in Ruby allows the injection of code for key events, but it does not allow for the specification of point-cuts as provided by aspect-oriented tools [19][20]. Also, aspects do not require editing of the class and a single aspect has the ability to affect different classes in different ways [21]. Recall in the earlier hooking example that the puts method had to be aliased and then modifications made within the method to achieve the desired effect. As previously mentioned, while not as complete as an AOP tool, Ruby offers the facilities to come fairly close with very little modification.

References and Resources for Additional Information

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Summer_2008/wiki1_5_bk&oldid=12759"