Servlets
A servlet is a Java class that is managed by server software known as a Web container (sometimes referred to as a servlets container or servlets engine). The purpose of a servlet is to read information from an HTTP request, perform some processing, and generate some dynamic content to be returned to the client in an HTTP response.
The Servlet Application Programming Interface includes a class, javax.servlet.http.HttpServlet, which can be subclassed by a developer.
The developer needs to override methods such as the following ones to handle different types of HTTP requests (in these cases, POST and GET requests; other methods are also supported):
public void doPost (HttpServletRequest request, HttpServletResponse response)
public void doGet (HttpServletRequest request, HttpServletResponse response)
When an HTTP request is received by the Web container, it consults a configuration file, known as a deployment descriptor, to establish which servlets class corresponds to the URL provided. If the class is already loaded in the Web container and an instance has been created and initialized, the Web container invokes a standard method on the servlets class:
public void service (HttpServletRequest request, HttpServletResponse response)
The service method, which is inherited from HttpServlet, examines the HTTP request type and delegates processing to the doPost or doGet method as appropriate. One of the responsibilities of the Web container is to package the HTTP request received from the client as an HttpServletRequest object and to create an HttpServletResponse object to represent the HTTP response that will ultimately be returned to the client.
Within the doPost or doGet method, the servlet developer can use the wide range of features available within Java, such as database access, messaging systems, connectors to other systems, or Enterprise JavaBeans.
If the servlet has not already been loaded, instantiated, and initialized, the Web container is responsible for carrying out these tasks. The initialization step is performed by executing the method:
public void init ()
And there is a corresponding method:
public void destroy ()
This is called when the servlet is being unloaded from the Web container.
Within the code for the doPost and doGet methods, the usual processing pattern is as follows:
| Read information from the request. This often includes reading cookie information and getting parameters that correspond to fields in an HTML form. |
|
| Check that the user is in the appropriate state to perform the requested action. |
|
| Delegate processing of the request to the appropriate type of business object. |
|
| Update the user's state information. |
|
| Dynamically generate the content to be returned to the client. |
The last step could be carried out directly in the servlet code by writing HTML to a PrintWriter object obtained from the HttpServletResponse object:
PrintWriter out = response.getWriter();
out.println("<html><head><title>Page title</title></head>");
out.println("<body>The page content:");
// ......
We do not recommend this approach, because the embedding of HTML within the Java code means that HTML page design tools, such as those provided by Rational Application Developer, cannot be used. It also means that development roles cannot easily be separated-Java developers must maintain HTML code. The best practice is to use a dedicated display technology, such as JSP, which we cover next.
The Servlet 2.5 specification introduces the following changes:
|
| Dependency on Java SE 5.0-Java SE 5.0 is the minimum platform requirement (because of annotations). |
|
| Support for annotations-Annotations can be used as an alternative to XML entries that would otherwise go in the web.xml deployment descriptor, or they can act as requests for the container to perform tasks that otherwise the servlet would have to perform itself. |
|
| web.xml conveniences-There are several changes in the file format of the web.xml deployment descriptor to make its use more convenient, such as servlet name wild carding or multiple patterns in mappings. |
|
| Removed restrictions-A few restrictions around error handling and session tracking have been removed. Error pages are now allowed to call setStatus() to alter the error code that triggered them. Included servlets can now call request.getSession(), which might implicitly create a session-tracking cookie header. This change is important for the Portlet specification. |
|
| Clarifications-Several edge cases were clarified to make servlets more portable and guaranteed to work as desired. |
|
ibm.com/redbooks |