Before Netscape, when Mosaic ruled the Web and people needed a straightforward way to exchange information between client and server, the Common Gateway Interface (CGI) was born. CGI applications (usually called scripts) run on the server side. A user initiates a request via HTTP and optionally transmits information, which is handed off to the CGI script. The script processes the information and packages a reply, which the server sends to the user.
Before Netscape, when Mosaic ruled the Web and people needed a straightforward way to exchange information between client and server, the Common Gateway Interface (CGI) was born. CGI applications (usually called scripts) run on the server side. A user initiates a request via HTTP and optionally transmits information, which is handed off to the CGI script. The script processes the information and packages a reply, which the server sends to the user.
The Need for Servlets
When CGI scripts were first developed, they were often written in C or Perl. C had the advantage of speed, while Perl was cross-platform. Both, however, suffered from the overhead needed to fork a new process each time the Web server needed the CGI script. The Apache Web server mitigates that penalty with modules like mod_perl, but Sun Microsystems came up with a better alternative: the Java servlet.
Figure One: The complete cycle of a Java servlet request/respond transaction.
A servlet is just a regular Java class that implements the interface javax. servlet.Servlet as defined by the Java Servlet Specification (http://java.sun.com/products/servlet). Servlets run in a separate container, which runs a Java Virtual Machine. The JVM then executes the servlet as a thread.
A typical setup uses Apache as the Web server and Tomcat as…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
