ernet [76] systems had been in use at Xerox PARC for some
time, the industrial Ethernet standard had only recently been
completed and the first products were still in development.
To the extent that network applications existed at all, out
side of PARC, they were fairly primitive point to point ap
plications such as FTP and email. UNIX did not yet support
a socket abstraction, and programming networked applica
tions required explicit message passing, which was difficult
and errorprone.
Eden was a research project proposed by a group of faculty
at the University of Washington (Guy Almes, Mike Fischer,
Helmut Golde, Ed Lazowska, and Jerre Noe). The project
received one of the first grants from what seemed even at the
time to be a very farsighted program at the National Sci
ence Foundation called Coordinated Experimental Research
(CER), a program that sought to build significant expertise
and infrastructure at a number of computer science depart
mentsaroundtheUnitedStates.ThestatedgoalofEdenwas
tosupport“integrateddistributedcomputing.”Whilenobody
had distributed systems at the time, it was clear that some
day in the future such systems would be commonplace, and
that programming them using existing paradigms would be
extremely difficult. The key insight of the Eden team was
to use objects—a computational model and technology that
was still controversial in both the operating system and the
programming language worlds at that time.
EdenwasitselfadescendantofHydra[108],thefatherofall
object based operating systems, developed by Bill Wulf and
his team at Carnegie Mellon in the early 1970s. Guy Almes,
a junior faculty member at UW, had written his thesis on
Hydra at CMU [4], and brought those ideas to Washington.
The idea behind an object based distributed system was that
every resource in the network—a file, a mail message, a
printer, a compiler, a disk—would be an object. At the time
we looked on an object as nothing more than some data
bound together with program code that operated on that data
to achieve a specific goal, such as printing a file object, or
sending a mail message object, or running a compiler object
on a file object. The code was partitioned into what are now
referred to as methods for printing, sending, running, etc.,
but at the time we just thought of the code as a bunch of
proceduresthatimplementedoperationsontheobject’sdata.
The great thing about objects was that client programs could
use an object simply by invoking an operation in that object
and supplying appropriate parameters; they didn’t have to
concern themselves with how the object was implemented.
Thus, objects were a physical realization of Parnas’ princi
ple of information hiding [85]. The key insight behind dis
tributed object based computing was that the same principle
appliedtothelocationoftheobject:aclientcoulduseanob
ject without worrying about where that object was actually
located in the network, and two conceptually similar objects
(for example, two files) that were located in disparate places
might have completely different implementations. The Eden
system would take care of finding the object, managing the
remote communication, and invoking the right code, all in
visibly to the programmer.
Several other research projects also explored the distributed
object notion, notably Argus at MIT [71] and Clouds at
Georgia Tech [2]. Argus, as a language design, was essen
tially complete before the Emerald project started. Thus, Ar
gus was contemporary with Eden rather than with Emerald,
and indeed shared with Eden the idea that there were two
kinds of objects—“large” objects that were remotely acces
sible (and, in the case of Argus, transactional), and small
local objects (essentially, CLU objects). Some of the Clouds
ideas moved to Apollo Computer with the principals, and
appeared in the Apollo Domain system; there were several
visits between Apollo and Eden personnel.
This distributed object model is now the dominant paradigm
for Internet programming, whether it is Java/J2EE, Mi
crosoft .NET, CORBA, SOAP, or whatever. We take it for
granted. So it is hard to convey how controversial the dis
tributed object idea was in the early 1980s. People thought
that distributed objects would never work, would be way too
slow, and were just dumb. Objects had not yet been accepted
even in the non distributed world: Simula was not main
stream,C++wouldnotbeinventedforsomeyears[100],and
Java wouldn’t appear for a decade and a half. Smalltalk had
just been released by PARC and was gathering a following
amongst computing “hippies,” but unless one had a Dorado,
it was not fast enough for “real” applications. Alan Born
ing, our colleague at Washington, had distributed copies of
the influential 1981 Smalltalk issue of Byte magazine, but in
our opinion, the focus of Smalltalk was on flexibility to the
detrimentofperformance.Smalltalk,althoughanimpressive
achievement, contributed to the view that poor performance
was inherent in object oriented languages.
Emerald was a response to what we had learned from our
early experience with Eden and from other distributed ob
ject systems of that time. In fact, it was a follow on to Eden
before Eden itself was finished. Before describing that ex
perience and its implications, we discuss the team and their
backgrounds and the beginnings of the project.
1.2 The People and the Beginning of Emerald
The Emerald group included four people:
1
• Andrew Black joined UW and the Eden project as a
Research Assistant Professor in November 1981. He had
a background in language design from his D.Phil. at
Oxford (under C.A.R. Hoare), including previous work
on concurrency and exception handling. Andrew brought
1
Another Ph.D. student, Carl Binding, participated in some of the initial
discussions with a view to being responsible for a reasonable GUI for
Emerald; he decided to do a different Ph.D., so the GUI of the Emerald
system remained quite primitive.
time, the industrial Ethernet standard had only recently been
completed and the first products were still in development.
To the extent that network applications existed at all, out
side of PARC, they were fairly primitive point to point ap
plications such as FTP and email. UNIX did not yet support
a socket abstraction, and programming networked applica
tions required explicit message passing, which was difficult
and errorprone.
Eden was a research project proposed by a group of faculty
at the University of Washington (Guy Almes, Mike Fischer,
Helmut Golde, Ed Lazowska, and Jerre Noe). The project
received one of the first grants from what seemed even at the
time to be a very farsighted program at the National Sci
ence Foundation called Coordinated Experimental Research
(CER), a program that sought to build significant expertise
and infrastructure at a number of computer science depart
mentsaroundtheUnitedStates.ThestatedgoalofEdenwas
tosupport“integrateddistributedcomputing.”Whilenobody
had distributed systems at the time, it was clear that some
day in the future such systems would be commonplace, and
that programming them using existing paradigms would be
extremely difficult. The key insight of the Eden team was
to use objects—a computational model and technology that
was still controversial in both the operating system and the
programming language worlds at that time.
EdenwasitselfadescendantofHydra[108],thefatherofall
object based operating systems, developed by Bill Wulf and
his team at Carnegie Mellon in the early 1970s. Guy Almes,
a junior faculty member at UW, had written his thesis on
Hydra at CMU [4], and brought those ideas to Washington.
The idea behind an object based distributed system was that
every resource in the network—a file, a mail message, a
printer, a compiler, a disk—would be an object. At the time
we looked on an object as nothing more than some data
bound together with program code that operated on that data
to achieve a specific goal, such as printing a file object, or
sending a mail message object, or running a compiler object
on a file object. The code was partitioned into what are now
referred to as methods for printing, sending, running, etc.,
but at the time we just thought of the code as a bunch of
proceduresthatimplementedoperationsontheobject’sdata.
The great thing about objects was that client programs could
use an object simply by invoking an operation in that object
and supplying appropriate parameters; they didn’t have to
concern themselves with how the object was implemented.
Thus, objects were a physical realization of Parnas’ princi
ple of information hiding [85]. The key insight behind dis
tributed object based computing was that the same principle
appliedtothelocationoftheobject:aclientcoulduseanob
ject without worrying about where that object was actually
located in the network, and two conceptually similar objects
(for example, two files) that were located in disparate places
might have completely different implementations. The Eden
system would take care of finding the object, managing the
remote communication, and invoking the right code, all in
visibly to the programmer.
Several other research projects also explored the distributed
object notion, notably Argus at MIT [71] and Clouds at
Georgia Tech [2]. Argus, as a language design, was essen
tially complete before the Emerald project started. Thus, Ar
gus was contemporary with Eden rather than with Emerald,
and indeed shared with Eden the idea that there were two
kinds of objects—“large” objects that were remotely acces
sible (and, in the case of Argus, transactional), and small
local objects (essentially, CLU objects). Some of the Clouds
ideas moved to Apollo Computer with the principals, and
appeared in the Apollo Domain system; there were several
visits between Apollo and Eden personnel.
This distributed object model is now the dominant paradigm
for Internet programming, whether it is Java/J2EE, Mi
crosoft .NET, CORBA, SOAP, or whatever. We take it for
granted. So it is hard to convey how controversial the dis
tributed object idea was in the early 1980s. People thought
that distributed objects would never work, would be way too
slow, and were just dumb. Objects had not yet been accepted
even in the non distributed world: Simula was not main
stream,C++wouldnotbeinventedforsomeyears[100],and
Java wouldn’t appear for a decade and a half. Smalltalk had
just been released by PARC and was gathering a following
amongst computing “hippies,” but unless one had a Dorado,
it was not fast enough for “real” applications. Alan Born
ing, our colleague at Washington, had distributed copies of
the influential 1981 Smalltalk issue of Byte magazine, but in
our opinion, the focus of Smalltalk was on flexibility to the
detrimentofperformance.Smalltalk,althoughanimpressive
achievement, contributed to the view that poor performance
was inherent in object oriented languages.
Emerald was a response to what we had learned from our
early experience with Eden and from other distributed ob
ject systems of that time. In fact, it was a follow on to Eden
before Eden itself was finished. Before describing that ex
perience and its implications, we discuss the team and their
backgrounds and the beginnings of the project.
1.2 The People and the Beginning of Emerald
The Emerald group included four people:
1
• Andrew Black joined UW and the Eden project as a
Research Assistant Professor in November 1981. He had
a background in language design from his D.Phil. at
Oxford (under C.A.R. Hoare), including previous work
on concurrency and exception handling. Andrew brought
1
Another Ph.D. student, Carl Binding, participated in some of the initial
discussions with a view to being responsible for a reasonable GUI for
Emerald; he decided to do a different Ph.D., so the GUI of the Emerald
system remained quite primitive.