wyant@apollo.uucp (Geoffrey Wyant) (03/26/88)
There seemed to be general interest in NCS after my posting
on how it handled object location, so I thought I would
give a brief overview.
NCS (Network Computing System) is a portable implementation of NCA (Network
Computing Architecture). NCA is an object-oriented framework for building
distributed applications. Its design is based on the concepts of object,
object type, operation, and interface. Objects are manipulated only
through well-defined operations. The object type defines the semantics
of the operations. Operations which are behaviorly related are gathered
into interfaces. The intent of the architecture is to enable application
designers to think in terms of invoking operations on remote objects
in a location independent manner, rather than as calls to a particular
machine. Objects, types, and interfaces are all named uniformly by
Universal Unique Identifiers (UUIDS). A uuid is similiar to a capability,
except it doesn't carry access rights. The architecture is more suited
to "heavyweight" objects (files, processes, devices, array processors,
databases, etc.) than to "lightweight" objects (i.e. typical programming
language datatypes).
NCA consists of four components: an interface description language (NIDL)
for describing interfaces exported by type managers; an at-most-once
RPC protocol; a "Global Location Broker", for locating objects; and a
network data representation which describes the format of data on the
wire. The NIDL language enforces the object oriented view in the following
manner. All operations in an interface are expected to have 'handle'
as their first parameter. This handle denotes the object on which the
operation is being invoked. It is similiar to the 'self' parameter of
Smalltalk, or the 'this' parameter of C++. The architecture defines
a primitive type, called (unimaginitively) handle_t which is used as
the type of the handle parameter. You could imagine the handle as just
being a socket address, but in the NCS implementation it actually has a
bit more structure. In any case, handle_t is opaque to clients. The
architecture also provides for user-definable handle types as well.
The abstract overview of how a client invokes operations on a an
object as follows. Objects are managed by a type manager, which registers
its managed objects with the Global Location Broker (GLB), along with
the associated types and exported interfaces. A client program that
wishes to invoke operations on a remote object calls the GLB passing
it the object's UUID. The GLB returns a list of exported interfaces and
the network address for that interface. This network address can be
turned into a handle and used in conjunction with the RPC protocol to
invoke operations on the remote object. The concrete way this is done
in NCS is by calling an runtime routine that converts a socket
address into one of these primitive handles.
NCS is an implementation of the above architecture. It provides an RPC
runtime based on datagrams. The Berkley socket abstraction is used for
transport independence. The runtime is designed to use lightweight
processes if the host OS provides them. The interface compiler takes
interfaces described by NIDL input and generates client and server side
stubs which interface to the RPC runtime. The compiler is fairly
sophisticated in that it does as much of the marshalling and unmarshalling
(and data conversion) of parameters inline as possible. The compiler
can also hide much of the work of locating and binding to objects from
clients. The GLB is implemented as a loosely consistent replicated
database. By loosely consistent, I mean that updates are not immediately
propogated to all replicas, but the replicas will become consistent over
time in the absence of conflicting updates.
The architecture (NCA) has been put into the public domain. NCS is available
from Apollo in either source form or binary form for a variety of machines.
Universities can get source to everything for cost of media. I don't want
to turn this into a commercial, so if you want more information on
availability, feel free to drop me mail. I'll also be glad to send you
a copy of some our papers and an architecture spec if you are interested.
Cheers,
Geoff
--
UUCP: ...{yale,mit-eddie}!apollo!wyant