The generic architecture given above defines a design space of collaboration architectures that differ in the way they resolve several important issues:
In the following sections, we discuss these issues in-depth. We do not give specific answers to these questions, since they would depend on particulars of the application. Instead, we present general constraints or approaches for resolving these issues and discuss the consequences of using these approaches.
In our discussion, we consider two decompositions of a collaborative application: by computation and concurrency unit. The first one, used in figure 9.2, assumes that an application is divided into one or communicating modules, a module may be composed of one or more levels, and each level consists of one or more replicated layers. In the rest of the discussion, we shall often use the term level and layer interchangeably, especially when a level consists of a single layer. The second one assumes that an application is decomposed into one or more distributable processes, and each process forks one or more concurrent threads. The difference between a process and a thread is that the former is a heavyweight unit of concurrency, associated with its own address space, which can be created on different hosts. In contrast, all threads within a process share a common address space and host, though they may execute on different processors on the host.
Figure 9.3 shows the two decompositions of an application. As shown later, these two kinds of decompositions are not independent in the architectures we present below.
Figure 9.3: Decomposing an application by computation and concurrency units.