Web programming Units WEB1P and WEB2P

Web programming in Java 1: Servlets

Servlets

Java added the concept of an "applet" to that of an application. An applet being a mini-program that could run within a specific context environment - i.e. a web browser. Applets are short lived (relatively) and perforce run on the client machine. To be able to write mini-programs that run on the server, the concept of a "servlet" was created. A servlet is a small program that can be run from a web server. It is started the first time it is requested, but stays alive after a request has been dealt with to respond to further similar requests. Thus it is much easier for a servlet to retain state from one request to another than it is when handling requests via CGI programs.

Servlets are part of the Java Enterprise Edition - a set of additional APIs that provide many of the facilities that are needed by large-scale (enterprise) applications.

Read chapters 2, 4 and 5 of Basham, Sierra and Bates's Head First Servlets and JSP.

The advantages of servlets over CGI include:

• more efficient
  • the same process handles each HTTP request
  • code is loaded into memory only once
  • only a new thread is created for each request
  • servlets remain in memory when completed so it is straightforward to store data between requests
• more convenient - there is an extensive infrastructure for:
  • decoding form data
  • reading and setting HTTP headers
  • handling cookies
  • tracking sessions
  • accessing databases
  • ...
• more powerful
  • servlets can talk directly to the web server (makes redirection possible)
  • multiple servlets can share data
  • maintain information from request to request
• more portable
  • very strong standard API makes porting servlets between implementations very easy
• inexpensive (but then so are many CGI tools!)
  • the J2EE is made available by Sun free of charge
  • Tomcat is available free from Apache
• more secure
  • not run via an operating system shell (that might treat some characters specially)
  • Java is not susceptible to buffer overflow attacks like C/C++
• more mainstream
  • proven technology
  • supported by major companies like IBM, Oracle, Sun, Macromedia
  • runs on many operating systems
  • used by many large companies

Servlet containers

To execute a servlet, one must have a servlet container or servlet engine. This is a program that responds to servlet requests (i.e. HTTP requests whose URLs map to servlets) and executes the corresponding servlet. The reference implementation of the servlet (and JSP) specifications is Apache Tomcat (formerly part of the Apache Jakarta project). Tomcat is designed to run alongside Apache (or another web server) and deal with servlet requests. See Alternatives to Perl and CGI for more details of how Tomcat interacts with the web server. More recently, Glassfish has been released - this implements the full Java EE specification, of which the web profile is a part. Glassfish thus does everything Tomcat does, plus a lot more.

A servlet container typically runs a number of web applications. Each application is independent of the others run by the same container. Each webapp must have a WEB-INF directory containing the following (at a minimum):

• a file web.xml containing configuration details of the application
• a classes directory containing Java class files that will be used by the application
• a lib directory containing Java JAR files used by the application

Most of the code to handle servlet requests is embodied in a set of Java interfaces and classes specified as part of the J2EE distribution. The servlet container calls appropriate methods at well-defined times. By extending the base set of classes, one can develop one's own servlets.

Interface servlet

All servlets must implement the Servlet interface. This defines a number of methods including init that gets called when a servlet is loaded by its container, and destroy that gets called when a servlet is terminated. Each time a request is received, the servlet's service method is called.

Class HttpServlet

HttpServlet is a class that implements the servlet interface for HTTP requests. It overrides service to distinguish between the different HTTP methods. HttpServlet defines methods called doGet and doPost (and others) that are called according to the requested method. (If you want a servlet to do the same thing regardless of method, just define one to call the other, or implement each by a call to a common method.)

Classes HttpServletRequest and HttpServletResponse

Each of HttpServlet's do-methods receive two arguments: one containing information about the request; the other providing access to attributes of the response.

To access parameters of the request (i.e. data from a submitted form), use request.getParameter(name). To obtain an output stream to write HTML to, use PrintWriter out = response.getWriter().

Class HttpSession

Servlet containers implement a session object that provides a way to identify a user across more than one page request or visit to a Web site and to store information about that user.

Example program

Consider this example Java servlet (PDF format) that just prints out the word "hello" followed by the value of the "name" parameter.

• Lines 12 and 13 import the necessary servlet classes.
• The init method (line 24) in this case doesn't do anything other than call the default init method defined on the superclass (HttpServlet). In other cases this might do any once-only code (e.g. setting up a persistent database connection).
• Methods doGet (line 65) and doPost (line 74) merely call the method processRequest (line 40).
• processRequest performs the following actions:
  • Sets the content type for the response (line 42).
  • Obtains an output stream (line 43).
  • Writes HTML to the output stream (lines 45-54).
  • Uses request.getParameter to get the value of the "name" form parameter (line 51).
  • Closes the output stream (line 56).

Contrast the Java code here with the first Perl CGI program we looked at (mynameis2.pdf). You can see how concepts like getting the form parameters and producing the output translate directly from one language to the other.

More example servlets

webapp1 home page

HelloYou.java (test if within the University firewall only) shows how servlets can access a variety of information from the request object. As well as parameters to the request, it can also access HTTP headers, the request URI, and the context and servlet paths.

HelloMIME.java (test if within the University firewall only) shows some of the things you can do with the response object, including setting the MIME content type for the output document, sending HTTP errors, and outputting non-textual documents. It also shows how the servlet context can be used to refer to resources (such as files) in the web application.