What Do Containers Do?

A common misconception about containers is that they operate within their own JVMs. This isn't the case, especially according to the J2EE EJB and Servlet/JSP specifications. Technically speaking, the containers are nothing more than vendor-provided (IBM, in this case) class packages that offer, among other things, deployment and runtime support for the specific application types that they're designed to support (e.g., EJBs and servlets).

However, the containers operate within the application server JVM. That is, as you've seen, you'll have one or many application servers running either clones or separate instances, and in each of those application servers, you'll have either a Web container or an EJB container, or both.

Let's look at each container in a little more detail.

The Web Container

The Web container, as noted previously, is the configuration and runtime engine for presentation layer type components, such as JSPs and servlets. Its role is to provide the plumbing for all the dynamic presentation components , such as the Request and Response objects, and manage the life cycle of each servlet as it is loaded and unloaded, finishing up with garbage collection by the application server's JVM.

Figure 9-2 shows how the Web container operates within the application server JVM space and how it communicates with the outside world.

Figure 9-2: Web container view

The application server itself is used to configure environmental settings such as the port that the Web container should listen on and a range of performance and operational settings that help to tune and optimize the runtime of this aspect of the application server.

As Web components (Web modules) are deployed to a WebSphere application server, part of the deployment process includes the absorption of configuration details located within the deployment descriptors of the Web modules (i.e., the WAR files). Included among these details in the deployment descriptors are directives such as the root context of the WAR and other specific types of information relating to the files to be referenced within the WAR file (e.g., servlet configuration and so forth).

As the application server "deploys" the WAR file, various other settings are configured through the deployment process. This covers settings such as HTTP transport configurations. Of these settings, the target HTTP port, Secure Socket Layer (SSL) configuration (if required), minimum and maximum threading allocation, time-out values, and a whole range of settings associated with the internal servlet engine (e.g., caching, session linkages, etc.) are configured during the deployment process.

Of note, the Session Manager is an embedded component within the IBM WebSphere application server's Web container. The Session Manager is also highly configurable, as you saw in Chapter 7.

The EJB Container

The EJB container is a little more complex than the Web container because of the nature of the components that operate inside it. Let's take a look at the EJB container (see Figure 9-3).

Figure 9-3: EJB container view

The key point to make about the EJB container is that, similar to the Web container, it sits in between the application server and the operational runtime components ”in this case, the EJBs. EJBs don't communicate directly to the outside world; instead, they communicate to the application server via the container interfaces. Like the Web container, the EJB container is a logical entity and not operational (as in an application server). Through vendor-provided classes, based on the application server, EJB, and EJB container specifications of the J2EE architecture, the container provides threading and transaction support as well as a bunch of other plumbing features.

An EJB is a complex beast . EJB technology builds on the philosophy that the application programmer shouldn't have to worry about the infrastructure, but merely about the application. This means that the server that deploys the EJBs must provide a number of services to EJBs in order to manage them properly. As such, there are a vast number of configurable combinations available within the EJB container aspect of the application server.

In order for the management of EJBs to be handled by the application server correctly, a client (i.e., a servlet, Java client, etc.) must access the EJBs through a conduit that is proxified. The conduit, or proxy, is provided by the EJB container. Ensuring that the outside world doesn't see the inner workings of the EJBs allows the EJB container to control persistence, security, caching, and connection management with no knowledge (or care) by the EJB client. To facilitate this, client access to EJBs is managed by multiple instances of the EJB home and EJB object interfaces. These interfaces are fundamental aspects of the EJB specification and are pivotal to the correct operation of the EJB container.

These interfaces are created by developers during development (e.g., within WebSphere Studio Application Developer or whatever Java/J2EE IDE the developers or you choose). This allows the application server to perform management tasks under the hood, by mapping the calls to these EJB interfaces to the appropriate calls to the EJB itself.

The role of the EJB home interface is to provide a way for clients to find and create EJBs as needed. For entity EJBs, the home interface includes methods for finding single beans or groups of beans, based on certain criteria, including at least one method that allows the location of a bean in a database using a primary key class (e.g., FindByPrimaryKey ).

For both entity EJBs and session EJBs, the home interface includes methods to create new instances of an EJB inside the EJB container and then return the reference to an instance of the EJB object interface for the specific EJB type.

Note  

There is only ever one EJB home interface instance per class of EJB in an EJB container, but there may be many EJB object interface instances, depending on how many actual instances of the EJB class are active in the EJB container.

Session and Entity EJBs

It's worth breaking here for a moment to briefly explain the distinction between session and entity beans, as well as the difference between the types of session beans (i.e., stateful and stateless beans).

As I've touched on in previous chapters, entity beans are essentially EJBs used for representation of persistent data. An entity bean can be accessed by multiple clients concurrently, unlike a session bean, which is typically associated with a singular client transaction. The session bean is created for use by a client request in which the transaction updates and alters the state of the session bean.

Both types of EJBs contain logic. In the case of the entity bean, it will contain logic to persist and depersist data to and from the data source (e.g., an Oracle database), as well as finder and other data query methods. The session bean more likely includes business logic such as application and integration logic.

As I alluded to previously, session beans consist of two types of enterprise beans: stateful session beans and stateless session beans. Stateful session beans are a heavier incarnation of the session bean flavor. This type of enterprise session bean has a tightly bound relationship with client transactions.

Stateless session beans, on the other hand, are reusable distributed object constructs. This form of session bean is higher performing than the stateful session bean and isn't as tightly bound to the client transaction as the stateful session bean is.

As a development or architectural recommendation, try to avoid using stateful session beans. Due to their tightly bound client transaction relationship, they don't offer a highly scalable solution. Stateless session beans provide a scalable and higher performing solution than stateful session beans. Primarily, this is due to the fact that stateful session beans need to have their state passivated, which increases load within certain components of your environment.

 

The final component, the EJB object interface, is responsible for providing access to the method operations of an EJB. Any call to an EJB object interface instance is associated with a corresponding call to an EJB instance by the EJB container. Because of this separation from the actual EJB, the container is free to release resources used by the EJB as it deems necessary. These resources include database connections or even the EJB instance itself, yet the container restores the EJB instance when a client makes a new call to it.

In the next section you'll look at the approach for tuning the EJB and Web containers. Be mindful of the previous sections ”it's a good thing to understand what it is you're tuning!