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.[1 These !inds of servlets are the
Java counterpart to other dynamic "eb content technologies such as #$# and
A%#.&'T.%ervlets are most often used to([citation needed
#rocess or store data that was submitted from an $T)* form.
#rovide dynamic content such as the results of a database query
)anage state information that does not exist in the stateless $TT# protocol, such as
filling the articles into the shopping cart of the appropriate customer
Technically spea!ing, a +servlet+ is a Java class in Java '' that conforms to the Java
%ervlet A#,,[- a standard for implementing Java classes which respond to requests.
%ervlets could in principle communicate over any client.server protocol, but they are
most often used with the $TT# protocol. Thus +servlet+ is often used as shorthand for
+$TT# 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 $T)*, but
may be other data such as 0)*. %ervlets can maintain state in session variables across
many server transactions by using $TT# coo!ies, or 12* rewriting.
To deploy and run a servlet, a web container must be used. A web container 3also !nown
as a servlet container4 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 12* to a particular servlet and ensuring that the 12* requester has the
correct access rights.
The %ervlet A#,, contained in the Java pac!age hierarchy 5avax.servlet, defines the
expected interactions of the web container and a servlet.[/
A %ervlet is an ob5ect that receives a request and generates a response based on that
request. The basic %ervlet pac!age defines Java ob5ects to represent servlet requests
and responses, as well as ob5ects to reflect the servlet6s configuration parameters and
execution environment. The pac!age 5avax.servlet.http defines $TT#7specific
subclasses of the generic servlet elements, including session management ob5ects that
trac! multiple requests and responses between the web server and a client. %ervlets
may be pac!aged in a "A2 file as a web application.
%ervlets can be generated automatically from Java %erver #ages 3J%#4 by the
Java%erver #ages compiler. The difference between servlets and J%# is that servlets
typically embed $T)* inside Java code, while J%#s embed Java code in $T)*. "hile
the direct usage of servlets to generate $T)* 3as shown in the example below4 has
become rare, the higher level )89 web framewor! in Java '' 3J%:4 still explicitly uses
the servlet technology for the low level request;response handling via the :aces%ervlet.
A somewhat older usage is to use servlets in con5unction with J%#s in a pattern called
+)odel -+, which is a flavor of the model.view.controller pattern.
The current version of %ervlet is /.1.
$istory[edit
The %ervlet specification was created by %un )icrosystems, with version 1.< finali=ed in
June 1>>?. %tarting with version -./, the specification was developed under the Java
9ommunity #rocess. J%2 @/ defined both the %ervlet -./ and Java%erver #age 1.-
specifications. J%2 1@A specifies the %ervlet -.A and -.@ specifications. As of )arch -B,
-<1<, the current version of the %ervlet specification is /.<.
,n his blog on 5ava.net, %un veteran and Class:ish lead Jim Driscoll details the history of
servlet technology.[A James Cosling first thought of servlets in the early days of Java,
but the concept did not become a product until %un shipped the Java "eb %erver[clarify
product. This was before what is now the Java #latform, 'nterprise 'dition was made
into a specification.*ife cycle of a servlet[edit
Three methods are central to the life cycle of a servlet. These are init34, service34, and
destroy34. They are implemented by every servlet and are invo!ed at specific times by
the server.
During initiali=ation stage of the servlet life cycle, the web container initiali=es the servlet
instance by calling the init34 method, passing an ob5ect implementing the
5avax.servlet.%ervlet9onfig interface. This configuration ob5ect allows the servlet to
access name7value initiali=ation parameters from the web application.
After initiali=ation, the servlet instance can service client requests. 'ach request is
serviced in its own separate thread. The web container calls the service34 method of the
servlet for every request. The service34 method determines the !ind 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. ,f 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.
:inally, the web container calls the destroy34 method that ta!es the servlet out of service.
The destroy34 method, li!e init34, is called only once in the lifecycle of a servlet.The
advantages of using servlets are their fast performance and ease of use combined with
more power over traditional 9C, 39ommon Cateway ,nterface4. Traditional 9C, scripts
written in Java have a number of disadvantages when it comes to performance(
"hen an $TT# request is made, a new process is created for each call of the 9C,
script. This overhead of process creation can be very system7intensive, especially when
the script does relatively fast operations. Thus, process creation will ta!e more time for
9C, script execution. ,n contrast, for servlets, each request is handled by a separate
Java thread within the web server process, omitting separate process for!ing by the
$TT# daemon.
%imultaneous 9C, request causes the 9C, script to be copied and loaded into memory
as many times as there are requests. "ith servlets, there is only one copy that persists
across requests and is shared between threads.
Enly a single instance answers all requests concurrently. This reduces memory usage
and ma!es the management of persistent data easy.
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 ma!es a
restrictive use of potentially harmful servlets possible.[/ 9C, programs can of course
also sandbox themselves, since they are simply E% processes.
Technologies li!e :ast9C, and its derivatives 3including %9C,, "%C,4 do not exhibit the
performance disadvantages of 9C, incurred by the constant process spawning. They
are, however, roughly as simple as 9C,. They are therefore also in contrast with servlets
which are substantially more complex.