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.

• A model represents business data and business logic or operations that govern access and modification of this business data. Often the model serves as a software approximation to real-world functionality. The model notifies views when it changes and provides the ability for the view to query the model about its state. It also provides the ability for the controller to access application functionality encapsulated by the model.
• A view renders the contents of a model. It accesses data from the model and specifies how that data should be presented. It updates data presentation when the model changes. A view also forwards user input to a controller.
• A controller defines application behavior. It dispatches user requests and selects views for presentation. It interprets user inputs and maps them into actions to be performed by the model. In a stand-alone GUI client, user inputs include button clicks and menu selections. In a Web application, they are HTTP GET and POST requests to the Web tier. A controller selects the next view to display based on the user interactions and the outcome of the model operations. An application typically has one controller for each set of related functionality. Some applications use a separate controller for each client type, because view interaction and selection often vary between client types.

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.

• Intercepting filter--This pattern applies to request pre- and post-processing. It applies additional services needed to process a request. For example, an intercepting filter such as a servlet filter may handle all incoming requests to the Web site and provide a central mechanism for authorization.
• View helper--A view helper encapsulates the presentation and data access logic portions of a view, thus refining the view and keeping it simpler. Presentation logic concerns formatting data for display on a page, while data access logic involves retrieving data. View helpers are often JSP tags for rendering or representing data and JavaBeans for retrieving data.
• Composite view--This pattern makes view presentation more manageable by creating a template to handle common page elements for a view. Often, Web pages contain a combination of dynamic content and static elements, such as a header, footer, logo, background, and so forth. The dynamic portion is particular to a page, but the static elements are the same on every page. The composite view template captures the common features.
• Front controller--This pattern provides a centralized controller for managing requests. A front controller receives all incoming client requests, forwards each request to an appropriate request handler, and presents an appropriate response to the client.
• Value object--This pattern facilitates data exchange between tiers (usually the Web and EJB tiers) by reducing the cost of distributed communication. In one remote call, a single value object can be used to retrieve a set of related data, which then is available locally to the client. See Chapter 5 for more information on value objects.
• Session facade--This pattern coordinates operations between cooperating business objects, unifying application functions into a single, simplified interface for presentation to the calling code. It encapsulates and hides the complexity of classes that must cooperate in specific, possibly complex ways, and isolates its callers from business object implementation changes. A session facade, usually implemented as a session bean, hides the interactions of underlying enterprise beans.
• Business delegate--This pattern intervenes between a remote business object and its client, adapting the business object's interface to a friendlier interface for the client. It decouples the Web tier presentation logic from the EJB tier by providing a facade or proxy to the EJB tier services. The delegate takes care of lower-level details, such as looking up remote objects and handling remote exceptions, and may perform performance optimizations, such as caching data retrieved from remote objects to reduce the number of remote calls.
• Data access object--This pattern abstracts data access logic to specific resources. It separates the interfaces to a systems resource from the underlying strategy used to access that resource. By encapsulating data access calls, data access objects facilitate adapting data access to different schemas or database types. See Chapters 5 and 6 for more information on data access objects.

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.