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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Interview with Patrick Volkerding
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
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