J2EE Web Tier Technologies

Simon Brown, January 2003

Abstract

This article, the second in a series, looks at the web technologies that are a part of the Java 2 Enterprise Edition. Specifically, it provides a brief tour of Java Servlets and JavaServer Pages, highlighting the key differences between the two technologies and how they fit into the larger J2EE platform.

Introduction

In the first article in the series, we started to take a look at the Java 2 Enterprise Edition (J2EE) by introducing what it is, what it can be used for and how to get started building applications. This article sees the start of our tour where weíll be taking a closer look at the technologies that make up the J2EE platform.

We saw last time that J2EE is a platform for building distributed, component based applications, although we didnít really mention that there are a number of ways in which this functionality can be exposed and delivered to the end user - be it a human or an automated user. Examples here include a traditional desktop GUI application, a web service, an application running on a mobile phone/PDA or, more commonly, a web-based browser interface. J2EE provides two technologies for building web based applications - Java Servlets and JavaServer Pages (JSP).

What are Java Servlets?

One of the first ways in which dynamic behaviour was implemented on the web was with CGI scripts. These small programs (usually written in languages such as C, C++, Perl and UNIX shell scripts) would take a HTTP request (e.g. from a web browser), process it in some way and return the results back to the user. Typically, the sort of functionality that they provided was to process information submitted by users using a HTML form, or to dynamically generate content for presentation to the user by embedding markup language (e.g. HTML) inside the CGI script. CGI was a great mechanism for addressing the needs of the fast moving web environment, although a couple of its weaker points were the integration with other technologies (e.g. databases) and the execution model since it typically spawned a new instance of the CGI script for each and every request. The latter of these potentially makes CGI unscalable and therefore restrictive for very large web sites.

Java Servlets was really the first true server-side Java technology and, at a high level, is simply the Java equivalent of CGI scripts. From an implementation perspective, servlets are simply Java classes that implement a predefined interface. The following example illustrates how to write a servlet that outputs an HTML page containing the current date, formatted in an appropriate way for the userís locale.

  package mypackage;

  import java.io.*;
  import java.text.*;
  import java.util.*;

  import javax.servlet.http.*;
  import javax.servlet.ServletException;

  public class DateServlet extends HttpServlet {

    protected void doGet(HttpServletRequest request, HttpServletResponse response)
      throws ServletException, IOException {

      // get a reference to the output writer
      PrintWriter out = response.getWriter();

      // get the locale of the client and create an appropriate date format
      Locale loc = request.getLocale();
      DateFormat df = DateFormat.getDateInstance(DateFormat.MEDIUM, loc);

      // and generate the page
      out.println("<html>");

      out.println("<head>");
      out.println("<title>The current date</title>");
      out.println("<link rel=\"stylesheet\" href=\"../page.css\">");
      out.println("</head>");

      out.println("<body>");
      out.println("<h1>The date is ");
      out.println(df.format(new Date()));
      out.println("</h1>");
      out.println("</body>");

      out.println("</html>");

      out.flush();
      out.close();
    }

  }

As this shows, servlets are fairly simple to build although even with this short example, a great deal of static content is embedded within the source code. However, servlets expand and improve on the concept of CGI because they address the two major issues that we mentioned earlier - integration and the execution model.

Where a new process will be created for each and every request in the CGI model, servlets are simply objects that run inside a container provided by a third party such as BEA, IBM and so on. Depending on which servlet container you use, there could be one or more instance of each servlet ready to service incoming requests, made possible by utilising Javaís threading model. For this reason, servlets are a much more scalable alternative to CGI scripts because rather than creating a new process to service a request, each request can be serviced by a different thread.

The other aspect that is greatly improved over the CGI model is that of integration. Since servlets are written in Java, they have access to the rich library of features provided by Java, including access to databases and other enterprise resources such as Enterprise JavaBeans (EJB). In essence, it is possible to achieve a great deal without ever leaving the Java environment.

What about JavaServer Pages?

We mentioned that there are in fact two web tier technologies within J2EE so letís look at the other. JavaServer Pages (JSP) is a technology for presenting information over the web and uses a paradigm where Java code is embedded into the HTML - the opposite of the approach taken with servlets where any static content is embedded within out.println() calls. From an implementation perspective, JSP is written as pages (e.g. HTML files) and can have embedded within them fragments of Java source code known as scriptlets. These scriptlets are a mechanism for adding dynamic behaviour into otherwise static content. A JSP version of the previous example is as follows.

  <html>
    <head>
      <title>The current date</title>
      <link rel="stylesheet" href="../page.css">
    </head>

    <%@ page import="java.text.*" %>
    <%@ page import="java.util.*" %>

    <body>
      <%
        // get the locale of the client and create an appropriate date format
        Locale loc = request.getLocale();
        DateFormat df = DateFormat.getDateInstance(DateFormat.MEDIUM, loc);
      %>
      <h1>The date is <%= df.format(new Date()) %></h1>
    </body>
  </html>

As this shows, JSP pages are really just static content (in this case HTML) with special tags and characters. In this example, first of all we have directives that specify something about the JSP page (<%@ ... %>), then we have scriptlets that contain regular Java code (<% ... %>) and finally we have expressions (<%= ... %>), the results of which get output to the page.

Doesnít mixing code and content lead to unmaintainable web applications?

One of the pitfalls in using JSP is that it is very easy to build large pages containing lots of embedded Java code and business logic. For this reason, JSPs provide easy integration with JavaBeans and another feature called JSP tag extensions, more commonly known as custom tags. These custom tags allow re-usable functionality to be encapsulated into XML-like tags that can be easily used on the pages by both page developers and designers. The example below illustrates how the functionality to format the date can be moved into, and reused as, a custom tag.

  <html>
    <head>
      <title>The current date</title>
      <link rel="stylesheet" href="../page.css">
    </head>

    <%@ taglib uri="/dateTaglib" prefix="date" %>

    <body>
      <h1>The date is <date:currentDate/></h1>
    </body>
  </html>

In this example, all of the Java code has been removed from the page and is now wrapped up and encapsulated as a reusable component. From an implementation perspective, custom tags are essentially just Java classes that again implement a specific interface. However, JSP 2.0 introduces the notion of building custom tags as fragments of JSP pages meaning that people that are not familiar with the Java programming language can also take advantage of custom tags to wrap up reusable functionality.

Building custom tags to represent common and recurring functionality is a great way to increase the maintainability of web applications while also making them easier to understand and read, particularly for page authors - those people that are focussed on the look and feel of an application rather than its functionality. After all, the amount of code on the page, mixed in with the content, is dramatically reduced.

Another good reason for using custom tags is that, through reuse, they can help decrease the time required to build web applications, and therefore decrease your time to market. There are currently many open source tag libraries (collections of custom tags) available to download from the Internet, and a good source of these is the Jakarta Taglibs project. Included in this collection of tag libraries is the JSP Standard Tag Library (JSTL) - an implementation of an initiative managed through the Java Community Process for the development of a standard tag library that can be used and reused for building JSP-based web applications. Essentially, JSTL contains a number of custom tags that help to solve many of the common problems encountered while building web applications, ranging from iterating over collections, delivering localized content and manipulating XML documents.

Why do we need Java Servlets and JSP?

On a final note, you may be wondering why we need both Java Servlets and JSP. After all, anything that can be done with servlets can be done with JSP and vice-versa, especially since behind the scenes a JSP is translated into a servlet the first time that it is requested. This is done automatically by the JSP container, and therefore all of the benefits around performance and scalability apply to JSPs too.

In reality, the answer to this question lies in how we use servlets and JSP pages, rather than any specific technical differences. Servlets are written in the same way as you would write regular Java classes and itís for this reason that they are more suited to delivering content that is easy to generate programmatically. In other words, servlets are useful where there is more code (logic) than content (for example HTML). JSPs are more useful in buiding the presentation side of web applications because generating dynamic content is much easier if you are writing much of that content in its native form. We'll be seeing more about how servlets and JSP pages coexist when we look in detail at J2EE design patterns and application architectures in a future article.

Where can I find more information about Java Servlets and JSP?

The Servlet and JSP home pages are a good place to start, as is TheServerSide.com. Of course, if you have a specific question, don't forget to join us over at the JavaRanch Servlets and JSP forums. Also, take a look at the J2EE section of The Bunkhouse for a list of related books, reviews and recommendations.

Summary

To wrap up, support for building web-based applications within the Java 2 Enterprise Edition is comprehensive and provides everything that you'll need in order to build scalable web-based interfaces to new or existing applications. Java Servlets and JavaServer Pages provide us with the ability to build rich, dynamic interfaces while allowing us to choose whichever of these two complementary technologies best fit our needs. In addition to this, experiences with JSP have led to the creation of JSP tag extensions that give us a way to wrap up and reuse the common, recurring functionality within our web applications. These are a very powerful tool with which to ensure that maintainability isn't just something that we achieve when coding regular Java classes.

With our brief tour of the J2EE web tier complete, the next article will look at the business tier and specifically Enterprise JavaBeans.