Shulou(Shulou.com)06/03 Report--

This article mainly introduces "the principle of facade design pattern in Tomcat". In daily operation, I believe that many people have doubts about the principle of facade design pattern in Tomcat. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "the principle of facade design pattern in Tomcat". Next, please follow the editor to study!

Facade design pattern

The facade design pattern is used many times in Tomcat, in Request and Response object encapsulation, in Standard Wrapper-to-ServletConfig encapsulation, and in ApplicationContext-to-ServletContext encapsulation.

The principle of facade design pattern

This design pattern has been used in so many occasions, so what on earth can this design pattern do? As the name implies, it is to encapsulate something into a facade so that it is easier to communicate with others, just like the Ministry of Foreign Affairs of a country.

This design pattern is mainly used when there are multiple subsystems in a large system, which must involve communicating with each other, but each subsystem can not expose too much of its internal data to other systems. otherwise, there is no need to divide subsystems. Each subsystem will design a facade to encapsulate the data of interest to other systems and access it through this facade. This is the meaning of the facade design pattern.

The schematic diagram of the facade design pattern is as follows:

Figure 1. Facade diagram

The fact that Client can only access the data provided in Fa ç ade is the key to the facade design pattern, but there are no rules on how Client accesses Fa ç ade and how Subsystem provides Fa ç ade facade design pattern.

Example of facade design pattern for Tomcat

Facade design pattern is widely used in Tomcat, because there are many different components in Tomcat, and each component has to interact with each other. It is a good way to use facade mode to isolate data.

The following is the facade design pattern used on Request:

Figure 2. Request facade design pattern class diagram

It can be seen from the figure that the HttpRequestFacade class encapsulates the HttpRequest interface to provide data, and the data accessed through HttpRequestFacade are proxied into HttpRequest, and usually the encapsulated objects are set to Private or Protected access modification to prevent direct access in Fa ç ade.

Observer design pattern

This design pattern is also a common design method, which is usually called publish-subscribe pattern, that is, event listening mechanism, which usually triggers some actions before and after an event occurs.

The principle of observer mode

The principle of the observer mode is also very simple, that is, when you are doing something, there is always someone watching you, and when you do something that it is interested in, it will do something else. But the person staring at you must register with you, or you can't notify it. The Observer pattern usually consists of the following roles:

Subject is an abstract topic: it is responsible for managing references to all observers while defining major event operations.

ConcreteSubject concrete theme: it implements all the defined interfaces of the abstract theme and notifies all observers when it changes.

Observer watcher: the corresponding operation interface for listening for changes in theme.

An example of the observer mode for Tomcat

The Observer pattern is also used in many places in Tomcat. The Lifecycle that controls the life cycle of components mentioned earlier is the embodiment of this pattern, as well as the same principle for the creation of Servlet instances, Session management, Container, and so on. Let's take a look at the specific implementation of Lifecycle.

Observer pattern structure diagram of Lifecycle:

Figure 3. Observer pattern structure diagram of Lifecycle

In the structure diagram above, LifecycleListener represents the abstract observer, which defines a lifecycleEvent method that is executed when the theme changes. ServerLifecycleListener represents a specific observer, and it implements the method of the LifecycleListener interface, which is the specific implementation of this specific observer. The Lifecycle interface represents an abstract topic, which defines the way to manage the observer and other methods it needs to do. StandardServer, on the other hand, represents a specific topic, and it implements all the methods of abstracting the theme. Here Tomcat extends the observer by adding two other classes: LifecycleSupport and LifecycleEvent, which extend the functionality of the observer as auxiliary classes. LifecycleEvent makes it possible to define event categories, and different events can be handled differently, making it more flexible. The LifecycleSupport class proxies the management of the topic to the multi-watchers, which is extracted and implemented uniformly. If you modify it later, you only need to modify the LifecycleSupport class, and you do not need to modify all the specific topics, because all the operations on the observers of the specific topics are proxied to the LifecycleSupport class. This can be thought of as an improved version of the observer model.

The method code for LifecycleSupport to call the observer is as follows:

Listing 1. The fireLifecycleEvent method in LifecycleSupport

one

two

three

four

five

six

seven

eight

nine

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; iTunes +)

Interested.lifecycleEvent (event)

}

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

Listing 2. The start method in the container

one

two

three

four

five

six

seven

eight

nine

ten

eleven

twelve

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; iTunes +) {

If (services [I] instanceof Lifecycle)

((Lifecycle) services [I]) .start ()

}

}

Lifecycle.fireLifecycleEvent (AFTER_START_EVENT, null)

}

Command design pattern

Previously, Connector and Container, the two core components of Tomcat, are compared to a couple. The man gave the accepted request to the hostess by order. The corresponding Connector and Container,Connector also call Container in command mode.

The principle of command mode

The main function of the command mode is to encapsulate the command and separate the responsibility of issuing the command from the responsibility of executing the command. It is also a functional division of labor. Different modules can interpret the same command differently.

The following is a command mode that usually contains the following roles:

Client: create a command and determine the recipient

Command command: command interface defines an abstract method

ConcreteCommand: specific command, which is responsible for invoking the corresponding operation of the recipient

Invoker requester: responsible for invoking the command object to execute the request

Receiver recipient: responsible for implementing and executing a request

Example of command mode in Tomcat

The command pattern in Tomcat is reflected between Connector and Container components. As an application server, Tomcat will undoubtedly receive many requests. How to allocate and execute these requests is a necessary function.

Let's take a look at how Tomcat implements the command mode, and here is the structure diagram of the Tomcat command mode:

Figure 4. Structure diagram of Tomcat command mode

Connector is the abstract requestor and HttpConnector is the concrete requestor. HttpProcessor as a command. Container is the abstract receiver of commands and ContainerBase is the concrete receiver. The client is the application server Server component. Server first creates the command requestor HttpConnector object, and then creates the command HttpProcessor command object. Then the command object is handed over to the command recipient ContainerBase container to process the command. The command is ultimately executed by the Container of Tomcat. Commands can come in as queues, and Container can handle requests in different ways, such as the HTTP1.0 protocol and HTTP1.1.

Responsibility chain model

One of the most easily discovered design patterns in Tomcat is the responsibility chain pattern, which is also the basis of Container design in Tomcat. The whole container is connected by a chain that correctly passes the request to the Servlet that finally handles the request.

The principle of the chain of responsibility model

The responsibility chain pattern is that many objects are connected to form a chain because each object has a reference to its next family, and 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 to the next family, until finally every object on the chain has been processed. In this way, arbitrary processing nodes can be added to the chain without affecting the client.

Typically, the chain of responsibility model consists of the following roles:

Handler (Abstract Handler): defines an interface for handling requests

ConcreteHandler (concrete handler): the specific class that handles the request, or passes it to the next

Example of chain of responsibility pattern in Tomcat

This design pattern is almost completely used in tomcat, and the container setting of tomcat is the responsibility chain pattern, passing requests through a chain from Engine to Host to Context to Wrapper.

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

Figure 5. Structure diagram of Tomcat responsibility chain model

The above figure basically describes the class structure diagram of the four sub-containers using the responsibility chain pattern. The corresponding role of the responsibility chain pattern is that Container plays the role of abstract handler, and the concrete handler is played by sub-containers such as StandardEngine. Unlike the standard chain of responsibility, Pipeline and Valve interfaces are introduced here. What do they do?

In fact, Pipeline and Valve extend the function of this chain, so that it can accept external intervention in the process of passing down the chain. Pipeline is the pipe that connects each sub-container, in which the Request and Response objects are like the water flowing in the pipe, and Valve is the small openings in the pipe, giving you a chance to get in touch with the water inside and do some extra things.

In order to prevent the water from being drawn out and not flowing to the next container, each piece of pipe has a node at the end to ensure that it can flow to the next sub-container, so each container has a StandardXXXValve. As long as it comes to this kind of chained processing flow, this is a model worth learning from.

At this point, the study of "the principle of facade design pattern in Tomcat" is over. I hope to be able to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.