Creating Your First JSP Page - Exploring a Brief History of Java and the Web
(Page 5 of 7 )
For the curious, the following sections summarize the history of the Web and the role that Java plays in it. Feel free to skip to the next chapter if you’d rather just get down to business.
The Web Back in the 1960s, as computers began their prolific distribution, the U.S. military constructed a computer network called ARPANET, which was designed to link key computers across the nation. The network was based on a peer-to-peer model; that is, instead of a single machine acting as the server, all computers on the network passed along messages. The idea was that this made the network resistant to disruption caused by a nuclear attack on the United States knocking out key computers.
Fortunately, this resistance to nuclear attack was never tested, but the network’s well-designed and robust architecture ensured its survival. As well as the military, the academic community was connected to it, and soon the network became primarily used for scientific research and collaboration. It was renamed the Internet because it linked up many local-area and wide-area networks.
In the early days of the Internet, few people outside the scientific disciplines were even aware that it existed, and fewer still had access to it. Ease of use wasn’t a priority, and the first generation of Internet users worked with command-line utilities such as Telnet, File Transfer Protocol (FTP), and Gopher to get anything useful done.
The seeds of a more user-friendly Internet, and hence one that was open for more widespread use, were sown in 1989 when Tim Berners-Lee, a computer scientist working for the European Organization for Nuclear Research (CERN), came up with the concept of the World Wide Web. Berners-Lee envisaged an interactive hypertext system on top of the existing Internet to facilitate communication in the world community of physicists. Hypertext refers to any system where certain words function as links to other documents or sections of a document; Macintosh users might remember the classic HyperCard, which was the first hypertext application used by many.
The Web began to gain momentum and by 1993 comprised around 50 Web servers. At this time an event occurred that would light the fuse of the Internet skyrocket: the National Center for Supercomputing Applications (NCSA) at the University of Illinois released the first version of the Mosaic Web browser for Unix, PC, and Macintosh systems. Prior to Mosaic, the only fully featured browser available was on the NeXT platform.
With the Mosaic foundation in place, 1994 saw the emergence of the Web into popular culture, and members of the general public began to explore the Internet for themselves. In the same year, a small Silicon Valley company, which would eventually become Netscape, was founded by some of the same folks who had created Mosaic. The so-called New Economy consisting of e-land grabs and irrationally overvalued companies was just around the corner. And the rest is, well, history.
| NOTE For more information about the history of the Internet, see http:// www.isoc.org/internet/history/.For more information about the history of the Web, see http://www.w3.org/History.html. |
How the Web Works There can be confusion as to what exactly the Internet is and how it’s different from the Web. The Internet is the physical computer network that links computers around the world. The Web, on the other hand, is a service that sits on the foundation of the Internet. The Web allows computers to communicate with each other. The Web is one of many different services that utilize the Internet; others include e-mail, streaming video, and multiplayer games.
As a service, the Web defines how two parties—a Web client (generally a Web browser) and a Web server—use the Internet to communicate. When you visit a Web site, you create a relationship between your browser and the Web site server. In this relationship, the browser and server communicate through the exchange of messages. First, your browser sends a message to the Web server requesting the particular Web page you’ve asked for, and the Web server responds with an appropriate message containing the HTML for the page if it’s available. For each additional page that’s viewed, the Web browser sends additional requests to the Web server, which likewise responds with the appropriate messages.
This type of relationship is called a request-response model. The requests and responses travel over the Web using HTTP. Just as a diplomatic protocol dictates how two governmental parties should conduct discussions, HTTP defines what messages should be exchanged when two computers communicate remotely. The request the client sends to the server is the HTTP request, and the response sent by the server back to the client is the HTTP response.
The Responsive Web
The Web today doesn’t consist solely of static pages that return an identical document to every user, and many pages contain content that’s generated independently for each viewer. Although static files still have their place, the most useful and appealing pages are dynamically created in response to the users’ preferences.
The Common Gateway Interface (CGI) provided the original mechanism by which Web users could actually execute programs on Web servers, not just request HTML pages. Under the CGI model, the following happens:
- The Web browser sends a request just as it would for an HTML page.
- The Web server recognizes that the requested resource corresponds to an external program.
- The Web server executes the external program, passing it the HTTP request that it received from the browser.
- The external program does its work and sends its results to the server.
- The Web server passes the program’s output back to the browser as an HTTP response.
CGI was enormously popular in the early days of the Web as a means of generating Web pages on the fly. Almost every programming language imaginable has been used to implement some kind of CGI-based solution, but Perl is perhaps the most popular language for CGI development.
However, as the Web grew in popularity and the traffic demands placed on Web sites increased, CGI wasn’t efficient enough to keep up. This is because, with CGI, each time a request is received, the Web server must start running a new copy of the external program.
If only a handful of users request a CGI program simultaneously, this doesn’t present too much of a problem, but it’s a different story if hundreds or thousands of users request the resource at the same time. Each copy of the program requires its own share of processing time and memory, and the server’s resources are rapidly used up. The situation is even bleaker when CGI programs are written in interpreted languages such as Perl, which result in the launch of large run-time interpreters with each request.
Alternatives to CGI
Over the years, many alternative solutions to CGI have surfaced. The more successful of these provide an environment that exists inside an existing Web server or even functions as a Web server on its own.
Many such CGI replacements have been built on top of the popular open-source Apache Web server (http://www.apache.org). This is because of Apache’s popular modular application programming interface (API), which allows developers to extend Apache’s functionality with persistent programs. The modules are loaded in memory when Apache starts, and Apache passes the appropriate HTTP requests to these in-memory modules and passes the HTTP responses back out to the browser. This means that the cost of loading an interpreter into memory is removed, and scripts can begin executing faster.
Although few developers actually create modules themselves (because they’re relatively difficult to develop), many third-party modules exist that provide a basis for developers to create applications that are much more efficient than normal CGI. These are a few examples:
- mod_perl: This maintains the Perl interpreter in memory, thus freeing Perl scripts from the overhead of loading a new copy of the Perl interpreter for each request. This module is very popular.
- mod_php4: This module speeds up code in the popular PHP language in the same way that mod_perl speeds up Perl.
mod_fastcgi: This is similar to plain-vanilla CGI, but it enables programs to stay resident in memory rather than terminating when each request is completed.
NOTE Although the Apache name originally referred only to the Apache Web server, a legion of open-source programs have been developed under the auspices of the Apache Project, including the Tomcat server, which you’re using in this book.
One CGI replacement technology you may well have already heard of is Microsoft’s Active Server Pages (ASP). Initially, Microsoft attempted to create an interface to its Internet Information Services (IIS) Web server, called Internet Server Application Programming Interface (ISAPI). This didn’t spawn the large following that Apache’s equivalent API did, but it’s nevertheless a high-performance API that many businesses use, including eBay (you can visit
http://www.netcraft.com to see which Web server any site on the Internet is using). However, because of its complexity, ISAPI is rarely suited to the beginning developer. Microsoft’s IIS Web server itself, however, is widely used, largely because it comes free with many versions of Windows. Incidentally, you can configure IIS to work with Tomcat.
Microsoft followed up ISAPI with its ASP technology, which lets you embed programming code, typically VBScript, into standard HTML pages. This model has proved extremely successful and was the catalyst driving the development of Java Web technology, which we’ll discuss shortly.
Next: Java and the Web >>
More Java Articles
More By Apress Publishing
|
 This article is excerpted from Beginning JSP 2: From Novice to Professional, by Peter den Haan et al (Apress, 2004; ISBN: 1590593391). Check it out at your favorite bookstore. Buy this book now.
|
|
/ 39 
