In this chapter we look at modularity in distributed systems.
As we said in chapter 1, systems are distributed for two basic
reasons. Either components of the system are distributed because of
inherent organisational reasons, or else they are distributed
explicitly by the implementors for reasons of performance.
In either case, these components represent moduels that need to
communicate, since at the very least they occupy different
address spaces. This means that we must move data from one modeul to
another by some inter-process communications mechanism if we want to
coordinate computation. They are also modules that are inherently concurrent,
that is to say that they reside on separate processors which are not
explicity coupled in their execution. It is the programmers task to
provide any such coordination if needed.
We normally refer to these modules as <#244#> processes<#244#> or <#245#> tasks<#245#>.
They are run on systems just like any other jobs, which means they
must be installed, scheduled and so forth.
Before communcation can take place, there must be mechanisms to provide
a way of finding the right module on the right computer. Then the
appropriate inter-process communcation mechanism must be selected.
Finally, any rules that constrain when we can and cannot communciate
between modules must be respected. Ideally, to make the task for the programmer
easier, all of these mechanisms are provided as simple extensions of
the same mechanisms that are present within a single computer system.
In the context of the viewpoints presented in Chapter 1,
access, location and concurrency transparency for the distributed
application, fall into the Engineering and Computational
viewpoints.
These mechanisms are the most well understood of distributed systems.
For example, processes that implement services that provide
access to distributed organsiational information or technology are
usually named hierarchically, and accessed through remote procedure
call. Often, concurrencey control is not required. Sometimnes,
replicated servers are provided to increase performance, sometimes
through lightweight processes or <#246#> threads<#246#> which allow a
programmer finer grain control over concurrency,
performance and scheduling than
conventional processes.
On the other hand, programs that have been distributed for reasons of
performance or availability often employ message passing as a
communcaitions mechanism, and may use a private naming system.