Reo is a domain-specific language for programming and analyzing coordination protocols that compose individual processes into full systems, broadly construed. Examples of classes of systems that can be composed with Reo include component-based systems, service-oriented systems, multithreading systems, biological systems, and cryptographic protocols. Reo has a graphical syntax in which every Reo program, called a connector or circuit, is a labeled directed hypergraph. Such a graph represents the data-flow among the processes in the system. Reo has formal semantics, which stand at the basis of its various formal verification techniques and compilation tools.
Definitions In Reo, a concurrent system consists of a set of components which are glued together by a circuit that enables flow of data between components. Components can perform I/O operations on the boundary nodes of the circuit to which they are connected. There are two kinds of I/O operations: put-requests dispatch data items to a node, and get-requests fetch data items from a node. All I/O operations are blocking, which means that a component can proceed only after its pending I/O operation has been successfully processed. The figure on the top-right shows an example of a producers-consumer system with three components: two producers on the left and one consumer on the right. The circuit in the middle defines the protocol, which states that the producers should send data synchronously, while the consumer receives those data in alternating order. Formally, the structure of a circuit is defined as follows: Definition 1. A circuit is a triple R = ( N , B , C , t ) {\displaystyle R=(N,B,C,t)} where:
N is a set of nodes;
B ⊆ N {\displaystyle B\subseteq N} is a set of boundary nodes;
C ⊆ 2 N × 2 N {\displaystyle C\subseteq 2^{N}\times 2^{N}} is a set of channels;
t : C → T {\displaystyle t:C\rightarrow T} assigns a types to every channel. such that | I ∪ O | = 2 {\displaystyle |I\cup O|=2} , for all ( I , O ) ∈ C {\displaystyle (I,O)\in C} . If c = ( I , O ) ∈ C {\displaystyle c=(I,O)\in C} is a channel, then I is called the set of input nodes of c and O is called the set of output nodes of c. The dynamics of a circuit resemble the flow of signals through an electronic circuit. Nodes have fixed merger-replicator behavior: the data of one of the incoming channels is propagated to all outgoing channels, without storing or altering the data (i.e., replicator behavior). If multiple incoming channels can provide data, the node makes a nondeterministic choice among them (i.e., merger behavior). Nodes with only incoming or outgoing channels are called sink nodes or source nodes, respectively; nodes with both incoming and outgoing channels are called mixed nodes. In contrast to nodes, channels have user-defined behavior represented by their type. This means that channels may store or alter data items that flow through them. Although every channel connects exactly two nodes, these nodes need not to be input and output. For instance, the vertical channel in the figure on the top-right has two inputs and no outputs. The channel type defines the behavior of the channel with respect to data. Below is a list of common types:
Sync: Atomically gets data from its input node and propagates it to its output node. LossySync: Same as Sync, but can lose data if its output node is not ready to take data. Fifo⟨n⟩: Gets data from its input node, temporarily stores it in an internal buffer of size n, and propagates it to its output node (whenever this output node is ready to take data). SyncDrain: Atomically gets data from both its input nodes and loses it. Filter⟨c⟩: Atomically gets data from its input node and propagates it to its output node if the filter condition c is satisfied; loses the data otherwise.
Software engineering properties
Exogeneity One way to classify coordination languages is in terms of their locus: locus of coordination refers to where coordination activity takes place, classifying coordination models and languages as endogenous or exogenous. Endogenous models and languages, such as Linda, provide primitives that must be incorporated within a computation for its coordination. In applications that use such models, primitives that affect the coordination of each module are inside the module itself. In contrast, Reo is an exogenous language that provides primitives that support coordination of entities from without. In applications that use exogenous models, primitives that affect the coordination of each module are outside the module itself. Endogenous models are sometimes more natural for a given application. However, they generally lead to an intermixing of coordination primitives with computation code, which entangles the semantics of computation with coordination protocols. This intermixing tends to scatter communication/coordination primitives throughout the source code, making the cooperation model and the coordination protocol of an application nebulous and implicit: generally, there is no piece of source code identifiable as the cooperation model or the coordination protocol of an application, that can be designed, developed, debugged, maintained, and reused, in isolation from the rest of the application code. On the other hand, exogenous models encourage development of coordination modules separately and independently of the computation modules they are supposed to coordinate. Consequently, the result of the substantial effort invested in the design and development of the coordination component of an application can manifest itself as tangible "pure coordinator modules" which are easier to understand, and can also be reused in other applications.
… excerpt ends here. Continue reading the full article.
