FTP and Telnet -- Distributed computing is somewhat newer, but not much. By about 1972, the ARPA-net was just coming up, but computer terminal access via phone lines had been around for some time. The first distributed operating systems, however, were developed for parallel machines rather than networks of computers as a means of providing resource sharing securely and fairly. The resources were CPUs and disks, mainly, and the goal was to implement abstractions that allowed multiple simultaneously executing processes (possibly under the control of different users) to share the resources of the machine in a controlled manner.
Ethernet -- In the early eighties, ethernet made desktop and enterprise-wide networking viable for the masses. Before that time, distributed systems consisted of either special-purpose architectures (parallel machines or fault-tolerant machines like those built by the Tandem corporation) or large centers inter-linked by expensive leased phone lines. The ARPA-net was available to a few research Universities and government laboratories, but access was far from ubiquitous. With ethernet came the possibility of linking many more small and medium sized computers together. Companies like Sun Microsystems capitalized, and did so by providing distributed sharing services such as the Network File System (NFS).
Distributed O.S. -- Until the emergence of "The Internet" (which is really a misnomer for the invention of HTML and the web browser), distributed file access and remote terminal access were, by far, the most prevalent applications of distributed computing technology. Systems such as MACH (from CMU), Amoeba (from the Free University in Amsterdam), and Locus (from UCLA) had been developed to try and provide higher-level, more powerful capabilities, but they were largely unsuccessful in networked settings.
The Web -- The Web (circa 1993) changed the file sharing functionality provided by systems like FTP and NFS to include a visualization requirement. The interface that XMosaic provided was certainly different than the standard FTP client, but the functionality was more or less the same: fetch the data from a specified location and display it. Clearly, the Web increased the demand for distributed systems, but from a architectural standpoint, the requirements it introduced were largely visualization oriented. That is, the Web (at first) made file sharing a great deal more popular, but provided little extra functionality over what anonymous FTP had provided for almost 15 years.
Ubiquitous Connectivity -- By 1995, however, cheap, fast networking (developed in response to the demand for faster, more complex Web page delivery) had become widely available. Cluster systems, based on local-area network technology, became feasible high-performance compute platforms. Transcontinental network performance, available to ISPs and research networks, enabled high bandwidth rates from coast-to-coast. Finally, routes between enterprise-specific networks were established allowing pretty much any computer with a network connection to communicate with any other computer similarly equipped.
Code as Cpmpression and Encryption of Content -- This ubiquitous connectivity had two stimulatory effects in the distributed systems community. The first was to motivate the development of more complicated forms of content delivery for the Web. Rather than shipping web pages, one at a time, a program written in Java capable of producing all of the pages (i.e. to render an animation sequence) could be shipped to the visualization point and executed. CGI and servlet technology allowed complex content to flow in the other direction, from the end-user to the persistent service. The main goal of these innovations, however, was to overcome limitations in network latency, and in some cases bandwidth, imposed by the intervening networks. Interactive applications, for example, are more pleasing to use if they are responsive. By running as a Java applet in the user's browser, the application need not incur network delay between user input and application response.
Much of the work in Internet Computing and Web caching has been focused on content delivery (both simple and complex) and how it can be made an "appliance" in everyday life. As a result of this work, content will become more complex and access more ubiquitous, but the focus will remain the same: content delivery.
Global Computing -- A second line of research spurred by the increased availability of high-quality networking focused on the aggregate computing capability that, in principle, full-scale connectivity provides. Originally termed "heterogeneous computing" and then renamed "metacomputing," it is this area of research that, today, is called "Computational Grid" computing.
The Computational Grid -- The term Computational Grid, itself, comes from a book published in 1998 with the title "The Grid: Blueprint for a New Computing Infrastructure" by Ian Foster and Carl Kesselman. In it researchers outlined their thinking about how to use the new and certain-to-be-permanent networking infrastructure to support computing in general -- in addition to content delivery. To be successful, they reasoned, the new distributed computing infrastructure had to support applications in the same way that the power utilities support the use of household appliances. The metaphor, then, is for computers to act as generators of computational "power", for applications to become computational "appliances", and the for the software infrastructure to act as the utility responsible for managing the interaction between them.
Foster and Kesselman, in their landmark text, lay out some characteristics that they believe differentiate Computational Grids from previous parallel and/or distributed computing systems. They say that the Grid must be
Middleware -- Realizing this vision does require some new capabilities, some of which have yet to be developed. The first issue is performance. Clearly, if each application ran only on the computer owned by its user, there would be no need for a Grid. Running a sequential application at a different target site than the one which is managing the storage on which it is stored is clearly useful, but distributed file systems and the Web can both provide this kind of functionality. The Grid, then, must support applications consisting of multiple components executing concurrently at different sites in a coordinated way. It differs from parallel computing, though, since the performance of each resource may be different, and can vary over time. In addition, it is unlikely that users will be willing to completely subjugate the control of their computers to any single organization. The Grid, then, cannot rely on the ability to supplant the system software on each system, nor can it require that resource owners relinquish ultimate control over their own resources. As a result Grid implementations are often postulated as "middleware" which is an ill-defined term that is usually taken to mean "software that does not run in the kernel."
Quantitative Characteristics of Computational Grids -- Computational Grid computing, then, shares many of the same problems with both parallel an distributed computing, but there are some differentiating characteristics, and these characteristics are quantifiable (in my opinion). A Computational Grid is