Like Java itself, servlets were designed for portability. Servlets are supported on all platforms that support Java, and servlets work with all the major web servers. Java servlets, as defined by the Java Software division of Sun Microsystems (formerly known as JavaSoft), are the first standard extension to Java. This means that servlets are officially blessed by Sun and are part of the Java language, but they are not part of the core Java API. Therefore, although they may work with any Java Virtual Machine (JVM), servlet classes need not be bundled with all JVMs. More information about the Java Extension Framework is available at http://java.sun.com/ products/jdk/1.2/docs/guide/extensions .
To make it easy for you to develop servlets, Sun has made publicly
available a set of classes that provide basic servlet support. The
javax.servlet.http packages constitute this Servlet API. Version 2.0 of these
classes comes bundled with the Java Servlet Development Kit (JSDK)
for use with the Java Development Kit version 1.1 and above; the JDSK
is available for download from
Many web server vendors have incorporated these classes into their servers to provide servlet support, and several have also provided additional functionality. Sun’s Java Web Server, for instance, includes a proprietary interface to the server’s security features.
It doesn’t much matter where you get the servlet classes, as long as you have them on your system, since you need them to compile your servlets. In addition to the servlet classes, you need a servlet engine, so that you can test and deploy your servlets. Your choice of servlet engine depends in part on the web server(s) you are running. There are three flavors of servlet engines: standalone, add-on, and embeddable.
A standalone engine is a server that includes built-in support for servlets. Such an engine has the advantage that everything works right out of the box. One disadvantage, however, is that you have to wait for a new release of the web server to get the latest servlet support. Because servlets are still fairly new, this sort of server is still a bit of a rarity. As the various vendors upgrade their web servers, we expect that many of the servers will provide built-in support for servlets.
Standalone engines in web servers include the following:
Sun’s Java Web Server (formerly called “Jeeves”), unofficially considered the reference implementation for how a servlet engine should support servlets. Written entirely in Java (except for two native code libraries that enhance its functionality but are not needed). See http://java.sun.com/products/ .
The World Wide Web Consortium’s Jigsaw Server, freely available and also written entirely in Java. See http://www.w3.org/Jigsaw .
O’Reilly’s WebSite Professional (Version 2.1 and later), the first server not written in Java to provide built-in servlet support. See http://website.oreilly.com .
Netscape’s Enterprise Server (Version 3.51 and later), the most popular web server to provide built-in servlet support. Unfortunately, Version 3.51 supports only the early Servlet API 1.0 and suffers from a number of bugs so significant it’s almost unusable. For the time being, use an add-on servlet engine with Netscape servers instead. See http://home.netscape.com/download .
Lotus’s Domino Go Webserver (Version 4.6 and later), another popular web server with built-in servlet support. Version 4.6.x supports only the early Servlet API 1.0; however, Lotus claims to be replacing its proprietary GWAPI server extension technology with Java servlets, so it’s likely that future versions of the Domino Go Webserver will include robust servlet support. See http://www.lotus.com/dominogowebserver/ .
Application servers are a fertile new area of development. An application server offers server-side support for developing enterprise-based applications. Here are two application servers that include servlet engines:
An add-on servlet engine functions as a plug-in to an existing server—it adds servlet support to a server that was not originally designed with servlets in mind. Add-on servlet engines have been written for many servers including Apache, Netscape’s FastTrack Server and Enterprise Server, Microsoft’s Internet Information Server and Personal Web Server, O’Reilly’s WebSite, Lotus Domino’s Go Webserver, StarNine’s WebSTAR, and Apple’s AppleShare IP. This type of engine acts as a stopgap solution until a future server release incorporates servlet support. A plug-in also can be used with a server that provides a poor or outdated servlet implementation.
Add-on servlet engines include these:
The Java-Apache project’s JServ module, a freely available servlet engine that adds servlet support to the extremely popular Apache server. See http://java.apache.org/ .
Live Software’s JRun, a freely available plug-in designed to support the full Servlet API on all the popular web servers on all the popular operating systems. The latest version even features a basic web server for development purposes. See http://www.livesoftware.com/products/jrun/ .
IBM’s WebSphere Application Server (formerly known as ServletExpress), a plug-in that is being called an application server. It is designed to support the full Servlet API on several popular web servers on several popular operating systems. See http://www.software.ibm.com/webservers/ .
New Atlanta’s ServletExec, a plug-in designed to support the full Servlet API on several web servers on several operating systems. See http://www.newatlanta.com/ .
Gefion Software’s WAICoolRunner, a freely available plug-in that supports most of the Servlet API on Netscape’s FastTrack Server and Enterprise Server versions 3.x and later, written in Java using Netscape’s WAI interface. See http://www.gefionsoftware.com/WAICoolRunner/ .
Unicom’s Servlet CGI Development Kit, a freely available framework that supports servlets on top of CGI. What it lacks in efficiency it makes up for in ubiquity. See http://www.unicom.net/java/ .
An embeddable engine is generally a lightweight servlet deployment platform that can be embedded in another application. That application becomes the true server.
Sun’s JavaServer Engine, a high-quality, high-end framework for designing and building Java servers. Sun’s Java Web Server and IBM’s WebSphere Application Server were built using the Java Server Engine. See http://java.sun.com/products/javaserverengine/ .
Jef Poskanzer’s Acme.Serve, a freely available, simple web server that runs servlets “more or less compatible” with the Servlet API. See http://www.acme.com/java/software/Package-Acme.Serve.html .
Paralogic’s WebCore, a freely available but unsupported embeddable web server, written entirely in Java. It incorporates parts of Acme.Serve. See http://www.paralogic.com/webcore/ .
Anders Kristensen’s Nexus Web Server, a freely available servlet runner that implements most of the Servlet API and can be easily embedded in Java applications. See http://www-uk.hpl.hp.com/people/ak/java/nexus/ .
Before proceeding, we feel obliged to point out that not all servlet engines are created equal. So, before you choose a servlet engine (and possibly a server) with which to deploy your servlets, take it out for a test drive. Kick its tires a little. Check the mailing lists. Always verify that your servlets behave as they do in the Java Web Server implementation. With servlets, you don’t have to worry about the lowest-common-denominator implementation, so you should pick a servlet engine that has the functionality that you want.
For a complete, up-to-date list of available servlet engines, see the official list maintained by Sun at:
 Note that several web server vendors have their own server-side Java implementations, some of which have also been given the name “servlets”. These are generally incompatible with Java servlets as defined by Sun. Most of these vendors are converting their Java support to standard servlets, or are introducing standard servlet support in parallel, to allow backward compatibility.
 At one point it was planned the contents of the JSDK would come bundled as part of JDK 1.2. However, it was later decided to keep the servlet classes separate from the JDK, to better allow for timely revisions and corrections to the JSDK.