Understanding the J2EE Container Model

Containers are vital to J2EE components. Containers are the run-time environments that provide standard common services to the deployed components. Containers are implemented and offered by various vendors in the form of J2EE-compliant Application Servers. Containers also provide unified access to enterprise information systems, such as access to relational data through the Java Database Connectivity (JDBC) API, or to legacy systems through J2EE Connector Architecture (JCA) API. In addition, containers provide a declarative mechanism for configuring applications and components at assembly or deployment time through the use of deployment descriptors. Features that can be configured at deployment time include security authorization and validation, transaction management, and other tasks. Figure 15.4 depicts the J2EE container model.

Each tier of the J2EE architecture may consist of more than one container. For example, the Web tier may consist of a servlet container (or engine) and a JSP container, which together make a Web container. Similarly, each EJB type runs on its own container, which is commonly known as an EJB container. Some Application Servers are offered with both a Web container and an EJB container.

A Java Application Server is a platform for developing and deploying multitier distributed J2EE-compiant enterprise applications. It centralizes application services such as Web server functionality, business components, and access to back-end enterprise systems. It uses technologies such as caching and connection pooling to enhance resource utilization and application performance. An Application Server also provides control over performance, transaction, security, scalability, and reliability. Application Servers provide infrastructure support to an enterprise, which not only reduces the cost of its applications, but also reduces the time-to-market. Each Application Server has its own advantages and disadvantages.

The following sections discuss each container used in the J2EE multitier architecture.

Applet Container (Web Browser)

Web browsers are standard clients for e-commerce applications. Web-based applications built with standard Web technologies are flexible, maintainable, and portable. In Web-based applications, the user interface is represented by HTML documents, images, form fields, and Java applets. The Web browser contains the logic to render the Web page on the user's computer from the HTML description.

J2EE Client Application Container

This is a Java client program that cannot run on a Web browser, and must supply its own code for rendering the user interface. Nonbrowser clients usually provide their own presentation and rendering logic. They depend on the Application Server for business logic and access to back-end services. They are more difficult to develop and deploy than Web-based clients. Any client applications written in Java can use an Application Server's common service over RMI (Remote Method Invocation).

RMI allows a client program to execute methods on an Application Server object the same way it does locally. Java applications can use the Java Swing classes to create powerful, portable, and sophisticated user interfaces. Java applications can be used effectively in the enterprise behind firewalls to avoid network issues. They can be integrated with CORBA-based applications by using the RMI/IIOP (Internet Inter-ORB Protocol) protocol.

Web Container

Web containers provide runtime support for responding to HTTP requests. They process requests by invoking JSP pages or a servlet, and returning results to the client. In addition, Web containers provide APIs to support user session management. Servlet containers and JSP containers, which collectively are called Web containers, host Web components. You learned about Web containers on Day 7.

EJB Container

As you learned on Day 1, EJB containers host EJB components. EJB containers provide automated support for transaction, security, persistence, and life cycle management of deployed components. EJBs are the business logic components for J2EE applications.

Clustering of J2EE Components and Services

An Application Server cluster is a group of Application Server instances that work together to provide scalable and reliable J2EE applications. A cluster of servers is transparent to its clients and perceived as a single server in delivering its consolidated services. The major two capabilities that a cluster provides are load balancing, and fail-over. Load balancing provide services that result in higher application scalability, while fail-over enhances the reliability and availability of the running applications.

All instances (also called nodes or members) of a cluster work together by replicating all components and services across them. Not all components and common services can be clustered. Each Application Server product provides unique capabilities for clustering objects. Should one member of a cluster fails, another member takes over the load to preserve the running services. This increases the availability of the application to its users.

Not all J2EE components and services are suitable for clustering. Some types of EJB, such as stateless session beans, read-only entity beans are highly clusterable objects, and can always be clustered. Services such as JMS and JNDI are suitable for clustering. On the other hand, great care must be provided when clustering stateful session beans, which are clustered using in-memory replication to provide failover. In-memory replication of state is a technique used to have multiple instances (called replicas) of the same component deployed across different nodes of the cluster. This is more efficient than replication done using persistence through the database. Read-write entity beans are always anchored to one member of the cluster on which they are instantiated. If this member fails, the application responsibility has to create a new instance.

JDBC connection pools can be clustered across multiple servers in an Application Server environment. When a client requests a connection from the pool, the cluster selects the server that will provide the connection, allowing load balancing and protection against server failure. After a client has a connection, the state maintained by the JDBC driver makes it necessary to pin the client to the host Application Server.

Java Message Service (JMS) objects also can be clustered among the different members of a cluster. Both JMS connection factories and JMS destinations (topic or queue) can be deployed on multiple members of a cluster. Such distribution of JMS resources throughout a cluster will enhance both load-balancing and fail-over of JMS services.

Load Balancing

You can configure multiple Application Servers to share large volumes of user requests. This is accomplished by using a proxy server (Web server) to perform load balancing by distributing requests across the multiple nodes in the tier behind it.

In large enterprise applications, multiple proxy servers (called a Web server farm) are used. The load on the proxy servers is distributed by an external load balancer. The most common load balancer is from Cisco.

Failover and Replication

Application Server provides session replication to ensure that a client's session state remains available. When the node managing the client session fails, the proxy server sends subsequent requests to the replica in the cluster. Session replication is done behind the scenes using the cluster software.

Session replication can be either in-memory or persistent replication. In-memory replication uses fewer resources and is more efficient than persistent replication, which is the most commonly used. Persistence replication writes the session data to a database; therefore, it's far less efficient and has a negative impact on the user's response time.