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.