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.
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
|The Many Paths to a Solution||Sep 21, 2016|
|Synopsys' Coverity||Sep 20, 2016|
|Naztech's Roadstar 5 Car Charger||Sep 16, 2016|
|RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop||Sep 15, 2016|
- Android Browser Security--What You Haven't Been Told
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Nativ Disc
- The Many Paths to a Solution
- Naztech's Roadstar 5 Car Charger
- Synopsys' Coverity
- Securing the Programmer
- RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop
- Glass Padding
- Identity: Our Last Stand
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide