Analysis of Java EE architecture

The Java EE architecture is one of the current mainstream architectures, and most enterprises adopt the structure design and solution of Java EE technology at present. The Java EE architecture provides a middle-tier integration framework to meet the needs of applications that require high availability, reliability, and scalability without much cost. By providing a unified development platform, Java EE lowers the cost and complexity of developing multi-tier applications, provides strong support for existing application integration, fully supports Enterprise JavaBeans, has good wizards to support packaging and deployment applications, adds directory support, and enhances security. Improved performance.

Efficient development: Java EE allows the company to give some common, cumbersome service-side tasks to the middleware vendor to complete. This allows developers to focus on how to create business logic and shorten development time accordingly. The advanced middleware vendors provide the following complex middleware services:

State Management Services--lets developers write less code, not care about how to manage state, so that program development can be completed faster.

Continuous services--developers can write applications without encoding data access logic, and build more lightweight, database-agnostic applications that are easier to develop and maintain.

Distributed shared data Object Cache service-enables developers to build high-performance systems that greatly increase the scalability of the overall deployment.

Support for heterogeneous environments: Java EE can develop portable programs that are deployed in heterogeneous environments. Java-based applications do not rely on any particular operating system, middleware, hardware. Therefore, a reasonable design based on Java program can be deployed to various platforms only once. This is critical in a typical heterogeneous enterprise computing environment. The Java EE Standard also allows customers to order off-the-shelf components from Java EE-compliant third parties, deploying them into heterogeneous environments, saving the cost of developing the entire solution for themselves.

Scalability: The enterprise must choose a server-side platform that provides excellent scalability to meet the large number of new customers who operate on their systems. Java EE platform based applications can be deployed on a variety of operating systems. For example, it can be deployed to high-end UNIX and mainframe systems, which can support 64 to 256 processors at a single computer. The suppliers in the Java EE field provide a broader load balancing strategy. Can eliminate the bottleneck in the system, allow multiple servers integrated deployment. This deployment is up to thousands of processors and enables a highly scalable system to meet the needs of future business applications.

Java EE uses a multi-tier distributed application model, the application logic is divided into components by function, each application component is distributed on different machines according to their layer. The traditional Java-EE multilevel enterprise Application model divides the different layers in the two-layered model into many tiers. A multi-tier application can provide a separate layer for each service, the following is a typical four-layer structure of Java EE:

Client layer components running on the client machine

Web-tier components running on the Java EE server

The business logic layer component running on the Java EE server

Enterprise Information System (Enterprise information System) layer software running on an EIS server

It is generally believed that the Java-EE platform is widely considered to be the architecture, the EJB container running on the Java server can be considered the core of this structure, the EJB container manages the execution of all EJBS, and the lifecycle of the EJB, and provides all system-level services to the EJB. The EJB component is responsible for accepting, processing the Web container's customer requests and connections to provide the data that the entire enterprise uses, the EIS layer of the service.

In this classic schema, all data accesses are passed through the entity bean, and the business object is a stateless session bean with a remote interface running in the EJB container. The EJB contains a variety of services, such as declarative transaction management, and provides a shared middle tier that supports various types of Java EE clients. However, the application performance and development overhead of the structure is heavy, some of the load is in EJB, and it is related to the characteristics of the distributed architecture. Furthermore, in order to distribute, the OO principle is sacrificed and difficult to test because business logic is often written in the EJB implementation classes, which are entirely dependent on the EJB container.

An improvement of this "classic" architecture is to replace the remote EJB with the local EJB, and realize the reuse of the architecture, and solve the problems of distribution. But the architecture is still quite complex. Many of the burdens of EJB still exist, and the benefits from EJB are few.

Therefore, with the continuous complexity of enterprise application development, the requirements of architectural design will also put forward new requirements:

The architecture is simple but powerful.

Schemas can be scaled horizontally by configuring the Web container cluster.

High portability between different application servers.

Facilitates unit testing of business objects outside the application server, and some integration tests can even be done with some lightweight containers such as JUnit.

In order to solve a series of problems caused by EJB in classical architecture and satisfy the development of enterprise application, a "lightweight container" of non EJB architecture is proposed. Lightweight containers and EJB schemas are container-managed business service objects, and then organize the entire architecture around the service layer. But instead of running in the EJB container, the business object runs in a lightweight container. Lightweight containers are not bound to Java EE, so it can run either in a Web container or in a standard application, and can run in an EJB container if necessary. This container is also not bound to the Servlet API? D? D This is different from the web framework of the MVC architecture. Lightweight containers start at a very low cost and require no EJB deployment.

Lightweight containers provide a way to manage and locate business objects. There is no need for additional assistance such as Jndi addressing, custom servers, and lightweight containers that provide registration services for application objects. Compared to EJB containers, it is not only powerful, but also avoids the container forcing business objects to adopt specific interfaces, minimizing intrusion and achieving excellent architectural reuse.

All Java classes in a lightweight container run in the same virtual machine.

The web layer is provided by the MVC framework (the MVC structure of struts or webwork, or the spring architecture)

The business object is Pojo, running in a lightweight container. AOP blocking mechanisms enable business objects to be enhanced to achieve enterprise-class services. Unlike the EJB container, business objects do not depend on the container's APIs, so they can be used outside the container, which is more conducive to unit testing. Business objects are accessed only through interfaces, and business objects do not need to be modified after changing the implementation classes of specific business objects. The interface-oriented programming is implemented.

The data access mechanism can be accessed through lightweight O/R Mapping, which provides a transparent persistence that implements a lightweight package of JDBC data access methods.