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:
A Java installation. Although some Linux distributions provide Java, the version may be limited in its API set or may be an older version.
A web server that can support servlets. There are several available. In this tutorial, I use Apache but recommend Jetty as well. You need to have Apache installed and functioning for servlet support. Most Linux distributions install Apache by default and already have it running, so this may not be a problem.
You need a mechanism by which the web server can execute Java servlets. For example, a popular servlet support extension to Apache is Tomcat. However, Linux distributions most likely will not provide this mechanism, and you will need to download it from the Web.
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.
|Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform||Jan 23, 2015|
|Designing with Linux||Jan 22, 2015|
|Wondershaper—QOS in a Pinch||Jan 21, 2015|
|Ideal Backups with zbackup||Jan 19, 2015|
|Non-Linux FOSS: Animation Made Easy||Jan 14, 2015|
|Internet of Things Blows Away CES, and it May Be Hunting for YOU Next||Jan 12, 2015|
- Designing with Linux
- Wondershaper—QOS in a Pinch
- Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform
- Internet of Things Blows Away CES, and it May Be Hunting for YOU Next
- Ideal Backups with zbackup
- Readers' Choice Awards 2014
- New Products
- Slow System? iotop Is Your Friend
- Hats Off to Mozilla
- January 2015 Issue of Linux Journal: Security
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane