站内搜索: 请输入搜索关键词
当前页面: 图书首页 > JavaServer Pages, Second Edition

JavaServer Pages, Second Edition

[ directory ] Previous Section Next Section

1.1 A Brief History of the Web

A Web transaction involves two participants: the browser and the server. As originally conceived, the browser was supposed to be a very simple, lightweight program that would allow users to navigate through data. This data could consist of plain text, HTML, images, and so on, and the browser would render all the data in a way that humans could understand and interact with. Data could be interconnected, and the browser would render references between documents as an image or text that could be clicked or otherwise selected.

Over time, regrettably, rapid development, the race to add new features, and poor adherence to standards have caused browsers to lose the simplicity for which they once strived. This has resulted in a situation best summarized by Internet legend James "Kibo" Parry's description of browsers as "fragile assemblies of bugs, held together with Hello Kitty stickers."

The server is an equally complex program. The server is responsible for finding the data requested by the browser, packaging the data for transmission, and sending it back to the browser.

In the simplest kind of Web transaction, the browser asks for a single document from the server, and the server retrieves this data and sends it back, at which point the browser renders it in an appropriate way for the user. This whole process is shown in Figure 1.1.

Figure 1.1. The relationship between browser and server.

graphics/01fig01.gif

This basic activity has many variations. The data being requested by the browser may come from a user typing a URL (universal resource locater) directly, may be in response to the user's clicking a link, or may be automatic, such as an image contained within a page. In each case, the server will receive a properly formatted request for the data, no matter how the request is generated on the client.

How the server fulfills this request also has many variations. In the simplest model, the response may come from a file. Often, there is a simple relationship between URLs and such files. For example, the URL http://somesite.net/lyrics/This_Ascension/forever_shaken.txt might come from a file called C:\Webfiles\This_Ascension\forever_shaken.txt on the computer called somesite.net.

However, just as the server does not care how the request is generated, the client does not care how the response is constructed. Storing data in a file is perfectly adequate for information that never changes, such as the lyrics to a song, or that doesn't change very often, such as a band's tour schedule. When a new date is added to such a schedule, someone can simply edit the file by using a text editor, such as emacs, vi, or notepad, or a full HTML editor, such as Dreamweaver.

However, the file-based model does not work for information that changes very rapidly or that requires input from the user. Following are a few of the ways in which a site might need to take input from a user.

  • Many Web sites are dedicated to getting stock quotes, and these sites are used by uncountable numbers of people. If Web servers could do no more than send files around, every site would need to have a separate file for every single stock in existence. The result would be a huge set of files, and it would be difficult, if not impossible, to keep them all updated.

  • Although many e-commerce companies have gone out of business, e-commerce itself is thriving, and the electronic shopping cart is now commonplace. This activity would also be completely impossible without the ability to run programs on the server. A site could still put its catalog online as a collection of files, but it takes a program to keep track of what items have been ordered, as well as to connect with the shipping and inventory systems to send the merchandise to the user.

  • Now that the Web is so big, the only way to find a particular piece of information is with a search engine. Some companies, notably Yahoo, build huge, well-ordered catalogs of Web sites, which could in principle be regular HTML files. For a user to enter arbitrary text in an entry box and obtain a list of files that contain that word requires a program to look through the files and find ones that match.

  • Users love Web sites where they can vote for their favorite celebrity, manage a virtual stock portfolio, or compete against other users in a match of wits and knowledge.

What all these situations have in common is that the content is now dynamic; it needs to change based on time, user input or preferences, or any of hundreds of other attributes.

    [ directory ] Previous Section Next Section