Architecture Key Concepts

Before embarking on a discussion of presentation requirements and architecture drivers, we need to step back and review some key concepts related to J2EE architecture.

J2EE Application Tiers

The J2EE specification and related documentation from Sun describe the J2EE platform as a distributed application environment organized in three tiers: client, business, and enterprise information systems (EIS) or data. Although this is a useful organization, it lumps all of the application-server-hosted components in the business tier. It is more common to break up this middle tier into two separate tiers, presentation and business, containing presentation-related components and business-related components, respectively. This organization is depicted in Figure 2.1.

Figure 2.1:  J2EE application tiers.

A related rule of thumb states that a component in a given tier may communicate directly only with components in adjacent tiers. JSP pages may not access the database directly, for example. Presentation-tier components must request information from components in the business tier, which then request data from the database or other data-tier systems as required. The advantages of this approach include the flexibility to leverage the same business components across multiple presentation-tier components and the reduction in coupling between nonadjacent layers .

There is nothing particularly new or revolutionary about organizing components in tiers. Three-tier and n -tier client/server technologies have followed this model for years , and even so-called two-tier systems often had stored procedures and other middle-tier business services. The benefits of organizing components in tiers or layers are well known and accepted in the industry, but this layered organization hardly defines an application architecture.

Model-View-Controller Architecture

One design pattern often cited as a Web application architecture is the model- view-controller (MVC) pattern. This pattern has its roots in the Smalltalk world, where applications often use sophisticated techniques for viewing business information (the model) using interfaces (views) that are updated and managed automatically by controller objects whenever business objects change state.

When architects discuss the model-view-controller pattern today, they usually mean a watered-down version of the original. Essentially, the MVC pattern has become another layered architecture, where view components must interact with a controller component to gain access to model data. As shown in Figure 2.2, the J2EE technologies have shuffled around a bit, but the left-to-right interactions implicit in a tiered architecture are still present.

Figure 2.2:  J2EE components mapped to MVC pattern.

There is more to the model-view-controller pattern than simply layering components and mandating left-to-right communication paths, of course. The MVC design pattern also commonly defines an approach for important presentation-tier behaviors such as defining navigational flow through the site and processing HTML form submissions.

Common J2EE Design Patterns

The J2EE architectural community has begun to rally around a number of important design patterns based on the seminal work on design patterns presented in Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (Addison-Wesley, 1995) and more recent books such as Core J2EE Patterns: Best Practices and Design Strategies by Deepak Alur, John Crupi, and Dan Malks (Prentice Hall PTR, 2001) and EJB Design Patterns: Advanced Patterns, Processes, and Idioms by Floyd Marinescu (John Wiley & Sons, 2002). Patterns such as the session fa §ade and value object are so prevalent now in application design that they have become, in a sense, part of the J2EE platform. Every J2EE architect should read these works and be well versed in the advantages and disadvantages of each design pattern before sitting down to architect a system.

There are still some rough edges in these common J2EE design patterns, however. Often they tackle problems individually, leaving the proper combination of many different (and possibly conflicting) patterns as an exercise for the architect. Some of the patterns introduce additional layers in the architecture, ostensibly to reduce coupling between the layers already defined. We wonder how much decoupling is truly advantageous to the development and maintenance effort taken as a whole. By the time you implement the business delegate , service locater , session fa §ade , value object assembler , and composite entity patterns in the business tier, for example, the resulting system may not be an improvement over the starting point.

The J2EE community has not yet reached the point where complete, end-to-end architectures incorporating a select set of well- understood design patterns are documented and available for new architectural efforts. We hope to address this deficiency in some small way in this chapter and subsequent chapters on EJB architecture by presenting complete, realistic example applications employing a consistent set of J2EE design patterns. The success or failure of your WebLogic project may depend more on the proper selection of architecture than on any other decision you make during development, so take the time to understand the issues involved before you start designing or coding.

Now that we have discussed some basic concepts related to Web application architecture, it is time to dig in and discuss the issues that drive presentation-tier architecture design decisions.