The J2EE platform provides a component-based approach to design, develop, assemble, and deploy an enterprise application. Moreover, a multi-layer distributed application model, the multiplexing of components, the uniform security model, and the flexible transaction control model. In recent years, it has been used in the enterprise system. With the large deployment of the J2EE application server, the number of customer visits is sluggish. Enterprises are increasingly high and higher in the scalability and high availability requirements of J2EE systems, especially in the field of e-commerce and financial fields. How to design and build a J2EE cluster application server with scalable, high availability, becoming a problem that the design J2EE application server design must consider. However, the J2EE application server cluster is based on the cluster of EJB components, and there is very different from ordinary web server cluster technology. The implementation method is also different.
1 Cluster system characteristics
A cluster system is a group of loosely combined server groups that form a virtual server that provides a unified service for client users. For this client, it is usually not realized when accessing a cluster system is provided by the specific server. The cluster system generally should be specially available for high availability, scalability, load balancing, fault recovery, and maintenanceability.
High availability is the most basic requirement of the cluster system, which is an evaluation of the operating stability of the entire system. Scalability refers to the ability of the entire system to continue to maintain a valid response time with the increase of the number of client users. In a scalability system, as the number of users increases, the effective response time is long, the linear change relationship, which also reflects the peak load processing capability of a system, but as more and more systems are in the Internet, The peak load of user access is valid to predict the variable impossible. The amount of user visits has solemn, so that the effective response time of the system is non-linear change, and the response time has grown sharply, knowing that the system is overwhelmed and stopped. The general solution is to boost the system hardware system or by adding the server. However, unreasonable increasing servers can only make the entire cluster system becomes increasing, and this complexity of the system means that the system failure rate is high, and the entire system reliability will be reduced.
Therefore, a system availability and scalability are a pair of contradictions, and there is a big relationship with the implementation methods of the entire cluster system.
2 EJB technology
EJB is the core of the J2EE application platform. Sun is defined in the EJB2.0 specification as follows: EJB is a component architecture for developing and deploying multi-layer structures, distributed, object-oriented Java applications across platforms. The EJB component has three types: session bean, entity bean, message driver bean. The session bean is divided into state and stateless.
The core of the EJB server is one or more EJB containers (Container) that provide EJB. EJB container manages the EJB it contains, providing an operating environment for the survival and execution of the EJB component, and is also responsible for EJB transaction management, security management, resource access control, and some exception handling. The EJB container does not allow J2EE's client program to directly access the EJB object in the container. When a client user wants to access an EJB, the EJB specification requires customers to use the Java Naming and Directory Interface API to locate bean HOME interface. To access EJB, it is generally necessary to pass through the following three steps (see Figure 1) (only listed below Remote):
1) Find the Home interface from JNDI. First of all, customers need to get a JNDI initialization context, then the customer can use the context's lookup method from one name to its HOME interface;
2) Use the CREATE () method in the home interface to get the Remote interface reference of the bean;
3) Use the method defined in the Remote Interface; a simple access example is as follows:
/ / Get JNDI initialization context
Context mycontext = new initialcontext ();
// Find my aejb and get a reference to the Home object
Object homef = mycontext.lookup ("myejb");
// Home object styling is RMI-IIOP object
MyBeanhome Home =
(MyBeanhome) PortableRemoteObject (Homef, MyBeanhome.class);
// Create an EJB object, return to the Remote interface
MyBeanRemote myref = home.create ();
// Call the method implemented in EJB through the Remote Interface
System.out.println (MyRef.getname ());
3 EJB server cluster
The cluster of the EJB server is a component-based clustering method, and there is very different from ordinary web server cluster technology. The method of implementation is also different. Also because there is no standards related to support clusters in the EJB specification, even if some vendors provide cluster features in the EJB server, how to implement clusters is also determined by vendors. The method of implementing is also different. Currently, most J2EE application servers provide clustering features such as the BEA WebLogic application server, open source JBoss application servers, and J2EE application servers provided by Sybase provide clustering. In the EJB server cluster design, load balance, EJB cluster, and HttpSession cluster technology are the main technologies involved in the design. The implementation of the EJB cluster is the core of the entire system.
3.1 Load Balance (Load Balance)
The main purpose of Load Balance is to disperse the load of the access system in different machines, enhance the entire system throughput and concurrency, which allows multiple servers to assume some heavy computing or I / O tasks to eliminate networks. Bottlenecks, improve the flexibility and reliability of the network. Common methods are as follows:
l cycle DNS
DNS load balancing is a simple and effective method that uses a simple domain name query IP address to implement a simple load balancing. Any address is given, and the DNS server has an IP address pool corresponding to. Returns the next address in the IP address pool each time you request to convert a domain name into an IP address. Therefore, it is called DNS Round-Robin. When a client access, send a DNS name to the URL of the request JNDI, as the URL of the naming server, each DNS name is converted into a different address, using this technology, each client initailContext request is sent directly Go to different servers. A large disadvantage of load balancing is: Once a server fails, even if the DNS settings are modified in time, it is necessary to wait enough time (because DNS needs a certain refresh time) to play, during which time, some client users are accessible Still send a fault server.
l Software Proxy
Software Proxy maintenance is connected to open connections on a series of servers. When a Client access server, first go through this software agent, this agent can realligate a user's access to a server through some load balancing algorithms (such as using similar DNS ROBIN, random methods, access algorithms). This software agent method can promptly discover the server crash or no response, effectively avoiding trouble access in the DNS Round-Robin method.
l Hardware equalizer
Such hardware equalizers generally use address conversion technology to map an external IP address into multiple internal IP addresses, and dynamically use one of the internal addresses for each TCP connection request to achieve load balancing. It is generally possible to use a switch of the fourth layer (or 4 or more), which is a swap that performs a virtual connection in accordance with the IP address and the TCP port, directly transmitting the packet to the respective port of the destination computer. The initial connection request from the outside can be associated with the internal plurality of addresses, respectively, to establish a virtual connection to implement load balancing. This fourth layer is exchanged based on hardware chips, so network transmission speed and exchange speed far exceeds a normal software agent. Hardware balance can be achieved if Cisco CSS 11150 (a L4 Switch) is used.
3.2 EJB cluster technology
Client End To access EJB container EJB is first to access JNDI Naming Server [See 2 EJB Technology]. So J2EE's EJB server's implementation cluster core is also surrounded by JNDI. According to the cluster, the JNDI name tree is different in the system, and the general EJB cluster can be divided into three types:
1) JNDI Tree Agent (PROXY)
Each J2EE Application Server in the Cluster maintains your own local private JNDI tree. Each server in the Cluster does not know the status and existence of other servers. Only the Proxy service knows the status of each server in the Cluster, and can access the Cluster. The JNDI tree on any server, which requires each server to keep in touch with the Proxy service after startup and start, so that proxy knows their work and all EJB objects of Cluster. Client Accesses the EJB object, first access JNDI Proxy, with PROXY, you can reallite all EJB objects in the Cluster (see Figure 2). The advantage of this approach is that it is simple, and only one JNDI Proxy agent is designed. For each application server does not do complex requirements; and the system's scalability is good, to upgrade the system, just simply adding the server. But this method has a fatal disadvantage that the Proxy service failed, the entire Cluster system will not work properly, and the reliability is poor.
2) Centralized JNDI tree
When using a centralized cluster, there is only one main name server in the entire cluster system. It is responsible for managing and maintaining a global, concentrated JNDI tree in the cluster. All EJB servers in the cluster are tied to the object to be released. Set on this named server, each EJB server does not need to maintain your own private JNDI tree, which is maintained by this primary naming server. If an EJB in the cluster is to be deployed on multiple servers, each server can bind the same HOME object to the naming server, when a customer requests access to this EJB home object from the naming server, you can put all your Home Object references are returned to the client, or you can return a server's Home object reference (see Figure 3) by one equalization algorithm. Such a centralized method should improve the entire system reliability, and must consider the backup problem of the naming server. It is often used in large systems to use multiple naming servers at the same time, and the naming server can use JNDI tree represence mode, or use the EJB server on multiple servers. Binding method. For example, Sybase's EJB application server uses this way, which uses JNDI trees in all application servers in Corba CoS Naming Service. This centralized design model is used, and the system is simple, but it also brings the deficiencies inherent in the system. First, when the naming server backup problem is taken into account, the naming server is getting more and more prominent as the cluster system is getting bigger and larger. 3) Distributed JNDI tree
In this model, each application server in Cluster has its own named server, named server not only maintains private local JNDI trees, but also maintains a global shared JNDI tree. The local JNDI tree is only bound to objects deployed in the local application server, and the global JNDI tree saves local JNDi tree copies on other application servers in the Cluster. This way to access any named server, to locate the EJB object across the system through its local private and global shared JNDI trees. It is generally used in the form of multicast. When a application server in the Cluster starts, add this Cluster multicast group, and then use IP multicast technology to copy its local JNDI tree to other servers in other servers in other servers in the Cluster, so Other servers in Cluster have a copy of its JNDI tree. At the same time, this application server and other servers have always maintained HeartBeats to detect the activity status of other servers at any time. If there is a server crash, this application server is to share from its global sharing. The JNDI tree deletes this exception server JNDI copy, and other active servers must do a similar operation. The biggest advantage of this distributed model system is to have strong scalability, add one server to the system, and other servers can do not change any changes. And the entire system adopts the distributed system availability, and any server crash in the system will not affect the normal operation of the entire system. This method is also a designed method currently using the most designed method. This design method is adopted by the BEA WebLogic Application Server and JBoss Application Server.
3.3 httpsession cluster
The session object is often used in J2EE's Web Programs JSP / Servlet, and its main function is to record information about access to the client session. In a general Web system, in the client access phase, the relevant information reserved in the session in the session in the server is assumed in the system access phase. User next access, you need to restart the establishment of a new session. The purpose of HttpSession Cluster is even if the server-side system crash is restarted, the last until the session in the last visit is still saved in the system, and the Client can then complete the last unfinished access.
In some large systems, at the same time, thousands of users are also accessed simultaneously, and they must save all Client's session information, and to ensure that once the system is invalid, the system will reload their own session status, users can continue to operate . The general implementation of the HTTPSession Cluster has the following two methods: 1) Adoption of memory replication:
In this method, when a HTTPSESSION an Object in a J2EE Server is modified, or after adding an Object, this Server can use some kind of communication method to transfer this object to others. Back up J2EE Server, let other J2EE Server simultaneously change.
2) Centralized:
The so-called centralized processing is very similar to the above memory replication method. Different are in centralized, the Object in the session is not sent to other Server, but is sent to a specific machine, in this machine The information in Object can be saved after the file is used, or after abstracting data, saves to the relational database. This machine centrally manages all Session status and information in all Clusters.
4 conclusion
This article analyzes the implementation of the JNDI tree for the cluster system, in practice in the actual design, it should also specifically consider the differences between the two session beans, entity beans and messages to the cluster method and their fault recovery. technology.
references:
