CONTENTS | PREV | NEXT | INDEX Designing Enterprise Applications
with the J2EE Platform, Second Edition

11.1 J2EE Architecture Approaches

Before delving into the design and architecture of the sample application, it is important to understand some commonly used J2EE architectural approaches. J2EE applications that are interactive benefit from using the Model-View-Controller (MVC) architecture. MVC is particularly well-suited for interactive Web applications--applications where a Web user interacts with a Web site, with multiple iterations of screen page displays and multiple round-trips of requesting and displaying data.

In contrast, a workflow architecture is more suitable for applications that focus on process control and have fewer interactive features. Such applications may use asynchronous messaging, implemented with message-driven beans and JMS, so that different processing steps in the workflow can communicate.

In addition to the architecture, J2EE design patterns help to determine well-formed application designs.

11.1.1 Model-View-Controller Architecture

The Model-View-Controller architecture is a widely-used architectural approach for interactive applications. It divides functionality among objects involved in maintaining and presenting data to minimize the degree of coupling between the objects. The architecture maps traditional application tasks--input, processing, and output--to the graphical user interaction model. They also map into the domain of multitier Web-based enterprise applications.

The MVC architecture divides applications into three layers--model, view, and controller--and decouples their respective responsibilities. Each layer handles specific tasks and has specific responsibilities to the other areas.

Figure 11.1 depicts the relationships between the model, view, and controller layers of an MVC application.

Figure 11.1 The Model-View-Controller Architecture

Separating responsibilities among model, view, and controller objects reduces code duplication and makes applications easier to maintain. It also makes handling data easier, whether adding new data sources or changing data presentation, because business logic is kept separate from data. It is easier to support new client types, because it is not necessary to change the business logic with the addition of each new type of client.

11.1.2 J2EE Design Patterns

A design pattern describes a proven solution to a recurring design problem. Design patterns leverage the knowledge and insights of other developers. They are reusable solutions for common problems. Design patterns address individual problems, but they can be combined in different ways to achieve a solution for an entire system. Because design patterns can be named, they become part of the architect's vocabulary for describing a solution.

There are a common set of design patterns for the J2EE platform. This section briefly mentions those J2EE design patterns that apply to the sample application. Later, you will see how these patterns are combined and used in the application architecture. Refer to Section 11.6 on page 383 for references to sources of more information on patterns. In particular, you should refer to Core J2EE Patterns, by Alur, Crupi, and Malks, as that book gives a complete description of all the J2EE patterns.

When deciding on a pattern to use, keep in mind that certain patterns are more applicable to a particular application tier. For example, patterns related to views and presentation are applied in the Web tier. Good examples of Web tier patterns are composite view and view helper. Other patterns are more concerned with controlling business logic, and they are more useful in the EJB tier. Session facade is a good example of an EJB tier pattern. Other patterns focus on retrieving data or delegating operations, and they are best applied between tiers. The value object and business delegate patterns fall into this category.

Copyright © 2002 Sun Microsystems, Inc. All Rights Reserved.