Trellis[11] and DCWPL[3] also advocated separating coordination from computation so that the former can be specified in a more declarative way and interpreted at runtime.
DCWPL provides a rather ad hoc scripting language with facilities for modeling and controlling access to shared artifacts. It allows for definition of a fixed set of artifact attributes such as ``Authorized'', ``MaxInstance'', and trigger-like attributes such as ``Preexecution'', ``Postexecution''. Even if we can presume that the set of attributes provided is sufficient to capture every possible artifact in all collaborations so that we do not need to extend the language under any circumstances, the problem is that whenever a policy or function is not directly available in the declarative language DCWPL, the user still needs to program it in a procedural language. In this way the declarativeness of the language is undermined. The language we propose in COCA, however, is self-contained. The users can specify whatever coordination policies they want without constantly resorting to a procedural language, assuming the tools have the required functionality. In this way the declarative feature is reserved.
Trellis used a variant of Petri Nets, CTN or colored timed nets, to specify group interaction protocols. Trellis is a client/server architecture in which a centralized controller processes service requests from clients according to the specification. We argue that a centralized architecture like Trellis may work well for small groups which primarily exchange textual messages. But for large groups with hundreds of participants, especially when multimedia data is widely communicated, it is not clear how it is modeled and handled in Trellis and what level of performance can be expected. It is also not clear, at least in the paper, how CTN models the collaboration of large groups whose participants are highly fluid, and how exceptions, such as floor loss and unexpected loss of the current floor holder, are handled in a Trellis specification.
[26] attempted to use LOTOS[22] to specify a group drawing tool. However, our observation is that LOTOS and other process algebra based formal methods are not convenient for specifying collaborations. In LOTOS, communicating components must be explicitly connected by parallel composition operators. This proved sufficient for some situations where communicating components are fixed and relatively small in number. But in many collaborations, only the participant types (namely the roles) are fixed, while the number of involved participants is large and fluid, the exact number cannot be determined at specification time. LOTOS is not directly convenient for specifying such situations. And even for small and fixed-population collaborative situations, LOTOS is also not always convenient. For example, in order to model situations where a process offers a value and several other processes accept it, LOTOS uses a multi-way synchronization which fails if even one process fails to synchronize at that point. Many collaborations can actually tolerate such exceptions by allowing processes that have received the value to proceed while ignoring or trying to re-transmit the lost data to processes which are temporally unavailable due to communication link delay or failure. We replace the parallel composition operators in LOTOS with the collaboration bus and the conference bus, synchronization among communicating components are achieved by explicit message passing.