Chapter 1: Introducing Tomcat

This, as befits a first chapter in a book on Tomcat, is a short history of dynamic Web content and how Tomcat fits into that history. Once you’ve dealt with that, you’ll learn about Tomcat’s architecture and its modular approach to configuration.

Understanding the Web Today

The Web isn’t solely made up of static pages that show the same document to every user; many pages contain content generated independently for each viewer. Although static files still have their place, many useful and necessary Web sites would be unable to function without dynamic content. For example, Amazon.com is one of the major success stories of the Web and is often the reason people go online for the first time. Without dynamic content, such as shopping baskets, personal recommendations, and personalized welcome messages, Amazon.com wouldn’t be the success it has been, and many people wouldn’t be online.

The Common Gateway Interface (CGI) was the original dynamic content mechanism that executed programs on a Web server and allowed Webmasters to customize their pages, which was extremely popular in the early days of the Web. The CGI model is as follows:

  1. The browser sends a request to the server just as it would for a Hypertext Markup Language (HTML) page.

  2. The server maps the requested resource to an external program.

  3. The server runs the external program and passes it the original Hypertext Transfer Protocol (HTTP) request.

  4. The external program executes and sends its results to the server.

  5. The server passes the program’s output to the browser as an HTTP response.

CGI has been implemented in many programming languages, but Perl was, and still is, the most popular language for developing CGI applications. However, CGI isn’t very efficient; each time the server receives a request, it must start a new copy of the external program.

So, if only a small number of users request a CGI program simultaneously, it’s not too big of a problem. However, it’s a different story if hundreds or thousands of users request the resource simultaneously. Every copy of the program requires a share of the server’s processing power, which is rapidly used up as requests pile up. The situation is made even worse with CGI programs that are written in interpreted languages such as Perl, which result in the launch of large runtime interpreters with each request.

Looking Beyond CGI

Many alternative solutions to CGI have been developed since the Web began. The more successful of these provide an environment that exists inside an existing server or even functions as a server on its own.

Many CGI replacements have been built on top of the Apache server (http://www.apache.org) because of Apache’s popular modular application programming interface (API). Developers can use the API to extend Apache’s functionality with persistent programs, and thus it’s ideal for creating programs that create dynamic content. Apache loads modules into its memory when it starts and passes the appropriate HTTP requests to them as appropriate. It then passes the HTTP responses to the browser once the modules have processed the requests. Because the modules are already in the server’s memory, the cost of loading an interpreter is removed and scripts can execute faster.

Although few developers actually create modules themselves (they’re relatively difficult to develop), many third-party modules provide a basis for applications that are much more efficient than normal CGI. The following are a few examples:

  • mod_perl: This maintains the Perl interpreter in memory, thus removing the overhead of loading a new copy of the Perl interpreter for each request. This is an incredibly popular module.

  • mod_php4: This module speeds up PHP in the same way that mod_perl speeds up Perl.

  • mod_fastcgi: This is similar to straight CGI, but it keeps programs in memory rather than terminating them when each request is finished.

Microsoft provides an interface to its Internet Information Services (IIS) Web server, called the Internet Server Application Programming Interface (ISAPI). This API doesn’t have the following that Apache’s API has because of its complexity, but it’s nevertheless a high-performance API. However, IIS is widely used, mainly because it comes as part of many versions of Windows. In Chapter 9 you’ll configure Tomcat to work with IIS so you can combine the best features of both.

Microsoft also developed the Active Server Pages (ASP) technology, which lets you embed scripts, typically VBScript, into standard HTML pages. This model has proved extremely successful and was the catalyst for Java Web technology, which I’ll discuss next.

Introducing Java on the Web

Java was initially released in the mid-1990s as a way to liven up static Web pages. It was platform independent and allowed developers to execute their programs, called applets, in the user’s browser. An incredible amount of hype surrounded applets: that they would make the Web more exciting and interactive, that they would change the way people bought computers, and that they would reduce all the various operating systems into mere platforms for Web browsers.

Applets never really caught on; in fact, other technologies, such as Macromedia Flash, became more popular ways of creating interactive Web sites. However, Java isn’t just for writing applets: you can also use it to create stand-alone platform-independent applications.

The main contribution of Java to the Web is servlets, which are another alternative technology to CGI. Just as CGI and its other alternatives aren’t stand-alone programs (because they require a Web server), servlets require a servlet container to load servlets into memory. The servlet container then receives HTTP requests from browsers and passes them to servlets that generate the response. The servlet container can also integrate with other Web servers to use their more efficient static file abilities while continuing to produce the dynamic content. You’ll find an example of this in Chapter 9 when you integrate Tomcat with Apache and IIS.

Unfortunately, although servlets are an improvement over CGI, especially with respect to performance and server load, they too have a drawback. They’re primarily suitable for processing logic. For the creation of content (that is, HTML), they’re less usable. First, hard-coding textual output, including HTML tags, in code makes the application less maintainable. This is because if text in the HTML must be changed, the servlet must be recompiled.

Second, this approach requires the HTML designer to understand enough about Java to avoid breaking the servlet. More likely, however, the programmer of the application must take the HTML from the designer and then embed it into the application: an error-prone task if ever there was one.

To solve this problem, Sun Microsystems created the JavaServer Pages (JSP) technology.

Adding to Servlets: JavaServer Pages

Although writing servlets requires knowledge of Java, a Java newbie can quickly learn some useful JSP techniques. As such, JSP represents a viable and attractive alternative to Microsoft’s ASP.

Practically speaking, JSP pages are compiled into servlets, which are then kept in memory or on the file system indefinitely, until either the memory is required or the server is restarted. This servlet is called for each request, thus making the process far more efficient than ASP, since ASP requires the server to parse and compile the document every time a user comes to the site. This means that a developer can write software whose output is easy to verify visually and that the result works like a piece of software. In fact, JSP took off mainly as a result of its suitability for creating dynamic visual content at a time when the Internet was growing in popularity.

One major practical difference between servlets and JSP pages is that servlets are provided in compiled form and JSP pages are often not (although precompilation is possible). What this means for a system administrator is that servlet files are held in the private resources section of the servlet container, and JSP files are mixed in with static HTML pages, images, and other resources in the public section of servlet container.



Pro Jakarta Tomcat 5
Pro Apache Tomcat 5/5.5 (Experts Voice in Java)
ISBN: 1590593316
EAN: 2147483647
Year: 2004
Pages: 94

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net