No book on web technology would be complete without a brief look at how the World Wide Web (WWW) has become as popular as it is today. The Web has come a long way since the days when the first hypertext documents were sent over the Internet. In 1989, when the physicists at the CERN laboratory proposed the idea of sharing research information between researchers using hypertext documents, they had no idea how big the Web would grow or how essential it would become to daily life for much of the industrialized world. The Web is now an accepted part of our vernacular.
It took a while for the benefits of using the Web to become clear to others outside of CERN, but as we all know, it eventually erupted into what we use today. From its beginnings, the Web was designed for dealing with static documents, but it was a natural progression to want the ability to generate document content dynamically. The Common Gateway Interface (CGI) was created to do that very thing. CGI is a standard that allows web servers to interact with external applications in such a way that hypertext pages no longer have to be static. A CGI program can retrieve results from a database and insert those results as a table in a hypertext document. Likewise, data entered into a hypertext page can be inserted into the database. This technology opened up infinite possibilities and, in fact, started the Internet craze of the mid-1990s and today.
Although CGI applications are very good at what they do, there are some serious limitations to this approach. For one thing, CGI applications are very resource-intensive. A new operating system (OS) heavyweight process is created to handle every request that comes from a browser. Once the CGI script is finished executing, the process has to be reclaimed by the OS. This constant starting and stopping of heavyweight processes is terribly inefficient. You can imagine how bad the response time might be if hundreds of concurrent users were making requests to the same web application. Another major limitation of CGI is that it's difficult to link to other stages of request processing, because it is running in a separate process from the web server. This makes it difficult to handle things such as authorization, workflow, and logging.
A few alternatives to standard CGI applications have been put forward. One alternative is FastCGI, a language-independent extension to CGI that doesn't have the same process model as standard CGI. It's able to create a single heavyweight process for each FastCGI program, allowing multiple requests to run within the same process space. However, when clients interact concurrently with the same FastCGI program, the program needs to create a pool of processes to handle each request. This is not much better than standard CGI. Another problem with FastCGI applications is that they're only as portable as the languages in which they are written. Other alternatives to CGI include mod_perl for Apache, NSAPI for Netscape, and ISAPI for Microsoft's IIS web server. While these solutions often offer better performance and scalability than standard CGI programs, they still have portability issues.
In 1997, while the Java language was experiencing tremendous growth and use by application developers, the Java Servlet technology was created. This new web technology opened up an entirely new avenue for web developers to explore.