Tomcat Architecture 5

Tomcat architecture include the following roles:
❑ Connectors
❑ Engines
❑ Realms
❑ Valves
❑ Loggers
❑ Hosts
❑ Contexts


The Server
The Server is Tomcat itself — an instance of the Web application server — and is a top-level component. It owns a port that is used to shut down the server. In addition, the Server can be set in debug mode,which instantiates a version of the Java Virtual Machine (JVM) that enables debugging.
Only one instance of the Server can be created inside a given Java Virtual Machine (JVM).
Separate Servers configured to different ports can be set up on a single machine to separate applications so that they can be restarted independently. That is, if one Server running in a JVM were to crash, the other applications would be safe in another Server instance. This is sometimes done in hosting environments in which each customer has a separate instance of a JVM, so a badly configured/written application will not cause others to crash.
The Service
A Service groups a container (usually of type Engine) with that container’s Connectors and is a top-level component.
An Engine is a request-processing component that represents the Catalina Servlet engine. It examines the HTTP headers to determine the virtual host or context to which requests should be passed.
Each Service represents a grouping of Connectors (components that manage the connection between the client and server) and a single container, which accepts requests from the Connectors and processes the requests to present them to the appropriate Host. Each Service is named so that administrators can easily identify log messages sent from each Service.
In other words, the container contains the Web applications. It is responsible for accepting requests,routing them to the specified Web application and specific resource, and returning the result of the pro-cessing of the request. Connectors stand between the client making the request and the container.They provide additional services such as SSL support.
The Connectors
Connectors connect the applications to clients. They represent the point at which requests are received from clients and are assigned a port on the server. The default port for nonsecure HTTP applications is kept as 8080 to avoid interference with any Web server running on the standard HTTP port, but there is no reason why this cannot be changed as long as the port is free. Multiple Connectors may be set up for a single Engine or Engine-level component, but they must have unique port numbers.
The default port to which browsers make requests if a port number is not specified is port 80. If Tomcat is run in standalone mode, the port for the primary Connector of the Web application can be changed to 80 by reconfiguring this component.
The default Connector is Coyote, which implements HTTP 1.1. Alternative Connectors are Apache JServ Protocol (AJP), an SSL Connector for secure connections, and an HTTP 1.0 Connector. These are discussed as part of Chapters 10–13, which deal with Tomcat’s Connectors and integrating Tomcat with Web servers such as Apache and IIS.
The Engine
The next component in the architecture is the top-level container — a container object that cannot be contained by another container. This means that it is guaranteed not to have a parent container. It is at this level that the objects begin to aggregate child components.
Strictly speaking, the container does not need to be an Engine, it just has to implement the container interface. This interface mandates the following: that the object implementing it is aware of its position in the hierarchy (it knows its parent and its children), that it provides access to logging, that it provides a Realm for user authentication and role-based authorization, and that it has access to a number of resources, including its session manager (and some internally important aspects that you do not need to worry about).
In practice, the container at this level is usually an Engine and so it makes sense to discuss it in that role.
As mentioned previously, an Engine is a request-processing component that represents the Catalina Servlet engine. It examines the HTTP headers to determine the virtual host or context to which requests should be passed. When the standalone configuration is used, the Engine that is used is the default one. This Engine doesthe checking mentioned earlier. When Tomcat is configured to provide Java Servlet support for a Web server, the default class used to serve requests is overridden because the Web server has normally determined the correct destination of the request.The host name of the server to which the Engine belongs is set here in multi-homed machines. An Engine may contain hosts representing a group of Web applications and contexts representing a single Web application.
The Realm
The Realm for an Engine manages user authentication and authorization. During the configuration of an application, the administrator sets the roles that are allowed for each resource or group of resources, and the Realm is used to enforce this policy.

Realms can authenticate against text files, database tables, LDAP servers, and the Windows network identity of the user.

A Realm applies across the entire Engine or top-level container, so applications within a container share user resources for authentication. This means that, for example, a manager for the intranet will have the same rights as the manager of the e-commerce site should both these applications be in the same Engine.
By default, a user must still authenticate separately to each Web application on the server. You will see how this can be changed in Chapter 8 using Single Sign-on, but, in brief, this is implemented as a Valve in Tomcat.
The Valves
Valves are components that enable Tomcat to intercept a request and pre-process it. They are similar to the filter mechanism of the Servlet specifications, but are specific to Tomcat. Hosts, contexts, and Engines may contain Valves.
Valves are commonly used to enable Single Sign-on for all Hosts on a Server, as well as log request patterns, client IP addresses, and server usage patterns (peak traffic, bandwidth use, mean average requests per time unit, the resources that most requests ask for, and so on). This is known as request dumping,and a request dumper Valve records the header information (the request URI, accept languages, source IP, host name requested, and so on) 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, and can therefore be added and removed from the request path according to need. Their inclusion is transparent to Web applications, although the response time will increase if a Valve is added). An application that wishes to intercept requests for pre-processing and responses for post-processing should use the filters that are a part of the Servlet specifications.
A Valve may intercept a request between an Engine and a Host/context, between a Host and a context, and between a context and a resource within the Web application.
The Loggers
Loggers report on the internal state of a component. They can be set for components from top-level containers downward. 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 establishes a convenient destination for all logging events for those components that are not specially configured to generate their own logs.
The Host
A Host mimics the popular Apache virtual host functionality. In Apache, this enables multiple servers to be used on the same machine, and to be differentiated by their IP address or by their host name. In Tomcat, the virtual hosts are differentiated by a fully qualified host name. Thus, the two Web sites www.websitea.com and www.websiteb.com can both reside in the same server, with requests for each routed to different groups of Web applications.Configuring a Host includes setting the name of the host. The majority of clients can be depended on to send both the IP address of the server and the host name they used to resolve the IP address. The host
name is provided as an HTTP header that an Engine inspects to determine the Host to which a request should be passed.

If the Host is not within an Engine, it is possible that it is the top-level container.

The Context Finally, there is the Web application, also known as a context. Configuration of a Web application includes informing the Engine/Hosts of the location of the root folder of the application. Dynamic reloading can also be enabled so that any classes that have been changed are reloaded into memory.However, this is resource-intensive, and is not recommended for deployment scenarios. The context may also include specific error pages, which enable a system administrator to configure error messages that are consistent with the look and feel of the application, and usability features (such as a search Engine, useful links, or a report-creating component that notifies the administrator of errors in the application).