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

1. Separating Concerns: Actors, Coordination Constraints, and Implementation Protocols in a Reflective Architecture Gul Agha University of Illinois at Urbana-Champaign http://osl.cs.uiuc.edu

2. 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 Collaborators

3. The Actor Model A Model of Distributed Object Computation State Interface Thread Interface Procedure State Thread Messages Procedure Interface State Thread Procedure

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

5. Ticker Actor Specification • States: T(n) -- n a number • Messages: tick, time@c -- c an actor id • Reaction Rules: ( t | T(n) ) t  tick ==> ( t | T(n+1) ) t  tick ( t | T(n) ) t  time@c ==> ( t | T(n) ) c  reply(n)

6. Ticker Actor Specification • States: T(n) -- n a number • Messages: tick, time@c -- c an actor id • Reaction Rules: ( t | T(n) ) t  tick ==> ( t | T(n+1) ) t  tick ( t | T(n) ) t  time@c ==> ( t | T(n) ) c  reply(n)

7. (t|T(2)) ttick ... ... (c|..t..) (t|T(3)) ttick ... ttime@c (t|T(n)) (c|..t..) ttick creply(3) ... (c|..t..) Ticker Actor Scenario dlv(ttick) ... c ... dlv(ttime@c)

8. The Actor Model send ready create

9. Operational Semantics Notion of equivalence

10. May versus Must Testing

11. Join Continuation a2 a1 v1 v2 f (v1,v2)

12. Local Synchronization Constraints • Recipient Actor may not be ready to accept a message in current state

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

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

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

16. SpecDiagrams

17. 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) = ∅

18. Example: Memory Cell Specification

19. Example: Specification of Two Tickers

20. A UML Specification and Its SpecDiagram

21. Refining Specifications

22. Reasoning about SpecDiagrams • Trace-based equivalence relation for may-testing • Executable Semantics in Term Rewriting (Thati, Agha & Talcott 2004)

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

24. Coordinating Robot Arms Synchronizer SimulRobot (actor leftHand, rightHand) { Constrain lhand.release ( ) : rhand.grasp ( ) }

25. Transforming Constraints • Dynamically customize schedulers S. Frolund, Coordinating Distributed Objects, MIT Press

26. Abstracting Interaction • Interaction may involve more than synchronization constraints • Separate interaction policy from protocols used to implement policy

27. What is a Protocol? • A protocol defines a role for each participating actor relative to the protocol • Primary Backup • Periodic Checkpoint

28. Specifying Protocols Protocol Auragen-backup { parameter declarations requirements protocol methods and initialization role definitions }

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

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

31. Dynamic Environment • Unpredictable requirements • Heterogeneity, e.g. Mobile Agents or Devices

32. 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)

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

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

35. 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time@c)/ }=> (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

36. Monitored Ticker Scenario (tm|M(t,mc,2,0)) (t|T(2)) ttick ... dlv(ttick) ... c ... ... (c|..t..) (tm|M(t,mc,3,0)) (t|T(3)) ... ttick ttime@c mclog(t,3,0) (c|..t..) (tm|M(t,mc,3,1)) (t|T(n)) ttick dlv(ttime@c) creply(3) ... (c|..t..)

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

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

39. 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 GetLog(client) 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.

40. 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  getLog@c, • collects reports from each node in the system, and • sends the log reply: LogReply(c,L) = c  getLogReply(L)@ls.

41. Logger Rule (la : logger(A)) =={deliver(av)/ seta(a,Log, geta(a,Log)+{av})}==> (la : logger(A)) if a in A

42. Reporter Rule (ra : reporter(A)) (ra  sendLog@c) == { /seta(a,Log,{}) for a in A}==> (ra : reporter(A)) (c  report(L)@ra) where L = Union(a in A, get(a,Log))

43. Log Server Rules (ls : logServerI(R)) ( ls  getLog@c ) ==> (ls : logServerW(R,c,{},R)) {r  sendReport@ls | 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 )

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

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

46. 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  sendLog@ls) or • (ls  report(L)@ra)

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

48. 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 )

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

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