What Are Java Servlets?

Java servlets have become the mainstay for extending and enhancing web applications using the Java platform. They provide a component-based, platform-independent method for building web applications. Servlets don't suffer from the same performance limitations that standard CGI applications incur. Servlets are more efficient than the standard CGI threading model because they create a single heavyweight process and allow each user request to use a much more lightweight thread, which is maintained by the Java Virtual Machine (JVM), to fulfill the request. Multiple user requests can be threaded through the same instance of a servlet. A servlet is mapped to one or more uniform resource locators (URLs), and when the server receives a request to one of the servlet URLs, the service method in the servlet is invoked and it responds. Because each user request is associated with a separate thread, multiple threads or users can invoke the service method at the same time. This multithreaded nature of servlets is one of the main reasons that they are more scalable than standard CGI applications. Also, because servlets are written in Java, they are not proprietary to a platform or OS.

Another significant advantage of being written in the Java language is that servlets are able to exploit the entire suite of Java application programming interfaces (APIs), including Java DataBase Connectivity™ (JDBC) and Enterprise JavaBeans (EJB). This was one of the factors in servlets becoming part of the mainstream so quickly; there already was a rich Java library in place for them to leverage.

Servlets are not executed directly by a web server. They require a servlet container, sometimes referred to as a servlet engine, to host the servlet. This servlet container is loosely coupled to a particular instance of a web server, and together they cooperate to service requests. Figure 1-1 illustrates how a web server and servlet container cooperate to service a request from a web browser.

Figure 1-1. Processing a client request

Developers are free to choose from one of many servlet containers available to host their servlets; they are not locked into a particular vendor or platform. Servlets can be ported to any of these containers without recompiling the source code or making any changes. This leads to a "best of breed" solution for web applications—you get the best product or component for a specialized need, while at the same time avoiding the high risk normally associated with a single solution.

There are several popular servlet containers on the market. Some are standalone servlet containers that must be connected to an external web server to work, while others provide both the web server and servlet container in the same product. There are even a few that are integrated into application servers and provide much more functionality than just a servlet container. Table 1-1 lists some of the more popular servlet containers. Some of the products are commercial products and some have a small or insignificant cost to use.

Table 1-1. Popular servlet containers
Servlet container	URL
Bluestone	http://www.bluestone.com
Borland Enterprise Server	http://www.inprise.com
iPlanet Application Server	http://www.sun.com/software/iplanet/
Orbix E2A (formally iPAS)	http://www.iona.com
Jetty	http://www.mortbay.com
JRun	http://www.macromedia.com/software/jrun/
Orion Application Server	http://www.orionserver.com
Resin	http://www.caucho.com
SilverStream	http://www.silverstream.com
Apache Tomcat	http://jakarta.apache.org/tomcat/
Weblogic Application Server	http://www.bea.com
WebSphere	http://www-4.ibm.com/software/webservers/appserv/
EAServer	http://www.sybase.com

For a more complete listing of available servlet containers, visit Sun's servlet industry momentum web site at http://java.sun.com/products/servlet/industry.html.

Although servlets are great at what they do, it quickly became apparent that hardcoding HyperText Markup Language (HTML) output in a servlet as a response to a request had some serious limitations. First and foremost, it was hard to make changes to the HTML because for every change, a recompilation of the servlet had to take place.

Secondly, supporting different languages is difficult because the HTML is hardcoded. Determining the user's language, region, and optional variant and then displaying the output is not easily accomplished. Many web applications built with servlets avoid the entire issue of internationalization^[1] by having different servlets, one for each supported locale.

^[1] Internationalization is commonly referred to as "I18N" because the word begins with the letter I, ends with the letter N, and contains 18 characters in between.

Finally, because HTML was embedded within the servlet, there was a problem with responsibility. Web designers build HTML pages; they are not usually experienced with Java programming, let alone skilled at object-oriented design and programming. When you mix HTML and Java code within the servlet, it becomes hard to separate the page design and programming duties. Even when a developer has the necessary skills to perform both functions, modifications to the page layout require recompilation, which adds to development and testing time.

Servlet programming is such a broad topic that it can't be covered in great detail here. If you feel that you need more information on Java Servlet technology, a great source of material is Jason Hunter's Java Servlet Programming (O'Reilly). You can also find more information at the Sun Servlet web site (http://java.sun.com/products/servlet/index.html).

JavaServer Pages was the next step in the linear progression of developing web technologies based on the Java platform. The introduction of JSP pages, as they are commonly referred to, helped to alleviate the servlet limitations mentioned earlier and opened up many new doors for web developers.