Evals for Grapevine and Emerald (wine anybody???)

Yod (h13nguye@ieng9.ucsd.edu)
Thu, 27 Apr 2000 01:18:35 -0700 (PDT)

Henry H. Nguyen
BS Computer Engineer
ME Computer Engineer
(858) 587 - 7046
Title: Fine-Grained Mobility in the Emerald System

This paper talks about a system that support object mobility in an
attempt to increase performance of the system. Emerald, which is
the focus of this paper, is an object-based language and system
designed for the construction of distributed programs. Objects are
classified into two categories in this system. One has a process,
while the other is a data only object. The advantages of
process migration, according to the paper, are: load sharing,
communications performance, availability, reconfiguration,
utilizing special capabilities, data movement, invocation performance,
and garbage collection.

The overall structure of this system is in some ways bounded by its
design principles. This system is not intended to run in large,
long-haul networks to maintain adequate performance because of the
system migration of objects from node to node. And because processes
migrate from node to node, these nodes are homogeneous in the sense
that they all run the same instruction set and that they are trusted.

Though the paper classified Emerald to have two distict objects. The
programmers of the system use a single object definition mechanism with
a single semantics for defining all objects. The Emerald compiler is
the one that analyzes the needs of each object and generates an
appropriate implementation.

Each Emerald object has four components: Name, data, set of operations,
and an optional process.

The mobility of an object in Emerald is provided by a small set of
language primities. An Emerald object can: Locate an object, Move an
object to another node, Fix an object at a particular node, Unfix an
object to make it mobile, and Refix an object.

After describing, in details, the way Emerald implemented object mobility,
the paper provides tables which is used to compare the performance of
the system to the performance of systems without mobility. From the
look of it, especially table IV - The Mail System Traffic, systems that
implement object mobility provide better performance than those that
do not.
Title: Experience with Grapevine: The Growth of a Distributed System

The focus of this paper is on the topic of distributed system. The
system that was the mentioned throughout the paper on this topic is
Grapevine, which was used by Xerox as the basis for the 8000 NS
product message system and clearinghouse. According to the author,
Grapevine is a distributed, replicated system that provides message
delivery, naming, authentication, resource location, and access
control services in an internet of computers.

The overview structure of the system is a collection of Ethernet
local networks, gateways, and long distance links that interconnects
personal workstation computers and shared server computers. The
server computers connect workstation computers together by addressing
protocols assigned to the workstations. The service provided by
Grapevine is message service and registration service. The message
service, running on the message server, accepts mesages from clients,
buffers to the inboxes on the server until recipient requests them.
The registration service provides naming, authentication, access
control and resource location functions to clients.

Because the primary clients of Grapevine are various mail system
interface programs, the design of the system reflects careful
attention to the scalability of the system to provide services
for the growing number of users. But several design aspects of
Grapevine continue to have problem with scalability such as longer
processing period for larger distribution lists, and mixed delay time
in message delivery cause by the design that only consider the shortest
path and not the bandwidth, reliability or congestion of those links.

Although many of the problems have been fixed, others mentioned have
not been carried out. The reluctance to fix these problems, according
to the author, is partly due to the potential disruption that introduced
bugs that would have on the large user community that depends on Grapevine
to get its work done. Many changes that would impove the system were
not added to the system, but were leaved on the hands of the implementors
of the product system.