The servlet is a Java programming language class used to extend the capabilities of a
server. Although servlets can respond to any types of requests, they are commonly used
to extend the applications hosted by web servers, so they can be thought of as Java applets
that run on servers instead of in web browsers. These kinds of servlets are the Java counterpart
to other dynamic Web content technologies such as PHP and ASP.NET.
Introduction Servlets are most often used to:
Process or store data that was submitted from an HTML form.
Provide dynamic content such as the results of a database query
Manage state information that does not exist in the stateless HTTP protocol, such as filling
the articles into the shopping cart of the appropriate customer
Technically speaking, a "servlet" is a Java class in Java EE that conforms to the Java
Servlet API, a standard for implementing Java classes which respond to requests. Servlets
could in principle communicate over any client–server protocol, but they are most often used with
the HTTP protocol. Thus "servlet" is often used as shorthand for "HTTP servlet". Thus,
a software developer may use a servlet to add dynamic content to a web server using
the Java platform. The generated content is commonly HTML, but may be other data such
as XML. Servlets can maintain state in session variables across many server transactions
by using HTTP cookies, or URL rewriting. To deploy and run a servlet, a web container
must be used. A web container is essentially the component of a web server that interacts
with the servlets. The web container is responsible for managing the lifecycle of servlets, mapping
a URL to a particular servlet and ensuring that the URL requester has the correct access
rights. The Servlet API, contained in the Java package
hierarchy javax.servlet, defines the expected interactions of the web container and a servlet.
A Servlet is an object that receives a request and generates a response based on that request.
The basic Servlet package defines Java objects to represent servlet requests and responses,
as well as objects to reflect the servlet's configuration parameters and execution environment.
The package javax.servlet.http defines HTTP-specific subclasses of the generic servlet elements,
including session management objects that track multiple requests and responses between
the web server and a client. Servlets may be packaged in a WAR file as a web application.
Servlets can be generated automatically from Java Server Pages by the JavaServer Pages
compiler. The difference between servlets and JSP is that servlets typically embed HTML
inside Java code, while JSPs embed Java code in HTML. While the direct usage of servlets
to generate HTML has become rare, the higher level MVC web framework in Java EE still explicitly
uses the servlet technology for the low level request/response handling via the FacesServlet.
A somewhat older usage is to use servlets in conjunction with JSPs in a pattern called
"Model 2", which is a flavor of the model–view–control The current version of Servlet is 3.1.
History The Servlet specification was created by Sun
Microsystems, with version 1.0 finalized in June 1997. Starting with version 2.3, the
specification was developed under the Java Community Process. JSR 53 defined both the
Servlet 2.3 and JavaServer Page 1.2 specifications. JSR 154 specifies the Servlet 2.4 and 2.5
specifications. As of March 26, 2010, the current version of the Servlet specification
is 3.0. In his blog on java.net, Sun veteran and GlassFish
lead Jim Driscoll details the history of servlet technology. James Gosling first thought of
servlets in the early days of Java, but the concept did not become a product until Sun
shipped the Java Web Server product. This was before what is now the Java Platform,
Enterprise Edition was made into a specification. Compared with other web application models
The advantages of using servlets are their fast performance and ease of use combined
with more power over traditional CGI. Traditional CGI scripts written in Java have a number
of performance disadvantages: When an HTTP request is made, a new process
is created each time the CGI script is called. The overhead associated with process creation
can dominate the workload especially when the script does relatively fast operations.
Thus, process creation will take more time for CGI script execution. In contrast, for
servlets, each request is handled by a separate Java thread within the web server process,
thereby avoiding the overhead associated with forking processes within the HTTP daemon.
Simultaneous CGI request will load the CGI script to be copied into memory once per request.
With servlets, there is only one copy that persists across requests and is shared between
threads. Only a single instance answers all requests
concurrently. This reduces memory usage and eases the management of persistent data.
A servlet can be run by a servlet container in a restrictive environment, called a sandbox.
This is similar to an applet that runs in the sandbox of the web browser. This enables
restricted use of potentially harmful servlets. CGI programs can of course also sandbox themselves,
since they are simply OS processes. Technologies like FastCGI and its derivatives
do not exhibit the performance disadvantages of CGI incurred by the constant process spawning.
They are, however, roughly as simple as CGI. They are therefore also in contrast with servlets
which are substantially more complex. Life cycle of a servlet
Three methods are central to the life cycle of a servlet. These are init(), service(),
and destroy(). They are implemented by every servlet and are invoked at specific times
by the server. During initialization stage of the servlet
life cycle, the web container initializes the servlet instance by calling the init()
method, passing an object implementing the javax.servlet.ServletConfig interface. This
configuration object allows the servlet to access name-value initialization parameters
from the web application. After initialization, the servlet instance
can service client requests. Each request is serviced in its own separate thread. The
web container calls the service() method of the servlet for every request. The service()
method determines the kind of request being made and dispatches it to an appropriate method
to handle the request. The developer of the servlet must provide an implementation for
these methods. If a request is made for a method that is not implemented by the servlet,
the method of the parent class is called, typically resulting in an error being returned
to the requester. Finally, the web container calls the destroy()
method that takes the servlet out of service. The destroy() method, like init(), is called
only once in the lifecycle of a servlet. The following is a typical user scenario of
these methods. Assume that a user requests to visit a URL.
The browser then generates an HTTP request for this URL.
This request is then sent to the appropriate server.
The HTTP request is received by the web server and forwarded to the servlet container.
The container maps this request to a particular servlet.
The servlet is dynamically retrieved and loaded into the address space of the container.
The container invokes the init() method of the servlet.
This method is invoked only when the servlet is first loaded into memory.
It is possible to pass initialization parameters to the servlet so that it may configure itself.
The container invokes the service() method of the servlet.
This method is called to process the HTTP request.
The servlet may read data that has been provided in the HTTP request.
The servlet may also formulate an HTTP response for the client.
The servlet remains in the container's address space and is available to process any other
HTTP requests received from clients. The service() method is called for each HTTP
request.
The container may, at some point, decide to unload the servlet from its memory.
The algorithms by which this decision is made are specific to each container.
The container calls the servlet's destroy() method to relinquish any resources such as
file handles that are allocated for the servlet; important data may be saved to a persistent
store. The memory allocated for the servlet and its
objects can then be garbage collected. Example
The following example Servlet prints how many times its service() method was called.
Note that HttpServlet is a subclass of GenericServlet, an implementation of the Servlet interface.
The service() method of HttpServlet class dispatches requests to the methods doGet(),
doPost(), doPut(), doDelete(), and so on; according to the HTTP request. In the example
below service() is overridden and does not distinguish which HTTP request method it serves.
Container servers GlassFish
IBM WebSphere Application Server Jetty
Apache Tomcat Caucho Resin http:www.caucho.com/ - A commercial
Servlet container. Caudium
Oracle iPlanet Web Server References
^ "servlet". http:www.webopedia.com/: WEBOPEDIA. Retrieved 2011-04-27. "A small java program
that runs on a server. The term usually refers to a Java applet that runs within a web server
environment. This is analogous to a Java applet that runs within a web browser environment."
^ Java Servlet API ^ a b c [1] 1.1 What is a servlet?
^ "Servlet History | Java.net". Weblogs.java.net. 2005-12-10. Retrieved 2013-06-14.
^ [2] External links
Official servlet tutorials from Sun/Oracle: Java EE 6
Oracle's Servlet technology overview JSR
JSR 315 - Servlet 3.0 JSR 154 - Servlet 2.4 and 2.5
JSR 53 - Servlet 2.3
New features added to Servlet 2.5 at JavaWorld