Understanding Tomcats Architecture

Understanding Tomcat’s Architecture

The latest version of Tomcat is 5.x, which supports the Servlet 2.4 and JSP 2.0 specifications. It consists of a nested hierarchy of components.

  • Top-level components exist at the top of the configuration hierarchy in a rigid relationship with one another.

  • Connectors connect the servlet container to requests, either from a browser or another Web server that’s handling the static resources.

  • Container components contain a collection of other components.

  • Nested components can reside in containers but can’t contain other components.

Figure 1-1 illustrates the structure of a Tomcat configuration.

image from book
Figure 1-1: An example Tomcat configuration. The components marked with a star can occur multiple times.

When configuring Tomcat, you can remove some of these objects without affecting the server. Notably, the engine and host may be unnecessary if you’re using a Web server such as Apache.

You won’t be surprised to hear that Tomcat is configured with an Extensible Markup Language (XML) file that mirrors the component hierarchy. You’ll learn about this file, called server.xml, in Chapter 4.

In the next couple of sections, you’ll look into each component in turn.

Top-Level Components

The top-level components are the Tomcat server, as opposed to the other components, which are only parts of the server.

The Server Component

The server component is an instance of the Tomcat server. You can create only one instance of a server inside a given Java virtual machine (JVM).

You can set up separate servers configured to different ports on a single server to separate applications so that you can restart them independently. So, if a given JVM crashes, the other applications will be safe in another instance of the server. This is sometimes done in hosting environments where each customer has a separate instance of a JVM so that a badly written application won’t cause others to crash.

The Service Component

A service component groups an engine component with its connectors. An engine is a request-processing component that represents the servlet engine. It examines the HTTP headers to determine to which host or context (that is, which Web application) it should pass the request. Each service is named so that administrators can easily identify log messages sent from each service.

So, this component accepts requests, routes them to the appropriate Web application, and returns the result of the request processing.

The Connector Components

Connectors connect Web applications to clients. They’re the point where requests are received from clients, and each has a unique port on the server. Tomcat’s default HTTP port is 8080 to avoid interference with any Web server running on port 80, the standard HTTP port. However, you can change this as long as the new port doesn’t already have a service associated with it.

The default HTTP connector implements HTTP 1.1. The alternative is the Apache JServ Protocol (AJP) connector, which is a connector for linking with Apache in order to use its Secure Sockets Layer (SSL) and static content-processing capabilities. I’ll discuss each of these in Chapter 9.

The Container Components

The container components receive the requests from the top-level components as appropriate. They then deal with the request process and return the response to the component that sent it to them.

The Engine Component

The engine component is the top-level container and can’t be contained by another container component. Only one may be contained in each service component.

The top-level container doesn’t have to be an engine, because it only has to implement the container interface. This interface ensures the object implementing it is aware of its position in the component hierarchy, provides a realm for user authentication and role-based authorization, and has access to a number of resources including its session manager and some important internal structures.

The container at this level is usually an engine, so you’ll see it in that role. As mentioned earlier, the container components are request-processing components, and the engine is no exception. In this case it represents the Catalina servlet engine. It examines the HTTP headers to determine to which virtual host or context to pass the request. In this way you can see the progression of the request from the top-level components down the hierarchy of components.

If Tomcat is used as a stand-alone server, the defined engine is the default. However, if Tomcat is configured to provide servlet support with a Web server providing the static pages, the default engine is overridden, as the Web server has normally determined the correct destination for the request.

The host name of the server is set in the engine component if required. An engine may contain hosts representing a group of Web applications and contexts, each representing a single Web application.

The Host Component

A host component is analogous to the Apache virtual host functionality. This allows multiple servers to be configured on the same physical machine and be identified by separate Internet Protocol (IP) addresses or host names. In Tomcat’s case, the virtual hosts are differentiated by a fully qualified host name. Thus, you can have http://www.apress.com and http://www.moodie.com on the same server. In this case, the servlet container routes requests to the different groups of Web applications.

When you configure a host, you set its name; the majority of clients will usually send both the IP address of the server and the host name they used to resolve the IP address. The engine component inspects the HTTP header to determine which host is being requested.

The Context Component

The final container component, and the one at the lowest level, is the context, also known as the Web application. When you configure a context, you inform the servlet container of the location of the application’s root folder so that components that contain this component can route requests effectively. You can also enable dynamic reloading so that any classes that have changed are reloaded into memory. This means the latest changes are reflected in the application. However, this is resource intensive and isn’t recommended for deployment scenarios.

A context component may also include error pages, which will allow you to configure error messages consistent with the application’s look and feel.

Finally, you can also configure a context with initialization parameters for the application it represents and for access control (authentication and authorization restrictions). More information on these two aspects of Web application deployment is available in Chapter 5.

The Nested Components

The nested components are nested within container components and provide a number of administrative services. You can’t nest all of them in every container component, but you can nest many of them this way. The exception to the container component rule is the global resources component, which you can nest only within a server component.

The Global Resources Component

As already mentioned, this component may be nested only within a server component. You use this component to configure global Java Naming and Directory Interface (JNDI) resources that all the other components in the server can use. Typically these could be data sources for database access or serverwide constants for use in application code.

The Loader Component

The loader component may be nested only within a context component. You use a loader to specify a Web application’s class loader, which will load the application’s classes and resources into memory. The class loader you specify must follow the Servlet specification, though it’s unlikely you’ll find it necessary to use this component, because the default class loader works perfectly well.

The Logger Component

This component is available only in Tomcat 5.0.x and not in Tomcat 5.5.x. You should use a logging implementation such as Log4J with Tomcat 5.5.x, more of which is covered in Chapter 4.

A logger component reports on the internal state of its parent component. You can include a logger in any of the container components. Logging behavior is inherited, so a logger set at the engine level is assigned to every child object unless overridden by the child. The configuration of loggers at this level can be a convenient way to decide the default logging behavior for the server.

This allows you to configure a convenient destination for all logging events for the components that aren’t configured to generate their own logs.

The Manager Component

The manager component represents a session manager for working with user sessions in a Web application. As such, it can be included only in a context container. A default manager component is used if you don’t specify an alternative, and, like the loader component mentioned previously, you’ll find that the default is perfectly good.

The Realm Component

The realm for an engine manages user authentication and authorization. As part of the configuration of an application, you set the roles that are allowed to access each resource or group of resources, and the realm is used to enforce this policy.

Realms can authenticate against text files, database tables, Lightweight Directory Access Protocol (LDAP) servers, and the Windows network identity of the user. You’ll see more of this in Chapter 11.

A realm applies across the entire container component in which it’s included, so applications within a container share authentication resources. By default, a user must still authenticate separately to each Web application on the server. (This is called single sign-on.) You’ll see how you can change this in Chapter 7.

The Resources Component

You can add the resources component to a context component. It represents the static resources in a Web application and allows them to be stored in alternative formats, such as compressed files. The default is more than sufficient for most needs.

The Valve Component

You can use valve components to intercept a request and process it before it reaches its destination. Valves are analogous to filters as defined in the Servlet specification and aren’t in the JSP or Servlet specifications. You may place valve components in any container component.

Valves are commonly used to log requests, client IP addresses, and server usage. This technique is known as request dumping, and a request dumper valve records the HTTP header information and any cookies sent with the request. Response dumping logs the response headers and cookies (if set) to a file.

Valves are typically reusable components, so you can add and remove them from the request path according to your needs; Web applications can’t detect their presence, so they shouldn’t affect the application in any way. (However, performance may suffer if a valve is added.) If your users have applications that need to intercept requests and responses for processing, they should use filters as per the Servlet specification.

You can use other useful facilities, such as listeners, when configuring Tomcat. However, filters aren’t defined as components. You’ll deal with them in Chapter 7.



Pro Jakarta Tomcat 5
Pro Apache Tomcat 5/5.5 (Experts Voice in Java)
ISBN: 1590593316
EAN: 2147483647
Year: 2004
Pages: 94

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net