Tomcat Architecture (II)

5. Container Components

In this section we will discuss the request processing component: engine, virtual host, context component.

5.1. Engine

The engine represents a Catalina instance of the servlet engine that can be run and contains the core functionality of the servlet container. There can be only one engine in a service. Also, as a true container, the engine element can contain one or more virtual hosts.

As the primary component of the request processing, it receives the object representing the incoming request and outputs the corresponding result. Its primary function is to delegate incoming requests to the appropriate virtual host for processing. If a managed virtual host is not found by name, the default host is used to determine which virtual host to process.

5.2. Virtual Host

The virtual host is represented in Tomcat using the host component, which is a Web application container or a context referred to in Tomcat.

There are two concepts in a virtual host that are important-the host's domain name and root directory.

• Domain Name: Each virtual host is identified by its registered domain name (example: www.host1.com). The domain name is the value you expect to enter in the client browser address bar, which is the request header for the virtual host. The name of a virtual host must be unique within the engine that contains it.

• Root directory: The folder where the root is located contains the context that will be deployed to this host. The root directory can be either an absolute path or a relative path to catalina_base.

Catalina_home is an environment variable that references the location of a tomcat binary file. With the CATALINA_BASE environment variable, you can run multiple Tomcat instances based on different configurations using only a binary file of the Tomcat installation information (which is primarily determined by the contents of the Conf folder).

Also, use a catalina_base reference location (unlike catalina_home) to keep the standard binary allocations separate from your installation. This is beneficial, making it easy for Tomcat to upgrade to a new version without worrying about affecting published Web applications and related configuration files.

Basic concepts

When it comes to the host name Mapping to the Internet Protocol address, the simplest scenario, a given fully qualified hostname (FQHN), such as www.swengsol.com, is associated with the IP address mapped to a specific host.

The disadvantage of this approach is that the host connection to the Internet is quite expensive. This is true, especially when you consider bandwidth costs, network infrastructure (e.g. database/mail servers, firewalls, uninterruptible power ups, fault tolerance, etc.) and maintenance (including staffing, management, and backup), not to mention getting an IP address first.

As a result, many small businesses think the best approach is to lease space and infrastructure from a managed service provider. A managed service may be a single physical server that can be connected to the Internet and identified by a specific IP address. This physical server can host multiple domain names, each representing a provider's customers.

For example, we assume that Acme Widgets Inc and Vertico LLC have their domain names, www.acme-widgets.com and www.vertico.com, which are hosted on the same physical server. Applications are deployed to their respective domains and do not interfere with each other.

In this case, these domains are called virtual hosts, and in this sense each domain appears to be a separate "physical host." In fact, however, they are just different logical partitions on the same physical host.

5.3. Virtual Host Technology

There are two common ways to set up a virtual host:

• Virtual hosting services based on independent IP addresses

• Name-based virtual hosting service

5.3.1 Virtual Host service based on independent IP address

With this technique, each fqhn (fully qualified hostname) is resolved to a separate IP address. However, each of these IPs is parsed and mapped to the same physical machine.

You can use the following mechanisms to implement this technique:

• Multihomed server, which means that it has multiple network cards (NICs) installed, each with an IP address assigned

• Use the operating system feature to set up a virtual network interface to dynamically assign multiple IP addresses to a single physical NIC (NIC)

In either case, the disadvantage is that we want to obtain multiple IP addresses, and these addresses (at least for IPV4) are a limited resource.

The Web server listens for the ports assigned to these IP addresses, and it generates the response information for the IP address when the Web server detects an incoming request at a specific IP address.

For example, you have a Web server that runs on a specific physical host that listens on 80 ports for 11.156.33.345 and 11.156.33.346 IP address requests. This Web server responds to requests when it receives a request from the host domain name www.host1.com, which is mapped to the 11.156.33.345 IP address, and to the subsequent IP address when it receives a request from the host domain name www.host2.com 11.156.33.346.

When a request is received from a 11.156.33.346 IP address, the Web server knows that it should prepare the response information for the ww.host2.com corresponding domain. To the user, this is a completely separate physical server that is serving him.

5.3.2 Name-based virtual hosting service

This is a relatively new technique that allows you to map different domain names to the same IP address. These are registered normal domain names, and multiple DNS entries map these domain names to the same IP address.

The HTTP 1.1 protocol requires that each request must contain a master header: a fully qualified host domain name, and the port number that the user wants to connect, if one is specified. The Web server running on the host receives this request and resolves the host header information in this request to determine the appropriate virtual host to respond to this request. Simple, and do not use unnecessary IP addresses, name-based virtual hosting service is our first choice.

However, when you use SSL (Secure Sockets Layer) and virtual hosts at the same time, you may have to use an IP address-based virtual hosting service. The reason is that before a particular virtual host responds to a request, the negotiation protocol is authenticated for the certificate. This is because the SSL protocol layer is located below the HTTP protocol layer, and the module that is requesting security authentication with the client cannot read the HTTP request header information until the handshake message authentication is complete.

You may be able to use both SSL and the name-based virtual host service if your Web server and client support RFC 3546 (Transport Layer Security extension http://www.ietf.org/rfc/rfc3546.txt) to specify the server name identity extension. With this extension, during the SSL negotiation, the client transmits the host name to the object it is trying to connect to, allowing the Web server to process the handshake information and return the certificate for the correct host name.

Virtual Host Aliases

When the Web server resolves the alias information, such as when it sees the alias name in the host header, the Web server treats the alias as the domain name of the virtual host. For example, if you set the swengsol.com as the alias of the virtual host domain name www.swengsol.com, you will receive a response from the same virtual host, whether you enter the domain name or alias in the client URL. This works well when a physical host has multiple domain names, and you don't want to mess up the configuration file when you create a set of entries for each alias.

5.4. Contextual (context)

A context or Web application is where the application of custom code (servlet, JSP) survives. It facilitates the organization of resources for Web applications.

At the same time, the context container provides a ServletContext instance for the servlet. In many ways, the servlet specification is primarily concerned with this context component. For example, it specifies the format of the deployment context and the descriptor for the deployment content.

The following are some important properties of the context:

• Root directory: This path refers to the directory in which the war package or the uncompressed project file is stored, either relative or absolute.

• Context Path: It refers to the part of a URL that uniquely identifies a web app under a host. It helps the host container to determine which context is deployed to handle incoming requests.

Perhaps you have configured the default context, which can handle incoming requests without finding a matching context. The default context can be tagged by configuring its context path to be empty, so it can be accessed by a path that has only a hostname (such as http://localhost:8080/). And the context has been defined by Tomcat by default as the root directory under the Roots directory.

• Auto Reload (automic reload): The resources in context are monitored by tomcat, and when the resource changes, Tomcat automatically reloads the resource file. While this feature is useful in the development process, it is very expensive to operate in a production environment and often requires a restart of the product application.

Context Configuration

The context is unique, primarily because its configuration contains multiple options. And what we've noticed before is that Conf/server.xml is used to configure some of the global parameters in the Tomcat instance. Although context-related things can be configured in this file, this is not recommended.

Instead, Tomcat recommends that you extract the context-related configuration from Server.xml and configure it to the context segment file, which is monitored by Tomcat and can be reloaded during the run.

Please note again that Server.xml is only loaded once at startup.

It is also necessary to ensure that a separate, clear host and engine is configured in the context, because Tomcat looks for context-dependent configurations under the catalina_home/conf///directory. The context segment file that is configured for a specific host under this directory is named by the name. Xml.

By default, there will be an engine Catalina and a host named LocalHost, with the corresponding working directory catalina_home/conf/catalina/localhost. But the directory can also be a valid domain name, such as www.swengsol.com, then the corresponding directory is catalina_home/conf/catalina/www.swengsol.com.

In addition, context fragments can be included in the Meta-inf directory in the war or deployment directory. In this case, the context file name must be context.xml.

In addition, the context can also be configured in Web application descriptor file XML. Although this fragment file is tomcat-specific, it is also applicable to other lightweight servlet containers under Java EE because the descriptor is described by the servlet specification.

Wrapper (Wrapper)

The wrapper wrapper object is a child container of the context container that represents a single servlet (or a servlet converted from a JSP file). It is called a wrapper because it wraps the Java.servlet.Servlet instance.

This is the lowest level of the container hierarchy, and adding any subclasses will result in an exception.

The wrapper is also responsible for the servlet it wraps, including loading, instantiating servlets, and invoking functions that control the life cycle of the servlet, such as the Init (), service (), and Destroy () methods.

In addition the wrapper also uses its basic valve to invoke and its packaged servlet-related filters.

In the next article we'll talk about nesting component related things.

Tomcat Architecture (II)