We have been engineering distributed computing architectures according to roughly the same formulas for quite a number of years; yet each time, the end result has had greater complexity. Modern distributed computing architectures have an enormous number of protocols, layers, configuration parameters, APIs, etc. While we seem to be proceeding in the right direction in functionality, the growth in complexity is perplexing and has the potential to slow progress in research and in commercial use. I'll discuss this topic and propose areas of research that are relevant to resolving the issue.

The design of most distributed systems has settled down into a reasonably coherent architectural framework, with only moderate perturbations occurring from system to system, and from generation to generation. I'll describe the framework, some lessons learned as this framework has progressed over the last 20 years, and some important research and engineering challenges ahead. I'll extrapolate to the types of amazing systems we might successfully construct, if we can meet these challenges.

Significant advances are required to make systems more adaptive to the growing range of impulses affecting them and to reduce their total cost of management. Progress seems to require significant innovation in adaptive techniques, systems architecture, software engineering, and standards. In this presentation, I will survey the space of the requirements and draw example problems from real systems. I'll then discuss the space of our research at IBM and highlight some of the more compelling research projects we are doing in the area. I'll conclude with a summary of some key challenges for the broader community as they relate to autonomic computing.

This paper describes the importance of modularity in systems and lists a number of reasons why systems will become increasingly modular. It describes two strawmen architecture models for systems and distributed databases in order to illustrate the hierarchical decomposition of complex systems. The paper also relates the systems model to the layering achieved in a few systems familiar to the author.

Increased interest in using workstations and small processors for distributed transaction processing raises the question of how to implement the logs needed for transaction recovery. Although logs can be implemented with data written to duplexed disks on each processing node, this paper argues there are advantages if log data is written to multiple log server nodes. A simple analysis of expected logging loads leads to the conclusion that a high performance, microprocessor based processing node can support a log server if it uses efficient communication protocols and low latency, non volatile storage to buffer log data. The buffer is needed to reduce the processing time per log record and to increase throughput to the logging disk. An interface to the log servers using simple, robust, and efficient protocols is presented. Also described are the disk data structures that the log servers use. This paper concludes with a brief discussion of remaining design issues, the status of a prototype implementation, and plans for its completion.

Weighted voting is used as the basis for a replication technique for directories. This technique affords arbitrarily high data availability as well as high concurrency. Efficient algorithms are presented for all of the standard directory operations. A structural property of the replicated directory that permits the construction of an efficient algorithm for deletion is proven. Simulation results are presented and the system is modeled and analyzed. The analysis agrees well with the simulation, and the space and time performance are shown to be good for all configurations of the system.

Facilities that support distributed transactions on user-defined types can be implemented efficiently and can simplify the construction of reliable distributed programs.To demonstrate these points, this paper describes a prototype transaction facility, called TABS, that supports objects, transparent communication, synchronization, recovery, and transaction management.Various objects that use the facilities of TABS are exemplified and the performance of the system is discussed in detail.The paper concludes that the prototype provides useful facilities, and that it would be feasible to build a high performance implementation based on its ideas.

The TABS prototype is an experimental facility that provides operating system-level support for distributed transactions that operate on shared abstract types. The facility is designed to simplify the construction of highly available and reliable distributed applications. This paper describes the TABS system model, the TABS prototype's structure, and certain aspects of its operation. The paper concludes with a discussion of the status of the project and a preliminary evaluation.

The synchronization issues that arise when transaction facilities are extended for use with shared abstract data types are discussed.A formalism for specifying the concurrency properties of such types is developed, based on dependency relations that are defined in terms of an abstract type's operations.The formalism requires that the specification of an abstract type state whether or not cycles involving these relations should be allowed to form.Directories and two types of queues are specified using the technique, and the degree to which concurrency is restricted by type-specific properties is exemplified.How the specifications of types interact to determine the behavior of transactions is also discussed.A locking technique is described that permits implementations to make use of type-specific information to approach the limits of concurrency.

This paper describes a replication algorithm for directory objects based upon Gifford's weighted voting for files. The algorithm associates version number with each possible key on every replica and thereby resolves an ambiguity that arises when directory entries are not stored in every replica. The range of keys associated with a version number changes dynamically; but in all instances, a separate version number is associated with each entry stored on every replica. The algorithm exhibits favorable availability and concurrency properties. There is no performance penalty for associating a version number with every possible key except on Delete operations, and simulation results show this overhead is small.