An introduction to Tomcat servlet interactions

Although its flexible configuration and interoperability with supporting technologies have enabled Apache Tomcat to act as a web application server in many circumstances, Tomcat is primarily a Java servlet container.  

Utilizing its implementation of the Java Servlet and JSP APIs, Tomcat is able to receive requests from a client, dynamically compile a container-managed Java class to handle the request as specified in the relevant application Context, and return the result to the client.  This method of generating dynamic content enables extremely fast, threaded, platform independent processing of requests.  

Furthermore, as the Java Servlet specification is designed for interoperability with all other major Java web technologies, a servlet hosted on a Tomcat server is able to leverage any resource that Tomcat makes available to it.  Tomcat's nested hierarchical XML configuration files allow for extremely fine-grained resource access control, while maintaining loose coupling, ease of deployment, and logical, human-readable architecture descriptions.  

In this article, we'll take a look at how Apache Tomcat uses Servlets to quickly deliver a wide range of dynamic content to a client.

Tired of tedious, error-prone deployment? Tcat deployment packages allow you to deploy sets of servlets and web applications to multiple Tomcat instances with a single click. Try Tcat today!

How Tomcat works with servlets

One of the key requirements worked into the Servlet specification is that they only are expected to handle certain parts of the total data transaction process.  For example, the servlet code itself will never listen for requests on a certain port, nor will it communicate directly with a client, nor is it responsible for managing its access to resources.  Rather, these things are managed by Tomcat, the servlet container.  

This allows servlets to be re-used in a wide variety of environments, or for components to be developed asynchronously from one another - a connector can be re-factored for improved efficiency without any changes to the servlet code itself, as long as no major changes are made.

Servlet life cycles

As managed components, servlets have a life cycle, which begins when the managing container loads the servlet class, usually in response to a request, and ends when the container closes the servlet by calling the "destroy" method.  All the servlet's activity between these two points is considered part of its life cycle.

The lifecycle of a typical servlet running on Tomcat might look something like this:

  1. Tomcat receives a request from a client through one of its connectors.
  2. Tomcat maps this request to the appropriate Engine for processing.  These Engines are contained within other elements, such as Hosts and Servers, which limit the scope of Tomcat's search for the correct Engine.
  3. Once the request has been mapped to the appropriate servlet, Tomcat checks to see if that servlet class has been loaded.  If it has not, Tomcat compiles the servlet into Java bytecode, which is executable by the JVM, and creates an instance of the servlet.
  4. Tomcat initializes the servlet by calling its init method.  The servlet includes code that is able to read Tomcat configuration files and act accordingly, as well as declare any resources it might need, so that Tomcat can create them in an orderly, managed fashion.
  5. Once the servlet has been initialized, Tomcat can call the servlet's service method to process the request, which will be returned as a response.
  6. During the servlet's lifecycle, Tomcat and the servlet can communicate through the use of listener classes, which monitor the servlet for a variety of state changes.  Tomcat can retrieve and store these state changes in a variety of ways, and allow other servlets access to them, allowing state to be maintained and accessed by various components of a given context across the span of a single or multiple user sessions.  An example of this functionality in action is an e-commerce application that remembers what the user has added to their cart and is able to pass this data to a checkout process.
  7. Tomcat calls the servlet's destroy method to smoothly remove the servlet.  This action is triggered either by a state change that is being listened for, or by an external command delivered to Tomcat to undeploy the servlet's Context or shut down the server.

Combination of components

Using servlets and the resources they access in conjunction with static HTML pages and JSP pages, which contain a mixture of HTML and Java code, and can call servlet methods using either native tag libraries or custom tags, Tomcat is able to present a user with a dynamic, secure, persistent web application.  

For example, a user might access a page where dynamic user interface objects are handled client-side with AJAX, CSS, and HTML5 interacting with the DOM, while user information is pulled from a database via a JSP tag that interacts with a servlet method.  This allows the presentation of a page to be completely separated from any business logic, for improved security and design flexibility.   

Further reading

In addition to this guide, we provide several guides that go into more depth about how Tomcat uses servlets:

  • Tomcat Deploy - A simple guide to deploying and configuring a servlet on your Tomcat Server.
  • Tomcat JSP - An in-depth look at JSP, a Java technology that uses elements of the Servlet specification, including an overview of its structure and a best practices guide.
  • Tomcat Context - An easy-to-follow, comprehensive introduction to Tomcat's container-based management model.  This is essential reading for anyone getting started with servlets.