Web Applications with Java/JSP

All the cool new programming languages, like Ruby, always have compilers/interpreters and tools for Linux, and the old UNIX standbys like Tcl/Tk are still around when you need them. Why, then, is Java not a ubiquitous player in the Linux arena?

Linux and Java really do have a lot to offer each other. Both are rock-solid and scalable server-class software systems, and most college and university graduates with software-related degrees are familiar with them, making for a powerful combination. In this article, I introduce you to Java Web applications through the Java Servlet Specification, the Java programming language itself and Java Server Pages. These three tools can help you get a Web application running in a lot less time than you think.

The Java Servlet Specification defines a Servlet Container, a Web application and the Servlet API, which is the glue that holds these pieces together.

A Servlet Container is analogous to a Web server, but it also knows how to deploy and manage Web applications, and so it often is known as an Application Server. The Servlet Container provides services that support the Servlet API, which is used by the Web application to interact with HTTP requests and responses.

A Java Web application is a self-contained collection of configuration files, static and dynamic resources, compiled classes and support libraries that are all treated as a cohesive unit by the Servlet Container. They are somewhat different from standard LAMP-style Web applications, which are more like collections of associated programs or scripts than formally defined, self-contained units. To demonstrate a Java Web application, I have developed a simple “timesheet” featuring some of the standard Java libraries that helped me write it.

Typically, a Web application is packaged in a WAR (Web ARchive) file, which is just a ZIP file with a special directory structure and configuration file layout. The directory structure of the Web application logically and physically separates these types of files. The WEB-INF directory contains all the configuration files, a lib directory contains all libraries (packaged in JAR, or Java ARchive files), and a classes directory contains the application's compiled code. Listing 1 shows the file layout of the Web application for reference.

index.jsp
tasks.jsp
WEB-INF/web.xml
WEB-INF/lib/jstl-impl-1.2.jar
WEB-INF/lib/jstl-api-1.2.jar
WEB-INF/classes/lj/timesheet/Task.class
WEB-INF/classes/lj/timesheet/GetTasksServlet.class
WEB-INF/classes/lj/timesheet/BaseServlet.class
WEB-INF/classes/lj/timesheet/Client.class
WEB-INF/classes/lj/timesheet/SaveTaskServlet.class
WEB-INF/classes/ApplicationResources_en.properties
WEB-INF/classes/ApplicationResources_de.properties
WEB-INF/classes/ApplicationResources.properties
WEB-INF/classes/ApplicationResources_es.properties
WEB-INF/classes/ApplicationResources_fr.properties
META-INF/context.xml
META-INF/MANIFEST.MF

The WEB-INF directory also contains a special file, web.xml, which is known as the Web application's deployment descriptor. It defines all the behaviors of the Web application, including URI mappings, authentication and authorization. Let's look at the deployment descriptor for this Web application.

<?xml version="1.0" encoding="ISO-8859-1" ?>

<web-app xmlns="http://java.sun.com/xml/ns/javaee"
    
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
        http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    version="2.5">

  <servlet>
    <servlet-name>get-tasks</servlet-name>
    <servlet-class>lj.timesheet.GetTasksServlet</servlet-class>
  </servlet>

  <servlet>
    <servlet-name>save-task</servlet-name>
    <servlet-class>lj.timesheet.SaveTaskServlet</servlet-class>
  </servlet>

  <servlet-mapping>
    <servlet-name>get-tasks</servlet-name>
    <url-pattern>/tasks</url-pattern>
  </servlet-mapping>

  <servlet-mapping>
    <servlet-name>save-task</servlet-name>
    <url-pattern>/save-task</url-pattern>
  </servlet-mapping>

  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Protected Pages</web-resource-name>
      <url-pattern>/tasks</url-pattern>
      <url-pattern>/save-task</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>*</role-name>
    </auth-constraint>
  </security-constraint>

  <login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>Timesheets</realm-name>
  </login-config>

  <security-role>
    <description>Users of the timesheet application</description>
    <role-name>user</role-name>
  </security-role>
</web-app>

You can see that each servlet is defined in a <servlet> element that defines the Java class that contains the code, as well as a name for the servlet (to be used later). After the servlets have been defined, they are then mapped (by name) to incoming URIs using <servlet-mapping> elements. This servlet mapping may seem tedious and verbose, but it can be very powerful for several reasons:

After the servlet mappings come container-managed authentication and authorization. The Servlet Specification requires that Servlet Containers provide mechanisms for authentication and authorization, and the configuration in the Web application is declarative: web.xml simply specifies what resources are protected and who is allowed to access them, using role-based authorization constraints. The setup is quite straightforward, and the Web application becomes simpler by not having to implement that capability inside the application. In this application, I've chosen to use HTTP BASIC authentication to simplify the application. DIGEST, FORM and (SSL) CLIENT-CERT are other options allowed by the Servlet Specification.