What Servlets Are and Why You Would Want to Use Them

Java Servlets are an efficient and powerful solution for creating dynamic content for the Web. Over the past few years Servlets have become the fundamental building block of mainstream server-side Java. The power behind Servlets comes from the use of Java as a platform and from interaction with a Servlet container. The Java platform provides a Servlet developer with a robust API, object-orientated programming, platform neutrality, strict types, garbage collection, and all the security features of the JVM. Complimenting this, a Servlet container provides life cycle management, a single process to share and manage application-wide resources, and interaction with a Web server. Together this functionality makes Servlets a desirable technology for server-side Java developers.

Java Servlets is currently in version 2.4 and a part of the Java 2 Enterprise Edition (J2EE). Downloads of the J2SE do not include the Servlet API, but the official Servlet API can be found on Sun Microsystems' Servlet product page, http://java.sun.com/products/servlets, or bundled with the Java 2 Enterprise Edition. Servlet API development is done through the Java Community Process, http://www.jcp.org, but the official reference implementation of the Servlet API is open source and available for public access through the Tomcat project, http://jakarta.apache.org/tomcat.

The Servlet 2.4 API includes many features that are officially defined by the Servlet 2.4 specification, http://java.sun.com/products/servlets, and can be broken down as follows.

Web Applications

Servlets are always part of a larger project called a Web Application. A Web Application is a complete collection of resources for a Web site. Nothing stops a Web Application from consisting of zero, one, or multiple Servlets, but a Servlet container manages Servlets on a per Web Application basis. Web Applications and the configuration files for them are specified by the Servlet specification.

Servlets and HTTP Servlets

The primary purpose of the Servlet specification is to define a robust mechanism for sending content to a client as defined by the Client/Server model. Servlets are most popularly used for generating dynamic content on the Web and have native support for HTTP.

Filters

Filters were officially introduced in the Servlet 2.3 specification. A filter provides an abstracted method of manipulating a client's request and/or response before it actually reaches the endpoint of the request. Filters greatly complement Servlets and are commonly used for things such as authentication, content compression, and logging.

Security

Servlets already use the security features provided by the Java Virtual Machine, but the Servlet specification also defines a mechanism for controlling access to resources in a Web Application.

Internationalization

One of the best features of a Servlet is the ability to develop content for just about any language. A large part of this functionality comes directly from the Java platform's support for internationalization and localization. The Servlet API keeps this functionality and can be easily used to create content in most of the existing languages.

The focus of this chapter is to introduce Servlets and explain how to use HTTP Servlets for creating dynamic content on the Web. For simplicity, this chapter focuses on the basics of Servlets and leaves more complex but practical examples for discussion in pertinent, later chapters. Filters, security, and true internationalization issues are all discussed in later chapters as they pertain to both Servlets and JSP.

Initialization is the first phase of the Servlet life cycle and represents the creation and initialization of resources the Servlet may need to service requests. All Servlets must implement the javax.servlet.Servlet interface. This interface defines the init() method to match the initialization phase of a Servlet life cycle. When a container loads a Servlet, it invokes the init() method before servicing any requests.

The service phase of the Servlet life cycle represents all interactions with requests until the Servlet is destroyed. The Servlet interface matches the service phase of the Servlet life cycle to the service() method. The service() method of a Servlet is invoked once per a request and is responsible for generating the response to that request. The Servlet specification defines the service() method to take two parameters: a javax.servlet.ServletRequest and a javax.servlet.ServletResponse object. These two objects represent a client's request for the dynamic resource and the Servlet's response to the client. By default a Servlet is multi-threaded, meaning that typically only one instance of a Servlet^[1] is loaded by a JSP container at any given time. Initialization is done once, and each request after that is handled concurrently^[2] by threads executing the Servlet's service() method.

The destruction phase of the Servlet life cycle represents when a Servlet is being removed from use by a container. The Servlet interface defines the destroy() method to correspond to the destruction life cycle phase. Each time a Servlet is about to be removed from use, a container calls the destroy() method, allowing the Servlet to gracefully terminate and tidy up any resources it might have created. By proper use of the initialization, service, and destruction phases of the Servlet life cycle, a Servlet can efficiently manage application resources. During initialization a Servlet loads everything it needs to use for servicing requests. The resources are then readily used during the service phase and can then be cleaned up in the destruction phase.

These three events form the Servlet life cycle, but in practice there are more methods a Web developer needs to worry about. Content on the Web is primarily accessed via the HyperText Transfer Protocol (HTTP). A basic Servlet knows nothing about HTTP, but there is a special implementation of Servlet, javax.servlet.http.HttpServlet, that is designed especially for it.

Servlets for the World Wide Web

When the term Servlet is mentioned, it is almost always implied that the Servlet is an instance of HttpServlet^[3]. The explanation of this is simple. The HyperText Transfer Protocol (HTTP)^[4] is used for the vast majority of transactions on the World Wide Webevery Web page you visit is transmitted using HTTP, hence the http:// prefix. Not that HTTP is the best protocol to ever be made, but HTTP does work and HTTP is already widely used. Servlet support for HTTP transactions comes in the form of the javax.servlet.http.HttpServlet class.

Before showing an example of an HttpServlet, it is helpful to reiterate the basics of the HyperText Transfer Protocol. Many developers do not fully understand HTTP, which is critical in order to fully understand an HttpServlet. HTTP is a simple, stateless protocol. The protocol relies on a client, usually a Web browser, to make a request and a server to send a response. Connections only last long enough for one transaction. A transaction can be one or more request/response pairs. For example, a browser will send a request for an HTML page followed by multiple requests for each image on that page. All of these requests and responses will be done over the same connection. The connection will then be closed at the end of the last response. The whole process is relatively simple and occurs each time a browser requests a resource from an HTTP server

Requests, Responses, and Headers

The first part of an HTTP transaction is when an HTTP client creates and sends a request to a server. An HTTP request in its simplest form is nothing more than a line of text specifying what resource a client would like to retrieve. The line of text is broken into three parts: the type of action, or method, that the client would like to do; the resource the client would like to access; and the version of the HTTP protocol that is being used. For example:

GET /index.html HTTP/1.0

The preceding is a completely valid HTTP request. The first word, GET, is a method defined by HTTP to ask a server for a specific resource; /index.html is the resource being requested from the server; HTTP/1.0 is the version of HTTP that is being used. When any device using HTTP wants to get a resource from a server, it would use something similar to the above line. Go ahead and try this by hand against Tomcat. Open up a telnet session with your local computer on port 80. From the command prompt this is usually accomplished with:

telnet 127.0.0.1 80

Something similar to Figure 2-2 should appear.

The telnet program has just opened a connection to Tomcat's Web server. Tomcat understands HTTP, so type^[6] in the example HTTP statement. This HTTP request can be terminated by a blank line, so hit Enter a second time to place an additional blank line and finish the request^[7].

GET /jspbook/index.html HTTP/1.0

The content of index.html is returned from the Web Application mapped to /jspbook (the application we started last chapter), as shown in Figure 2-3.

You just sent a basic HTTP request, and Tomcat returned an HTTP response. While usually done behind the scenes, all HTTP requests resemble the preceding. There are a few more methods to accompany GET, but before discussing those, let's take a closer look at what Tomcat sent back.

The first thing Tomcat returned was a line of text:

HTTP/1.1 200 OK

This is an HTTP status line. Every HTTP response starts with a status line. The status line consists of the HTTP version, a status code, and a reason phrase. The HTTP response code 200 means everything was fine; that is why Tomcat included the requested content with the response. If there was some sort of issue with the request, a different response code would have been used. Another HTTP response code you are likely familiar with is the 404 "File Not Found" code. If you have ever followed a broken hyperlink, this is probably the code that was returned.

Along with the HTTP response code, Tomcat also sent back a few lines of information before the contents of index.html, as shown in Figure 2-4.

All of these lines are HTTP headers. HTTP uses headers to send meta-information with a request or response. A header is a colon-delimited name:value pairthat is, it contains the header's name, delimited by a colon followed by the header's value. Typical response headers include content-type descriptions, content length, a time-stamp, server information, and the date the content was last changed. This information helps a client figure out what is being sent, how big it is, and if the data are newer than a previously seen response. An HTTP request will always contain a few headers^[8]. Common request headers consist of the user-agent details and preferred formats, languages, and content encoding to receive. These headers help tell a server what the client is and how they would prefer to get back information. Understanding HTTP headers is important, but for now put the concept on hold until you learn a little more about Servlets. HTTP headers provide some very helpful functionality, but it is better to explain them further with some HttpServlet examples.

GET and POST

The first relatively widely used version of HTTP was HTTP 0.9. This had support for only one HTTP method, or verb; that was GET. As part of its execution, a GET request can provide a limited amount of information in the form of a query string^[9]. However, the GET method is not intended to send large amounts of information. Most Web servers restrict the length of complete URLs, including query strings, to 255 characters. Excess information is usually ignored. For this reason GET methods are great for sending small amounts of information that you do not mind having visible in a URL. There is another restriction on GET; the HTTP specification defines GET as a "safe" method which is also idempotent^[10]. This means that GET must only be used to execute queries in a Web application. GET must not be used to perform updates, as this breaks the HTTP specification.

To overcome these limitations, the HTTP 1.0 specification introduced the POST method. POST is similar to GET in that it may also have a query string, but the POST method can use a completely different mechanism for sending information. A POST sends an unlimited amount of information over a socket connection as part of the HTTP request. The extra information does not appear as part of a URL and is only sent once. For these reasons the POST method is usually used for sending sensitive^[11] or large amounts of information, or when uploading files. Note that POST methods do not have to be idempotent. This is very important, as it now means applications have a way of updating data in a Web application. If an application needs to modify data, or add new data and is sending a request over HTTP, then the application must not use GET but must instead use POST. Notice that POST requests may be idempotent; that is, there is nothing to stop an application using POST instead of GET, and this is often done when a retrieval requires sending large amounts of data^[12]. However, note that GET can never be used in place of POST if the HTTP request is nonidempotent.

In the current HTTP version, 1.1, there are in total seven HTTP methods that exist: GET, PUT, POST, TRACE, DELETE, OPTIONS, and HEAD. In practice only two of these methods are usedthe two we have already talked about: GET and POST.

The other five methods are not very helpful to a Web developer. The HEAD method requests only the headers of a response. PUT is used to place documents directly to a server, and DELETE does the exact opposite. The TRACE method is meant for debugging. It returns an exact copy of a request to a client. Lastly, the OPTIONS method is meant to ask a server what methods and other options the server supports for the requested resource.

As far as this book is concerned, the HTTP methods will not be explained further. As will soon be shown, it is not important for a Servlet developer to fully understand exactly how to construct and use all the HTTP methods manually. HttpServlet objects take care of low-level HTTP functionality and translate HTTP methods directly into invocations of Java methods.

HTTP Response Codes

An HTTP server takes a request from a client and generates a response. Responses, like requests, consist of a response line, headers, and a body. The response line contains the HTTP version of the server, a response code, and a reason phrase. The reason phrase is some text that describes the response, and could be anything, although a recommended set of reason phrases is given in the specification. Response codes themselves are three-digit numbers that are divided into groups. Each group has a meaning as shown here:

• 1xx: Informational: Request received, continuing process.

• 2xx: Success: The action was successfully received, understood, and accepted.

• 3xx: Redirection: Further action must be taken in order to complete the request.

• 4xx: User-Agent Error: The request contains bad syntax or cannot be fulfilled.

• 5xx: Server Error: The server failed to fulfill an apparently valid request.

• Each Status: Code has an associated string (reason phrase).

• The status code you'll see most often is 200. This means that everything has succeeded and you have a valid response. The others you are likely to see are:

  • 401: you are not authorized to make this request

  • 404: cannot find the requested URI

  • 405: the HTTP method you have tried to execute is not supported by this URL (e.g., you have sent a POST and the URL will only accept GET)

  • 500: Internal Server Error. You are likely to see this if the resource to where you are browsing (such as a Servlet) throws an exception.

If you send a request to a Servlet and get a 500 code, then the chances are your Servlet has itself thrown an exception. To discover the root cause of this exception, you should check the application output logs. Tomcat's logs are stored in /logs^[13] directory of the Tomcat installation.