Web Application Design Guidelines

Revised: April 14, 2003

Important: The Java application server and MySQL database are not included as part of the kinetic Service annual fee. These technologies are available on an as-requested basis for an additional fee. Contact David Drum at david@more.net or (800) 509-6673 for additional information.

Contents

• Overview
• Tomcat 4 Application Server
• Apache Web Server
• Java APIs Installed with Tomcat
• MySQL Database Usage
• Sending E-mail
• Portability
• Remote Client Sessions
• General Tips for Application Design

Overview

This document provides technical guidelines to use when designing a Java web application for deployment on a server hosted as part of the kinetic Service. It includes information about the server environment and configuration to make it easier for you to develop and deploy a web application. Application design best practices are also discussed to help you design your web application so that it runs efficiently, reduces request latency, and scales well as traffic to your web site grows.

Tomcat 4 Application Server

Tomcat 4 is installed as the application server (servlet container) in which your web applications run. Tomcat 4 implements the Java Servlet 2.3 and JavaServer Pages (JSP) 1.2 specifications. Tomcat is installed on a Sun Sparc server running the Solaris 8 UNIX OS with the latest released version of the Java 1.3 JVM from Sun. Tomcat 4 runs with the Java SecurityManager enabled and a strict Java security policy.

Apache Web Server

The Apache web server is used to serve requests for web pages from your web site. A recent version of Apache 2.0 is installed on a Sun Sparc running the Solaris 8 UNIX OS.

Apache uses mod_jk to connect to Tomcat and pass along any requests for servlets or JSPs in your web applications. The Apache mod_jk module is configured to forward all requests for /{web-application-directory}/servlet/* and *.jsp to Tomcat for processing. Requests for *.do used by the Struts controller are also forwarded to Tomcat.

HTTP requests for the following directories and files return the HTTP 403 error code (Access Forbidden):

• /{web-application-directory}/WEB-INF/
• /{web-application-directory}/META-INF/
• /*.war (web archive files in the root directory for web site content)

You can use Apache .htaccess files within your web applications to have Apache restrict access to sensitive resources. For more information about restricting access with .htaccess files, see Web Access Controller.

Static files within your web applications, such as image and html files, are served directly by Apache. This is more efficient than having Tomcat serve all requests.

Caution: Apache will not honor any security restraints you specify in your web application web.xml configuration. Consider using an Apache .htaccess file instead.

Web application WAR files and web application directories can be placed in the /www directory, the root directory for web site content.

The Apache web server has Server Side Include (SSI) enabled for all files which have the file extensions .shtml and .shtm. Content generated by web application JSP pages, servlets, and *.do files (used by the Struts framework) can also include SSI statements. These statements are interpreted by Apache when it processes page requests if the content is of mime type text/html. By using SSI in your web applications, you can easily include common components from your web site, such as headers and footers, in your web applications without duplicating the content in both the web site and your applications. For more information about Server Side Includes, see Apache Tutorial: Introduction to Server Side Includes.

Note: For performance reasons the Apache web server does not resolve the IP addresses of remote clients to their hostname. Because of this the HttpServletRequest getRemoteHost() method will always return a null String.

Java APIs Installed with Tomcat

The most recently released versions of the following Java APIs are available for use by your web application. There is no need for your web application to install these in its /WEB-INF/lib directory.

• JDBC 2.0 Extensions
• Java Activation Framework
• Java Mail
• Java Naming and Directory Interface (JNDI)
• Java Secure Socket Extension (JSSE)
• Java Transaction API (JTA)
• MySQL JDBC Driver
• Xerces XML (JAXP compatible) Parser
• Xalan XSLT stylesheet processor
• Jakarta-Commons DBCP
• Jakarta-Commons Pool
• Jakarta-Commons Collections

MySQL Database Usage

A recent version of MySQL 3.23 is installed on a Sun Sparc running Solaris 8 UNIX OS.

Establishing a Database Connection

The application server provides an easy way for your application to establish a connection to the database for your web site. The server supports use of the Java Naming and Directory Interface (JNDI) to access a Java DataBase Connection (JDBC).

A JNDI named JDBC DataSource is made available for use by any web application you install in Tomcat for your web site. The JNDI name for this connection is:

java:/comp/env/jdbc/data

Your application can use the JNDI named JDBC DataSource either by using the DBTags JSP Tag Library, the JSP Standard Tag Library, or directly using Java code. See the Creating Your First Database-enabled Web Application Tutorial for an example of using DBTags with a JNDI named JDBC DataSource.

Database Connection Pooling

Database connection pooling improves the performance of applications which use a database by maintaining a pool of database connections and reusing them. Establishing a new connection to a database delays page processing and can be the main source of latency between the time a page is requested and the time it is returned to the site visitor. Use of a connection pool improves the performance of your application.

The JNDI named JDBC DataSource provided by the application server implements database connection pooling for you. If your application uses the JNDI named JDBC DataSource, there is no need for your application to implement database connection pooling.

Caution: Your application must make sure it closes each JDBC ResultSet, Statement, and Connection. Failure to close these prevents that database connection from being re-used. This results in your application failing due to not being able to get a connection to the database.

Database Object Caching

Database object caching is a middleware technology used to persist and cache objects from a database and can significantly improve performance. Specifically, an object cache addresses performance issues such as delays from database query latency and unnecessary thrashing of the JVM for creation and subsequent garbage collection of objects created for result sets.

The Jakarta Object Relational Bridge project: http://jakarta.apache.org/ojb has additional information for those interested in this type of performance tuning.

MySQL Privileges

MySQL uses an access privilege system to implement security. The following MySQL privileges are granted to the database connection your application uses:

Select

Insert

Update

Delete

Efficient use of MySQL

See the MySQL Best Practices document for information on how to best use and not abuse the MySQL database.

Sending E-mail

The application server provides an easy way for your application to send e-mail. The server supports use of the Java Naming and Directory Interface (JNDI) to send e-mail via a JavaMail MimePartDataSource.

A JNDI named MimePartDataSource is made available for use by any web application you install in Tomcat for your web site. The JNDI name for this connection is:

java:/comp/env/mail/send

Your application can use the JNDI named MimePartDataSource either by using the Mailer JSP Tag Library or directly using Java code. See the JSP examples which come with the kinetic Tomcat4 Local Development distribution for an example of using the Mailer JSP Tag Library with a JNDI named MimePartDataSource.

Portability

Please design the web application so that it is self contained and portable between your development server and the production server. If you don't have to make any changes when installing the web application on the production server, maintenance and updating of your application will be easier and less error prone. Here are some tips for keeping your application portable:

Use of file based resources

File based resources within the web application should be obtained using a web application context relative path so that the application is portable between the development server and the production server.

For more information, see the Java documentation for the ServletContext getResource() methods.

Database Access

Use the JNDI named JDBC DataSource for database access. This abstracts out the database, connection, user, and password from the application so it can be seamlessly moved between the development server and the production server.

Remote Client Sessions

A servlet container can store information about a remote user's usage of your application by using a Session. A Session should not be created for a remote client (user) unless you need to track information about the user's usage of your application between HTTP requests. Creating Sessions for remote users when your application doesn't need them creates additional unnecessary work for the servlet container.

If your applications use JavaServer Pages (JSP), the default behavior of a JSP page is to create a Session. Please use the following JSP page directive at the top of each JSP page to explicitly disable Sessions if you don't need them:

<%@ page sessions="false" %>

General Tips for Application Design

Please do not turn your entire web site into a web application using JSP pages. This is not very efficient. Apache serves static files much faster than Tomcat serves dynamic content generated from JSP. Serving as much content as possible using static .html or .shtml files improves your site's performance and reliability.

Do not design your site to use JSP for generating HTML for content that changes infrequently. You might be tempted to store news stories, announcements, etc. in the database and then use JSP to generate pages for your web site. If this content, which resides in the database, changes infrequently (several dozen times a day), you are essentially using JSP to serve mostly static content. In this case we recommend that you use a build system which generates static html pages from the content of the database, and then publish those static pages to your web site. This will make your site more efficient and reliable.

If your application uses JSP, try to avoid embedding Java code in the JSP. Try to use JSP tags and JSP custom tag libraries instead. This will make your JSP pages much easier to maintain and less prone to failure. If your application requires business logic, put that logic in Java Beans or your own JSP custom tag library.

If you have a page on your web site which only has a small portion of it generated by JSP, create the page as a .shtml page and use SSI to include the output of the JSP page for the dynamic portion of the web page content.