Java Web Applications

A Java Web application consists of one or more servlets, JSP files, utility classes, files with static content (such as HTML, image, audio and video files), client side applets and associated classes, and meta information to tie together these components. This meta information is also known as the Web application deployment descriptor.

A servlet is nothing but a application-specific Java class that extends abstract class javax.servlet.http.HttpServlet and overrides methods such as doGet() and doPost() to process corresponding HTTP requests. Servlets are deployed within a J2EE Web container. JSPs are related to servlets but offer a different approach, known as a page-oriented approach, to develop Web applications, allowing developers to focus on the layout and content of the page to be displayed by the Web browser. Internally, within the container, JSP files get transformed into servlets and the processing of requests takes place in the same way as with servlets.

A J2EE Web container is essentially an HTTP server capable of hosting compliant Web applications. The hosting requirement includes support for deployment mechanisms, dispatch of request messages and provisioning of runtime services.

This container is responsible for accepting HTTP connections, reading the request message, converting it to appropriate Java objects, and invoking the appropriate methods of the appropriate servlet. The specific servlet method to be invoked by the Web container depends on the HTTP method of the request: doGet() for HTTP-GET, doPost() for HTTP-POST and so on. These methods are the entry points for the application code.

Selection of the appropriate servlet by the Web container for dispatching a particular HTTP request is more complicated and depends upon the full request URI, the different Web applications deployed within the Web container and the mappings specified in the deployment descriptors.

On the file system, the files comprising a Web application exist within a structured hierarchy of directories, the root of the hierarchy serving as the document root for the Web application. This root corresponds to the context path in the Web container. We will take a look at an example to illustrate these entities, but before that let us understand the directory structure holding different components of a Web application.

As we just mentioned, a Web application is rooted in a specific directory. This directory must have a subdirectory named WEB-INF, which may have deployment descriptor file web.xml and subdirectories classes and lib to hold the .class and .jar files, as shown below:

<root-dir>
        WEB-INF
                web.xml
                classes
                lib

This directory tree can be archived into a single WAR (Web ARchive) format file with .war extension, using the jar utility.

A Web application is deployed in a container-specific manner. A common deployment mechanism is to copy the directory tree rooted at the document root or the corresponding WAR file into a specific directory designated for this purpose. The name of this directory is webapps for the the popular Web container Apache Tomcat.

Let us illustrate this mechanism with the help of an example Web application, which we call Example ch9-rmb. Here RMB stands for Rudimentary Message Board, for this example implements the functionality of a very rudimentary message board. The directory structure of this example is shown in Listing 9-1.

Listing 9-1. Example ch9-rmb Web application directory structure

rmbindex.jsp
   ask_post.jsp
   post.jsp
   sel4rem.jsp
   
emove.jsp
   WEB-INFweb.xml
           classes
mbMessageBean.class
                       MessageBoard.class

We talk more about this example and the specific files in a subsequent section. For the time being, let us focus only on its directory structure and the deployment process. To deploy RMB, one could simply copy the directory tree rooted at rmb to the webapps directory. In this case the document root is webapps mb and the context path is /rmb.

The Web container reads the deployment descriptor of all the deployed Web applications on startup and performs the necessary initializations. Whether a particular Web application gets loaded at the start of the Web container or at the receipt of the first request targeted to the application depends upon a specific parameter, load-on-startup, set in the deployment descriptor.

On receipt of an HTTP request, the Web container determines the target servlet, wraps the request within a javax.servlet.http.HttpServletRequest and invokes the appropriate method of the target servlet. The servlet method extracts the information contained within the HttpServletRequest object, carries out the necessary processing steps, writes back the response to the corresponding HttpServletResponse object and returns. The control is back to the Web container, which forms the HTTP response message from the HttpServletResponse object.

For HTTPS connections, the Web container is responsible for carrying out SSL-related activities and supplying a server certificate to the client. The processing steps are the same for HTTPS requests, the only difference being the fact that a SSL server socket is used to accept the connection.

Depending upon the configuration details in the deployment descriptor, the Web container may also do some pre-processing before dispatching the request and some post-processing after getting the response. A specific kind of pre-processing, the one related to user authentication and URL access control based on the user role, is quite relevant for us and we talk more about it later in this chapter.

There is lot more to Web applications, servlets, JSPs, and Web containers than we can cover here. Please refer to the references in the section Further Reading for more information.

As we noted earlier, certain deployment and operational aspects depend on specifics of the Web containers. Hence, to keep the discussion concrete, we need to pick a specific Web container. As mentioned earlier, our choice is Apache Tomcat.