In order to discuss access and location transparency, we need to
understand how objects are named, addressed and reached within a
distributed system.
The classic definition of these three terms is due to Shoch[#shoch##1#]:
-
A name distinguishes one object in a distributed system from another.
-
Its address tells us where an object is.
-
A route is how to get to an object from elsewhere..
In a distributed system, access transparency means that we must <#251#> hide<#251#>
the distribution from the application somehow.
However, often hiding only goes so far as the access mechanism (e.g.
remote procedural], and the distribution may be apparent from
the <#252#> name<#252#>. Examples of distribution being obvious from the name are
common in distributed programs such as electronic mail and some
distributed file systems [for example, names for remote
files in many PC network file sharing systems
include the remote fileserver name]. However,
in a distributed system many objects may have the same name
(sometimes deliberately as in groups, sometimes by accident); an
object may have many names. Choosing unique names in a large
distributed is a hard problem, which some argue it doesn't even make
sense to try to solve.
To access an object, we must derive first an address, and then a route
to that address, from its name.
Addressing and routing are the mechanisms that hide the distribution
from the application.
Names often become addresses and vice versa as you move through
different levels of abstraction in the system: as an example, here are
the mappings from name to address at the application level and network
level, and then from name to address from the inernet level to the
local area network level:
verbatim4
<#516#>#tex2html_wrap3804#<#516#>
Names, Addresses and Routes are so often confused that one might be forgiven
for saying <#254#> One person's name is another person's address<#254#>. The
reason for the confusion is partly the multiplicity of contexts these
words are used in, but also partly because although the design
requirements are clear, the functions are often mixed up in
implementation, or in presentation to a human user. In the author's
experience, the easiest way to understand the model given here is to
map it to one particular implementation (be it the postal service, the
telephone system of the Internet or another) and thereafter think of all
new systems encountered in terms of that!
<#517#>#tex2html_wrap3806#<#517#>