Take a Tour of Web Tier Technologies
Use the latest J2EE 1.4 Web tier technologies to your advantage.
by Paul Philion

JavaOne, June 28, 2004

The Web tier has existed in Web-based applications since the introduction of the thin client. The move from the fat-client, two-tier enterprise application models (traditional client/server architecture) to Web-browser-based, thin-client n-tier application models required the introduction of a tier to handle the Web-based presentation logic distinct from the business logic in the middle tier.

The earliest Web tier implementations relied on dynamic HTML generation using server-side scripting languages such as Perl. Those prototypical applications were plagued with problems: They were inefficient (some required a new process per HTTP request); they didn't scale at all; they were tedious to test and debug; they were difficult to extend and enhance; and overall, they were maintenance nightmares.

Java's introduction with cross-platform portability and the Java servlet model, which streamlined browser-server (request-response) interactions, sparked a revolution in the Web tier. Since the servlet specification's introduction, we've seen multiple advances in Web tier technology, each extending the capabilities and effectiveness of the last. The release of the Java 2 Platform, Enterprise Edition (J2EE) 1.4 contains the latest versions of these technologies: servlets, JavaServer Pages (JSP), JavaServer Pages Standard Tag Library (JSTL), and JavaServer Faces (JSF).

J2EE Web tier technologies are the focus of numerous sessions at JavaOne this week. This article discusses those technologies and describes design patterns and guidelines for making the technologies work together.

J2EE Tiered Architecture
J2EE Web applications are usually broken into three distinct tiers: the business tier, the integration tier, and the Web tier. The business tier represents the business-level logic and coordinates the interactions between the components of the integration tier and the Web tier. The integration tier contains all the "back-end" systems: database systems, legacy systems, external services, and other enterprise integration systems (EISs). The Web tier contains the layer of software that interacts with users of the enterprise application (humans or other enterprise apps). The Web tier is also called the presentation tier, but because it has moved beyond rendering HTML for human users into XML and Web services, "Web tier" seems to better describe this tier's responsibilities.

The Java servlet model was the first J2EE Web tier technology introduced. It started the Web tier revolution by providing several powerful abstractions in an efficient request-response framework. The model is efficient because it separated the request processing from session handling based on the Strategy and Flyweight design patterns: The same instance of a servlet object can be used by many requests by many users, so a new instance of the servlet doesn't need to be created and initialized for each individual request. You accomplish this by storing the session data in a separate object in the servlet container.

Servlets provide a powerful framework for developing efficient Web-based applications, but they do little to assist in dynamic generation of HTML content. Web designers typically author HTML using completely different methods and tools from those used by Java developers. In the servlet model, the servlet implementation contains hardcoded strings of HTML markup. This requires both the servlet developer and the Web designer to work on the same file containing a mishmash of both Java source code and HTML markup.

Such servlet files are messy, a pain to work on, and difficult to maintain. Further, it is common to change the HTML in a Web application to provide an updated look and feel. Such HTML modification requires changes to servlet source code and the associated recompile, retest, and redeploy cycle.

JSP: Inside-Out Servlets
To address these problems, JavaServer Page (JSP) technology was introduced to simplify the generation of dynamic HTML content and allow Web designers to edit the HTML markup without writing Java code. JSP pages accomplish this by turning servlets "inside out": A servlet is Java code that contains HTML markup in hardcoded strings. A JSP page, on the other hand, contains predominantly HTML markup with some Java code (scriptlets) to control the dynamic presentation. Further, JSP pages are evaluated at run time, when the requested JSP page is translated into a servlet and then compiled and deployed automatically. This makes the JSP page much more flexible and quicker to develop and deploy than servlets.

Whereas JSP pages enable much more flexible Web-based presentation, they still require Java code (in the form of scriptlets) to provide dynamic user interface (UI) behavior and interactions with the business tier. This is the same problem, only inverted: Web designers are not Java developers, and should not be expected to add Java code to a Web page.

J2EE Web tier technologies advanced two ways to address these issues: JSP pages have been extended to provide dynamic behavior without using scriptlets. Further, the roles of JSP pages and servlets in the Web tier have been formalized to define standard interactions between the Web browsers, servlets, JSP pages, and the business tier.

The necessity for scriptlets in JSP files poses a problem for a traditional Web developer because they are pieces of Java code with the associated overhead. A Web designer, graphic artist, or UI expert should not be concerned with Java syntax or how to import a Java package. Instead of a Web developer writing Java code, or a Java developer working on the same JSP file, a better solution is to use JSP technologies that provide the necessary dynamic behavior without the use of any Java code. These technologies include the tag library framework (taglibs) in JSP, the JSP Standard Tag Library, and the JSP Expression Language, introduced in JSP 2.0.

Tag Library Framework
The JSP tag library framework lets you add custom tags (special JSP-specific markup) to a JSP page. A Java developer can define specific dynamic behavior in a taglib by extending the right classes and implementing the appropriate callbacks, and provide that taglib to a Web designer. The Web designer can use the behavior by adding the appropriate tags to the JSP page, which invokes the taglib when the JSP page is evaluated. This provides a wide range of dynamic behavior without exposing the Web designer to Java code or requiring scriptlets in the JSP file.

Taglibs allow true separation between the roles of Web designers and Java developers, but they don't really make things much easier. The taglib framework is complex and difficult to implement. Also, many trivial tags (such as simple iteration) must be implemented for every project.

The JSP community has addressed this by developing numerous tag library collections of standard tag sets, and the Java Community Process (JCP) has formalized a standard tag library. The JSP Standard Tag Library (JSTL) is a set of simple tags to address the core needs of most Web applications. JSTL provides conditional processing, iteration, XML handling, internationalization, and SQL interaction. With JSTL, a Web developer is able to implement complex dynamic behavior in a JSP without touching Java code.

In some cases, dynamic behavior is required beyond that provided in the standard tag libraries. To address the underlying taglib complexity problem, JSP 2.0 introduced the SimpleTag and SimpleTagSupport classes to make developing custom taglibs easier.

JSP Expression Language
The JSP Expression Language (EL) provides access to data stored in Java objects using a simple syntax. Before EL, a Web designer had to use scriptlet expressions that invoked Java methods to display those values. EL simplifies that process by using a simple syntax to access object values. For example, a scriptlet expression might look like this:

  <%= session.getAttribute("profile").getName() %>

The EL for the same thing would look like this:

  ${sessionScope.profile.name}

EL also provides access to Java arrays and maps as well as logical, mathematic, and string operations. You can use EL expressions together with tags (both standard and custom) to provide a wide range of dynamic behavior in a JSP page without touching Java code. This cleanly separates the roles of the Web designer and the Java Web component developer.

Because of the dynamic capabilities of JSTL and EL, JSP 2.0 provides a means to disallow scriptlets and other scripting elements in a JSP file. This is useful because it forces the separation of HTML/JSP markup from Java code and makes the Web application easier to develop, test, and maintain.

To turn off scripting elements in all JSP pages, place this code in the web.xml for the Web application:

   <jsp-property-group>
       <url-pattern>*.jsp</url-pattern>
       <scripting-invalid>true</scripting-invalid>
   </jsp-property-group>

Moving to Model-View-Controller
While taglibs and EL provide control over a Web application's presentation and replace much of what scriptlets provided in a JSP page, the overall dynamic behavior of a Web application still requires Java code: A JSP page does a good job providing the presentation of specific information, but a servlet does a better job of controlling the application behavior and interactions with the business tier.

A classic approach to this applies the Model-View-Controller (MVC) design pattern to the Web tier. In the MVC pattern, the responsibilities for presentation and application control are separated. The view component displays the underlying information in a flexible manner. In the J2EE Web tier, one or more JSP pages represent the view. The controller component accepts requests from the user and updates the information and the state of the application. Servlets fill this role nicely. Finally, the model component stores all the data associated with the Web application, which the view displays and the controller updates. In a J2EE Web application, the model is effectively the entire business tier, but is really only accessed through a specific set of interfaces, following the Business Delegate design pattern.

This specific application of the MVC design pattern to the J2EE Web tier is traditionally called the Model 2 architecture. In Model 2, an end user, using a Web browser, makes a request to the system (see Figure 1). A servlet (the controller) processes the request, performs operations on the business tier (the model), and then forwards control to a JSP page (the view). The JSP page accesses the updated information in the business tier and renders the response to the original request.

The Model 2 architecture speeds and simplifies development of robust, easy-to-maintain Web applications. The clean separation of presentation from business logic and application control allows you to add many views to the same application: Model 2 can support new types of clients (fat clients, voice clients, Web services, and mobile/micro clients) with little additional code and testing. The centralization of control (in the controller, following the Front Controller design pattern) allows you to handle application-wide behavior (security and logging) from a single place, instead of spreading the code across every JSP page in the application. Further, you can easily extend that central controller to add new or custom behavior to the Web application without impacting the presentation or business tier.

JavaServer Faces
The formalized Model 2 architecture is the foundation for the JavaServer Faces (JSF) architecture. JSF takes the next logical step and provides a robust server-side UI framework for Web applications, based on servlets and JSP. Like the Swing API in the Java 2 Platform, Standard Edition (J2SE), JSF takes a component-based approach to Web application user interfaces.

As part of this model, JSF introduces a set of Web-based UI components. These are represented by custom tags in a JSP page (outputText, graphicImage, inputText, and commandButton), and by UI components in the JSF API (UIOutput, UIGraphic, UIInput, and UICommand). JSF also provides the "glue" that ties user actions in the browser to UI events in the JSF framework. This allows standard listeners to be written in Java. For example, the ActionListener listens for when commandButton is pressed.

The component and event models in JSF offer an even greater level of separation between the presentation (look and feel) of a Web application and the underlying behavior. Changing the presentation in a JSF-based UI entails simply updating the HTML markup in a JSP page, whereas adding new behavior requires implementing and adding a new event listener in Java. Further, as JSF matures, more and more standard JSF components will be available, similar to the wide variety of available Swing API-based components. These components will help usher in a new level of reuse in the Web tier.

Take a look at a JSP page that uses the JSF framework, taken from Sun Microsystems' J2EE 1.4 Tutorial (see Listing 1 and Resources). In it, you can see a simple form (form) that contains some text (outputText), an image (graphicImage), an input field (inputText), and a button to submit the input to the server (commandButton).

The JSP listing also demonstrates the use of automated validation in JSF. The validateLongRange tag in the inputText component tells JSF to make sure the value in the field is between the minimum and maximum values. In this case, those values are expressions—the same expressions used to display the minimum and maximum field values earlier in the JSP page. Also note that JSF uses different scripting markup than the JSP 2.0 EL (#{UserNumberBean.minimum} in JSF vs. ${UserNumberBean.minimum} in JSP). Hopefully, this will be reconciled in the next release of JSF.

Web Tier Wrapup
The J2EE 1.4 Web tier technologies have matured immensely since the original introduction of the servlet framework. Whether you develop a Web application based on JSF or follow the Model 2 architecture to build a custom Web application from scratch using servlets and JSP, you should keep several general guidelines in mind:

• Avoid HTML markup in servlets and use JSP pages for presentation.
• Disable scriptlets and use EL and standard taglibs (JSTL) in JSP pages.
• Use servlets to control interaction with the business tier, following the Business Delegate pattern.
• Use a servlet to determine which view (JSP page) should display information, following the Dispatcher View pattern.
• Centralize application-wide behavior to allow extension and maintenance, following the Front Controller pattern.

Together, these simple guidelines will help you develop robust Web applications without introducing maintenance and debugging nightmares.

For more details about Web tier components, read "Delve Into Web Tier Components."

About the Author
Paul Philion has been developing in Java professionally since JDK 1.0a2. He is a Sun-certified Java programmer, developer, architect, and Web component developer. He is the principal architect at Acme Rocket Company, where he designs enterprise systems, tinkers with new technologies, and expresses his opinions (loudly).