The transparencies are:
The transparencies are only one group of <#73#> properties<#73#> of an Open
Distributed System. The groups are listed in table #tbtp#74>.
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
This transparency has two parts:
Keeping a syntactical or
mechanical consistency between distributed and non-distributed access,
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).
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.
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
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.
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.
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.
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.
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.
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:
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
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
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
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.
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 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 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).