X Home X X News X X Apps/Tools X X Support X X Downloads X X Articles X X Contact X
Introduction to Servlets
Share |

Introduction to Servlets

Craig Knudsen (craig@k5n.us)
01 Dec 1998

CGI/Perl has been around the block, so why would you want to use something else like Java servlets? There's plenty to consider, but servlets are a new and improved way to implement web-based applications.


What is a servlet? Servlets are 100% Pure Java web-based server applications. They are an alternate solution to CGIs. Because servlets are compiled Java applications, they are portable across operating systems. Servlets use the Servlet API allowing them to be used with almost any web server.

When I started developing web sites a few years ago, the most complicated used CGI/Perl and flat files for data storage and retrieval. Today, I'm working with databases like Oracle or Microsoft SQL Server and coding lots of Java. So, is CGI/Perl still suited for today's increasingly complex web sites?

Comparison of servlets to CGI/Perl

CGI (Common Gateway Interface) has been the standard for developing interactive web sites for what seems like an eternity. Although the CGI standard allows any language to be used, Perl is chosen the majority of the time. Servlets are always written in Java. The Servlet API requires Java. (It's technically possible to write a servlet in another programming language if you have a compiler that generates Java class files, but the end result would still be Java objects.)


When deciding on CGI/Perl or servlets, the first question you might ask would be "Can it do what I need it to do?". Then you might move on to "And how hard will it be to implement?" The answer to these questions often are found in the free and commercial add-ons for both CGI/Perl and servlets. Perl uses a concept of modules to add new capabilities. For instance, the DBI module (DataBase Independent) allows perl scripts to access databases including Oracle, Sybase, Ingres, and Informix. The CGI module includes functions for helping in CGI development including routines for form variables, cookies and sessions. There are hundreds of Perl modules freely available from CPAN, the Comprehensive Perl Archive Network. Java uses packages rather than modules. The Servlet API provides many of the same tools available in the Perl CGI module. For database access, JDBC can be used (and is included with the JDK 1.1 release). Note that in addition to JDBC, you will need a JDBC driver for your database. (See Sun's list of JDBC drivers.) Many drivers such as Sybase's jConnect and Oracle's JDBC Thin Driver can be freely downloaded.


One of the most common complaints about CGI/Perl are its drain on system resources. In a typical CGI environment, each request creates a new process which then loads the Perl interpreter (typically over 500k in size). The Perl interpreter then loads the CGI script, compiles it and the executes it. Additionally, if the application communicates with a database, a new connection will need to established for each CGI (a rather expensive process for some databases). There are solutions available to help reduce the overhead of CGI/Perl. The mod_perl module for the Apache web server links the Perl runtime library into the server. With mod_perl it is not necessary for the web server to start a new process for each request. There is also FastCGI which can help and will work with more web servers than mod_perl. So how does a servlet compare? Servlets start a new thread with each request rather than starting a new process. Each servlet is loaded once and used over and over. This allows servlets to share a pool of database connections that can be opened the first time the servlet is referenced. Note that unlike CGI, you will have a Java VM running on the server at all times. For busy sites, this allows servlets to use much less system resources, scale better and provide improved performance.


Security can be a problem when developing CGIs. The largest area of concern is processing user input. This could be from forms or from data within the URL. Many CGIs written in Perl can be vulnerable to attacks where the end user tricks the CGI into executing a command on the server. Servlets are not at risk of running unintended shell commands. Compiled languages such as Java (or C) provide better security than an interpreted scripting language. (See the WWW Security FAQ's section on CGI Scripts for more information on this.)

Are you installing the application on someone else's server? Servlets are compiled class files while CGI/Perl is delivered in its original source form. Depending on who has access to your web server, you may prefer not to install source code.


Many sites are looking for a portable solution. Perhaps they want developers to use Linux or Windows NT while their production server runs Solaris. They might want to sell their web application to as many customer on as many platforms as possible. There are versions of Perl for every variant of UNIX as well as Windows 95 and NT. While Perl for UNIX is not 100% compatible with Perl for NT, CGIs written in Perl can be written to work on both. I've had to port CGIs to Windows NT on more than one occassion. It's not difficult to do, but the developer should be aware of this requirement beforehand. Otherwise, the CGI may contain UNIX shell commands that will not work on Windows NT.

Portability with Java servlets is simpler. Java was designed to be portable across all platforms allowing applications to be moved easily from one operating system to another.


Perl development is fairly simple. All you need is your favorite text editor and lots of Perl documentation (available online). While many Perl developers feel most comfortable in this type of environment, there's a growing breed of IDE (Integrated Development Environment) developers. In that arena, Java stands far above Perl. There are IDEs available from Sun, Microsoft, Symantec and many others providing simple GUI-based build and debug environments. IDEs can provide useful time-saving tools and ease the learning curve for new developers. Of course, you can still use your favorite text editor with Java.

Sharing development among developers is also easier with Java. Developers can be assigned to develop individual packages. I have yet to work on a CGI/Perl application where two or more developers were working on the application simultaneously. The application is typically handed from one developer to another. Java application development scales better for large projects.


Debugging web-based applications can difficult. CGI/Perl is no exception. A run-time compile error will cause the CGI to abort and the end user will either see Navigator's "Document contains no data" error message or a server error message. Older web servers will not indicate where the Perl script aborted or what caused it. Newer web servers will include the standard error output from the CGI in the server error log. This will typically indicate what line and file the error occurred.

A servlet that generates an exception will be similarly logged on the server (depending on your servlet engine). For example, the following is from the servlet error log for a servlet that attempted to improperly access a null value:

        at HelloWorld.doGet(HelloWorld.java:15)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:486)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:575)
        at org.apache.jserv.JServConnection.run(JServConnection.java:349)

Recently, I delivered a web application written in Java. Soon after, I received an email saying "It doesn't work." Ordinarily, this type of message would leave me wondering why the user couldn't be a little more specific about the problem. But, I wasn't worried because we had server logs for the Java application. I could clearly see where the error had occured and what exception was generated. This was enough information for me to track down the problem.

Java also has remote debugging support. What does that mean for web applications? If your servlet engine will allow you to pass the -debug option to the JVM and log its output (which includes the remote debugging password), then you will be able to attach a debugger (like the JDK's jdb or a debugger from one of the many IDEs) to your servlet engine and debug your servlets. This is a step up from CGI/Perl which does not support any kind of interactive debugger.


Will your application continue to grow? I recently developed a tool for tracking projects and tasks using CGI/Perl and flat files. When more people started using the tool, it became too slow. When the company wanted an electronic timecard system integrated into the tool, I knew we had just outgrown flat files. So, I converted the system from flat files to Oracle and DBI. This relieved some of the performance problems, but there are still some performance problems with many concurrent users. Why did I start with CGI/Perl and flat files? I chose CGI/Perl so that I could deliver a working application sooner. CGI/Perl is a wonderful tool for rapid prototypes. At the time, it was not clear how big the tool would get. Looking back, it might have been better to start with a servlet approach.

Servlet-enabled web servers

You can run servlets by either obtaining a servlet-enabled server or by obtaining a server add-on that will run the servlets.

Sun's Java Web Server includes support for servlets without the need for a server add-on and also supports Java Server Pages (JSP) allowing you to embed Java code in static HTML pages. These pages are then compiled into servlets.

For the more adventurous, you can freely download the Apache web server and the mod_jserv module that supports servlets. Note that this is not a point-and-click installation. You will need to compile Apache, mod_jserv and edit Apache's configuration files.

Example: "Hello World" servlet

Writing your first servlet is very simple. Most servlets are a subclass of the HttpServlet class. Requests are processed through either the doGet() or doPost() methods. The following example displays an HTML page saying nothing more than "Hello World."

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

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

public class HelloWorld extends HttpServlet {

  public void doGet (
    HttpServletRequest request,      // form variables, etc.
    HttpServletResponse response )   // methods for providing output
    throws ServletException, IOException {
    // set content type of HTTP header
    response.setContentType ( "text/html" );

    // create an output object and send our response
    PrintWriter out = response.getWriter ();
    out.println ( "<HTML><HEAD><TITLE>Hello World</TITLE></HEAD>\n" +
      "<BODY>Hello World!</BODY></HTML>" );
    out.close ();

So, how does this compare with CGI/Perl? The example below shows how this would be done in CGI/Perl.

print "Content-type: text/html\n\n";
print "<HTML><HEAD><TITLE>Hello World</TITLE></HEAD>\n" .
  "<BODY>Hello World!</BODY></HTML>";
exit 0;

The Perl implementation is fewer lines and could be written in less time. If this is all your application needs to do, you're probably better off with CGI/Perl. If your application needs to access a database, process HTML forms or send email, then you'll need to consider other issues like performance, portability, security and how the Servlet API and add-on packages compare to available Perl modules for the functions you will need.

The Servlet API

The Servlet API is contained within two packages:

  • javax.servlet.http: HTTP-specific classes
  • javax.servlet: non-HTTP classes

Although the Servlet API is designed for use with HTTP, the separation into two packages allows the Servlet API to be extended to support alternate protocols. Today's servlets typically use mostly the HTTP-specific classes.

Servlet requests are processed through either the doGet() or doPost() methods. Both methods accept a HttpServletRequest and a HttpServletResponse object. Additionally, you can define init() and destroy() methods for when the servlet is first loaded and then unloaded. The same object instance may be used many times after being loaded. Initialization is a good time to setup database connections or perform other resource-intensive setup functions. Below is an overview of the most common methods of the HttpServletRequest, HttpServletResponse, HttpSession, and Cookie interfaces.

doGet() Called to handle HTTP GET requests
doPost() Called to handle HTTP POST requests
getCookies() Obtains array of cookies
getMethod() Returns the HTTP method (GET or POST)
getPathInfo() Returns any extra path information for the request URI
getRemoteUser() Gets the name of the user making the request (provided by HTTP authentication)
getSession() Returns the current valid session assoicated with this request or creates a new session
addCookie() Adds the specified cookie to the response
encodeURL() Encodes the URL by including the session id in it if needed
sendError() Sends an error response to the user with the specified error code
sendRedirect() Sends a redirect request to the user
getValue() Returns an object bound to the specified name for the session
putValue() Binds an object to the specified name for the session
removeValue() Removes an object bound to the specified name for the session
getName() Returns the name of the cookie
getValue() Returns the value of the cookie
setValue() Sets the value of the cookie

Java on the server

While applets certainly generated a lot of attention for Java, the server may be the best environment to deploy a Java solution. Java's advantages of code-reuse, strict typing, portability and performance can be particularly important to server applications. With the finalization of the Enterprise JavaBeans specification, more server-side Java solutions are on the way.

Sun is currently working on the Java Server Pages specification which allow developers to embed Java within HTML files. The embedded Java code is compiled into servlets. Both Live Software's JRun and Net Atlanta's ServletExec support Java Server Pages and servlets.


So what should you choose: CGI/Perl or servlets? That depends on what you're developing and how much you are concerned about server load, scalability, security, portability and growth potential. If you're building a small web application that needs to be delivered quickly, you can stick with CGI/Perl. But if you're building a complex web application that connects a database to your site, you may want to try a servlet implementation.



Feel free to provide feedback on this article.

About the Author

Craig Knudsen has been developing software solutions since the early 90s. He founded the open source WebCalendar project in 2000 and continues to lead the project. He has developed web-based applications using all sorts of combinations of C, Perl, Java, JavaScript, PHP and even ASP. When not attempting to build furniture in his workshop, you can reach him at craig@k5n.us.
Valid XHTML 1.0 Valid CSS PHP
Page Last Updated: 22-Aug-2010
Copyright ©2004-2018 k5n.us, All Rights Reserved