Coordination

Bergstra & Klint (1996b,a) have introduced the TOOLBUS, a component interconnection architecture resembling a hardware communication bus. To control the possible interactions between software components connected to the bus direct inter-component communication is not supported by the architecture.

The TOOLBUS serves the purpose of defining the cooperation of a number of components $C_i$ $(i = 1 ,\ldots, m)$ that are to be combined into a complete system as is shown in Figure 2. The internal behavior or implementation of each component is irrelevant: they may be implemented in different programming languages or be generated from specifications. Components may, or may not, maintain their own internal state. The parallel process $P_1\parallel\cdots\parallel P_n$ in Figure 2 describes the initial behavior of the interaction between the components $C_1,\dots,C_m$ and the interactions between the sequential processes $P_1,\ldots,P_n$. A sequential process $P_i$ can, for example, describe communication between components, communication between processes, creation of new components, or creation of new processes. TOOLBUS processes also support relative and absolute time aspects. In the communication between the TOOLBUS and a component both can take the initiative for the communication. In this way, the TOOLBUS can send computation requests to components (ultimately resulting in some answer from the component), or the component can send a request to the TOOLBUS (typically, to notify the TOOLBUS of user-interaction or an error condition). The operators like the parallel composition operator $\parallel$ that we use in TOOLBUS processes stem from concurrency theory, more precisely, they are based on the algebra of communicating processes (ACP) described by Baeten & Weijland (1990) and Baeten & Verhoef (1995).

Coming back to the discussion on Unix pipelines (Section 1.2), it will be clear that we have extended the set of composition operations from only sequential composition to a much richer set of operators. Bergstra & Klint (1996b) give a comparison of the TOOLBUS with other approaches to software integration. Here it is sufficient to summarize the most innovative aspects of the TOOLBUS: (i) the process-oriented description of cooperation; and (ii) the standardization of the intermediate data exchanged between components as described in the next section.

The overall effect of the TOOLBUS approach is that components become black boxes that can transform and generate information in a common intermediate data format. We have explicitly chosen to ignore the meaning of the operations performed by the components; it remains the responsibility of a system's designer to compose components in meaningful ways.