Transparencies

A transparency is some aspect of the distributed system that is hidden from the user (programmer, system developer, user or application program). A transparency is provided by including some set of mechanisms in the distributed system at a layer below the interface where the transparency is required. A number of basic transparencies have been defined for a distributed system. It is important to realize that not all of these are appropriate for every system, or are available at the same level of interface. In fact, all transparencies have an associated cost, and it is extremely important for the distributed system implementor to be aware of this. Much of the text of this book describes engineering solutions to archiving these transparencies, and attempts to outline the cost of the solutions. It is a matter for much research how the costs of implementing multiple transparencies interact. This is part of current research in how to reduce operating system and communications stack overheads through such approaches as Application Layer Framing and Integrated Layer Processing[#alf##1#]. The transparencies are:

Access Transparency There should be no apparent difference between local and remote access methods. In other words, explicit communication may be hidden. For instance, from a user's point of view, access to a remote service such as a printer should be identical with access to a local printer. From a programmers point of view, the access method to a remote object may be identical to access a local object of the same class. This transparency has two parts:
1. Keeping a syntactical or mechanical consistency between distributed and non-distributed access,
2. Keeping the same semantics. Because the semantics of remote access are more complex, particularly failure modes, this means the local access should be a subset. Remote access will not always look like local access in that certain facilities may not be reasonable to support (for example, global exhaustive searching of a distributed system for a single object may be unreasonable in terms of network traffic).
Location Transparency The details of the topology of the system should be of no concern to the user. The location of an object in the system may not be visible to the user or programmer. This differs from access transparency in that both the naming and access methods may be the same. Names may give no hint as to location.
Concurrency Transparency Users and Applications should be able to access shared data or objects without interference between each other. This requires very complex mechanisms in a distributed system, since there exists true concurrency rather than the simulated concurrency of a central system. For example, a distributed printing service must provide the same atomic access per file as a central system so that printout is not randomly interleaved.
Replication Transparency If the system provides replication (for availability or performance reasons) it should not concern the user. As for all transparencies, we include the applications programmer as a user.
Fault Transparency If software or hardware failures occur, these should be hidden from the user. This can be difficult to provide in a distributed system, since partial failure of the communications subsystem is possible, and this may not be reported. As far as possible, fault transparency will be provided by mechanisms that relate to access transparency. However, when the faults are inherent in the distributed nature of the system, then access transparency may not be maintained. The mechanisms that allow a system to hide faults may result in changes to access mechanisms (e.g. access to reliable objects may be different from access to simple objects). In a software system, especially a networked one, it Is often hard to tell the difference between a failed and a slow running process or processor. This distinction is hidden or made visible here.
Migration Transparency If objects (processes or data) migrate (to provide better performance, or reliability, or to hide differences between hosts), this should be hidden from the user.
Performance Transparency The configuration of the system should not be apparent to the user in terms of performance. This may require complex resource management mechanisms. It may not be possible at all in cases where resources are only accessible via low performance networks.
Scaling Transparency A system should be able to grow without affecting application algorithms. Graceful growth and evolution is an important requirement for most enterprises. A system should also be capable of scaling down to small environements where required, and be space and/or time efficient as required.

The transparencies are only one group of <#73#> properties<#73#> of an Open Distributed System. The groups are listed in table #tbtp#74>.

#table75#
Table: Properties

Obligations are drawn from the properties of co-operation. These are ;SPM_quot;contractual;SPM_quot; in the Object Oriented Programming sense. The behavior of applications or Objects can be evaluated against precise specifications. Obligations include:

Quality of Service In a similar sense to QoS terminology used in telecommunications, we may assign a set of values to various parameters of Open Distributed System services, such as availability and performance.
Policy. A set of prescriptive requirements may be imposed on the system excluding certain behaviors merely for policy reasons. For instance some particular set of users may be disallowed from access to some services at certain times. Constraints. Constraints are similar to policies but apply to the behavior of particular objects in the system, rather than to behavior of the system as a whole. These obligations are not implemented as objects themselves, but may be imposed by some objects within the system.
Persistence. Persistence is the notion of activity versus passivity. In conventional systems, the idea of process and data express activity versus passivity. In an Open Distributed System, the notion is less well defined since objects may be seen as passive relative to some parts of the system (e.g. a migration object would see other objects as passive, while clients of these objects after they have migrated would see them as active).

The reader may ask what freedom is left for the systems or applications programmer, when there are so many descriptive and prescriptive properties. That is exactly the strength of the Open Distributed Systems approach: The specification of the system will lead directly through object modeling to the choice of engineering and other tradeoffs available to the programmer. Prescriptive properties rule out those not available. Descriptive properties give choice - for example between failure transparency and access transparency constrained by a cost policy. The first seven chapters of this book discuss the design of the mechanisms needed to support these transparencies and describe some of the engineering costs involved in implementations of these mechanisms. The rest of this chapter outlines the distinction between operating system and application service support, and then provides an overview of the Object Oriented approach to structuring modules in open distributed systems. Much of the material is presented from the Engineering viewpoint.