2.1 Servlet


A servlet is a java module stored and run on web server.
In web-based applications, the user access a system via a browser, and the bulk of code that implements the
application runs on a web server.
Those applications use Java servlets In order to carry out wide variety of functions.
As illustrated in figure 2.2 a servlet's job is to take a client's request, process it, and send back a response.
The client request might be simple such as get the welcome page or it might be complex such as process form
data, access database and construct complex web pages dynamically.
The request carries critical data, and the servlet code has to know how to find it and how to use it.
The response carries the information the browser needs to render a page (or download bytes), and the servlet
code has to know how to send it back or, it may pass the request to another page, servlet, or JSP instead
(13Ju).
Servlets are written in java therefore we can use the full capabilities of Java language. Servlets run on server,
where the security environment can be defined and controlled.

2.1 Servlet


Also Servlets are very useful in implementing the sort of 3-tier system we encountered in topic 1 for example;
servlets can get access to databases on the computer that hosts them or on a database server running on
another computer.
Also servlets have the advantage of separating the user interface of a web application (which runs on the client)
from the processing and database access.
This can make it easier to change and support system independency.
Figure 2.2: Web applications with server running Java servlet


2.1 Servlet


The Advantages of Servlets Over "Traditional" CGI
Java servlets are more efficient, easier to use, more powerful, more portable, safer, and cheaper than traditional
CGI and many alternative CGI-like technologies (Hall and Brown 2004).
Performance:
With traditional CGI, the server has to launch a heavy-weight process for each and every request.
The overhead of starting the process can dominate the execution time.
With servlets, the Java virtual machine stays running and handles each request with a lightweight Java
thread, not a heavyweight operating system process (Hall and Brown 2004).
Similarly, in traditional CGI, the code for the CGI program is loaded into memory for every request, if there
are N requests to the same CGI program, the code for the CGI program will be loaded N times.
On other hand with servlets, there would be N threads, but only a single copy of the servlet class would be
loaded.
This approach reduces server memory requirements and saves time by instantiating fewer objects (Hall and
Brown 2004).

2.1 Servlet


Finally, when servlets complete a response, they remain in memory, this approach makes it easy to cache
computations, keep database connections open, and perform other optimizations that rely on persistent
data.
With a traditional CGI program, the program terminates after finishing handling a request (Hall and Brown
2004).
Convenient:
With servlet technology, in addition to improved scalability, offers the well-known Java advantages of object
orientation, platform independence, security, and robustness.
Servlets are fully integrated with the Java language and its standard APIs, such as JDBC for Java database
connectivity and offers an extensive infrastructure for automatically parsing and decoding HTML form data,
reading and setting HTTP headers, handling cookies, tracking sessions, and many other such high-level
utilities.
In CGI, you have to do much of this yourself (Hall and Brown 2004).

2.1 Servlet


Powerful:
Servlets support several capabilities that are difficult or impossible to accomplish with regular CGI.
Servlets can talk directly to the Web server, whereas regular CGI programs cannot, at least not without using
a server-specific API.
Communicating with the Web server makes it easier to translate relative URLs into concrete path names, for
instance.
Multiple servlets can also share data, making it easy to implement database connection pooling and similar
resource-sharing optimizations.
Servlets can also maintain information from request to request, simplifying techniques like session tracking
and caching of previous computations (Hall and Brown 2004).
Portable:
Because servlets are written in the Java programming language, they are supported on any platform that
has a Java virtual machine and a Web server that supports servlets.
Servlets can be used on different platforms without recompiling.

2.1 Servlet


You can package servlets together with associated files such as graphics, sounds, and other data to make a
complete Web application.
This simplifies application development and deployment (Hall and Brown 2004).
Cheap:
A number of free or very inexpensive Web servers are good for development use or deployment of low or
medium volume Web sites.
Thus, with servlets and JSP you can start with a free or inexpensive server and migrate to more expensive
servers with high performance capabilities or advanced administration utilities only after your project meets
initial success (Hall and Brown 2004).
With servlets and JSP, you could start with a free server: Apache Tomcat (either standalone, embedded in
the regular Apache Web server, or embedded in Microsoft IIS).
Once the project starts to become successful, you could move to a server like Caucho Resin that had higher
performance and easier administration but that is not free.
If the project becomes even larger, you might want to move to a distributed (clustered) environment.

2.1 Servlet


No problem: you could move to Macromedia JRun Professional, which supports distributed applications
(Web farms).
If the project becomes quite large and complex, you might want to use Enterprise JavaBeans (EJB) to
encapsulate your business logic.
So, you might switch to BEA WebLogic or Oracle9i AS.
Finally, if your project becomes even bigger, you might move it off of their Linux box and onto an IBM
mainframe running IBM Web-Sphere.
And during this chain guess what? None of your servlets or JSP pages has to be rewritten (Hall and Brown
2004).
Secure:
One of the main sources of vulnerabilities in traditional CGI stems from the fact that the programs are often
executed by general purpose operating system shells.
So, the CGI programmer must be careful to filter out characters such as backquotes and semicolons that
are treated specially by the shell.

2.1 Servlet


Implementing this precaution is harder than one might think, and weaknesses stemming from this problem
are constantly being uncovered in widely used CGI libraries (Hall and Brown 2004).
A second source of problems is the fact that some CGI programs are processed by languages that do not
automatically check array or string bounds.
For example, in C and C++ it is perfectly legal to allocate a 100-element array and then write into the 999th
"element," which is really some random part of program memory.
So, programmers who forget to perform this check open up their system to deliberate or accidental buffer
overflow attacks (Hall and Brown 2004).
Servlets suffer from neither of these problems.
Even if a servlet executes a system call (e.g., with Runtime.exec or JNI) to invoke a program on the local
operating system, it does not use a shell to do so.
And, of course, array bounds checking and other memory protection features are a central part of the Java
programming language (Hall and Brown 2004).

2.1 Servlet


Mainstream:
Servlets are the single most popular application of the Java programming language.
They are arguably the most popular choice for developing medium to large Web applications.
They are used by the air-line industry (most United Airlines and Delta Airlines Web sites), online banking
(First USA Bank, Banco Popular de Puerto Rico), Web search engines/portals (excite.com), large financial
sites (American Century Investments), and hundreds of other sites that you visit every day.
Of course, popularity alone is no proof of good technology.
Numerous counter-examples abound.
But our point is that you are not experimenting with a new and unproven technology when you work with
server-side Java (Hall and Brown 2004).


2.1 Servlet


A quick peek at Servlet code
Figure 2.3 shows a simple servlet that outputs a small HTML page to the client. The code is explained in detail
later, but for now, just notice four points:
It is regular Java code. There are new APIs, but no new syntax.
It has unfamiliar import statements. The servlet and JSP APIs are not part of the Java 2 Platform, Standard
Edition (J2SE); they are a separate specification (and are also part of the Java 2 Platform, Enterprise
Edition-J2EE).
It extends a standard class (HttpServlet). Servlets provide a rich infrastructure for dealing with HTTP.
It overrides the doGet method. Servlets have different methods to respond to different types of HTTP
commands.

2.1 Servlet


Figure 2.3: Hello World servlet


2.1 Servlet


Figure 2.4: Hello World servlet result