The smell of `object-orientedness' that the use of classes in AIL creates matches nicely with Amoeba's object-oriented approach to RPC. In Amoeba, almost all operating system entities (files, directories, processes, devices etc.) are implemented as objects. Objects are managed by services and represented by capabilities. A capability gives its holder access to the object it represents. Capabilities are protected cryptographically against forgery and can thus be kept in user space. A capability is a 128-bit binary string, subdivided as follows:
48 24 8 48 Bits +----------------+------------+--------+---------------+ | Service | Object | Perm. | Check | | port | number | bits | word | +----------------+------------+--------+---------------+
The service port is used by the RPC implementation in the Amoeba kernel to locate a server implementing the service that manages the object. In many cases there is a one-to-one correspondence between servers and services (each service is implemented by exactly one server process), but some services are replicated. For instance, Amoeba's directory service, which is crucial for gaining access to most other services, is implemented by two servers that listen on the same port and know about exactly the same objects.
The object number in the capability is used by the server receiving the request for identifying the object to which the operation applies. The permission bits specify which operations the holder of the capability may apply. The last part of a capability is a 48-bit long `check word', which is used to prevent forgery. The check word is computed by the server based upon the permission bits and a random key per object that it keeps secret. If you change the permission bits you must compute the proper check word or else the server will refuse the capability. Due to the size of the check word and the nature of the cryptographic `one-way function' used to compute it, inverting this function is impractical, so forging capabilities is impossible.3
A working Amoeba system is a collection of diverse servers, managing files, directories, processes, devices etc. While most servers have their own interface, there are some requests that make sense for some or all object types. For instance, the std_info() request, which returns a short descriptive string, applies to all object types. Likewise, std_destroy() applies to files, directories and processes, but not to devices.
Similarly, different file server implementations may want to offer the same interface for operations like read() and write() to their clients. AIL's grouping of requests into classes is ideally suited to describe this kind of interface sharing, and a class hierarchy results which clearly shows the similarities between server interfaces (not necessarily their implementations!).
The base class of all classes defines the std_info() request. Most server interfaces actually inherit a derived class that also defines std_destroy(). File servers inherit a class that defines the common operations on files, etc.