EJB Based on J2EE,

EJB Based on J2EE,

EJB Based on J2EE

1,What is EJB?

Enterprise Java Beans (EJB) is a commercial application component technology in JavaEE and one of the three major components of JavaEE (Servlet, JSP, EJB. EJB provides a framework for clients to use remote distributed objects, greatly simplifying the development of enterprise-level applications with good scalability. The EJB component structure is a distributed computing structure based on components and a component in a distributed application system.

EJB is the specification of the Java Server service framework and defines a technical specification for the server component system. This specification provides a standard, distributed, and object-oriented architecture. It shields component developers and users from the implementation of complex system-level underlying functions, allowing developers to focus on the implementation of business logic. Some of the complex underlying services are the responsibility of EJB containers. EJB can be expanded based on the growth of applications. The EJB server provides the load balancing function and resource access control.

2,Communication between EJB containers and components

The EJB container provides a runtime environment for the EJB component. The EJB container manages the EJB in a similar way as the Web Container manages the Servlet, And the EJB must run in the EJB container. The EJB container manages the persistence, lifecycle management, security management, transaction management, remote connection, concurrent processing, clusters, and load balancing of ejbs. The container manages the instances of the EJB component to maximize the efficiency and memory utilization of the EJB component. Containers can activate and deactivate EJB components and manage instance pools. The container is responsible for managing the complex problems of Distributed Transaction processing. It manages low-layer communication issues for remote connections, and hides communication problems for developers and customers of EJB components. Therefore, EJB component developers can focus on encapsulating business logic, and containers are responsible for processing all other transactions. EJB interacts with containers through ejbContent, JNDJ, callback functions, and other mechanisms.

JBoss is a container and server for managing ejbs. It supports EJB1.1, EJB2.0, and EJB3 specifications. It is generally used together with Tomcat or Jetty.

See Figure 1 (Working Principle of the EJB container ):

Figure 1: How EJB containers work

An EJB component is a distributed object that can communicate with applications in other address spaces after being instantiated. The EJB instance is encapsulated in the framework (skeleton) object, which communicates with the client through the stub object. Stubs do not include business logic, but implement commercial interfaces. Whenever the commercial method on the commercial interface of the stub is called, the stub sends the network message to the framework to tell it which method is called. The Framework calls the corresponding method of the EJB instance, and sends the results returned by the EJB instance to the stub, which then returns the results to the corresponding application. Through the two intermediate objects of the stub and framework, the complex communication process between distributed objects is shielded. The framework is implemented by containers, and the stubs are automatically generated by development tools. No code is required for both frameworks. See figure 2 (Communication schematic of the EJB component) below ):

Figure 2: communication principle between EJB components

 

3,EJB Classification

The EJB component can be divided into two types: Session Bean and message-driven Bean. The Session Bean encapsulates the business logic. The client can call the Session Bean method locally, remotely, and Web services to access the application deployed on the server and call other Bean methods, session Bean is not persistent, that is, its data is not stored in the database. The Session Bean includes three types: stateful Session Bean, stateless session Bean, and single-piece Session Bean. Message-driven Bean is usually used as a listener for specific types of messages, so that JavaEE can process asynchronous messages, and the client does not access the message-driven Bean through interfaces.

The following describes the stateful Session Bean, stateless Session Bean, single-piece session Bean, and message-driven Session Bean in sequence.

 

4,Stateless Session Bean

The stateless Session Bean only provides business logic for the client and does not retain the session status for the client. When the client calls a stateless Session Bean method, the properties of the corresponding session Bean will describe the call status, but only remain in this status during this method call. When the method call ends, the status is cleared.

The lifecycle of the stateless Session Bean is controlled by the container. When the EJB container receives a request from the client for a stateless Session Bean, if the EJB does not exist, the container creates an instance of the Bean and injects the required resources into the component, then the container calls back the PostConstruct method and the component is created. In this case, the Bean is switched from the "not exist" status to the "exist" status. After the client call ends, the container calls back the PreDestroy method and the Bean is destroyed. At this time, the Bean is changed from the "existing" status to the "nonexistent" status. See Figure 3 (the lifecycle of the stateless session Bean ):

 Figure 3: lifecycle of a stateless Session Bean

 

5,Stateful Session Bean

The stateful Session Bean retains the session state for the user. It cannot be put into the component pool as the stateless Session Bean for sharing by different users. For stateful session beans, as long as a client sends a request, the container creates an instance that corresponds to the client, and a client corresponds to an instance. During the lifetime, the stateful Session Bean maintains the user information. Once the session ends, the lifecycle of the stateful Session Bean ends.

Stateful session beans have three activity states: nonexistent, active, and passive. After a stateful Session Bean is active for a period of time, if you still do not receive requests from an external client, in order to save system resources, the container will serialize the status information in the stateful Session Bean to the temporary bucket and remove the stateful Session Bean from the memory. This process is called "passivation ". The container calls back the PrePassivate method before passivation. When the container receives a request for a stateful session Bean that has been deactivated, it reinitializes the instance of the stateful Session Bean and retrieves the status information from the temporary space so that it returns to the active status, this process is called "activation ". After activation, the container calls back the ProActivate method. After a stateful Session Bean is deactivated for a period of time, the container will completely clear the instance and call back the PreDestroy method. See Figure 4 (lifecycle of a stateful session Bean ):

  

Figure 4: lifecycle of a stateful Session Bean

 

6,Single-room Session Bean

A single-piece Session Bean is instantiated once for each application and remains in the life cycle of the application. A single-piece Session Bean is designed for a specific scenario. The client can access this unique EJB instance in a shared and concurrent mode.

The single-piece Session Bean is similar to the stateless Session Bean. The difference is that the single-piece Session Bean has only one instance in the application, while the stateless session Bean can have many instances, each instance is placed in a component pool for sharing.

A single-piece Session Bean is never inactive like a stateless Session Bean. Its life cycle only contains two types of bodies: "Not Exist" and "exist ". See Figure 5 (the life cycle of a single-piece session Bean) below ):

 

Figure 5: life cycle of a single-piece Session Bean

 

7,Message-driven Bean

Message-driven Bean is a component specially designed to process message requests. Message-driven Bean integrates Java Message Service (JMS) and enterprise Bean functions. The client cannot directly obtain its reference and call the method. It can only start with system messages.

An EJB container usually creates a message-driven Bean component pool. Like a stateless Session Bean, a message-driven Bean is never inactive, and its lifecycle contains only two stages: nonexistent and existent.

The message-driven Bean class must implement the MessageListener interface. When the container detects a message in the Bean listening queue, it calls the onMessage () method to pass the message as a parameter.