Web Application Architecture

When a request comes in something has to to instantiate the servlet or at least make a new thread to handle the request. Something has to call the servlets doPost() or doGet() method and they have crucial arguments - the HTTP request and HTTP response objects, so something has to handle the life, death and resources of the servlet and that something is the Web Container.

What is a Container

Tomcat is an example of a container, when a web server gets a request for a servlet , the web server hands the request to the Container in which the servlet is deployed. It's the Container that gives the servlet the HTTP request and response and it's the Container that calls the servlet's methods (doPost() and getGet()).

The Container will give you the following

The following steps are how the Container handles a request for a servlet

  1. The user clicks a link that has a URL to a servlet instead of a static page
  2. The container "sees" that the request is for a servlet, so the container creates two objects HttpServletResponse and HttpServletRequest
  3. The container finds the correct servlet based on the URL in the request, creates or allocates a thread for that request and passes the request and response Objects to the servlet thread
  4. The container calls the servlet's service() method, depending on the type of request, the service() methods calls either the doGet() or doPost() method
  5. The doGet() method generates the dynamic page and stuffs the page into the response object. Remember, the container still has a reference to the response object
  6. The thread completes, the container converts the response object into an HTTP response, send it back to the client, then deletes the request and response objects.

See the below diagrams on how this works

Step 1
Step 4
Step 2
Step 5
Step 3
Step 6

The below is an example of how it looks in code

Servlet Code

import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;

public class TestServlet extends HttpServlet {

  public void doGet(HttpServletRequest request, HttpServletResponse response throws IOException {
    PrintWriter out = response.getWriter();
    java.util.Date today = new java.util.Date();
    out.println("<html> +
                "<body>" +
                "<h1 style="text-align:center">" +
                "Test Servlet</h1>" +
                "<br>" + today +
                "</body>" +

A servlet can have three names

Naming and Mapping Servlets

By mapping the name instead of coding in the real file and path name you have the flexibility to move things around without having the maintenance nightmare of tracking down and change client code that refers to the old location of the servlet files, also by mapping the filename you can hide the real directories, thus increasing security.

When you deploy your servlet into your Web Container, you will can create a XML document called the Deployment Descriptor (DD) to tell the Container how to run your servlets and JP. You use two XML elements to map URLs to servlets - one to map the client-known public URL name to your own internal name, and the other to map your own internal name to a fully-qualified class name. The class name will be located in a specific place which all servlets are located, the Container uses a sophisticated set of rules for finding a match between the URL that comes in from the client request and an actual Java class sitting somewhere on the server, this location will be discussed in a later topic.

URL mapping

<web-app ...>

    <servlet-name>Internal name 1</servlet-name>

    <servlet-name>Internal name 2</servlet-name>

    <servlet-name>Internal name 1</servlet-name>

    <servlet-name>Internal name 2</servlet-name>


You can use the DD to customize other aspects of your web application including security roles, error pages, tag libraries, initial configuration and if it's a full J2EE server (JBoss) you can even declare that you'll be accessing a specific enterprise Java Bean.

MVC Introduction

Model-View-Controller (MVC) is a design pattern that lets you separate the business logic from the presentation but put something between them so that the business logic can stand on its as a reusable Java class and does not have to know anything about the view. MVC is not specific to servlets and JSP but can be used in any application.

Model (M) is the logic of the site, the rules that determine what is shown and to whom it is shown. In other words it knows the rules for getting and updating the state, for an example a shopping cart contents would be part of the Model in MVC.
View (V) is the component of this architecture it is the JSPs that displays the content that is created, it is responsible for presentation, it gets the state of the model from the Controller. It also passes information to the controller so that the model can use it (like form data).
Controller (C) designates which part of the Model is invoked and which JSP is used to render the data. It defines the structure of the web site and the page flow logic basically takes user input from the request and figures out what it means to the model. Tells the model to update itself and makes the new model state available for the view (JSP).

I have also touched on this subject in my Tomcat section.

How JEE fits into all this

The Java Enterprise Edition (also called J2EE) is a kind of super edition, it incorporates other specifications including the servlets 2.4 spec and JSP 2.0 spec for the Web Container (Web components) and it also includes the Enterprise JavaBean 2.1 specification for the EJB Container (business components). fully-compliant JEE application server must have both a web container and an EJB container (plus other things including JNDI and JMS implementation).