So far, we have portrayed servlets as an alternative to other dynamic web content technologies, but we haven’t really explained why we think you should use them. What makes servlets a viable choice for web development? We believe that servlets offer a number of advantages over other approaches, including: portability, power, efficiency, endurance, safety, elegance, integration, extensibility, and flexibility. Let’s examine each in turn.
Because servlets are written in Java and conform to a well-defined and widely accepted API, they are highly portable across operating systems and across server implementations. You can develop a servlet on a Windows NT machine running the Java Web Server and later deploy it effortlessly on a high-end Unix server running Apache. With servlets, you can truly “write once, serve everywhere.”
Servlet portability is not the stumbling block it so often is with applets, for two reasons. First, servlet portability is not mandatory. Unlike applets, which have to be tested on all possible client platforms, servlets have to work only on the server machines that you are using for development and deployment. Unless you are in the business of selling your servlets, you don’t have to worry about complete portability. Second, servlets avoid the most error-prone and inconsistently implemented portion of the Java language: the Abstract Windowing Toolkit (AWT) that forms the basis of Java graphical user interfaces.
Servlets can harness the full power of the core Java APIs: networking and URL access, multithreading, image manipulation, data compression, database connectivity, internationalization, remote method invocation (RMI), CORBA connectivity, and object serialization, among others. If you want to write a web application that allows employees to query a corporate legacy database, you can take advantage of all of the Java Enterprise APIs in doing so. Or, if you need to create a web-based directory lookup application, you can make use of the JNDI API.
As a servlet author, you can also pick and choose from a plethora of third-party Java classes and JavaBeans components. In the future, you’ll even be able to use newly introduced Enterprise JavaBeans components. Today, servlets can use third-party code to handle tasks such as regular expression searching, data charting, advanced database access, and advanced networking.
Servlets are also well suited for enabling client/server communication. With a Java-based applet and a Java-based servlet, you can use RMI and object serialization to handle client/server communication, which means that you can leverage the same custom code on the client as on the server. Using CGI for the same purpose is much more complicated, as you have to develop your own custom protocol to handle the communication.
Servlet invocation is highly efficient. Once a servlet is loaded, it generally remains in the server’s memory as a single object instance. Thereafter, the server invokes the servlet to handle a request using a simple, lightweight method invocation. Unlike with CGI, there’s no process to spawn or interpreter to invoke, so the servlet can begin handling the request almost immediately. Multiple, concurrent requests are handled by separate threads, so servlets are highly scalable.
Servlets, in general, are naturally enduring objects. Because a servlet stays in the server’s memory as a single object instance, it automatically maintains its state and can hold on to external resources, such as database connections, that may otherwise take several seconds to establish.
Servlets support safe programming practices on a number of levels. Because they are written in Java, servlets inherit the strong type safety of the Java language. In addition, the Servlet API is implemented to be type-safe. While most values in a CGI program, including a numeric item like a server port number, are treated as strings, values are manipulated by the Servlet API using their native types, so a server port number is represented as an integer. Java’s automatic garbage collection and lack of pointers mean that servlets are generally safe from memory management problems like dangling pointers, invalid pointer references, and memory leaks.
Servlets can handle errors safely, due to Java’s exception-handling mechanism. If a servlet divides by zero or performs some other illegal operation, it throws an exception that can be safely caught and handled by the server, which can politely log the error and apologize to the user. If a C++-based server extension were to make the same mistake, it could potentially crash the server.
A server can further protect itself from servlets through the use of a Java security manager. A server can execute its servlets under the watch of a strict security manager that, for example, enforces a security policy designed to prevent a malicious or poorly written servlet from damaging the server file system.
The
elegance of servlet code is striking. Servlet code is clean, object
oriented, modular, and amazingly simple. One reason for this
simplicity is the Servlet API itself, which includes methods and
classes to handle many of the routine chores of servlet development.
Even advanced operations, like cookie handling and session tracking,
are abstracted into convenient classes. A few more advanced but still
common tasks were left out of the API, and, in those places, we have
tried to step in and provide a set of helpful classes in the
com.oreilly.servlet package.
Servlets are tightly integrated with the server. This integration allows a servlet to cooperate with the server in ways that a CGI program cannot. For example, a servlet can use the server to translate file paths, perform logging, check authorization, perform MIME type mapping, and, in some cases, even add users to the server’s user database. Server-specific extensions can do much of this, but the process is usually much more complex and error-prone.
The Servlet API is designed to be easily extensible. As it stands today, the API includes classes that are optimized for HTTP servlets. But at a later date, it could be extended and optimized for another type of servlets, either by Sun or by a third party. It is also possible that its support for HTTP servlets could be further enhanced.
Servlets are also quite flexible. As you’ll see in the next
chapter, an HTTP servlet can be used to generate a complete web page;
it can be added to a static page using a
SERVLET tag in what’s known as a
server-side include; and it can be used in cooperation with any
number of other servlets to filter content in something called a
servlet chain. In addition, just before this book went to press, Sun
introduced
JavaServer Pages, which offer a way to
write snippets of servlet code directly within a static HTML page,
using a syntax that is curiously similar to Microsoft’s Active
Server Pages (ASP). Who knows what they (or you) will come up with
next.
Get Java Servlet Programming now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
