Keywords

1 Introduction

Since late 70’s, the development of concurrent and distributed systems has been receiving much attention from the research community [72, 77]. Later, since 90’s, component, connector, and coordination have been key concepts exploited in different communities to manage the complexity of concurrent and distributed systems development [2, 4, 9, 17, 18, 24, 32, 37, 43, 47, 49, 52, 75, 78, 79, 83, 84, 87]. Process calculi and algebras laid the theoretical foundation for concurrency. The concept of coordination was introduced to offer software developers programming language constructs and models at a level of abstraction higher than the primitives offered by the parsimony of process algebras [3, 39]. The concept of connectors emerged in software architectures as a useful construct to facilitate communication among independently developed components.

In this paper, we discuss three different approaches within three different classes: composition in software architectures, coordination models, and programming abstractions for concurrency. These classes encompass different perspectives and solutions to face crucial challenges in developing concurrent and distributed systems. Strictly concerning the purpose of this festschrift paper, we limit our discussion to previous work by De Nicola et al. and previous work by the authors. Specifically, we focus on programming abstractions for concurrent and autonomic systems [84]; exogenous coordination [5]; and the architectural synthesis of software coordinators for the distributed composition of heterogeneous components [18].

Since these approaches are radically different in nature, it is not possible, neither would it make sense, to make a point-to-point comparison or to force a description of them by adopting a uniform writing strategy at the same level of detail. However, this paper makes an effort to discuss the three approaches with respect to the same set of characteristics of interest for the above classes: compositionality, incrementality, scalability, compositional reasoning, reusability, and evolution.

This paper is organized as follows. Section 2 preludes our discussion by collocating the three works above within the state of the art. Section 3 provides a concise, yet complete, description of the three works, which are then characterized in Sect. 5 with respect to the six dimensions defined in Sect. 4. Section 6 concludes the paper.

2 Praeludium

In this section, we give a brief account of the three approaches that we consider followed by a brief discussion on related approaches.

The first approach by De Nicola et al. [84] is based on the definition of programming abstractions for concurrent and autonomic systems. The starting point of the work is represented by the notions of autonomic components (ACs) and autonomic-component ensembles (ACEs). The defined programming abstractions permit to model their evolution and their interactions. The authors define SCEL (Software Component Ensemble Language), a kernel language for programming the behavior of ACs and the formation of ACEs, and for controlling the interaction among different ACs. These abstractions permit describing autonomic systems in terms of behaviors, knowledge, and aggregations by complying with specific policies.

The second approach essentially concerns the work conducted by Arbab as described in [5], among other references. The author emphasizes the separation between computation and coordination defining a data-flow paradigm. Arbab defines the notion of Abstract Behavior Types (ABTs) as a higher-level alternative to ADT (Abstract Data Type) and proposes it as a proper foundation model for both components and their composition. An ABT defines an abstract behavior as a relation among a set of timed-data-streams, without specifying any detail about the operations that may be used to implement such behavior or the data types it may manipulate for its realization. ABTs allows for loosely coupling and exogenous coordination that are considered as two essential properties for components and their composition. ABTs serve as the primary formal semantic model for the coordination language Reo.

The third approach that we consider is described in the work conducted by Inverardi et al. [18]. The authors provide a complete formalization of an automated synthesis method for the distributed composition and coordination of software services. The method takes as input a specification of the global collaboration that the involved services must realize. This specification is given in the form of a state machine. The methods automatically generates a set of Coordination Delegates (CDs). CDs are additional software entities with respect to the participant services, and are synthesized in order to proxify and control their interaction. When interposed among the services, the synthesized entities enforce the collaboration prescribed by the specification. The synthesized CDs are proved to be correct by construction, meaning that the resulting distributed system realizes the specification. The synthesis method is able to deal with heterogeneous services that communicate synchronously and/or asynchronously. CDs are able to handle asynchrony through 1-bounded FIFO queues.

As already introduced, beyond the above mentioned approaches, there are many other approaches in the literature that should be considered (see [85] for an early comprehensive survey). For instance, in [2], the authors define a control-flow event-based paradigm for both computation and coordination. The WRIGHT architecture description language [1] is used as a specialized notation for architectural specification. As underlining formalism, the authors embed in WRIGHT an approach based on process algebra. In fact, in [2], CSP [86] (Communicating Sequential Processes) is used by the authors in order to provide an operational formalization of the separation between computation and coordination.

A family of process calculi called “Kell calculus” is presented in [33, 34, 87, 90]. It has been intended as a basis for studying distributed (and ubiquitous) component-based programming. Essentially, the Kell calculus is an high-order extension of \(\pi \)-Calculus. Its aim is to support the modeling of different forms of process mobility (e.g., logical and physical mobility). This is done by considering the possibility to directly transmit processes as messages and not only channels (used by processes in order to communicate) as it is in \(\pi \)-Calculus.

A further approach concerns the work described in [36]. The authors propose an algebraic formalization of the structure of the interactions enabled by connectors in component-based system implemented in the BIP framework [26, 89]. It is a control-flow paradigm based on active/inactive communication ports of components.

The work described in [79] presents a modeling approach based upon the Bigraphical Reactive Systems framework developed by Milner, which consists of a bigraph together with a collection of bigraphical rewrite rules. Analogously to Kell calculus, this approach introduces mobility, locality and dynamism.

Further approaches are described in [37, 47, 75] and, as pure algebraic modeling approaches, they are theoretically very powerful although, they result to be hard to be used by practitioners.

Beyond the notational/algebraic/mathematical class of works on connector/component modeling, another interesting class of works that should be considered concerns quantitative approaches, e.g., [9, 24]. These approaches are quantitative in the sense that they are able to express, and reason about, characteristics such as the probability of an event occurring, the elapse of time, performance, QoS, etc. In particular, in [9], the work described in [5] is extended in order to take into account QoS attributes of both computation and coordination, e.g., shortest time for data transmission, allocated memory cost for data transmission, and reliability represented by the probability of successful transmission. Furthermore, this work defines a semantic model for connectors different from ABTs, i.e., it is an operational model based on a QoS extension of constraint automata [24] called Quantitative Constraint Automata. In spirit, this model is a variant of a labelled transition-system model. Other extensions of Reo are also based on the constraint-automata semantics, and allow two forms of probability distributions, continuous-time (with no nondeterminism) and discrete-time (with nondeterminism) [25].

3 Looking into the Three Cs

Within the “three Cs sphere”, the three approaches considered in this paper represent three possible ways of dealing with component-based system development, component connection and coordination. For different purposes and at different levels, these approaches target the complexity of concurrent and distributed system development, and address crucial challenges to be faced when developing component-based systems, possibly reusing existing third-party components, connecting them and coordinating their interaction.

This section provides a concise, yet complete, description of the three approaches. For each of them, we first provide an overview by summarizing notions and aspects borrowed from the corresponding original work; then, we discuss the approach with respect to the best-fitting “C”.

3.1 Software Component Ensemble Language

The aims of the work in [84] is to provide language designers with appropriate programming abstractions and constructs to deal with the development of concurrent and autonomic systems, adaptation with respect to possibly unforeseen changes of the working environment, evolving requirements, emergent behaviors resulting from complex interactions. The work in [84] is based on the two fundamentals notions of Autonomic Components (ACs) and Autonomic-Component Ensembles (ACEs), and defines programming abstractions to model their evolutions and their interactions. The authors define the Software Component Ensemble Language (SCEL) that is a programming language for programming the behavior of ACs and the formation of ACEs, and for controlling the interaction among different ACs. These abstractions permit describing autonomic systems in terms of Behaviors, Knowledge, and Aggregations by complying with specific Policies.

Overview of the SCEL’s Design Principles – ACs and ACEs serve to structure systems into independent and distributed building blocks that interact and adapt.

ACs are entities with dedicated knowledge units and resources; awareness is guaranteed by providing them with information about their state and behavior via their knowledge repositories. These repositories also can be used to store and retrieve information about ACs’ working environments, and thus can be exploited to adapt their behavior to the perceived changes. Each AC is equipped with an interface, consisting of a collection of attributes, describing the component’s features such as identity, functionalities, spatial coordinates, group memberships, trust level, response time, and so on.

Attributes are used by the ACs to dynamically organize themselves into ACEs. Indeed, one of the main novelties of SCEL is the way groups of partners are selected for interaction and thus how ensembles are formed. Individual ACs can single out communication partners by using their identities, but partners can also be selected by taking advantage of the attributes exposed in the interfaces. Predicates over such attributes are used to specify the targets of communication actions, thus permitting a sort of attribute-based communication. In this way, the formation rule of ACEs is endogenous to ACs: members of an ensemble are connected by the interdependency relations defined through predicates. An ACE is therefore not a rigid fixed network but rather a highly flexible structure where ACs’ linkages are dynamically established.

Fig. 1.
figure 1

Autonomic component ensembles

Full size image

A typical scenario that gives rise to ACEs is reported in Fig. 1. It suggests that ACEs can be thought of as logical layers (built on top of the physical ACs’ network) that identify dynamic ubnetworks of ACs by exploiting specific attributes; in the picture, these are the different colours associated to individual ACs.

The main linguistic abstractions that SCEL provides developer with for programming the evolution and the interactions of ACs and the architecture of ACEs are listed as follows.

  • Behaviors describe how computations may progress and are modeled as processes executing actions, in the style of process calculi.

  • Knowledge repositories provide the high-level primitives to manage pieces of information coming from different sources. Each knowledge repository is equipped with operations for adding, retrieving, and withdrawing knowledge items.

  • Aggregations describe how different entities are brought together to form ACs and to construct the software architecture of ACEs. Composition and interaction are implemented by exploiting the attributes exposed in ACs’ interfaces.

  • Policies control and adapt the actions of the different ACs for guaranteeing accomplishment of specific tasks or satisfaction of specific properties.

By accessing and manipulating their own knowledge repository or the repositories of other ACs, components acquire information about their status (self-awareness) and their environment (context awareness) and can perform self-adaptation, initiate self- healing actions to deal with system malfunctions, or install self-optimizing behaviors. All these self-* properties, as well as self-configuration, can be naturally expressed by exploiting SCEL’s higher-order features, namely, the capability to store/retrieve (the code of) processes in/from the knowledge repositories and to dynamically trigger execution of new processes. Moreover, by implementing appropriate security policies (e.g., limiting information flow or external actions), components can set up self-protection mechanisms against different threats, such as unauthorised access or denial-of-service attacks.

Discussion – More on the Component side, the work by De Nicola et al. addresses the challenges to develop large systems composed of a massive numbers of components, featuring complex interactions among components, as well as with humans and other systems. These complex systems are often referred to as ensembles. The complexity of the ensembles is due to their large dimension and their need to adapt to the changes of the working environment and to the evolving requirements. Self-* abilities are thus desirable to make this kind of systems autonomic, hence capable to self-manage by continuously monitoring their behavior and context, and by selecting corrective actions if needed.

Due to such an inherent complexity, today’s engineering methods and tools do not scale well, and new engineering techniques are needed to address the challenges of developing, integrating, and deploying them. As the blending of different concepts that have emerged in different fields of computer science and engineering, the work by De Nicola et al. proposes programming abstractions specific to autonomic system development, and reconcile them under a single and uniform formal semantics. Main advances brought by De Nicola et al. are (i) ability to deal with heterogenous systems and different application domains; (ii) flexibility and suitability to support adaptive context-aware activities in pervasive and mobile computing scenarios together with transparent monitoring; (iii) strict relation with component-based design, which has been indicated as a key approach for adaptive software design; (iv) flexible and expressive forms of communication and adaptation that are adequate to deal with highly dynamic ensembles; (v) strict relation with context-oriented programming, which has been advocated to program autonomic systems.

3.2 Reo Connectors

Reo [4, 6, 7] is a dataflow-inspired language for incremental construction of complex connectors by composing simpler ones, with a graphical as well as a textual syntax [45]. Every Reo connector encapsulates a concrete interaction protocol. In contrast to traditional models of concurrency, where actions or processes constitute the basic building blocks, Reo espouses and advocates an interaction-centric model of concurrency, where the only first class primitive is interaction.

Reo views components in a concurrent system as black boxes, each of which has an interface consisting of a set of ports. A port is a uni-directional means of communication through which a component exchanges with its environment by performing blocking I/O operations get and put. Because a component has access to only its own ports and Reo offers no other means of inter-process communication, components cannot communicate with each other directly. Instead, a separate construct, a connector, connects to the ports of various components and mediates the flow of data amongst them. Every connector imposes the interaction protocols that it encapsulates upon the communication of the components, exogenously (from the outside of the components, which remain oblivious to the interaction protocol that engages them).

Fig. 2.
figure 2

A typical set of Reo channels

Full size image

Overview of Reo – A complex connector in Reo is constructed as a graph whose edges comprise of primitive binary connectors, called channels, and whose vertices consist of particular synchronous dataflow components, called nodes.

A channel is a medium of communication that consists of two ends and a constraint on the dataflows observed at those ends. There are two types of channel ends: source and sink. A source channel end accepts data into its channel, and a sink channel end dispenses data out of its channel. Every channel (type) specifies its own particular behavior as constraints on the flow of data through its ends.

Although all channels used in Reo are user-defined and users can indeed define channels with any complex behavior (expressible in the semantic model) that they wish, a very small set of channels, each with very simple behavior, suffices to construct useful Reo connectors with significantly complex behavior. Figure 2 shows a common set of primitive channels often used to build Reo connectors.

A Sync channel has a source and a sink end and no buffer. It accepts a data item through its source end iff it can simultaneously (i.e., atomically) dispense it through its sink.

A LossySync channel is similar to a synchronous channel except that it always accepts all data items through its source end. This channel transfers a data item if it is possible for the channel to dispense the data item through its sink end; otherwise the channel loses the data item. Thus, the context of (un)availability of a ready consumer at its sink end determines the (context-sensitive) behavior a LossySync channel.

A FIFO1 channel represents an asynchronous channel with a buffer of capacity 1: it can contain at most one data item. When its buffer is empty, a FIFO1 channel blocks I/O operations on its sink, because it has no data to dispense. It dispenses a data item and allows an I/O operation at its sink to succeed, only when its buffer is full, after which its buffer becomes empty. When its buffer is full, a FIFO1 channel blocks I/O operations on its source, because it has no more capacity to accept the incoming data. It accepts a data item and allows an I/O operation at its source to succeed, only when its buffer is empty, after which its buffer becomes full.

More exotic channels are also permitted in Reo, for instance, synchronous and asynchronous drains. Each of these channels has two source ends and no sink end. No data value can be obtained from a drain channel because it has no sink end. Consequently, all data accepted by a drain channel are lost. SyncDrain is a synchronous drain that can accept a data item through one of its ends iff a data item is also available for it to simultaneously accept through its other end as well. AsyncDrain is an asynchronous drain that accepts data items through its source ends and loses them exclusively one at a time, but never simultaneously.

For a filter channel, or Filter(P), its pattern \(\mathtt{P} \subseteq Data\) specifies the type of data items that can be transmitted through the channel. This channel accepts a value \(d \in \mathtt{P}\) through its source end iff it can simultaneously dispense d through its sink end, exactly as if it were a Sync channel; it always accepts all data items \(d \not \in \mathtt{P}\) through its source end and loses them immediately.

Fig. 3.
figure 3

Reo nodes

Full size image

A Reo node is a logical place where channel ends coincide and coordinate their dataflows as prescribed by its node type. Figure 3 shows the three possible node types in Reo. A node is either source, sink, or mixed, depending on whether all channel ends that coincide on that node are source ends, sink ends, or a combination of the two. Reo fixes the semantics of (i.e., the constraints on the dataflow through) Reo nodes, as described below.

The source and sink nodes of a connector are collectively called its boundary nodes. Boundary nodes define the interface of a connector. Components attach their ports to the boundary nodes of a connector and interact anonymously with each other through the interface of the connector. Attaching a component to a (source or sink) node of a connector consists of the identification of one of the (respectively, output or input) ports of the component with that node. The blocking I/O operations performed by components on their own local ports, triggers dataflow through their attached connector nodes.

A component can write data items to a source node that it is attached to. The write operation succeeds only if all (source) channel ends coincident on the node accept the data item, in which case the data item is transparently written to every source end coincident on the node. A source node, thus, acts as a synchronous replicator. A component can obtain data items, by an input operation, from a sink node that it is attached to. A take operation succeeds only if at least one of the (sink) channel ends coincident on the node offers a suitable data item; if more than one coincident channel end offers suitable data items, one is selected nondeterministically. A sink node, thus, acts as a nondeterministic merger. A mixed node nondeterministically selects and takes a suitable data item offered by one of its coincident sink channel ends and replicates it into all of its coincident source channel ends. Note that a component cannot attach to, take from, or write to mixed nodes.

Fig. 4.
figure 4

Reo circuits for alternators

Full size image

The connector shown in Fig. 4(a) is an alternator that imposes an ordering on the flow of the data from its input nodes A and B to its output node C. The SyncDrain enforces that data flow through A and B only synchronously (i.e., atomically). The empty buffer of the the FIFO1 channel together with the SyncDrain guarantee that the data item obtained from A is delivered to C while the data item obtained from B is stored in the FIFO1 buffer. After this, the buffer of the FIFO1 is full and data cannot flow in through either A or B, but C can dispense the data stored in the FIFO1 buffer, which makes it empty again. Thus, subsequent take operations at C obtain the data items written to A, B, A, B, ..., etc.

The connector in Fig. 4(b) has an extra Sync channel between node B and the FIFO1 channel, compared to the one in Fig. 4(a). It is trivial to see that these two connectors have the exact same behavior. However, the structure of the connector in Fig. 4(b) allows us to generalize its alternating behavior to any number of producers, simply by replicating it and “juxtaposing” the top and the bottom Sync channels of the resulting copies, as seen in Fig. 4(c) and Fig. 4(d).

The connector in Fig. 4(d) is obtained by replicating the one in Fig. 4(b) 3 times. Following the reasoning for the connector in Fig. 4(c), it is easy to see that the connector in Fig. 4(d) delivers the data items obtained from A1, A2, A3,and A4 through C, in that order.

Semantics. Reo allows arbitrary user-defined channels as primitives; arbitrary mix of synchrony and asynchrony; and relational constraints between input and output. This makes Reo more expressive than, e.g., dataflow models, Kahn networks, synchronous languages, stream processing languages, workflow models, and Petri nets. On the other hand, it makes the semantics of Reo quite non-trivial. Various models have been developed to capture (various aspects of) the semantics of Reo, each to serve some specific purposes [55]. In this paper, we briefly describe only the ABTs [5], which constitute the primary formal semantics of Reo.

Formally, an ABT is a relation on a set of time-data-streams. ABTs yield an expressive compositional semantics for Reo where coinduction is the main definition and proof principle to reason about properties involving both data and time streams [14].

Discussion – Building upon earlier work on classical dataflow [15, 44, 56, 57], synchronous languages [30, 31, 40, 48], and Ptolemy [38, 74], interaction-centric concurrency allows treatment of protocols as concrete objects of discourse. Besides Reo, more recent work, such as BIP [16, 27], multiparty session types [51], Scribble [50, 91], and Pabble [81, 82] represent other examples of interaction-centric models that to various degrees of expressiveness and generality. Allowing arbitrary user-defined primitive building blocks and arbitrary mix of synchronous and asynchronous communication in its compositions, Reo relaxes restrictions and limitations implicit in most other above-mentioned models. See, for instance, [46] for an in-depth comparison of BIP and Reo.

The examples in Fig. 4 demonstrate how more complex connectors can be constructed by incremental composition of simpler ones. They also show how (1) arbitrary mix of synchrony and asynchrony, (2) preservation of synchrony through composition, which results in (3) propagation synchrony and exclusion though composition make Reo an expressive language. Several model checking tools are available for verification of Reo connectors [20,21,22,23, 35, 58,59,60,61, 67,68,69].

A high-level language like Reo that supports this form of protocol specification offers clear software engineering advantages (e.g., programmability, maintainability, verbatim-reusability, verifiability, scalability, etc.). The results of on-going work on compiling Reo connectors suggest that smart optimizing compilers for high-level protocol languages can generate executable code with better performance than hand-crafted code produced by programmers written in contemporary general-purpose languages with constructs of traditional models of concurrency [54]. For some protocols, existing Reo compilers already generate code that can compete with code written by a competent programmer [53].

Reo has been used for composition of Web services [12, 64, 73], modeling and analysis of long-running transactions in service-oriented systems [66], coordination of multi-agent systems [8], performance analysis of coordinated compositions [9, 10, 13, 80], modeling of business processes and verification of their compliance [11, 65, 88], and modeling of coordination in biological systems [42].

3.3 Coordination Delegates

The work in [18] is based on the notion of Coordination Delegate and aims to formalize an automated synthesis method for the distributed composition and coordination of software services or, more in general, of software components. Following a modular and reuse-based approach, the business functionality of the system is assumed to be implemented by a set of software services, possibly black-box since provided by third parties. The system to be realized – out of the set of considered services – is specified as a global collaboration that the involved services have to realize by interacting via either synchronous or asynchronous message passing. This specification is given in the form of a state machine. Starting from this specification, and accounting for the specification of the interaction protocol performed by the involved services, the synthesis method is able to automatically generates a set of Coordination Delegates (CDs). CDs are additional software entities with respect to the participant services, and are synthesized in order to proxify and control their interaction. When interposed among the services by following the rules of a well-defined architectural style, the synthesized entities enforce the collaboration prescribed by the system specification. The synthesized CDs are correct by construction, meaning that the resulting distributed system realizes the specification. CDs are able to handle asynchrony through 1-bounded FIFO queues.

Overview of the Synthesis Method – Figure 5 shows an overview of the method for the automatic synthesis of CDs that, when interposed among the participant services, control those interactions that need coordination in order to enforce the realizability [28, 29] of the specified global collaboration.

Fig. 5.
figure 5

Synthesis method overview

Full size image

The method is organized into four steps that are performed in the following order: Projection, Selection, Synthesis, and Concretization.

1: Projection – It takes as input the system specification given in terms of a state machine where transitions model possibly simultaneous message exchanges among participants. As such, the system specification describes the way participants perform their interactions from a global perspective defining the (partial) order in which the message exchanges occur. Each single message exchange involves two participants: the sender and the receiver of the message. The specification abstracts from the way participants communicate to exchange messages, e.g., synchronous communication versus asynchronous one.

Out of the specification, Projection generates a behavioral model for each participant. This model is a state machine where transitions model (sets of possibly simultaneous) actions sending or receiving message, or actions internal to the participant that are not observable from outside. Message send and receive are, instead, observable actions. Simultaneous actions serve to deal with parallel flows specified in the global collaboration and, hence, simultaneous executions. A projection represents the participant expected behavior according to the flows of message exchanges specified by the collaboration. Being derived from the system specification, also this model abstracts from the type of the send and receive actions (synchronous or asynchronous). We call this model Abstract Participant Behavior.

2: Selection – We recall that our approach is reuse-oriented, meaning that it allows to enforce system realizability in contexts in which the system is not implemented from scratch but it is realized by reusing, as much as possible, third-party services published in a Service Inventory. Services are selected from the inventory to play the roles of the abstract participants in the system specification. This calls for exogenous coordination of the selected concrete participants since, in general, we cannot access the participant code or change it.

A concrete service in the inventory comes with a behavioral specification of its interaction protocol. We call this model Concrete Participant Behavior. It is a state machine where transitions model (sets of possibly simultaneous) actions sending or receiving message, or internal actions. Similarly to the choreography specification, it can also specifies parallel flows that are joined afterwards. Differently from the Abstract Participant Behavior, for each transition, its type is specified: synchronous, asynchronous, or internal. That is, our approach does not impose constraints on the way concrete participants communicate, hence dealing with hybrid participants that can support both synchrony and asynchrony. For instance, a concrete participant could be a SOAP Web Service whose WSDLFootnote 1 interface defines both Request/Response (synchronous interaction) and One-way operations (asynchronous interaction). In order to exchange messages asynchronously, concrete participants make use of bounded message queues. Our approach does not impose constraints on the size of the participants queues.

In order to select concrete participants that can suitably play the roles of abstract participants, our approach exploits a notion of behavioral refinement in order to automatically check whether the behavior of a concrete participant \(Pi^C\) is a refinement (\(\bowtie \) in the figure) of the behavior of an abstract participant Pi. In the best case, for each abstract participant, a suitable concrete participant is found in the inventory. Otherwise, it might be the case that the set of selected participants covers a subset of the abstract participants in the specification. In this case, the abstract behavior of the remaining participants can support code generation activities to implement the missing concrete participants from scratch. Furthermore, the newly implemented concrete participant can be published in the inventory for possible future reuse.

An important consideration here is that, even in the case of limited reuse of third-party participants, our approach realizes separation of concern between the pure business logic implemented locally to each participant and the coordination logic needed for the realization of the global collaboration specified for the system. This logic is automatically generated as a set of CDs (Synthesis step). Keeping the needed coordination logic separated from the business one saves developers from writing code that goes beyond the development of the pure business logic internal to single participants. This allows developers to realize the specified system, without requiring any specific attention to what concerns coordination aspects. This aspect permits practitioners to develop the specified distributed system according to their daily development practices.

3 and 4: Synthesis and Concretization – The Synthesis step takes as input the system specification and automatically generates a set of CD Abstract Behavior models. Similarly to the Abstract Participant Behavior, each of them is a state machine where transitions model (sets of possibly simultaneous) actions sending or receiving message, or internal actions. These actions are related to the standard communication performed to achieve the choreography business logic. Differently from the Abstract Participant Behavior, there are also transitions modeling the synchronous exchange of coordination/synchronization messages. These actions model additional communication required to realize the coordination logic that is needed to enforce the realizability of the specified global collaboration. Standard communication takes place between a CD and the participant it controls and supervises, or directly among participants in case coordination is not required. When needed, additional communication messages are exchanged among the involved CD.

The Synthesis step is performed after a set of suitable concrete participants is obtained. Since the CD Abstract Behavior is generated out of the system specification, it abstracts from the way the supervised participants communicate (synchronously or asynchronously). This information will be added by the Concretization step that enriches the CD Abstract Behavior to achieve the so called CD Concrete Behavior.

Fig. 6.
figure 6

Collaboration-based architectural style (a sample instance of)

Full size image

For the set of synthesized CDs, correctness by construction means that when they are composed with the selected participants, the behavior of the resulting system realizes the specified global collaboration. That is, the generated CDs enforce by construction the realizability of the specified collaboration. Leveraging results on choreography realizability and its decidability from the work in [28, 29], to correctly deal with asynchrony, the concrete CDs (Concretization step) in the controlled system make use of 1-bounded message queues. According to a predefined architectural style, CDs are interposed only among the participants needing coordination. Figure 6 shows an instance of the architectural style underlying our synthesis method.

CDs perform coordination (i.e., additional communication in the figure) of the participants interaction (i.e., standard communication in the figure) in a way that the resulting collaboration realizes the specified system. According to the type of actions performed by the concrete participants, standard communication can be synchronous or asynchronous. Additional communication is always synchronous. It is worth to note that CDs coordinate the interaction among the participants only when it is strictly needed for realizability enforcement purposes. That is, some participants are left free to communicate directly on those interactions that do not prevent the realizability of the specified global collaboration. Furthermore, depending on the specified collaboration, CDs do not necessarily require to be connected one to each other.

Discussion – Last but not least, on the Coordination side, the work by Inverardi et al. targets the development of reuse-based concurrent and distributed systems, from specification to composition and coordination code synthesis. The approach finds its most effective application in the distributed computing environment offered by the current Internet, which is increasingly populated by a virtually infinite number of software services that can be opportunistically composed to realize more complex and powerful distributed applications.

According to John Musser, founder of the ProgrammableWebFootnote 2, the production of application programming interfaces (APIs) growths exponentially and some companies are accounting for billions of dollars in revenue per year via API links to their services. The evolution of today Internet is expected to lead to an ultra large number of available services, hence increasing their number from 104 services on 2007 to billions of services in the near future. This situation radically changes the way software will be produced. Modern service-oriented systems will be more and more often built by reusing and assembling existing pieces of software, exposed through their APIs. Thus, the ability to automatically compose and coordinate these pieces of software enables the productive construction of innovative and revolutionary everyday-life scenarios within smart cities and related software ecosystems [76].

Most of the existing approaches to software composition are heavily based on central coordination. A centralized approach composes multiple components into a larger application, in which one component centrally coordinates the whole system interaction. The approach by Inverardi et al. permits to describe the interactions among the different system parties from a global perspective. It permits to model a peer-to-peer communication by defining a multiparty protocol that, when put in place by the cooperating parties, allows reaching the overall goal in a fully distributed way. In this sense, it differs significantly from a centralized approach, where all participants (but one) play the passive role of serving requests. Future software systems will be increasingly composed of active entities that, communicating peer-to-peer, proactively make decisions and autonomously perform tasks according to their own imminent needs and the emergent global collaboration. Each involved party knows exactly when to execute its operations and with whom to interact. The system execution becomes a collaborative effort focusing on the exchange of messages among several business participants to reach a common global goal. Thus, (i) the ability to reuse, compose and coordinate existing pieces of software are all basic ingredients to achieve this vision; (ii) automated supported is needed to realize correct-by-construction coordination logic.

4 Characteristics of Interest

The approaches presented in previous sections will be characterized in next section by using the six characteristics of interest defined in the following.

  • Compositionality: this characteristic concerns the ability to compose a system in a hierarchical way out of simpler components/sub-systems and, roughly speaking, it does not matter the way we conduct this hierarchical construction, the result is always equivalent. This means that the system construction process is based on a composition operator ‘\(*\)’ that is associative, i.e., for all x, y, z then \(x*(y*z) \equiv (x*y)*z\). Compositionality is crucial for system analysis purposes since it may improve the efficiency of the analysis.

  • Incrementality: incrementality is implied by compositionality but the former does not imply the latter. This characteristic concerns hierarchical system construction. However, differently from compositionality, the associativity property is not required. Icrementality is another crucial aspect for system design purposes since it promotes reuse. It is implied by the existence of a composition operator that hides the internal details of the composition and exposes its observational (external) behavior.

  • Scalability: also scalability is implied by compositionality and it refers to the ability for a composition to scale to systems with an increasing number of components (i.e., systems of systems).

  • Compositional reasoning: this characteristic is related to compositionality but not necessarily. It refers to the ability to infer properties held by the whole by locally checking properties held by its constituents. This characteristic promotes efficient system analysis by performing local checks instead of a global one, hence facing complexity issues in some cases.

  • Reusability: this characteristic concerns the reuse degree of components/sub-systems. A sub-system can be: (i) reusable in any context (i.e., it is context-free), (ii) parameterized with respect to an abstract characterization of a set of contexts and, hence, reusable only in some contexts (i.e., it is partially context-free), or (iii) not reusable at all (i.e., it is not context-free) since it is tailored to a specific context.

  • Evolution: this characteristic refers to the ability to express and deal with dynamicity and reconfiguration, two aspects that promote system evolution. It is related to programming constructs useful to model specific forms of system evolution.

Note that the characteristics of interest above must be considered to be general in nature and, as such, in the following are inflected in different ways and interpreted according to the purposes of the three approaches.

5 Matching the Characteristics of Interest

In this section, we characterize the approaches described in Sect. 3 with respect to the characteristics of interest introduced in Sect. 4. The results of the characterization are summarized in the tables below, and discussed just after in the following subsections.

We make use of “Yes”, “No”, and “Limited” to rank at a glance how the considered approaches match the characteristics of interest. Obviously, “Yes” and “No” are used to indicate that an approach enjoys or does not enjoy at all, respectively, the ability/property associated to the indicated characteristic. “Limited” is used to indicate either limited or constrained (i.e., if some assumptions hold) support for the indicated characteristic (Tables 1 and 2).

Table 1. Matching the characteristics of interest (Part 1)
Full size table
Table 2. Matching the characteristics of interest (Part 2)
Full size table

5.1 Software Component Ensemble Language Characterization

The main benefits of SCEL can be summarized as follows with respect to the characteristics of interest introduced in Sect. 4.

  • Compositionality: as formalized in [84], SCEL builds systems by composing in parallel subsystems/components in a process algebra style. The parallel composition operator is both commutative and associative, hence directly achieving incrementality and compositionality.

  • Incrementality: it is directly implied by compositionality.

  • Scalability: systems programmed in SCEL are able to self-manage by continuously monitoring their behavior and their working environment and by selecting the actions to perform for best dealing with the current status of affairs. The self-* properties supported by SCEL allows developer to overcome typical scalability issues of ensembles, by improving their development, integration and deployment.

  • Compositional reasoning: compositional reasoning is not explicitly discussed in [84]. However, it is shown that SCEL supports the verification of reachability properties such as checking the probability of reaching a configuration where a given predicate on collected data is satisfied within a given deadline. The fact that a SCEL system is built by means of an associative composition operator and its constituents are well-understood, independent and distributed suggests that compositional reasoning might be supported at least for such reachability properties.

  • Reusability: SCEL supports different forms of reusability. It defines abstractions to program behaviors (ACs) and aggregations (ACEs) and its syntax is parametric with respect to knowledge and policies. Thus, reusability of ACs and ACEs with respect to different approaches to knowledge handling and policies specification is supported. Similarly to what is done by the object-oriented paradigm, SCEL components are exposed through their interface that allows developers to control the access to their internal knowledge, policies and processes. Thus, another form of reusability that is directly supported concerns the one achievable through subtyping. Furthermore, SCEL provides high-order features to store/retrieve the code of processes in/from the knowledge repositories and to dynamically trigger the execution of new processes.

  • Evolution: as briefly discussed above, SCEL components are self-aware and context-aware and enjoy a number of self-* properties, e.g., they are capable to perform self-adaptation and self-reconfiguration. Thus, dynamic evolution is completely supported by the programming abstractions provided by the language.

5.2 Reo Connectors Characterization

For what concerns Reo, main benefits are as follows:

  • Compositionality: Reo connectors are fully compositional. Starting with a set of (user-defined) primitive binary connectors—i.e., channels—Reo’s composition rules, manifested as nodes, hierarchically construct more complex connectors. Examples in Figs. 3 and 4 demonstrate this property. Composition in Reo is associative.

  • Incrementality: This property is impled by Reo’s compositionality.

  • Scalability: This property is impled by Reo’s compositionality. Figure 4 serves as an example that demonstrates scalability.

  • Compositional reasoning: Hiding the internal nodes of a connector, e.g., the exclusive router in Fig. 4(a), simplifies its semantics to the behavior of the connectors that is externally observable through its boundary nodes which comprise its interface, e.g., \( XRout (\langle \alpha , a\rangle ; \langle \beta , b\rangle , \langle \gamma , c\rangle )\), above. Once this behavior is verified, using this simplified semantcs avoids the need to repeat in-situ re-verification of its internal details whenever the connector is used as a sub-connector in a construction.

  • Reusability: Figures 3 to 4 demonstrate verbatim reusability of Reo connectors.

  • Evolution: Reo offers operations to dynamically reconfigure the topology of its connectors, thereby changing the interaction protocol of a running application. A semantic model for Reo cognizant of its reconfiguration capability, a logic for reasoning about reconfigurations, together with its model checking algorithm, are presented in [41]. Graph transformation techniques have been used in combination with the connector coloring model to formalize the dynamic reconfiguration semantics of Reo circuits triggered by dataflow [62, 63, 70, 71].

5.3 Coordination Delegates Characterization

The main benefits of the synthesis method, and of using the notion of Coordination Delegate for distributed coordination, can be summarized as follows.

  • Compositionality: the composition operator that is used to model the coordination logic of the controlled system, i.e., the parallel composition of the synthesized CDs, is based on a enhanced version of the synchronous product of LTSs that is able to deal with aptly defined synchronization messages (additional communication in Fig. 6) that are exchanged synchronously among the CDs in different ways (one-to-one, one-to-many, many-to-one, or many-to-many interactions). Compositionality can be straightforwardly achieved by making the non-synchronized communication observable from outside. This means that the coordination logic can be modeled by composing in parallel the CDs in an incremental way and it does not matter the order in which the composition is performed.

  • Incrementality: it is directly implied by compositionality.

  • Scalability: concerning the CDs synthesis method, the experimental example discussed in [18] show that: (i) the “performance” of the CDs scale, meaning that they are not affected when the number of system consumers increases; (ii) the time required for executing the needed distributed coordination logic is neglectable with respect to the overall collaboration execution time, hence confirming that the CDs enforces the specified global collaboration effectively and efficiently.

  • Compositional reasoning: the coordination logic synthesized by the method supports compositional reasoning for verifying a global property of the controlled system by just performing local checks. Each check considers: (i) a projection (similarly to what is done in step 1) of the property with respect to a set of participants; and (ii) a projection of the coordination logic with respect to the same set of participants. Both (i) and (ii) provide local (to each participant) models of the property and local models of the coordination logic, respectively. Standard model-checking techniques can be then used to singularly check each projection of the property against the related projection of the coordination logic.

  • Reusability: the abstract CDs as synthesized after step 3 (Synthesis) of the method are concrete services independent since they are generated by only looking at the global collaboration specification. This means that, as long as the interaction protocol of the selected concrete participants refines the one of the corresponding abstract participants in the specification, the generated abstract CDs can be reused and only their Concretization (step 4) need to be performed again. Thus, we can conclude that reusability is achieved, although in a limited form.

  • Evolution: in another recent work [19] from the authors of [18], which is based on a slightly revised version of the summarized synthesis method, a novel global collaboration specification is presented where the designer can specify the so called variation points. They are points in the specification that can be realized by alternative collaborations. Each alternative can be dynamically enabled/disabled during system execution depending on the “sensed” context. The CDs that are automatically synthesized out of this new specification are thus able to deal with this (limited) form of dynamic evolution by performing not only exogeneous distributed coordination, as already discussed above, but by also handling the enabling/disabling of the different specified alternatives.

6 Conclusions

Component, connector, and coordination have been key concepts exploited in different communities to manage the complexity of concurrent and distributed system development.

In this paper we discussed three approaches within three different classes: composition in distributed software architectures, exogenous coordination models, and programming abstractions for concurrent and autonomic systems. These classes encompass different perspectives and solutions to face crucial challenges in developing concurrent and distributed systems.

Our discussion considered previous work by De Nicola et al. about the SCEL language [84] for developing autonomic systems, and previous work by the authors about Reo connectors [5] for achieving exogenous coordination and distributed Coordination Delegates [18] for the distributed composition of heterogeneous components.

The approaches have been discussed with respect to some characteristics of interest for the above classes: compositionality, incrementality, scalability, compositional reasoning, reusability, and evolution.

All the three discussed approaches have been found to be representative for the three classes above since they support to some extent all the six dimension of interests for the engineering and development of concurrent and distributed systems.