15 Servlet Container and structure of Web Application

Pravin Jain

Servlet specifications for server side

In a earlier module we have already seen about http protocol which is a key to the web application. What we had seen in the earlier module which was related to the http protocol, we had seen the structure of the http protocol, the structure of the request, the response, and the api which we had seen was something about how to interact with the server. To send a http request and get a response from the server, so that is something which would be used from the client side, now we are looking at the java on the server side.

So developing a client-server application, but here the client is going to be a browser, so we are interested in doing something on the server side. What are the options for the server side and how Java fits on the server side and that too for http protocol.

So as we mentioned earlier module for enterprise application, that one of the specification available as part of javaEE is the servlet specification. So we are now looking at the server side specification for the web which is going to be the servlet specification.

Servlet specification is about how to help a Java developer to create just the components which can get the information submitted as part of an http request, sending a response which is normally a content back to a http client without actually worrying about implementing the http protocol itself.

So this is the specification for the http on the server side. So the term used here is web container/servlet container. Container is a place where various kind of components are supported. The component here is going to be a Servlet. We have kind of a definition for a servlet, what is a Servlet?

A Servlet is a java component on the server side which can handle a request and give a response back to the client. It is meant for those type of protocols which are based on request-response paradigm and the most commonly used protocol here is the http protocol.

Our servlet specifications are created in two parts:

1. In general it is a specification which is for a server side where any client may be sending a request, which may have a content also and giving back a response in the form of a content. So any content based request response protocol could be used. So this specification is a general specification.
2. It has a specific part, specific to the http protocol.

So to help development in the servlet specification, it has its own API API here has two major packages:

1. javax.servlet package
2. javax.servlet.http package

Let us try to understand what exactly happens on the server side.

Look at it from the client point of view, what does a client do? A client uses a browser, keys in a url, once he keys in a URL, an http request is sent by the browser, to the server and it is waiting for the response from the server.

The response in the form of the content. We have already seen the format of the response for http protocol.

Now, if we look at the URL, what is the url made up of?

typically you specify the host, domain name identifying the host, then what is the rest of it, / and then what, that whole of the string which is after domain is known as a resource.

URL is nothing but a Uniform Resource Locator, where we are specifying that using a particular protocol, so you have scheme like http: then we saying // and then we are specifying a host, so on that host we are saying, I want that specific resource using this particular protocol.

So here host and port are used to identify how to make a connection. But once a connection is done, on this connection, the protocol is simply to specify the resource, and the resource is also specified in the hierarchical term in the form of a path which is a hierarchical thing. So it starts with / and some..name and / and some..more..thing/ and some..more..thing forming a path. On any host which is supporting some type of a protocol which is based on some resources, you are identifying a set of resources.

Let us come to a definition of a web application. What is a web application? A web application is nothing but a collection of a resources, which would be identified by the initial path in your URL. When I talk of a new resource means I have a resource which starts with some name.

Let us think that you want an application on the server side, which would be related to an inventory. So if you thinking of an application for inventory, the resource name would look like, it identifies the host in the URL like.. hostname/inventory/… within inventory I have various resources, so what is an application? it is a collection. of resources, the initial /inventory is identifying the application and within that I have the whole set of resources.

So when we are looking at the web application from the point of view of the end user, we are identifying it and relating to the URL, and in url we have the initial part the first part identifies our web application. / and the single identifier eg. /inventory.

In the servlet specification there was a major change, a major standardization, which came in version 2.0, and the current specification is 3.1. But in the initial specifications there was no concept of a web application, so each thing was a servlet, we were identifying each servlet independently, and we were only identifying servlets which serves the request.

In servlet specifications 2.0 they started the concept of web application, where the initial part of the URL was identifying the application. Not only there was specification there was a term called web application which was defined, but there was also a standardization on how to organise the resources on server side. There was also a standardization of the directory structure for any kind of a web application. So it does not matter which implementation of servlet specification you are using, because we have various options of using the servlet specifications. You could be using a servlet specification ….

Most commonly used implementation of Servlet specification is the Tomcat server which is simply an implementation of the servlet specifications and the web related specification and not the whole of the javaEE specifications, it does not implement the whole of JEE, but it implements the web tier of the javaEE specifications.

So it is implementing the servlet specifications, JSTL specification, EL specification all those things are being supported in the tomcat. So tomcat is that kind of an implementation.

So coming back to what is that directory structure, which has been

If you want to have any web application you should have separate directory for each web application, so if I want to have an application for an inventory i would have a folder called inventory and within that folder whatever I have they are all identified as a resources in the inventory web application.

So if I  say  I have an index.html then someone may ask  for it like hostname/inventory/index.html.

if I want some image, let us say, I do have a folder called images and have some jpeg file in the image folder which may be a part of an inventory folder, so it is accessible as hostname/inventory/images/… so like this anything under this folder is accessible by using the URL.

So web application is the structure. you have the folder for the application and you have all your static resources organised there.

So servlet is a java component but it is not acting like the resource. so if I have compiled class file for the servlet, but the class file is not the resource here. The job of servlet here is whenever a client hits for the resource name which corresponds to the servlet, servlet is not the thing which has to be transferred as a content rather it is a content generator.

i.e. when the servlet code is hit as a resource it is not the class file which has to go but lifecycle method has to be invoked which in turn result in generation of a content and the generated content is then to be sent back to the client.

So there is a provision in the directory structure given by the specification for certain things to not be accessible to the client by using a URL directly, not as a content. so for that what has been done here is, that we have a special folder called WEB-INF in the directory structure for a web application. A WEB-INF folder is a private folder. So whatever is there in the WEB-INF is not accessible to the client. So there can be a class file in the WEB-INF and also other things can be kept in the WEB-INF folder.

So let us say, if a client hits the URL saying http://hostname//inventory//WEB- INF and tries to access any content of the WEB-INF folder, the client is always going to get 404 – file not found. This is what the servlet specification is all about.

So when the container would start, it would be loading JVM so if somebody hits for the servlet it would result in loading of some classes. These classes are not the one which needs to be transferred like applet. applet is a content but not the servlet class. So it is required to load the classes and for loading these classes in the web container there is a specific structure specified.

So within the WEB-INF folder we have two specific folders with fixed names called classes in which you can organise class files, if you have packages then we will have package structure within the classes folder, but if you got some jar files for jdbc drivers, some apis for which, jar files are available, then you don’t have to extract those jar files and put them into classes folder. for jar files and all we have another folder called lib. Within lib folder you can keep all kind of your jar files. So all our apis, the drivers all goes in the lib folder. This is how our web application components are organised.

So now it is important to know which servlet corresponds to which resource such mapping needs to be made available to the container. So making this mapping available the servlet specification uses a xml file where we can specify various java components to be used here. which are part of the application server for this particular web application.for each web application there is going to a separate xml file which is known as the deployment descriptor for the web application.

We will go through various type of tag used in our deployment descriptor. Deployment Descriptor is also identified as web.xml under the folder WEB-INF. so whenever web container starts it is actually looking for the folder containing web.xml file for identifying the java components. So the structure of web application is like one folder containing static resources and another folder which is private where we keep something which is not served directly as a content. So you may keep something outside the WEB-INF which can be served as a content which can be specified in URL and can be accessed straight away by the client.

For the client web application is something where he can access the resources through URL. So resources are the static content and the java components. So web container when starts looks for what all applications are deployed on the server which is identified by WEB-INF folder for the deployment descriptor which is nothing but our web.xml file. It reads the content of web.xml file. for every web application which is there, something is happening on the server side.

The Container, for each identified web application it would create one object of ServletContext and corresponding to it is web.xml. One web.xml per web application. The top level tag in our deployment descriptor is <web- app></web-app>.

Each of these web containers have some kind of administrative tools through which we can see the list of applications.

One of the tags within <web-app></web-app> is <display-name></display-name> -has some name to identify the application. This may be used in the administration tools and may be shown in the listing of web application.

<context-param></context-param>- has <param-name> tag and <param- value>. you can have any number of <context-param> eg: JDBC driver name to be used, JDBC class name, JDBC URL to be used, may be specified using the <context-param> tag.

Now we would like to have servlet which would service any request coming from the client. In javaEE it is not the developer creating servlet component but it is the container doing that. So the role of the container is to manage the components. We have something in our web.xml by which our container is creating the objects of our servlet. So if we want to have servlets we could add in our deployment descriptor, a tag called <servlet></servlet>.

<servlet></servlet>-by using this tag we asking the container to create our object of our servlet. within this tag we will mention <servlet-name></servlet- name> by which this object is identified and <servlet-class></servlet-class>, name of a class which is an implementation of Servlet interface. We may need multiple object of the servlet class. we cannot have two objects with the same name. <servlet name> cannot be repeated but <servlet class> can be the same. Instead of writing the java code for handling request and response someone may be more comfortable writing the JSP which is more about giving the response. It is something like giving straight away the content if someone request for such servlet. JSP is also a special kind of servlet which is user interface oriented rather than handling the particular request. So, if we have developed a JSP and not a java file. you could have a <servlet> entry which says thats my <servlet-name> and <servlet-class>, but instead of using <servlet- class>, we can have <jsp-file> which gives the location within the application starting with the /. for eg you don’t to give access directly to the JSP so in the WEB-INF you can create the jsp folder where you can have something like myJsp.jsp so you can mention it as /WEB-INF/jsp/myJsp.jsp. By mentioning the servlet you are forcing the container to create object.

Now when the application starts is it that time the object needs to be created and initialisation done right at the beginning or should it be done when the first request comes for the component. So we are interested for the object to be created right at the beginning, when the application starts, for that we got another tag here called <load-on-startup></load-on-startup> within which some numerical value is given. This numerical value is a sequence number. We have <servlet> entries and many of the <servlet> entries may have <load-on-startup> tag. So when the servlet will be loaded and the object will be created depends on the <load-on-startup> tag. Let us say we have its value as 1, then that servlet will be loaded first. So basically it is the sequence for the servlet to be loaded and initialised.

Another  tag  within  the  <servlet>  tag  is,  <init-param></init-param>.  It  has <param-name> and <param-value> specific to servlet.

<servlet> tag is the list of servlet objects that need to be created. There should be resource name to know when to use which servlet. We need to map URL to the servlet to know when, which servlet should be used. So there is one more entry called <servlet-mapping>. <servlet-mapping></servlet-mapping> contains other tags called <servlet-name></servlet-name> and <url- pattern></url-pattern> which indicates that whenever any such pattern comes in the url this servlet should be used. You may use two different pattern with the same <servlet-name> but in the different <servlet-mapping>. There are three different ways of specifying url here.

1. specific path : /something/something/something specific name and path for the
2. wild card: /inventory/hello/* in this the end of the url pattern should be /*. 3)extension based : in this url pattern ends as *.ext or *.hello.

There are going to be other types of components along with the servlets in web.xml like filters etc. which we will come across later.

Suggested Reading:

1. Core Servlets and Java Server Pages Volume 2 by Marty Hall & Larry Brown, Second Edition, Pearson Education.
2. Inside Servlets by Dustin R Callaway, Pearson Education.
3. Java Server Programming for Professionals by Ivan Bayross, Sharanam Shah, Cynhthia Bayross and Vaishali Shah Shroff Publishers and Distributros.
4. http://download.oracle.com/otndocs/jcp/servlet-3.0-fr-oth-JSpec/