Separating Concerns:
1 / 76

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

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Gul Agha University of Illinois at Urbana-Champaign osl.cs.uiuc' - angus

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

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 specification of two tickers
Example: Specification of Two Tickers

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



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