Types of EJB
EJB is an acronym for Enterprise Java Beans. It is a server-side software element. It encapsulates the business logic of an application. It is a specification for developing a distributed business application on the Java platform. There are three types of EJBs: Session Bean, Entity Bean, and Message-Driven Bean. In this section, we will discuss all types of EJB in detail.
Let's discuss one by one in detail.
The bean sprout business idea that can be systematically used by customer, remote, and web service. When a client wants to use an application distributed on a server, then the client uses session bean methods. This session bean provides services to customers, protecting them from complex problems by performing business operations within the server.
To get to an application that is conveyed to the worker, the client summons the meeting bean's strategies. The meeting bean performs work for its client, safeguarding it from intricacy by executing business errands inside the worker. Remember that session beans are not persistence.
There are two types of session beans:
Stateless Session Beans
A stateless session bean doesn't keep a conversational state with the customer or client. When a client invokes the methods for a stateless bean, the bean's instance variable may contain a state explicitly to that client however only for the span of the invocation.
At the point when the method has finished, the client explicit state should not be held. However, the client may change the state of instance variable presented in pooled stateless beans, and this state is held over to the following invocation of the pooled stateless bean.
Besides this, during the invocation of the method, all instances of a stateless bean are the same, permitting the EJB container to assign an instance to any client. Therefore, the state of a stateless session bean should apply across all clients. It can be implemented in a web-services.
Since they can maintain various customers, stateless session beans can offer better adaptability for applications that require large numbers of clients. Ordinarily, an application requires fewer stateless session beans than stateful session beans to support the same number of clients.
To improve execution, we may choose a stateless session bean in the event that it has any of these characteristics.
Stateful Session Beans
A stateful session bean is the same as an interactive session. The state of an object comprises the values of its instance variables. In a stateful session bean, the instance variables denote the state of a unique client/bean session. Since, the client interacts with its bean. The state is usually called the conversational state. It maintains the state of a client across multiple requests. So, we cannot implement it in the web services because it cannot be shared. When the client terminates the session, it is no longer associated with the client.
The state is held for the span of the client/bean session. In case if the client eliminates the bean, the session closes and the state is omitted. This transient nature of the state isn't an issue, because the interaction between the client and the beans ends. So, it is not required to hold the state.
Stateful session beans should be used, if any of the following conditions are valid:
Note: Stateless and stateful both session beans are not persistent.
Singleton Session Beans
A singleton session bean maintains one instance per application and the instance exists for the lifecycle of the application. It offers the same functionality as the stateless session beans. But the only difference is that there is only one singleton session bean per application while in the stateless session bean a pool of beans is used.
From that pool, any of the session beans may respond to the client. We can implement it in the web-service endpoints. It takes care of the state but does not hold the state if unexpected crashes or shutdown occur. It can be used if we want to perform cleanup tasks on closing the application or shut down as well. It is because it operates throughout the life cycle of the application.
Singleton session beans are suitable for the following conditions:
An entity bean is an unpredictable business substance. It models a business substance or models different activities inside a business interaction. It is used to encourage business benefits that include data and calculations on that data. It can deal with various, needy, diligent articles in playing out its essential assignments. A substance bean is a far-off object that oversees steady information and performs complex business rationale. It can be extraordinarily distinguished by an essential key.
It is a far-off object that oversees steady information, performs complex business rationale, possibly utilizes a few ward Java protests, and can be remarkably distinguished by an essential key. It ordinarily coarse-grained determined items since they use steady information put away inside a few fine-grained relentless Java objects. Element beans are diligent on the grounds that they do endure a worker crash or an organization's disappointment.
Every entity bean has a persistence identity that is associated with it. It means that it comprises a unique identity that can be fetched if we have a primary key. The type for the unique key is defined by the bean provider. A client can retrieve the entity bean if the primary has been misplaced. If the bean is not available, the EJB container first, instantiates the bean and then re-populates the data for the client.
The diligence for entity bean information is given both to saving state when the bean is passivated and for improving the state when a failover has detected. It can endure in light of the fact that the information is put away determinedly by the holder in some type of information stockpiling framework, like a data set.
Entity beans persist business data by using the following two methods:
Bean Managed Persistence
Bean-managed persistence is more complicated in comparison to container-managed persistence. Because it allows us to write the persistence logic into the bean class, explicitly. In order to write the persistence handling code into the bean class, we must know the type of database that is being used and how fields of the bean class are mapped to the database. Therefore, it provides more flexibility between the database and the bean instance.
It can be used as an alternative to CMP. If the deployment tools are incompatible for mapping the bean instance's state to the database. The disadvantage of BMP is that more work is required to define the bean and it ties the bean to a specific database type and structure.
In container-managed persistence, the EJB container transparently and implicitly handles the relationship between the bean and the database. Bean developers focus on the data and the business process. The principal constraint is that the EJB compartment can most likely not produce information base access articulations with the proficiency of a programmer.
Unlike BMP, CMP does not allow us to write database access calls in the methods of the entity bean class. It is because the persistence is handled by the container at run-time. The following two things are required to support the CMP:
Note: Entity bean has been replaced with Java persistence API.
Message-Driven Bean (MDB)
MDB is a Java Messaging Service (message listener). It consumes messages from a queue or subscription of a topic. It provides an easy way to create or implement asynchronous communication using a JMS message listener. An advantage of using MDB is that it allows us to use the asynchronous nature of a JMS listener. We can implement message-driven beans with Oracle JMS (Java Messaging Service).
There is an EJB container (contains MDBs pool) that handles the JMS queue and topic. Each incoming message is handled by a bean that is invoked by the container. Note that no object invokes an MDB directly. All invocation for MDB originates from the container. When the container invokes the MDB, it can invoke other EJBs or Java objects to continue the request.
It is quite similar to stateless session bean. Because it does not save informal state, also used to handle multiple incoming requests. EJB has the following benefits over the JMS are as follows:
The primary function of MDB is to read (receive) or write (send) incoming from a JMS destination (i.e. queue or topic). While using MDB ensure that it is configured and installed properly. It interacts with JMS and the JMS installed on the Oracle database. The database retains queue or topic. The following figure depicts how MDB interacts with the JMS destination.
The working of MDB is as follows:
Note that it does not handle the requests that are requested by the clients instead it handles requests that are placed into a queue.
MDB implements the javax.ejb.MessageDriverBean interface and inherits the javax.jms.MessageListener class that provides the following methods:
Difference Between Session and Entity Bean
The following table depicts the key differences between session bean and entity bean.