Web Applications

The Internet is a colossal network of networks, and in general, all of the machines on the Internet can be classified
into two types: the server and the client. The client is the machine requesting some information, and the server
is the machine that provides that information. The information data that flows from the information provider
(that is, the server) to the information requester (that is, the client) is bound by a definite rule that governs the
marshaling of the information to be transmitted by the server and the unmarshaling of the information to be
translated or read by the client. This rule is called the protocol.

The web browser (that is, the client), the web server (that is, the server), and the web application all converse
with each other through the Hypertext Transfer Protocol (HTTP). The clients send HTTP requests to the web
servers, and the web servers return the requested data in the form of HTTP responses. The HTTP clients and
the HTTP servers are the bricks and mortar that lay the foundation of the World Wide Web, and HTTP is the
lingua franca of the Web.

HTTP is a request-response stateless protocol, the corollary of which is that, from the web server’s view, any
request is the first request from the web browser. When a client makes a request for the resource, the request
also encloses the identification of the resource being requested, in the form of a Uniform Resource Locator
(URL). URLs are described in RFC 3986 as a uniform way of uniquely identifying a resource. URLs are designed
to implicitly provide a means of locating a resource by describing its “location” on a network.

A generic URL is a hierarchical sequence of components, structured as

scheme://hostName:portNumber/path/resource?query string

To identify the parts of a URL, consider the following URL example:

http://www.yourbookstore.com/bookstore/bookServlet?action=bookDetails

Figure 1 illustrates the parts of this URL

Figure 1: Anatomy of a URL

The host name and port number together are termed an authority. By default, a web server such as Tomcat, as
explained later, listens for incoming requests on port 8080. Some parts of the URL shown in Figure 1 are optional,
including the port number (which defaults to the well-known ports 80 and 443 for the HTTP and HTTPS

1
schemes, respectively) and the query string. When present, a query string is a series of name-value pairs preceded
with a question mark (?) and with an ampersand (&) separating the pairs.

A web application is a collection of web components that work together to provide a specific functionality on
the Web. In the Java EE specification, a web component is defined to be either a Servlet or a Java Server Page
(JSP) page.

The web application and its constituent components are managed and executed inside the web container, also
called a servlet container, which provides additional features to the web application such as security. When the
web server gets a request for specific functionality that a particular web component (such as a servlet or a JSP
page) can provide, the web server forwards the request to the servlet container in which the web component
resides. All requests for the dynamic content (that is, all requests to the web component that is responsible for
generating the dynamic content) are mediated by the servlet container, as shown in Figure 2.

Figure 2: Request for dynamic content

The Java EE Servlet and JSP specifications describe the service contract that a servlet container must provide
and specify how a servlet should use those services. In terms of implementation, a servlet is a Java class that acts
as a dynamic web resource.

Servlets
Servlets are the central processing unit of a Java web application and are responsible for most of the processing
required by a web application. Specifically, a servlet is a Java class that implements the javax.servlet.Servlet
interface. The Servlet interface defines the methods that all servlets must implement. “One ring to rule them
all!” This interface, along with other methods, defines key life-cycle methods such as init(), service(), and
destroy() to initialize a servlet, to service requests, and to remove a servlet from the server, respectively. Table
1 describes all the methods of the javax.servlet.Servlet interface.

Table 1: The Life-Cycle and Non-Life-Cycle Methods of the Servlet Interface

Modifier and Type Method
void init(ServletConfig config)
void service(ServletRequest req, ServletResponse res)
void destroy()
ServletConfig getServletConfig()
String getServletInfo()

2
The life-cycle methods are invoked by the container at appropriate instants in a servlet’s life in the following
sequence:
1. The servlet is constructed and then initialized with the init method.
2. Any calls from clients to the service method are handled.
3. The servlet is then destroyed with the destroy method, garbage collected, and finalized.

The Servlet interface methods illustrated in Table 1 are explained here:

 init(ServletConfig): Called by the servlet container exactly once after instantiating the servlet. This
method must complete successfully before the servlet is a candidate to receive any requests.
 service(): Called by the servlet container, after the servlet’s init() method has completed
successfully, to allow the servlet to respond to a request.
 destroy(): Called by the container to destroy the servlet and serves as a method in which the servlet
must release acquired resources before it is destroyed.
 getServletConfig(): Allows the servlet to get start-up information in the form of a ServletConfig
object returned by this method. The ServletConfig object contains initialization and start-up
parameters for the servlet.
 getServletInfo(): Allows the servlet to return its own information such as the servlet’s author and
version.