Separating Concerns:
This presentation is the property of its rightful owner.
Sponsored Links
1 / 76

Gul Agha University of Illinois at Urbana-Champaign osl.cs.uiuc PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Separating Concerns: Actors, Coordination Constraints, and Implementation Protocols in a Reflective Architecture. Gul Agha University of Illinois at Urbana-Champaign Mark Astley Svend Frolund YoungMin Kwon Ian Mason Jose Meseguer Shangping Ren Koushik Sen.

Download Presentation

Gul Agha University of Illinois at Urbana-Champaign osl.cs.uiuc

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Separating Concerns: Actors, Coordination Constraints, and Implementation Protocols in a Reflective Architecture

Gul Agha

University of Illinois at Urbana-Champaign

Mark Astley

Svend Frolund

YoungMin Kwon

Ian Mason

Jose Meseguer

Shangping Ren

Koushik Sen

Scott Smith

Dan Sturman

Carolyn Talcott

Prasanna Thati

Nalini Venkatasubramanian

Reza Ziaei


The Actor Model

A Model of Distributed Object Computation














The Actor Model

  • Actor system - collection of independent agents interacting via message passing

  • Features

    • Acquaintances - initial, created, acquired

    • History Sensitive

    • Asynchronous fair communication

  • An actor can:

    • create a new actor and initialize its behavior

    • send a message to an existing actor that is an acquaintance

    • change its local state or behavior

Ticker Actor Specification

  • States: T(n) -- n a number

  • Messages: tick, [email protected] -- c an actor id

  • Reaction Rules:

    ( t | T(n) ) t  tick


    ( t | T(n+1) ) t  tick

    ( t | T(n) ) t  [email protected]


    ( t | T(n) ) c  reply(n)

Ticker Actor Specification

  • States: T(n) -- n a number

  • Messages: tick, [email protected] -- c an actor id

  • Reaction Rules:

    ( t | T(n) ) t  tick


    ( t | T(n+1) ) t  tick

    ( t | T(n) ) t  [email protected]


    ( t | T(n) ) c  reply(n)









t[email protected]







Ticker Actor Scenario


... c ...

dlv(t[email protected])

The Actor Model




Operational Semantics

Notion of equivalence

May versus Must Testing

Join Continuation





f (v1,v2)

Local Synchronization Constraints

  • Recipient Actor may not be ready to accept a message in current state

Separate Synchronization Constraints

  • Abstract Data Types separate the interface (what )from the representation (how)

  • Synchronization constraints express when in terms of what

    constrain get ( ) when empty?(buffer)

    constrain put ( ) when full?(buffer)

    Conditions are functions over the state.

Actor Languages

Primitives extended by

  • join continuations

  • local synchronization constraints

  • Synchronous communication

    Translated to primitive (kernel) actor language

    (see Mason & Talcott U2K)

    Translation preserves actor semantics

How to Specify Actor Systems

  • SpecDiagrams (Smith & Talcott):graphical notation for specifying message passing behavior of open distributed object systems

  • Draws upon concepts from various formalisms

    • Dynamic name generation and name passing as in the pi-calculus

    • Asynchronous communication and locality discipline on names as in concurrent object models such as Actors

    • Imperative notions such as variables, environments, and assignments

    • Logical features such as assertions and constraints, which are appropriate for specification languages.


SpecDiagrams Syntax

D := 0 | ae | a(x):D | D1 // D2 | (νa) D | recX:D | X (asynch π)

| D1;D2 | D1 + D2 | fork(D) (control)

| { γ : D } | x := e

| pick(x) :=e (imperative)

| pick(x) : D | wait(∅) (logical)

Let rcp(D) be the set of all free names in D that occur as an input subject.

Uniqueness of names: If D1 ; D2 are two top-level diagrams, then rcp(D1) ∩ rcp(D2) = ∅

Example: Memory Cell Specification

Example: Specification of Two Tickers

A UML Specification and Its SpecDiagram

Refining Specifications

Reasoning about SpecDiagrams

  • Trace-based equivalence relation for may-testing

  • Executable Semantics in Term Rewriting

    (Thati, Agha & Talcott 2004)

Policies as Coordination Constraints

  • Local synchronization constraints express constraints over the history of single actor

  • Synchronization between actors

    • precedence of actions

    • “atomic” actions

    • real-time constraints

    • Example: two robots with a shared task

  • Express coordination constraints modularly

  • Real-time constraints

Coordinating Robot Arms

Synchronizer SimulRobot (actor leftHand, rightHand) {


lhand.release ( ) : rhand.grasp ( )


Transforming Constraints

  • Dynamically customize schedulers

S. Frolund,

Coordinating Distributed Objects, MIT Press

Abstracting Interaction

  • Interaction may involve more than synchronization constraints

  • Separate interaction policy from protocols used to implement policy

What is a Protocol?

  • A protocol defines a role for each participating actor relative to the protocol

  • Primary Backup

  • Periodic Checkpoint

Specifying Protocols

Protocol Auragen-backup {

parameter declarations


protocol methods and initialization

role definitions


Protocol Instances

  • Protocol instances are runtime instantiatons of protocols:

    • A participant actor has a role in a protocol

    • An actor may participate in multiple protocols

    • Protocol methods may be invoked on instances

Transparent Implementation of Protocols

Reflection enables protocol implementations to be independent of application implementations

  • A meta-level actor describes functionality of actor.

  • To change the application’s behavior, modify the relevant meta-actor.

Dynamic Environment

  • Unpredictable requirements

  • Heterogeneity, e.g. Mobile Agents or Devices

The Two Level Actor Model

  • Stratify actors into

    • Base-level actors (application)

    • Meta-level actors (OS, communication, middleware)

  • Meta-level actors

    • can examine/modify runtime state and annotations of base-level objects.

    • notified when base-level events of interest to them occur.

    • distributed groups of meta-actors cooperate to provide local and system wide services.

      (Venkatasubramanian & Talcott)

TLAM structure/syntax

  • TLAM = < Net, TLAS, loc >

    • Net - distributed computer network with

      • processor nodes

      • communication link between nodes

    • TLAS - a two level actor system with

      • base- and meta-level actor states

      • base- and meta-level messages

      • annotations on base-level actors and messages

      • reaction rules for messages and events

    • loc - distribution function mapping actors to nodes

TLAM semantics

  • Labeled transition system

    • Trans C Lab  C

  • A configuration C = < lc, nq, ac>

    • a (hypothetical) global snapshot

    • lc - link configuration -- messages in transit

    • nq - node buffer configuration -- messages queued

    • ac - actor configuration -- base- and meta-level actor states

  • Two kinds of transitions:

    • communication -- moving messages

    • execution -- computation step followed by event handling

Ticker Monitor Rules

(tm | M(t,mc,tx,rx))

={dlv(ttick)/ }=>

(tm | M(t,mc,tx+1,rx))

(tm | M(t,mc,tx,rx))

={dlv(t[email protected])/ }=>

(tm | M(t,mc,tx,rx+1)) mc  log(t,tx,rx+1,c)

(tm | M(t,mc,tx,rx)) tm  reset

={ /t:=T(0)}=>

(tm | M(t,mc,0,0)) mc  reset-ack

Monitored Ticker Scenario






... c ...







t[email protected]






dlv(t[email protected])




TLAM modeling

  • System

    • set of configurations closed under TLAM transitions

  • System properties specified in terms of properties of

    • configurations

    • transitions

    • admissible computations

  • Restriction to base level measures meta-level effect on functionality

Log Service Example

  • Logging Service

    • logs messages delivered to a given set of base actors and when requested reports the messages logged since the previous request.

  • To provide the service, we specify a set of meta-actor behaviors and configure a service based on these behaviors.

Logging Service Specification

A system S provides logging service w.r.t.

  • loggable actors A

  • request GetLog : ActorId  Message and

  • reply LogReply : ActorId  Message*  Message

    if every request


    gets a unique reply,

    LogReply(client, log), s.t.

  • log is a subset of the messages delivered to loggable actors,

  • no messages in log have previously been reported.

  • every message delivered to a loggable actor will eventually be reported.

Logging Behavior

A system S with logging behavior has

  • a logger on each node, that does the recording for the loggable actors on its node,

  • a reporter on each node, that does the reporting for the loggable actors on its node, and

  • a log server ls (one for the system) that

    • receives log requests: GetLog(c) = ls  [email protected],

    • collects reports from each node in the system, and

    • sends the log reply: LogReply(c,L) = c  getLogReply(L)@ls.

Logger Rule

(la : logger(A))


seta(a,Log, geta(a,Log)+{av})}==>

(la : logger(A))

if a in A

Reporter Rule

(ra : reporter(A)) (ra  [email protected])

== { /seta(a,Log,{}) for a in A}==>

(ra : reporter(A)) (c  report(L)@ra)

where L = Union(a in A, get(a,Log))

Log Server Rules

(ls : logServerI(R)) ( ls  [email protected] )


(ls : logServerW(R,c,{},R))

{r  [email protected] | r in R }

(ls : logServerW(R,c,L,R'+r)) ( ls  report(L')@r )


(ls : logServerW(R,c,L+L',R')) if r not in R’

(ls : logServerW(R,c,L,{}))


(ls : logServerI(R)) ( c  getLogReply(L)@ls )

Logging Non-interference Requirement

A system S satisfies the logging non-interference requirement if:

  • non-logging meta actors do not set Log attributes

  • the only messages sent to logging meta actors by non-logging meta actors are log request messages addressed to the log server

Logging Theorems

  • Theorem 1 (Base-meta noninterference)

    • If system S has Logging Behavior, then Log meta-actors of S preserve base-level behavior.

  • Theorem 2 (Behavior implies service)

    • If system S has Logging Behavior and satisfies the logging initial conditions and non-interference requirements, then S provides logging service.

Theorem 2 Proof -- LogOk

LogOk holds for all system configurations:

  • If the log server is idle, then there are no undelivered internal logger system messages.

  • If the log server is waiting for reports from R', then there are no undelivered messages to or from the other reporters, and for each reporter ra in R' there is a single undelivered message, either

    • (ra  [email protected])


    • (ls  report(L)@ra)

Theorem 2 Proof - Responsiveness

Every request receives a unique reply

  • by fairness messages will be delivered (once)

  • by LogOk a waiting log server will get the expected replies and respond to the request it is handling

QoS Broker Case Study

  • Multimedia (MM) Server Design & Management

    • Multimedia Load Management

      • Adaptive scheduling of incoming MM requests

      • Reconfigure data to optimize servicing of requests

    • Cost-based QoS metrics

  • QoS Broker

    • coordinates activities in a distributed MM system

      • interactions between multiple QoS sessions

      • interactions across multiple system services

    • manages requests -- admission control

    • manages data placement activities

      (Venkatasubramanian, Talcott & Agha, TOSEM 2004 )

Light-weight Verification Methods

  • Concolic Testing

    • Combine symbolic and concrete testing

  • Runtime Verification

    • Monitoring specifications

  • Probabilistic Models

    • Statistical Model Checking

      As opposed to

  • Theorem Proving

  • Model Checking all states

Decentralized Runtime Monitoring

  • Distribute property

    • Properties expressed with respect to a process

    • Local properties at every process

  • Decentralize Monitoring

    • Maintain knowledge of global state at each process

    • Update knowledge with incoming messages

    • Attach knowledge with outgoing messages

    • At each process check safety property against local knowledge

Decentralized Monitoring Example

“If a receives a value from b then b calculated the value after receiving request from a”

valRcv → @b((valComputed  @a(valReq)))

valComputed  @a(valReq)


(valComputed  @a(valReq))







valRcv → @b((valComputed  @a(valReq)))

Past time Distributed Temporal Logic (pt-DTL)

  • Based on epistemic logic

    • [Aumann76][Meenakshi et. al. 00]

  • Properties with respect to a process, say p

  • Interpreted over a sequence of global states that the process p is aware of

    • Each process monitors the properties local to it

    • No need for extra messages to create a relevant portion of global state

    • KnowledgeVector keeps track of relevant global state that can effect a property.

Remote Expressions in pt-DTL

  • Remote expressions – arbitrary expressions related to the state of a remote process

  • Propositions constructed from remote and local expressions

    “If my alarm is set then eventually in past difference between my temperature and temperature at process b exceeded the allowed value”

    alarm → ((myTemp - @btemp) > allowed)

Safety in Airplane Landing

“ If my airplane is landing then the runway that the airport has allocated matches the one that I am planning to use”

landing → (runway = @airportallocRunway)

Leader Election Example

“If a leader is elected then if the current process is a leader then, at its knowledge, none of the other processes is a leader”

elected → (state=leader → /\i≠j(@j(state ≠ leader)))

pt-DTL syntax and semantics

  • Fi ::= true | false | P(Ei) | : Fi | FiÆ Fi propositional

    | ¯ Fi | ¡ Fi | Fi | Fi S Fi temporal

    | @jFj epistemic

  • Ei ::= c | vi2 Vi | f(Ei) functional

    | @jEj epistemic

  • c : constant

  • vi : variable at process I

  • P(Ei) : predicate on Ei

  • f(Ei) : function f applied to Ei

  • @jEj : expression Ej at process j

  • ¯ Fi : previously Fi

  • ¡Fi : always in past Fi

  • Fi : eventually in past Fi

  • Fi S F’i : Fi since F’i

  • @jFj: Fj at process j

Interpretation of @jEj at process i
















Since, at s23 p2 is aware of s12 of p1

value of @1E in s23 at p2 = value of E in s12 at p1

Monitoring Algorithm

  • Requirements

    • Should be fast so that online monitoring is possible

    • Little memory overhead

    • Additional messages sent should be minimal; ideally zero

  • KnowledgeVector

    • Motivated by Vector Clocks

    • Unlike Vector Clocks size independent of number of processes


  • KV is a vector

    • one entry for each process appearing in formula

    • KV[j] denotes entry for process j

    • KV[j].seq is the sequence number of last event seen at process j

    • KV[j].values stores values of j-expressions and j-formulae

KnowledgeVector Algorithm

  • [internal event]: (at process i)

    store eval(Ei,si) and eval(Fi,si) for each @iEi and @iFi in KVi[i].values

  • [send m]:

    KVi[i].seq à KVi[i].seq + 1. Send KVi with m as KVm

  • [receive m]:

    for all j, if KVm[j].seq > KVi[j].seq then

    • KVi[j].seq à KVm[j].seq

    • KVi[j].values à KVm[j].value

    • store eval(Ei,si) and eval(Fi,si) for each @iEi and @iFi in KVi[i].values




































¡(Y¸ @1X) at p2


DIANA Architecture



Modeling Large ScaleDistributed Systems

  • Each node is modeled by a finite state machine

  • Cannot represent the state of all nodes as a product of individual states

    • 1000 nodes of 5 state machines  51000 states

Models of Time

  • Global synchronous wall clock

    • Synchronization is too tight

    • Too detailed an execution model

  • Asynchronous, distributed time

    • Vector clocks are too expensive

    • Application behavior is complicated

      Need a more expressive model of time:

  • Notion of distance and distribution.

  • Space-Time cone of causal influence.


Future causality




Not Causally related



Past causally connected


Light Cones

WSN modeling

  • Statistically abstract the state of a WSN

    • Represent a state as a probability mass function (pmf)

    • e.g.: 90% of the nodes are in ‘READY’ state.

  • Model a WSN as Discrete Time Markov Chain (DTMC)

  • Periodic sampling of a real WSN  DTMC estimation






  • With PCTL like logics, ‘P[X=A] > .3 is always true’ is always false regardless of initial pmfs

  • However if 50 out of 100 nodes are in A state and the others are in B state =>50% of the nodes are always in A state.

  • iLTL can specify this situation because it works on pmf transitions

iLTL Formula

  • Syntax

iLTL Formula:atomic propositions

  • At least 10% more nodes are in READY state than in IDLE state

    • P[X=READY] > P[X=IDLE] + 0.1

    • P[X=READY] - P[X=IDLE] > 0.1

  • Expected Queue length is less than 2

    • 1*P[Q=S1] + 2*P[Q=S2] + 3*P[Q=S3] < 2

  • Availability of a system X is 10% larger than that of a system Y

    • P[X=READY] > P[Y=READY] + 0.1

Main Theorem

  • If

    • Markov matrix M is diagonalizable

    • Absolute value of second largest eigenvalue of M is strictly less than 1

    • For all inequalities of an iLTL formula Ψ, the steady state expected value of LHS is not equal to its RHS

  • Then

    • There is a bound N after which all inequalities of Ψ become constants

Model Checking Algorithm



Example Markov Reward Model

  • Example:

    • send/ack

    • S={s, ra, rX, XX, d}

    • Expected energy consumption

Model Checking an Agilla Application

  • Agilla is an agent middleware for sensor networks

  • Markov Chain Agilla=(S,M),

    • S = {Halt, Wait, Arrive, Leave }

    • M is 4x4 matrix that is estimated

  • Energy consumption for each state

    • r = [0,1,3,10] pA for each state from 3V source

    • Expected energy consumption

    • E[energy] = r*x, where xi = P [X=si]

Model Estimation

  • Sampling from 20 motes -> Markov model estimation

Model Checking

Model: Markov chain Agilla has states : { H, W, A, L}, transits by : [ 0.5405, 0.4039, 0.0175, 0.7020; 0.0567, 0.3765, 0.3444, 0.1044; 0.2973, 0.0381, 0.5593, 0.0000; 0.1055, 0.1815, 0.0788, 0.1936]


a : 1*P{Agilla=W}+ 3*P{Agilla=A}+ 10*P{Agilla=L} > 2.25,

b : 1*P{Agilla=W}+ 3*P{Agilla=A} +10*P{Agilla=L} < 2.3 <>[] ~ (a /\ b)

Is the expected energy between 2.25 to 2.3pW?


  • Programming Abstractions

  • Richer models of time, state, and transitions

    • Probabilistic models and properties

  • Lightweight Formal Methods

  • Login