Moses[24] was originally intended to make the Linda[12] communication safer by ensuring that the interaction of each process with the shared tuple space be managed by a controller. Each controller enforces a set of rules to capture the following two events: when a message is sent out by the local agent, and when one arrives at this agent, the local control state is checked, transformation is possibly performed, then this message is either forwarded to the tuple space, or delivered to the local agent, or blocked according to the rule definition. Our work is different from Moses in the following ways: (1) we explicitly divide participants in a policy group by roles. Different roles are controlled by different set of rules rather than all participants governed by the same set of rules as in Moses. Messages can be directed to roles (fluid sets of participants) as well as individual participants. We further allow participants to dynamically join and leave a collaboration by taking and dropping roles, and support the dynamic modification of rules at runtime. (2) We borrowed the concept of ``gate'' from LOTOS to denote the points where our controller, the COCA virtual machine, interacts with its environment, and define active rules upon the arrival of messages at these gates. In this way, the controller can monitor messages arriving at multiple different gates instead of just one to and one from the tuple space as defined in Moses.
Both the tuple space in Linda and the internal database in COCA are associate memory for coordination between concurrency activities. Linda is often criticized for its overheads to maintain a tuple space. Such overheads become more aggravated when situated in large-scale distributed systems. In COCA, there are actually two levels of concurrency. First, activities of all the participant cocavms are concurrent. Their coordination and synchronization are achieved by explicit, asynchronous message passing. Second, within each cocavm, multiple threads are executed concurrently. Their coordination is primarily through database operations which are correspondent to those in Linda. The cost of maintaining such an internal database is trivia, if not none.
In Manifold[1], ports are unidirectional and are considered as part of the definition of a component or manifold. Channels are established between the output port of a manifold to the input port of another manifold. Although this kind of connections are not restricted to be one-to-one, multi-point communication must be fulfilled by connecting one output port to multiple input ports. So it is not the multicast bus architecture as we are using.