Enterprise JavaBeans in a Nutshell

Summary

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.

By Richard Monson-Haefel

The convergence of two technologies

The EJB specification represents the convergence of two technologies: traditional transaction-processing (TP) monitors, and distributed-component services.  TP monitors are powerful, reliable, scalable platforms that run applications written in procedural languages like COBOL and PL/1.  They manage the entire application environment including transactions, security, resource management, load balancing, and fault tolerance.  TP monitors like CICS, TUXEDO, and Encina are the backbone of many mission-critical enterprise applications.  TP monitors pioneered the distributed three-tier architecture, which separates the responsibilities of enterprise software into presentation, business logic, and backend resources.

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 end result is that Enterprise JavaBeans makes developing robust, three-tier enterprise applications much easier.  Corporate IT shops that have struggled with the complexities of delivering distributed systems using CORBA, DCOM, or Java RMI will find that EJB provides a far simpler and more productive platform on which to base development efforts.
 

The Enterprise JavaBeans Specification

The Enterprise JavaBeans specification defines the responsibilities of the component developers as well as EJB server vendors.  Component developers write business components (enterprise beans) according to the programming model defined in the specification.  Enterprise beans that conform to the specification are portable across all EJB servers.  Because EJB servers conform to the same specification, they can run any enterprise bean, and will automatically manage the enterprise bean's entire environment.
 

The Enterprise JavaBeans Architecture

Enterprise JavaBeans servers run in the middle tier of a three-tier architecture.  The presentation tier of the architecture is composed of Java clients that access enterprise beans using JNDI and Java RMI-IIOP.  The resource tier comprises one or more backend resource(s), usually including a database.  This is only a logical view of how EJB fits into an application architecture, however – it doesn't dictate physical location of the tiers.  The presentation tier, for example, might be desktop Java applications, Java servlets, or other enterprise beans.

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 bean’s 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 bean’s 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.

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 client’s 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 bean’s 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.
 

Conclusion

The Enterprise JavaBeans specification defines a powerful platform for distributed computing.  It defines both the component model used by the developers of application solutions and the infrastructure implemented by vendors of application servers.  It furnishes developers with a platform for defining business solutions that are robust, scalable, and portable across many vendors.