Why do we need to distinguish J2EE containers from J2EE application systems?
We know that a J2EE application system can run only when deployed in a J2EE container. Why is it divided into a J2EE container and a J2EE application system? By operating the J2EE containerLine MachineFrom the analysis, we can find that the J2EE container actually separates some common functions of the general application system, such as the transaction mechanism, the security mechanism, and the performance optimization mechanism such as the object pool or thread pool.
These functional mechanisms are almost required by every application system. Therefore, they can be separated from a specific application system to form a general framework platform, the Design and Development of these functional mechanisms are difficult, and the stability and speed of running at the same time are very important. It must be developed after a long time of debugging and Operation Experience. Therefore, A dedicated J2EE container server product is formed, such as Tomcat JBoss, websphere, and weblogic.
The J2EE system is divided into J2EE containers and J2EE application systems. We have seen a method of decentralization (separation of concerns ).
Distribute attention
The common requirement function is separated from no related classes. At the same time, many classes share an action. Once the behavior changes, you do not have to modify many classes. You only need to modify this behavior.
AOP is a programming method that implements decentralized attention. It encapsulates "Focus" in "aspect.
What is AOP?
AOP is a continuation of OOP, short for Aspect Oriented Programming, meaningAspect-Oriented Programming. AOP is actually a continuation of the gof design model. The design model tirelessly pursues decoupling between callers and callers. AOP can be said to be an implementation of this goal.
For example, assume that in an application system, a shared data must be accessed concurrently. First, encapsulate the data in a data object called data class, there will be multiple Metadata classes dedicated for accessing the same data object at the same time.
To achieve the preceding concurrent access to the same resource, the lock concept must be introduced. That is to say, when a metadata class accesses this data object at a certain time point, the data object must be locked, immediately after useUnlockUnlocked.
Using traditional programming habits, we will createAbstract classAll the parent classes inherit this abstract parent class, as shown below:
Abstract class worker { Abstract void locked (); Abstract void accessdataobject (); Abstract void unlocked (); } |
Disadvantages:
The accessdataobject () method requires a "Lock" status or something like that.Code. Java only provides single inheritance. Therefore, a specific worker class can only inherit this parent class. If a worker class also inherits other parent classes, for example, another worker parent class, it cannot be conveniently implemented. Reuse is compromised. Because the specific classification class also contains Code related to the "Lock" status, it can only be reused when there is a "Lock". The Reuse scope is very narrow.
The "Lock" of this application has the following features:
The "Lock" function is not the primary or primary function of a specific category. The primary function of the category is to access data objects, such as reading or changing data.
The "Lock" behavior can be separated from the main functions of a specific category.
The "Lock" function is actually a vertical aspect of the system and involves many classes and methods. For example:
Therefore, a newProgramThe structure should focus on the vertical aspect of the system. For example, the "Lock" function of this application. The new program structure is aspect (aspect) in this application, the "Lock" aspect (aspect) you should have the following responsibilities:
Provides some essential functions to implementLockOr unlock the function. To ensure that all the operations on the data object can be called to lock (), after it is used, call unlock () to unlock.
Is AOP necessary?
Of course, the above application examples have also been solved without using AOP. For example, JBoss 3. xxx also provides the above application functions, but does not use AOP.
However, using AOP allows us to understand software systems from a higher abstract concept. AOP may provide a valuable tool. This can be said: Because the AOP structure is used, the source code of JBoss 4.0 is much easier to understand than JBoss 3.x, which is very important for a large complex system.
From another aspect, it seems that not all people need to care about AOP. It may be an architectural design option. If you choose a J2EE system, the above general aspects of AOP have been implemented by J2EE containers. J2EE application system developers may need to pay more attention to the aspect of industrial applications.
Specific implementation of AOP
AOP is a concept that does not set the implementation of a specific language. It can overcome the disadvantages of a single inheritance feature language (such as Java). Currently, the specific implementation of AOP has the following items:
Aspectj (TM): it was created in Xerox PARC. It has a history of nearly ten years and has mature technology.
Disadvantages: Too complicated; destroys encapsulation; Special Java compiler is required.
Dynamic AOP: Uses JDK's dynamic proxy API or bytecode processing technology.
Specific projects based on dynamic proxy APIs include:
JBoss 4.0 JBoss 4.0 Server
Bytecode-based projects include:
Aspectwerkz
Spring