The Structure of a Web Application | Professional Java Servlets 2.3

< Free Open Study >

Armed with the knowledge of what web applications contain, and why they were introduced, we will now look at how a simple web application is structured.

The directory structure of a web application is strictly defined. This directory structure consists of two parts:

Each web application has a unique context path in which all of its components reside. Within the root directory of the web application is a special subdirectory called WEB-INF that contains all private web application components that cannot be accessed by the client. This can include servlet class files, deployment descriptors, external libraries, and any other private files used by the application.
All files outside of WEB-INF are considered public in that they can be accessed by name from the client. Typical examples of public resources include static HTML pages, JSP pages, and images.

To illustrate this structure, a simple web application called SimpleWebApp could have the following directory structure:

     SimpleWebApp/                  index.html                  main.jsp                  images/                         company.jpg                         divider.jpg                  admin/                        admin.jsp                  WEB-INF/                          web.xml                          classes/                                  servlets/                                           LoginHandler.class                                           ShoppingCart.class                          lib/                              xerces.jar                          xalan.jar

It is simple to see that the public resources for the above web application are one HTML file (index.html), two JSP files (main.jsp and admin/admin.jsp), and two JPEG images (images/company.jpg and images/divider.jpg.) The remaining resources, those that are under the WEB-INF directory, are not available to the client, and are resources to be used exclusively by the web container.

A resource that is termed as public in a web application is any resource that can be directly downloaded by the client and rendered in their browser in the usual way. The resource is delivered to the client and it is the responsibility of their browser or application to make correct use of that resource.

Although JSP pages are included in the public directories of a web application, they are not sent directly to the client unmodified. When a client requests a JSP, it is compiled into a servlet, executed, and the resulting HTML is sent to the client. This might look like a lot of overhead, but it actually only happens the first time that the JSP is requested. You can learn more about JSP pages in Chapter 8. As well as these public resources, there are many resources in a web application that should not be directly accessed or downloaded by the user. These resources include servlets, JSP pages, Java class files or any other components that contain the request processing logic behind our web application, as well as configuration files such as the deployment descriptor web.xml. Private resources are placed in the WEB-INF directory, which must be present in the top-level of the web application. As you can see, the deployment descriptor is placed in the top-level of the WEB-INF directory, while any classes used by the web application are located in the classes folder, which is also placed in the top-level of WEB-INF. Finally, the web application may also make use of JAR files, which should be added to the library directory (lib), again located in the top-level of WEB-INF.

Using a structure such as this for your web application offers several immediate advantages. The first of these is that multiple web applications can coexist within one web container. Structuring web applications in this way allows the web container to easily understand which components belong to which web application, thus avoiding problems such as naming conflicts (for instance two different servlets could have the same name in two different web applications).

The second major advantage is that the web container knows where to look to load classes for your web application. The classpath was always a problem with web application development in the past. It was always hard to tell where classes were being loaded from. However, with this rigidly structured approach, the classloader knows that it should look in the classes and lib directories to find classes, so you do not need to explicitly add all of the JAR files used by your application to your system's classpath.

Web Application Archives

Once you have your web application in the structure detailed above, there are two options for deployment. The first, and simplest option, is to copy the whole directory structure to the web applications directory of your web container. For Tomcat this directory is the webapps directory (%CATALINA_HOME%/webapps). This method of deployment is known (for obvious reasons!) as Exploded Directory Format. This is by far the best way to deploy an application in a development scenario, or any scenario where a small number of files in your web application will change frequently. In order to make changes to an element in your web application, you simply copy the modified files into the appropriate point in the directory structure.

Although this format is ideal for development, it is far from an ideal way to deploy applications in a production environment, or for a situation where you wish to move your application between different web containers. Although it is possible to just copy the directory structure between servers, imagine a scenario where you have to do this via a command line file transfer program. It would take a significant amount of effort to transfer each individual file and directory.

Fortunately for us, there is a very simple mechanism for packaging web applications so that they can easily be deployed on many different servers and containers. This format is known as the Web Application Archive, or WAR format. A WAR file is simply an archived version of the directory structure mentioned above. The WAR file is easily created using the standard Java jar tool, although other commercially-available archiving tools can be used (for example WinZip). The reason that a Web Application Archive does not have the standard Java archive extension (.jar) is to indicate that the archive has a different purpose. A WAR file represents a full structured web application and not just an archive of (possibly unrelated) Java classes.

We will see many examples of WAR file creation later in this chapter, but here's a quick example of how we could create a WAR file at the command line. First we would move to the top-level of the web app, and then we would issue the command:

     jar -cv0f SimpleWebApp.war .

This would create a WAR file called SimpleWebApp.war that would contain the contents of the current directory. We can examine the contents of such a file using the following command:

     jar -tvf SimpleWebApp.war

You can refer to the Java Development Kit documentation for additional information about other configuration options for the jar tool. Using WinZip is another quick and easy way to open WAR files and examine their contents.

Once we have created a WAR file, a J2EE-compliant web container (or application server) will automatically deploy the application on start-up. The only caveat to this is that the application is placed in the correct directory. For Tomcat this directory is webapps. If you place the archive file in this directory and restart the Tomcat server, the container will automatically deploy the application. The application will be deployed with its name set as the name of the WAR file minus the .war extension (so for the example WAR file above, we could access the application at http://localhost:8080/SimpleWebApp/)

While WAR files are great for moving web apps between containers, they are not so appropriate to use during development. Imagine changing one file in your web application archive. In order to re-deploy the application you would have to re-archive it first. This could be fairly time-consuming for a large application, so it's usually better to use the Exploded Directory Format described above. WAR files become more appropriate the closer to a production environment you get. It is wonderfully simple to take a WAR file and deploy it to a new server for testing, for example.

It is envisaged that over time a market for WAR files will exist. As the format becomes more popular and more people develop web applications, WAR files will be available as plug-in components for web containers. These components could be downloaded from a web site, copied to the right place, and be capable of processing user requests right away, irrespective of web container.

It is worth noting at this point that although it is recommended, it is not mandatory that a web container uses the web application structure as their runtime representation. All J2EE-compliant web containers must be able to accept a web application for deployment, but what they do to that application from that point on, is undefined. For example, we deployed the SimpleWebApp application to the Tomcat container, it would be automatically copied into the %CATALINA_HOME%/work/localhost/SimpleWebApp directory. This is where files are really taken from when requested. This facilitates the hot deployment of applications, as it is guaranteed that the files in the webapps directory will not be in use to service requests.

< Free Open Study >