The Web server itself is primarily used to support HTTP protocols, including listening and corresponding HTTP requests. A Web server generally handles static requests, such as static files in a file system. A Web container is a Web-related component that provides a running environment and can understand its meaning slightly from the word ' container '.
Simply put, Web servers and Web containers themselves are just one platform application. So, in order to understand its role, let's say how we respond to client requests without Web servers and Web containers. From the point of view of network programming, we need:
New one ServerSocket listening on a port
Call Accept to wait for a client connection
There is a connection that returns a socket object corresponding to the client for communication between the client and the server
In order to be able to process requests concurrently, multi-threading support is required, queuing requests, opening multiple threads to process requests in the queue, or opening one thread per request
For Web applications, also analyze the HTTP protocol, process HTTP packets, and respond to the client based on the data in the HTTP packet
As can be seen, in the absence of Web servers and Web containers, it is very difficult to develop a Web application, so the Web server and Web container help us to do all these common things, only in the existing framework, focus on their own business development.
The Web container itself, from the word container can be seen, it mainly provides a running environment. The Web application itself does not have a main function, and is executed primarily through a request-triggering approach. If the Web app is focused on the business itself, where it starts executing, and the analysis of the HTTP packet itself, including request parameters, protocol versions, data types, and so on, requires a complete execution environment, which is the Web container. As far as the servlet is concerned, the development of the servlet begins with inheriting HttpServlet and implements its Dopost and Doget function processing requests. However, the parameters of the two functions themselves are httpservletrequest and HttpServletResponse objects, and the HttpRequest object already contains the parameter fields in the HTTP request, which are provided by the Web container. There is also no need to care about the build of the Servlet object itself, the container loads the Servlet class, calls the constructor, the Init function, and the last destroy. It provides management of the entire servlet lifecycle.
The servlet handles HTTP requests, acting as a controller in the MVC pattern of web development. Used to invoke the specific business logic object to process the business logic, and then forward the processing results to the view layer, which is sent to the client through the Web server.
As I said before, the Web container is responsible for managing the life cycle of the servlet, as shown in the servlet lifecycle itself:
650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/26/8F/wKioL1NrXt6zYjXbAACsnZZwqrA312.jpg "title=" Servlet life cycle "alt=" wkiol1nrxt6zyjxbaacsnzzwqra312.jpg "/>
Before the servlet loads, the container loads the servlet's class file, invokes its constructor, and enters the servlet's real life cycle, init-"service-" destroy, which guarantees that the service method executes before the container The Init method has been completed so that it is initialized appropriately before the service is provided. The container loads the servlet at different time periods depending on the servlet configuration, and when the servlet is configured with Load-on-startup, it is loaded when the server is started, which can be used to initialize some global environments. When Load-on-startup is not configured, the container loads the servlet response request when the first request arrives. The servlet's life is primarily spent in service, in response to the client's service, which distributes the request based on different request functions, dopost the POST request, and doget the GET request for processing. When the server shuts down, the container invokes the servlet's destroy method to ensure that its held resources are freed before the servlet ends.
So what does the container do in the life cycle of the servlet and in the request response, as previously stated, it parses the HTTP packets, packages them into HttpServletRequest and HttpServletResponse objects, and executes the service method. In fact, the container creates a new thread for each HTTP request and processes the request. threads, requests, response, and service compose a client environment from request to response. When the request ends, the container cleans up the requests and response objects, ends the thread, or reclaims them to the thread pool. As you can see from here, each request runs in a separate thread, but the servlet itself is not thread safe. As can be seen from the servlet life cycle analysis, each Servlet object has only one life in the entire Web application, and for each request, it executes its service method in a different thread.
The client's request is typically a URL, how to map to the servlet from the URL, and then load (if necessary) initialize the corresponding servlet. Each Web project needs to be configured with XML, which includes <servlet>,<servlet-mapping> two tags. <servlet> tags are used for mapping from the servlet's class to the Servlet-name, Servlet-name is a name used only in the Web. XML configuration, which can be arbitrarily named for URLs and for direct decoupling of the class. <serlvet-mapping> for mappings from URLs to <servlet-mapping>. The mapping of containers from URLs to Servlets can be achieved by parsing Web. Xml. First find the global qualified name of the corresponding class from the <servlet-mapping> from the URL to the Servlet-name, and then from the Servlet-name. After the class is found, if it needs to be loaded, it loads the classes and travels the life cycle process described above, and if it has already been loaded, the container executes its service method directly, processing the request. This is the process of responding from the URL to the servlet to the client. The container is solely responsible for the servlet's life cycle.
This article is from the "Thinking Java EE" blog, please make sure to keep this source http://xjava.blog.51cto.com/2949562/1408531