Enterprise JavaBeans in a Nutshell
This article provides an extremely succinct overview of Enterprise JavaBeans (version 2.0) and is intended for developers and managers who are not familiar with EJB but have some background in distributed-object technologies. All the prime essays at https://prime-essay.net/ cover similar or related themes, including the professional guides for our clients.
The convergence of two technologies
Distributed-component systems represent a more modern approach to the three-tier architecture. These systems make objects or components that run in the middle tier available to other processes through remote proxies. These remote proxies communicate requests to the distributed component over the network.
Distributed-component services like Java RMI, CORBA, and DCOM have been in use for several years. Distributed components are more reusable and flexible than procedure-based applications used in traditional TP monitors, because they can be assembled into a variety of combinations when developing the business application, but they can be difficult to program, and lack the robust infrastructure that the TP monitors offer.
Combining the best of both TP monitors and distributed components, EJB servers provide a TP monitor-like environment for distributed components. The TP monitor characteristics of the EJB platform reduce the complexity of development by automatically managing the entire application environment, including transactions, security, concurrency, persistence, load balancing, and failover. The distributed-component characteristics of the EJB platform make developers more productive by allowing them to assemble applications from flexible and reusable components.
The distributed components used in EJB are called enterprise beans (beans). Enterprise beans are written in Java and are used to model the business logic of an organization. When a bean is developed it can be assembled with other beans into applications and deployed into an EJB server. At deployment time, the transaction, persistence, and security behavior of enterprise beans can be modified through declarative attributes, making EJB applications highly configurable.
The Enterprise JavaBeans Specification
The Enterprise JavaBeans Architecture
An enterprise bean comprises four essential parts: a home interface, a remote interface, a bean class, and an XML deployment descriptor. The home interface declares factory methods that are used by Java clients to create new enterprise beans, locate existing enterprise beans, and destroy beans. The remote interface declares the business methods of the enterprise bean, which are used by Java clients at run time. The bean class encapsulates the application logic of the bean and implements the business methods defined in the remote interface. The deployment descriptor is an XML configuration file that describes the enterprise bean and its run-time attributes to the EJB server when it is deployed. It is the responsibility of the bean developer to create the four parts of the bean and package them into a JAR file for deployment.
Figure 4: The enterprise bean component.
When an enterprise bean is deployed, the deployer uses tools provided by the EJB server to open its JAR file and read the XML deployment descriptor. The information in the deployment descriptor is used to configure the enterprise beans run-time behavior, so that it will execute properly on the EJB server. The enterprise bean is deployed into a container, which is a logical term that defines the part of the EJB server that hosts instances of enterprise beans. The container is responsible for managing transactions, security, concurrency, persistence, and resources the enterprise bean uses at run time. In addition, the container generates EJBHome and EJBObject proxies that implement the enterprise bean's home and remote interfaces respectively. These distributed-component proxies provide Java clients in the presentation tier with access to the enterprise beans in the middle tier. There is one EJBHome for every enterprise bean deployment, and one EJBObject for every remote reference to an enterprise bean.
Java clients on the presentation tier use JNDI (Java Naming and Directory Interface) to obtain a remote reference (proxy) to an enterprise beans EJBHome. JNDI is a vendor-neutral Java API that can be used with any kind of naming or directory service like CORBA naming, or LDAP. EJB servers must use some kind of JNDI-compatible naming or directory service to provide access to the EJBHome. Some EJB servers will use third-party naming or directory services while others will provide their own.
The client will use the EJBHome to create or find specific enterprise beans in the EJB container. When it does, it receives a remote reference to an EJBObject . The EJBObject implements the enterprise bean's remote interface and delegates calls made by the client to instances of the bean.
Java clients access enterprise beans through their EJBHome and EJBObject remote proxies, rather than directly. The EJB container intercepts every method invocation made on the remote proxies, so that it can manage the bean's run-time environment associated with the invocation. Method invocations on the EJBHome cause the enterprise bean's container to create or locate enterprise beans and provide EJBObject proxies to the client. Method invocations on the EJBObject are delegated to an instance of the enterprise bean class, which contains the business logic needed to service the request. The EJB container may use many instances of the enterprise bean class to support many clients, which allows the EJB server to scale, so that it can handle very large client loads.
Figure 6: Object interaction diagram
There are three types of enterprise beans: session, entity, and message-driven. While the message-driven bean is new in EJB 2.0, the session and entity beans were introduced in Enterprise JavaBeans 1.0, in 1998. Session and entity beans are similar to typical distributed components: they reside in the middle tier and handle synchronous remote method calls made by clients. A message-driven bean, on the other hand, is not like a distributed component. It processes asynchronous messages delivered via the Java Message Service (JMS).
Session beans represent non-persistent, transaction-aware, server-side components. They are used to model processes, services, and client-server sessions. A session bean may be stateful or stateless.
A stateful session bean is dedicated to the Java client that created it. Its class defines instance variables that can hold session data from one method invocation to the next, which makes methods interdependent. This trait allows the bean to act as an extension of the client, maintaining session data on the EJB server and executing tasks for the client. Stateful session beans are used to model business concepts that represent agents or roles that perform tasks on a clients behalf. Examples of such beans may include a bank teller that processes monetary transactions, a shopping cart used in on-line commerce, or a travel agent that makes flight, hotel, and car-rental reservations.
Stateless session beans are not dedicated to a single client; they are shared by many. This sharing makes stateless session instances more scalable, but also prohibits them from maintaining session data. Stateless session beans behave more like an API, where method invocations are not interdependent. Each invocation is effectively stateless and is analogous to static methods in Java classes. Stateless session beans are used to model stateless services such as credit-card processing, financial calculations, and library searches.
Entity beans are persistent, transactional, server-side components. They are used to model persistent business-domain objects like bank accounts, orders, and products. Each of these has behavior in addition to data (typically stored in a database).
There are two types of entity bean, distinguished by how their persistence is managed. A bean-managed persistence (BMP) entity bean is responsible for managing its own relationships and persistence state in the database. A developer defining a BMP bean writes the database-access logic directly into the bean class. A container-managed persistence (CMP) entity bean, by contrast, leaves management of its persistent state and relationships to an EJB container. The beans developer need not write database-access code; it is generated automatically at deployment time. Container-managed persistence has undergone a major overhaul in EJB 2.0.
Message-driven beans are stateless, server-side components that are used to receive and process messages that Java clients send to them via JMS. They are used to model processes and routers that operate on inbound enterprise messages. Developers might use message-driven beans to integrate an EJB system with a legacy system, or to enable business-to-business interactions. While a message-driven bean consists of a bean class and an XML deployment descriptor, it does not have a remote or home interface. Message-driven beans are not distributed components, and do not have EJBObject and EJBHome references; they respond only to asynchronous messages delivered from JMS.