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

Gul agha university of illinois at urbana champaign osl cs uiuc

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

The Actor Model

A Model of Distributed Object Computation














The actor model1

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

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 specification1

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 scenario









t[email protected]







Ticker Actor Scenario


... c ...

dlv(t[email protected])

The actor model2

The Actor Model




Operational semantics

Operational Semantics

Notion of equivalence

May versus must testing

May versus Must Testing

Join continuation

Join Continuation





f (v1,v2)

Local synchronization constraints

Local Synchronization Constraints

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

Separate synchronization constraints

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

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

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

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: Memory Cell Specification

Example specification of two tickers

Example: Specification of Two Tickers

A uml specification and its specdiagram

A UML Specification and Its SpecDiagram

Refining specifications

Refining Specifications

Reasoning about specdiagrams

Reasoning about SpecDiagrams

  • Trace-based equivalence relation for may-testing

  • Executable Semantics in Term Rewriting

    (Thati, Agha & Talcott 2004)

Policies as coordination constraints

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

Coordinating Robot Arms

Synchronizer SimulRobot (actor leftHand, rightHand) {


lhand.release ( ) : rhand.grasp ( )


Transforming constraints

Transforming Constraints

  • Dynamically customize schedulers

S. Frolund,

Coordinating Distributed Objects, MIT Press

Abstracting interaction

Abstracting Interaction

  • Interaction may involve more than synchronization constraints

  • Separate interaction policy from protocols used to implement policy

What is a protocol

What is a Protocol?

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

  • Primary Backup

  • Periodic Checkpoint

Specifying protocols

Specifying Protocols

Protocol Auragen-backup {

parameter declarations


protocol methods and initialization

role definitions


Protocol instances

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

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

Dynamic Environment

  • Unpredictable requirements

  • Heterogeneity, e.g. Mobile Agents or Devices

The two level actor model

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 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

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

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

Monitored Ticker Scenario






... c ...







t[email protected]






dlv(t[email protected])




Tlam modeling

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

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

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

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

Logger Rule

(la : logger(A))


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

(la : logger(A))

if a in A

Reporter rule

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

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

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

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

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

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

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

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

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

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

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 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

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

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

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 @ j e j at process i

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

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

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


D i a na architecture

DIANA Architecture



Modeling large scale distributed systems

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

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

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

iLTL Formula

  • Syntax

Iltl formula atomic propositions

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

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

Model Checking Algorithm




Example markov reward model

Example Markov Reward Model

  • Example:

    • send/ack

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

    • Expected energy consumption

Model checking an agilla application

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

Model Estimation

  • Sampling from 20 motes -> Markov model estimation

Model checking

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