2.1 Enterprise JavaBeans Applications

Enterprise beans are components that are used as parts of distributed enterprise applications. Each enterprise bean encapsulates a part of the business logic of the application. An enterprise bean typically communicates with resource managers (such as database management systems), other enterprise beans, and other enterprise applications.

At the same time, various types of clients access enterprise beans. The clients of an enterprise bean can be other enterprise beans, Web service and enterprise applications, servlets, or application clients.

At runtime, an enterprise bean resides in an EJB container. An EJB container provides the deployment and runtime environment for enterprise beans, including such services as remote access using standard distributed protocols, security, transaction, deployment, and concurrency and instance life-cycle management. (Refer to Section 2.4, Container Tools and Services, on page 44 for a complete discussion of the EJB container and its services.) The process of installing an enterprise bean in an EJB container is called enterprise bean deployment.

An enterprise application can include one or more enterprise beans. When an application includes multiple enterprise beans, they can be deployed in one or more containers located on the enterprise's network.

Figure 2.1 illustrates an enterprise application that includes seven enterprise beans EJB1 through EJB7 as well as components that are not enterprise beans: a Web service (WebService1), a Web application (WebApp1) comprised of several JavaServer Pages, and an application-client program (Client1). The figure illustrates how an enterprise bean can function as a client of another enterprise bean. Each enterprise bean that invokes a method on another enterprise bean is considered a client of the second enterprise bean. For example, EJB3 is a client of EJB5 and EJB6, whereas EJB2 is a client of EJB3 and EJB4.

Figure 2.1. Enterprise Application with Multiple Enterprise Beans

An enterprise can deploy the enterprise beans of the application illustrated in Figure 2.1 in either a single EJB container or multiple EJB containers. Figure 2.2 illustrates the deployment across three EJB containers that reside on multiple machines on a network.

Figure 2.2. Deployment Across Multiple EJB Containers

A client accesses an enterprise bean through the enterprise bean's client-view API. An enterprise bean can provide a remote client-view API, a local client-view API, or a Web service client-view API.

The remote client-view API is location transparent. This means that a client, regardless of whether it executes in the same Java™ virtual machine (JVM) as the enterprise bean or in a different JVM, can use the same API to invoke an enterprise bean. If the JVMs are in different containers, the client communicates with the enterprise bean over the network to perform the invocation. The remote client-view API consists of the bean's remote component and remote home interfaces.

If the client and the enterprise beans are intended to be in the same JVM, the developer may use a local client view, which allows the container to use an optimized internal path to perform the invocation without the overheads of remote calls. Furthermore, the local client-view API has more capabilities than the remote client-view API. The local client-view API consists of the local component and local home interfaces.

If the enterprise bean needs to expose its functionality as a Web service to other Java or non-Java clients, then the developer may use a Web service client view. Like the remote client view, a Web service client view is location transparent. However, it includes specific features that allow the methods of the enterprise bean to be exposed as Web service operations and accessed using XML-based Web service protocols. In the EJB 2.1 architecture, the Web service client view is available to only a specific kind of bean: stateless session beans.

The client-view API is independent of the type of the client using the API. This means that a client that is itself an enterprise bean uses the same API to invoke another enterprise bean as, for example, a Web application and a stand-alone Java client program. While it is possible for an application developer to provide more than one client-view API for an enterprise bean, the developer typically designs an enterprise bean with a single client view in mind. (Refer to Section 2.3, Structure of Enterprise Beans, on page 27 for more information on the client-view API.)

To succeed in the marketplace, all enterprise applications must quickly adapt to rapidly changing requirements; at the same time, enterprises need to evolve their businesses. It is essential that an application environment allow for this evolution, and the EJB architecture and the client-view API do allow for this. The organization of an application's business logic into components that communicate with one another via a well-defined client-view API enables application evolution to be accomplished with a minimum of overhead and disruption or downtime. If business rules change, an enterprise needs to upgrade only the enterprise bean that implements the changed business rules. If the upgraded enterprise bean preserves the original client-view API or provides a backward-compatible client-view API, an enterprise does not need to change the rest of the application to accommodate the changed business rules.