ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

J2EE Application Deployment Considerations

by Allen Chan

1 Introduction

If you talk to any senior J2EE developers today, many of them will be happy to provide you with details on the different EJB types or how to use JMS to send and receive asynchronous messages. However, it may be difficult to find someone to describe a deployment architecture that can ensure scalability, reliability, and performance. One reason for the lack of understanding by many developers on deployment architecture is that the J2EE specification contains few details on application deployment, leaving most up to individual vendors. This leads to confusion, as each vendor devises its own unique way of deploying J2EE applications. In this article, we will first describe the different J2EE modules and the different packaging structures. Afterwards, we will discuss possible deployment architectures and some of the deployment issues to consider during the design and implementation of a J2EE application.

Related Reading

Java Enterprise in a Nutshell
By William Crawford, Jim Farley, David Flanagan

Our discussion assumes that you already have some understanding of the core J2EE technology and are comfortable with technologies such as servlets, JSP, EJB, and XML. For details of the J2EE specification, please visit the Sun J2EE web site.

1.1 J2EE Modules

J2EE 1.3 supports the packaging of J2EE applications into different deployable modules. There are two families of J2EE modules:

  • Application modules (enterprise application or web application)
  • Standalone modules (EJB or resource adapter)

Basically, a Web Application Archive (WAR file) is used to deploy a web-based application. This file may contain servlets, HTML files, JSPs, and all associated images and resource files. On the other hand, an Enterprise Application Archive (EAR file) is a meta-container and may contain EJBs, resource adapters, and one or more web application modules. One area of consideration when packaging enterprise applications is the number of EAR files an application should use: should I include all of my EJBs in one EAR, or put each of them in different EAR files? This decision could have an impact on the performance, scalability, and maintainability of the application. We will discuss this further. For details on the individual module types, please refer to the J2EE 1.3 specification (PDF).

1.2 ClassLoader Relationship

One area that is often overlooked during the design of a J2EE application is the ClassLoader relationship between different module types. The Java Virtual Machine (JVM) uses the ClassLoader to locate and load Class objects into memory. By default, the SystemClassLoader will use the path information specified in the CLASSPATH environment variable to locate classes. It is also possible for an application to provide its own ClassLoader, a well-known example being the URLClassLoader used by the Servlet Engine to locate and initiate classes from a URL.

Depending on the implementation of the J2EE application server, there are at least 3 levels of ClassLoaders:

Figure 1. ClassLoader relationship

As illustrated in Figure 1, the application server is using the SystemClassLoader and it will only see resources on the system CLASSPATH. There is a separate ClassLoader within each EAR, RAR, and WAR module. The exact relationship of these ClassLoaders is not clearly defined, but typically there is a parent-child relationship between the 4 different ClassLoaders, whereby the child ClassLoader will be able to locate classes that are visible in the parent ClassLoader, but not vice versa. In the case of J2EE, the SystemClassLoader is the parent of all EAR Classloaders, where an EAR ClassLoader is the parent of the WAR, and RAR ClassLoader of the enclosing WAR and RAR files.

Figure 2. ClassLoader Parent-Child Relationship

According to the Java specification, a child ClassLoader must use its parent ClassLoader first to locate a class before it will attempt to locate the class itself. This may sound non-intuitive at first, but is necessary to prevent ambiguity and conflict when there are multiple ClassLoaders within the same JVM. Some application servers allow you the option to change the lookup behavior of the EAR or WAR ClassLoader, but this is not recommended, as it can lead to other types of problems (e.g., ClassCastException may occur if you have two versions of the same class in different ClassLoaders).

The visibility restrictions between the different ClassLoaders will affect the choices you can make when packaging a J2EE application, especially when dealing with resources and libraries.

2 Deployment Architecture

A typical Three-tier enterprise application is organized into three major tiers:

  • The presentation tier: this tier is responsible for managing the interaction with the end users.
  • The business logic tier: this tier usually acts as a server to serve requests made by the users in the presentation tier.
  • The data tier: this tier includes the database and any components that are responsible for managing the access to it.

In a large-scale enterprise solution, each tier will be deployed in separate domains to allow each domain to scaled differently based on business needs. In addition, load balancers may be deployed in front of the presentation tier to improve availability and support better fail-over. The business and data tiers tend to rely on clustering technology to provide fail-over support. The following diagram outlines the basic deployment architecture:

Figure 3. Typical Three-tier Deployment Architecture

Depending on the actual business use cases, there may be variations on the above architecture.

For a J2EE application, the presentation tier is usually handled through the use of servlets and JSPs, which can be packaged as one or more WAR files. The business tier is usually handled through the use of session beans (either stateless or stateful), which may be packaged as one or more EAR files. The data tier is usually handled through the use of entity beans (which control access to database resources) or a resource adapter (which controls access to legacy or non-JDBC resources), which may be packaged as one or more EAR files. The following diagram shows the same deployment architecture with specific J2EE resources and modules:

Figure 4. Java Enterprise Application Deployment Architecture

Deploying a J2EE application based on the above structure will provide the greatest flexibility, but there are other considerations that must come into play before the deployment architecture can be finalized.

Pages: 1, 2, 3

Next Pagearrow