Looking Inside an EJB

Generally, an EJB consists of two interfaces and one class. The interfaces are the home and component interfaces, and the class is the bean class. Figure 1.3 illustrates what's inside an EJB, and how a client interfaces with it.

The home interface lists the available methods for creating, removing, and finding EJBs in the container. The home object is the implementation of the home interface that's generated by the container at deployment time. At runtime, the home object will be used by the client in conjunction with a naming service to find the component and establish a connection to its component interface.

The component interface defines the business methods offered by a bean class. Note that the bean class does not directly implement this interface but, rather, uses an EJBObject class that mediates the client's calls to a bean object. The container provides the implementation of this interface, and the client (in conjunction with a naming service to find the component and establish a connection to its component interface) will use it. The component interface can be either remote or local, depending on the location of the EJB client with respect to the EJB. This distinction is made to avoid network traffic due to remote calls.

The bean class is the implementation of the business methods listed in the component interface. It's accessed by the client through the component interface; it's not accessed directly.

The primary key class (not shown in Figure 1.3) is used only for entity beans, and is provided only if the underlying data table has a segmented key.

The EJB client locates the EJB containers through the JNDI service, and it interfaces with the EJB through the objects generated by the container. After an EJB client finds a reference to an EJB home interface, it can retrieve the EJB component interface. It can then issue business methods on the EJB component interface, which the container in turn delegates to the bean itself. EJB clients can be servlets, JSPs, or Java application clients.

Additional interfaces defined in the EJB specification allow beans to interact with the transaction service and control persistence if they are designed to do so. For simplicity, these interfaces are not shown in Figure 1.3.

The EJB container hosts enterprise beans, providing life cycle management and services such as caching, persistence, and transaction management.

EJB Server

The EJB server (also known as the J2EE application server) is the outermost container of the various elements that make up an EJB environment. The EJB server manages one or more EJB containers and provides required support services, such as transaction management, persistence, and client access. A JNDI-accessible naming space can be used by clients to locate the EJB. Figure 1.4 illustrates a J2EE application server.

The J2EE application server also provides operation resources, such as process and execution threads, memory, networking facilities, system resource management, connection pooling and caching, load balancing, fail-over, and so on to the containers and the elements within them. The EJB server can offer further vendor-specific features, such as optimized database access drivers, interfaces to backend systems, and CORBA accessibility.

A number of J2EE application servers are available today, such as BEA's WebLogic Server, IBM's WebSphere, and the open source JBoss.

EJB Containers

An EJB container is an abstract facility that manages instances of EJB components. The EJB specification defines the contractual agreement between the EJB and its container to provide both infrastructure and runtime services. Clients never access beans directly: Access is gained through container-generated methods, which in turn invoke the beans' methods. A container vendor may also provide additional services implemented in either the container or the server.