2.4 Container Tools and Services

Enterprise beans implement the business logic of an application. By themselves, however, they are not a complete operational application. You must first deploy an enterprise bean in a container so that it becomes part of a runnable application.

Deployment tools, provided by the container vendor note that the commercial term for an EJB container is application server read the deployment descriptor for the enterprise beans and generate additional classes, called container artifacts. The complete application consists of the enterprise beans, the generated container artifacts, and the container.

Recall that the container includes the implementation of the system-level services that are required by the application. The container artifacts enable the container to inject these system-level services into the application. In other words, the container uses the generated artifacts to interpose on the client calls to the enterprise beans so that the container can inject its services into the application.

2.4.1 Container Artifacts

Container artifacts are the additional classes generated by container tools at deployment. These classes are necessary to bind the enterprise beans with the container runtime. At a minimum, the container tools generate the classes that implement the enterprise bean home and component interfaces. Because the goal of the EJB architecture is to allow clients to invoke the enterprise bean via the home, remote, and Web service interfaces over the network, the objects that implement these interfaces cannot be simple Java objects. The home and remote objects are distributed Java RMI objects that implement the communication between a remote client and the enterprise bean deployed in the container. The Web service endpoint object is a JAX-RPC (Java API for XML-based RPC) endpoint object. These objects also communicate internally with the container at runtime to inject container services into the client method invocation path. Although the services provided by the container must meet the requirements of the EJB specification, container vendors still have a great deal of latitude in how they implement these services.

The EJB architecture allows any distributed object protocol to be used between the clients and the container for invocations to a remote interface. However, compliant container implementations must support at least the RMI-over-IIOP protocol for enterprise bean invocations, along with the CORBA transaction, security, and name service mechanisms. This allows clients and enterprise beans to interoperate even when they are running in containers built by different vendors. Of course, containers may support additional protocols, which could be used when both the client and the EJB container are running in the same vendor's environment. When the container is using RMI-IIOP, the container tools typically generate two RMI-IIOP object types (Figure 2.4). Each RMI-IIOP object type consists of multiple Java classes.

Figure 2.4. Container Artifacts

AccountRMI and AccountHomeRMI are RMI-IIOP object types. Their instances are distributed CORBA objects that implement the communication between the clients and the enterprise beans in the container. The AccountHomeRMI object type provides the implementation of the enterprise bean home interface, AccountHome. The AccountRMI object type provides the implementation of the enterprise bean remote interface, Account.

The instances of the AccountRMI object type are referred to as enterprise bean objects. The instances of the AccountHomeRMI object type are referred to as enterprise bean home objects. Most container implementations create only one instance of the enterprise bean home object type. This one instance is shared among all clients.

The client communicates with the enterprise bean objects AccountRMI and the enterprise bean home object AccountHomeRMI. The client never communicates directly with the instances of the enterprise bean class. Because the container vendor defines the implementation of the AccountRMI and AccountHomeRMI objects, these objects can inject or add the container services when delegating the client-invoked methods to the enterprise bean instances.

For the local home and local interfaces, too, the container needs to similarly generate implementation classes that implement all the methods in these interfaces and delegate to the actual enterprise bean class after injecting container services. However, because they are accessed only by clients in the same JVM, both the local and local home objects are not distributed Java RMI objects. The local and local home objects follow a similar inheritance hierarchy as for remote interfaces but implement the local interface and local home interface, respectively.

For the Web service interface, the container again needs to generate the appropriate skeleton classes to communicate with the Web services protocol layer in the application server. The Web services protocol is typically Simple Object Access Protocol (SOAP), so the container-generated artifacts extract the EJB invocation request from the SOAP message and perform the invocation. See Chapter 9 for more information. Figure 2.5 illustrates the instances of the RMI-IIOP objects, local objects, and Web service objects that exist at runtime in our AccountEJB example.

Figure 2.5. AccountEJB Example Runtime Objects

2.4.2 Container Runtime Services

As discussed in Section 2.4.1, Container Artifacts, the EJB architecture uses a method-call interposition protocol to invoke the methods of the enterprise bean. Rather than invoking the methods of the enterprise bean directly, the client invokes them indirectly via the runtime objects generated by the container tools. This method-call interposition allows the container to inject its services transparently to the enterprise bean and client application code. The deployer specifies the services that the container adds to a method call. The deployer bases this specification on the information in the enterprise bean's deployment descriptor.

The container provides the following services to enterprise beans deployed in the container: distributed object protocol, thread management and synchronization, process management, transactions, security, state management, resource pooling, data access, system administration support, failure recovery, high availability, and clustering.

• Distributed object protocol The container implements the distributed object protocol used for communication between the enterprise beans and their clients. For example, if the container uses RMI-IIOP for the communication with clients, the container includes an ORB and RMI-IIOP runtime library. The container tools automatically generate the RMI-IIOP stubs and skeletons for the enterprise beans' home and remote interfaces at deployment. This service allows the bean developer to write only local Java code. The developer does not have to implement distributed programming.

• Thread management and synchronization The container starts and stops threads as needed to serve multiple client requests. The container synchronizes the threads to avoid concurrent method invocations of an enterprise bean instance. This relieves the bean developer from having to do complex multithreaded programming. Instead, the bean developer codes the business methods as if the enterprise bean instances were used by only one user.

• Process management The container may use as many operating system processes as is optimal on the target server machine and/or as set by the system administrator. Because the container handles system process usage, the bean developer does not have to learn how to manage operating system processes.

• Transactions The container manages transactions according to the information in the deployment descriptor. Based on the deployment descriptor instructions, the container may

  • Wrap a method invocation in a transaction

  • Import a transaction from the client

  • Run the method without a transaction

  If a method executes in a transaction, the container propagates the transaction to resource managers and to other enterprise beans called by the enterprise bean. The container also performs the transaction-commit protocol. Having the container handle transactions means that the bean developer does not have to implement the complex management of transactions in a distributed system.

• Security The container performs security checks before permitting a client to access an enterprise bean business method. The container checks whether a client is authorized to invoke a business method before it delegates a client call. This authorization service means that security policies do not have to be hard-coded into the enterprise beans. The deployer and system administrator can set security policies to meet the needs of the enterprise by using administration and deployment tools.

• State management The container performs state management and optimizes resource usage. When it needs to free resources, the container can deactivate an enterprise bean object. Later, the container activates the object when the object is invoked by a client. State management by the container means that the container can achieve scalability to a high number of users with minimal burden on the bean developer.

• Resource pooling The container can efficiently reuse resources, such as database connections, to achieve better performance. As a result, the bean developer does not have to develop complex pooling logic as part of the application code.

• Data access The container generates the data access logic for entity beans with container-managed persistence. This not only makes the development of the bean easier but also makes it possible to adapt an enterprise bean at deployment time to work with existing customer databases.

• System administration support The container provides system administration tools to manage deployed applications. These tools enable the management of enterprise bean applications at runtime. This support also relieves the bean developer from having to develop the administration support as part of the application. For example, the container may allow the system administrator to classify applications by priority and to set limits on the resources used by low-priority applications.

• Failure recovery The container can provide automatic restart of a failed transaction or application. This means that the bean developer does not code failure recovery or restart logic into the application.

• High availability Containers may provide sophisticated high-availability strategies to mask various server errors from the clients. It is important to note that the support for high availability is transparent to the bean developer. Thus, most well-formed EJB applications can be made highly available simply by deploying them in a container that implements the support for high availability.

• Clustering A high-end container may be distributed across multiple nodes of clustered server. Clustering is transparent to the bean developer. This transparency enables all EJB applications to run on a clustered system.

Table 2.3 summarizes the services that the container provides to the enterprise beans at runtime.

Table 2.3. Container Runtime Services

Service	Description	Benefit
Distributed object protocol	The container implements the distributed object protocol used for communication between the enterprise beans and their clients.	The bean developer writes only local Java code and does not have to implement distributed programming.
Thread management and synchronization	The container starts and stops threads as they are needed to serve multiple client requests. The container synchronizes the threads to avoid concurrent method invocations of an enterprise bean instance.	The bean developer does not have to implement the complexity of multithreaded programs but instead codes the business methods as if the enterprise bean were used by only one user.
Process management	The container may use as many operating system processes as is optimal on the target server machine and/or as set by the system administrator.	The bean developer does not have to learn how to manage operating system processes.
Transactions	Based on the information in the deployment descriptor, the container may wrap a method invocation in a transaction, import a transaction from the client, and propagate a transaction into resource managers and other enterprise beans used by the enterprise bean. The container also performs the transaction-commit protocol.	The bean developer does not have to implement complex management of transactions in a distributed system.
Security	The container checks whether the client is authorized to invoke a business method before delegating a client call.	Security policies do not have to be hard-coded into the enterprise beans but rather can be set by the deployer and system administrator to meet the needs of the enterprise.
State management	When it needs to free resources, the container can deactivate an enterprise bean object. Later, the container activates the object when it is invoked by a client.	The container can achieve scalability to a high number of users with minimal effort by the bean developer.
Resource pooling	The container can efficiently reuse resources, such as database connections, to achieve better performance.	The bean developer is not burdened with developing any complex pooling logic.
Data access	For entity beans with container-managed persistence, the container generates the data access logic.	An enterprise bean can be adapted at deployment to work with existing customers' databases.
System administration support	The container provides administration tools to manage deployed applications.	Enterprise bean applications are manageable at runtime. The bean developer does not have to develop the administration support as part of the application.
Failure recovery	The container can provide automatic restart of a failed transaction or application.	The bean developer does not code any failure recovery or restart logic into the application.
High availability	Containers may provide sophisticated high-availability strategies to mask various server errors to the client.	Because the support for high availability is transparent to the bean developer, any EJB application can be made highly available by deploying it in a container that supports high availability.
Clustering	A high-end container may be distributed across multiple nodes of a clustered server.	Because clustering is transparent to the bean developer, all EJB applications are enabled to run on a clustered system.