Advanced JavaServer Pages

Chapter 5. DESIGN
Topics in this Chapter

• Model 1
• Model 2: An MVC Approach
• A Model 2 Example
- The Beans
- The Deployment Descriptor
- Successful Login Use Case
- Creating a New Account
• Conclusion

Developing web pages in HTML is easy. Designing flexible and maintainable web
applications that combine HTML, JSP, and Java and access databases or legacy systems is
not. This chapter provides insights into the use of JSP, beans, and servlets the latter by
examining some common approaches to web application design.

The authors of the JSP specification designed JSP to be flexible. You can implement JSP-
based web applications in many ways; for example, you can approach the project as follows:

• Freely mix HTML and JSP scriptlets

• Delegate functionality to Java beans
• Use servlets, JSP pages, and Java beans to implement a Model-View-Controller
(MVC) architecture

The first approach listed above —mixing copious amounts of Java code with HTML in JSP
pages—leads to applications that are difficult to maintain and extend, and therefore is not
recommended.

Delegating functionality to Java beans is a viable approach because it moves Java code from
JSP pages to beans. This approach was first advocated in the 0.91 version of the JSP
specification,1 and is commonly known as the Model 1 architecture.

The last approach listed above —combining servlets, JSP pages, and Java beans in an MVC
architecture—results in extensible and maintainable software because it encapsulates
functionality and reduces the impact of change. This approach was also first advocated in the
0.91 JSP specification and is known as the Model 2 architecture.

This chapter begins with a brief discussion of the Model 1 architecture, followed by
an in-depth examination of Model 2. In Chapter 6, Then we extend turn our attention to
extending Model 2 with a framework that facilitates implementing Model 2 applications.

Model 1

The Model 1 architecture consists of JSP pages, Java beans, and business objects, as depicted
in Figure 5-1.

1
You can download the 0.91 and 0.92 JSP specifications from http://www.kirkdorffer.com/jspspecs.

112
 Advanced JavaServer Pages

Figure 5-1. Model 1 Architecture: JSP Page, Java Beans, and Business Objects

The Model 1 architecture submits requests to JSP pages, which indirectly access business
objects through Java beans. This indirect access insulates JSP pages from business object
changes—which are typically frequent, especially for large projects—because those changes
are dealt with by beans. As long as bean interfaces remain constant, JSP pages are
independent of business object implementations.

Software developers implement the business objects and the beans. Ideally, web page authors
would be responsible for JSP pages, resulting in a division of labor where business objects
and web pages are developed in parallel by developers with different skill sets. That division
of labor is difficult to achieve with the Model 1 architecture because JSP pages are
responsible for content generation, which nearly always requires Java code, in addition to
content presentation.

Because a division of labor between web page authors and software developers is difficult to
achieve with the Model 1 architecture, that approach is only appropriate for small projects
with a few developers, all of whom are fluent in Java, JSP, and HTML or XML.

For large projects, it's imperative to maintain a division of labor between web page authors
and software developers. For those projects, a different approach must be taken. Most often,
that approach is the Model 2 architecture.

JSP Tip

Model 1 Pros and Cons

The Model 1 architecture reduces dependencies between JSP pages and business objects,
allowing web pages and business objects to be developed in parallel.

But with the Model 1 architecture, software developers are typically involved in the
development of both web pages and business objects. That makes it difficult to achieve a
division of labor where web page authors implement web pages and software developers
provide underlying functionality. Such a division of labor is often crucial for large
projects.

113
 Advanced JavaServer Pages

Model 2: An MVC Approach

The Model 2 architecture, like Model 1, separates business objects from JSP pages, as is
essential which is a necessity for most web development projects where business objects are
in a constant state of flux. Additionally, Model 2, illustrated in Figure 5-2, separates content
generation from content presentation.

Figure 5-2. The Original Model 2 Architecture: An MVC Approach

The Model 2 architecture submits requests to a servlet, which accesses business objects to
create content. That content is stored in a Java bean, which is accessed by a JSP page. That
JSP page subsequently presents the content, typically in HTML.

Separating content generation from presentation is beneficial because Java code, for the most
part, is restricted to content generation.2 This encapsulation of Java code lets software
developers concentrate on servlets and business objects and lets web page authors focus on
corresponding JSP pages.

Model 2 is an MVC architecture, where business objects represent the model (data), servlets
represent controllers (which handle requests), and JSP pages are views of the model.
The MVC architecture, which originated in Smalltalk back in the stone age of computing, has
stood the test of time because it separates business and presentation logic. That separation
allows for pluggable components, resulting in flexible, reusable, and adaptable software.

Note

The Model 2 architecture is actually a modified MVC implementation because its model
does not fire events to its views. That modification evolved because web applications
typically do not display more than one view of their model at a time.

2
Java code in the presentation layer is easily replaced by custom tags; see “The Importance of Custom Tags”

114
 Advanced JavaServer Pages

JSP Tip

The Benefits of MVC

The MVC architecture has long been the foundation upon which Smalltalk applications are
built, and for good reason.

The most fundamental aspect of object-oriented development is identifying abstractions

and encapsulating them in classes. For example, a payroll application would identify
abstractions such as employees, salaries, etc. Encapsulating abstractions in classes allows
for loose coupling between objects, thereby reducing which reduces dependencies and
increasing increases flexibility and reuse.

MVC encapsulates three general abstractions that are present in most graphical
applications: models, views, and controllers. By encapsulating what other architectures
intertwine, MVC applications are much more flexible and reusable than their traditional
counterparts.

A Model 2 Example

This section discusses the implementation of a familiar web application: login and
registration. The application is implemented with the Model 2 architecture and consists of two
servlets—one for login and another for creating a new account— two Java beans, one custom
tag, and six 6 JSP pages, as shown in Figure 5-3. The application also includes a deployment
descriptor (/WEB-INF/web.xml), which defines servlet mappings, and a tag library descriptor3
(/WEB-INF/tlds/utilties.tld) that defines the application's lone custom tag.

3
See Defining Custom Tags—The TLD

115