# Presentation: 725681

## Components for Web Applications

- Marcia Perry
- Distributed Systems Department
- Ernest Orlando Lawrence Berkeley National Laboratory
- August 14, 2001

## Organization

- Major Components
- Overview of the Build Process
- Configuration
- URL to File System Mappings
- Starting/Stopping Web Server Processes
- More Information

**Notes:**
To give a high-level perspective, I’ll go over the ‘basics’ first.  Then look at the major components—what we used, what the components do, and how they interoperate.  Next I’ll present an overview of our build process, pointing out some of the gotchas.   I’ll next discuss one possible configuration and show how apache and tomcat translate URLs to file system paths.  Then I’ll show some practical ways to start and stop apache and tomcat and end w/ a list of pointers to more information.

## Basic Components

**Web server**:  application that responds to HTTP requests by returning ‘web’ resources (e.g., HTML files, images, applets, CGI output, ...) over the Internet
**CGI** **(Common Gateway Interface)**:
- conventions used by a web server to execute programs
- early technique for creating dynamic content
- scripts/apps executed by web server

**Notes:**
CGI commonly used to process form data or access a database

## Advanced Components

- Servlets:
- Java classes loaded into and run by a JVM (requires a servlet ‘container’)
- In response to HTTP requests
- To extend web server functionality
- Adv. over CGI:
- Java (one language, portability, convenience, type-checking, error-handling, ...)
- Efficiency (classes usually loaded once; not necessarily run as separate process)

## Advanced Components

- import java.servlet.*; import java.servlet.http.*; import java.io.*;
- public class HelloWWW extends HttpServlet {
- 	public void doGet(HttpServletRequest req, HttpServletResponse resp)
- 		throws ServletException, IOException {
- 	   resp.setContentType(“text/html”);
- 	   PrintWriter out = resp.getWriter();
- 	   out.println(“<html><body>Hello WWW</body></html>”);
- 	   out.close();
-      }
- }

- HelloWWW.java

## Servlet Containers

- Servlet containers can be:
- Standalone:  Integral part of web server (as when using a Java-based web server)
- Add-on component to web server:  Java container implementation + web server plugin
- Servlet code runs inside Java container
- Java container runs inside of JVM
- Web server plugin opens JVM

## Advanced Components

**JSPs (Java Server Pages)**:  for mixing static content w/ dynamically generated content
- JSPs are automatically translated into servlets behind the scenes
- More convenient to write/modify
- Separates content from presentation

## Advanced Components

- <HTML><HEAD><TITLE>Welcome to Our Store</TITLE></HEAD>
- <BODY><H1>Welcome to Our Store</H1>Welcome,
- <!-- User name is ‘New User’ for first time visitors -->
**<%= Utils.getUserNameFromCookie(request) %>**
- To access your account settings, click <A HREF=“Account-Settings.html”> here.</A>
*Regular HTML for the rest of the on-line store’s web page.*
- </BODY></HTML>

- Sample JSP page

## Advanced Components

**Applets**:  Java code that runs inside browser
- Advantages:
- Extends functionality on the client side
- More complicated GUIs than w/ HTML or JavaScript
- Computation can be off-loaded from server
- Users don’t have to build, install, and configure
- Disadvantages:
- Download time
- “Sandbox” limits functionality (unless signed)
- Window management by browser

## Advanced Components

**JavaScript**
- Interpretive language w/ object-oriented capabilities
- Allows including executable content within web pages (e.g., window management, further processing)
- Both client and server side

## Apache

**Apache**:  “Industrial strength” HTTP/1.1 compliant web server
- Highly configurable
- Implements many features in addition to its core functionality (e.g., security/access control, virtual hosting, CGI script execution, ...)
- Extensible with third-party modules (e.g., servlet engine, security, WebDAV, ...)

**Notes:**
From the available web servers and servlet containers, we went w/ Apache and Tomcat.
Some of the additional features of apache come as optional modules within the apache distribution while others are available by 3rd –party modules.

## Modules for Apache

**mod-ssl** (secure HTTP communication between a browser and a web server):
- Provides strong cryptography for privacy
- Provides use of digital signatures for data integrity
- Allows server and/or client authentication
- Integrates SSL/TLS protocols w/ Apache (via OpenSSL)
**mod-dav **(publishing into the web environment):
- Provides server support for WebDAV (web-based distributed authoring and versioning)
- Implements WebDAV extensions to HTTP 1.1
- )

## Tomcat

**Tomcat**: Java-based web server + servlet container w/ JSP environment
-  Execution modes:
**Standalone**:  default mode for Tomcat
**Out-of-process add-on**:  web server plugin opens JVM outside web server; plugin and JVM communicate using IPC mechanism (TCP/IP sockets and special protocol)
- Most popular!!

## Tomcat Execution Modes

**Standalone**
- Not as fast as Apache for static pages
- Not as configurable as Apache
- Not as robust as Apache
- May not support functionality found only in Apache modules (e.g., Perl, PHP, security)
- Mainly for development and debugging

## Tomcat and Apache

- Communication mechanism between Tomcat and Apache:
- Termed “web server adapter” or “connector”
- Implemented as library (e.g., mod_jserv.so, mod_jk.so)
- Uses/manages TCP connections
- Uses the AJPV12/AJPV13 communication protocol

**Notes:**
AJPV stands for “Apache Jserv Protocol Version”
Note that the Tomcat mod_jserv.so started out w/ the old mod_jserv from the Apache Jserv Project, but the mod_jserv from Apache is obsolete and they are not the same!

## A Basic Installation

- servlet

**Notes:**
To get the best of both worlds, we went w/ using Tomcat for servlets/JSPs and Apache for everything else.  There are 3 config files that tie all this together, which I’ll show in later slides.

## How Apache & Tomcat Interoperate

- http://host/path/to/resource

- Apache in standalone mode; Tomcat in out-of-process add-on mode

**Apache**

- adapter

**Notes:**
1). A URL comes in to Apache in an HTTP (or HTTPS) request from a client
2). Apache knows from the URL that it must forward the request to Tomcat and invokes its web server adapter to handle the Apache-Tomcat connection and hand off the request to Tomcat.  Communication between the adapter and Tomcat is NOT HTTP—it is via the Apache Java Protocol (AJP).  Basically, the adapter sends a request to serve a particular file from a particular “context”.  The request is NOT a URL as used w/ HTTP.

3). Tomcat does internal processing and generates output.
4). Tomcat returns this output via the Tomcat-Apache connection
5). Apache returns the output to the client.

## Building and Installing Apache and Tomcat

- Apache supports statically-linked and dynamically-linked modules (DSOs)
- Script to automate the build/configure process: www-itg.lbl.gov/Grid/projects/WebServer-SG.html
- Step-by-step procedure: www-itg.lbl.gov/~mperry/apache_build.html

## Overview of the Build Process

- Assumptions:
- Java already installed (JDK 1.2/JDK1.3)
- APACHE = /usr/local/apache
- TOMCAT = /usr/local/tomcat
- Build OpenSSL (needed for mod_ssl)
- Configure mod_ssl
- Build mod_dav.a
- Build and install Apache w/ DSO support

**Notes:**
Choose the modules you want.  If they’re going to be statically linked in, you may have to build them first in their own source tree.  If you’re building a dynamically-linked module, then you need to build Apache first since, in addition to building the Apache binary, it builds other tools, one of which is used to build dynamic objects.

## Configuration

**Apache**:
**httpd.conf**  (in APACHE/conf/): master configuration file
**tomcat-apache.conf** (generated by tomcat at startup from tomcat.conf): included in httpd.conf to give mod_jserv info about Tomcat
**Tomcat** (in TOMCAT/conf/):
**server.xml**: global configuration file for Tomcat
**tomcat.conf**: for interoperability between Apache & Tomcat
**web.xml**: deployment descriptor; configures Tomcat web applications (contexts) by mapping web app components and properties

**Notes:**
Httpd.conf is for overall config of Apache, tomcat-apache.conf is generated by Tomcat when it starts and must be included in httpd.conf.
server.xml is for the overall config of Tomcat; tomcat.conf lets Apache work w/ Tomcat by telling apache which requests should be forwarded to the adapter and telling the adapter which URLs it should serve and what port to use for connecting to Tomcat.
You need a web.xml file for each web app, but there is a generic global one that is the default.

## Configuring the Ports

**Apache**

**Tomcat**

- Default configuration

- http/8080

## Configuring the Ports

**server.xml**
**<!– disable webserver on port 8080 **
-        <Connector className=“org.apache.tomcat.service.SimpleTcpConnector”>
-               <Parameter name=“handler” value=“org.apache.tomcat.service.http.HttpConnectionHandler”/>
-  	<Parameter name=“port” value=“8080”/>
-        </Connector>
**-->**
-        <Connector className=“org.apache.tomcat.service.SimpleTcpConnector”>
- 	<Parameter name=“handler” value=“org.apache.tomcat.service.connector.Ajp12ConnectionHandler”/>
- 	<Parameter name=“port” value=“8007”/>
-        </Connector>

## Configuring the Ports

**tomcat.conf**
- #Tell Apache to load the shared object communication module
- LoadModule jserv_module libexec/mod_jserv.so
- # Set communication protocol and port
- ApJServDefaultProtocol ajpv12
- ApJServDefaultPort 8007

## Configuring the Ports

**httpd.conf**
- ServerRoot “/usr/local/apache”
- # Here’s where we can overwrite default ports
- Port 80
- <IfDefine SSL>
- Listen 80
- Listen 443
- </IfDefine>
- <VirtualHost _default_:443>

**Notes:**
We’ll come back to these files as we look at more configuration, such as the next topic, setting up the file system and mapping URLs to that file system.

## Sample File System

**	****	****APACHE**

**	****	****       ****TOMCAT**

**Notes:**
This sample file system structure is used for purposes of explaining how to configure the web server’s file system and how apache and tomcat map URLs to the file system.  Of course you may want to change it!  

SSL is implemented by using Apache’s virtual hosting capability (one web server appears as more than one) and so I have a document root for each virtual host.  Having 2 directories (htdocs and securedocs) makes it clear which ones are accessible by HTTP or HTTPS.
In this file system structure, we have 3 document roots: htdocs is the doc root for HTTP requests sent to apache on port 80 and securedocs is the doc root for HTTPS requests sent to apache on port 443; webapps is what Tomcat uses as its doc root.

## URL to File System Mappings

**httpd.conf**
- DocumentRoot “/usr/local/apache/htdocs”
- <IfDefine SSL>
- # General setup for the virtual host
- DocumentRoot “/usr/local/apache/securedocs”
- # Lots of stuff
- </IfDefine>
- Include /usr/local/tomcat/conf/tomcat-apache.conf

- http://hostname  /  foo/                          /usr/local/apache/htdocs/ foo/

- https://hostname  /  foo/                          /usr/local/apache/securedocs/ foo/

**Notes:**
Now that we see how apache translates URLs into file system paths, let’s take a side trip and look at how to restrict access to files and directories, and then we’ll look at how tomcat maps URLs to file system paths.

## Apache Directory Access

- Restrict access on per-directory basis via **httpd.conf**.
- <Directory />
- 	AllowOverride None
- </Directory>
- <Directory “/usr/local/apache/htdocs/webDAVdir”>
- 	Order deny, allow
- 	Deny from all
- 	Allow from .lbl.gov
- 	DAV On
- </Directory>

**Notes:**
Here are some slides showing ways to restrict directory access.

The first Directory entry means to ignore .htaccess files in the root directory.  The second directory entry applies to the webDAVdir subdirectory in htdocs.  Here I’m first denying everyone access and then allowing hosts in the .lbl.gov domain to have read and write access.  The “DAV On” entry is to turn on webDav in this directory. The next slide shows how to break access down further.

## Apache Directory Access

- Per-directory access restriction (httpd.conf)
- <Directory “/usr/local/apache/htdocs/webDAVdir”>
- 	Order deny, allow
- 	<Limit GET POST >
- 		Deny from all
- 		Allow from .lbl.gov
- 	</Limit>
- 	<Limit PUT DELETE MKCOL COPY MOVE LOCK UNLOCK>
- 		Deny from all
- 		Allow from 131.243.2
- 	</Limit>
- </Directory>

**Notes:**
Here I’m using the Limit directive within a directory to allow the .lbl.gov domain to do essentially ‘read’ operations (get, post) and allowing only one subnet within this domain to do what are essentially ‘write’ operations.  We could specify individual hosts, additional subnets, etc.

## Tomcat File System

- index.html

## URL to File System Mappings

**tomcat-apache.conf**
- AddType text/jsp .jsp
- AddHandler jserv-servlet .jsp
- Alias /examples /usr/local/tomcat/webapps/examples
- ApJServMount  /examples/servlet  /examples
- <Location /examples/WEB-INF/ >
- 	AllowOverride none
- 	deny from all
- </Location>

**Notes:**
Using mod_jserv, Apache uses the tomcat-apache.conf file to recognize which requests to hand off to Tomcat.  The AddType and AddHandler entries register the JSP type w/ Apache and instruct Apache to have all JSP requests handled by the jserv-servlet handler.  From Wainright (p. 159):  We can use aliases to locate resources somewhere else other than document root.  The Alias directive allows a file path prefix to be substituted for a URL prefix before Apache attempts to relate the URL to a file location.  It takes 2 parameters: the URL to alias and the path to alias it to.  The alias entry here tells Apache the location of the ‘examples’ context so that Apache can serve files from this directory (such as static HTML files).  A ‘context’ represents a path in the Tomcat hierarchy where you put a web application.  For Tomcat, contexts are mapped to paths in server.xml and contexts are configured in the web.xml for that context.  Basically ApJServMount entries mount ‘contexts’ to Tomcat so that Apache can direct known URLs to Tomcat.  ApJServMount entries are in the form:
ApJServMount <URI> <Tomcat process location and context in URL format>
The Tomcat process location and context can be a relative or full path and can even specify a Tomcat process on another host, e.g., ApJServMount /myapp/servlet ajpv12://myTomcastHost:1234/some/path
This says “Any request that starts with <URI> should be passed on to <Tomcat process location and context> for execution.  The ApJservMount entry shown here tells Apache to forward all requests for servlets (URLs starting with /examples/servlet) to Tomcat.  You should have as many such mount directives as the number of specific servlet URLs.  The first field of a ApJServMount entry tells Apache which requests to forward to Tomcat and the second field is the context that Tomcat should serve from.   The second ApJServMount entry tells Apache to send all requests for URLs that start w/ “/servlet” to Tomcat and tells Tomcat to use “/ROOT” as the context.
 The Location directive instructs Apache to protect the WEB-INF directory from client access so no one can view its contents.  NOTE:  Keep this file in APACHE/conf!
Tomcat writes this file each time it starts so it will overwrite any changes you made (as for new web apps or contexts), so by keeping this file in the APACHE directory and including the APACHE tomcat-apache.conf file in httpd.conf is a good idea.  Note that if we replace mod_jserv with mod_jk, we’ll replace this config file with a config file specific for mod_jk.

## URL to File System Mappings

**server.xml**:
- 	<Context path=“/examples”  docBase=“webapps/examples” debug=“0” 	reloadable=“true”
-    </Context>

- SIDE NOTES: (1) ‘path’ is used in URLs; ‘docBase’ is actual directory name on f/s. They do NOT have to match!  (2)Tomcat docs recommend turning on **servlet auto-reloading only for development**.

**Notes:**
The server.xml file maps a context to a “docBase”.  Here the ‘examples’ context is located in the path “webapps/examples”, which Tomcat adds to the path of its home directory—in our case, the full path would be /usr/local/tomcat/webapps/examples.   SIDE NOTE:  Apparently Tomcat (at least v3.1) finds and loads new contexts automatically when it starts up so new entries for new contexts aren’t really needed.  But installing a new context does require restarting Tomcat (and probably making tomcat-apache.conf entries).

NOTE: The name of ‘Context path’ (here, /examples) does NOT have to be the same as the actual name of the directory!

## Configuring a Context

**web.xml**
- <web-app>
-    <servlet>
- 	 <servlet-name>MyServlet</servlet-name>
- 	 <servlet-class>SimpleServlet</servlet-class>
-    </servlet>
-    <servlet-mapping>
- 	 <servlet-name>MyServlet</servlet-name>
- 	 <url-pattern>/docservlet/*</url-pattern>
-    </servlet-mapping>
- </web-app>

- URLs

- http[s]://*server*/*context*/*url*-*pattern*/*servlet-name *||* servlet-class*
*    *
- ‘servlet’ = default url-pattern

- http://shaggy/
-     examples/servlet/MyServlet
-     examples/servlet/SimpleServlet
-     examples/docservlet/MyServlet
-     examples/docservlet/NewServlet

## Starting Tomcat

- Do NOT start Tomcat as root.
- Create a new user account or use an existing one.
- Use the ‘startup.sh’ script in TOMCAT/bin
- If necessary add or modify entries for JAVA_HOME, TOMCAT_HOME, and CLASSPATH.

**Notes:**
NOTE:  Be sure that the files and directories have ownership, groups, and permissions that are with your configuration.

## Tomcat Startup Script

- TOMCAT/bin/startup
- #!/bin/sh
- TOMCAT_HOME=/usr/local/tomcat
- export TOMCAT_HOME
- PATH=/usr/local/java/bin:$PATH
- export PATH
- CLASSPATH=$CLASSPATH:/usr/local/MyJavaPkg:.
- export CLASSPATH
- BASEDIR=`dirname $0`
- $BASEDIR/tomcat.sh start “$@”

## Executing Apache

- Specify user and group to run as (in httpd.conf):
- User nobody
- Group 	cpc
- Remember to add libexec/ to LD_LIBRARY_PATH
- Start Apache as root:
- 	# cd /usr/local/apache/bin
- 	# ./apachectl startssl

**Notes:**
Apache can be started by root.  It will fork processes to actually handle client requests.  These child httpd processes are run as the user and group specified in httpd.conf.  NOTE:  The docs say to start tomcat first since it writes the tomcat-apache.conf file that httpd needs.  But, if you run tomcat once and keep this file in the Apache Home Directory’s conf subdirectory, you can start tomcat in any order.  And you only have to start the process whose configuration you changed.

## Starting Apache

** **Sample startup script:  APACHE/start
- #!/bin/sh
- LD_LIBRARY_PATH=/usr/local/apache/libexec:/usr/local/openssl-0.9.6:$LD_LIBRARY_PATH
- export LD_LIBRARY_PATH
- /usr/local/apache/bin/apachectl startssl
- echo “Apache started”

**Notes:**
Note that version compatibilities exist between openSSL, mod_ssl, and apache.  The mod_ssl website specifies which versions to use.

## Starting Apache

- Usage:  APACHE/bin/httpd [-d directory] [-v] [-h] [-l]...
- 		-d:  specify alternative ServerRoot
- 		-v:  show version number
- 		-h:  list available command line options
- 		-l:  list compiled-in (static) modules

## Stopping Apache/Tomcat

- Tomcat
- As ‘tomcat user’ run TOMCAT/bin/shutdown.sh
- Apache
- As root, use apachectl (or write a ‘stop’ script):
- # cd /usr/local/apache/bin
- # ./apachectl stop
- 	        OR
- # cd /usr/local/apache
- # ./stop

**Notes:**
The “stop” script in the APACHE toplevel directory just invokes ‘apachectl stop’.

## More Information

- Wainright, P., “Professional Apache,” Wrox Press Ltd.
- http://www.webdav.org/
- http://httpd.apache/org/docs/
- http://jakarta.apache.org/tomcat/
- http://java.sun.com/products/servlet/download/

## More Information

- http://www.ccl.net/cca/software/UNIX/apache/
- http://www-itg.lbl.gov/~mperry/apache_build.html
- http://www-itg.lbl.gov/Grid/projects/WebServer-SG.html
- https://idcg-ca.lbl.gov
- http://www.modssl.org/