A Role-Based Coordination Model and its Realization

ions for these system behaviors; this enables us to conceal the dynamicity and scale of the ODE environment. In addition to representing abstractions for the properties of the system behaviors, roles also are responsible for actively coordinating their players to achieve coordination requirements. Roles serve as an abstraction by specifying membership criteria, i.e., a static specification of functional behaviors that computation actors belonging to the role must have. The role is responsible for managing the integrity of its membership. Roles also actively coordinate their member actors in order to satisfy coordination requirements. The intra-role coordination coerced by roles realizes and complements the inter-role coordination enacted by coordinators. Membership management behavior Before a role can perform its membership management activities, the behavior abstraction, i.e. the role membership criteria, must be specified. We use logic expressions of actor states and operations to describe the criteria. More specifically, the role membership criteria are represented by a tuple < O, A >, where O is a set of message types (operations) that an actor must be able to process, and A is a set of attributes that actors need to display for joining the role. Any actor that is controllable by coordination rules must declare its own functional behavior, using the same tuple format. Upon observing a new event or a ready event from a computation actor, the role acquires the newly updated behavior from the computation actor and compares it against its membership criteria. It then determines whether the actor should be added to the membership list (the actor behavior matches the role criteria), ignored (the actor was not a member and its behavior does not match the role criteria), or removed from the role (the actor was a member but its new behavior does not match the role criteria). More precisely, a role’s management behavior is a mapping from a set of actor events to membership updates. Note that according to the semantics of the actor model, actors are free to reject exposing their internal states to the roles. This allows an actor to reject coordination. Such actors will belong to a “default” role that performs no coordination. Each role has a distinct purpose. This requirement disallows overlapping criteria among roles, eliminating the possibility that conflicting constraints will be imposed on an actor by multiple roles simultaneously. This requirement has its basis in the underlying actor model: each actor has only a single thread of control and therefore may play only one role at any given time. More precisely, let C(γ) denote the role membership criteria declared by role γ, and let B(α) denote the functional behaviors provided by an actor α. As we have discussed, the actor functional behaviors and the membership criteria are both represented as a comparable tuple < O, A >. To be added to a role, the actor functional behaviors have to match the role’s membership criteria. A and Γ denote the set of actors and roles in the system, respectively, and F : A → Γ is a function that assigns an actor to a role. At any given time, well-defined roles and actors in a system must satisfy the following requirements: 1. Roles are exclusive: role declared behaviors do not overlap, i.e., ∀γ, γ′ ∈ Γ : C(γ) ∩ C(γ′) = φ 2. Roles are exhaustive: every actor belongs to one of the roles, i.e.,