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
Let's look at each container in a little more detail.
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
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
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 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
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
The role of the EJB home interface is to provide a way for
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.
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.
It's worth breaking here for a moment to
As I've touched on in previous chapters, entity beans are
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
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