Java Application Server Overview

Revised: November 16, 2004

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
• Application Servers
• Web Applications
• Logging
• Security

Overview

MOREnet manages multiple Java application servers for deployment of customer web applications. Web applications can utilize a MySQL database, send e-mail, and provide dynamic content to supplement your web site.

Important: This document assumes that you are familiar with the local development environment for developing and testing your web site and web applications. For more information, see Local Development.

Application Servers

The kinetic Service provides three Java Application Servers. These include the following:

• Primary Server #1. This server is the primary Java Application Server. The Apache Web Server is configured to forward requests for web applications to this server by default.
• Failover Server #2. This server is the failover Java Application Server. If the primary server fails, requests will automatically be directed to this server. In addition to failover use, this server is also available if MOREnet must perform maintenance on the primary application server.
• Spare Server #3. This server is configured but not running. It is used when the other two servers are unavailable.

Each application server is an instance of the Tomcat 4 servlet container from the Apache Software Foundation's Jakarta Project. It is written in Java and runs using the Java 2 SDK, Standard Edition, version 1.4. It implements the Java Servlet 2.3 and JavaServer Pages 1.2 specifications.

Web Applications

A Web application is installed by uploading its web application archive .war file to your web site document root directory. See Web Application Overview for details about managing web applications.

The Apache web server and Tomcat application servers are configured so that Apache serves static files such as HTML and images. If the web server recognizes that a request to your web site is for a Java Servlet or JavaServer Page, that request is forwarded to Tomcat for processing. The following mapping identifies which HTTP requests are forwarded to Tomcat for processing:

/*.jsp - Any request which has a jsp file extension.
/*/servlet/* - Any request where the second path component is named servlet.
/*.do - Any request ending with the struts framework action extension of .do.

Important: This configuration allows Apache to access files in your web application, so you can use standard Apache .htaccess files to restrict access to your web application.

The Apache web server is configured to prevent access to any directories with the name WEB-INF or META-INF. It also forbids access to any .war files located in your www directory.

Logging

Web Server Request and Error Logs

All requests for documents on your site are handled by the Apache web server. If a request is for a Java Servlet or JavaServer Page, the web server forwards that request to the Tomcat servlet container for processing. Because of this, your web server access and error logs contain entries for requests of Java Servlets and JavaServer Pages. These files are used by the Analog Web Statistic reports. For more information about logging and reports, see the "Default Directories Within All Web Sites" section of Web Site File Guidelines and Directory Structure, and the Reports section of this site.

Web Application Logs and Work Directories

When you view your web site using FTP, you will see a tomcat directory in addition to the logs and www directories. The tomcat directory contains a logs directory for web application log files and three work directories for the three application servers (work1, work2, and work3). The log file names are in the form of tomcatX_log-YYYY-MM-DD.txt, where X is the number of the app server listed above (1, 2, or 3), YYYY is the year, MM is the month, and DD is the day.

Important: The last 30 days of logs are retained. Application logging and Java Exceptions thrown by your applications are sent to the log files. If your web application will not start properly or run-time exceptions occur when you attempt to use it, please start your troubleshooting process by reviewing the logs.

Security

kinetic server security is very important. Security is what mimimizes the chance of a kinetic server being compromised or a web site being defaced. Because security is important, Tomcat is configured to use the Java SecurityManager.

The Java SecurityManager is typically used by programs such as web browsers and applet viewers to run untrusted code within a controlled environment. For example, the Java SecurityManager allows a web browser to run an applet in its own "sandbox" to prevent potentially harmful code from accessing files on the local system or connecting to a host other than the one from which the applet was loaded.

In the same way that the SecurityManager protects you from an untrusted applet running in your browser, it assists in protecting Tomcat and the server from trojan servlets, JSPs, JSP beans, and tag libraries. In some cases it can even help protect the server from inadvertent coding mistakes. For example, imagine if someone invadvertently included the following in a JSP:

<% System.exit(1); %>

Tomcat would exit every time that JSP was executed and would no longer be available to process requests. However, the SecurityManager settings prevent this situation from happening by restricting run-time Java operations such as exit(). In addition, the SecurityManager settings allow you to constrain activities for a variety of other operations, such as file I/O and network connections.

In summary, the Java SecurityManager is another line of defense a system administrator can use to keep the server secure and reliable.

Security Policy Settings

The Java SecurityManager is implemented via a security policy. The policy is flexible and may include the following types of permissions:

• File Permissions -- Read, write, delete, and execute permissions on a per directory or file basis.
• Socket Permissions -- Network connection permissions by host domain or IP address and port.
• Property Permissions -- Permissions to read or write java properties in the Java Virtual Machine (JVM) such as java.home.
• Runtime Permissions -- Permissions for security-sensitive Java runtime operations like exit() and exec().

Configuring the Security Policy

MOREnet system administrators must configure the security policies for any web applications that you deploy. Before putting a web application into production, please test your application on your own test version of Tomcat with the SecurityManager enabled and identify what permissions will be required. The local development environment provides a security policy that is similar to the policy on production customer application servers. Contact MOREnet Systems & Programming to schedule placing your application into production and provide them with information about the required security permissions.