Introduction

The J2EE platform supports the development and deployment of a variety of standard deployment configurations. It is such standard deployment configurations that take a lot of the guesswork out of application development. In the following sections, you'll find descriptions of the most common deployment configurations, and the pros and cons of each.

If you're not already familiar with the J2EE concepts, see those described in Java 2 Platform Enterprise Edition (J2EE) Overview before going further.

Standalone Deployment Configuration

The first deployment configuration is shown in Figure 1. In this configuration, there is neither a Web container nor an EJB container-a client accesses EIS resources directly, and is responsible for handling any presentation logic, business logic, and integration logic itself.

Figure 1: Standalone Deployment Configuration

At first glance, this configuration might seem like an attractive proposition for applications that provide simple manipulation of data held in the EIS resources. However, this configuration has a number of potential drawbacks.

Changes to EIS resources can have a major impact on the implementation of the application, which is often directly dependent on the internal structure of each EIS resource, such as the structure of database tables. Any change to the application itself requires a complete rollout to every user-there is no central server where the application is deployed so that clients have immediate access to the latest fixes.

Also, this deployment configuration does not encourage a division of responsibility. For example, it's often the case that presentation logic and business logic are tightly coupled, making it difficult to support application evolution and maintenance.

The real issues with this deployment configuration, however, start to surface when you decide to scale your application. Client workstations have limited performance characteristics so, ideally, you should distribute processing across a number of machines. However, the standalone configuration isn?t designed to support distributed processing. Also, when you attempt to support more clients accessing EIS resources concurrently, you might find that your applications are constrained by the EIS resource itself, such as the number of concurrent database connections.

EJB-centric Deployment Configuration

The EJB-centric deployment configuration is shown in Figure 2. In this configuration, an EJB container sits between the client container and the EIS resources-there is no Web container. The presentation logic is in the client, with business logic residing in EJBs. Rather than accessing EIS resources directly, all requests from the clients are managed by the appropriate EJBs. Clients are, therefore, shielded from changes in EIS resources.

Figure 2: EJB-centric Deployment Configuration

The EJB-centric deployment configuration is designed to address many of the issues present in the standalone deployment configuration. From a scalability perspective, the J2EE platform implementation can distribute processing across a number of machines. Also, an EJB container is responsible for ensuring efficient use of limited resources, such as database connections. From an application evolution and maintenance perspective, this configuration also encourages a separation of presentation logic and business logic.

However, one of the drawbacks of the EJB-centric deployment configuration is that even minor changes to the user interface require a complete rollout of the application to every user. Even though the business logic encapsulated in EJBs can be redeployed on the server (thereby giving users immediate access to any changes), this is not true of the presentation logic. This is unfortunate, as the look and feel of an application could undergo frequent changes.

Web-centric Deployment Configuration

The Web-centric deployment configuration is shown in Figure 3. In this configuration, a Web container sits between the client container and the EIS resources-there is no EJB container. Both presentation logic and business logic are handled by elements in the Web container (JSPs and servlets). In this configuration, a simple markup language is used in the client, such as HTML, although this equally could be XML or WML.

Figure 3: Web-centric Deployment Configuration

Typically a Web-centric deployment configuration results in an emphasis on supporting the look and feel of the resulting application, with less emphasis on supporting the business logic. Such a configuration supports frequent changes to the look of an application and is in wide use today.

A Web-centric deployment configuration provides a number of benefits. First, clients aren?t impacted by changes to EIS resources, since clients don?t access these resources directly. Second, it's possible to redeploy the entire application without requiring any rollout to users, since the application resides wholly on a server.

However, while the use of EJBs is sometimes considered to be overkill for the job at hand, the omission of EJBs results in some of the issues raised for the standalone deployment configuration. Specifically, this configuration does not encourage a clear division of responsibility between presentation logic and business logic, often resulting in tightly coupled elements that impede application evolution and maintenance. Also, all of the scalability issues present in a standalone deployment configuration apply to a Web-centric architecture.

Multi-tier Deployment Configuration

The multi-tier deployment configuration is shown in Figure 4. This configuration includes both a Web container and an EJB container, and it exhibits all of the benefits discussed for the other deployment configurations with none of the drawbacks. Presentation logic is handled by elements in the Web container, with business logic handled by EJBs in the EJB container.

Figure 4: Multi-tier Deployment Configuration

Clients aren?t impacted by changes to EIS resources because these resources aren?t accessed directly. Also, it's possible to redeploy the entire application without requiring any rollout to users, since the application resides wholly on the server.

From a scalability perspective, processing can be distributed to support concurrent processing. Also from a scalability perspective, the EJB container is responsible for ensuring efficient use of limited resources, such as database connections.

From an application evolution and maintenance perspective, this configuration also encourages a clean separation of responsibilities. The presentation logic is decoupled from EIS resources, and the business logic is decoupled from the look and feel. This clean separation can aid allocation of work to differently skilled developers, and presentation logic and business logic can be developed concurrently.

The multi-tier deployment configuration can also ease the migration from one client device (such as a Web browser) to another (such as a PDA). A complete rewrite of the application isn?t required because the business logic encapsulated in EJBs remains unchanged and can be used as-is.

To summarize, there are a number of deployment configurations, each with its pros and cons. One of the objectives of the J2EE platform is to be flexible enough to support whatever deployment configuration is deemed appropriate for an organization, at the same time addressing the enterprise concerns.