5.2 Enterprise Beans as J2EE Business Objects

As discussed in the previous section, business objects need to provide some generic services to clients, such as support for transactions, security, and remote access. These common services are complex in nature and are outside the domain of the business logic required to implement an application. To simplify development, enterprise applications need a standard server-side infrastructure that can provide such services.

The EJB tier of the J2EE platform provides a standard server-side distributed component model that greatly simplifies the task of writing business logic. In the EJB architecture, system experts provide the framework for delivering system-level services, and application domain experts provide the components that hold business-specific knowledge. The J2EE platform enables enterprise developers to concentrate on solving the problems of the enterprise instead of expending their efforts on system-level issues.

The Enterprise JavaBeans architecture defines components--called enterprise beans--that allow the developer to write business objects that use the services provided by the J2EE platform. There are three kinds of enterprise beans: session beans, entity beans, and message-driven beans.

• Session beans are intended to be private resources used only by the client that creates them. For this reason, session beans, from the client's perspective, appear anonymous.
• Entity beans are components that represent an object-oriented view of some entities that are stored in persistent storage, such as a database. In contrast to session beans, every entity bean has a unique identity that is exposed as a primary key.
• Message-driven beans are new to the EJB 2.0 architecture supported in the J2EE 1.3 platform. Message-driven beans are components that process asynchronous messages delivered via the Java Message Service (JMS) API. Message-driven beans, by implementing a JMS message listener interface, can asynchronously consume messages sent to a JMS queue or topic.

Later sections of this chapter discuss each type of enterprise bean in detail.

Enterprise beans live inside EJB containers, which provide life cycle management, transactions, security, persistence, and a variety of other services for them. An EJB container is part of an EJB server, which provides naming and directory services, e-mail services, and so on. When a client invokes an operation on an enterprise bean, the call is intercepted by its container. By interposing between clients and components at the method call level, containers can inject services that propagate across calls and components, and even across containers running on different servers and different machines. Because the container adds these services "behind the scenes," this mechanism simplifies development of both components and clients. Figure 5.1 illustrates this.

Figure 5.1 Client View of Enterprise Beans

5.2.1 Enterprise Beans and EJB Containers

The EJB architecture endows enterprise beans and EJB containers with a number of unique features that enable portability, reusability, and ease of use:

• Enterprise bean instances are created and managed at runtime by a container. If an enterprise bean uses only the services defined by the EJB specification, the enterprise bean can be deployed in any compliant EJB container. Specialized containers can provide additional services beyond those defined by the EJB specification. An enterprise bean that depends on such a service can be deployed only in a container that supports that service.
• The behavior of an enterprise bean is not wholly contained in its implementation. Service information, including transaction information (described in Chapter 8) and security information (described in Chapter 9), is separate from the enterprise bean implementation. (For transactions, this separation is particularly true when the bean opts to delegate transaction management to the container. However, beans that choose to do their own transaction management include calls to the appropriate methods of the javax.transaction.UserTransaction interface in their implementation class.) When service information is kept separate from the bean implementation, the service information can be customized during application assembly and deployment (described in Chapter 7). This makes it possible to include an enterprise bean in an assembled application without requiring source code changes or recompilation, even when it is redeployed in a different environment. Specifying service-level details in the deployment descriptor also greatly reduces the amount of code that a developer needs to write.
• The bean provider defines the client view of an enterprise bean. The client view of an enterprise bean can be either a remote view or a local view. A provider can define both types of views for a bean, but usually only one or the other is provided. The client view of an enterprise bean--either remote or local--is provided through two interfaces: a component interface and a home interface. Although the client view is unaffected by the container and server in which the bean is deployed, the client of a bean's local client view must be co-located in the same container as the bean. Because the client view is the same regardless of the container or server in which the bean is deployed, it ensures that both the beans and their clients can be deployed in multiple execution environments without changes or recompilation. The client view interfaces are implemented by classes generated by the container when a bean is deployed. It is by implementing these interfaces that the container can interpose on the client operations on a bean and inject its services. See Section 5.3 on page 140.

The following sections describe the home and component interfaces and the enterprise bean class. Note that only session and entity beans have client view interfaces. Message-driven beans are not directly accessible by clients. Access to message-driven beans is discussed in Section 5.6 on page 153.

The home interface provides methods for creating and removing enterprise beans. In addition, the home interface of an entity bean also contains methods to find instances of the bean based on certain search criteria, and it may contain home business methods.

The home interface for an enterprise bean with a remote client view must extend javax.ejb.EJBHome. The home interface for an enterprise bean with a local client view extends javax.ejb.EJBLocalHome.

Generally, the enterprise bean's remote home interface allows a client to do the following:

• Create new enterprise bean instances
• Remove enterprise bean instances
• Get the metadata for the enterprise bean through the javax.ejb.EJBMetaData interface. The javax.ejb.EJBMetaData interface is provided to allow application assembly tools to discover the metadata information about the bean.
• Obtain a handle to the home interface. The home handle can be serialized and written to stable storage. Later, possibly in a different Java virtual machine, the handle can be deserialized from stable storage and used to obtain a reference to the home interface.
• Find an existing entity bean instance. The home interface of an entity bean provides one or more methods for finding existing entity bean instances within the home. Every entity bean home contains a findByPrimaryKey method. A client that knows the primary key of an entity object can obtain a reference to the entity object by invoking the findByPrimaryKey method on the entity bean's home interface. The bean provider may define other finder methods in the entity bean's home interface as well.
• Provide business logic across all bean instances. The home interface of an entity bean may also define methods to provide business logic that is not specific to an individual bean instance.

An enterprise bean's local home interface is similar to the remote home interface. It allows clients to create and remove enterprise bean instances, but it does not provide methods for getting metadata or for obtaining a handle.

The component interface defines the set of business methods available to clients. An enterprise bean may have a remote and/or a local client view. The bean developer must define a component interface for each such client view that the bean provides. Usually, a bean provides either a local or remote view, but not both.

The remote component interface must extend javax.ejb.EJBObject, while the local component interface extends javax.ejb.EJBLocalObject. Implementations of these interfaces (which are generated by the container) delegate invocation of a business method to an instance of the enterprise bean class.

The javax.ejb.EJBObject and the javax.ejb.EJBLocalObject interfaces define the methods that allow clients to perform the following operations on a reference to an enterprise bean object:

• Obtain the home interface
• Remove the enterprise bean object
• Test whether a given enterprise bean object is identical to another
• Obtain an entity bean object's primary key

The javax.ejb.EJBObject interface for a bean with a remote client view defines a method that allows its clients to obtain a handle to the enterprise bean object. This method is not available to clients of a bean with a local client view.

The enterprise bean class provides the actual implementation of the business methods of the bean. A business method defined on the enterprise bean class is called by the container when the client calls the corresponding method listed in the component interface. In the case of a message-driven bean, the container invokes the onMessage method defined on the message-driven bean class when a message arrives for the bean to service. Depending on whether the bean is an entity bean, a session bean, or a message-driven bean, the enterprise bean class must implement the javax.ejb.EntityBean, the javax.ejb.SessionBean, or the javax.ejb.MessageDrivenBean interface.

In addition to business methods, the home interface and the enterprise bean class also share responsibility for create methods and for finder methods and home methods (in the case of entity beans).

The create methods provide ways to customize a bean at the time it is created. For each create... method listed in the home interface, the bean class implements a corresponding ejbCreate... method. A message-driven bean class must also implement an ejbCreate method, even though it has no home interface.

Finder methods provide ways to locate a bean. For each finder method listed in the home interface of an entity bean with bean-managed persistence, the bean class implements the corresponding ejbFind... method. In the case of an entity bean with container-managed persistence, the ejbFind... methods are defined as query methods in the deployment descriptors, and their implementation is provided by the container.

Entity bean classes must also provide an implementation for each home method listed in the home interface. These home methods are implemented with corresponding ejbHome... methods.

An entity bean with container-managed persistence may also define select methods in its bean class. A select method is a query method for the internal use of the entity bean class and is not exposed in the home or component interface. The bean provider defines the semantics of a select method by specifying an Enterprise JavaBeans Query Language (EJB QL) query string in the deployment descriptor. The container provides the implementation of the select method. Select methods return values from the container-managed persistent and container-managed relationship fields of entity beans with container-managed persistence.

The following three sections contain in-depth discussions of the properties and uses of entity and session beans. Message-driven beans are covered in Section 5.6 on page 153.