Sanjay R Radia

An overview of the Spring system

Spring is a highly modular, distributed, object-oriented operating system. This paper describes the goals of the Spring system and provides overviews of the Spring object model, the security model, and the naming architecture. Implementation details of the Spring microkernel, virtual memory system, file system, and UNIX emulation are supplied.<<ETX>>

The per-process view of naming and remote execution

The per-process approach lets each process create its own private view of naming, instead of relying solely on the systems naming tree as in the per-system approach. The result is a flexible naming environment for distributed systems, especially for remote execution.<<ETX>>

Security in the Spring name service

Spring provides a uniform name service for an open ended collection of object types-in principle, any object, of any type, can be bound to any name. The name service implements authentication and access control to protect itself, and provides these same functions in an integrated way for the convenience of clients and the object managers that implement the various objects in the system. An object manager can delegate these functions to the name service, or implement its own policies. The name service is implemented as a collection of name servers which are generally autonomous and separate from each other and also from object managers. The architecture allows trusted and untrusted name servers and object managers to participate in providing naming and in publishing objects. Authentication is done at appropriate times to establish trust. These trust relationships are encoded in capability-like authenticated objects which are reused to avoid authentication complexity and overhead after trust is established.<<ETX>>

Coherence in naming in distributed computing environments

Many different kinds of names (identifiers) are used in computer systems. Names are resolved (interpreted) in a context. A context is a function that maps names to entities. Multiple contexts allow the flexibility of giving different meanings to a name in different parts of the system; however, there are situations where it is desirable for the meaning of a name to be the same in different parts. This property is called coherence in naming. Since the meaning of a name depends on the context selected, the analysis of coherence is based on the notion of closure mechanisms-implicit rules that select a context for resolving names. The authors define coherence and show how it is affected by various closure mechanisms. Then they present several approaches for dealing with the lack of coherence. Incoherence arises from selecting an incorrect context, and consequently, closure mechanisms are involved in the solutions.<<ETX>>

Autonomy, local autonomy, and coherence in naming in distributed computer systems

In a distributed system, different subsystems (for example, a machine or a network) may have the need and capability for quite different degrees of autonomy; for example, a mobile machine with a large disk that occasionally connects to a distributed system would be configured to be more autonomous than a disk-less workstation that is permanently connected. We wish to understand the issues and tradeoffs in controlling the degree of autonomy.An important factor limiting autonomy in a distributed system is dependence on remote objects. However, making these objects locally available may not be sufficient. The autonomy of a subsystem with respect to its local objects may be constrained by the need for coherence (or cooperation) in the system. Coherence can occur in different forms and at different levels[8]; for example, a common protocol may be used to allow subsystems to communicate, operations may have the same semantics for local and remote objects (this is often called network transparency), global names may be used to allow names to be freely exchanged and to make sharing easier, etc. The potential conflict between autonomy and coherence was observed early in the development of distributed systems [2,8].The aim is to find mechanisms that support coherence within a system, but do not constrain the autonomous functioning of a subsystem with respect to its local objects. This would allow a choice between autonomy and dependence so that different subsystems can be configured with different degrees of dependence on remote objects and hence different degrees of autonomy.We investigate two areas. First, we take a closer look at what it means for a subsystem to be autonomous, for this has been largely neglected in the literature. We aim for a broad definition which is consistent with the general meaning of the term autonomy. Second, we investigate the conflict between autonomy and coherence in naming, and outline a solution for naming communication end-points that supports coherence without limiting the autonomy of machines and networks.