Models and paradigms for distributed systems structuring: the BirliX approach
Authors: H. Härtig, W. E. Kühnhauser, W. Lux, O. C. Kowalski, H. Streich, A. Bäcker
Venue: Proceedings of the 5th workshop on ACM SIGOPS European workshop: Models and paradigms for distributed systems structuring (1992)

A primary objective in building distributed operating systems is to identify and implement abstractions,&bull; that are understood and easily used by application's and system's programmers, and&bull; that can be implemented efficiently, reliably and securely in distributed environments.These abstractions should be open for&bull; adding functionality e.g. reading and writing data from/to a file, adding/removing a date to a calendar&bull; adding non-functional properties e.g. transparently accessing a file over a network or caching a file for a sequence of read/writesIn many cases, when such non-functional properties are offered, there is a trade off between&bull; transparency e.g. for the purpose to relieve the programmer of the burden to deal with networks&bull; control e.g. for the purpose to give the programmer means to select (or add) the most efficient, scalable ... protocol for its purposeUnix processes and files are an extremely successful example. Its abstractions are easy to use and have been implemented successfully in distributed environments. Non-functional properties, such as network transparent access, have been added in straight forward ways. Hiding everything behind files transparently, yet providing means to control, has been done in a rudimentary way (e.g. ioctrl operations to control devices, while still having applications that use devices as files).Limitations of Unix, originating in its separation of non persistent processes and passive files, become apparent when more complex non-functional properties are investigated. A replicated file system together with process pairs is not sufficient to support replicated applications. An additional weakness is the absence of coherent interfaces to control otherwise transparent non-functional properties. A well known example for missing means to control transparent non-functional properties is the absence of means to control buffer management for databases and for multimedia applications.Microkernels per se do not solve that problem. They might succeed in providing better structured, i.e. maintainable ..., implementations, but they do not provide an interface that clearly separates functional and non-functional properties and balances transparency vs. control.The BirliX system has been built based on that analysis. It provides --- at the system kernel interface --- a single abstraction: persistent instances of BirliX types. Applications, e.g. the Unix Emulation, are clusters of cooperating instances. They have in common a set of non-functional properties (e.g. the location of an instance can change without burdening the programmer of the type) and a set of operations to control such non-functional properties (e.g. operations to migrate an instance dependent on some selected algorithm). Thus, a non-functional property balanced load can be achieved by a policy server that uses the type independent migrate operation.In the remainder of this extended abstract first a more precise description of BirliX Types is given (essentially an excerpt from [HKLR92]). Then, two examples are given that show how the transparency vs. control problem is dealt with in the BirliX approach. Finally, the achievements and limitations of the BirliX paradigm based on our experience are given.