As shown above, each of the multi-user tools we have considered has important advantages and drawbacks. Therefore, it would be useful if a single application could use the services of multiple tools to to support sharing of different parts of its data. However, currently, there are several barriers to using more than one of these multiuser tools together:
On the other hand, it is possible for a client of one of these multiuser tools to also be a client of a database system, an RPC system, or a message server since these tools have been designed to accommodate multiple application and machine architectures, programming languages, and operating systems. Thus, it is possible to create a multiuser application as a set cooperating processes that communicate with each other using a database system, RPC system, or a message server, as illustrated by Figure 8.18.
Implementing the example user-interface: Consider implementation of the example user-interface using a message server, RPC, Colab, and Suite (Figure 8.18). Each user of the application would interact simultaneously with a Suite dialogue manager, which would manages the edit window, and a Colab client, which would manage the test window. Colab broadcast methods would be used to define the WYSIWIS coupling among the test windows and the Suite coupling attributes would be used to define the semantic coupling among the edit windows. The coupling among test and edit windows would be implemented by the Suite and Colab clients, which be communicate with each other using RPC, a message server, and/or a database system.
Figure: Using Multiple Tools
Naturally, this approach is not ideal since it requires that logical components of a multiuser application that needs the services of different incompatible tools be made separate processes, thereby increasing the cost of starting the application and communicating among these components. However, it is the only practical approach until these tools are made more interoperable.