CHAPTER 6
What Are Servlets?

Servlets, Sun’s latest contribution for enhancing the capabilities of a Web server, are small Java programs that run on a Web server. The name servlets is play on words because servlets are to a Web server as applets are to a Web browser. Servlets replace the need for other server-side programming paradigms with a Java-specific solution. Web servers began as a mechanism for sending static Web documents to a Web browser using a simple protocol, HTTP. Before long, people began looking for ways to extend the capabilities of the Web browser so that more complex forms of elements and objects such as date validation fields and spreadsheet objects could be displayed. At the same time, several technologies emerged for adding program logic on the server.

This chapter shows how typical server-side programming works and compares it to the process of servlet creation and use. This comparison provides you with a basis for understanding how other server-side technologies provide Web client services and at the same time provides an overview of how to use servlets to perform the same tasks in Java. Chapter 7, “Programming Servlets,” covers the features and use of servlets in greater detail.

Server-Side Programming Technologies

Many technologies for programming on the server have emerged. The most common technologies include the following:

Common Gateway Interface (CGI). CGI enables developers to create separate applications that communicate with the Web server. The applications (or scripts) generate Web pages or other files dynamically by processing form data and returning documents based on the form values and other criteria.

Plug-ins. Server vendors such as Microsoft and Netscape came out with their own proprietary APIs for extending the application logic of their particular servers. These “plug-in” technologies (ISAPI and NSAPI, respectively) allow the programmer to take advantage of server-specific features for managing the relationship between the Web server and other resources. Plug-ins are custom code extensions that are added directly to the server and run inside the server’s memory address space. Plug-ins have the performance advantage of running in the Web server process, but if the plug-in crashes, it also has the potential of crashing the server.

Server-side includes. Many servers support extensions to HTML called server-side includes. Some Web servers have the ability to preprocess HTML before sending it to the Web browser. The Web servers support additional HTML tags that can be dynamically processed by the Web server so that the resulting HTML viewed in the Web browser can be customized by this server-side include. An extension to server-side includes is the concept of server-side scripting. Many servers are now supporting this type of scripting. For example, Microsoft’s Web server supports Active Server Pages; Netscape supports Server-Side JavaScript, previously known as LiveWire. These extensions are interpreted by the server.

All of these technologies enable developers to create complete, distributed applications in which the user interface logic is displayed in the Web browser and the business logic is managed in server programs. Enhanced HTML capabilities for developing complete (but rudimentary) user interfaces for the Web browser and the ability to build complex business logic via CGI and other technologies on the Web server clearly changed the way enterprise applications are written for a large number of systems.

Rather than creating a single monolithic application, we define smaller applications that provide a finite number of functions such as validating a credit card or retrieving a product description from a database. These smaller applications work together to perform the functions of a larger enterprise system. Each of these applications can reside on a single server, or they can be distributed throughout the network. This flexibility allows better load balancing, performance tuning, and maintenance of each individual component. For instance, you can upgrade one component such as an application that provides the user with a menu of options without having to change the rest of the application components.

The next section describes how a CGI script can be used to process Web client requests. This discussion forms a basis for comparing CGI and servlets.

Processing Forms with CGI

While each of the server technologies is slightly different in how it performs its tasks, the CGI process illustrates the basic purpose and function of server-side logic. CGI programs can be used to dynamically generate Web pages, as in this simple example using the Perl language:

#!/bin/perl

# Send the output mime type to the server to know what output to handle
print “Content-type: text/html\n\n”;

print “<HTML>\n”;
print “<HEAD><TITLE>Hello World</TITLE></HEAD>\n”;
print “<BODY>\n”;

print “<H1>Hello World</H1>\n”;

print “</BODY></HTML>\n”;

exit;

Depending on how your Web server is configured, from a Web browser you could type:

<HTTP://www.myserver.com/cgi-scripts/helloworld.pl>

to access this program. Typically, CGI programs are used to process HTML forms and then return dynamic HTML; however, CGI can be used to input and output any type of data. Figure 6.1 shows a simple HTML form that is processed with a CGI script.

Figure 6.1  HTML form.

After the user enters values in the form, he presses the Submit button. The values are sent to the CGI script as the FORM action. The CGI script processes the values sent to it and then dynamically returns an HTML page thanking the user for the entry.

Here is the HTML for the page:

<html>
  <head>
    <title>Book Review</title>
  </head>

  <body>
    <H1>Book Review</H1>
    <form action=<HTTP://servername/cgi-bin/bookreview.pl> method=POST>
      What is your first name?
      <input type=text name=fname>

      <BR><BR>Check if you are planning to write a servlet
      <input type=checkbox name=writeservlet>

      <BR><BR>What was your favorite chapter so far?<BR>
        <BR>Chp. 1<input type=radio name=favchap value=1>
        <BR>Chp. 2<input type=radio name=favchap value=2>
        <BR>Chp. 3<input type=radio name=favchap value=3>
        <BR>Chp. 4<input type=radio name=favchap value=4>
        <BR>Chp. 5<input type=radio name=favchap value=5>
        <BR>Chp. 6<input type=radio name=favchap value=6>
      <BR><BR><input type=submit><input type=reset>
    </form>
  </body>
</html>

Notice that each form element has a unique name and value. When the user presses the Submit button, the form data is packaged up and sent to the CGI program as a request. The CGI program parses the request and processes each of the form element’s values. Then the CGI program typically returns another HTML document to the Web browser. Figure 6.2 shows what a response might look like after the preceding form is submitted.