AOP! = Interception)

 

Recently, a bunch of authors have been talking about AOP (Aspect-Oriented Programming) And how AOP is like Nb. However, most of them talk about an original pattern called interception ). They are neither stupid nor misled. Interception is an Nb-effective mechanism, but it is different from AOP. They do have many common features, but understanding AOP as an interceptor is like understanding object-oriented as a combination of a bunch of data structures and a bunch of function pointers. Just like the idea that we don't play with objects as a set of data and code, we can't understand what object-oriented means. If we really need to understand the potential of AOP, we must go beyond the idea that "AOP and interceptor are a sub-task. They obviously have something in common, but they are not the same thing.

 

Definition 

 

First of all, because 90% of the arguments come from semantic differences, we define them first.

 

AOP:

 

AOP software development is a new separation of concerns (SOC) technology. AOSD technology makes it possible to modularize each aspect of the system. -- AOSD Homepage

The central idea of AOP is that, although the modularized mechanism supported by oo semantics is very useful, its mechanism limitations still cannot meet the requirement that all the concerns throughout the complex system are modularized. We believe that in any large and complex system, these concerns that cannot meet modularization need to be further modularized.

AOP's implementation of crosscutting concern is like the language support that OOP has implemented for object encapsulation or inheritance-it provides a language mechanism to completely obtain various slices in the structure (crosscutting ). This makes modularization of various concerns throughout the system possible, and achieves the advantage of Modularization in general: simpler and easier to develop and maintain code, better reusability. We call this "well-modularized focus throughout the system" an aspect (aspect, a In AOP ).

 

Interceptor (Interception)

 

"The interceptor architecture mode allows you to add services to the Framework virtually and automatically call a specific event when it is triggered ." -- Patterns of software architecture, Vol 2 by Schmidt et. al, p. 109

 

At first glance, they are surprisingly similar-the interceptor is triggered at a specific execution point, providing additional functionality for the object method it hosts. In the form of AOP, the Code is also "Woven" into the declared starting point to provide additional behavior before and after the object method it cut in. However, just like many things, the difference is always beyond the details and superficial phenomena. As part of this discussion, it is necessary to declare the definition of some terms so that we can really see why their overlapping areas are so large:

 

Separation of concerns (Separation of concerns,SOC):A focus mainly refers to a relatively independent thing that we want to modularize. For example, in an accounting system, property considerations are a concern. Then we want to capture all things related to property in an object. In this way, we can capture some abstract concepts in the system, so as to enhance the maintainability and functionality of the system over time. Although these abstract concepts are hard to define and distributed in every corner of the system, various languages still use capturing them more or less as one of their main goals.

 

Concern (Cross-cutting concern):The text state of aspectj is a concern. It cannot be used as a first-class cosntruct in a general oo semantic system) captured. For example, you can trace the entry and return of a method. In general, this is something that can only be done by each object, just like:

If (debugging. isenabled ())

Debugging. Trace ("method Foo () entered ");

 

//...

 

If (debugging. isenabled ())

Debugging. Trace ("method Foo () Exiting ");

As we can imagine, this is not something that can be easily implemented by inheriting the base class or by using an internal reference with other classes (an OO system solves the normative path of separation of focus is inheritance and combination ). All the methods that need to be tracked by the above Code need to copy and paste the four lines of code. In addition, the more complex aspect concerns are generally more apparent in enterprise-level systems, and such systems generally include persistence (storing objects that have long existed in the system on the physical carrier ), synchronization (how does my object work normally in multi-thread concurrent access) and remote (how does my object support access across process boundaries ). These cannot be completely captured by a traditional object-oriented environment.

 

Interceptor andAOP

 

In the past, I have always referenced A Piece Of saying about the interceptor in posa2 (pattern-oriented-software-architecture 2) as its standard definition, which says: "framework development can be extended by the invisible." The solution is as follows:

By using a pre-defined interface and registering as an out-of-the-box service in the Framework, the application is allowed to be extended, and then the framework automatically triggers these services through specific events. (Here, "Event" refers to an application-level event that sends a request or response in an object request proxy (ORB) framework, these events are generally within the framework .) In addition, opening up the implementation of the framework helps "non-compilation" services to access and control specific aspects of framework behavior.

On the other hand, the interceptor implies some things as the basis:

1.The system provides support for the interceptor.Posa2 is called the framework, COM + ,. net, Servlets, and EJB provide support for Interceptor at the container boundary, these underlying mechanisms that support interceptor behavior are similar-a xx structure is located in a XX place (I always call them "sewers"), which integrates the interceptor with conventional processes. This means that only "first-class citizens" with toilets in their homes are eligible to use interceptors-they cannot intercept anything without a restroom. For example, in the servlet framework (Versions later than 2.3), the filter is used to implement the interceptor mechanism, which provides programmers with interception of JSP pages (or any URL or something similar). Although the interceptor can process URL requests or responses here, the filter cannot intercept a common Java object call, or remote calls such as RMI through other channels.

2.Support for Request Response semantics.The interceptor implies a dependency on the Request Response semantics. Therefore, the interceptor is usually triggered at the start or end of the method. This means that a large part of object interaction semantics is ignored and cannot be supported. (If this is abstract, we will explain it again later .)

3.The Interceptor is a runtime structure in general.Posa2 explicitly mentions this fact that these services do not need to be called in all circumstances, so the services provided by the interceptor cannot be statically integrated into the system-they need to be registered at runtime. Unfortunately, this increases a certain amount of runtime overhead, especially when the interception event model of the interceptor has a large granularity. For example, in the. NET context architecture, calls to all object methods in the context can be intercepted through the imessagesink architecture. Once the interceptor is registered in such an environment, the context interceptor is triggered for every method call in the context. We cannot implement interceptors that are only available for a certain type of method.

 

 

On the other hand, it seems that the current assumption is that the interceptor is a mechanism that only supports remote interaction and takes effect only when operations cross process boundaries. This assumption is obviously not true. For example, Java provides a general interceptor architecture through the dynamic proxy API, and provides a mechanism for Java programmers to create an interceptor on classes that inherit interfaces. (Dynamic proxy implements the interceptor by implementing a layer between the caller and the implementation based on the original implementation. At the same time, the caller only accesses the called interface, I don't know whether the original implementation or something is actually called .)

 

Now let's talk about AOP, which is based on two basic structures: Join points and advice ). The access point is often interpreted as a code module in the AOP system being "woven" into the specific point of the original code. The suggestion is the specific code module to be woven. Whether an AOP system is rich depends on whether it supports a strong Access Point model. For example, aspectj defines a rich set of access point models, including capturing dictionary value assignment processes, capturing method call responses, and capturing method execution responses. What is the difference between method call and method execution? You know...

This means:

1. AOPThe system does not need "underground pipelines ".This is indeed a bit controversial, because there is indeed something that needs to be woven into the access point throughout the software execution process. However, in general, this should not be an operation executed at runtime, but should be executed at compilation or loading. For example, aspectj is a compiler that completes all the "knitting" operations at compilation.

2. AOPThe system can "Weave" everything in the system ".The AOP system is limited to its Access Point model. For example, aspectj can define an object-related persistence strategy based on a JavaBean. When a field is accessed, the latest field value in the database is synchronized to this field, and the value in the database is updated when the field value changes. Although the efficiency of this policy is quite low (Database interaction is too frequent )... However, this policy can be attached to any JavaBean, Servlet, swing control, or j2_object. This is where the mechanism is Nb.

 

Here is an example where AOP can handle but other interceptor mechanisms cannot. I know that there is a very practical problem called SQL injection attacks? I really don't know ....)

Well, I kindly explain to my children's shoes who do not know the attack method. The typical column is like this: we implement a login web interface in two steps:

 

1. A form with the user name, password, and submit button is displayed. When the user clicks submit, the form is submitted to servlet or httphandler.

2. in the server code, spell SQL "select * from users where username = '" + form. getparameter ("username") + "'and Password ='" + form. getparameter ("password") + "'" run it. Then we get a result. Next we will understand the result...

 

The key issue is that if a grandson fills in something like this in the username field "bob' -- ignore the rest of this line", what will happen? The combined SQL statement becomes like this:

 

Select *

From Users

Where username = 'bob' -- ignore the rest of this line and Password =''

 

If some children's shoes are DBAs, they will tell us that the dual horizontal bar is a valid character in the SQL statement, and the subsequent statements will be commented out. We allowed Bob to log on without checking his password. Well, if this grandson passes in "Bob '; drop table users --", oh yeah. Note: you are fond of SQL spelling. You can use parameters to solve this problem in the future)

 

Obviously, we cannot simply write a base class or util class for developers to call this method to solve this problem, this method is used to pass parameters into the SQL statement (JDBC and. net ADO.. net. The problem lies in the developer's carelessness when writing this part of the Code, or the reason why he is uncomfortable with the website of his own company.

 

Obviously, this is not a problem that the interceptor can solve, because it is not a problem that can be solved in the Request Response Mode-the execution of SQL statements may not always be captured when a method is called and returned, it may be part of a large piece of code (such as a query operation. This is not a problem that occurs only when you log on, but it is necessary to prevent such a problem in any place with user input. Therefore, every insert, update or delete are vulnerabilities in our system .) However, in the AOP system, we can use the rich Access Point model provided by it to capture every JDBC connection. createstatement () method to add statements to throw a runtime exception for this problem. Then we solved this problem very brilliantly (WES Isberg of aspectj Team described more methods to solve this problem using AOP)

 

On the other hand, we have discussed domain-independent, such as persistence, call tracking, security authentication, and so on. Although there are so many specific fields that run through our system, we can find some examples: aspectj team encountered such a problem when providing support for a graphic display system, they need to track the movement of all display objects to force the interface to refresh when the object moves to a new carrier. This is obviously a problem in a specific field that is not independent. It is necessary to trigger interface refresh when capturing the points of attention throughout the system. This is another requirement that is not easily captured by an interceptor-based system.

 

Conclusion

 

Of course, the boundary between AOP and interceptor is indeed vague. For example, John Lam's claw implements adding necessary aspect modules to. Net SCE (public language) during compilation. This is regarded as an AOP or interceptor. Indeed, there is a conflict. This is something between the two. It has its advantages in loading during compilation, but it is also limited to the Methods explicitly named at the access point, this reduces the flexibility of a large part of access points (and only captures inbound and return methods .)

 

It can be clearly stated that it is possible to build an AOP system with an interceptor as the underlying mechanism-EJB, Servlets, Asp.. net, MTS/COM +, and. the. NET Context Model verifies this. JBoss EJB is a model in this regard. It proves that a well-designed Interceptor-based structure plays a huge role in complex systems.

 

In general, the interceptor provides a simple access point mechanism for capturing incoming and return methods, and a dynamic "Weaving" mechanism during runtime, so the interceptor can be regarded as a prototype of AOP (just like VB is the prototype of OOP ). Of course, understanding the interceptor is a huge step in our understanding of AOP. Even in some systems, using AOP is like a cool tool. It is better to use the Interceptor to solve the problem and convenience. But do not think that the interceptor is over. The Interceptor is suitable for processing boundary-specific behavior on the component boundary, and AOP is more suitable for handling specific problems within the boundary.

 

Note:

 

In fact, there is no need to argue who is comparing the interceptor with AOP. For the interceptor, a large part of the enterprise-level applications we are concerned with can be further modularized through the interceptor. For AOP: although it supports more powerful processing mechanisms. the net world does not seem to have a very well-formed solution, so we can only wait for Microsoft. Who made us eat soft meals.

Through this article, we are more clear about their respective meanings, so that they are in different stages and what path we will follow after object-oriented development.

In this way, we will not be confused by some hot concepts, even though this was a concept N years ago.

 

Just mark the source and the author for the reposted content. The concepts and articles n years ago are free.