Handshaking Protocol for Distributed Implementation of Reo

Handshaking Protocol for Distributed Implementation of Reo N. Kokash Niels Bohrweg 1, 2333 CA Leiden, The Netherlands [email protected] Reo, an exogenous channel-based coordination language, is a model for service coordination wherein services communicate through connectors formed by joining binary communication channels. In order to establish transactional communication among services as prescribed by connector semantics, distributed ports exchange “handshaking” messages signalling which parties are ready to provide or consume data. In this paper, we present a formal implementation model for distributed Reo with communication delays and outline ideas for its proof of correctness. To reason about Reo implementation formally, we introduce Timed Action Constraint Automata (TACA) and explain how to compare TACA with existing automata-based semantics for Reo. We use TACA to describe “handshaking” behavior of Reo modeling primitives and argue that in any distributed circuit remote Reo nodes and channels exposing such behavior commit to perform transitions envisaged by the network semantics. 1 Introduction Service-oriented systems (SOS) are composed of autonomous services deployed on remote machines and accessed through the network. Reo coordination language [1] is an extensible notation for compositional modeling and execution of SOS. Services that have no prior knowledge about each other communicate through channel connectors which guarantee that each participant, service or client, receives right data at the right time. Each channel is a binary function that imposes synchronization and data constraints on input and output messages. Channels can be composed to realize complex behavioral protocols, including multi-party synchronous rendezvous. This approach enables models that are both concise and compositional, but it also makes operational semantics for Reo non-trivial. The most basic semantic model for Reo is constraint automata (CA) [6]. States or locations in CA represent configurations of data stored in the buffers of Reo networks, while transition labels are composed of (i) sets of channel ends where dataflow is observed simultaneously, and (ii) data constraints necessary to trigger such transitions. The CA for a Reo connector can be computed as a product of the CA for its parts (sub-connectors or channels). CA is the theoretical basis for validation and verification tools for Reo, which are integrated in a framework known as the Extensible Coordination Tools (ECT)1 . The Quality of Service (QoS) of a SOS depends on the quality of its components, efficiency of the “glue code” that coordinates individual services, and quality of the communication network. To evaluate the QoS of SOS coordinated by Reo, we need to estimate time to deliver input messages supplied by services to the input ports of the circuit to their consumers - services listening to the output ports of the circuit. The early semantic models for quantitative Reo [4, 3] assumed that delays in channels do not affect the operational semantics of Reo. This assumption is not realistic and limits the degree of concurrency in the presence of transactions with different durations. Hence, a more refined semantic model for Reo [16] was introduced to solve this problem. 1 http://reo.project.cwi.nl/ Submitted to: FOCLASA 2014 c N. Kokash This work is licensed under the Creative Commons Attribution License. 2 Handshaking Protocol for Distributed Implementation of Reo B A B A Sync LossySync A B Filter B A FIFO A B Transform B A A SyncDrain A B C Merger A B AsyncDrain B C Replicator Figure 1: Graphical representation of basic Reo channels and nodes Distributed Reo ports exchange technical messages signalling the readiness of coordinated services to provide or consume data. It has been recognized that the implementation of Reo should be distributed to avoid performance bottlenecks [21]. The existing semantic models for Reo focus on the description of the observable dataflow and are not suitable for the implementation and QoS evaluation. In this paper, we present a formal coordination protocol that can serve as foundational basis for distributed time-aware Reo implementation. One of the main issues is to decide which requests are considered simultaneous and should synchronize on each execution cycle. In our approach, we propose to use a timeout which each node in a network should wait for to acquire the information about pending requests on remote ports and decide which transition to fire. The timeout is chosen to guarantee that the information about the communication requests on boundary ports is propagated through the circuit. The remainder of this paper is organized as follows. In Section 2, we explain the basics of Reo. In Section 3, we describe a semantic model for Reo used and extended in this paper. In Section 4, we explain the objectives of our work. In Section 5, we present implementation semantics for basic types of Reo nodes and channels. In Section 6, we explore the properties of our approach. Section 7 overviews related work. Finally, Section 8 concludes the paper and outlines future work. 2 Reo Coordination Language Reo is a coordination language in which components and services are coordinated exogenously by channel-based connectors [1]. Connectors are graphs where the edges are user-defined communication channels and the nodes adhere to fixed routing rules. Channels in Reo are entities that have exactly two ends, also referred to as ports, which can be either source or sink ends. Source ends accept data into, and sink ends dispense data out of their channel. Although channels can be defined by users, a set of basic Reo channels (see Figure 1) suffices to implement most common workflow patterns [5]. Among these channels are (i) the Sync channel, which is a directed channel that accepts a data item through its source end if it can instantly dispense it through its sink end; (ii) the LossySync channel, which always accepts a data item through its source end and tries to instantly dispense it through the sink end. If this is not possible, the data item is lost; (iii) the SyncDrain channel, which is a channel with two source ends that accept data simultaneously and loses them subsequently; (iv) the AsyncDrain channel, which accepts data items only through one of its two source channel ends at a moment in time and loses it; and (v) the FIFO channel, which is an asynchronous channel with a buffer of capacity one. For data manipulation, Reo introduces the Filter channel. which always accepts a data item at its source end and synchronously passes or loses it depending on whether or not the data item matches a certain predefined pattern or data constraint, and the Transform channel, which applies a user-defined function to the data item at its source end and synchronously yields the result at its sink end. Channels can be joined together using nodes. A node can be a source, a sink or a mixed node. Source and sink nodes form the boundary nodes of a connector to enable the interaction with its environment. 3 N. Kokash Source nodes act as synchronous replicators, and sink nodes as non-deterministic mergers. A mixed node combines these two behaviors by atomically consuming a data item from one of its sink ends at the time and replicating it to all of its source ends. Often two other nodes, route and join, are used to model non-deterministic routing and synchronization of flow, respectively. The router can be constructed from basic Reo channels while the join node is a shorthand notation for a component that forms a tuple from data items received from several channel sink ports. Channels can also differ at the level of their QoS. In quantitative Reo [4], channels are characterized by a set of associated QoS parameters such as communication delays or cost. We recognize two types of communication delays: handshaking delay, or time to decide whether the connector can satisfy the I/O request on its ends, and data transfer delay, or the time needed to transfer the data accepted by the circuit. 3 Semantic models for Reo The semantics of any Reo connector can be better understood in terms of a specific semantic model and its appropriate translation into that model. The most basic semantic model for Reo is constraint automata (CA) [6]. Transitions in CA are labeled with sets of ports that fire synchronously and data constraints on these ports. For example, a CA dA =dB ,{A,B} for the Sync channel with port ends A and B contains one state (s0 ) and one transition s0 −−−−→ s0 . The FIFO channel with ports A and B is described by a CA with two states corresponding to an empty d=dA ,{A} dB =d,{B} buffer (s0 ) and a full buffer (s1 ), and transitions s0 −−−−→ s1 and s1 −−−−→ s0 . The behavior of any Reo circuit can be computed using the product of CA of its basic channels. The hiding operator is introduced to abstract from unnecessary details such as dataflow on the internal ports [6]. Timed constrained automata (TCA) [2] represent CA with clock assignments and timing constraints. The semantic models for Reo have been extended to compositionally compute QoS [4, 3], including communication delays in the circuit. It was assumed that delays do not affect operational semantics of the circuit and QoS labels were added to the transitions of basic CA. However, an example in [16] shows that such approach limits concurrency in the circuit. Action constraint automata (ACA) were introduced to overcome this issue [16]. ACA distinguish several kinds of actions triggered on channel ports to signal the state changes of the channel: Definition 3.1 (ACA [16]) An action constraint automaton A = (S, N , →, s0 ) consists of a set of states S, a set of action names N derived from a set of port names M and a set of admissible action types T , a transition relation → ⊆ S × 2N × DC × S, where DC is the set of data constraints over a finite data domain Data, and an initial state s0 ∈ S. An ACA model proposed in [16] uses the set of action types T1 = {b, u}, where b stands for the ‘block’ and u stands for the ‘unblock’ actions to model synchronous channels with data transfer delays: when a channel is blocked, it does not accept new I/O requests. ACA is the generalization of CA, and CA can be seen as ACA with one action type: data flow through a Reo node. To reason about the correctness of ACA as semantic models for Reo, we introduce a refinement relation for ACA with various action types (in a specific case, for ACA and CA as the latter is equivalent to the ACA with one action: observation of dataflow on Reo ports). For simplicity we omit data constraints in the rest of this paper and focus on ACA synchronization constraints. First, we need to be able to say whether automata with various observable actions describe the same Reo circuit or not. Thus, we 4 Handshaking Protocol for Distributed Implementation of Reo introduce an action renaming operator to unify sets of action names, show its compositionality and then define a weak bisimulation relation to compare ACA with renamed actions. Proofs for the following properties can be found in [17]. Definition 3.2 (Action renaming) For any A = (S, N , →, s0 ), let ρ (A , R) be an action renaming operator where R is a set of renamings in the form x → y, x ∈ H ⊆ N , y = ρ (x), ρ : H → H ′ ⊆ N ′ . ρ (A , R) = (S, N ′ , →′ , s0 ) is an ACA such that for any (s, N, s′ ) ∈→ there exists (s, N \ H ∪ ρ [N ∩ H], s′0 ) ∈→′ . Proposition 3.1 (Commutativity of renaming and hiding) ρ (hide(A , K), R) = hide(ρ (A , R), (K \ H) ∪ ρ [K ∩ H]). For H ∩ K = 0/ it holds that ρ (hide(A , K), R) = hide(ρ (A , R), K). As in [18], we use the port synchronization function γ as follows: we write N1′ for N1 \γ1 [N ] and N2′ for N2 \γ2 [N ]. If, for subsets N1 ⊆ N1 , N2 ⊆ N2 , it holds that γ1−1 [N1 ] = γ2−1 [N2 ] we write N1 |γ N2 = (N1 ∩ N1′ ) ∪ γ1−1 [N1 ] ∪ (N2 ∩ N2′ ). Hence, N1 |γ N2 is the union N1 ∪ N2 but with the parts of N1 and N2 that are identified via γ1 and γ2 replaced by the shared names γ1−1 [N1 ] = γ2−1 [N2 ]. The following proposition states that the action renaming is compositional provided that in the product of ACA we rename the set of synchronized actions that is obtained from the sets of renamed actions in the original automaton: Proposition 3.2 (Compositionality of action renaming) Let A1 = (S1 , N1 , →A1 , s10 ) and A2 = (S2 , N2 , →A2 / Let also γ : N → N1 ×N2 be an action , s20 ) be two ACA with disjoint sets of action names, N1 ∩N2 = 0. synchronization function defined as γ (n) = (γ1 (n), γ2 (n)), where γ1 : N → N1 , γ2 : N → N2 is a set of injective functions that map action names from the new set N into action names from the initial sets N1 and N2 , N ∩ (N1 ∪ N2 ) = 0. / Given sets of renamings R1 : {x → y = ρ1 (x), ρ1 : H1 → L1 , H1 ∈ N1 } and R2 : {x → y = ρ2 (x), ρ2 : H2 → L2 , H2 ∈ N2 }, for A1 and A2 , respectively, and a set of renamings R = {x → y = ρ (x)} for their product, where   ρ1 (x) ρ (x) = ρ2 (x)   f (ρ1 (x1 ), ρ2 (x2 )) x ∈ H1 ⊆ H1 |γ H2 x ∈ H2 ⊆ H1 |γ H2 x = γ1−1 (x1 ) = γ2−1 (x2 ), x1 ∈ H1 , x2 ∈ H2 it holds that ρ (A1 ⊲⊳ γ A2 , R) = ρ (A1 , R1 ) ⊲⊳ ω ρ (A2 , R2 ). Here ω : M → M1 × M2 , is an action synchronization function for the renamed actions defined as ω (n) = (ω1 (n), ω2 (n)), ω1 : M → M1 , ω2 : M → M2 , M = ρ [H1 |γ H2 ] ∪ N \ (H1 |γ H2 ), M1 = ρ [H1 ] ∪ N1 \ H1 , M2 = ρ [H2 ] ∪ N2 \ H2 , γ1 (n) = n1 ∧ γ2 (n) = n2 iff ω1 (ρ (n)) = ρ (n1 ) ∧ ω2 (ρ (n)) = ρ (n2 ). Note that hiding can be seen as renaming to unobservable action τ . Hence, it is compositional under the same conditions. We define traces for ACA in a usual way: a finite or infinite sequence of transitions N0 N1 N2 r = s −−−−→ s1 −−−−→ s2 −−−−→ s3 ... 5 N. Kokash is an s-trace in ACA. Let S∗ be the set of all finite sequences over a set S. Given finite sequences σ1 and σ2 , we denote their concatenation σ1 · σ2 . If for some ACA there exists an s-trace N1 0/ 0/ N2 0/ N3 0/ s −−−−→ s1 −−−−→ s2 −−−−→ s3 −−−−→ s4 −−−−→ s5 −−−−→ s6 −−−−→ s′ , N1 ·0· / 0·N / 2 ·0·N / 3 ·0/ where N1 , N2 , N3 ⊆ N are sets of actions representing ACA labels, we write s −−−−−−−−−−−−−−→ s′ , N1 ·N2 ·N3 or s =========⇒ s′ for the empty action set abstracted traces. Definition 3.3 (Weak bisimulation) Let A = (S, N , →, s0 ) be an ACA. A weak bisimulation on A is N N an equivalence Θ on S such that for all (s1 , s2 ) ∈ Θ if s1 =⇒ p1 then s2 =⇒ p2 for some (p1 , p2 ) ∈ Θ. States s1 and s2 are called weakly bisimilar iff there exists weak bisimulation R such that (s1 , s2 ) ∈ R. Definition 3.4 (Action refinement) Let A = (S, N , →A , s0 ) and B = (Q, M , →B , q0 ) be two ACA. We say that A is an action refinement of B, written as B 4 A , iff there exist a set K ⊆ N and a set of renamings R = {x → y = ρ (x), ρ : N \ K → M } such that B and ρ (hide(A , K), R) = (S, M , →′ , s0 ) are weakly bisimilar. Proposition 3.3 (Compositionality of action refinement) Let A1 = (S1 , N1 , →A1 , s10 ) and B1 = (Q1 , M1 , →B1 , q10 ) be two ACA such that B1 4 A1 with a set of hidden actions K1 ⊆ N1 and a set of renamings R1 : {x → y = ρ1 (x), ρ1 : N1 \ K1 → M1 }. Let A2 = (S2 , N2 , →A2 , s20 ) and B2 = (Q2 , M2 , →B2 , q20 be two ACA such that B2 4 A2 with a set of hidden actions K2 ⊆ N2 and a set of renaming R2 : {x → y = ρ2 (x), ρ2 : N2 \ K2 → M2 }. Assume also that N1 ∩ N2 = M1 ∩ M2 = 0. / The γ -synchronous product of automata A1 and A2 is the action refinement of the ω -synchronous product of automata B1 and B2 , i.e., B1 ⊲⊳ ω B2 4 A1 ⊲⊳ γ A2 with a set of hidden actions K = K1 |γ K2 and a set of renamings R = {x → y = ρ (x) : (N1 \ K1 ) |γ (N2 \ K2 )} → M1 |ω M2 where ρ (x) is defined as in Prop. 3.2, γ = (γ1 , γ2 ), γ1 : N → N1 , γ2 : N → N2 and ω = (ω1 , ω2 ), ω1 : M → M1 , ω2 : M → M2 are action synchronization functions such that N ∩ (N1 ∪ N2 ) = 0, / M ∩ (M1 ∪ M2 ) = 0, / and γ1 (n) = n1 ∧ γ2 (n) = n2 iff ω1 (ρ (n)) = ρ (n1 ) ∧ ω2 (ρ (n)) = ρ (n2 ). 4 Semantic model for Reo implementation Existing semantic models for Reo describe the coordination behavior of Reo circuits but do not show how to achieve it. We refer to the process of exchanging messages among remote Reo nodes in order to establish whether they are ready to accept or provide data as handshaking protocol: before transmitting service data, Reo nodes notify each other about their internal states. It is not clear how Reo nodes and channels should behave to determine which transitions are enabled and agree to perform one transition from the set of enabled ones. Specifying such behavior is important for the generation of executable coordination code [21]. In Reo, large synchronous regions can be constructed. By synchronous region we understand part of a circuit consisting of joint synchronous channels. Figure 2 shows a synchronous Reo circuit with eight boundary nodes and its operational semantics in the form of ACA. In this circuit, 4 source nodes 6 Handshaking Protocol for Distributed Implementation of Reo may provide data, 4 sink nodes may consume data, while 7 mixed internal nodes together with channels coordinate data flow. Here L is an exclusive route node, M is a join node, and other nodes and channels behave as explained in Section 2. Assume that a write request arrives on node A. A can accept this request iff (i) D has a pending write request, (ii) nodes C and G are ready to accept, and (iii) there is no data flow on port M (required by the semantics of the AsyncDrain channel). If nodes are deployed on remote machines, the node cannot decide whether to accept data until it receives messages from all parties it depends on. If several transitions are enabled (as shown by the ACA semantics, 11 transitions are possible in our example if all boundary nodes are ready to communicate), the implementation should non-deterministically choose one of them. The goal of the handshaking protocol is to ensure that the internal choice made by Reo nodes locally lead to the correct implementation of the global observable behavior of the circuit. For example, if there are pending requests on nodes K, O and S, but no request on node N, the exclusive router L should transfer data to the node P and the merge node R should consume data from node P because transition {K, L, O, P, R, S} (corresponds to an observable transition {K, O, P}) is enabled and should not be excluded by a local choice of a node or a channel with non-deterministic behavior. {bA,bC,bD,bG,bK,bO,bS} {uA,uC,uD,uG,uK,uO,uS} {bO} {uA,uC,uD,uG,uK,uO} {uO} {bA,bC,bD,bG,bK,bO} A B C {uA,uC,uD,uG,uO} {bK} {bA,bC,bD,bG,bO} {uK} D E F G q {bK,bO} {uA,uC,uD,uG,uK} {uK,uO} K L M N O P R S (a) Reo model {bA,bC,bD,bG,bK} {bK,bO,bS} {uK,uO,uS} {uK,uN,uO,uS} {bK,bN,bO,bS} {bK,bN,bS} {bA,bC,bD,bG} {uK,uN,uS} {uA,uC,uD,uG} (b) ACA Figure 2: Complex synchronous circuit The existing implementations for Reo either (i) decompose a circuit to synchronous regions and deploy all nodes and channels from such a region on a single machine [19], (ii) propagate technical messages to establish which nodes are ready to process data as if there were no delays [21]. The first approach is not a fully distributed solution: if the whole network consists of a single synchronous region, the coordination is performed by a single machine. The second approach implies no constraints on node deployment but it is not efficient for two reasons. Firstly, after an internal node receives a request message, it propagates it to the rest of the network. Meanwhile, if another message comes to the same node, it needs to be propagated again. Thus, internal nodes update their routing tables several times per execution cycle. Secondly, on each execution cycle, one node is elected to resolve non-deterministic choice and need to keep a list of enabled nodes for the whole synchronous region. Consider a circuit with a merge fragment in Figure 3. Assuming that both input ports A and B receive write requests simultaneously, in the time-agnostic implementation [21], the merge node C propagates the request that arrives first. I.e., if t1 < t2 , the merge node assumes that only transition {A,C} is enabled. 7 N. Kokash A t1 {bB,bC} {uA,uC} {uB,uC} {A,C} {B,C} C B {bA,bC} t2 (a) Circuit (b) CA (c) ACA with port blocking actions Figure 3: Merge circuit and its semantics In time t2 − t1 it learns that {B,C} is enabled as well and sends a new technical message to notify other nodes in the synchronous region. This causes undesired traffic and does not scale well. Furthermore, the non-deterministic choice introduced by C is not resolved locally, but delegated to an external node (elected randomly, depending on its ID). Thus, the existing implementation is not optimal in time-aware environment and relies on centralized resolution of non-determinism at each execution cycle to ensure absence of inconsistencies. We need a time-aware sematic model for Reo that displays their internal state changes (e.g., from idle to waiting for reply to committed and back to idle). TCA [2] models circuit time delays while ACA [16] allows multiple actions to be observed on node and channel ports. We combine these two models to describe our handshaking protocol. Let C be a finite set of clocks and v : C → R≥0 be a clock assignment function as defined in [2]. Let also cc be a clock constraint for C, which is defined as a conjunction of atoms of the form x ⊙ n where x ∈ C , ⊙ ∈ {<, ≤, >, ≥, =} and n ∈ N. CA(C ) (or CA) denotes the set of all clock assignments and CC(C ) (or CC) the set of all clock constraints. Definition 4.1 (Timed ACA) A Timed ACA (TACA) is a tuple A = (S, C , N , →, s0 , ic), where S is a finite set of states, C is a finite set of clocks, N is a set of action names derived from a set of port names M and a set of admissible action types T , → ⊆ S × 2N × DC ×CC × 2C × S is a transition relation such that DC is the set of data constraints over a finite data domain Data, s0 ∈ S is an initial state, ic : S → CC is a function that assigns to any location s an invariance condition ic(s). Let an injective function act : M × T → N define action names for each pair of a port name and an action type observed on the port as discussed in [16]. The action synchronization function γ : N → N1 × N2 is defined through a pair of injective functions γ1 : N → N1 , γ2 : N → N2 from a new set of action names N into N1 and N2 [18]. Definition 4.2 (Product of TACA) For two TACA A1 = (S1 , C1 , N1 , →1 , s10 , ic1 ) and A2 = (S2 , C2 , N2 , →2 , s20 , ic2 ) and the action synchronization function γ : N → N1 ×N2 with γ1 : N → N1 and γ2 : N → N2 , the TACA A1 ⊲⊳ γ A2 , called the γ -synchronization product of A1 and A2 , is given by A1 ⊲⊳ γ A2 = (S1 × S2 , C1 ∪ C2 , N1′ |γ N2′ , →, hs10 , s20 i, ic(hs1 , s2 i)) where ic(hs1 , s2 i) = χ (ic(s1 )) ∧ χ (ic(s2 )), for any s1 ∈ S1 , s2 ∈ S2 , χ : CC1 ∪ CC2 → CC is a clock constraint and location invariance condition update function, and the transition relation → is determined by the following rules: N1 ,g1 ,cc1 s1 −−−−→1 t1 N1 ⊆ N1′ N1 ,g1 ,χ (cc1 ) hs1 , s2 i −−−−→ ht1 , s2 i and N1 ,g1 ,cc1 s1 −−−−→1 t1 N2 ,g2 ,cc2 N2 ,g2 ,cc2 s2 −−−−→1 t2 s2 −−−−→1 t2 N2 ⊆ N2′ N2 ,g2 ,χ (cc2 ) hs1 , s2 i −−−−→ hs1 ,t2 i γ1−1 (N1 ) = γ2−1 (N2 ) N1 |γ N2 ,γ (g1 ∧g2 ),γ (χ (cc1 )∧χ (cc2 )) hs1 , s2 i (1) −−−−−−−−−−−−−−→ ht1 ,t2 i (2) 8 Handshaking Protocol for Distributed Implementation of Reo Function χ is introduced to update invariance conditions and clock constraints in composed circuits. In particular, this extension is needed to increase timeouts for composed networks. For example, if invariance conditions in A1 are in the form x ≤ T1 and the invariance conditions in A2 are in the form x ≤ T2 , by setting χ (x ≤ T1 ) = x ≤ T1 + T2 , and χ (x ≤ T2 ) = x ≤ T1 + T2 , we extend timeout needed for the traversal of the composed network. Consequently, clock constraints in the form x > T1 and x > T2 are replaced with x > T1 + T2 . We define the hiding operator hide(A , K), where K is a non-empty set of actions K ⊆ N , and a state-transition graph of TACA GA analogously to the TCA [2]. The only distinction is that instead of the nodes set as in CA we deal with the action sets as in ACA. To reason about time-agnostic Reo semantics, we need to abstract from time in TACA. We omit data constraints and focus on action synchronization constraints. Let q = hs, vi be a state of a state-transition graph of TACA GA . We call a finite or infinite sequence of transitions N0 ,t0 N1 ,t1 N2 ,t3 r = q −−−−→ q1 −−−−→ q2 −−−−→ q3 ... a q-trace in GA . We say that a finite or infinite sequence of transitions N0 N1 N2 r = q −−−−→ q1 −−−−→ q2 −−−−→ q3 ... is an untimed q-trace iff there exist t0 ,t1 ,t2 , ... ∈ R≥ such that N0 ,t0 N1 ,t1 N2 ,t2 r′ = q −−−−→ q1 −−−−→ q2 −−−−→ q3 ... is a q-trace in GA . Let Q∗ be the set of all finite sequences over a set Q = {hs, vi | s ∈ S}. Given finite sequences σ1 and σ2 , we denote their concatenation σ1 · σ2 . If for some TACA there exists an untimed trace N1 ·{}·{}·N2 ·{}·N3 ·{} q −−−−−−−−−−−−−−→ p, where N1 , N2 , N3 ∈ 2N are sets of actions representing TACA labels, we write N1 ·N2 ·N3 q =========⇒ p. 5 Reo handshaking protocol I/O requests arrive to the Reo source nodes from writers, or to the sink nodes from readers. Writers and readers for synchronous regions are either external components or buffered Reo channels. Once a pending request is detected, the boundary node initiates handshaking message exchange through channels that connect it with its neighbors, reporting its status and requesting to confirm the ability to accept or provide data. At this stage, channels work as simple communication links between adjacent nodes regardless of their semantics. Three message propagation strategies are possible: (i) forward propagation, when the handshaking is initiated by writers, readers remain passive and reply to the arrived messages; (ii) backward propagation, when the communication is initiated by readers, writers are passive; and (iii) two-side propagation, when both writers and readers can initiate the message exchange. Two-side propagation minimizes handshaking delay, but it is also more difficult to implement. In the remainder of this paper we consider forward propagation. The handshaking behavior of Reo nodes depend on their type (input, output, simple internal, merge, replicate, route, or join) and (the number of) adjacent channels. Nodes can exchange three types of messages: (i) intention to write (write), (ii) possibility to read (read), and (iii) possibility to write (may write). 9 N. Kokash {},x > T s0 x<T {?wAout },x:=0 {uA},x > T x<T {!rAout } {bA},x:=0 (a) Source node {} {} {!mwAin },x:=0 {!wAin },x:=0 s0 {?rAin }{},x > T {uA},x > T {!wAin } x<T x<T {},x > T {},x > T {?mwAout }, x:=0 {!mwAin } s0 x<T {!wAin } {},x > T {uA},x > T {!wAin } {?rAin },x:=0 {bA},x:=0 x<T x<T {!rAout } {?rAin } {bA},x:=0 (b) Sink node {?wAout },x:=0 x<T {!rAout } {?rAin } (c) Mixed node Figure 4: Handshaking behavior of source, sink, and simple mixed nodes The third message type is needed for routers to obtain status of nodes in alternative branches without giving definite promise to write data. Together with three message types, four actions are recognized at each channel port: (i) send a message to an adjacent node, (ii) receive a message from an adjacent node, (iii) block (or commit) port, (iv) unblock the port. Figure 4 shows the TACA for simple Reo nodes: a source node with one output port Aout , a sink node with one input port Ain , and a mixed node with one input port Ain and one output port Aout . We use a set of action types T1 = {?, !} × {w, r, mw} to represent sending and receiving of write, read, and may write messages, respectively. We also use a set of actions T2 = {b, u} to define blocking and unblocking of node ports. Thus, a set of action names derived from the set of port names {Ain , Aout } and a set of admissible action types T = T1 ∪ T2 , is N = Nin ∪ Nout where Nin = {?wAin , !wAin , ?rAin , !rAin , ?mwAin , !mwAin , bAin , uAin } is a set of actions observed on the node’s input port, and Nout = {?wAout , !wAout , ?rAout , !rAout , ?mwAout , !mwAout , bAout , uAout } is the set of actions observed on its output port. If a node performs the same action on all its ports simultaneously, we write α A | α ∈ T . For example, bA and uA stand for “block/unblock all ports of node A”, respectively. The handshaking behavior of a source node is shown in Figure 4(a)). The source node A sends a write message through its output port and waits for a reply for the time x < T, where T is a timeout large enough to guarantee that any message in the synchronous region of the circuit is propagated to the most remote (in terms of the communication delay) node and back. If the node does not receive a reply from the accepting party, it assumes that the latter is not ready to read and discards the request. If the answer is received (i.e., !rAout ), the node commits to transfer data by blocking its ports (bA). Finally, after the timeout expires, the node unblocks its ports (uA) and returns to the initial state. The sink node (see Figure 4(b)) is a passive node that waits for the write or may write messages. After such a message is received, it either confirms its readiness to accept (?rAin ) or ignores the message and returns to the initial state. The transition shown with the dashed line is not required for always accepting sink nodes. If the write message is received and the node is ready to accept, it goes to the committed state. If the may write was received and the node confirmed the intention to accept, it awaits for the confirmation to write (!wAin ), replies to it and only then commits. The mixed node exhibits the behavior which is the combination of the above. It accept the incoming messages and forwards the them to its neighbor though the output port (?wAout and ?mwAout ), waits for the reply (!rAout ) and forwards it back through the input port (?rAin ). Similarly, if !wAin is received after !mwAin , the mixed node forwards the write request to the output port, waits for the acknowledgement, forwards it to the sender, and commits. 10 Handshaking Protocol for Distributed Implementation of Reo {},x > T x<T s0 {uA},x > T {},x > T {!rAout2 } {!rAout1 } {!mwAin } {!wAin } {?mwAout1 , ?mwAout2 },x:=0 {!rAout1 , !rAout2 } x<T {},x > T {},x > T x<T {},x > T {!rAout1 } x<T {bA},x:=0 {},x > T {!rAin } {!rAout1 } {!rAout2 } x<T {!rAout2 } {!rAout1 , !rAout2 } {!rAout2 } {?rAin },x:=0 {} x<T {!wAin } {?wAout1 , ?wAout2 },x:=0 x<T {!rAout1 } x<T Figure 5: Replicate node Note that it is important to acknowledge both may write and write messages to be able to propagate I/O information in the circuit: the read message in response to a may write message is just a confirmation that some accepting sink node exists in the circuit, yet the data transfer through a particular node may not happen due to the non-deterministic choices of internal Reo nodes. In contrast, the read message in response to a write message means that the exchanging parties agreed to transfer data. Considering the presence of may write messages followed by write messages, T can be roughly estimated as C times the longest path in the (synchronous region of the) Reo circuit graph, where C is a constant that depends on the number of branches for merge nodes that may receive may write messages. We will address the issue of computing the lower bound on timeout delays in our future work. The handshaking behavior of the replicate node with input port Ain and output ports Aout1 and Aout2 is shown in Figure 5. Once a write or may write message is received, the node sends a may write message to its both output ports and waits for the replies. If meanwhile the timeout expires, the node returns to its initial state. If both neighbors confirm their ability to read, the further processing depends on the status of the input port: if the write message was received initially, the node A knows that it is able to provide data to its output ports and thus sends {?wAout1 , ?wAout2 } to agree on the certain data exchange with them. If both !rAout1 and !rAout2 are observed, A forwards the reply back through its input port and commits (bAin ). Alternatively, if !mwAin initially triggered the decision making cycle on A, it has to request for the confirmation of the flow (?rAin ), and if it is confirmed (!wAin ), proceed as before. The difference in the procedure for the triggering may write message is shown with dashed lines. The behavior of the merge node with two input ports Ain1 and Ain2 and one output port Aout depends on the type of the incoming messages: both write, both may write, or the combination of write and may write. In the first case (see Figure 6(a)), the merge node in its initial state waits for an incoming message on at least one of its input ports, !wAin1 , !wAin2 or both, forwards the incoming write message to the output port (?wAout ), and waits for the confirmation to read (!rAout ). If one input message is received, the node waits for the incoming message on the other input port. If the second message does not arrive within the timeout, it means that the other writer is not ready to write and A will proceed with the available request. If both input ports received a write request, the merge node chooses an incoming port to accept data from. Once the decision is made, the node A sends the read message to the selected input port (?rAin1 or ?rAin2 ) and commits ({bAin1 , bAout } or {bAin2 , bAout }). 11 N. Kokash {uAin1 , uAout },x > T {?wAout },x > T ,x:=0 x<T x < T* {},x > T {!wAin1 },x:=0 {!wAin2 } {},x > T s0 {!wAin1 , !wAin2 } {!wAin2 },x:=0 {!rAout } {?wAout },x:=0 {!wAin1 } {},x > T {?rAin1 } {bAin1 , bAout },x:=0 x<T {?rAin2 } {bAin2 , bAout },x:=0 x<T {!rAout } x<T {!rAout } {?wAout },x > T ,x:=0 {!rAout } x<T x < T ** {uAin2 , uAout },x > T (a) Merge node with both source ends ready to write {},x > T {?mwAout },x > T , x := 0 {!rAout } x<T x<T {},x > T {!mwAin1 },x:=0 {!mwAin2 } {},x > T s0 {!mwAin1 ,!mwAin2} {?mwAout }, x := 0 x<T {},x > T {!rAout } {!wAin1 } {?wAout },x:=0 ∗ {!wAin1 } x<T {?rAin1 ,x:=0} {?rAin2 ,x:=0} x<T {!mwAin2 },x:=0 {!mwAin1 } {},x > T {?mwAout },x > T , x := 0 x<T x<T x<T {?rAin1 },x:=0 {},x > T {!rAout } {},x > T {?rAin2 },x:=0 x<T {!wAin2 } {!wAin2 } {?wAout },x:=0 ∗∗ (b) Merge node with both source ends that may write Figure 6: Merge node In Figure 6(b), !mwAin1 and !mwAin2 are initially received. This means that the sender tries to establish which transactions are enabled. Consequently, after propagating the initial may write message to the output port (?mwAout ) and receiving !rAout , the node A needs to wait for the definitive confirmation to provide data from at least one of its input ends, !wAin1 or !wAin2 . If such a message arrives, the node commits, otherwise, returns to the initial state. In the case when both input nodes are ready to write, A non-deterministically chooses one of the branches and sends the read message to it, either ?rAin1 or ?rAin2 . If the selected input port receives the confirmation to write, the node forwards it to the output port and commits. However, the node that issued the initial may write message may choose to fire a different transaction and the node A will not receive a write message. This should not exclude the transaction that involves the pending request on its second input port. Thus, on the timeout the node A sends the read message to the remaining source port. If the write message is finally received (?wAout ), the node forwards it to its output port and processes further messages as in Figure 6(a). Otherwise, due to the external choices, the node does not participate in the data transfer at this cycle and returns to its initial state. The combination of write and may write messages yield an automaton with the behavioral patterns shown in the above two cases. The route node with one input port Ain and two output ports Aout1 and Aout2 receives a write message !wAin or a may write message !mwAin , forwards it to its output ports and waits for the read messages. 12 Handshaking Protocol for Distributed Implementation of Reo {uA},x > T x<T {},x > T {},x > T s0 {},x > T x<T {!rAout1 } {!rAout2 } {!wAin{}?mwAout1 ,?mwAout2 },x:=0{!rAout1 ,!rAout2 } x<T {!rAout2 } {!rAout1 } x<T {},x > T {!rAout1 } {?wAout1 },x:=0 {},x > T {!rAout1 } {?rAin } {bAin , bAout1 },x:=0 x<T {!rAout2 } x<T {?wAout2 },x:=0 {!rAout2 } {?rAin } {bAin , bAout2 },x:=0 x<T x<T {?wAout1 },x:=0 {},x > T {},x > T {?wAout2 },x:=0 x<T {uA},x > T Figure 7: Route node Figure 7 shows the case for the initial write message, the may write is processed in a similar way and is omitted due to the lack of space. After at least one of the output ports confirms the ability to read (!rAout1 and/or !rAout2 ), the node A non-deterministically chooses among the available options and confirms the intention to write (?wAout1 or ?wAout2 ). If the confirmation is received, the node proceeds by sending to the input port ?rAin and commits ({bAin , bAout1 } or {bAin , bAout1 }). Alternatively, on the expiration of the timeout, the route node tries to confirm the intention to write to another enabled output port if such an option is available. For the initial may write message the mechanism is similar, but before the node decides to issue a definite write message, it needs to confirm the ability to read !rAin , receive the definite write message ?wAin , make a choice between ?wAout1 and ?wAout2 , make sure that the port it had chosen acknowledged the ability to read (or try other options alternatively), send another confirmation to read to its input port (!rAin ) and commit. For the join node A to commit, both its input ports Ain1 and Ain2 should receive write (or may write with the consequent confirmation to write) messages, and its sink port should be able to read. If only one input request is received within the timeout, it is discarded. If both messages are write messages, the node A simply checks whether the sink end can read (?wAout followed by !rAout ), confirms the possibility of the flow to both senders ({!rAin1 , !rAin2 }) and commits. Figure 8 shows a less obvious case with one may write input message (!mwAin1 ) and one write message (!wAin2 ). The join node cannot guarantee the flow to its sink and thus senses whether the sink end can read with an uncertain may write request (?mwAout ). If !rAout follows, the node should first request the uncertain input port to confirm the intention to write (?rAin1 ). If so, the node behaves as in the previous case: it sends the write messages to its sink end, waits for the confirmation, forwards the confirmation to both input ports ({?rAin1 , ?rAin2 }) and commits. Data flow in a Reo circuit is controlled not only by its nodes, but also by its channels that may perform operations on the data they receive. What is a channel and how do we implement them? Essentially, each channel is an abstraction for a set of hops in a computer network to and from a component that implements the channel’s behavioral logic; its source port is known to data suppliers while its sink port is 13 N. Kokash x<T {},x > T {!mwAin1 },x:=0 {!wAin2 } s0 {!mwAin1 , !wAin2 } {!wAin2 },x:=0 {},x > T {},x > T {},x > T {?mwAout },x:=0 x<T {!rAout } {!mwAin1 } {uA},x > T x<T {?rAin1 },x:=0 x<T {!wAin1 } {?wAout } {},x > T x<T {bA},x:=0 {?rAin1 , ?rAin2 } {!rAout } x<T Figure 8: Join node x<T {!wAin } {bAin } {?rAin },x > T ,x:=0 {},x > T {?rAin },x:=0 {bAin },x := 0 x<T {uAin },x > T {?mwAout }, x := 0 {!mwAin } s0 x<T {!rCout , x := 0}{!α Cin },x:=0 x<T s0 x<T {?rCin },x > T{?α Cout },x > T (a) Sync {?rAout },x:=0 {},x > T {?rAin },x:=0 {!wAin } x<T {?rA {?rA } },x > T inin {!wAin } {?wAout },x:=0 x<T {uA},x > T {!rAout } {bA},x:=0 {bA},x:=0 x<T {?rAin } (b) LossySync Figure 9: Handshaking behavior of Sync and LossySync channels known to data consumers. From the viewpoint of handshaking protocol, Reo channels are communication links to exchange messages between adjacent nodes (e.g., Sync channel). However, channels behave also like nodes that determine which transitions are enabled (e.g., SyncDrain and AsyncDrain). The handshaking behavior of a Sync channel c with communication delay t, source port Cin and sink port Cout can be modeled as shown in Figure 9(a). It accepts a write or a may write message on its source end (!α Cin where α ∈ {m, mw}) and notifies its sync end (?α Cout ). Similarly, it accepts a read message on its sink end (!rCout ) and transfers it to its source end (?rCin ). The behavior of the LossySync channel as a transition link is analogous. However, its ability to lose data either when its output node is not ready to accept (context-dependent LossySync) or nondeterministically (context-independent LossySync) should be modeled explicitly. In the first case, the decision to accept data on the source end of the LossySync channel despite the fact that its sink end is unable to read can be modeled as shown in Figure 9(b). This figure shows the handshaking behavior of an always accepting mixed node that commits to a transaction that involves only its input port after the timeout of waiting for a read message from its output port expires. Thus, a context-dependent LossySync channel can be represented as a Sync channel joint to such a node. The context-independent LossySync behaves similarly, but it may accept data without notifying its sink port, as shown by two dashed transitions ?bAin in Figure 9(b), in right and left branches. Alternatively, a non-deterministic LossySync can be modeled with the help of a router node that either chooses to pass data or reroute it to an unobservable always accepting output node τ (trash bin) where this data item is destroyed. In the same fashion, the behavior of SyncDrain and AsyncDrain channels can be modeled with the help of auxiliary join and merge nodes as shown in Figure 10. 14 Handshaking Protocol for Distributed Implementation of Reo A A B B (a) SyncDrain A A SyncDrain B (b) SyncDrain (c) AsyncDrain B AsyncDrain (d) AsyncDrain Figure 10: Modeling handshaking behavior of SyncDrain and AsyncDrain channels 6 Handshaking protocol correctness In this section, we outline the sketch of a proof that the presented handshaking TACA provides correct implementation for Reo. To be able to show this formally, we need to define the notion of correct implementation. Definition 6.1 (Observable trace) For a synchronous Reo circuit with a set of nodes P, let A = (S, C , N , →A , s0 , ic), N = P × TA be its handshaking TACA with port blocking, unblocking and N1 ·N2 ·...·Nn auxiliary actions, {b, u} ⊂ TA . We say that s =========⇒ s′ is an observable trace in A if it is an untimed trace in hide(A , N \ M ) where M = P × TB , TB = {b, u}. Definition 6.2 (Correct implementation) For a synchronous Reo circuit with a set of nodes P, let B = (Q, M , →B , q0 ) | M = P × TB , TB = {b, u} be its ACA, and A = (S, C , N , →A , s0 , ic) | N = P × TA where TA ∩ TB = {b, u} be its handshaking TACA. The Reo handshaking protocol defined by A is a correct implementation of Reo iff there exists a mapping Θ : Q → S such that N1 ·N2 ·...·Nn M • for any q −−−−→ q′ in B there exists an observable trace s =========⇒ s′ in A such that M = N1 ∪ N2 ∪ ... ∪ Nn , N1 ·N2 ·...·Nn M • for any observable trace s =========⇒ s′ in A , there exists q −−−−→ q′ in B, M = N1 ∪ N2 ∪ ... ∪ Nn . Intuitively, this definition requires the handshaking protocol to block and unblock only those sets of ports that appear in synchronization constraints of port blocking ACA. Since auxiliary actions may be required in the implementation, blocking and unblocking of all involved ports does not need to be simultaneous, it is sufficient that for each ACA transition to have a state in TACA with all necessary ports blocked and later unblock these ports. To show the correctness of our protocol, we should (i) show that TACA provide correct implementation of port blocking ACA for each basic Reo node and channel as defined in [16], (ii) using product operator, define TACA for a composed circuit by synchronizing message exchange actions on shared ports and show that such a TACA is a correct implementation for the composed circuit. For each Reo node and channel, we hide all handshaking messages in the time-abstracted version of TACA and show that the obtained automaton is weakly bisimilar to the port-blocking ACA for this node or channel (or equivalently, the initial TACA is the action refinement of the port blocking ACA). Compositionality of this relation helps to extend the proof to any Reo circuit. For a circuit with a set of nodes P, its handshaking behavior is given by A = (S, C , N , →A , s0 , ic), N = P × TA , TA = {b, u, ?w, !w, ?mw, !mw, ?r, !r}. It can be checked that for all basic Reo channels and nodes, B 4 A with a set of hidden actions K = M {α · X, α ∈ TA \ TB , X ∈ P} and an empty set of renamings R = 0. / Since for each q −−−−→ q′ in B M there exists s =⇒ s′ in hide(A , N \ M ), A is a correct implementation of B. 15 N. Kokash To compose the TACA for handshaking, let us define a synchronization function γ : (γ1 , γ2 ), γ1 : N → N1 , γ2 : N → N2 as follows. For any two joint ports Aout and Bin in a Reo circuit, γ1 (?wAout Bin ) =?wAout , γ1 (?mwAout Bin ) =?mwAout , γ1 (!rAout rBin ) =!rAout , γ1 (bAout Bin ) = bAout , γ1 (uAout Bin ) = uAout , γ2 (?wAout Bin ) =!wBin , γ2 (?mwAout Bin ) =!mwBin , γ2 (!rAout rBin ) =?rBin , γ2 (bAout Bin ) = bBin , γ2 (uAout Bin ) = uBin . (3) The definition of the implementation correctness of the handshaking protocol in the form of TACA is a weaker requirement than the action refinement and our synchronizing function enables an automaton for only one instance of suitable implementations. The TACA product without synchronizing blocking and unblocking actions in lines 4 and 5 of (3) will also yield a correct implementation for the corresponding port blocking ACA, but not the action refinement. It also generates a significantly larger automaton that is harder to deal with formally. However, in the distributed environment with communication delays it may be difficult to perform simultaneous port blocking and unblocking on remote nodes to signal that they are ready to transfer data. In practice, we are only interested in the existence of a state in which all ports involved into a firing transition are blocked. In the TACA product without synchronizing blocking and unblocking actions, Reo ports that are ready for firing transitions are blocked in any order. For example, in the case of a node with two ports, bAout and bBin , their interleaving bAout ||bBin = bAout .bBin + bBin .bAout + bAout |bBin gives us traces with the same set {bAout , bBin } of performed actions, which conforms to our definition of the correct implementation. 7 Related work Proença et al. [21] identifies five implementation approaches for Reo and offers their own framework, called Dreams. The most straightforward approach is a speculative approach: data is sent through the channels and rolled back when an inconsistency arises. This approach has never been implemented. The automata-based approach [19] relies on CA semantics and pre-computed behavior at compile time. Implementations based on connector coloring [19] compute all solutions for the behavior of each round and keep them in a routing table. Existing search-based implementations rely on structural operational semantics and are implemented in Alloy [15] and Maude [20]. The constraint-based approach [8] applies SAT solving techniques to search for single solutions on each round. Dreams [21] is the first working implementation of a distributed engine for Reo. It is based on a commit and send message exchange and has common traits with our protocol. However, our protocol is a form of a speculative approach that does not require rollbacks and unnecessary data propagation. We provide a theoretical model for distributed Reo implementation with desired characteristics [21]: • Decoupling: each node can be deployed on a separate machine, transitions in synchronous regions fire independently, and handshaking message exchange occurs within the boundaries of synchronous regions. • Scalability: similarly to the Dreams, no global consensus is required. The behavior is computed per step, avoiding not only the state space explosion typical for the centralized implementation, but also the need for each node to remember the states of other nodes in the same synchronous region. In contrast to the Dreams, our implementation resolves non-determinism locally by each node or channel with inherent non-deterministic behavior. This is a more scalable approach because it does not use routing tables, the decision which transition to fire is taken in the distributed manner. 16 Handshaking Protocol for Distributed Implementation of Reo • Reconfiguration: runtime reconfiguration of a connector will not require any global or regional changes. Once a node detects a change in its environment, it only needs to adjust its own behavior. For example, if a new channel is connected to an input port of a simple node, this node becomes a merge node and should behave accordingly. Formal protocol adjustment rules to enable reconfiguration will be developed in our future work. • Fault tolerance: with the exception of failures of committed nodes, our protocol is fault tolerant. The timeouts as opposed to the permanent locks in Dreams guarantee that a failure is treated as inability of a node to process data. Even in the case of a committed node failure, only current transaction is affected, at the next step (after timeout expires on each committed state) the remaining circuit resumes its normal operation. In some applications of Reo such as coordination of processes in a multi-core execution environment, delays are negligible. Arriving requests are propagated through the network instantly and can be modeled using action synchronization. In [10], a Reo-to-C compiler which generates partially-distributed implementations for shared-memory platforms is presented. An optimization technique to improve the scalability of the generated code is later introduced [11]. In [9] and [12], the formal details of an implementation with partial-distribution based on synchronous regions are developed. An early Reo-to-Java compiler, which generates completely centralized implementations is described in [14] and used for service orchestration in [13]. The approach proposed in this paper can be used as foundation for distributed implementation of other coordination approaches for agent- and component-based systems where global consensus of synchronous entities is required. As opposed to commits and rollbacks typically employed to implement transactional processes [7], sensing messages like our may write messages can be employed to elicit the states of remote entities before taking decisions locally. 8 Conclusions and Future Work In this paper, we proposed a theoretical model for distributed implementation of Reo. We extended the definition of ACA with the notion of time, used this model to define what a correct implementation for Reo is, and described a handshaking protocol that complies with our definition of correct implementation. Our approach exhibits properties implied by Reo but not enforced in the previous implementations: the resolution of non-deterministic choices does not require centralized decisions, and the timeout mechanism ensures that the network does not lock due to a failure of a remote node or a channel. Consequently, this execution model is more suitable for real-time monitoring, QoS estimation, failure detection and reconfiguration. Due to the space limitations we could not discuss some relevant aspects of the approach, most notably, computation of timeouts. We plan to extend the protocol to handle data constraints and implement a service that deploys and executes Reo circuits based on the presented model. The approach used in this paper can be applied to describe handshaking behavior of Reo nodes and channels assuming other propagation strategies: backward and two-side propagation. References [1] F. Arbab (2004): Reo: A Channel-based Coordination Model for Component Composition. Mathematical Structures in Computer Science 14, pp. 329–366. N. Kokash 17 [2] F. Arbab, C. Baier, F. de Boer & J. Rutten (2007): Models and Temporal Logical Specifications for Timed Component Connectors. Software and Systems Modeling 6(1), pp. 59–82. [3] F. Arbab, T. Chothia, R. van der Mei, M. Sun, Y.J. Moon & C. Verhoef (2009): From Coordination to Stochastic Models of QoS. In: Proc. COORDINATION 2009, LNCS 5521, Springer, pp. 268–287. [4] F. Arbab, T. Chothia, M. Sun & Y-J. Moon (2007): Component Connectors with QoS Guarantees. In: Proc. COORDINATION 2007, LNCS 4467, Springer, pp. 286–304. [5] F. Arbab, N. Kokash & M. Sun (2008): Towards Using Reo for Compliance-aware Business Process Modelling. In: Proc. ISoLA 2008, CCIS 17, Springer, pp. 108–123. [6] C. Baier, M. Sirjani, F. Arbab & J. Rutten (2006): Modeling Component Connectors in Reo by Constraint Automata. Science of Computer Programming 61(2), pp. 75–113. [7] A. Baragatti, R. Bruni, H. Melgratti, U. Montanari & G. Spagnolo (2007): Prototype platforms for distributed agreements. ENTCS 180, pp. 21–40. [8] D. Clarke, J. Proença, A. Lazovik & F. Arbab (2011): Channel-based coordination via constraint satisfaction. Science of Computer Programming 76. [9] S.-S. T. Q. Jongmans & F. Arbab (2013): Global Consensus Through Local Synchronization. In: Proc. FOCLASA 2012, 393, pp. 174 – 188. [10] S.-S. T. Q. Jongmans, S. Halle & F. Arbab (2013): Reo: A Dataflow Inspired Language For Multicore. In: Proc. DFM 2012. [11] S.-S. T. Q. Jongmans, S. Halle & F. Arbab (2014): Automata-Based Optimization Of Interaction Protocols For Scalable Multicore Platforms. In: Proc. COORDINATION 2014, LNCS 8459, Springer, pp. 65–82. [12] S.-S. T. Q. Jongmans, F. Santini & F. Arbab (2014): Partially-Distributed Coordination With Reo. pp. 1 – 34. [13] S.-S. T. Q. Jongmans, F. Santini, M Sargolzaei, F. Arbab & H. Afsarmanesh (2012): Orchestrating web services using Reo: from circuits and behaviors to automatically generated code. In: Proc. ESOCC 2012, LNCS 7592, Springer, pp. 1 – 16. [14] Sung-Shik Jongmans & Farhad Arbab (2013): Modularizing and Specifying Protocols among Threads. In: Proc. PLACES 2012, EPTCS 109, pp. 34–45. [15] R. Khosravi, M. Sirjani, N. Asoudeh, S. Sahebi & H. Iravanchi (2008): Modeling and analysis of Reo connectors using Alloy. In: Proc. COORDINATION 2008, LNCS 5052, pp. 169–183. [16] Changizi B. Kokash, N. & F.: Arbab (2010): A Semantic Model for Service Composition with Coordination Time Delays. In: Proc. ICFEM’10, LNCS, Springer. [17] N. Kokash (2014): Handshaking Protocol for Distributed Implementation of Reo. Technical Report TR 2014-01, LIACS, Leiden University. [18] N. Kokash, C. Krause & E.P. de Vink (2010): Data-Aware Design and Verification of Service Composition with Reo and mCRL2. In: Proc. of SAC 2010, ACM Press, pp. 2406–2413. [19] Z. Maraikar, A. Lazovik & F. Arbab (2008): Building mashups for the enterprise with SABRE. In: Proc. ICSOC 2008, LNCS 5364, pp. 70–83. [20] M. Mousavi, M. Sirjani & F. Arbab (2006): Formal semantics and analysis of component connectors in Reo. ENTCS 154(1), pp. 83–99. [21] Jose Proença, Dave Clarke, Erik de Vink & Farhad Arbab (2012): Dreams: a framework for distributed synchronous coordination. In: Proc. SAC 2012, ACM.