Using and Writing Java Servlets

Creating dynamic web pages is necessary if a web site wants to display the current state of data accurately, for example showing temperatures around the world. There are several ways to accomplish this, such as using Perl or shell scripts. In this article, I discuss the viability of using Java programs (servlets) with a web server. A servlet is a Java application that performs a task that may generate a dynamic web page or process input from a web page form.

The first advantage is that only one instance of the JVM (Java Virtual Machine) needs to be started. For each servlet, a new thread is created and managed by the same JVM. In contrast, Perl and shell CGI (common gateway interface) scripts require a new process to be created each time the script is run. This may become a problem if dynamic web pages are being created for many (possibly thousands) of web pages per minute. The JVM itself is more efficient because it only needs to keep one copy of the actual servlet code to create the dynamic portions, such as variable data and program context, for each instance of the servlet. Another plus is that if you have Java expertise, it is not necessary to relearn a new scripting language with a new set of APIs and quirks.

Since the JVM has a rapport with the web server, it is possible for servlets to communicate to the server directly. This, of course, poses a security risk but does allow servlets to be written that manipulate the web server on the fly.

The user does not need to have a Java-capable browser because there are still many small internet devices that do not have the capacity to run complex Java APIs. Also, the Java servlet code is portable across operating systems and machine architectures.

None of the graphical user interface components of the Java API can be used by a servlet, as its display is an HTML web page. However, it is possible to use the imaging APIs to create graphs and display them as a final rendered image. In addition, the servlet has access not only to a vast amount of standard APIs for accessing databases and other information but also to third party APIs for Java.

As Java progresses through various versions, APIs are deprecated and eventually discarded, and sometimes even the language itself is changed. This may not cause a problem as the Java-generated pseudo code (a type of machine-independent machine code) can still execute on a different version of the JVM. However, at some point (several years down the line) you will be required to recompile and port the servlet with the Java Development Kit (JDK) of the day.

Another disadvantage is that Java, unfortunately, is slow. Although great strides have been made in performance improvements, Java code will not be as fast as native executables but probably is faster than several other popular scripting languages.

Since the servlet manager (in this case Tomcat) is a Java program and is separate from the web server, Apache, the communication between the two is not instantaneous. This may produce a performance hitch on heavily active web servers.

The biggest hiccup with servlets is the installation and running of the various components that are required for servlet support. Here is a list of some requirements:

You need to inform Tomcat of the location of the Java distribution; if the installation process does not detect it at install time, you will need to edit /etc/rc.d/init.d/tomcat. Be particularly careful if you have more than one version of Java installed (e.g., 1.1.18 and 1.2.2).

Also, whenever Tomcat is restarted, the Apache server must be restarted as well. This is to establish the communication path between Apache and Tomcat. The Apache server can be restarted without having to restart Tomcat.