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

This article mainly explains "what is the implementation principle of the middleware container". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn "what is the implementation principle of the middleware container?"

Tomcat system architecture analysis of the structure of Tomcat is very complex, but Tomcat is also very modular, find the core module of Tomcat, seize the "seven inches" of Tomcat. The overall structure of Tomcat

The overall structure of Tomcat is distributed from outside to inside. The largest range of service containers are Server components, Service service components (which can exist at the same time), Connector (connectors), Container (container services), and other components: Jasper (Jasper parsing), Naming (naming service), Session (session management), Logging (log management), JMX (Java manager extension service), Websocket (interactive service).

Tomcat overall structure diagram

As you can see from the figure above, the heart of Tomcat consists of two components: Connector and Container, which will be described in more detail later.

The Connector component can be replaced, which provides server designers with more choices, because this component is so important that it is not only related to the server design itself, but also to different application scenarios, so a Container can choose to correspond to multiple Connector. Multiple Connector and a Container form a Service.

Everyone is very familiar with the concept of Service, with Service can provide services to the outside world, but Service also needs a living environment, and someone must be able to give her life and control the power of her life and death, then it must be Server. So the entire life cycle of Tomcat is controlled by Server.

Take Service as "marriage"

If we compare Connector and Container in Tomcat as a whole to a couple, Connector is mainly responsible for external communication, which can be compared to Boy,Container mainly dealing with requests accepted by Connector, mainly dealing with internal affairs, which can be compared to Girl. So this Service is the marriage certificate that connects the couple. It is Service that connects them together to form a family. Of course, to form a family, there are many other elements.

To put it bluntly, Service just wraps an extra layer around Connector and Container, assembles them together and provides services to the outside world. A Service can set up multiple Connector, but there can only be one Container container. The list of methods for this Service interface is as follows:

1) Service interface

Method list

As can be seen from the methods defined in the Service interface, it is mainly for associating Connector and Container, while initializing other components below it. Note that the interface does not stipulate that it must control the life cycle of the components below it. The life cycle of all components is controlled in an Lifecycle interface, and an important design pattern is used here, which will be described later.

The standard implementation class for the Service interface in Tomcat is StandardService, which implements not only the Service excuse but also the Lifecycle interface, so that it can control the life cycle of the components below it. The StandardService class structure diagram is as follows

2) Class structure diagram of StandardService

Method list

From the figure above, we can see that in addition to the implementation of the Service interface method and the Lifecycle interface implementation that controls the component life cycle, there are several other methods for event listening, not only for this Service component, but also for other components in Tomcat. This is also a typical design pattern, which will be described later.

Let's take a look at the code for several main method implementations in StandardService. Here is the source code for the setContainer and addConnector methods:

3) StandardService. SetContainerpublic void setContainer (Container container) {Container oldContainer = this.container; if ((oldContainer! = null) & & (oldContainer instanceof Engine)) ((Engine) oldContainer) .setService (null); this.container = container; if ((this.container! = null) & & (this.container instanceof Engine)) ((Engine) this.container) .setService (this) If (started & & (this.container! = null) & & (this.container instanceof Lifecycle) {try {((Lifecycle) this.container) .start () } catch (LifecycleException e) {;}} synchronized (connectors) {for (int I = 0; I < connectors.length) I connect +) connectors [I] .setContainer (this.container) } if (started & & (oldContainer! = null) & & (oldContainer instanceof Lifecycle)) {try {(Lifecycle) oldContainer) .stop () } catch (LifecycleException e) {;}} support.firePropertyChange ("container", oldContainer, this.container);}

This code is very simple, in fact, it is to determine whether the current Service has been associated with Container, and if so, remove the association-- oldContainer.setService (null). If the oldContainer has been started, end its life cycle. Then replace the new association, initialize and start the life cycle of the new Container. Finally, notify the interested event listener of this process. What's worth noting here is that when you modify a Container, you need to associate the new Container to each Connector, but fortunately, there is no two-way association between Container and Connector, otherwise the association will be difficult to maintain.

4) StandardService. AddConnectorpublic void addConnector (Connector connector) {synchronized (connectors) {connector.setContainer (this.container); connector.setService (this); Connector results [] = new Connector [connectors.length + 1]; System.arraycopy (connectors, 0, results, 0, connectors.length); results [connectors.length] = connector; connectors = results If (initialized) {try {connector.initialize ();} catch (LifecycleException e) {e.printStackTrace (System.err) }} if (started & & (connector instanceof Lifecycle)) {try {(Lifecycle) connector) .start ();} catch (LifecycleException e) { Support.firePropertyChange ("connector", null, connector);}}

Above is the addConnector method, which is also very simple, starting with setting up the relationship, then initializing the work and starting a new life cycle. It's worth mentioning here that Connector uses arrays instead of List collections, which is understandable from a performance point of view. What's interesting is that arrays are used here, but we don't assign a fixed-size array at the beginning, as we usually do. Its implementation mechanism here is to recreate an array object of the current size, and then copy the original array object into the new array. This way realizes the function of similar dynamic array, which is worth using for reference in the future.

StandardService is basically unchanged in the latest Tomcat6, but Service, Server, and container classes all inherit the MBeanRegistration interface from Tomcat5, and Mbeans management is more reasonable.

Take Server as the "residence"

As mentioned earlier, a couple becomes a couple because of Service. They have the basic conditions to form a family, but they also have a physical home, which is the foundation for their survival in society. With a home, they can safely serve the people and create wealth for the society.

The simple task of Server is to be able to provide an interface for other programs to access the Service collection while maintaining the life cycle of all the Service it contains, including how to initialize, how to end the service, and how to find the Service that others want to access.

There are other minor tasks, such as you live in this place to register, and you may have to cooperate with the daily security checks of the local authorities.

The class structure diagram of Server is as follows:

1) Class structure diagram of Server

Its standard implementation class, StandardServer, implements the above methods as well as all the methods of the Lifecycle and MbeanRegistration interfaces. Let's take a look at the implementation of addService, an important method of StandardServer:

2) StandardServer.addServicepublic void addService (Service service) {service.setServer (this); synchronized (services) {Service results [] = new Service [services.length + 1]; System.arraycopy (services, 0, results, 0, services.length); results [services.length] = service; services = results; if (initialized) {try {service.initialize () } catch (LifecycleException e) {e.printStackTrace (System.err) }} if (started & & (service instanceof Lifecycle)) {try {((Lifecycle) service) .start () } catch (LifecycleException e) {;}} support.firePropertyChange ("service", null, service);}

From the first sentence above, we know that Service and Server are related to each other. Server also manages it like Service Management Connector. It also puts Service in an array. The later part of the code also manages the life cycle of this newly added Service. There is no change in Tomcat6.

The lifeline of the component "Lifecycle" has been saying that Service and Server manage the life cycle of the components below it, so how do they manage it?

The life cycle of components in Tomcat is controlled through the Lifecycle interface, as long as the component inherits this interface and implements the methods in it, it can be uniformly controlled by the component that owns it, so that the life cycle of all components in Tomcat can be controlled by a top-level component, the highest component is Server, and the one that controls Server is Startup, that is, you start and shut down Tomcat.

The following is the class structure diagram of the Lifecycle interface:

1) Lifecycle class structure diagram

In addition to the Start and Stop methods that control the lifecycle, there is a listening mechanism to do some additional operations at the beginning and end of the lifecycle. This mechanism is also used in other frameworks, such as in Spring. This design pattern will be described later.

The methods of the Lifecycle interface are implemented in other components, and as mentioned earlier, the life cycle of the component is controlled by the parent component that contains it, so its Start method naturally calls the Start method of the component below it, and so is the Stop method. For example, in Server, the Start method calls the Start method of the Service component. The Start method code of Server is as follows:

2) StandardServer.Startpublic void start () throws LifecycleException {if (started) {log.debug (sm.getString ("standardServer.start.started")); return;} lifecycle.fireLifecycleEvent (BEFORE_START_EVENT, null); lifecycle.fireLifecycleEvent (START_EVENT, null); started = true; synchronized (services) {for (int I = 0; I < services.length) If (services [I] instanceof Lifecycle) ((Lifecycle) services [I]) .start ();}} lifecycle.fireLifecycleEvent (AFTER_START_EVENT, null);}

The listening code surrounds the startup process of the Service component, which is simply a loop to start the Start method of all Service components, but all Service must implement the Lifecycle interface, which makes it more flexible. The Stop method code of Server is as follows:

3) StandardServer.Stoppublic void stop () throws LifecycleException {if (! started) return; lifecycle.fireLifecycleEvent (BEFORE_STOP_EVENT, null); lifecycle.fireLifecycleEvent (STOP_EVENT, null); started = false; for (int I = 0; I < services.length; iTunes +) {if (services [I] instanceof Lifecycle) ((Lifecycle) services [I]). Stop () } lifecycle.fireLifecycleEvent (AFTER_STOP_EVENT, null);}

What it needs to do is similar to the Start method.

At this point, I believe you have a deeper understanding of "what is the implementation principle of the middleware container". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.