When JSPs were first introduced, the specifications distinguished the uses of JSPs from servlets by defining two model architectures. Recent specifications have dropped the topic, leaving it (more appropriately) to the J2EE blueprint to define. The models are still useful, so we'll take a few minutes to review them.

The Parts of the J2EE Standard

A Java 2 Enterprise Edition (J2EE) release is made up of several components. First, there are the constituent specifications, which include the JSP and servlet specifications. Then, there are reference implementations; Tomcat is the reference implementation for the JSP and servlet specifications. Finally, there is a blueprint, which defines the J2EE architecture and provides guidelines for the use of the technologies that compose J2EE. The J2EE blueprint is available online at http://java.sun.com/blueprints/.

In the Model 1 architecture, JSPs accept client requests, decide which actions to take next, and present the results. JSPs work with JavaBeans or other services to affect business objects and generate the content. The important thing to remember about this model is that a JSP always remains in control of the application. Figure 20.1 illustrates a Model 1 architecture.

Unfortunately, this almost always means that the JSP has a considerable amount of business logic in it, usually in the form of scriptlets littered throughout the page. In most implementations, it's a complex document that rarely meets the objectives presented earlier this hour.

Consider Your Architectural Requirements

A Model 1 architecture can be successful. You can reduce the complexity by using tags and EL, thereby making it easier to create and maintain. Custom tags can encapsulate most functionality that is sophisticated enough to require Java. You may find that a Model 1 architecture is just right for your needs.

In the Model 2 architecture, a servlet accepts a client request, handles the processing, and then forwards to a JSP for presentation. In this architecture, the servlet can access the business objects, obtain the information that needs to be displayed, and pass it along to a JSP that is dedicated to presentation. It's quite easy to keep the business logic in the servlet (and Java code for that matter) and use JSPs strictly for presentation. The view of the information will be constructed using directives and standard and custom actions. For the really tough presentation problems, EL is there to help. Figure 20.2 depicts the Model 2 architecture.

Using the Model 2 architecture helps partition functionality and results in reduced coupling between components, making the application flexible and easier to maintain. Let's look at a successful Model 2 architecture in more detail.

The Model 1 and Model 2 Architectures

Figure 20.1. The structure of a Model 1 architecture is shown here.

Figure 20.2. The structure of a Model 2 architecture is shown here.