Servlet Architecture and Workflow

Servlet Architecture and Workflow | In the Servlet container tutorial, we discussed what a servlet container, and how to work. The web server software internally contains the web container. Every Java-based web server like tomcat supplies two built-in containers:- servlet container and JSP container. The servlet container is used to manage the life cycle of servlet components, and to manage the life cycle of JSP components both servlet and JSP containers are required.

Then, in the tomcat server, we discussed what the tomcat server is, how to install it. Tomcat installation directory tells the structure of the installation directory, types of contained files, and their purposes. Finally, we developed a simple and basic servlet web application. Now let us understand the flow of the web application from deployment to web browser result.

Deployment Operations of the Servlet Web Application

In the servlet example, the web application directory was,

DateApp
   |=> WEB-INF
      |=> web.xml
      |=> classes
          |=> DateServlet.java

There, the web.xml file,

<web-app>
   <!--Servlet Configuration-->
   <servlet>
      <servlet-name>date</servlet-name>
      <servlet-class>com.kp.servlet.DateServlet</servlet-class>
   </servlet>

   <!--Servlet Mapping-->
   <servlet-mapping>
      <servlet-name>date</servlet-name>
      <url-pattern>/home</url-pattern>
   </servlet-mapping>
</web-app>

Here:-

• URL:- /home
• Logical name:- date
• Mapped Servlet component:- com.kp.servlet.DateServlet

In one web.xml we configure all the servlet components with URL (but in our example, only one configuration is there). Assume there are 10 servlet components configured in the web.xml. When we make a request “/home” from the browser then the web container first finds the logical name (<servlet-name) for that URL. In our example, the logical name for “/home” is “date”.

Workflow for Deployed Servlet web application,

1. We deployed the DateApp web application in the Tomcat webserver (<Tomcat_home>\webapps folder).
2. The web container of the Tomcat web server verifies the deployment directory structure.
3. The web container loads the web.xml file and checks whether it is well-formed and valid? If web.xml is not valid and well-formed then it throws exceptions. If yes then go for the next activities.
4. The servlet container creates In-Memory metadata of the web.xml file in the memory where the servlet container/web application is running (i.e. in JVM memory of the RAM).
5. Other deployment-related activities will take place.

In-Memory meta-data for web.xml of ServletExample web application,

URL	Logical Name	Servlet class
/home	date	com.kp.servlet.DateServlet

For one web application, XML files will be loaded, verified, metadata created only for one time at the time of deployment. That metadata will be used for all the requests given to that web application. 

If the web container won’t create the metadata for the web.xml file, then web containers have to load, verify, fetch details from the web.xml file for every request. Which is a time consuming process, XML parsers are themselves heavy, and may take more time. Overall it may degrade the performance of the web application therefore the web container creates the metadata and use it for all the requests. For every request no need to load, verify and fetch details from the web.xml file, just go to the metadata and fetch the details.

The moment a web application is stopped its JVM memory in the RAM will vanish. In that process InMemory metadata of XML files like web.xml will also vanish. 

The modification done in the content of the web.xml file will be reflected by the servlet container, no need to reload the web application.

Workflow for the First Request to the Servlet Component

Partial workflow from request arrival to response display with the above servlet component-based Java-based web application.

1) End-User types request URL in the browser address bar and generates the request. (i.e. entered  http://localhost:8080/DateApp/home)
2) Based on the “localhost:port-number” of the request URL, the tomcat server traps and takes the request.
3) Tomcat server hands over the request to the servlet container.
4) Based on the “DateApp” of the request URL, the servlet container links the request to the deployed “DateApp” web application.
5) Servlet container creates 1 set of request and response objects for the current request.

6) Based on the “/home” of request URL, it will go to the in-memory metadata of the web.xml file and verifies:- is there any servlet component that is mapped with the “/home” URL pattern? And it gets “date” as a logical name, and “com.kp.servlet.DateServlet” as a servlet component class.
7) Web container takes the logical name and verifies for the servlet component class object in internal cache? Since it is the first request therefore currently nothing is available in the internal cache.
8) Web container loads the com.kp.servelt.DateServlet class and creates the object, initializing the object (servlet life cycle instantiation-related activities).
9) Web container keeps created objects of com.kp.servlet.DateServlet class in the internal cache having the logical name “date” as the key and servlet component DateServlet class object as its value.

Internal cache for DateApp web application,

Logical Name (key)	Class Name (value)
date	com.kp.servlet.DateServlet

The web container is using an internal cache because from the next request onwards it does not need to load, create, initialize class objects once again. From the next request to that servlet component, it will check in the internal cache and use it. For internal cache, HashMap is used which maintains data as key-value pairs.

10) Web container creates one thread based on the current request.
11) Created thread calls service(-,-) method on DateServlet class object having request, response object as the arguments.
12) The service(-,-) method processes the request and writes the generated output to the browser as a response through response object => web container => web server.
13) Browser receives the response and displays it on the browser as a dynamic web page.
14) Web containers destroy the current request-related thread.
15) Web containers destroy the current request-related response and request objects.

Workflow for Other than First Request

From the next request (i.e. except the first request) 8^th and 9th step will not be there, and the remaining things will be performed the same as the first request.

Other than the first request, the web container won’t create the object, initialize the object, keep it in the internal cache. Because in the 7^th step it checked the internal cache and found the required details (which was created in the first request time). Web containers fetch those details, skip the 8th and 9th steps and perform the next operations.

If you enjoyed this post, share it with your friends. Do you want to share more information about the topic discussed above or do you find anything incorrect? Let us know in the comments. Thank you!

Search