1.1 History of Web Applications

Java Servlet Programming, 2nd Edition > 1. Introduction > 1.1 History of Web Applications

< BACK

CONTINUE >

While servlets can be used to extend the functionality of any Java-enabled server, they are most often used to extend web servers, providing a powerful, efficient replacement for CGI scripts. When you use a servlet to create dynamic content for a web page or otherwise extend the functionality of a web server, you are in effect creating a web application. While a web page merely displays static content and lets the user navigate through that content, a web application provides a more interactive experience. A web application can be as simple as a keyword search on a document archive or as complex as an electronic storefront. Web applications are being deployed on the Internet and on corporate intranets and extranets, where they have the potential to increase productivity and change the way that companies, large and small, do business.

To understand the power of servlets, we need to step back and look at some of the other approaches that can be used to create web applications.

1.1.1 Common Gateway Interface

The Common Gateway Interface, normally referred to as CGI, was one of the first practical techniques for creating dynamic content. With CGI, a web server passes certain requests to an external program. The output of this program is then sent to the client in place of a static file. The advent of CGI made it possible to implement all sorts of new functionality in web pages, and CGI quickly became a de facto standard, implemented on dozens of web servers.

It's interesting to note that the ability of CGI programs to create dynamic web pages is a side effect of its intended purpose: to define a standard method for an information server to talk with external applications. This origin explains why CGI has perhaps the worst life cycle imaginable. When a server receives a request that accesses a CGI program, it must create a new process to run the CGI program and then pass to it, via environment variables and standard input, every bit of information that might be necessary to generate a response. Creating a process for every such request requires time and significant server resources, which limits the number of requests a server can handle concurrently. Figure 1-1 shows the CGI life cycle.

Figure 1-1. The CGI life cycle

Even though a CGI program can be written in almost any language, the Perl programming language has become the predominant choice. Perl's advanced text-processing capabilities are a big help in managing the details of the CGI interface. Writing a CGI script in Perl gives it a semblance of platform independence, but it also requires that each request start a separate Perl interpreter, which takes even more time and requires extra resources.

Another often-overlooked problem with CGI is that a CGI program cannot interact with the web server or take advantage of the server's abilities once it begins execution, because it is running in a separate process. For example, a CGI script cannot write to the server's log file. For more information on CGI programming, see CGI Programming on the World Wide Web by Shishir Gundavaram (O'Reilly).

1.1.1.1 FastCGI

A company named Open Market developed an alternative to standard CGI named FastCGI. In many ways, FastCGI works just like CGI the important difference is that FastCGI creates a single persistent process for each FastCGI program, as shown in Figure 1-2. This eliminates the need to create a new process for each request.

Figure 1-2. The FastCGI life cycle

Although FastCGI is a step in the right direction, it still has a problem with process proliferation: there is at least one process for each FastCGI program. If a FastCGI program is to handle concurrent requests, it needs a pool of processes, one per request. Considering that each process may be executing a Perl interpreter, this approach does not scale as well as you might hope. (Although, to its credit, FastCGI can distribute its processes across multiple servers.) Another problem with FastCGI is that it does nothing to help the FastCGI program more closely interact with the server. Finally, FastCGI programs are only as portable as the language in which they're written. For more information on FastCGI, see http://www.fastcgi.com.

1.1.1.2 PerlEx

PerlEx, developed by ActiveState, improves the performance of CGI scripts written in Perl that run on Windows NT web servers (Microsoft's Internet Information Server and iPlanet's FastTrack Server and Enterprise Server). It has advantages and disadvantages similar to FastCGI. For more information on PerlEx, see http://www.activestate.com/plex.

1.1.1.3 mod_perl

If you are using the Apache web server, another option for improving CGI performance is using mod_perl. mod_perl is a module for the Apache server that embeds a copy of the Perl interpreter into the Apache executable, providing complete access to Perl functionality within Apache. The effect is that your CGI scripts are precompiled by the server and executed without forking, thus running much more quickly and efficiently. The downside is that the application can be deployed only on the Apache server. For more information on mod_perl, see http://perl.apache.org.

1.1.2 Other Solutions

CGI/Perl has the advantage of being a more-or-less platform-independent way to produce dynamic web content. Other well-known technologies for creating web applications, such as ASP and server-side JavaScript, are proprietary solutions that work only with certain web servers.

1.1.2.1 Server extension APIs

Several companies have created proprietary server extension APIs for their web servers. For example, iPlanet/Netscape provides an internal API called WAI (formerly NSAPI) and Microsoft provides ISAPI. Using one of these APIs, you can write server extensions that enhance or change the base functionality of the server, allowing the server to handle tasks that were once relegated to external CGI programs. As you can see in Figure 1-3, server extensions exist within the main process of a web server.

Figure 1-3. The server extension life cycle

Because server-specific APIs use linked C or C++ code, server extensions can run extremely fast and make full use of the server's resources. Server extensions, however, are not a perfect solution by any means. Besides being difficult to develop and maintain, they pose significant security and reliability hazards: a crashed server extension can bring down the entire server; a malicious server extension could steal user passwords and credit card numbers. And, of course, proprietary server extensions are inextricably tied to the server API for which they were written and often tied to a particular operating system as well.

1.1.2.2 Server-side JavaScript

iPlanet/Netscape also has a technique for server-side scripting, which it calls server-side JavaScript, or SSJS for short. Like ASP, SSJS allows snippets of code to be embedded in HTML pages to generate dynamic web content. The difference is that SSJS uses JavaScript as the scripting language. With SSJS, web pages are precompiled to improve performance. Support for server-side JavaScript is available only with iPlanet/Netscape servers. For more information on programming with server-side JavaScript, see http://developer.netscape.com/tech/javascript/ssjs/ssjs.html.

1.1.2.3 Active Server Pages

Microsoft has a technique for generating dynamic web content called Active Server Pages , or sometimes just ASP. With ASP, an HTML page on the web server can contain snippets of embedded code (usually VBScript or JScript although it's possible to use nearly any language). This code is read and executed by the web server before it sends the page to the client. ASP is optimized for generating small portions of dynamic content, using COM components to do the heavy lifting.

Support for ASP is built into Microsoft Internet Information Server Version 3.0 and above, available for free from http://www.microsoft.com/iis. Support for other web servers is available as a commercial product from Chili!Soft at http://www.chilisoft.com. Beware that ASP pages running on a non-Windows platform may have a hard time performing advanced tasks without the Windows COM library. For more information on programming Active Server Pages, see http://www.microsoft.com/asp/ and http://www.activeserverpages.com/.

1.1.2.4 JavaServer Pages

JavaServer Pages , commonly called just JSP, is a Java-based alternative to ASP, invented and standardized by Sun. JSP uses a syntax similar to ASP except the scripting language is Java. Unlike ASP, JSP is an open standard implemented by dozens of vendors across all platforms. JSP is closely tied with servlets because a JSP page is transformed into a servlet as part of its execution. JSP is discussed in more detail throughout this book. For more information on JSP, see http://java.sun.com/products/jsp.

1.1.3 Java Servlets

Enter Java servlets. As was said earlier, a servlet is a generic server extension a Java class that can be loaded dynamically to expand the functionality of a server. Servlets are commonly used with web servers, where they can take the place of CGI scripts. A servlet is similar to a proprietary server extension, except that it runs inside a Java Virtual Machine (JVM) on the server (see Figure 1-4), so it is safe and portable. Servlets operate solely within the domain of the server: unlike applets, they do not require support for Java in the web browser.

Figure 1-4. The servlet life cycle

Unlike CGI and FastCGI, which must use multiple processes to handle separate programs and/or separate requests, servlets can all be handled by separate threads within the same process or by threads within multiple processes spread across a number of backend servers. This means that servlets are also efficient and scalable. Because servlets run with bidirectional communication to the web server, they can interact very closely with the server to do things that are not possible with CGI scripts.

Another advantage of servlets is that they are portable: both across operating systems as we are used to with Java and also across web servers. As you'll see shortly, all of the major web servers and application servers support servlets. We believe that Java servlets offer the best possible platform for web application development, and we'll have much more to say about this later in the chapter.

< BACK

CONTINUE >