Why a web container can manage a servlet?

Question

Good afternoon.
Why an HTTPservlet's life cycle can be managed by a WEB-container?
A WEB-server(for example Apache Tomcat) is able to capture an HTTP request from client, to process and to reply with an HTTP response; a servlet needs a web container(for example Apache Tomcat again) because it has not a main, so we can see servlet engine as "a main" that initializes a servlet(in a nutshell).
Good! Now I don't understand why this thing is possible. When a client sends an HTTP request, if this is the first invocation of that servlet, web container calls init(). Then, it allows to call doGet, doPost(and the other methods). Finally the servlet is destroyed[destroy()]. But how web container do this? What happen inside servlet engine?

****************************************EDIT*******************************************

My question talks about the reason why a servlet engine can manage the cycle of a servlet. The answer is really easy. A servlet engine can manage the cycle of a servlet(so it can call automatically create(), service() and destroy() methods) because servlet has a public interface, javax.Servlet.servlet. This interface declares methods that have a semantic, an accurate meaning:

create() is used just to create servlet
service() is used to handle HTTP methods
destroy() is used to delete the servlet

Programmers can override these methods but they must respect the semantic of method.

Answer 1

The Java 2 EE standard describes how the different parts of a web application play together. In a nutshell:

• Your project is compiled into a WAR files with a specific layout. This archive contains the code of your application and all the dependencies.
• Servlets need to register themselves in the file web.xml which is part of the WAR archive
• A servlet is a Java class which implements the HttpServlet API.
• When the container loads the WAR, it creates a special classloader that can load all the classes contained in it.
• When a specific URL is requested by the client, the container looks into the web.xml to find the servlet which can handle the request.
• When a servlet is found, the container uses the classloader and the parameters from the web.xml to load the class and create an instance.
• When the instance exists, it calls the method which matches the request.
• The method will then prepare the result.
• If anything goes wrong, the container will prepare an error answer.

Answer 2

A servlet container :

• keep a list of all Servlet in war that is deployed (Servlet class must be declared in a special file named web.xml in the war. Note that since Servlet 3.0 annotation can be used instead of web.xml)
• keep track of url mapping rules (url xyz must be handeled by Servlet abc, ...). Those mappings are also defined in web.xml.
• is able to create a new instance of servlet : it use dynamic invocation to create the instance and then call the "init()" method on it.

When an HTTP request arrives :

• the Servlet container create the HttpServletRequest (based on the HTTP request received) and HttpServletResponse objects.
• the Servlet container look at the url to see which Servlet will handle it. (If the Servlet was never called before, then it is created and initialized). Once the Servlet is ready (after the init() call return) : the container call the doGet(...) or doPost(...) or ... of the Servlet. (the arguments are the HttpServletRequest and HttpServletResponse just created)

Note : this is really an overview of the system. Many details omitted like servletFilters, management of thread pool, class-loader concerns, ...