Transparency

Transparency is defined as the concealment from the user and the application programmer of the separation of components in a distributed system so that the system is perceived as a whole rather than as a collection of independent components. The implications of transparency are a major influence on the design of the system software.The ANSA Reference Manual [ANSA 1989] and the nternational Organization for Standardization’s Reference Model for Open Distributed Processing (RM-ODP) [ISO 1992] identify eight forms of transparency. We have paraphrased the original ANSA definitions, replacing their migration transparency with our own mobility transparency, whose scope is broader:
Access transparency enables local and remote resources to be accessed using identical operations.
Location transparency enables resources to be accessed without knowledge of their physical or network location (for example, which building or IP address).
Concurrency transparency enables several processes to operate concurrently using shared resources without interference between them.

Replication transparency enables multiple instances of resources to be used to increase reliability and performance without knowledge of the replicas by users or application programmers.

Failure transparency enables the concealment of faults, allowing users and application programs to complete their tasks despite the failure of hardware or software components.
Mobility transparency allows the movement of resources and clients within a system without affecting the operation of users or programs.
Performance transparency allows the system to be reconfigured to improve performance as loads vary.
Scaling transparency allows the system and applications to expand in scale without change to the system structure or the application algorithms.
The two most important transparencies are access and location transparency; their presence or absence most strongly affects the utilization of distributed resources. They are sometimes referred to together as network transparency.As an illustration of access transparency, consider a graphical user interface with folders, which is the same whether the files inside the folder are local or remote. Another example is an API for files that use the same operations to access both local and remote files (see Chapter 12). As an example of a lack of access transparency, consider a distributed system that does not allow you to access files on a remote computer unless you make use of the FTP program to do so.
Web resource names or URLs are location-transparent because the part of the URL that identifies a web server domain name refers to a computer name in a domain, rather than to an Internet address. However, URLs are not mobility-transparent, because someone’s personal web page cannot move to their new place of work in a different domain – all of the links in other pages will still point to the original page.
In general, identifiers such as URLs that include the domain names of computers prevent replication transparency. Although the DNS allows a domain name to refer to several computers, it picks just one of them when it looks up a name. Since a replication scheme generally needs to be able to access all of the participating computers, it would need to access each of the DNS entries by name. As an illustration of the presence of network transparency, consider the use of an electronic mail address such as Fred.Flintstone@stoneit.com. The address consists of a user’s name and a domain name. Sending mail to such a user does not involve knowing their physical or network location. Nor does the procedure to send an email message to depend upon the location of the recipient. Thus electronic mail within the Internet
provides both location and access transparency (that is, network transparency).
Failure transparency can also be illustrated in the context of electronic mail, which is eventually delivered, even when servers or communication links fail. The faults are masked by attempting to retransmit messages until they are successfully delivered, even
if it takes several days. Middleware generally converts the failures of networks and processes into programming-level exceptions (see Chapter 5 for an explanation).
To illustrate mobility transparency, consider the case of mobile phones. Suppose that both caller and callee are traveling by train in different parts of a country, moving from one environment (cell) to another. We regard the caller’s phone as the client and the callee’s phone as a resource. The two phone users making the call are unaware of the mobility of the phones (the client and the resource) between cells. Transparency hides and renders anonymous the resources that are not of direct relevance to the task at hand for users and application programmers. For example, it is generally desirable for similar hardware resources to be allocated interchangeably to
perform a task – the identity of a processor used to execute a process is generally hidden from the user and remains anonymous. As pointed out in Section 1.3.2, this may not always be what is required: for example, a traveler who attaches a laptop computer to
the local network in each office visited should make use of local services such as the send mail service, using different servers at each location. Even within a building, it is normal to arrange for a document to be printed at a particular, named printer: usually, one that is near to the user.

Frequently Asked Questions