A Coordination Component Framework for Open ...

A Coordination Component Framework for Open Systems1 Juan Carlos Cruz, Sander Tichelaar and Oscar Nierstrasz Software Composition Group, University of Bern2

Abstract. Coordination technology addresses the construction of open, flexible systems from software agents in distributed systems. Most of the work on coordination technology so far has focused on the development of special coordination languages and environments that provide the basic mechanisms for realizing the coordination layer of a distributed application. Typically each new language proposes its own set of coordination abstractions that realizes a particular paradigm for realizing coordination. Coordination problems, however, are not always well-suited to a particular paradigm. Instead of proposing a new language, we are attempting to develop an open set of software components that realize various useful coordination abstractions. We are validating our approach by developing an experimental framework of coordination components in Java and applying them to a canonical set of sample applications. We present our initial analysis of the coordination domain, and give a few examples of simple applications using the developed coordination components.

1 Introduction Over the last two decades software development has changed significantly. Its evolution has been motivated by the goal of producing open rather than closed, proprietary systems. Open systems are basically “open” in terms of topology, platform and evolution [30]: they run on networks which are continuously changing and expanding, they are built on the top of a heterogeneous platform of hardware and software pieces, and their requirements are continuously evolving. Evolution is the most difficult requirement to meet, since not all the application requirements can be known in advance [22]. Development of open systems is a difficult task, because in addition to requirements concerning openness, they have special computational constraints. Open systems are composed of encapsulated software entities (active objects, agents, actors, etc.) [31] that run and process information concurrently, that could be physically distributed, that run asynchronously, that are tolerant to faults [9], and that interact together in a coordinated way to produce results. We propose to tackle the problem of development and evolution of open systems, particularly their coordination aspects, using a component-based approach. We will validate this ap1. Submitted to COORDINATION’97 2. Authors address: Institut für Informatik (IAM), Universität Bern, Neubrückstrasse 10, CH-3012 Berne, Switzerland. Tel: +41 (31) 631.3315. Fax: +41 (31) 631.3965. E-mail: {cruz,tichel,oscar}@iam.unibe.ch. WWW: http://iamwww.unibe.ch/~scg.

2.

A Coordination Component Framework for Open Systems

proach by defining and constructing an open coordination component framework useful for supporting the development of coordination aspects in open systems. Coordination components realize generic solutions to standard coordination problems. They can be specialized and parameterized to solve specific coordination problems. With these components we provide explicit separation of coordination from computation, and facilitate reuse and evolution of coordination aspects. We do not focus our work, as traditionally has been done on coordination research, on the definition of a new language that realizes a particular paradigm for realizing coordination. This approach is inherently limited because coordination problems are not always well-suited to a particular paradigm. We are developing a prototype of this coordination component framework using the Java language, an object-oriented language well-suited to modelling software entities in a distributed setting. We are validating the framework by applying it to a set of sample applications that characterize open systems. This paper presents an initial analysis of the coordination domain, and gives examples of simple applications that make use of the developed coordination components. The remainder of this paper is structured as follows. Section 2 discusses the problem of development and evolution of coordination aspects in open systems and introduces the approach that we propose to use to tackle this problem. Section 3 introduces some examples of coordination components that compose our framework and gives examples of simple applications using these components. Section 4 gives an overview of related work. Finally, section 5 concludes with a discussion: evaluating our contributions and pointing to directions for future work.

2 Development and Evolution of Coordination Aspects in Open Systems Open systems are systems composed of encapsulated and persistent software entities [31] which interact in a coordinated way to produce results. They are encapsulated because they have an interface that hides their implementation; and they are persistent because their lifetime is longer than that of the atomic interactions (e.g messages) which they execute. Open systems are hard to develop because they pose a series of requirements that are not easy to meet. The basic computational requirements are that they be [9]: • • • • •

Concurrent: software entities run and process information concurrently. Distributed: software entities run physically distributed. Asynchronous: software entities run asynchronously. Control Decentralized: local decisions are preferred to centralized decisions. Heterogeneous: the knowledge represented in the software entities could contain different perspectives and conflicting beliefs. • Continuously operating: failures of individual software entities do not affect the operation of the system. In addition to these computational requirements, open systems must support the continuous evolution of the application requirements. Evolution is the most difficult requirement to meet, since in effect not all the application requirements can be known in advance due to changing needs and technological demands [22].

Juan Carlos Cruz, Sander Tichelaar and Oscar Nierstrasz

3.

Traditional application development methods are inadequate to support the development of open systems [21]. They assume closed and fixed requirements, and therefore result in inflexible systems that cannot be easily adapted to unexpected changes in requirements [22][23]. The problem of development and evolution of open systems could be tackled using a component-oriented approach [19][22]. In this approach, each application is viewed as only one instance of a generic class of applications, each being flexible composed of “software components”. New application requirements are addressed by removing, replacing and reconfiguring the software components without disturbing other parts of the application. A generic class of applications can be defined using component frameworks[20] that describe the way in which a specific class of systems are composed by its components, their interactions, the patterns that guide their composition, and the constraints on these patterns [20][28]. We want to validate this approach by constructing a prototype component framework for one of the most important development aspects of an open system: the coordination of the concurrently operating active entities of the system [12]. Coordination in this context basically concerns the management of the possible interdependencies between the activities that these entities perform (e.g. managing the allocation of shared resources, managing simultaneity constraints, etc.). These interdependencies define what we call coordination problems. The coordination component framework that we are constructing will be composed of coordination components that realize generic solutions to standard coordination problems. We will call in this paper these generic coordination solutions Generic Coordination Abstractions. A framework of coordination components is important for supporting the development and evolution of coordination aspects in open systems. In the next subsections we introduce a more complete description of the problem of coordination in software systems. We propose a definition of coordination that will be used to systematically identify coordination problems in open systems (2.1) as well as some examples of coordination problems that we have identified so far. Each one of the coordination problems will be introduced including particular situations in which they can occur (2.2). We discuss more precisely four of them: managing allocation of shared resources (2.2.1), managing the transfer of information between activities (2.2.2), managing synchronization constraints between activities (2.2.3), and managing group decisions (2.2.4). We present for each one of these examples the coordination process that describes the generic solution to the coordination problem. These generic coordination processes will be used to define the components that will compose our coordination component framework.

2.1

Coordination

We all have an intuitive idea of what the word “coordination” means. Even if we are capable of identifying situations which require some form of coordination (e.g. accessing a database, taking group decisions, etc.) it is always difficult to explain: what it is and why we need it?. We are interested in having answers for these questions in the particular case of open systems. Coordination problems arise in the organisation of interactions of a group of entities that collaborate and cooperate to accomplish some task and to satisfy some goals. It is because entities cooperate that they can accomplish more elaborated actions, but it is also because of their multiplicity that they must coordinate their actions and resolve conflicts.

4.


The problem of the interaction of a group of autonomous entities not only concerns the description of the mechanisms that allow entities to interact (e.g. communication, etc.), it also concerns the study of the different forms of interaction that the entities could practice to accomplish their tasks and to satisfy their goals (cooperation, collaboration, coordination of actions, etc.) [6]. Cooperation is the most common form of interaction. It includes the resolution of all the subproblems which constitute the collaboration, the coordination of actions and the resolution of conflicts [6]. These subproblems are related with determining who makes what, when, where, with which resources, how, and with whom. Coordination in this context concerns the organisation in time and in space of the behaviour of a group of entities in order to either improve their collective results, or to reduce their conflicts. This definition of coordination does not specify the reasons why the actions of multiple entities need to be coordinated. They are basically three [11]: 1. There are dependencies between the activities performed by multiple entities: Interdependencies arise when either decisions made by one entity have an impact on the decisions of the other entities (e.g. to access a shared resource), or when it is possible to have harmful interactions (e.g. to modify a global value). 2. There is a need to meet global constraints: Global constraints exist when conditions are imposed on the way in which solutions must be implemented by the entities. 3. No individual has enough competence, resources, or information to solve the entire problem. One interesting body of work in the area of coordination theory is that of Malone and Crowston [14]. It is basically oriented to the study of the different kinds of dependencies between activities performed by multiple entities. They propose to define coordination as: The act of managing interdependencies between activities performed by entities in order to achieve some goals 1. What is different between these two definitions of coordination is that the first one includes the organisation of the behaviour of the group of entities as a basic coordination activity, while the second concerns basically the activity of managing possible conflicts (which they call dependencies) that can occur once that the behaviour of the group has been defined. Nevertheless both are related with the goal of improving the collective results of entities that interact together to achieve some goals. The second definition is more restrictive. Malone and Crowston [14] say that their definition focuses explicitly on the elements that are unique to coordination. These unique elements being the interdependencies between the activities. We have focused initially our work on the study of these aspects that are unique to coordination. Nevertheless we include some initial results on coordination as an organizational activity. Malone and Crowston [14][16] have identified the following kinds of interdependencies: • Shared Resource: a resource is required by multiple activities. • Prerequisite: an activity must be completed before another can begin. 1. Even if many important coordination situations involve multiple actors, this definition also applies even if there is only one actor which perform the activities.


• • • • •

5.

Transfer: an activity produces something that is required by another. Usability: whatever is produced by an activity should be usable by another. Simultaneity: some activities need to occur (or cannot occur) at the same time. Task/Subtask: a group of activities are all “subtasks” for achieving some overall goal. Group Decisions: decisions are taken collectively.

One interesting remark at this point is that only two of these dependencies represent synchronization constraints between activities: Prerequisite and Simultaneity. The point is that coordination problems cannot be reduced to only the management of synchronization constraints. We recognize their importance but we do not fix our work on them. We will introduce now some work that we have done on these kinds of interdependencies. It concerns basically the generalisation and specialization of the constraints imposed on them. Our first proposal concerns the generalisation of the prerequisite and transfer interdependencies. The definition proposed by Malone and Crowston, basically defines a one-to-one relationship between a producer activity and a consumer activity. The first generalisation that we propose corresponds to a redefinition of these types of interdependencies specifying an undefined number of producer and consumer activities. • Multiple-Prerequisite: some activities must be completed before others can begin. • Multiple-Transfer: some activities produce things that are required by others. The second generalisation that we propose, concerns exclusively the prerequisite dependency. In this dependency the beginning of an activity is constrained by the termination of another. We propose to generalize this constraint by defining general conditions based on possible states of the producer activity (e.g. the producer is pending, etc.) • Conditioned-Prerequisite: The beginning of an activity is constrained by some condition concerning the state of another. The third proposal concerns the specialization of the transfer dependency. This dependency does not make anything explicit about the thing that must be transferred. We propose to specialize the “thing” by defining it as possibly composed by different kinds of “sub-things”. • MultiComposed-Transfer: Several activities produce different things that, when composed together, can be used by other activities. Our last proposal concerns the definition of a time dependency between executing activities. Even if we have not included the time dimension in the definition of open systems, we recognise that this aspect is fundamental in some of these systems (e.g. to determine the moment of execution of an activity, to establish time-outs, etc.). We propose to modify the prerequisite dependency by imposing a time constraint on the relationship between the actives. • Delta_Time-Prerequisite: an activity must begin a delta-time afterwards the end of another. This list of interdependencies is not intended to be exhaustive. Its importance is that it could be used to propose a systematic approach to identify coordination problems in open systems. Basically the approach that we followed was: 1) to take the list of dependencies1 presented be1. In this process the list of interdependencies can be iteratively updated.

6.


fore; 2) to identify common concurrent activities in open systems (e.g.communication, management of resources and services, application control, etc.) [5][18][29]; and 3) to analyse the existence of possible interdependencies in these activities. We will present in the next subsection some examples of coordination problems that we have identified using this approach. For each problem we will present particular situations in which these coordination problems can occur. Finally, we want to close our general discussion on coordination considering the work made by Mintzberg [17] on the definition of different ways to handle coordination. He considered three fundamental coordination forms or styles: • Mutual adjustment: This occurs whenever two or more entities agree to share resources to achieve some goal. Entities must exchange information and make adjustments in their behaviour, depending on the behaviour of other entities. In this form of coordination no entity has any prior control over the others. • Direct Supervision: This occurs when two or more entities have already established a relationship in which one entity has some control over the others. The prior relationship is commonly established by mutual adjustment. In this form of coordination the supervisor controls the use of common resources and prescribes certain aspects of the behaviour of its subordinates. • Standardization: This occurs when entities have to follow pre-established standard procedures in a number of situations. In these form little coordination is needed, until the procedure itself needs to change. Mutual adjustment defines a form of coordination particularly well adapted to a distributed setting. The fact that no entity has a prior control over the others avoids the existence of a centralized supervisor susceptible of failures that might become a performance bottleneck. Nevertheless, Direct Supervision has the advantage that the coordination process is simpler, less messages need to be exchanged and no group decisions are necessary. Standardization could be used in both cases (centralized and decentralized setting) the problem is that this form of coordination is not well adapted to the evolution of the coordination requirements. Malone suggests that using these fundamental forms of coordination, it is possible to construct sophisticated systems for coordination [15].

2.2

Coordination Problems in Open Systems

There are a lot of coordination problems that appear over and over again when developing open systems. They are primarily concerned with dependencies that exist between the activities performed by the entities of the system. They concern, for example, problems like: • Managing the allocation of shared resources (e.g. when allocating resources like actor’s time, memory, or disk space, etc.). • Managing the access to shared resources (e.g. when we request access to a window, a print-service, or a database, etc.). • Managing execution ordering between activities (e.g. when a file must be opened before write operations can be done; when a pipe must be created before sending information through it, etc.).


7.

• Managing the transfer of information between entities (e.g. when computing the topology of a network, or when communicating partial results, etc.). • Managing simultaneity constraints between activities (e.g. when two input operations cannot be performed at the same time on a screen, when two users cannot open the same file at the same time, etc.). • Managing task/subtask dependencies (e.g. when a group decides to decompose a goal into a set of activities, etc.). • Managing group decisions (e.g. when, due to a failure a new server must be elected, when a synchronization token must be regenerated in ring, when deciding how to allocate resources, etc.). This is not a complete list of coordination problems in open systems. They represent a large set that we have already identified. They describe generic coordination problems in the sense that there could be a lot of concrete situations in which these coordination problems could occur. We will introduce some of them now, with examples of situations in which they can occur. We have selected a set of representative coordination problems that we think are simple and easy to understand: 1) managing allocation of shared resources, 2) managing the transfer of information between activities, 3) managing synchronization constraints between activities, and 4) managing group decisions. 2.2.1

Managing Allocation of Shared Resources

Managing the allocation of shared resources is one of the most common coordination problems that occurs in software systems. Whenever multiple activities share some limited resource (e.g. storage space, an actor’s time, etc.), a coordination process which controls the allocation of the resource is needed. The coordination process must: serialize concurrent allocation-requests to the resource, select (by using a pre-defined allocation policy) the request to be served, control that all clients will obtain the resource, control security aspects (access rights, etc.), take care of possible software and hardware failures, etc. A particular situation in which this coordination problem occurs is when multiple processes share a unique disk space (fig.1). In this example the coordination process serializes the incoming requests using a queue.

Requests Processes Queue

Disk

Figure 1 Processes requesting disk space

2.2.2

Managing The Transfer of Information Between Activities

Producer/consumer relationships occur in software systems whenever one activity produces some information that is used by another activity. A coordination process which controls the transfer of information between activities is needed. The coordination process must: guarantee the physical transfer of information between the entities (from one entity space to another),

8.


control their synchronization, control the replication and transfer of information in case of a replicated-transfer (multicast, broadcast, etc.), and guarantee the atomicity (all or none of the entities will receive the information) and the order of arrival of the information (all the entities receive the same information in the same order) in case of atomic or order replicated-transfer of information. Examples of particular situations in which this coordination problem occurs in open systems are: when computing the topology of a network, or when communicating partial results to a group of entities (fig.2), etc. In the example that we present some information must be transferred to a group of entities. The information is replicated and transferred to each one of the entities, it arrives in the same order to each entity, and in case of transmission failure it is considered as not sent. 1 1 1

2 1

Producers

Queue

Consumers

Figure 2 Communicating results to a group of entities

2.2.3

Managing Synchronization Constraints between Activities

Execution of activities in a concurrent setting must be synchronized in order to either communicate, or to share resources. Two general forms of synchronization are necessary when working with concurrent activities: Condition-Prerequisite (the beginning of an activity is constrained by some condition concerning the state of another) and Simultaneity (some activities need or cannot occur at the same time). Condition-Prerequisite is concerned with ensuring that an activity delays if necessary until a given condition is true. Simultaneity is concerned with ensuring either that critical sections of actions that access shared resources are not executed at the same time, or that a series of actions is executed as an atomic unit (the partial execution of the executed actions is not visible). A coordination process that controls the synchronization between the concurrent activities must basically: serialize concurrent execution requests, and select (by using a pre-defined execution policy) the request to be executed. An execution policy can be, for example, a mutual-exclusion policy if the activities cannot occur at the same time. A particular situation in which this coordination problem occurs is when a producer and a consumer communicate (fig 3). The producer produces items the consumer needs. The consumer cannot consume what the producer has not produced, and the producer cannot produce if the consumer does not consume. The coordination process in this case manages the synchronization between the producer and the consumer.

produce Producer

consume Consumer

Figure 3 Producer-Consumer communication


2.2.4

9.

Managing Group Decisions

It is very common that a group of entities working together are confronted with the problem of making coordinated decisions. These decisions cannot be made in isolation by one of the members, possibly because no individual has enough competence or information to decide. A coordination process that controls the group decision must: ensure that all the entities will receive an invitation to participate in the group decision, implement a decision scheme (e.g. consensus, voting, authority, etc.), announce the final decision to the group, and decide what to do in case of failures of the entities which participate (to terminate the process, etc.). A particular situation in which this kind of coordination problem can occur is in the election of a new server from a group of replicated servers (fig. 4). Replication of servers is a common strategy used to guarantee the fault tolerance of a provided service. It is appropriate when having a unique service provider for a particular kind of service is too critical for the system.When having replicated servers, if the active server goes down, the group of replicas need to decide which one will take its place.

Service Replicated Servers Clients ?

Server Down

Figure 4 Election of a new Server

3 Generic Coordination Abstractions If we analyse different solutions to a coordination problem we will find that there are some common elements that could be used to define the structure of a generic solution. In the preceding section we have discussed coordination processes that represent generic solutions to coordination problems. The coordination processes define the functionality and the imposed constraints that a generic implementation of a coordination abstraction should respect. Specific coordination abstractions for managing coordination problems in a system, can be generated by using these generic architectures of solutions. We say that: A Generic Coordination Abstraction represents a generic and reusable solution to a standard coordination problem that could be used to generate specific coordination abstractions. The coordination component framework that we are constructing will be composed of coordination components that realize these Generic Coordination Abstractions.

10.

3.1


A Generic Coordination Abstraction for Managing Shared Resources

If we analyse different solutions to the problem of management of shared resources [5], we will find that there are some common elements which define the structure of these solutions. They are: the definition of the resource, and the definition of the allocation policy. What all the solutions have in common is that they are designed to manage the allocation of a resource with certain characteristics applying a certain allocation policy (fig. 5). Some characteristics of these elements are fundamental for the specification of the solutions. For the resource they are basically: the size of the resource, and the number of concurrent entities which can access the resource at the same time. For the allocation policy they are basically: the order in which the resource is going to be assigned, the maximum allowed to each entity, if there will be priorities on the requests of the allocations, and what to do with the allocation requests that cannot be processed simultaneously (to define a waiting-queue of entities, to ignore them, etc.). There are also some fault-tolerance aspects like what to do in case of software failures (to ignore precedent request, to guarantee recovery, etc.) that have to taken into account. All these aspects define the parameters of variability of the generic coordination abstraction that could be specified and that can be used to generate specific coordination solutions. We will present a practical example of the implementation of this coordination abstraction. It will clarify the ideas that we have presented here.

Coordination Abstraction Allocation Policy Fault-tolerance Aspects

Resource Characteristics

Clients

Figure 5 Coordination abstraction for managing shared resources

3.1.1

Implementing a Generic Coordination Abstraction for Managing Shared Resources

As an example of what is being done, we show access policy components for a shared resource in a toy banking system. In this case the resource is an account database which is shared by multiple teller machines. The teller machines need to get information from the account database in order to check a client’s account. They also need to update account information if they have given money to a client. To keep the database consistent we need an access policy to regulate the multiple requests.


11.

As a solution for this regulation problem we introduce an access policy component. This solution not only provides access regulation, but also explicitness of architecture and flexibility. By having an explicit policy component, it is clear in the design that there is a policy and also which policy is chosen. Flexibility is needed to adapt easily to new requirements. We can imagine a banking system which initially starts with a basic FIFO policy, but which, as more and more teller machines get connected to the system, needs a more sophisticated policy to handle the increasing number of incoming requests. By creating a structure which allows us to change policies transparently, the banking system can be adapted without having to change other parts of the system. Our solution is shown in fig. 6. In its design we used ideas from the Command and Strategy pattern from Gamma et al. [7], and from the Active Object pattern [24]. Command execute() Resource request()

Interface request()

1

ConcreteCommand execute() 2

incoming requests

4 Resource.request();

c = new ConcreteCommand;

3

Policy

policy component

put(Command c)

FIFOPolicy

ReadersWriterPolicy

PriorityPolicy

PrConfiguration RWConfiguration

Figure 6 Access policy for shared resource.

The class Interface is the interface to the resource for the rest of the system. For every command which is invoked by an incoming request (1), a Command object is created (2). This explicit representation of commands allows us to buffer the commands, change their order, execute them in parallel, or whatever a policy needs to do with them. This is, for instance, needed for a readers/writer policy, which allows multiple readers to access the database simultaneously. These commands are then given (3) to the policy which is connected (through parameterization) to the interface. This policy handles the commands, i.e. determines when and in which order the requests can access the resource. If the command is allowed, it executes (4). A major problem with the transparency of these policies, is that policies may need application-dependent information. A readers/writer policy for instance needs knowledge about a getBalance command being a reader command and an updateBalance command being a

12.


writer command. This problem obviously violates the transparency of the proposed solution: by integrating the storage and retrieval of this application-dependent information in the Command or the Policy, the change and reuse of policies is much more difficult. We tackle this problem by introducing a configuration object. This object contains the application-dependent information of the policy. Before parameterizing the Interface with a Policy, we parameterize this Policy with a Configuration object. With this solution we are able to switch policies transparently to the rest of the system, assuming we have the correct configuration objects available. The policies can also be reused in other applications, again by configuring them with the right configuration objects.

3.2

Generic Coordination Abstractions for Managing the Transfer of Information between Activities

The transfer of information between activities (communication) constitutes the fundamental mechanism of interaction that entities can use to interact, and to induce specific behaviours or reactions on others. We can distinguish between two forms of communication: 1) communication based on the use of shared variables (variables that can be referred by more than one activity) and 2) communication based on message-passing. In both cases the operation of communication is defined as the transfer of information from a sender to a (to some) receiver(s). If we analyse the first form of communication, we find that a controlled access to the shared variable is necessary. The use of a mutual exclusion mechanism is mandatory if we want to guarantee the atomicity of the operations that access the shared variable: modification (by the sender(s)) and query (by the receiver(s)). A coordination component that implements a generic solution to this coordination problem, must guarantee the mutual exclusion of the concurrent executing activities.

Coordination Abstraction

modify

query

Receivers

Sender Shared Variable Figure 7 Coordination abstraction for managing the transfer of information using shared variables

Message-passing communication on the other hand, is based on the explicit exchange of information between the communicating entities by means of a communication medium. Two primitives are necessary to realize the exchange of information: send and receive. A coordination component that implements message-passing communication must guarantee basically the physical transfer of information between the entities, and control the synchronization between the entities that communicate (fig. 8). Depending on the type of synchronization we can have asynchronous, or synchronous message passing. The first one presupposes the existence of a communication medium with an unbounded capacity, and hence the send primitive does not


13.

block. With synchronous message-passing, communication and synchronization are tightly coupled. In particular the send primitive blocks until the receiver is ready to receive the message. The exchange of a message represents a synchronization point. Between these two forms of message-passing, we have a third one called, buffered message-passing. In this a communication medium has a fixed capacity, and hence send blocks only when the buffer is full (e.g. unix pipes). The number of receivers can determine equally other forms of message-passing communications. If the same message needs to be sent to a set of receivers we will call this form of communication multicast-message passing, and if the same message must be send it to every potential receiver on the system we will called it broadcast message-passing communication. Our coordination component must be open to implement these forms of communication. It must control the atomicity and manages possible communication faults while performing the multi-transfer operation. Another interesting form of message-passing is Generative-Communication [8], a form of communication similar to asynchronous message passing. Their main difference is that in generative communication, the entities share a single communication medium called tuple-space. With generative communication associative naming is used to distinguish different kinds of messages stored in the tuple-space, whereas in asynchronous message-passing, different communication mediums are used for different kinds of messages. This form of communication is very useful to solve some coordination problems and therefore could be (and probably will be) part of our framework. There is an additional aspect that has to be taken in account in the definition of a coordination abstraction for managing message-passing. It is, whether the communication is connection or connectionless oriented. A coordination component must additionally guarantee in the first case, the exclusive use of a communication medium for the exchanging of messages.

Coordination Abstraction

send

receive Receiver

Sender Buffer

Figure 8 Coordination abstraction for managing the transfer of information using buffered message-passing

3.2.1

Connection-Oriented Transfer of Information

In this section we give an example of a coordination component for managing connection oriented transfer of information between activities. Our solution is based on the socket mechanism the Java API provides. The functionality of this component (fig. 9) is divided in two parts: one that manages the establishment of connections, and another that manages the exchange of information considering the specific characteristics of the type of communication to be realized

14.


(one or two way, multicast, ordered, etc.). In its design we used ideas from the Acceptor and Connector patterns from Schmidt [26][27]. Connector

ConnectionMgr

Acceptor

putConnection()

SocketConnection readLine() writeLine() connect() reconnect()

client side

server side

Figure 9 Connection-Oriented transfer coordination abstraction.

On the client side we have a SocketConnection that wraps the connection once it is instantiated. It provides a clear interface to read and write information on and from the connection. The establishment of the connection is encapsulated by the Connector. On the server side we have an Acceptor, which continuously waits for Connectors that try to connect. When the Acceptor accepts a connection it gives it to a connection manager ConnectionMgr that determines what has to be done with the incoming connections. Its behaviour depends on the characteristics of the type of communication that it implements. We build some sample applications using a central server. We first show a network game, and afterwards we show with a multichat facility, how the same abstraction can be reused and reconfigured to implement a different communication abstraction. In the central server based application we put all the application dependent stuff at the client side. On top of that we put a communication layer that takes care of the transfer of information between clients. The first example shows a simple one-to-one game using a central server (fig. 10). Clients connect to the game-server which groups them by two. Connector

ConnectionMgr

Acceptor

putConnection()

TWConnectionMgr SocketConnection LineReader

readLine() writeLine() connect() reconnect()

TwoWayConnection 2

OneWayConnection

Dispatcher

coordination.communication client

server

Game

Figure 10 Network game example.

game application


15.

Additionally to the basic structure we showed in figure 9, we have in this example some extra abstractions. On the client side we have a LineReader, which reads information from the connection when there’s some available, and passes it to the application part that implements a Dispatcher interface. On the server side we have the TwoWayConnectionMgr which connects two incoming connections via a TwoWayConnection. In the multiuser chat application (fig. 11), the communication part on client side is exactly the same as in the preceding example. On the server side we reused the Acceptor, but now we configured it with another connection manager, namely the MulticastConnectionMgr. This connection manager uses a MulticastConnection: all incoming information is multicasted to all connected clients. Connector

ConnectionMgr

Acceptor

putConnection()

MCConnectionMgr SocketConnection LineReader

readLine() writeLine() connect() reconnect()

MulticastConnection

Dispatcher

coordination.communication client

server

chat application

Chat

Figure 11 Multiuser chat application.

Different types of connection-oriented communication can be realized using this component-approach, new types can be realized by reconfiguring the basic structure of our generic coordination abstraction. We have showed with our examples the way how our approach has been used to realize two different types of connection oriented communications: TwoWay and Multicast.

4 Related Work The work described in this paper is built on work from a variety of active research areas. Areas like open systems, coordination, distributed artificial intelligence, and software composition. To our knowledge, this is the first time that a component-based approach is used to solve the problem of development and evolution of coordination aspects in open systems. Most of the work done in the area of coordination is directed to the development of coordination languages (e.g. Linda [3], Gamma [2], etc.) used to describe coordination aspects in open systems [4]. One work in this line is the coordination language Objective Linda [12]. This work combines generative communication and object-based modelling to propose a coordination model for open systems. A model combining these two features covers some important requirements of open systems: dynamics, separation of concerns and encapsulation. In this model components are modelled as encapsulated and reactive entities communicating in an un-

16.


coupled way. Entities provide and use services by using a common service space. The fact that the coordination model it implements is based on a particular paradigm makes this language limited in scope. Each new coordination language proposes its own set of coordination abstractions that realizes a particular paradigm for realizing coordination. Coordination problems, however, are not always well-suited to a particular paradigm. Language based approaches are inherently limited in scope. Instead of proposing a new language, we are attempting to provide an open set of coordination components that realize various useful coordination abstractions. Two other problems characterise these language based approaches: 1) they do not provide higher coordination abstractions for managing more complex coordination problems (e.g. management of shared resources, etc.), and 2) they do not prevent the complete mixing of coordination and computation concerns. The second problem is very important because, the mixing of concerns complicates the design, the reusability and the evolution of applications. Recently there have been some works in the area of coordination that have partially tackled this problem of mixing of computation and coordination concerns. One of them is the coordination language Manifold [1]. In this language coordination modules for managing complex and dynamically changing interconnections among cooperating processes can be written. There are some problems with this approach. First, the coordination activity is reduced to the management of interconnections among processes; and second, changes in the interconnections are reduced to the some predefined possibilities specified in the application code of the coordination modules. Nevertheless the idea of defining encapsulated modules of coordination goes in the right way for supporting the reuse and evolution of the coordination aspects in these systems. Another interesting work in this line is the ConCoord software environment [10]. A ConCoord program is a dynamic collection of processes for either computation or coordination. Computation processes encapsulate sequential computations, and coordination processes encapsulate the management of the concurrency. They handle dynamic evolution of the program structure depending on conditions and execution states of processes. It presents the same kind of problems that the Manifold language. First, the coordination activity is reduced to the management of only one coordination aspect of a system: the management of its concurrency; and second, evolution is reduced to the creation and the destruction of predefined entities defined in the application code. In our approach we enforce the separation of computation and coordination concerns by the explicit definition of encapsulated coordination components. All coordination aspects of a particular solution to a coordination problem are encapsulated inside of these components. An aspect lacking in all the approaches presented before is the explicit representation of the system architecture. Darwin [13] is a configuration language for describing distributed systems that makes architectures explicit by specifying the connections between software agents. Representing this information explicitly is the key to making systems flexible, since evolution is a question of reconfiguring components and their interconnections. Our proposal makes the architecture of the system explicit. The coordination components that compose our framework define explicitly the architecture of the solution they implement. New coordination requirements can be addressed by reconfiguring the coordination component. In a different domain, the Adaptive Communication Environment (ACE)[25] is an interesting reference. One of the most important contributions of this work is the set of coordination patterns [24][26][27] that it proposes and that can be used to realize coordination components.


17.

We have presented examples of coordination components that have used some ideas from some of these design patterns. The object-oriented network programming toolkit includes a series of wrappers, class libraries and frameworks for developing communication software. Some coordination abstractions for managing coordination aspects like synchronization and transfer of information are included in this environment. The main problem with these work is its closeness. Synchronization and communication abstractions in the ACE toolkit are reduced to those provided by some common operating systems (e.g. Mutex, Condition, Semaphore, RW, pipes, FIFOs, sockets, etc.), thus limiting its scope. New coordination abstractions representing solutions to more complex coordination problems can not be included in the environment by users. Our approach is more open in this way. New coordination components realizing more complex forms of coordination can be included in our framework. Another important remark concerning this work concerns its specificity to a limited context: ACE is targetted to simplify the development of concurrent event-driven communication software. This is not the case in our coordination framework. We do not fix our coordination components to implement abstractions for one particular application style.

5 Conclusions We have presented in this paper a new approach to the problem of development and evolution of coordination aspects in open systems. A component-oriented approach has been used to specify and implement a set of coordination components representing generic solutions to coordination problems. There are two major contributions of our approach: First, we explicitly separate the coordination aspects from the computational aspects in an application (as promoted by coordination languages) in order to facilitate their development, and second, by using a component-oriented approach we tackle the problem of evolution of the coordination aspects of a system. We have included an introduction to the problem of coordination, particularly in open systems. We have analysed some definitions of what coordination is and different ways to manage it. We have proposed a systematic approach to identify coordination problems in open systems, and we have presented examples of particular situations in which these coordination problems occur. The coordination component framework that we are building includes coordination components that realize abstractions for managing some coordination problems in open systems that we have identified. We have presented some examples of simple applications using the developed coordination components. The coordination components that compose our framework have been implemented using the Java language. Java provides some basic coordination abstractions (communication and synchronization abstractions) that can be used to build more elaborated forms of coordination. This language has also been chosen because we were interested in exploring at the same time its limitations for supporting a model of components. This is work in progress. We want to explore the following aspects: • The design and implementation of distributed coordination abstractions.

18.


• The design and implementation of coordination abstractions for managing real-time coordination problems. • The design and implementation of other forms of coordination different from the management of interdependencies (e.g. coordination as an organizational activity, etc.) • The definition of a taxonomy of coordination abstractions.

Acknowledgements This research is supported by the Swiss National Science Foundation project grant 200046947.96. The authors are grateful with the members of the Software Composition Group that reviewed an earlier draft of this paper: Serge Demeyer, Theo Dirk Meijler and Tamar Richner. Our thanks also to Thilo Kielmann and Tom Holvoet for their remarks about our work.

References [1]

Farhad Arbad, “ The IWIM Model for Coordination of Concurrent Activities”, Proceedings of COORDINATION’96, P. Ciancarini and Chris Hankin (Ed.), LNCS 1061, Springer-Verlag, Cesena, Italy, 1996, pp. 34-55.

[2]

Jean-Pierre Banatre and Daniel Le Metayer, “Gamma and the Chemical Reaction Model”, Proceedings of Coordination’95 Workshop, IC Press, Londres, 1995.

[3]

N. Carriero and D. Gelernter, “Linda in Context”, Communications of the ACM, vol. 32, no. 4, April 1989, pp. 444-458.

[4]

Paolo Ciancarini, “Coordination Languages for Open System Design”, Proceedings of the 1990 International Conference of Computer Languages, New Orleans, March 12-15, 1990, pp. 252-260.

[5]

George Coulouris, Jean Dollimore and Tim Kindberg, “Distributed Systems Concepts and Design”, Addison-Wesley, 1994.

[6]

Jacques Ferber, Les Systemes-Multiagents: Vers une Intelligence Collective, Intereditions, 1995.

[7]

Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, “Design Patterns”, Addison-Wesley, MA, 1995.

[8]

David Gelernter, Nicholas Carriero, “Coordination Languages and their Significance”, Comm. ACM, vol. 35, no. 2, February 1992.

[9]

C. Hewitt, “Offices are Open Systems”, ACM Transactions Off. Inf. Syst., vol. 4, no. 3, 1986,, pp. 270-287.

[10]

A.A.Holzbacher, “A Software Environment for Concurrent Coordinated Programming“, Proceedings of COORDINATION’96, P. Ciancarini and Chris Hankin (Ed.), LNCS 1061, Springer-Verlag, Cesena, Italy, 1996, pp. 249-266.

[11]

Nick R. Jennings, “Coordination Techniques for Distributed Artificial Intelligence”, Foundations of Distributed Artificial Intelligence, G.M.P. O’Hare and N.R. Jennings (Ed.), John Wiley & Sons, 1996, pp. 187-210.

[12]

Thilo Kielmann, “Designing a Coordination Model for Open Systems“, Proceedings of COORDINATION’96, P. Ciancarini and Chris Hankin (Ed.), LNCS 1061, Springer-Verlag, Cesena, Italy, 1996, pp. 267-284.


19.

[13]

Jeff Magee, Naranker Dulay and Jeffrey Kramer, “Structuring Parallel and Distributed Programs”, Proceedings of International Workshop on Configurable Distributed Systems, London, March 1992.

[14]

Thomas Malone and Kevin Crowston, “What is coordination Theory and How Can It Help Design Cooperative Work Systems?”, Proceedings of CSCW’90, October 1990, pp. 357-370

[15]

Thomas Malone, “Organizing information processing systems: Parallels between human organizations and computer systems”, Cognition, Computation and Cooperation, W.W. Zachary and S.P. Robertson (Ed.), pp. 56-83.

[16]

Thomas Malone, Kevin Crowston, “The Interdisciplinary Study of Coordination”, ACM Computing Surveys, vol. 26,no. 1, March 1994

[17]

H. Mintzberg, “The structuring of Organizations”, Prentice-Hall, 1979.

[18]

Sape Mullender, “Distributed Systems: Second Edition”, Addison-Wesley, 1993.

[19]

Oscar Nierstrasz and Laurent Dami, “Component-Oriented Software Technology”, ObjectOriented Software Composition, O. Nierstrasz and D. Tsichritzis (Ed.), Prentice Hall, 1995, pp. 3-28.

[20]

Oscar Nierstrasz and Theo Dirk Meijler, “Research Directions in Software Composition”, ACM Computing Surveys, vol 27, no. 2, June 1995, pp. 262-264.

[21]

Oscar Nierstrasz and Theo Dirk Meijler, “Requirements for a compositional language”, Object-Based Models and Languages for Concurrent Systems, P. Ciancarini, O. Nierstrasz and A, Yonezawa (Ed.), LNCS 924, Springer-Verlag, 1995, pp. 147-161.

[22]

Oscar Nierstrasz, “Research topics in Software Composition”, Proceedings Langages et Modeles a Objects, Nancy, Oct 1995, pp 193-204.

[23]

Oscar Nierstrasz, “Formalizing Composable Software Systems : A Research Agenda”, Proceedings 1st IFIP Workshop on Formal Methods for Open Object-based Distributed Systems FMOODS’96, Chapmann and Hall, 1996, pp 271-282.

[24]

R. Greg Lavender and Douglas C. Schmidt, “Active Object: an Object Behavioral Pattern for Concurrent Programming”, Proc. Pattern Languages of Programs, September 1995.

[25]

Douglas Schmidt, “The ADAPTATIVE Communication Environment: An Object-Oriented Network Programming Toolkit for Development of Communication Software”.

[26]

Douglas Schmidt, “Acceptor: A Design Pattern for Passively Initializing Network Services”, C++ Reports, SIGS, Vol. 7, no. 8, Nov/Dec 1995.

[27]

Douglas Schmidt, “Connector: A Design Pattern for Actively Initializing Network Services”, C++ Reports, SIGS, Vol 8, no. 1, January 1996.

[28]

Mary Shaw and David Garlan, “Software Architecture: Perspectives on an emerging Discipline”, Prentice-Hall, 1996.

[29]

Gerard Tel, “Introduction to distributed algorithms”, Cambridge Press, 1994

[30]

Dennis Tsichritzis, “Object-Oriented Development for Open Systems”, Information Processing 89 (Proceedings IFIP’89), North Holland, San Francisco, Aug. 28-Sept. 1, 1989, pp. 1033-1040.

[31]

Peter Wegner, “Trade-offs between Reasoning and Modelling”, Research Directions in Concurrent Object-Oriented Programming, Gul Agha, Peter Wegner, and Akiro Yonezawa (Ed.), 1993, pp. 22-41.