Tomcat system architecture and Design Patterns, part 2nd: Analysis of design patterns

Tomcat system architecture and Design Patterns, part 2nd: Analysis of design patterns

This two-part series studies the system architecture of Apache Tomcat Server and the many classic design patterns it uses. The 1th part analyzes how Tomcat works, and the 2nd section analyzes many of the classic design patterns used in tomcat, such as template mode, Factory mode, and Singleton mode. Through the study of their practical use can give us the future of software design plays a certain role in reference.

Façade Design Patterns

Façade design patterns are used in Tomcat in multiple places, in Request and Response object encapsulation, standard Wrapper to ServletConfig encapsulation, ApplicationContext to ServletContext This design pattern is used in the middle of the package.

The principle of façade design pattern

This design pattern is used on so many occasions, so what can this design pattern do? As the name implies, it is to encapsulate a thing as a façade. It's easier to communicate with others, just like a foreign ministry in a country.

This design pattern is mainly used in a large system in a number of subsystems, these subsystems are bound to involve mutual communication, but each subsystem can not be too much of their internal data exposure to other systems, otherwise there is no need to partition subsystems. Each subsystem will design a façade that encapsulates data of interest to other systems and accesses it through the façade. This is the meaning of the façade design pattern existence.

The façade design pattern is as follows:

Figure 1. Façade

Client access to the data provided in Façade is key to the façade design pattern, and there is no provision for client access to Façade and Subsystem how to provide Façade façade design patterns.

Example of Tomcat's façade design pattern

The façade design pattern in Tomcat is used a lot because there are many different components in Tomcat, each interacting with data, and it's a good way to isolate data in a façade mode.

Here is the façade design pattern used on Request:

Figure 2. Request's façade design pattern class diagram

It can be seen that the Httprequestfacade class encapsulates the HttpRequest interface to provide data, the data accessed through Httprequestfacade is proxied to HttpRequest, and usually encapsulated objects are set to Private or P rotected access adornments to prevent direct access in Façade.

Back to top of page

Viewer design Pattern

This design pattern is also commonly used in design methods, often called the publish-subscribe mode, which is the event listener mechanism, usually triggering some actions before or after an event occurs.

The principle of the observer pattern

The Observer pattern principle is also very simple, that is when you are doing things, there is always a person staring at you, when you do the thing is that it is interested in, it will follow other things. But the one who stares at you must register with you, or you won't be able to tell it. The Observer pattern typically contains the following roles:

• Subject is an abstract topic: it is responsible for managing the references of all observers and defining the main event actions.
• ConcreteSubject specific topic: it implements all the defined interfaces of an abstract subject, and notifies all observers when it changes itself.
• Observer Observer: The listener theme changes the corresponding operation interface.

Example of the Observer pattern for TOMCAT

The Observer pattern in Tomcat is also used in many places, the Lifecycle of the control component life cycle mentioned above is the embodiment of this pattern, and the creation of Servlet instances, Session management, Container, etc. are the same principle. The following is a look at the specific implementation of Lifecycle.

Lifecycle Observer Pattern Structure:

Figure 3. Lifecycle Observer Pattern Structure diagram

In the above structure diagram, Lifecyclelistener represents an abstract observer, which defines a lifecycleevent method, which is the method to be executed when the subject changes. Serverlifecyclelistener represents the specific observer, which implements the Lifecyclelistener interface method, which is the specific implementation of this particular observer. The Lifecycle interface represents an abstract topic that defines the method of managing the observer and the other methods it wants to do. Instead, Standardserver represents a specific topic that implements all the methods of an abstract subject. Here TOMCAT expands the observer by adding two additional classes: Lifecyclesupport, lifecycleevent, which extend the viewer's functionality as a helper class. Lifecycleevent makes it possible to define event categories, and different events can be handled differently and more flexibly. Lifecyclesupport class agent for the topic of multi-observer management, the management of the implementation of the unified, if modified as long as the modification of the Lifecyclesupport class can be, do not need to modify all the specific topics, because all the specific topics of the observer's actions are delegated to Lifecyclesupport class. This can be considered an improved version of the Observer pattern.

The method code for the LIFECYCLESUPPORT call Observer is as follows:

Listing 1. The Firelifecycleevent method in Lifecyclesupport

public void Firelifecycleevent (String type, Object data) {    Lifecycleevent event = new Lifecycleevent (lifecycle, type, data);    Lifecyclelistener interested[] = null;    Synchronized (listeners) {        interested = (lifecyclelistener[]) listeners.clone ();    }    for (int i = 0; i < interested.length; i++)        interested[i].lifecycleevent (event);}

How does the subject inform the observer? Look at the following code:

Listing 2. The Start method in the container

public void Start () throws Lifecycleexception {    lifecycle.firelifecycleevent (before_start_event, null);    Lifecycle.firelifecycleevent (start_event, null);    started = true;    Synchronized (services) {for        (int i = 0; i < services.length; i++) {            if (Services[i] instanceof Lifecycle) 
    ((Lifecycle) services[i]). Start ();            }        }    Lifecycle.firelifecycleevent (after_start_event, null);}

Back to top of page

Command design mode

The previous two core components of Tomcat, Connector and Container, were compared to a couple. The man will accept the request and give it to the hostess by the way of order. Correspondence to Connector and Container,connector is also called through the command mode Container.

The principle of the command mode

The main function of the command pattern is to encapsulate the command, separating the responsibility for issuing the command from the responsibility for executing the order. is also a function of the division of labor. Different modules can make different interpretations of the same command.

The following are the command patterns that typically contain the following roles:

• Client: Create a command and decide who the recipient
• Command command: Defines an abstract method for the Commands interface
• Concretecommand: The specific command that is responsible for invoking the corresponding action of the recipient
• Invoker requester: Responsible for invoking Command object execution request
• Receiver recipient: Responsible for specific implementation and execution of a request

Example of a command pattern in Tomcat

The command pattern in Tomcat is reflected between the Connector and Container components, and Tomcat, as an application server, will no doubt accept many requests, and the ability to allocate and execute these requests is a must.

Here's a look at how Tomcat implements the command pattern, and here's a diagram of the Tomcat command pattern:

Figure 4. Structure diagram of the Tomcat command pattern

Connector as an abstract requestor, httpconnector as a specific requestor. Httpprocessor as an order. Container as the abstract recipient of the order, containerbase as the specific recipient. The client is the Application Server server component. The Server first creates the command requestor HttpConnector object, and then creates the command Httpprocessor Command object. The command object is then handed to the command recipient Containerbase container to handle the command. The command was eventually executed by Tomcat's Container. Commands can come in as queues, Container can also handle requests in different ways, such as HTTP1.0 protocols and HTTP1.1 processing in different ways.

Back to top of page

Responsibility chain Model

One of the most discoverable design patterns in Tomcat is the responsibility chain model, which is also the basis for Container design in Tomcat, where the entire container is connected through a chain that always passes the request correctly to the Servlet that ultimately handles the request.

The principle of the responsibility chain model

The chain of responsibility pattern is that many objects have each object's reference to its home to form a chain, the request is passed on this chain, until an object on the chain processes the request, or each object can process the request and pass it on to the next, until each object on the final chain is processed. This allows you to add arbitrary processing nodes to the chain without affecting the client.

The usual chain of responsibility pattern consists of the following roles:

• Handler (Abstract processor): Defines an interface for processing requests
• Concretehandler (Specific processor): The specific class of processing the request, or passed to the

Example of a responsibility chain pattern in Tomcat

In Tomcat, this design pattern is almost completely used, and Tomcat's container setting is the chain of responsibility, from Engine to Host to Context until Wrapper is passed through a chain of requests.

The class structure diagram for the responsibility chain pattern in Tomcat is as follows:

Figure 5. A structure diagram of the TOMCAT responsibility chain model

The basic description of the four sub-containers using the responsibility chain model of the class structure diagram, corresponding to the role of the chain model, Container play the role of abstract processor, the specific processor by Standardengine and other sub-containers play. Unlike the standard chain of responsibility, the Pipeline and Valve interfaces are introduced here. What role do they have?

In fact, Pipeline and Valve have expanded the functionality of the chain, allowing for external intervention in the process of transferring the chain down. The Pipeline is the pipe that connects each sub-container, and the Request and the Response object in it are like the water flowing in the pipe, and Valve is a small opening on the tube that gives you the opportunity to get in touch with the water inside and do something extra.

In order to prevent water from being drawn and not flowing into the next container, there is always a node at the end of each tube to ensure that it will flow to the next sub-container, so each container has a standardxxxvalve. As long as the link is involved in the process of processing this is a very worthy of reference model.

Tomcat system architecture and Design Patterns, part 2nd: Analysis of design patterns