Web Tier Design

Although J2EE allows for different client types, web apps are the most important in practice. Today even many intranet apps use web interfaces. The four architectures discussed above do not differ in the design of their web interfaces, but in the manner that they implement and access business logic. The following discussion of web interface design applies to all four architectures. The web tier is responsible for translating gestures and displays understood by users to and from operations understood by the app's business objects.


It's important that the web tier is a distinct layer that sits on the middle-tier business interfaces. This ensures that the web tier can be modified without altering business objects and that business objects can be tested without reference to the web tier.

In a web app, the web tier is likely to be the part subjected to the most frequent change. Many factors, such as branding changes, the whims of senior management, user feedback, or changes in business strategy, may drive significant modifications in a web site's look and feel. This makes designing the web tier a major challenge. The key to ensuring that the web tier is responsive to change is to ensure a clean separation between presentation on the one hand, and control logic and access to business objects on the other. This means making sure that each component focuses either on markup generation or processing user actions and interacting with business objects.

The Model View Controller (MVC) Architectural Pattern

A proven way of achieving separation between presentation and logic is to apply the MVC architectural pattern to web apps. The MVC architecture was first documented for Smalltalk user interfaces, and has been one of the most successful OO architectural patterns. It is also the basis of Java's Swing interface packages. MVC divides the components needed to build a user interface into three kinds of object, ensuring clean separation of concerns:

We'll discuss the design of the web tier in detail in , but let's take a look at how a variant of the MVC pattern can be implemented in J2EE. In J2EE apps, the web tier will be based on servlets. JSP pages and other presentational technologies such as XSLT will be used to render content. A typical implementation involves having a standard controller servlet as a single point of entry into an entire app or subset of app URLs. This entry point chooses one of multiple app-specific request controllers to handle the request. (The mappings will be defined in configuration, outside Java code.) The controller servlet is effectively a controller of controllers. There's no standard term for what I call a "request controller" – the Struts web app framework calls such delegates actions. A request controller or action corresponds to the controller in the MVC triad. It produces no output itself but processes requests, initiates business operations, optionally manipulates session and app state, and redirects requests to the appropriate view, where it exposes a model resulting from its processing. Model, view, and controller objects map onto J2EE components as follows:

Each component type is used to its strengths; Java classes (request controllers) handle logic, not presentation, while JSP pages focus on generating markup. The following sequence diagram illustrates the flow of control. The controller servlet will be a standard class provided by a framework such as Struts (there is seldom any need to implement an MVC framework in house, since many implementations are available as open source). The request controller is part of the app's UI tier, and uses the business interface, as part of the middle tier in each of our four architectures. The view might be a JSP page:

Java Click To expand

The sequence diagram overleaf shows the use of the Command design pattern, which encapsulates requests to a subsystem as objects. In J2EE web apps, the Command design pattern promotes clean connectivity between web tier and middle tier through non web-specific command objects. In this example, command objects are created to encapsulate the information contained in HTTP requests, but the same command objects could also be used with other user interfaces without any impact on business objects.


Readers familiar with the "Core J2EE Patterns" will note that I've described the Service-to-Worker presentation tier pattern. I don't recommend the Dispatcher View pattern, which allows data retrieval to be initiated by views. I discuss the drawbacks of this approach in .

Systems built using the MVC approach tend to be flexible and extensible. Since presentation is separated from logic, it's possible to change an app's presentation significantly without affecting its behavior. It's even possible to switch from one view technology to another (for example, from JSP to XSLT) without significant change to app logic.


Use the MVC architectural pattern in the web tier. Use a web app framework such as Struts to provide a standard implementation of the MVC pattern, minimizing the amount of app code you will need to write.

Connectivity Between the Web Tier and Business Objects

It's vital that the web-tier is cleanly separated from business objects. While the MVC pattern results in a clean separation between web-tier controllers and presentation objects (which hold formatting), it's no less important to separate web tier controllers (which are still tied to the Servlet API) from business objects (which are interface-agnostic). In later chapters we look at infrastructure that promotes good practice in this respect. For now, let's consider the key goals:


In a well-designed J2EE web app, the web tier will be very thin. It will only contain code that's necessary to invoke middle-tier business interfaces on user actions and to display the results.