Enterprise JavaBeans (EJB) is a Java-based comprehensive component architecture for design and development of world-class distributed modular enterprise applications. EJBs are not only platform-independent, but can also run in any application server that implements EJB specifications. The EJB component architecture integrates several enterprise-level requirements such as distribution, transactions, security, messaging, persistence, and Enterprise Resource Planning (ERP) systems.
1. Benefits of EJB
Unlike other distributed component technologies such as CORBA and Java RMI, the EJB architecture hides most of the underlying system-level semantics such as instance management, object pooling, connection pooling, and thread management. The EJB container performs these tasks on behalf of us.
In the EJB architecture, beans contain the business logic, not the client. Therefore, the client developer can devote more time to the presentation of the client. Since clients do not have to implement business logic, they are thinner. This is very much required if devices running client applications are small and resource-constrained.
EJBs are portable and can run on any EJB compliant server.
It also provides us different types of components for business logic, session, persistence, and enterprise messages.
2. Usage Scenario
The EJB architecture should be used for those applications that have any of the following requirements:
- The applications must be scalable. The application’s components need to be distributed across multiple machines to accommodate a large number of users. EJBs can run on different machines. Moreover, their location will remain transparent to the clients.
- Transactions are required to ensure data integrity. Enterprise beans allow us to perform transactions in a safe way. They also provide mechanisms for accessing shared objects concurrently.
- The application will have a wide variety of clients. Remote clients can easily locate enterprise beans using just a few lines of code. These clients can be thin, various, and numerous.
3. EJB Architecture
Before discussing the EJB architecture, let us understand the fundamental requirements of the distributed component architecture.
- It must provide mechanisms to instantiate the server-side and client-side proxies. A client-side proxy is created at the client side that represents the actual remote server object and acts as a proxy. A server-server side proxy, on the other hand, is created at the server-side. It must provide the basic mechanism to accept client requests and delegate these requests to the object implementation.
- It must provide a mechanism that allows us to have a reference to the client-side proxy. Using this reference, clients invoke methods. The client-side proxy is responsible for communicating with the server-side proxy.
- It must support a mechanism that can be used to inform the system that a specific component is no longer needed.
To satisfy these requirements, the EJB architecture specifies two types of interfaces: javax. ejb.EJBHome and javax.ejb.EJBObject. The javax.ejb.EJBHome defines the methods that allow a remote client to create, find, and remove EJB objects, as well as home business methods that are not specific to a bean instance. On the other hand, javax.ejb.EJBObject defines methods that collectively provide the remote client view of an EJB object.
There are three kinds of beans in the EJB architecture: Session Beans, Entity Beans, and Message Driven Beans.
4. Session Beans
Session beans perform specific tasks for a client. They are plain remote objects meant for abstracting business logic.
A client invokes methods of the session bean to access an application, which is deployed on the EJB server. The session bean performs business tasks inside the server on behalf of the client, hiding all the complexities from the client.
A session bean, as its name suggests, can be considered as an interactive session. A session bean is not shared. It can handle a single client in the same way that an interactive session may have just one client. A session bean, like an interactive session, is not also persistent. This means that its state is not saved to a database. When the client finishes, its session bean is also terminated. There are two types of session beans: stateless and stateful.
4.1. Stateless Session Beans
A stateless session bean does not keep the state between client requests. When a client sends a request for method invocation, the EJB container assigns an instance of a stateless bean. During the method invocation, bean’s instance variables may have a state, but that is valid only during the method invocation. When the client makes another request, the same instance may not be assigned to the client, possibly due to the reason that it is already assigned to another client.
Since a stateless bean can be assigned to any client, it supports multiple clients. Therefore, to support the same number of clients, a lesser number of stateless session beans is required than stateful session beans. Session beans are useful for applications that have a large number of clients.
4.2. Stateful Session Beans
The state of a bean consists of values of its instance variable. Unlike stateless session beans, stateful session beans maintain their states. It means that a client sees the same state of the bean when it interacts with the stateful session bean through multiple method invocation. This is accomplished by assigning the same session bean to the client across multiple requests.
The stateful session bean loses its state when a client terminates. When the client terminates, the state is no longer necessary.
5. Entity Beans
Entity beans model real world business objects such as customers, orders, and products. They contain business logic that can be saved in a persistent storage for later use. The state of an entity bean persists beyond the lifetime of the application or the EJB server process. In J2EE, the persistency is obtained using a relational database. Usually, each entity bean has an underlying table in a relational database. Each instance of the bean corresponds to a row in that table.
Persistency can be obtained in two ways: bean-managed and container-managed. In the bean- managed persistency mechanism, the entity bean itself contains the code to save its state in the underlying table. On the other hand, in the container-managed persistence mechanism, the EJB container generates the necessary database access calls automatically.
Container-managed entity beans are not tied to a specific database. Therefore, you can redeploy the same entity bean on different J2EE servers that use different databases without modifying or recompiling the bean’s code.
Multiple clients may share entity beans. So, entity beans work within transactions. The EJB container usually supports transaction management. In this case, you only have to specify the transaction attributes in the bean’s deployment descriptor. The EJB container will take care of the rest of the procedure.
6. Message Driven Beans
A Message Driven Bean acts as a listener for the Java Message Service API, processing messages asynchronously. It is similar to an event listener, except that it receives messages instead of events.
The messages may be sent by a wide range of entities such as J2EE components, application clients, other enterprise beans, web components, JMS applications, or even systems that do not use J2EE technology. Message Driven Beans currently process only JMS (Java Message Service) messages, but provisions are left so that they can process other kinds of messages in the future.
The message-driven beans differ from session and entity beans in the sense that clients do not access message-driven beans through interfaces. Message Driven Beans and stateless session beans are similar with respect to the following points:
- They do not maintain state for a client. However, sometimes they can contain state across the handling of client messages such as an open database connection, an object reference to an enterprise bean object, or a JMS API connection.
- All instances are similar. The EJB container can use any instance to process a message. So, it can process multiple messages concurrently.
- One instance of a Message Driven Bean can handle multiple requests.
Note that, session and entity beans allow us to send and receive JMS messages. However, it happens in a synchronous way. We should not use synchronous ‘send-receive’, which are costly and blocking in a server-side component. Instead, message-driven beans can be used to send and receive messages asynchronously.
Source: Uttam Kumar Roy (2015), Advanced Java programming, Oxford University Press.