1 Introduction
Traditional programming techniques, using decomposition to divide a software system into a relatively small, easy to analyze, understand, if these modules are still difficult to analyze, understand, the iteration is broken down into smaller modules until these Modules can be easily analyzed, understood, design and encoding. These modules are assembled in a programming language to form a final software system by analyzing these modules, and then implemented these modules in the programming language. For example, in process programming, the system is decomposed into a function of completing a single function, and complex functions are completed through the call between the functions, and ultimately form this system. Object-oriented programming, through analysis, abstracts a series of objects with certain properties and behavior, and complete the system's functionality through collaboration between these objects.
Traditional programming techniques tend to segment software systems in accordance with functions or behaviors, and the result of this segmentation is a module that implements a function, such as functions, procedures, classes, and more. However, in programming practice, it is recognized that some behavior in the software system cannot package in a single module, such as logging, matter processing, the context-sensitive error handling, performance optimization, and more. Usually these functions and behavior do not implement the system's business function, but assist these functions, and spread in many modules that implement system functions, resulting in tangling of code, which makes code difficult to read, understand, and Debug, maintenance and expansion, etc., and make the entangled code difficult to multiplex. If we will implement the module of the system business function as the longitudinal decomposition unit of the system, the function and behavior of the above disperse form a horizontal aspect, aspects and modules form cross cuts (crosscutting) A traditional programming technology cannot be modularized, causing two code tangles.
Therefore, we need a new programming idea to process cross-cutting aspects in the system, resolve the resulting code entangled, and make the aspects can be modular, facilitate the multiplexing of functional modules and aspects.
2 AOP
Aspect-Oriented Programming, AOP is a new programming idea that is distinguished from traditional programming technology, initially subjected to a research group led by Gregor Kiczales in the Palo Alto Research Center of Xerox ALTO in 1997. AOP is based on aspects of the formation and module, resulting in this observation, and proposes a new programming idea to solve this problem. Later, AOP has developed through several different groups of efforts in their respective directions, so far, AOP is still in development.
2.1 Basic Thoughts of AOP
As mentioned earlier, the reason for code entanglement is that the code in which the non-business function implementation implemented in the software system cannot be modular, which is caused by the code that implements the service function. Here, we introduce the concept of concerns (Concern), and the focus is the problem that needs to be solved in the software system. The business function of the software system has formed core concerns, which is the problem to be solved by software systems, and concerns such as log records, things such as logging, crosscutting converns, because these attention In the core focus point, the point is found to have a cross-cut relationship, which is the concept of the previous mentioned aspects.
In view of this, the solution proposed by AOP is to encode the two mutually cross-cutting points, using traditional programming languages, and use the face-oriented programming language to cross-cut concerns, that is, aspects Perform programming. Then use a mechanism to automatically mix the two code to form the final code. Here, aspect-oriented programming languages can be extensive existing programming languages (Aspectj, AspectC , Aspectc, AspectC #, APOSTLE, etc.), or a new language, design code for writing (Caesar, D2al, Jasco, etc.). The mechanism mixing between two code is called weaving, and the tool for achieving this mechanism is called a Weaver. Therefore, it is separately encoded, and the two code is mixed by appropriate woven mechanisms, which constitutes the cornerstone of AOP solving code entangled problem. 2.2 Woven mechanism
As mentioned earlier, the woven is an important mechanism for achieving AOP. There are a variety of weaving implementation mechanisms, substantially divided into two categories, static woven and dynamically woven. Static woven is the appropriate location in the business function code, such as a certain code execution, or after execution, insertion of the coded, thereby forming a mixed encoding. The encoding in the aspect has been inlined to the business function code before the program is running. Therefore, the code can be optimized, so that the overhead produced by the woven is minimized, the final resulting mixed code, the execution speed is close to the use of AOP mode Written code. However, static woven is unable to do this when the program is running, according to the aspect of the decision inserted by the context dynamic, dynamically woven, can do this. Dynamic woven can be done in accordance with the context, increase or delete one aspect.
According to the woven time, it can be divided into three categories, compile, when loading, running. When compiling, you can prepare before compiling, automatically mix the two code, automatically insert the code in the aspect of the function module code, or after compiling, the compiled code is operated. When loading, it is woven when the code is loaded, and the code is realized. Operation is running at runtime, performing the appropriate aspect code based on the call to the method to achieve the woven.
Taking the Java implementation of AOP as an example, including the use of reflection, dynamic proxy or other mechanism-based intercept frames, metadata-based operations, as well as the operation of the bytecode when the class is loaded, etc. . With the further promotion of AOP applications, it is believed that there will be more new woven methods.
3 AOP implementation mechanism
According to the AOSD (Aspect-Oriented Software Developments,
The statistics of http://aosd.net, currently related to AOP projects have reached nearly 100, and more than 20 of Java-based AOP implementation mechanisms have more than two of the following are commercially available. Java's AOP implementation mechanism.
3.1 aspectj
Aspectj is currently the most complete AOP language, and a group led by AOP's first proposal Gregor Kiczales and has been developed. Aspectj is an extension to the Java programming language. By adding some new structural blocks to support the modular packages of cross-cutting points, it is a typical use of static woven from the code level of code. AOP implementation mechanism. Aspectj provides two transverse realization mechanisms, a dynamic crosscutting, and another static crosscutting. Dynamic cross-cutting refers to a pre-defined implementation in a clear point in the program, is a static implementation mechanism, not dynamic. In order to achieve dynamic transverse, four new concepts are introduced in Aspectj: Join Point, Pointcut, Advice, and aspect. (ASPECT). The connection point is a point in which the program execution process is clear. The entry point refers to a set of associated connection points. Reference defines additional implementation of the connection point execution, aspects refers to a modular package of cross-cutting points. The unit implemented, similar to the class in the AOP, consisting of the entry point, reference to the normal Java member statement. As mentioned earlier, the connection point is a point in which the program execution is clear, for example, when the method is called, the method is called, the attribute access is an example of the connection point, and the predefined additional implementation can be performed at the connection point. . To indicate which connection points, you need to define the entry point, the entry point can match the specific connection point when the program is running, and a series of standard entry points are predefined in Aspectj, including the call to the constructor, accept call , Execution, domain GET, SET Access, exception handling, instance type matching, in the class or method body, in the control flow, the caller call method, the initialization of the type, and the static initialization, the combination of these predefined entrants can be implemented. Custom, complex entry point. At compile time, reference will be converted to a standard method, and the connection point of the matching point in the class code will be converted to a static markup point, and then these static points will be converted to the reference. The call is replaced, thereby completing the woven entry of the two code, and finally compiles the resulting code to the bytecode, that is, the entire compilation process is completed. At present, Aspectj supports the fabrication of code before compiling, and also supports compiled bytecode operations.
Static cross-cutting refers to the introduction of new methods, attributes, attributes, etc., with dynamic transverse, and dynamic behavior, but also changes their static structures, but also import (Introduction). By declaring the method, attribute, the superclass, the interface, etc. inherited in the aspect of the code, the definition of classes that apply this aspect can be changed when the code is woven.
3.2 AspectWerkz
AspectWerkz is a dynamic AOP framework that utilizes woven in terms of modification of the bytecode, and implements dynamic AOP requirements using the dynamic replacement of the Java virtual machine. AspectWerkz does not extend Java language, aspects, reference, entry points, etc., using standard Java construction blocks, ie, class, and methods, and use XML files to define these structural blocks, and the AspectWerkz also supports running period attribute definitions implemented using JavadoC tags. . AspectWerkz adopts a connection point model similar to the AspectJ, just supported connection points less than aspectj, the reference type is consistent. AspectWerkz is introduced into an indirect layer, aspect container and the conversion of the bytecode, that is, the code is designed to implement dynamic AOP requirements, the container management deployment class, aspect code, and according to XML file or javadoc comments Aspects, reference, entry point, and the like to obtain associated aspect information at the connection point, and control the execution flow in the execution of the program, and perform the appropriate reference at the matching connection point.
AspectWerkz intercepts class loads by intercepting class loads by an appropriate location of the class load hierarchy. AspectWerkz provides two woven patterns to implement AOP: static woven and dynamically woven. Static woven is only transformed from the bytecode when the class is loaded. By moving the class's method to the ASPECTWERKZ named method, the code rewrite the code in the original method, and the appropriate reference is called by the container. The method of the ASPECTWERKZ is added to complete the woven. Import is implemented by a mixed type (Mixin), which is used to add a new method for classes, and the mixing type is a mechanism for simulating multiple inheritance using an interface and implementation class. AspectWerkz implements a hybrid type interface by modifying a band code, and assigns control to the container manager in the interface definition method, which is called to complete the call. Static woven can be dynamically increased at runtime, delete a reference, can introduce a new reference, but you can't define a new entry point, which requires dynamic to woven. Dynamic woven is done by two phases, which are class load phases and activation stages, respectively. First, when the class is loaded, a corresponding empty method is added to each method that needs to realize the dynamically woven class, except for the method of matching the connection point. Then, in the activation phase, the code in the original method body will be swapped to the newly generated method of class load, the original method will achieve the same processing as the static woven, thereby control flow. The aforementioned code exchange is implemented by hotswap, which is an API provided by JVM. AspectWerkz provides dynamic AOP implementation through aspect containers and woven models.
3.3 Springframework
SpringFramework is a J2EE-based lightweight application framework with Inversion of Control, IOCs. The core of SpringFramework is IOC container, for other applications, such as database access, log, etc. SpringFramework uses existing, mature frameworks. SpringFramework uses a modular way, and each module can be used together, or one of the modules of SpringFramework provides support for dynamic AOP, and the declarative transaction management provided in SpringFramework is based on dynamic AOP.
The implementation of AOP in SpringFramework is based on dynamic proxy. The dynamic agent is derived from the proxy mode, that is, the access to the business object is implemented through the interface, but the dynamic agent does not need to generate a proxy object to each required business object, only need Providing an interface and proxy implementation that requires a proxy, you can generate a proxy object during runtime, the agent's access to the above interface, the same mechanism is also used for the derived agents, using a modem, by subcatenification achieve. Springframework defaults to the dynamic proxy mechanism provided by JDK, at which point, the business object is programmed by interface. If you need a proxy to access, you will need to use CGLIB, which is an open source dynamic proxy implementation. Springframework's AOP implementation is different from AspectJ and AspectWerkz, it is not a full AOP implementation, but is designed to implement AOP in the application server environment, and use the SpringFramework IOC container. In the SpringFramework, the entry points and aspects are implemented by ordinary Java objects, where the connection point model is the same as AspectJ, but it is not as far as the aspectj, and currently only provides interception of method calls. There are four types of references, and when the method is called, the reference type can be customized by implementing the SpringFramework, respectively, and the reference interface of the SpringFramework is customized. In SpringFramework, aspect is called Advisor, a Java class containing a reference and entry point. Like other components managed by the IOC container, reference, entry points, and aspects are also managed by the IOC container, defined by an XML configuration file. Configuring content includes interfaces and implementations of business objects, custom, or entry points provided by SpringFramework, or replacing a separate entry point with the reference class using an Adviser class. At runtime, you can automatically generate a proxy object by the container using the proxy mechanism, and performing a reference at the connection point defined by the entry point. SpringFramework except for its own AOP framework, the integration with other AOP implementation mechanisms is now implemented, and the integration with Aspectj is currently implemented to use AspectJ rich entry point syntax and use aspectj's aspect.
3.4 JBoss
JBoss is an open source compliant with J2EE specification, as a J2EE specification, the AOP framework is introduced in JBoss, providing J2EE services for normal Java classes without following the EJB specification. When JBoss is loaded, use Javassist to implement dynamic AOP frameworks for the bytecode operation, JavaSST is an open source editing code code.
In the JBoss, the entry point and aspects are also implemented by a normal Java object and use an XML file configuration. The JBoss's connection point model is slightly different from Aspectj, providing a series of predefined entry points, including class matching, method calls, constructor calls, domain access, specific calls and modified relationships. Through the logical operation of these entry points, a more complex entry point can be achieved. Aspects are Java classes, reference is one of the methods, and there is no entry point in terms of aspects, mainly for various interceptors, the interceptor is only one reference, and the single connection point can be made up of multiple interceptors. Form an interceptor chain, an interceptor performs additional operations. Interception of the method is managed by Advisor class, and then calls the interceptor in the connection point and finally calls the logical method. Information about the entry point, reference, and aspects are managed by AspectManager. In addition, JBOSS provides support for metadata for additional properties to classes, methods, constructors, and domains and can be accessed in operation. To implement interception, JBoss needs to modify the bytecode of the class, which is the process below. Information about the entry point, interceptor, metadata, and mixed classes in the XML configuration file are read, parsed, and generate the corresponding objects when the application deployment, which is managed by the ASPECTManager. When the class load that needs to be mixed, the AspectManager will create an Advisor class, pass the relevant information to it, and modify the bytecode of the class, then handle the modified bytecode to the class loader. The load of the class. The modification of the bytecode is mainly to add a series of methods to the loaded classes to proxy methods calls, constructor calls, domain access, and method imports, and to the call to the ADVISOR class. Each method in the class will rename, retain the original method body, and add a method of the same name with the original method. In this method, those proxy methods are called to call the agent to the Advisor class, or call the renamed original method. For domain access, add two methods, corresponding to read and write operations, to access the domain access agent to the Advisor class, in which the domain is accessed, the access to the domain is required to call the above method. For the constructor call, add a method to call the agent to the Advisor class, and convert the constructor of the structure of the constructor. For imports, a mixed class implementation will be added in the introduced class, and the method in the hybrid interface is added, and the call to the mixing class method is proxy to the Advisor class, and the implementation of the hybrid class is finally called. After the relevant class is loaded, the Advisor class is initialized to fill in the interceptor chain to complete the entire process.
4 Conclusion
AOP is not a technique for replacing traditional programming technology, but a supplement to these technologies, which solves some of the problems that some traditional technologies cannot be solved. Especially for object-oriented technologies, it can make each other, solve the problem of cross-cutting attention in the core code, and cannot modify the problem in software systems. Separate different attention points. Although the current AOP is still in the development stage, many practical applications and academic research projects have emerged, and some recognized basic elements have been accumulated for AOP. It is foreseeable that the current AOP will bring changes to software development like OOP 20 years ago.
references
1 Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Videira Lopes, C., Loingtier, J.-m., And Irwin, J. Aspect-Oriented Programming. In Proc. Of ecoop Springer-Verlag (1997) .2 Kai Bollert. On Weaving Aspects. In Proc. Of Ecoop, Springer-Verlag (1999).
3 Dynamic Weaving for Aspect-Oriented Programming. A. Popovici, T. Gross, and G. Alonso. Proceedings of Aosd, Enschede, The Netherlands (2002).
4 Gregor Kiczales, Erik Hilsdale, JIM HUGUNIN, MIK KERSTEN, JEFFREY PALM AND WILLIAM G. GRISWOLD. An Overview of Aspectj. In Proc. Of ecoop, Springer-Verlag (2001).
5. Alexandre Vasseur. Dynamic AOP and Runtime Weaving for Java - How does aspectWerkz Address It? In Dynamic AOP Workshop of Aosd 2004
6. Jonas Boner. AspectWerkz? Dynamic AOP for Java.
http://aspectwerkz.codehaus.org/papers_talks.html
7. Rod Johnson, etc. Spring Reference Documentation.
http://www.springframework.org/documentation.html
8. JBoss AOP REFERENCE.
Http://docs.jboss.org/aop/aspect-framework/reference/en/pdf/jbossaop_reference.pdf
