Understanding the concepts of servlets and servlet containers, Web servers, etc.

Reprinted from http://blog.csdn.net/iAm333

Before in open source China saw an article, "Beginner Java Web Development, please stay away from the various frameworks, from the Servlet development", feel very good. I felt ashamed to think of myself before having been obsessed with various frameworks. So, read Xinxin Sun's "servlet/jsp in-depth: Tomcat-based Web development", Lin Shinliang's "Jsp&servlet Study notes (second edition)" and some other related information on the Internet, to organize their own understanding of the following.

Web Technology

With the development of Internet technology, Web applications based on HTTP and HTML are growing rapidly. Early Web applications are mainly used to browse static pages such as news, the user requests the static page on the server through the HTTP protocol, after the server's Web server software receives the request, reads the URI marked resources, plus the message sends the hair to the client browser, the browser is responsible for parsing the HTML, the result is rendered Now come out.

However, as time progresses, users are not satisfied with browsing static pages only. The user needs some interaction to get some dynamic results. If server-side software enhancements based on the HTTP protocol are too complex, some extension mechanisms are needed to implement the functionality that the user wants. The Web server extension mechanism used earlier is CGI (Common Gateway Interface, Public Gateway Interface). Using this method, the user clicks a link or enters a URL to access the CGI program, the Web server receives the request, runs the CGI program, processes the user request, and then processes the result and produces a response, which is returned to the Web server, which wraps the response. Returned to the browser in the form of an HTTP response.

The CGI program solves the user's needs to some extent. However, there are some shortcomings, such as the difficulty of writing CGI programs, longer response times, and running in a process mode resulting in limited performance. So in 1997, Sun unveiled the servlet technology as a CGI solution for the Java camp.

servlet and servlet containers

Java servlet (Java Server applet) is a Java-based Web component that runs on the server side and is managed by the Servlet container for generating dynamic content. Servlets are platform-independent Java classes that write a servlet that actually writes a Java class according to the servlet specification. The servlet is compiled into a platform-independent bytecode that can be dynamically loaded into a Web server that supports Java technology.
A servlet container, also called a servlet engine, is a part of a Web server or application server that provides network services on top of sent requests and responses, decodes MIME-based requests, and formats MIME-based responses. The servlet has no main method, cannot run independently, it must be deployed to the servlet container, and the methods of the servlet (such as doget () and Dopost ()) are instantiated and invoked by the container. The servlet container embraces and manages servlets throughout the servlet's life cycle. When JSP technology is launched, the container for managing and running servlet/jsp is also known as the Web container.

(note: Commonly used MIME types: text/html,application/pdf,video/quicktime,application/java,image/jpeg,application/jar,application /octet-stream,application/x-Zip)

With a servlet, the user accesses the Servlet,web server by clicking on a link or entering a URL directly into the browser's address bar, rather than handing the request directly to the servlet, but to the servlet container. The servlet container instantiates a servlet, invokes a specific method of the servlet, processes the request, and produces a response. This response is returned by the servlet container to the Web server, which wraps the response and sends it to the Web browser in the form of an HTTP response.

what can a servlet container provide?

We know that servlets need to be managed and run by a servlet container, but why do we do this? The reasons for using the servlet container are:

Communication support: Using the method provided by the container, you can easily let the servlet talk to the Web server without having to build serversocket, listen to a port, create a stream, and so on. The container knows the protocol between itself and the Web server, so your servlet doesn't have to worry about the API between the Web server (such as Apache) and your own web code, just consider how to implement the business logic in the servlet (such as processing an order).
Lifecycle Management: The servlet container controls the life and death of the servlet, which is responsible for loading classes, instantiating and initializing the servlet, invoking the Servlet method, and making the servlet instance garbage-collected, with the servlet container, and you don't need to think too much about resource management.
Multithreading support: The container automatically creates a new Java thread for each servlet request it receives. For the user's request, the thread will end if the servlet has already run the appropriate HTTP service method. This is not to say that you don't have to think about thread safety, but you also have a sync problem, but that can make you less work.
Declarative security: With the servlet container, you can use the XML deployment profile to configure and modify security without having to hard-code it into the Servlet class code.
JSP support: The servlet container is responsible for translating the JSP code into real Java code.

In contrast to CGI programs, Servlets have the following advantages:

A servlet is a single-instance multithreaded operation in which each request runs in a separate thread, while the servlet instance that provides the service has only one.
Servlets are upgradeable and can respond to more requests because the servlet container uses a thread rather than an operating system process, and the thread consumes only limited system resources.
The servlet uses the standard API and is supported by more Web servers.
The servlet is written in the Java language and therefore has all the advantages of the Java programming language, including ease of development and platform independence.
Servlets have access to the Java platform's rich library of classes, making it easier to develop a variety of applications.
The servlet container provides additional functionality to the servlet, such as error handling and security.
Classification of servlet containers

The servlet container can be divided into the following three categories, depending on the servlet container working mode:

1) stand-alone servlet container

When we use a Java-based Web server, the servlet container exists as part of the Web server. However, most Web servers are not Java-based, so there are two types of servlet containers working in the following mode.

2) in-process servlet container

The servlet container consists of the Web server plug-in and the Java container's implementation of the two parts. The Web server plug-in opens a JVM (a Java Virtual machine) in a Web server's internal address space, allowing the Java container to load and run the servlet in this JVM. If a client invokes the servlet's request, the plug-in obtains control of the request and passes it (using JNI technology) to the Java container, which is then referred by the Java container to the servlet for processing. The in-process servlet container is ideal for single-process, multi-threaded servers, providing high speed, but with insufficient scalability.

3) out-of-process servlet container

The servlet container runs in an address space outside the Web server, and it is made up of both the Web server plug-in and the Java container implementation. The Web server plug-in and the Java container (running in the external JVM) communicate using the IPC mechanism (usually TCP/IP). When a request to the servlet arrives, the plug-in obtains control of the request and passes it (using the IPC mechanism) to the Java container. Out-of-process servlet containers respond to customer requests less quickly than in-process servlet containers, but out-of-process containers have better scalability and stability.

Tomcat

To learn servlet technology, you need to have a servlet runtime environment, that is, you need a servlet container, this article uses Tomcat.

Tomcat is a free open source servlet container, a top-of-the-line project of the Apache Software Foundation (Apache Software Foundation) developed by Apache, Sun, and other companies and individuals. With Sun's involvement and support, the latest servlet and JSP specifications are always reflected in Tomcat, and Tomcat 6 supports the latest servlet 2.5 and JSP 2.1 specifications. Because Tomcat technology advanced, stable performance, and free, and thus deeply loved by Java enthusiasts, and has been recognized by some software developers, become the most popular Web server.

Tomcat, like IIS, Apache and other Web servers, has the ability to handle HTML pages, and it is also a servlet and JSP container, and the standalone servlet container is the default mode for Tomcat. However, Tomcat does not have the ability to handle static HTML as well as Apache, and we can integrate Apache with Tomcat, Apache as an HTTP Web server, and Tomcat as a Web container.

The process for the Tomcat server to accept customer requests and respond is as follows:

1) The client (usually the browser) accesses the Web server and sends an HTTP request.
2) After the Web server receives the request, it is passed to the servlet container.
3) The servlet container loads the servlet and, after producing the servlet instance, passes it to the object that represents the request and response.
4) The Servlet instance uses the request object to obtain the client's request information and then handles it accordingly.
5) The servlet instance sends the processing results back to the client through the response object, which is responsible for ensuring that the response is sent out correctly while returning control to the Web server.

the architecture of Tomcat

The Tomcat server is made up of a series of configurable components, the core of which is the Catalina servlet container, which is the top-level container for all other Tomcat components. We can understand the hierarchical relationship between Tomcat components by looking at the Server.xml file in the Conf folder under the Tomcat installation folder. Because server.xml annotations are too many, the special simplification is as follows:

<?XML version= ' 1.0 ' encoding= ' utf-8 '?>  <ServerPort= "8005"shutdown= "SHUTDOWN">      <Servicename= "Catalina">          <ConnectorPort= "8080"Protocol= "http/1.1"ConnectionTimeout= "20000"Redirectport= "8443"uriencoding= "UTF-8"/>          <Enginename= "Catalina"Defaulthost= "localhost">              <Hostname= "localhost">                  <ContextPath=""DocBase= "Workdir"reloadable= "true"/>              </Host>          </Engine>      </Service>  </Server>  

Where Workdir is the path to the project you want to import. Let's take a brief look at the role of each component in the Tomcat server.
(1) Server

The server represents the entire Catalina servlet container. Tomcat provides a default implementation of the server interface, which usually does not need to be implemented by the user itself. In the server container, you can include one or more service components.

(2) Service

A service is an intermediate component that survives within the server and binds one or more connector (Connector) components to a single engine. In server, you can include one or more service components. Service is also rarely customized, and Tomcat provides the default implementation of the service interface, which is both simple and satisfying to use.

(3) Connector

The connector (Connector) handles communication with the client, which is responsible for receiving customer requests and returning response results to the customer. In Tomcat, there are multiple connectors that can be used.

(4) Engine

In Tomcat, each service can contain only one servlet engine. The engine represents a request processing pipeline for a particular service. As a service can have multiple connectors, the engine receives and processes all requests from the connector, returns the response to the appropriate connector, and transmits it to the user through the connector. Users are allowed to provide custom engines by implementing the engine interface, but typically do not need to do so.

(5) Host

Host represents a virtual host, and an engine can contain more than one host. Users typically do not need to create a custom host because the implementation of the host interface given by Tomcat (class Standardhost) provides important additional functionality.

(6) Context

A context represents a Web application that runs on a specific virtual host. What is a Web application? In the Java servlet specification released by Sun, the Web application is defined as follows: "A Web application is a complete application that runs on a Web server, consisting of a set of Servlets, HTML pages, classes, and other resources." It can run in a Web container that implements the Servlet specification in multiple vendors. " A host can contain multiple context (representing a Web application), and each context has a unique path. Users typically do not need to create a custom context, because the implementation of the context interface (class Standardcontext) given by Tomcat provides important additional functionality.

Understanding the concepts of servlets and servlet containers, Web servers, etc.