The J2EE Container Architecture

---

The J2EE architecture views an application as a collection of related yet independent components, that interact with one another through the container. The container acts as an execution environment for the components and provides services for them. This relationship is illustrated below:

The above diagram illustrates the relationship where the container contains one, or more components. The components contain the Java code and resources (servlets, static files, property files, API, descriptors) required to perform their function. As part of the component deployment process we specify the container settings for each component, and for the J2EE application as a whole (using XML files as we'll see in Chapter 4). Once the application components are deployed, the range of J2EE services provided by the container are available to the components.

From the programmer's point of view, the J2EE platform vendor provides the container, subject to the J2EE specification. The programmer's responsibility is to develop the components, within the context of the container. The application developer does not need to understand specifically how the container receives requests (over socket connections) and maps them to a specific resource or any of the other responsibilities of the container. The J2EE container has this responsibility and the developer has only to worry about their specific components and application.

J2EE Container Types

The architecture of J2EE, which is component-based and platform-independent, allows us to develop enterprise applications that are much easier to write, build, and maintain due to the straightforward modularity of the design. The J2EE server provides specific containers for different component types. Business logic can be modularized and reused where possible, without having to directly manage any of the low level complexities such as resource pooling, transactions, and the management of state.

The diagram below shows the J2EE container architecture:

On the client side, two containers are specified by J2EE: the applet container and the application container. I have also included a J2EE server and an application server (covering J2EE and non-J2EE servers) as the client tier is not restricted to Java based applets or applications, but may also include other servers or programs.

The middle tier is managed by a J2EE application server. This is a Java-based web server that provides a web container for our web application. To be J2EE platform compliant it will also offer a J2EE EJB container and access to J2EE APIs such as JDBC, JNDI, and JAAS (more on these later). It may offer additional services or resources specific to the vendor, but at a minimum will comply with the J2EE specifications. BEA WebLogic Server, IBM WebSphere Application Server and the iPlanet Application Server are examples of J2EE application servers.

This application server manages two containers. The web container contains and provides the services for the web components. The EJB (Enterprise JavaBean) container is the business tier of the J2EE platform. This is where the business logic resides.

Let's now take a closer look at all of these types of container.

Client Containers

When considering client containers it is important to remember that J2EE clients need not be J2EE-specified clients. The J2EE specifications do not mention Java 2 Platform, Micro Edition (J2ME) clients that may run on smaller hand-held devices (for instance cell phones or PDAs) and could be suitable clients for a J2EE server. There may be other non-Java applications or servers, or even J2EE servers, acting as clients.

For example, there may be an existing client-server-database three-tier application already running successfully in a company. As the business changes and develops, the business rules and logic governing this application may change and it may be better to rewrite part or all of the application. It may be simplest to rewrite the server side of the equation because this may be all that is affected, while the database and client (written in another language possibly) may be left unchanged. The client may be rewritten at a later stage, but users may be happy with the client as it stands and don't want to change it.

Often, client components use HTTP to communicate with the server, but any other suitable protocol may be used as long as both client and server tiers support the protocol. Any number of communication methods can be used, from straight web-based (D/X) HTML for browsers, to WML for cell phones, to XML for applet/application or other clients, or serialized Java objects between Java-based applets or applications.

Java-based clients in J2EE applications will use a thin client structure, which means that a relatively lightweight client application communicates with the server. The server has the more complex and heavyweight responsibilities, such as connecting to one or more databases, connecting to other 'legacy' applications, providing other services (messaging, say), and any other processing of complex business logic. This is generally considered most efficient, as J2EE servers contain the wider range of services (which do not then have to be downloaded to the client) and are designed to be secure, fast and reliable.

The specification also mentions that HTML pages may also be used to provide a more limited user interface for the J2EE application.

Application Container

The application container (provided by J2SE) runs the Java application from the client machine and normally uses the Swing (and/or Abstract Window Toolkit (AWT)) APIs to construct the graphical user interface. The diagram below shows the containers and a sample application:

The application, as shown in the diagram above, is packaged in a JAR file. As expected, the application is executed from the main() method in the application class. The JAR file also includes any other classes or packages required by the application, and may also include (though not included in the J2EE specifications) any resource files, such as images that may be required. The application container will provide access to the entire standard API included with J2SE and may provide additional services. The application may have access to all components that exist on the middle tier including servlets, JSP pages and EJBs.

Generally though, the application will connect to the middle tier to send requests and receive responses. Normally the client is fully responsible for initiating requests, although the JMS (Java Message Service) API can be used to listen for event or message notification from the middle tier. The application container provides the client application with the runtime environment and access to the libraries of the Java 2 Platform, Standard Edition.

Applet Container

The J2EE specification also mentions the container in which the applet client will run, which may be in a browser or other application or device which supports the applet programming model. Applets are GUI based, and are subject to more restrictions than other applications due to the Sandbox security model which limits their access to the client machine. They are normally contained in a web page downloaded from the server and run within a sandboxed JVM within the browser; the applet clients are deployed from a J2EE server and then loaded by the client and executed. The applet is also limited to only contacting the server from which it was downloaded.

Middle Tier Containers

There are two containers that can be found on a J2EE application server, and these contain components from the middle tier: either web components or EJB components. Let's take a closer look at them.

The Web Container

A web container is a Java environment that manages the execution of all servlets and JavaServer Pages (JSP) (both of which are web components) for a web application. It is part of a web or application server that supplies the network services over which requests and responses are made. It must support HTTP, and optionally may support other protocols. It may be built into a web server or may be plugged in as a component to a web server. The container is responsible for the management of the lifecycle (initialization and destruction) and the invocation of the servlet and JSP instances.

For the programmer, the web container is where we place our web application so that we can run them on the web server that provides the web container.

The EJB Container

Enterprise JavaBeans (EJB) are business components that contain the business rules or logic. There are two basic types of EJBs. Session beans are logic-orientated and deal with handling client requests (often from servlets) on one hand and the data processing logic on the other hand. Entity beans on the other hand are strongly coupled with the data itself and deal with data access and persistence.

EJBs are run in an EJB container. EJB components are reusable and are designed to be pooled and efficiently recycled for optimization. It is the EJB container's responsibility to manage the execution and pooling of EJBs for the application.

---