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.
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
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.
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.
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.
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
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
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.