Motivation
There are several reasons for the growing importance of open distributed computing in a wide swath of fields. First, the problems the world is facing are growing more complex, requiring more complex models and analyses to solve them. Second, there is an abundance of relatively inexpensive computational power available in the form of microcomputers, which can be used to work on the problems in parallel to speed up the process (Linpack Benchmark, 2009). The importance of this is magnified by evidence that suggests that current semiconductor technology is rapidly approaching its theoretical limits in terms of speed and size. According to IBM Fellow Carl Anderson, the end of the exponential scaling down of the size and cost of semiconductors is coming to an end within two generations of devices (keynote address, International Symposium on Physical Design, 2009 conference). This means that further advances in computing speed must come from architecture and software changes, such as distributed and parallel computing. Distributed programming skills are thus in rapidly rising demand for developing applications in emerging fields that require massive amounts of computation.
The development of open distributed systems present challenges for software development technology. Open distributed systems are systems consisting of independent software components (processes) that work together as a single coherent system. The ‘open’ is closely related to ‘heterogeneity’ which indicates the systems may be developed in different programming languages to run on different platforms and communicate through different networks.
Classical concurrent programming languages do not well support the development of open distributed systems. Programmers are required to write the code in dealing with the computation, synchronization, heterogeneity, and communication details of the systems. Programmers are also required to use the low-level language constructs to implement these details. It usually makes the distributed programming more complicated and error prone (Chiang, 2004). Examples of low-level language constructs for distribution and synchronization are fork/join, semaphores, and remote procedure call. Without careful writing these constructs in programs, a programmer can easily create a deadlock in the programs. Object-oriented technologies might help the decoupling of synchronization from the code. Dragoon (Atkinson, Goldsack, Maio, & Bayan, 1991) is an object-oriented language that provides an approach trying to separate the synchronization behavior from the object behavior.
The middleware technologies offer a promising way to alleviate the problems of developing distributed systems in classical concurrent programming languages. Over the years, the middleware technologies were developed to abstract away and encapsulate the details of communication in a heterogeneous computing environment. Programmers can focus on the details of computation without concerning the communication details. Middleware technologies do provide support for the integration of components in a heterogeneous computing environment. However, the coordinating components are implemented in terms of explicit communication protocols which are not abstract enough to decouple the coordination and communication. Therefore, as a coordination pattern changes, there is a need to change the implementation. As the programs evolve, it often results in the code difficult to maintain. In addition, the middleware technologies also suffer the problems of reuse of components (Chiang, 2003).
A new class of coordination models and languages has recently evolved for the development of open distributed systems to address the coupling issues using the middleware technologies. The models aim to decrease the complexity of the development by decoupling the concerns of coordination and computation in the development of the systems. A new research direction has been suggested to integrate the coordination models in the context of middleware. Thus, the coordination models and languages can be used to decouple the complexity of coordination, communication, computation, and heterogeneity.
In general, distributed systems can be divided into either non-cooperative or cooperative. Nevertheless, many systems might suggest that there is no definite place for cooperation in the former and no place for competition in the latter. A cooperative system is a system where groups of participants may enforce cooperative behavior, hence exhibits a competition between coalitions of participants, rather than between individual participants. In this paper, we are presenting two major categories of coordination models and languages, data-driven and control-driven models for the development distributed cooperative systems. A typical data-driven coordination model, namely Linda will be described in detail followed by the discussion of Manifold which is a control-driven model. The Dining Philosophers problem is used to illustrate the differences of these models. Different from Linda and Manifold, we present a control-driven model allowing coordination to be handled implicitly. The paper ends with a discussion comparing these three models and then concludes the paper.
The rest of the paper is organized as follows. First, we give the definition of coordination followed by the definitions of coordination models and coordination languages. Related work is presented afterwards. A data-driven coordination model with Linda is illustrated using the Dining Philosophers Problem in the following section. Next we present a control-driven coordination model with Manifold using the same example. We propose our coordination model which is contro-driven after that. The model provides a level of abstraction which hides the complexity of coordination and communication from programmers. The Dining Philosophers problem is used to demonstrate the differences of our model and the data-driven and control-driven models.