Coordination Operators and Their Composition Under the Actor-Role-Coordinator (ARC) Model

Coordination Operators and their Composition under the Actor-Role-Coordinator (ARC) Model

Miao Song, Shangping Ren Computer Science Department Illinois Institute of Technology Chicago, USA {msong8,ren}@iit.edu

Abstract—For large open and distributed real-time appli- or the supporting run-time environment, such as operating cations, coordination constraints among concurrent, spatially systems, or system architectures. distributed and autonomous entities can be complex. The The base of our model is build upon the belief that how Actor-Role-Coordinator (ARC) model we developed earlier [1] introduced the concept of roles which are abstractions of to implement a functionality and when/where to execute behaviors that are to be coordinated. Each role’s behaviors the functionality are orthogonal. Computational entities may be shared by many concurrent entities, or played by implements the how, while when and where to execute many actors. Based on the role concept, coordination activities the functionality is defined by coordination constraints in large systems are partitioned into inter-role and intra-role which are encapsulated in coordination entities. As how coordinations to mitigate the coordination complexity. This paper focuses on coordination primitives and the composition and when/where are orthogonal, good programming models of these primitives in forming more complex intra-role and should ensure implementation transparency among the two inter-role coordination constraints. In particular, we define two orthogonal classes, i.e., among computational entities and primitive coordination operators, i.e., precede (t) and select coordination entities. (Dp), and use them to express temporal and spacial (with In the Actor-Role-Coordinator (ARC) model, the Actor respect to actor system’s behavioral space) coordination constraints among concurrent and autonomous actors. We further model [2], [3] is used to model distributed and concurrent provide an operational semantics for these operators under computation. Under the Actor model, each actor encap- the ARC model and provide case studies to illustrate their sulates a single thread of computation. It has states and expressiveness in specifying complex coordination constraints. communicates with other actors in the system by asynchronous messages. The Actor system only guarantees that a Keywords-Actor model; Actor-Role-Coordinator model; co- message sent by an actor will eventually be processed by its ordination; coordination constraints; coordination operators; receiving actor. The only coordination constraints inherent transition systems; operational semantics in the Actor system is the causal order [4]. The ARC model adds a coordination layer (role and coordinator) on top of the I.INTRODUCTION actor system and externally enforces coordination constraints through manipulations of actor message dispatch time and For large open distributed and real-time applications, there dispatch location. As the Actor model is a pure asynchronous are often many concurrent asynchronous and distributed system model and does not assume any message delivery entities, and they communicate with each other through time, such message manipulations are transparent to actors messages. Due to the dynamicity and openness of these and hence enable us to program computation (actors) and applications, it is impetuous to assume synchrony among coordination (roles and coordinators) independently. these entities. However, the virtue of real-time applications, For large open distributed and real-time applications, co- on the other hand, requires certain temporal orders, or more ordination requirements among concurrent and autonomous generally, requires coordination constraints being enforced entities can be complex. One of the challenging issues among these autonomous and concurrent entities. arises: is there a small set of primitive coordination oper- Traditional approaches often embed these requirements ators through which or through their composition complex inside implementation languages, operating systems, or sys- coordination requirements can be represented? This question tem architectures, rather than treat coordination constraints is motivated by the existence of functionally completed logic as independent and first class entities at programming lan- operations. In logic domain, logical propositions can be guage level. One of the drawbacks of such approaches is complex, however, these complex propositions in fact can that any modification of coordination constraints may require be represented by a small set of simple, but functionally changes of the application’s programming implementations, completed logic operations, such as the set {∧, ¬}. In this paper, we propose two coordination operators, i.e., B. Roles and Coordinators precede ( ) which constraints the quantitative temporal t Roles and coordinators in the ARC model constitute the order among two computational events, and select ( ) Dp coordination layer. Roles are introduced as behavior ab- which constraints the actors in their behavioral space, and stractions to mitigate coordination scalability and complexity study their compositions. issues inherent in large open distributed applications. With The rest of paper is organized as follows: for self- the introduction of roles, coordination is partitioned into containment, Section II briefly discusses the ARC model two categories, i.e., inter-role coordination and intra-role upon which our current work is built. Section III introduces coordination, which are the responsibility of coordinators the two primitive coordination operators and studies their and roles, respectively. Fig. 1 illustrates the layered structure properties and compositions. Section IV gives formal opera- of the ARC model. tional semantics for the two coordination operators under the ARC model. Section V discusses related work. We conclude in Section VI.

II.THE ACTOR-ROLE-COORDINATOR (ARC) MODEL For self-containment, this section gives a brief overview of the ARC model, detailed discussion of the model and its implementation can be found in [1] and [5], respectively. As the model name indicates, there are three distinctive types of entities in the model, i.e., the actors, roles and coordinators. The actors encapsulate asynchronous, autonomous and concurrent computation, while the roles and coordinators encapsulate coordination constraints to be enforced upon the computation entities, i.e., the actors. The following subsections summarize the functionalities and properties of these three types of entities.

A. Actors Actors in the ARC model are the same as the one Figure 1. The Actor Role and Coordinator (ARC) Model defined in the Actor model [2], [3]. In particular, actors are single-threaded active objects. They communicate with As shown in Fig. 1, the separation of concerns is apparent each other only through asynchronous messages. Each actor in the relationships among the layers. The actor layer is has a mailbox where the received and yet to be processed dedicated to computational behaviors and is oblivious to messages are buffered. Actors have states and behaviors. The the coordination enacted in the role and coordinator layers. actor’s current state and behavior decide how it processes The roles and coordinators constitute the coordination layer messages dispatched on its active thread. The actor’s state responsible for imposing coordination constraints among ac- and behavior can only be changed by the actor itself while tors. The coordinator layer is oblivious to the actor layer and processing a message. The active threads within actors is dedicated to inter-role coordination. The role layer bridges continuously process messages whenever their mailboxes are the actor layer and the coordinator layer and may therefore not empty. There are only three primitive operations each be viewed from two perspectives. From the perspective of a actor can perform, i.e., create new actors, send messages coordinator, a role enables coordination of a set of actors to other actors whom the sender knows the address of, that share the static descriptions of an abstract behavior and while processing a message, an actor can also perform associated with the role without requiring the coordinator become upon which the actor assumes a new state and a to have fine-grained knowledge of the individual actors that new behavior. All these operations are atomic. Therefore, play the role. From the perspective of an actor, a role we treat these operations as instantaneous events. The only is an active coordinator that transparently manipulates the order inherent in the Actor model is the causal order and the messages sent and received by the actor. only guarantee provided by the model is that messages sent Roles and coordinators themselves can be viewed as by actors will eventually be processed by their receiving meta actors and react to meta messages and actor events actors. Other synchronization and coordination constraints which are the occurrences of actors executing create, send, for the purpose of quality of services hence need to be or become. The role meta actors are able to observe and externally enforced. Roles and coordinators are to enforce manipulate messages in the actor layer. All events and such constraints. message manipulations associated with an initial triggering event or meta messages are indivisible and atomic, with no the wheel may “turn-right”, “turn-left” or “stop”. However, intermediate states visible across or within the three layers. at any given time instance, it can only perform one and Since the role and coordinator meta actors are state-based only one action. Wheel:turn-right defines the behavior of objects, the coordination policies within an application may the wheel actor, i.e., the wheel actor processes the turn-right adapt over time. message. More specifically, Definition 1 formally defines the actor behavior. C. Inter-role and Intra-role Coordination constraints Definitions 1 (Actor Behavior): An actor behavior is de- Inter-role coordination constraints restrict abstract behav- noted as [A :: M], where A is the actor’s unique name iors in temporal and actor behavioral space domains, while representing the state of the actor, and M is an message intra-role coordination constraints enforce the temporal and instance the actor A processes. spacial (with respect to actor behavioral space) order upon actors which carry out the distributed computation. The execution of the actor behavior [A :: M] means that We use a simplified robotic hand example to help un- the message M is dispatched on the thread of actor A where derstand the differences and relationships between inter-role it is processed. As message processing in the Actor model and intra-role coordination constraints. Consider two robotic is atomic, we hence treat actor behaviors as instantaneous. hands transferring an object from its left hand to its right Definitions 2 (Actor Behavior Space): Given an actor hand and we assume each hand may have many fingers. If we system (A), M is the message set that all the actors in A use actors to model individual fingers, the left hand and the can process, the actor behavior space (B) of the system A right hand are two different roles. The inter-role constraint is define as for transferring an object from the left hand to the right hand is that the left hand must release the object before the right B = {[A :: M] | A ∈ A, and M ∈ M} ∪ {>, ⊥} (1) hand grasps the object; while the intra-role constraint for where > indicates the initial behavior when the system left hand is that all fingers must simultaneously release the starts, and ⊥ indicates when the system terminates. object. As we can see from this example, although the coordina- Actor messages are processed in time. To obtain the time tees of inter-role and intra-role coordinations are different, instances at which an actor executes a specific behavior, we both constraints are to enforce certain orders among a define a time function T to project a specific actor behavior selected set of actions. to the time domain. The next section is to define two coordination operations Definitions 3 (Actor Behavior Time Function): The actor and study their expressiveness under the ARC model. behavior time function T : B → R≥0, where B is the actor III.COORDINATION OPERATIONS UNDER THE ARC behavior space of a given actor system, and R≥0 is non- MODEL negative real number set.

As we have mentioned in earlier sections, the underly- T ([A :: M]) = t ∈ R≥0 (2) ing computational model that the ARC model built upon is an asynchronous model, i.e., the Actor model, which and T (>) = 0, T (⊥) = inf. only guarantees the causal order. For applications with QoS requirements, such as real-time requirements, more restrictive orders and stronger guarantees are needed. In this B. Temporal Constraint Operator: Precede section, we introduce two primitive coordination operators, In the Actor model, as both actors and communications i.e., precede (t) which constraints the quantitative temporal are asynchronous, no order assumptions are made among order among two computational events, and select (Dp) actors, implicit or explicit, other than that the causal order which constraints the actors in their behavioral space, and is obeyed by the actor system. In this subsection, we study their properties and compositions. introduce a temporal coordination operator proceed which quantitatively constraints actor behaviors in the time domain. A. Terms and Notations It is worth pointing out that we assume that all the actors Before we present the two coordination operators, we first share the same global wall-clock time. introduce a few terms and notations that are used throughout Definitions 4 (Precede Operator: t): The precede op- the paper. erator constrains quantitative temporal relationship be- 1) Actor Behavior and Behavioral Space: Actor behav- tween two behavior sets. {[A11 :: M11], ··· , [A1n :: iors decide what type of messages an actor is able to process. M1n}] t {[A21 :: M21], ··· , [A2m :: M2m]} requires An actor may have many different behaviors. However, at that max{T ([A2j :: M2j])} − max{T ([A1i :: M1i])} = t, any given point in time, it can only manifest one behavior. where T is defined in Definition 3, t ≥ 0, 1 ≤ i ≤ n, For example, if we consider a wheel of a car as an actor, and 1 ≤ j ≤ m. As a syntactic sugar, we use T ([A2 :: M2]) − T ([A1 :: M1]) = t, when the sizes of the behavior floor levels. The requirement that if any of the smoke sets both equal to 1. detectors has triggered an alarm, the fire door at the level where the alarm is located shall be closed in fact involves There are three special cases with respect to the value two selections, the selection of smoker detectors and the t associated with the constraint, i.e., when t = 0, t is not selection of fire doors. specified, or t = inf. We discuss each in detail. Definitions 6 (Select Operator: Dp): Given a set of be- Case 1: when t = 0 (0) haviors in an actor system, B = {>, [A1 :: M1], ··· , [Ai :: A behavior precedes another by a time quantity of zero Mi], ··· , [An :: Mn], ⊥}, Dp(B) is function defined as amount indicates that the two involved behavior must happen Dp : 2B −→ B. Dp(B) = [Aj :: Mj] indicates that simultaneously. It is worth pointing out that as actor systems [Aj :: Mj] ∈ B, and [Aj :: Mj] satisfies the selection criteria are asynchronous, there is no guarantee that behaviors of p. When p = true, it is omitted from the notation. different actors will happen at the “exact” same wall-clock time point. We use the word “simultaneously” to indicate The definition of the select operator seems rather weak that the happenings of the behaviors are atomic and no inter- and does not provide much information other than that a medium states are visible. Hence the commonly encountered behavior in a behavior group is selected to participate in synchronization constraint becomes a special case of the a coordinated activities. In fact, the loosely defined select quantitative precede constraint. As a syntactic sugar, we operator provides the intra-role coordinators, i.e., the roles, define syn operator. a powerful tool to select appropriate member actors to fulfill Definitions 5 (Syn Operator): inter-role coordination without hard wiring to specific actors. The fire door and smoke detector scenario described above syn([A1 :: M1], [A2 :: M2]) ≡ gives an example. [A1 :: M1] 0 [A2 :: M2] (3) With the select operator, the coordination between smoke detectors and fire doors can be expressed as below: Case 2: when t is not specified () ( ) ( ) (5) When the qualitative time amount is not specified, Dp1 SD t Dp2 FD the precede constraint defines a precedence order where, SD and FD are smoker detectors and fire doors between the involved two behaviors. For instance, behavior spaces, p1 and p2 are selection criteria for the [A1 :: M1] [A2 :: M2] only restricts that [A1 :: M1] detector and door, respectively. happens before [A2 :: M2]. As it can be seen, when we use door-role and detector-role to categorize two groups of actors, i.e., doors and detectors, Case 3: when t = inf (inf ) respectively, the inter-role precedence constraint built upon The semantics that a behavior must happen infinitely long the intra-role coordination operation select becomes rather before another behavior in fact disables the second behavior static, and does not depend on which detector triggers an from happening. In other words, [A1 :: M1] inf [A2 :: alarm. M2] means actor A1’s processing the message M1 disables The select operator selects only one behavior from a given message M2 being dispatched on actor A2. group, multiple selections can be done through iteratively Based on the definition, the transitivity property of the use of the select operator. For instance, formula 6 non- precede operator becomes evident, i.e., deterministically selects two elements from a given behavior Property 1 (Transitive Property): group B: ([A1 :: M1] t1 [A2 :: M2]) ∧ ([A2 :: M2] t2 [A3 :: M3]) {Dp(B)} ∪ {Dp(B − {Dp(B)})} (6) −→ [A1 :: M1] t1+t2 [A3 :: M3] (4) where − represents set subtractions. Similar to introducing the syn operator as a syntactic sugar C. Behavioral Space Coordination Constraint Operator: for convenience purpose, we introduce multiple selection n Select operator Dp . n An actor behavior space as given in Definition 2 defines Definitions 7 (Multiple Selection Operator: Dp ): all the possible behaviors an actor system may have during n Dp (B) = {bi | bi ∈ B, 0 ≤ i ≤ n, n ≤ |B|, p(bi) = True} the lifetime of its execution. We define a coordination operator select (Dp) to describe a selection of participants where |B| is the cardinality of the behavior set B. When all in a coordinated group, where p is the selection criteria, behaviors that satisfy p are chosen, we use all in the place represented by a logic expression. of n. Furthermore, when p = True, we omit it from the As an example, consider a building instrumented with notation. many smoke detectors at different locations and different In the smoke detector example, if we would like to prevent on different criteria, or role abstraction. If we take the false alarm caused by smoke detector malfunction, and location of actors into consideration, we have behavior space require two smoke detectors simultaneously set on alarm for each room, i.e., Br1, Br2 and Br3, where before a fire door is closed, we can easily express the coordination requirement as shown below: Br1 ={[a1 :: Mon], [a1 :: Moff ], [a1 :: Mglr], [a2 :: Mon], [a :: M ], [a :: M ]}, 2 2 2 2 glr syn(Dp1(SD)) t Dp2(FD) (7) Br2 ={[a3 :: Mon], [a3 :: Moff ], [a3 :: Mglr], [a4 :: Mon], Before we complete this section, we give a few examples [a4 :: M4], [a4 :: Mglr]}, to illustrate the use of these operators, and show their ={[a :: M ], [a :: M ], [a :: M ]} expressiveness. Br3 5 on 5 off 5 glr Clearly, if we partition the behavior space based on a D. Examples different abstraction, such as on the type of messages, we In this subsection, we use a lighting system as an example have different subset of behavior space as following: to illustrate the use of proposed coordination operators. = {[a :: M ], [a :: M ], ··· , [a :: M ]}, Example: Consider a building with three rooms, BMon 1 on 2 on 5 on

room1, room2 and room3. Room1 and room2 have BMoff = {[a1 :: Moff ], [a2 :: Moff ], ··· , [a5 :: Moff ]}, two lights, a1 and a2 in room1, and a3 and a4 in BMglr = {[a3 :: Mglr], [a2 :: Mglr], ··· , [a5 :: Mglr]} room2, while room3 has only one light a5. All the lights work independently and they can be turned The role in the ARC model in fact defines these individ- on, off, or glittering. Furthermore, each light has ual behavior spaces. These subspaces are partitions of the a property to indicate if it is of an energy-saving system’s behavior space. In particular, we have type. Bri ∩ Brj = φ, if i 6= j Assuming all the lights are off when the lighting system ∩ = φ, if i 6= j starts, we study the following coordination scenarios: BMi BMj B = Br1 ∪ Br2 ∪ Br3 1) All lights in room1, a1 and a2, glitter simultaneously. 2) The light a5 in room3 glitters every 5 time units, and B = BMon ∪ BMoff ∪ BMglr glitters for 3 times. 1) All lights in room1, i.e., a and a , glitter simultane- 3) The lights in all three rooms with energy-saving prop- 1 2 ously. erty must be turned on within 5 time units, but the order in which they are turned on can be arbitrary. syn({[a1 :: Mglr], [a2 :: Mglr]}) (8) 4) In each room, all lights must be turned on within 5 time units. However, if there are both energy-saving or, it can also be represented by and non-energy-saving lights, the energy-saving lights all syn(D (Br1 ∩ BMglr )) (9) must be turned on before the non-energy-saving one. 5) There are two light glitters in room2. We require that The representation of (8) directly binds two spe- the two glitters come from two different lights. cific actors. Hence, if the number of lights in the 6) There are two light glitters in room2. We require that room changes, the constraint specified will have to the two glitters come from the same light, but we do make corresponding change. The representation of (9) not care which light the glitters come from. (which is based on the role, or behavioral space) is, 7) The two lights in room1 may take action of turning on the other hand, oblivious to such changes. on or glittering, we require that 2 time unit after the 2) The light a5 in room3 glitters every 5 time units, and room1’s two lights take their actions, a light in room2 glitters for 3 times. and a light in room3 must be simultaneously turned [a :: M ] [a :: M ] [a :: M ] on. 5 glr,1 5 5 glr,2 5 5 glr,3 ( ∩ ) (10) If we model the lights as actors, these actors accept three inf D Br3 BMglr types of messages, i.e., turn-on (Mon), turn-off (Moff ), The coordination constraint (10) disables any glittering and glitter (Mglr). The actor behavior space of the lighting in room3 after the light has glittered for 3 times. system in the building can hence be given by the following: 3) The lights in all three rooms with energy-saving property must be turned on within 5 time units, but the B ={[a1 :: Mon], [a1 :: Moff ], [a1 :: Mglr ], ··· , order in which they are turned on can be arbitrary. [a5 :: Mon ], [a5 :: Moff ], [a5 :: Mglr ]} all > 5 Dp (BMon ) (11) The lighting system’s behavior space, B, can be further partitioned into different small actor behavior spaces based where p is the criteria for energy saving property. 4) In each room, all lights must be turned on within 5 system’s operational semantics is given by the configuration time units. However, if there are both energy-saving transitions. The notations are adopted from the Actor model. and non-energy-saving lights, the energy-saving lights Definitions 8 (Actor Configuration): must be turned on before the non-energy-saving one. An actor configuration contains an actor map α, and

all multi-set of messages, µ. It is represented as: > 5 Dtrue(BMon )∧ all all hhα | µii (16) Dp (BMon ) D¬p(BMon ) (12) p energy saving where is the criteria for property. where the actor map α maps an actor’s unique identifier to room2 5) There are two light glitters in . We require that its current state and corresponding behavior. the two glitters come from two different lights. Definitions 9 (Role Configuration): A role configuration contains a set of actors playing the D (Br2 ∩ BM3 ) D(Br2 ∩ BM3 − {b}) (13) role, αγ , the role itself, γ, and a multi-set of messages

where b = D(Br2 ∩ BM3 ) stored in the mailboxes of the actors playing the role, µγ . It 6) There are two light glitters in room2. We require that is denoted as: the two glitters come from the same light, but we do not care which light the glitters come from. hhαγ , γ | µγ ii (17) We define a function F : B → A to extract corresponding actor(s) for a given actor behavior, and A. Operational Semantics for Precede ( ) function I : A → N to extract the unique identifier for t a given actor. With the two supporting functions, the Based on the specification of t, we have four different coordination requirement can be represented as (14). system transitions as below.

D (Br2 ∩ BMglr ) Dp(Br2 ∩ BMglr ) (14) Case 1: when two behaviors must be executed simultaneously, i.e, t = 0 (0). where is the property given below: α1, ··· , αi , ··· , αj , ··· , αn, γ , γ , ··· , γ | µ, mi , mj γ1 γ2 1 2 m γ1 γ2

p : I(F(Br2 ∩ BMglr )) = I(F(D(Br2 ∩ BMglr )) i i j j [αγ :: mγ ] 0 [αγ :: mγ ] The predicate p requires that the actor identiﬁer from −−−−−−−−−−−−−−−−−−−−−→1 1 2 2 the second select must be the same as the one chosen α1, ··· , αi [mi ], ··· , αj [mj ], ··· , αn, γ , γ , ··· , γ | µ from the ﬁrst select. γ1 γ1 γ2 γ2 1 2 m (18) 7) The two lights in room1 may take action of turning on or glittering, we require that 2 time unit after the Case 2: when the second behavior is disabled, i.e., t = inf ( ) room1’s two lights take their actions, a light in room2 inf . α1, ··· , αi , ··· , αj , ··· , αn, γ , γ , ··· , γ | µ, mi , mj and a light in room3 must be simultaneously turned γ1 γ2 1 2 m γ1 γ2 on. [αi :: mi ] [αj :: mj ] 2 γ1 γ1 inf γ2 γ2 D (Br1 ∩ (BMon ∪ BMglr )) −−−−−−−−−−−−−−−−−−−−−−→

2 syn{D(Br2 ∩ BMon ), D(Br3 ∩ BMon )} (15) α1, ··· , αi [mi ], ··· , αj , ··· , αn, γ , γ , ··· , γ | µ γ1 γ1 γ2 1 2 m (19) As we can see from these exercises that complex co- Case 3: when only qualitative temporal precedence is ordination constraints can be concisely represented by the required, i.e., t is not specified (). two proposed coordination operators, i.e., precede and se- In this case, the intermediate state becomes visible to the lect. Furthermore, the concept of roles, or behavior spaces, outside world while the first behavior is executed. In other enables more static and flexible constraint representations words, from system configuration perspective, we will see that are resilient to changes at the lower computation layer. one message is dispatched on its destination actor, while the Next section, we provide formal semantics for the two other may still remain in its mail-queue. operators.

α1, ··· , αi , ··· , αj , ··· , αn, γ , γ , ··· , γ | µ, mi , mj IV. OPERATIONAL SEMANTICSOF Precede AND Select γ1 γ2 1 2 m γ1 γ2 UNDERTHE ARCMODEL i i j j [αγ :: mγ ] [αγ :: mγ ] Before we give the operational semantics for the proposed −−−−−−−−−−−−−−−−−−−−→1 1 2 2 two coordination operators, we first introduce configurations α1, ··· , αi [mi ], ··· , αj , ··· , αn, γ , γ , ··· , γ | µ, mj that are used to define an ARC system’s operational se- γ1 γ1 γ2 1 2 m γ2 mantics. A configuration captures the system’s state and the (20) V. RELATED WORK Case 4: when quantitative temporal precedence is required, i.e., 0 ≤ t ≤ inf (t). Coordination models can be categorized into two classes, This is a more complicated case in which a timer is i.e., control-driven (also called dataflow-driven) and data- needed. When the precedent behavior is executed, it sets driven. A broad survey on coordination models and lan- the timer for the amount required. When the timer reaches guages can be found in [6], [7]. In data-driven models such 0, it immediately triggers the second behavior. Therefore, as Linda and its extensions [8], coordination tends to be two system configuration transitions are involved as given endogenous and embedded within computational entities. in (21) and (22). In control-driven models, coordination tends to be exoge- nous and isolated from computational entities. ABT [9], α1, ··· , αi , ··· , αj , ··· , αn, γ , ··· , γ , τ | µ, mi , mj γ1 γ2 1 m γ1 γ2 ROAD [10], IWIM, and CoLaS [11] are examples of control- driven coordination models. Hybrid approaches such as tuple i i j j [αγ :: mγ ] t [αγ :: mγ ] −−−−−−−−−−−−−−−−−−−−→1 1 2 2 centres and ReSpecT [12] combine the data-driven and control-driven models. α1, ··· , αi [mi ], ··· , αj , ··· , αn, γ , ··· , γ , τ[t] | µ, mj γ1 γ1 γ2 1 m γ2 Reo [13], [14], [15], [16] is built on IWIM and ABT (21) models. The abstract communication medium is a channel with exactly two ends and a constraint that relates the flow α1, ··· , αi , ··· , αj , ··· , αn, γ , γ , ··· , γ , τ[t] | µ, mj γ1 γ2 1 2 m γ2 of data at its ends. Channels are connected to make a circuit by joining channel ends together to form nodes. The coor- syn(τ[t] = 0, [αj :: mj ]) γ2 γ2 dination in Reo is abstracted as a Reo circuit specified by a −−−−−−−−−−−−−−−−−−−→ constraint automaton [13], while in the PBRD [17] model, α1, ··· , αi , ··· , αj [mj ], ··· , αn, γ , γ , ··· , γ , τ | µ coordinations are described as informal rule specifications on γ1 γ2 γ2 1 2 m (22) the resulting interactions of coordinated actors. A detailed comparison among the ARC, Reo and PBRD model can be found in [18]. B. Operational Semantics for Select (Dp) Some control-driven models, such as ROAD, CoLaS, The operational semantics of the select (Dp) operator performed by the roles is given the following interpretation. and Finesse [19], target the scalability issues of open distributed systems through group-based coordination models. The selection criteria of the Dp operator, p, is a role state dependent propositional function, and its selection space Most current role-based coordination models are based on is the behavior space of the role’s member actors . For a organizational concepts, where roles abstract coordination behaviors among participants that play the roles. Role-based given role γ, if [A :: M] ∈ Bγ , p(γ, [A :: M]) = True, coordination models are surveyed in [20]. and [A :: M] is selected, i.e., Dp(Bγ ) = [A :: M], then the behavior [A :: M] is either constrained by a inter-role Many recent researches have focused on application spe- coordination constraint imposed by a coordinator, or the cific coordination problems. For instance, Fok et.al. [21] execution of the behavior disables the rest of the behaviors proposed a new service provisioning based middle-ware that satisfy the same selection criteria p. Formula (23) gives to collaborate heterogeneous devices in wireless sensor its operational semantics. networks. Similarly, in order for software developer to adjust to ad hoc, heterogeneous, and changing hardware 1 i j n i j αγ , ··· , αγ , ··· , αγ , ··· , αγ , γ[Dp] | µγ , mγ , ··· , mγ architecture, Bouhadiba et.al. [22] proposed the notion of “contract” and associated it with a component-based descrip- l l pi≤l≤j (γ, αγ , mγ ) = true tion framework to describe complex hardware behaviors. An −−−−−−−−−−−−−−−−−−−→ event-based coordination model [23] extends the CEAOP by modeling coordination of concurrent adaptation rules as DD 1 i l j n EE αγ , ··· , αγ , ··· , αγ ··· , αγ , ··· , αγ , γ | µγ (23) explicit contexts to be applied in context-aware applications. A coordination model to manage collaborative real-time Disabling a behavior is done by permanently removing the editing work is proposed in [24]. A visual dataflow language message without dispatching the message to its destination tailored towards mobile applications is presented [25] as a actor. separate coordination language to express the interactions As we can see from the formal definition of select, among mobile components that operate on data streams. the selection from qualified message dispatching is not The focus of this paper is to define a small set of co- predetermined, and it is rather arbitrary. The decision is to ordination operators that are capable of expressing complex minimize unnecessary hard-wires and maximize the flexibil- coordination constraints among autonomous, concurrent and ity to accommodate the dynamic nature of the open systems. asynchronous entities in distributed and open systems. VI.CONCLUSIONAND FUTUREWORK [11] J. Cruz and S. Ducasse, “A group based approach for coor- Coordinatio Languages and Models In this paper, we have proposed two basic coordination dinating active objects,” , pp. 15–15, 1999. operators, i.e., precede (t) and select (Dp) and further used examples to illustrate the expressiveness of these operators [12] A. Omicini, “Formal ReSpecT in the A&A perspective,” in forming more complex coordination constraints. The Electronic Notes in Theoretical Computer Science, vol. 175, precede operator in essence controls the scheduling order no. 2, pp. 97–117, 2007. of message dispatches among actors; and the select operator [13] C. Baier, M. Sirjani, F. Arbab, and J. Rutten, “Modeling com- corresponds to a decision control over which actor a message ponent connectors in Reo by constraint automata,” Science of is dispatched to. We feel these two coordination operations Computer Programming, vol. 61, no. 2, pp. 75–113, 2006. together with first order logic operations are functionally [14] S. Tasharofi and M. Sirjani, “Formal modeling and con- complete with respect to expressing coordination constraints. formance validation for WS-CDL using Reo and CASM,” However, the formal proof of its completeness, or finding a Electronic Notes in Theoretical Computer Science, vol. 229, counter-example that indicates its insufficiency, is yet to be no. 2, pp. 155–174, 2009. done and will be our future research focus. [15] F. Arbab, L. As¸tefanoaei,˘ F. de Boer, M. Dastani, J. Meyer, and N. Tinnermeier, “Reo connectors as coordination arti- ACKNOWLEDGMENT facts in 2APL systems,” Intelligent Agents and Multi-Agent The research is supported by NSF CAREER Award (CNS Systems, pp. 42–53, 2008. 0746643) and CNS 1035894. [16] N. Kokash and F. Arbab, “Applying Reo to service coordi- REFERENCES nation in long-running business transactions,” in Proceedings of the 2009 ACM symposium on Applied Computing. ACM, [1] S. Ren, Y. Yu, N. Chen, K. Marth, P. Poirot, and L. Shen, 2009, pp. 1381–1382. “Actors, Roles and CoordinatorsA Coordination Model for Open Distributed and Embedded Systems,” in Coordination [17] C. Talcott, “Policy-based coordination in pagoda: A case Models and Languages. Springer, 2006, pp. 247–265. study,” Electronic Notes in Theoretical Computer Science, vol. 181, pp. 97–112, 2007. [2] G. Agha, “Actors: a model of concurrent computation in distributed systems,” AITR-844, 1985. [18] C. Talcott, M. Sirjani, and S. Ren, “Comparing three coordination models: Reo, ARC, and PBRD,” Science of Computer [3] G. Agha, P. Thati, and R. Ziaei, “Actors: a model for reason- Programming, 2009. ing about open distributed systems,” in Formal methods for distributed processing. Cambridge University Press, 2001, [19] A. Berry and S. Kaplan, “Open, distributed coordination with p. 176. finesse,” in Proceedings of the 1998 ACM symposium on Applied Computing. ACM, 1998, p. 184. [4] L. Lamport, “Time, clocks, and the ordering of events in a [20] G. Cabri, L. Ferrari, and F. Zambonelli, “Role-based ap- distributed system,” Commun. ACM, vol. 21, no. 7, pp. 558– proaches for engineering interactions in large-scale multi- 565, 1978. agent systems,” Software Engineering for Multi-Agent Sys- tems II, pp. 360–361, 2004. [5] N. Chen and S. Ren, “Building a coordination framework to support behavior-based adaptive checkpointing for open [21] C. Fok, G. Roman, and C. Lu, “Enhanced coordination in distributed embedded systems,” in Proceedings of the 40th sensor networks through flexible service provisioning,” in Annual Hawaii International Conference on System Science, Coordination Models and Languages. Springer, 2009, pp. 2007. 66–85.

[6] G. Papadopoulos and F. Arbab, “Coordination models and [22] T. Bouhadiba and F. Maraninchi, “Contract-based coordina- languages,” Advances in Computers, vol. 46, pp. 329–400, tion of hardware components for the development of em- 1998. bedded software,” in Coordination Models and Languages. Springer, 2009, pp. 204–224. [7] F. Arbab, “Composition of Interacting Computations,” Inter- active Computation, pp. 277–321, 2006. [23]A.N u´nez˜ and J. Noye,´ “An event-based coordination model for context-aware applications,” in Proceedings of the 10th [8] G. Picco, A. Murphy, and G. Roman, “LIME: Linda meets international conference on Coordination models and lan- mobility,” in Proceedings of the 21st international conference guages. Springer-Verlag, 2008, pp. 232–248. on Software engineering. ACM, 1999, pp. 368–377. [24] A. Imine, “Coordination model for real-time collaborative [9] F. Arbab, “Abstract behavior types: A foundation model for editors,” in Coordination Models and Languages. Springer, components and their composition,” in Formal Methods for 2009, pp. 225–246. Components and Objects. Springer, 2003, pp. 33–70. [25] A. Lombide Carreton and T. DHondt, “A Hybrid Visual [10] A. Colman and J. Han, “Coordination systems in role-based Dataﬂow Language for Coordination in Mobile Ad Hoc Net- adaptive software,” in Coordination Models and Languages. works,” in Coordination Models and Languages. Springer, Springer, 2005, pp. 63–78. 2010, pp. 76–91.