Composing distributed applications through generative communication

Component-oriented approaches to software development aim to support cost-effectiveness in building applications. Components are defined as reusable entities. In this paper, we present CO3PS, a software development method for building agent-based software. Agents coordinate through generative communication. We employ generative communication to define reusable CO3PS components. Components are entities that export object spaces, i.e. places from which they can retrieve data objects and in which they can put data objects. Components can be reused by assembling them with other components through defining a mapping of their respective object spaces. The high degree of reusability that is achieved is due to the anonymous and uncoupled nature of generative communication. 1 I n t r o d u c t i o n Various terms referring to the words component or composition have been introduced recently. The marketing value of such terms is undoubtedly one important reason, as these words have a connotat ion of "support for distribution" and "reuse" and hence for cost-effective software development. Two categories of what can generally be called component-related approaches can be distinguished. A first category is concerned with s u p p o r t i n g c o m m u n i c a t i o n between software entities that may be distributed over several hosts in a network environment. As object technology has evolved rapidly over the past decade, recent proposals in this category focus on objectto-object communication. Components in this category are hence objects, while the term composition refers to the fact that distributed objects can communicate easily, i.e. with a syntax and semantics that resemble object communication in a non-distributed environment. This is the basic starting point for systems like CORBA [Obj93], the ISO reference model of open distributed processing (RMODP) [ISO95] and Java's RMI (Remote Method Invocation) lAG96]. These approaches heavily rely on remote references. Such systems are vulnerable for dangling references and require non-trivial naming schemes: A second category of component-related approaches concerns techniques for developing reusable software, mostly referred to as "component-oriented software development". The underlying philosophy is the following. System requirements typically change frequently. Class hierarchies are the soul reuse mechanism supported by object-oriented languages, but it is obvious that this does not suffice for all reuse purposes. Components are defined as generic "entities that are designed to be composed and reused" [ND95]. Component-oriented software development methods need to define components as well as composition techniques. Composition allows to combine existing components in order to constitute more complex components or applications. Only few approaches are thoroughly discussed in the current literature. E.g. components in Darwin [MK96] (as well as in related approaches that are called "Architectural Description Languages") are entities for which input and output ports are identified. A composition of components consequently is the result from bindings between input and output ports of the composite entities of the component. In this paper, we propose a definition of components and composition mechanisms as part of a component-oriented software development method, called C03PS. C03PS is based on genera t ive communica t ion . Generative communication allows to achieve high reusability of components and system openness (systems can allow fragments of software to cooperate easily and successfully with new, a priori unknown entities). This paper is organised as follows. In Section 2, we describe generative cominunication. We indicate the main advantages of this coordination model, and illustrate it. Section 3 presents principles of C03PS, including definitions of agents, passive objects, agent coordination and configurations. Then we define components and composition within C03PS in Section 4. We distinguish between static composition, which shares its goals with so-called architectural description languages (ADLs), and dynamic composition, which denotes a run-time mechanism for assembling software entities. We illustrate components through an example of a master/worker setting. Finally, Section 5 presents concluding remarks. 2 G e n e r a t i v e Communica t ion Generative communication is a communication paradigm that is extensively being researched in the area of coordination [Cia90, MC94, GC92]. In generative communication, communicating entities do not exchange messages directly, but through a shared data space. Concurrent entities can drop (or "generate") items in the data space, and others can retrieve items from the data space using associative matching. This way of communication inherently uncouples communicating processes. A sender of a data item does not directly contact anothe.r party, and a reader only contacts the shared space when it actually requires the data. The reader does not even have to exist at the time of generation. This leads to the other major advantage of generative communication: the active entities are able to communicate although they are anonymous to each other. This uncoupled and anonymous communication style directly contributes to the design of parallel and distributed applications: uncoupled communication allows to abstract from details (such as identification and interface) of the entities that are cooperating. Instead, focus is on the coordination data that each entity requires and produces. Due to these advantages, coordination models based on generative communication are superior to message passing or trader-based schemes because these both rely on knowledge about a receiver's or server's identification. PfinOob Printer PrinUob Creator Printer Creator < shared data space > ~ Figure 1: A producer/consumer setting using generative communication. Figure 1 presents a situation for a producer/consumer setting using generative communication. A number of producer entities (called PrintJobCreators) repeatedly generate items (print jobs) that need to be consumed (printed). Consumer entities (Printers) repeatedly retrieve items from the data space and consume these. The behaviour of either entity is independent of the name or the type of the other. If, for example, another Printer is presented, it can seamlessly be added to the system without requiring existing entities to be changed. Also, if an existing Printer is eliminated, this will not affect the behaviour of the PrintJobCreators, as these do not have a direct or indirect reference to it. Linda [GC92] is a generative coordination language. It supports a minimal set of language primitives for storing and retrieving data items from a data space. 3 C o m p u t a t i o n and Coord ina t ion in C03pS C03pS [Ho197] is an object-oriented method and execution environment for developing distributed applications, based on generative communication. Distributed applications are modelled as sets of cooperating active objects, called agents. Agents perform computations by creating and manipulating passive object. Passive objects are not shared between agents and "do not have an autonomous behaviour. The CO 3pS coordination model can shortly be explained as follows. Each agent is attached to one or more object spaces. Object spaces are particular objects which may be shared amongst agents. Agents communicate by exchanging passive objects through object spaces. They use interface operations that are defined on object spaces to achieve this. C03P5 enhances Linda mainly in three ways: ® object matching: contrary to Linda, where matching of items in the shared data space is based on the contents of record fields, object matching in C03ps is based on object types and the predicates defined by the corresponding type interfaces; the items that entities (agents) can put and retrieve from object spaces are (passive) objects; • non-blocking multi-set operations on object spaces: the operations defined on the object spaces (mainly insertion and retrieval of objects) are annotated with a time-out value; this is necessary to cope with system failures, which are not unlikely in open distributed systems; moreover, the operations are extended such that multi-sets of matching objects can be inserted in or retrieved from object spaces atomically. • multiple object spaces: having only one object space is not feasible mainly for two reasons: scalability (for a huge set of agents, one global sharedblackboard is untenable from a practical point of view) and communication structure (using one blackboard as the communication medium for multiple groups of closely related agents imposes undesirable complexity); since object spaces are the forum for communication between objects, multiple object spaces may be used for separate goals, i.e. closely related objects should use the same object space (see Figure 2); a setting consisting of several agents and object spaces is called a C03ps configurat ion.