The Web is not a single technology, but a myriad of protocols, languages, and tools stitched together to form a single user experience. This is the first in a series of posts that describe those technologies, and particularly how they’re used on proloquor.net. Before diving in however, let’s review how we got where we are today.
In the Beginning
1968 was a banner year in U.S. history by any standard, and the world of Information Technology is no exception. That’s the year the [Defense] Advanced Research Projects Agency ([D]ARPA) began soliciting ideas for ARPANET, an experimental notion of a nationwide computer network that would link high-end computer mainframes so that they can be used by researchers throughout the country. The initial network linked 4 sites in California and Utah, but was designed so that nodes could be easily added without significant manual reconfiguration.
As the network grew from 10’s to 100’s to 1000’s of nodes, more sophisticated applications began to emerge that leveraged this connectivity. Telnet was one of the first that allows a remote user to interact with the command shell of a mainframe computer. The File Transfer Protocol (FTP) is another early application that allows users to exchange files between computers. These, along with ubiquitous Electronic Mail (E-Mail), are still very much in use today. Others like Gopher, an early document delivery system, and Usenet, a world-wide discussion bulletin board, are all be defunct these days. All these applications are built on top of the Internet Protocol (IP), version 4 of which is the backbone of the Internet today.
A New Perspective
As ARPANET evolved in the late 1980’s into the modern Internet, designers started paying more attention to these applications, rather than just the underlying technologies that carried them. While perfectly utilitarian, telnet, ftp, and email all operated under vastly different rules, making it difficult to sell the Internet as a consumer product.
Starting in 1980, Sir Tim Berners-Lee, a then contractor for the European Organization for Nuclear Research (CERN), began working on two new technologies that would form the basis of what is now known as he World Wide Web (WWW), revolutionizing the Internet and its role in society. The cornerstone of Berners-Lee’s ideas are:
- HyperText Markup Language (HTML) – The language of the World Wide Web. It allows web sites to serve up rich, multi-format content in a single but extensible structure.
- HyperText Transfer Protocol (HTTP) – The carrier of the World Wide Web. It provides the mechanism for web sites to deliver HTML-based and other content to the requesting browser.
We’ll cover these technologies in a bit more detail shortly. While there are more components to consider, one can create and distribute a lot of content with just these two.
The Web’s operation centers around the delivery of documents. The definition of a document can be fairly abstract, including audio, video, or other data. But most of the time, we think of a document as text, possibly decorated with different fonts, colors, and other typesetting. Using HTML, these documents are produced manually before any site can serve them. In other words, their content is static, until someone repeats the manual editing process.
But what if content could be created dynamically, at the very moment the browser requests it? Instead of Amazon creating a unique document for every one of its 270,000,000+ products for example, wouldn’t it be more efficient if every click caused a program to run that:
- looked up the relevant information in a database, then
- created the document with a standard format using the retrieved data, and
- handed it to the server to be presented to the browser
That’s what happens in modern enterprise-class Web applications.
Client-side or Server-side?
But where does that program run? There are two basic choices, each with their pros and cons depending on the work to be done.
- Server-side – This is the computer that runs the Web server. The advantage of running programs here is that the data used to generate the documents lives here, but a heavily used services requires massive infrastructure at the hosting server. Because server side technologies must integrate only with the server and not the millions of clients using it, the technology choices are nearly endless. Ruby, PHP, Python, ASP.NET, and CGI are all popular choices, but we’ll focus on Java Servlets and Java Server Pages (JSPs) as they are used on proloquor.net.
This post covered a lot of ground, so we’ll need to return to many of these technologies for more detail, particularly those used on proloquor.net.