Chapter 9: WebSphere EJB and Web Container Performance

A key component for all J2EE application servers is the container. The container essentially compartmentalizes certain aspects of the operational runtime of your J2EE engine. Specifically in this chapter, you'll look at the EJB container and the Web container (sometimes referred to as the servlet container).

The Container: An Overview

As I've discussed in earlier chapters, the container is essentially a runtime environment in which the J2EE-based applications operate . The container also provides hooks into the application server interfaces, as well as distributes computing logic between external enterprise application and various services available from and within the local runtime.

J2EE tech-speak calls this a "federated API view, providing a common, yet maintainable framework for the deployment and runtime of J2EE- and J2SE- based application environments." Sound complex? It's not, really. Consider the diagram in Figure 9-1 to get a better understanding.

Figure 9-1: High-level application server framework container view

Essentially, Figure 9-1 shows a high-level view of a WebSphere implementation. There are three main components shown here. The first component is the outer box, which is the WebSphere application server itself. This area, or governing engine, provides all of IBM's implementation of the J2EE API stack and the associated services. The application server includes things such as the communications stack, administration functionality (e.g., JMX), and distributed computing services such as clustering and WLM functionality.

Within the WebSphere application server, you have the container (among other things). The container encompasses such things as enterprise application management services, J2EE application service interfaces, and distributed computing logic. It also contains deployment and configuration services for the J2EE applications that will be deploying and managing within your WebSphere environment.

The last major section in the diagram shows the J2EE application itself. This component or group of components contains all the Web Archives (WARs), Enterprise JavaBean Java Archives (EJB-JARs), and standard components such as external Java Archives (JARs) and stand-alone classes.

All of this is typically bundled up into an Enterprise Archive Resource, or EAR, file. Within the EAR file, you have all the components included into a tarball-like structure, governed and mastered by an enterprise application deployment descriptor (i.e., ejb-jar.xml files) and vendor-specific deployment descriptors.

The enterprise application deployment descriptor is the master descriptor for your J2EE application. It includes all important information associated with your EAR and its internal components. Bootstrap information, initial JNDI context information, and proprietary vendor information specific to each vendor's implementation of an application server are all included within the enterprise application deployment descriptor.

Each of the constituent parts , such as the WARs and EJB-JARs, has deployment descriptors specific to it and the code and logic within it.

Note  

Technically speaking, there are actually several different containers within WebSphere. Not only are there the standard or more commonly known containers, the Web and EJB containers, but also there are others, such as the application container (for application clients ). These secondary level containers are pretty much self-managing and don't offer a lot in the way of performance-tuning capability.