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
See the below diagrams on how this works
The below is an example of how it looks in code
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.
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.
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).