Why to differentiate Java-ee containers and Java EE application system?
We know that the Java EE Application system can only be deployed in the Java container to run, then why is divided into Java-ee container and Java application system? Through the analysis of the operation mechanism of Java-EE container, we can find that: in fact, the Java container has separated some common functions of general application system, such as transaction mechanism, security mechanism, object pool or thread pool and other performance optimization mechanisms.
These functional mechanisms are almost always required by every application system, therefore, it can be separated from the specific application system to form a common framework platform, and, the design and development of these functional mechanisms have a certain degree of difficulty, while the stability and speed of the operation are very important, must undergo a long time debugging and operation experience accumulated, therefore, The formation of a dedicated Java container server products, such as Tomcat JBoss, Websphere, WebLogic and so on.
From the Java EE system divided into Java-ee container and Java application System Two aspects, we have seen a distraction of the idea (separation of concerns).
Distract attention
The common requirements function is not separated from the related classes, and can make many classes share a behavior, once the behavior changes, do not need to modify many classes, as long as the modification of this behavior can be.
AOP is this way of implementing decentralized attention, which encapsulates "concerns" in "aspects."
What is AOP?
AOP is a continuation of OOP, an abbreviation for aspect oriented programming, meaning aspect-oriented programming. AOP is actually a continuation of the GOF design pattern, and the design pattern tirelessly pursues the decoupling between the caller and the callee, which can be said to be an implementation of this goal.
For example: Suppose that in an application system, there is a shared data must be concurrent access, first of all, the data encapsulated in the data object, called Data class, and there will be more than one access class, dedicated to the same time access to the same data object.
In order to achieve the above concurrent access to the same resources, the concept of locking lock needs to be introduced, that is, at some point, when an access class accesses the data object, the data object must be locked and locked, and then the unlocked is unlocked immediately after use, which is then accessed by other access classes.
With traditional programming habits, we create an abstract class, and all the access classes inherit this abstract parent class, as follows:
Abstract class worker{
abstract void locked ();
abstract void Accessdataobject ();
abstract void unlocked ();
}
Disadvantages:
The Accessdataobject () method requires related code such as "Lock" status. Java only provides a single inheritance, so the specific access class can only inherit this parent class, if the specific access class also inherits other parent classes, such as another worker's parent class, will not be easy to implement. Reuse is discounted, the specific access class because it also contains the "lock" status and other related code, can only be reused in the relevant "lock" occasions, the scope of reuse is very narrow.
A careful look at the "lock" of this application actually has the following characteristics:
The lock feature is not the primary or primary feature of a specific access class, and the primary function of the access class is to access data objects, such as reading data or changing actions.
The "lock" behavior is actually the main function of the specific access classes can be independent and separate.
The "lock" function is actually a longitudinal section of the system, involving many classes, many classes of methods.
Therefore, a new program structure should be concerned with the vertical section of the system, such as the "lock" function of the application, the new program structure is aspect (aspect) in this application, the "lock" aspect (aspect) should have the following responsibilities:
Provides some necessary functionality to lock or unlock the object being accessed. To ensure that lock () locking is invoked before the operation of the data object is modified, and the unlock () unlock is invoked after it has been used.
AOP Application Scope
It is clear that AOP is well suited to developing Java-EE container servers, and currently JBoss 4.0 is being developed using an AOP framework. The specific functions are as follows:
Authentication Permissions
Caching Cache
Context Passing content delivery
Error handling Fault Handling
Lazy Loading Lazy load
Debugging debugging
Logging, tracing, profiling and monitoring
Record Tracking Optimization Calibration
Performance Optimization Performance optimization
Persistence persistence
Resource Pooling resource Pool
Synchronization Sync
Transactions Affairs
is AOP necessary?
Of course, the above application paradigm is also resolved without AOP, for example, the JBoss 3.XXX provides the above application functionality, but it does not use AOP.
However, using AOP allows us to understand software systems from a higher abstract concept, and AOP may provide a valuable tool. It can be said that because of the AOP architecture, JBoss 4.0 's source code is much easier to understand than JBoss 3.X, which is very important for a large and complex system.
On the other hand, it seems that not all people need to care about AOP, it may be a choice of architecture design, if you choose the Java-EE system, AOP attention to the above common aspects have been implemented by the Java EE container, Java EE application System developers may need to focus more attention on industry applications aspect.
AOP Concrete Implementation
AOP is a concept that does not set the implementation of a specific language, it can overcome the shortcomings of the single inheritance language (such as Java), the current AOP specific implementation of the following several projects:
AspectJ (TM): Created in Xerox PARC. Has nearly 10 years of history, technology maturity.
Disadvantages: Overly complex, damaging encapsulation, requiring specialized Java compilers.
Dynamic AOP: Using the JDK's dynamic proxy API or bytecode bytecode processing technology.
Specific projects based on the dynamic proxy API are:
JBoss 4.0 JBoss 4.0 Server
Nanning
The items based on bytecode are:
Aspectwerkz
Spring