Top Level Components

The Server and Service container components exist largely as structural
conveniences. A Server represents the running instance of Tomcat and contains
one or more Service children, each of which represents a collection of request
processing components.

Server

A Server represents the entire Tomcat instance and is a singleton within a
Java Virtual Machine, and is responsible for managing the life cycle of its
contained services.

The following image depicts the key aspects of the Server component. As shown,
a Server instance is configured using the server.xml configuration file. The root
element of this file is <Server> and represents the Tomcat instance. Its default
implementation is provided using org.apache.catalina.core.StandardServer,
but you can specify your own custom implementation through the className
attribute of the <Server> element.

A key aspect of the Server is that it opens a server socket on port 8005 (the default)
to listen a shutdown command (by default, this command is the text string
SHUTDOWN). When this shutdown command is received, the server gracefully shuts
itself down. For security reasons, the connection requesting the shutdown must be
initiated from the same machine that is running this instance of Tomcat.

A Server also provides an implementation of the Java Naming and Directory
Interface (JNDI) service, allowing you to register arbitrary objects (such as data
sources) or environment variables, by name.

At runtime, individual components (such as servlets) can retrieve this information by
looking up the desired object name in the server’s JNDibindings.

While a JNDiimplementation is not integral to the functioning of a servlet container,
it is part of the Java EE specification and is a service that servlets have a right to
expect from their application servers or servlet containers. Implementing this
service makes for easy portability of web applications across containers.

While there is always just one server instance within a JVM, it is entirely possible to
have multiple server instances running on a single physical machine, each encased
in its ownjVM. Doing so insulates web applications that are running on one VM
from errors in applications that are running on others, and simplifies maintenance
by allowing a JVM to be restarted independently of the others. This is one of the
mechanisms used in a shared hosting environment (the other is virtual hosting,
which we will see shortly) where you need isolation from other web applications
that are running on the same physical server.

Service

While the Server represents the Tomcat instance itself, a Service represents the set of
request processing components within Tomcat.

A Server can contain more than one Service, where each service associates a group
of Connector components with a single Engine.

Requests from clients are received on a connector, which in turn funnels them
through into the engine, which is the key request processing component within
Tomcat. The image shows connectors for HTTP, HTTPS, and the Apache JServ
Protocol (AJP).

There is very little reason to modify this element, and the default Service instance is
usually sufficient.

A hint as to when you might need more than one Service instance can be found in
the above image. As shown, a service aggregates connectors, each of which monitors
a given IP address and port, and responds in a given protocol. An example use case
for having multiple services, therefore, is when you want to partition your services
(and their contained engines, hosts, and web applications) by IP address and/or
port number.

For instance, you might configure your firewall to expose the connectors for one
service to an external audience, while restricting your other service to hosting
intranet applications that are visible only to internal users. This would ensure that
an external user could never access your Intranet application, as that access would
be blocked by the firewall.

The Service, therefore, is nothing more than a grouping construct. It does not
currently add any other value to the proceedings.

	The server and service components are covered in more detail in

	Chapter 5, The Server and Service Components.

Connectors

A Connector is a service endpoint on which a client connects to the Tomcat
container. It serves to insulate the engine from the various communication protocols
that are used by clients, such as HTTP, HTTPS, or the Apache JServ Protocol (AJP).

Tomcat can be configured to work in two modes—Standalone or in Conjunction with
a separate web server.

In standalone mode, Tomcat is configured with HTTP and HTTPS connectors,
which make it act like a full-fl edged web server by serving up static content when
requested, as well as by delegating to the Catalina engine for dynamic content.

Out of the box, Tomcat provides three possible implementations of the HTTP/1.1
and HTTPS connectors for this mode of operation.

The most common are the standard connectors, known as Coyo te which are
implemented using standard Java I/O mechanisms.

You may also make use of a couple of newer implementations, one which uses the
non-blocking NIO features of Java 1.4, and the other which takes advantage of native
code that is optimized for a particular operating system through the Apache Portable
Runtime (APR).

Note that both the Connector and the Engine run in the same JVM. In fact, they run
within the same Server instance.

In conjunction mode, Tomcat plays a supporting role to a web server, such as
Apache httpd or Microsoft’s IIS. The client here is the web server, communicating
with Tomcat either through an Apache module or an ISAPiDLL. When this
module determines that a request must be routed to Tomcat for processing, it will
communicate this request to Tomcat using AJP, a binary protocol that is designed
to be more efficient than the text based HTTP when communicating between a web
server and Tomcat.

On the Tomcat side, an AJP connector accepts this communication and translates it
into a form that the Catalina engine can process.

In this mode, Tomcat is running in its ownjVM as a separate process from the
web server.

In either mode, the primary attributes of a Connector are the IP address and port on
which it will listen for incoming requests, and the protocol that it supports. Another
key attribute is the maximum number of request processing threads that can be
created to concurrently handle incoming requests. Once all these threads are busy,
any incoming request will be ignored until a thread becomes available.

By default, a connector listens on all the IP addresses for the given physical machine
(its address attribute defaults to 0.0.0.0). However, a connector can be configured
to listen onjust one of the IP addresses for a machine. This will constrain it to accept
connections from only that specified IP address.

Any request that is received by any one of a service’s connectors is passed on to
the service’s single engine. This engine, known as Catalina, is responsible for the
processing of the request, and the generation of the response.

The engine returns the response to the connector, which then transmits it back to
the client using the appropriate communication protocol.

	This component is covered in more detail in Chapter 6,

	The Connector Component.

Comments

comments