Towards a universal directory service

Directory services and name servers have been discussed and implemented for a number of distributed systems. Most have been tightly interwoven with the particular distributed systems of which they are a part: a few are more general in nature. In this paper we survey recent work in this area and discuss the advantages and disadvantages of a number of approaches. From this, we arc able to extract some fundamentai requirements of a nanaing system capable of handling a wide variety of object types in a heterogeneous environment. We outline how these requirements can be met in a universal directory service. 1. I n t r o d u c t i o n In recent years, researchers have paid a great deal of attention to data abstraction, modularization, and information hiding. The result has been a clean separation between the implementation of an object and the interface to that object, Specifically, each object is associated with a server or manager that implements the object and presents to clients an interface that defines the operations that can bc performed on the objccl. This model is particularly appropriate for distributed systems where the physical separation of objects and clients requires that the implementation be on one machine, while the interface is duplicated across multiple machines. One might think thai a coherent model of interfaces and implemcntations would also lead to common mechanisms for representing, naming, locating, and manipuialing objects. By so doing, different types of ohjccls could be mmfipulalcd with the same primitives, such that one object a file, say could be substituted for another object a terminal, say in the manner of UNIX 1 standard I/O[22]. Ironically, the server model frequently has led to implementations especially monitor-based implementations that thwart the goal by enfi)rcing overly strong typing. A file server provides a set of primitives that .is 1UNIX is a tradcmm'k of AT&T Belt Laboratories. Permission to copy without fee all or pad of this material is granted provided thai the copies are nol made or distrihuled for direct eonunercial atlv:inla/4e, the ACM copyrif4111 notice and Ihe title of the llnbliealion and its dale appear, and nolice is given thai copying is lly permission of Ihe Associalion for (~onilniling Mal:hinery, To copy otherwise, or to repuhlish; rellnires a fee and/or specific permission. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. ¢1985 ACM0-89791-167-9 /1985/0800-0250 $00.75 250 incompatible with the primitives provided by a mail server, which are in turn incompatible with the primitives for a p.dnter server. Often, each server provides its own naming system. Even where a distinct "name server" is available, it typically ks restricted to narrow domains, such as services (how to access a file server) or mailboxes (how to send mail and where to find the mailbox). In this paper we address some of these problems by developing a universal directory service that: • can span a heterogeneous internetwork of existing naming domains; • allows us to name, locate, and discover how to manipulate objects (including files, processes, mailboxes, people, and services): • provides dynamic binding and context medaanisms; and • can be integrated into most existing systems as a "valueadded" feature. On the one hand, the UDS may be thought of a superimposing a virtual directory structure on top of a multitude of pre-existing directories (name spaces). On the other hand, the UDS is designed in such a way as to admit base-level or native implementations where it provides the only directory structure. Indeed, a prototype base-level implementation has been running at Stanford for over a year [9]. We begin in Section 2 by examining some existing nanaing systems to understand how they manage objects. Section 3 discusses advantages and disadvantages of the various approaches. In Section 4 we attempt to move beyond existing systems and suggest very general principles on which a general naming service should be based. "lhc architecture for a universal directory selvice (UDS) is presented in Section 5, followed by a brief discussion of implementation issues in Section 6. Section 7 summarizes the major contributions of the UDS. A subsequent paper will present experience with the existing implementation. 2: The State of t h e A r t As noted above, a number of name services have been implemented for distributed systems. In early mes~sage-based systems rudimentary name servers were developed that mapped simple string names for services (such as ".File System") into the identifiers for the processes that unplemented those services [3, ]1, 34]. Similarly restrictive name servers include those that have been developed to map string names for hosts or mailboxes into their network addresses[5, 14, 17, 27] and the "dictionaries" of many da!abase systems [l, 13]. More recently, several efforts have extended the notion of file system directory to include access to objects other than files, typicall.y by having the directory entry contain a process or port identifier rather than a file identificr [12,19]. Other efforts have been orienied toward providing access to objects based on the "attributes" of the objects, rather than by a fixed-format name [8, 32]. These last few efforts represent the first steps towards implementing name services that can handle all objects. "lhere are, of course, numerous paper designs for sintilar name services. More importantly, there is a wealth of available research on the fundamental principles of naming (in distributed systems); the reader is referred to [18], [21], [23], [25], [261, and [31], in particular. "lhe universal directory service described in this paper represents an attempt to refine both the concepts of naming and the implementation of viable name services. In the remainder of this section we examine a number of naming systems that represent the "'stale of the art". For each system, we briefly introduce the motivation for and background of the system. We cover the key areas of object management by taking the viewpoint e ra human user who, upon encountering each system for the first time might attempt to use its naming services.