Java servlets are making headlines these days, claiming to solve many of the problems associated with CGI and proprietary server API's. In this article Nakul describes the overall servlet architecture and what you need to develop a web application using servlets. He uses several coding examples to show you how to use the servlet API and compares it with CGI and proprietary server API's.
An Introduction to Java Servlets - The dark ages (Page 2 of 10 )
Back in the early nineties when the web was just starting to take shape, the Common Gateway Interface (CGI) was defined to allow Web servers to process user input and serve dynamic content. CGI programs can be developed in any scripting or programming language, however Perl is by far the most common language to use. Virtually all web servers support CGI and many Perl modules are available as freeware or shareware to handle most tasks.
CGI is not without drawbacks however. Performance and scalability are big problems since a new process is created for each request, quickly draining a busy server of resources. Sharing resources such as database connections between scripts or multiple calls to the same script is far from trivial, leading to repeated execution of expensive (in terms of processing power) operations.
Security is another big concern with CGI. Most Perl scripts use the command shell to execute OS commands with user-supplied data, for instance to send mail, search for information in a file, or just leverage OS commands in general. The use of shell in this way opens up many opportunities for a creative hacker to tinker with a script that might be able to remove all files on the server, mail the server's password file to a secret account, or do any other unauthorized activity that the host didn't anticipate.
Web server vendors have defined APIs to solve some of these problems, notably Microsoft's ISAPI and Netscape’s NSAPI. But an application written to these proprietary APIs is married to one particular server vendor. If you need to move the application to a another a server running a different vendor software then you have to start from scratch. Another problem with this approach is reliability. The APIs typically support C/C++ code executing in the Web server process. If the application crashes, e.g. due to a bad pointer or division by zero, then it brings the entire Web server down with it.