Programming Clouds for Scalability and Security: A...

Programming Clouds for Scalability and Security: A Tutorial on Actor Languages

Gul Agha

University of Illinois at Urbana-Champaignhttp://osl.cs.uiuc.edu

UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN | ENGINEERING AT ILLINOIS | INFORMATION TRUST INSTITUTE

Acknowledgements

Work reported here is joint with Carl Hewitt, Chris Houck, WooYoung Kim Pohao Chang, Rajesh Karmani, Mark Astley, Dan Sturman, Stas Negara, Rajendra Panwar, Svend Frolund, Reza Shiftehfar among others.

Supported in part by AFOSR/AFRL Air Force Research Laboratory and the Air Force Office of Scientific Research under agreement FA8750-11-2-0084 for the Assured Cloud Computing at the University of Illinois at Urbana-Champaign, and by the National Science Foundation under grant NSF CCF 14-38982.

211/6/2014 Gul Agha, University of Illinois


3

Actor Languages and Frameworks

Erlang E Axum Stackless Python Theron (C++) RevActor (Ruby) Dart …

Scala Actors ActorFoundry SALSA Kilim Jetlang Actor’s Guild Clojure Fan Jsasb … still growing


Presenter

Presentation Notes

Brought us lot of funding, revived the Actor model for client-side computing. Why you should care?


Example Actor Applications Martian Rover (1990s) Charm++ molecular dynamics software Twitter's message queuing LiftWeb Framework (Scala for web applications) Image processing in MS Visual Studio 2010 Vendatta game engine (Erlang)

Battelship gallactica has 1M people playing Facebook Chat System (Erlang) LinkedIn

11/6/2014 4Gul Agha, University of Illinois


Examples of Actor-oriented Frameworks Distributed programming

EJBs, services in SOA

Dataflow programming Pipeline stages in stream processing (StreamIt) Nodes in visual computing (Labview)

Reactive, event-driven programming Embedded computing (Ptolemy) Sensor networks (ActorNet)

Operating Systems Singularity, Unix processes + pipes

11/6/2014 Gul Agha, University of Illinois 5

Presenter

Presentation Notes

Criticised for being too general and presumedly inefficient due to message passing overhead… No incentive for client-side computing since there was no parallelism


6

Characteristics of the Actor Model

Computation broken into autonomous, concurrent agents called actors: Actors do not share state Analogous to animals in natural systems.

Each actor operates asynchronously The rate at which an actor operates may vary. An actor is like a virtual processor.

An actor may interact with other actors.

[Actors: A Model of Concurrent Computation in Distributed Systems," Gul Agha. MIT Press, 1986.]


Presenter

Presentation Notes

Why a significant revival in the multicore era? Although EJBs, SOA, stages in stream computing, visual computing Last bullet point allows communication-computation overlap


Distribution and Parallelism

Each actors represents a point in a virtual space.

Events at an actor are ordered linearly.

Events may change the state of an actor

7

a

e1

e3

a'

e'1

e'2

e2

time



Message-Passing There is no action at a distance An actor a an only affect a by sending it a

message. Messages are asynchronous

8

aa



Fairness Each actor makes progress if it can: If multiple actors execute on a single processor,

each actor is scheduled. Every messages is eventually delivered if it

can be: When an actor is idle and has a pending

message, it processes that message. Multiple pending messages are processed in an

order so none is permanently ignored by the target actor.



Actor Names

The name (mail address) of each actor is unique.

The name (mail address) of an actor cannot be guessed, ergo: An actor must know the name (mail address) of

the target actor to send it a message Called the locality property of actors. Locality property provides a built in capability

architecture for security.



Actor Topology

If an actor a1 knows the address of another actor a2 , a1 may communicate the name of an a2 in a message.

Thus the interconnection topology of actors is dynamic.

Supports mobility and reconfiguration of actors.



Actor Creation

Unlike some process models, new actors may be created: Increases the available concurrency in a

computation. Facilitates dynamic parallelism for load balancing. Enables mechanisms for fault-tolerance.



The actor model



The actor model with buffer queues



Example: An actor implementation of sequential factorial In response to a communication with a non-zero

integer n, the actor with the ‘factorial’ behavior: Creates an actor whose behavior will be to

multiply n with an integer it receives and send the reply to the mail address to which the factorial of n was to be sent.

Sends itself the “request” to evaluate the factorial of n − 1 and send the value to the customer it created.



Example: An actor implementation of sequential factorial create a customer which waits for the

appropriate communication, in this case from the factorial actor itself.

The factorial actor is free to concurrently process the next communication.

We assume that a communication to a factorial includes a mail address to which the value of the factorial is to be sent.



Event diagram for a factorial computation




The Actor Model

Thread State

Procedure

ThreadState

Procedure

ThreadState

Procedure

Interface

Send Messages

ThreadState

Procedure

Interface

Create

ReceiveMessages

Presenter

Presentation Notes

Actor system - collection of independent agents interacting via message passing Features encapsulation of state encapsulation of a thread of control Asynchronous fair communication An actor can: create a new actor and initialize its behavior send a message to an existing actor that it knows about change its local state or behavior


19

Defining an actor language

Start with a sequential object-based language or framework, add concurrency to objects, operators for: actor creation

create(node, class, params) Locally or at remote nodes

message sending send(actor, method, params)

State change Become idle (ready to process next message)



Message Patterns More complex message patterns may be

defined in terms of asynchronous messages:

20

a a

e1

e2

e3

rpc like messaging

Actor Event Diagrams



21

Standard Actor Semantics

Encapsulation (no shared, concurrent access to state)

Fairness Location Transparency Mobility



22

Actor Encapsulation: State Isolation

Recall: no shared state between actors ‘Access’ another actor’s state only by sending

it a message and requesting it: Messages have send-by-value semantics Implementation may be relaxed on shared

memory platforms, if “safe”



23

Why State Encapsulation?

Reasoning about safety properties becomes “easier”

JVM memory safety is not sufficient for Actor semantics.

Languages such as Erlang and some actor frameworks (SALSA, ActorFoundry) enforce encapsulation.

Frameworks such as Scala and Kilim impose conventions instead of enforce isolation Easier to introduce inadvertant state sharing



24

Fairness Permanently Disabled Actor: An actor executing

an infinite loop, blocked on a external call.. Enabled Actor: not permanently disabled, and has a pending message

Actor Scheduling fairness: An enabled actor is eventually scheduled

Fair Message Delivery: a message is eventually delivered if the recipient is not permanently disabled.


Presenter

Presentation Notes

Delivery fairness subsumes scheduling fairness


25

Why Fairness?

Required for proving liveness: An actor in an infinite loop (or stuck) could starve

enabled actors. Cannot guarantee a result is eventually produced.

Fairness specially critical in libraries for existing languages Interaction with existing code-base, plug-ins, 3rd

party components



26

Why Location Transparent Naming? Enables automatic load-balancing and fault-

tolerance mechanisms Run-time can exploit resources available on

cluster, grid or scalable multicores (distributed memory)

Uniform model for multicore and distributed programming



Actors Reduce Concurrency Bugs

For example: Macro-step semantics No bugs caused by interleaving between steps of

different actors Granularity of abstraction is increased

No deadlocks caused by synchronous messaging



‘Old fashioned’ bugs in sequential code Inconsistent state updates between actors Livelocks due to rpc-like communication

Actor programs can have bugs…


Presenter

Presentation Notes

An actor is essentially an autonomous concurrent object that communicates with other actors by sending messages It encapsulates “Behavior + state + independent thread of control + mailbox” It has a unique name that is used to send it messages… this name acts as a handle that provides location transparency Communicates by sending messages - Messages are by default asynchronous Actors have: A UNIQUE NAME – location independence A mailbox for receiving messages It’s own thread of execution A local state – in its pure form there is NO shared state A behavior


29

Actor anatomy

Actors = encapsulated state + behavior + independent control + mailbox

Object


Presenter

Presentation Notes

Great thing about library: leverage existing libraries, code and expertise, easier to build Uniquely addressable mailbox Natural extension of OO model, infact Simula and Smalltalk were intended to be actor-like


30

ActorFoundry

Off-the-web library for Actor programming Major goals: Usability and Extensibility Other goals: Reasonable performance Supports standard Actor semantics


Presenter

Presentation Notes

Motivation beyond getting an A Treasure hunting Encourage programming fine-grained actors objects look-alike


31

ActorFoundry – Programming Model Actors are like objects Implicit ‘receive’ Run-time provides fetch-decode loop

One-to-one correspondence between message and Java method

Primitives for asynchronous (send) as well as synchronous, RPC-like (call) messages

Wraps standard IO objects as actors (stdout, stdin, stderr actors)


Presenter

Presentation Notes

‘return’ is implicitly a message back to the sender for RPC-like messages


Implicit Control (ActorFoundry)Base class for Actors

Location-independent

address

Asynchronous message

Annotation for message declaration

Messages as

methods



Explicit control & mailbox (Kilim)


Presenter

Presentation Notes

Kilim syntax


Explicit control (Scala)


Presenter

Presentation Notes

Scala syntax inspired by Erlang’s


35

ActorFoundry - Implementation

Maps each actor onto a Java thread Actor = Java Object + Java Thread + Mailbox + ActorName

ActorName provides encapsulation as well as location transparency

Message contents are deep copied Fairness: Reliable delivery (but unordered

messages) and fair scheduling Support for distribution and actor migration



36

ActorFoundry – Runtime Library

TCP, UDP

Broker, Shell



37

Comparison of Semantics

Scala Actors

Kilim JavAct Jetlang SALSA AA AF

State Encapsulation No No Yes Yes Yes Yes Yes

Safe Messaging No No No No Yes Yes Yes

Fair Scheduling Yes No No No Yes Yes Yes

Location Transparency No No Yes Yes Yes Yes Yes

MobilityNo No Yes No Yes Yes Yes



38

ActorFoundry Benefits

Extensibility Modular and hence extensible

Usability Actors as objects + small set of library calls Leverage Java libraries and expertise

Performance Let’s check…


Presenter

Presentation Notes

Encourage programming fine-grained actors So very programmable, modular and hence extendible. So let’s try Threadring…. Model – checking, Test, Debugging, GC, Compiler optimizations, Run-time optimizations


39

Great Language Shootout Ported ActorFoundry to Java6 The Computer Language Benchmarks Game [2]

Implemented a concurrent benchmark in ActorFoundry: Thread-ring

Thread-ring: Pass a token around 503 concurrent entities 107 timesPlatform Time (s)Java threads 134.98Haskell threads 6.70Erlang light-weight processes 7.49Scala actors 56.5ActorFoundry actors 13 minutes

[2] http://shootout.alioth.debian.org/11/6/2014 Gul Agha, University of Illinois

Presenter

Presentation Notes

Generics, variable number of arguments, autoboxing, annotations


40

and now in a Chart

Intel Core2 Duo, 2.4GHz, 4GB RAM, Java Heapsize: 256M

Coarse-grained actors + Support for standard semantics

[Karmani and Shali and Agha, PPPJ 2009.]11/6/2014 Gul Agha, University of Illinois


41

The Quest for Continuations

Kilim actor runtime library provides a “Weaver” (Java bytecode post-processor) for CPS transform

With a custom continuations based scheduler M:N architecture


Presenter

Presentation Notes

One major problem: Java Reflection


42

M:N Runtime Architecture

OS

1 2 3 4 5 6

Worker Threads

Run-time (+ Scheduler)

JVM

Cores



43


OS

1 2 3 4 5 6

Worker Threads


JVM

Cores



44


OS

1 2 3 4 5 6

Worker Threads


JVM

Cores



45

Fairness – ActorFoundry Weaving Scheduler thread periodically monitors

“progress” of worker threads Progress means executing an actor from schedule

queue If no progress has been made by any worker

thread => possible starvation Launch a new worker thread Conservative but not incorrect

Integrate with ActorFoundry improves threadring performance: ~ 7 minutes



46

The cost of isolation

Major bottleneck: deep copying of message contents

serializing/de-serializing object

[Karmani and Shali and Agha, PPPJ 2009.]11/6/2014 Gul Agha, University of Illinois


47

To copy or not to copy?1. Exclude immutable types2. Introduced new run-time functions:

sendByRef (actor, method, params) callByRef (actor, method, params)

Threadring performance: ~ 30s Scala, Kilim provide zero-copy messages

Onus on programmers to copy contents, if needed Breaks encapsulation, infeasible in general


Presenter

Presentation Notes

Not many convincing examples for copying? Audience please. Linear types + copy-on-write Expose structure, infeasible


Avoiding Message Copying

[Negara and Karmani and Agha, in submission, 2010.]

sendbyref



Static Analysis



50

Performance – crude comparison

Threadring benchmark on Intel Core2 Duo, 2.4GHz, 4GB RAM, Heapsize: 256M[Karmani and Shali and Agha, PPPJ 2009.]11/6/2014 Gul Agha, University of Illinois


51

Performance – crude comparison

Chameneos-redux benchmark on Intel Core2 Duo, 2.4GHz, 4GB RAM, Heapsize: 256M[Karmani and Shali and Agha, PPPJ 2009.]11/6/2014 Gul Agha, University of Illinois


52

Context sensitive call graph: Receiver instance context: separate nodes for the

same method invoked on different objects (receivers) Actors’ messages serve as entry points Bigger but sparser than context insensitive call graph More precise but not much slower points-to analysis

Field sensitive, flow insensitive interprocedural Andersen’s points-to analysis

Custom interprocedural live variable analysis Incorporated in a tool called SOTER

Can we infer ownership transfer?

Stas Negara, Rajesh Karmani, Gul Agha: Inferring Ownership Transfer for Efficient Message Passing11/6/2014 Gul Agha, University of Illinois


53

Imprecise, flow insensitive points-to analysis

Assumption that fields are always live (insignificant impact)

Open world assumption: not checking for safe read/read sharing

General static analysis limitations e.g. not detecting false sharing

Not considering semantics e.g. immutable objects

Sources of imprecision



54

57

77

188

37

16

62

2610

40

80

120

160

200

concurrentsuc. over relax.cham

eneos

Exe

cutio

n tim

e, s

ec

SOTER ActorFoundry usefulness

16

25

4

14

108

26

55

8

4

124 454

7

1 12

0

5

10

15

20

25

30

threadringcopym

essagesleaderphilosopherspi quicksortCopyquicksortCopy2

Before After Ideal



55

Ownership transfer is very common Although conservative, SOTER can infer most safe pass

by reference sites: ActorFoundry programs: 71% Scala actor programs: 84%

SOTER regains much of the optimal performance without requiring any additional effort from a developer

SOTER handles actor programs in reasonable time: ActorFoundry programs: max analysis time = 24 seconds Scala actor programs: max analysis time ≈ 78 seconds

Observations



56

Promise for scalable performance?

Over-decompose application into fine-grained actors

As the number of cores increase, spread out the actors Location independent naming facilitates

transparent migration Of course, speed-up is constrained by

parallelism in application Parallelism is bounded by # of actors


Presenter

Presentation Notes

What it means for design patterns


High Level Concurrent Languages

Primitive actor constructs give a bare bones language for concurrency.

High level language abstractions are needed to simplify concurrent programming.



Synchronization and Coordination

Essential for correct functioning of actor systems

A source of complexity in concurrent programs



Synchronizing in a Concurrent World

The interface of an actor may be dynamic: Cannot get from an empty buffer Cannot put into a full buffer

Producer

Buffer

Consumer

put

get



Separation of Concerns

Abstract Data Types: Enable separation of interface (what) from the

representation (how). Actors: When actions happen is underspecified

(asynchrony). Recipient may not be ready to process a message

when it arrives – synchronization constraints.



61

Local Synchronization Constraints Constrain the “local” order of processing

messages For all sending actors

Usually specified as disabling conditions on message Function of local state and message contents

These have delay semantics i.e. disabled messages are buffered

Implementations: Disabling constraints in AF, Pattern matching in Erlang, Scala



Expressing Local Synchronization Constraints

Per actor logical rules which determine the legality of invocations: disable get when empty? (buffer)

Producer

Buffer

Consumer

put

get



Implementation of Local Synchronization Constraints

Mail Queue

SynchronizationConstraints

ControllerData and Methods

Incoming Messages

Pending queue

Actor



Multiparty Coordination Constraints

Synchronization between actors precedence of actions “atomic” actions

Example: two robots which need to cooperate



Synchronizers A ‘membrane’ which filters and synchronizes

messages Expresses logical expression of constraints

between actors

S. Frolund, Coordinating Distributed Objects, MIT Press



66

Synchronizers

Express interaction among multiple actors Can have internal state Also allows expressing atomic processing of

messages by multiple actors All-or-none semantics

Declarative style (disable, atomic) Include more actions? drop, reject



Extensions of the Actor Model

Real-time systems. Sensor networks. Control and hybrid systems. Cyberphysical systems.



68

Cloud Computing Framework for Mobile-Cloud Apps

Center of data storage and processing

Efficient, Elastic, Scalable, Affordable

Cloud + Mobile:

1. Remove hardware limitations

2. Reduce mobile energy consumption

Mobile-Cloud Computation (MCC)

How? Use code-offloading


Presenter

Presentation Notes

Cloud is dominant term for new computing paradigm 1 will allow: Applications that cannot currently be executed on the phone to be executed -> New trend of applications (e.g. those requiring so much data/memory that didn’t fit on phone) Computationally intensive app that takes too long to run on the phone to finish in time (e.g. obj. recognition in a mobile robot) 2 will allow: Computationally intensive apps (e.g. image retrieval. Voice recognition, games) can now run longer on the phone (e.g. Siri) and can be part of the daily used apps Apps that requires large data from external sources (navigation) can stop downloading the data to the phone


69

Cloud Model:An Adaptive Prog. Framework for Mobile-Cloud Cloud AppsPublic Cloud

Affordable/scalable/elastic

Problems:

1. Lack of control and transparency

2. Legal implications

Private Clouds

User-control

Problems:

Not efficient/scalable/elastic as public Cloud

Hybrid Cloud:

benefits of public Cloud

User-control


Presenter

Presentation Notes

As an example. ILLINOIS law prevents storage of student grades on 3rd party machines regardless of how secure those machines are, encryption of the data and …


70

Code offloadingAn Adaptive Prog. Framework for Mobile-Cloud Apps

How?

1. Ask programmers to rewrite the code

2. Use full process or full VM migration

3. Combine the two

Separation of concerns

Fine-Granularity

References: [1]11/6/2014 Gul Agha, University of Illinois

Presenter

Presentation Notes

Ask programmers to rewrite the code: Cons: it makes the already complex programs even more complex and requires significant structural changes to the already written applications Full Process/Full VM migration: based on the assumption that running the same code on a faster machine will improve the overall performance of the application. Cons: previous studies have already shown that moving virtual machines is very costly even within a local area network Combine the two: This motivates the need for an intermediate ADAPTIVE solution that minimizes the required manual changes to applications and prevents creating additional work for the programmers. Requires: To have fine-grained components that can dynamically move between mobile device and cloud space Does not require programmers to manage them Need to be consisted of proper independent components Components need to be dynamically managed and moved around


71

Our Approach Framework for Mobile-Cloud Apps

• Bridge the gap between mobile application and cloud computing

• Separate application logic from component distribution

• Allow dynamic distribution of components based on run-time changes

• Support policy-based definition of customized constraints


Presenter

Presentation Notes

1) Facilitate Mobile-Cloud application development by bridging the gap between… 2) Separating the application logic, to be developed in future by programmers, from the application component configuration and distribution, to be performed transparently and dynamically at run-time …. and satisfying user/application expectations Application goal can range from Max. App. Performance, Min. Mobile energy consumption, Min. Total network consumption, or a combination


72

n Related Mobile-Cloud Systems

References: [ 2, 3, 9, 10]

Year SystemName

Goal Offloading Decision

PartitionLevel

Parallel Policy-basedPrivac

y

ManualWork

No. Cloud

spaces

2010 MAUI Mobile Energy Saving Dynamic Method No No Yes 1

2011 CloneCloud Mobile Energy Saving = Performance Improvement

Static Method Pseudo No No 1

2012 ThinkAir Mobile Energy Saving = Performance Improvement

Dynamic Method Pseudo No Yes 1

2012 Cloud OS(COS)

Load Balancing forCloud space

Dynamic Actor Yes No No Can beMany

2014 IMCM Mobile Energy Saving,Performance Improvement,

Combination for Applications

Dynamic Actor Yes Yes No Many


Presenter

Presentation Notes

Goal : { Improving Performance/Saving Energy} Improve performance: Minimize the Application Execution time -> Maximize the Application Performance Saving Energy: Maximize the energy saving on the phone -> Minimize energy consumption on the mobile device Note that In previous works, offloading is considered as a freeze-migrate-resume scenario meaning that it works for serial application with not much level of parallelism. -> This means that most of the time, Minimizing Execution time is SIMILAR to minimizing the energy consumption Offloading Decision: {Dynamic/Static} Static: Program is partitioned between the mobile and Cloud during the installation Dynamic: Program is partitioned Dynamically during run-time based on the situation/Context Partitioning level: Method level: at the entrance of every method the code is checked for offloading MAUI: from MSR CloneCloud: from Intel Labs at Berkeley ThinkAir: Deustche Telekom Labs + Huawei Research Center


73

IMCM: Overall System Design An Adaptive Prog. Framework for Mobile-Cloud Cloud Apps

Application Component Distribution

Elasticity Manager

Energy EstimatorNetwork ParametersDevice profilingApplication profiling

System Properties

• Max. App. Performance• Min. Mobile Energy Consumption• Min. Cloud cost• Min. Network data usage

Application Target Goal

• Application Policy • Access Restrictions• User preferences

Org./App./User Policy

System Monitor

Policy Manager

Target goalProfiled execProfiled comm.

OffloadingPlan

Decision Maker


Presenter

Presentation Notes

Add the decision making models!!!


74

IMCM: Illinois Mobile Cloud application ManagementAn Adaptive Architecture Framework for Mobile-Cloud Cloud

Apps

Image proc: Local exec (base case) vs. Remote Exec (Ideal Case) vs. Automatic Management


Presenter

Presentation Notes

(Fig. 6 of IC2E paper) Green Curve -> Manual placement of component at their optimal location (IDEAL case) Red Curve -> Local mobile execution (Base Case) Purple Curve -> Since manual placement is not always possible, Purple curve shows the automatic placement of components. Note that we do not use profiling across executions -> There is an initial lag to collect enough data form profiling and then it kicks in Ideal component distribution depends on several factors that can dynamically change during execution. Thus, an elasticity manager is required to monitor environmental changes and find optimal offloading plan. Implemented elasticity manager uses the previous profiled execution times of different components at various locations to find the optimal location for placing every component for next interval. when problem size and resulting total application execution time increases, the gap between ideal placement of component and automatic distribution becomes narrower.


75

Flexible Policy-based restrictions

IMCM Policy rule definition/enforcement system:

Authorization policy:

1. Hard Policy:

organization-wide policy

2. Soft Policy:

User/developer policy (App-instance-specific policy)Every application-instance comes with:

1. An unchangeable hard policy2. A (changeable) soft policy

Grammar to define rulesAttribute basedStatic & dynamic binding

References: [ ]11/6/2014 Gul Agha, University of Illinois

Presenter

Presentation Notes

Closed system: Any action without explicit permission is rejected Rules regulate actions + Rules can be defined as both permissions & denials Soft policy can only further tighten Hard policy. e.g. If hard policy allows accessing components A,B,C -> Soft policy can limit it to accessing only A,B and not C -> It cannot add access to component D Each application is used by one end user -> We have Application Instances Developer can define Policy for each application/ application instance and allow users to adjust their policy We followed XACML guidelines in terms of entities involved: Policy provide machine -> Provides Hard policy at time of authentication Policy enforcement point (PEP) Policy Decision Point (PDP) Conflict resolution policy: In case of a conflict between a permission and a denial, denial always governs


11/6/2014 Gul Agha, University of Illinois7676

2nd Jindo Bridge Haenam(Inland)

(June 2009 – December 2012)

2nd Jindo Bridge

Type Cable-stayed bridge

Spans 70+344+70 = 484m

Girder Steel box (12.55m width)

Design velocity 70 km/hr

Designed by Yooshin cooperation (2000, Korea)

Constructed by Hyundai construction (2006, Korea)

Owner Iksan Regional Construction and Management Administration

Special feature Twin bridge

Daejeon (KAIST)

Seoul

Jindo

Jindo Bridges

Jeju Island

Field validation of smart wireless sensor-based SHM system of a cable-stayed bridge in KoreaEstablishment of an international SHM testbed using massive distributed computingParticipants :

Korea : H.J. Jung & C.B. Yun (KAIST), H.K. Kim (SNU), J.J. Lee (Sejong U.)J.W. Seo (Hyundai E&C)

US : B.F. Spencer, Jr. & G. Agha (UIUC)Japan : Y. Fujino & T. Nagayama (U. of Tokyo)

US-Korea-Japan Testbed on Wireless Smart Sensor Networks for SHM


77

References1. Gul Agha. Actors: a model of concurrent computation in distributed

systems. MIT Press, Cambridge, MA, USA, 1986.2. Rajesh K. Karmani, Amin Shali, and Gul Agha. Actor frameworks

for the JVM platform: a comparative analysis. In PPPJ ’09: Proceedings of the 7th International Conference on Principles and Practice of Programming in Java, 2009. ACM.

3. Gul Agha, Ian A. Mason, Scott Smith, and Carolyn Talcott. A Foundation for Actor Computation. Journal of Functional Programming, 1997.

4. Rajendra Panwar and Gul Agha. A methodology for programming scalable architectures. In Journal of Parallel and Distributed Computing, 1994.

5. Astley, Mark, Daniel C. Sturman, and Gul Agha. "Customizable middleware for modular distributed software." Communications of the ACM 44.5 (2001): 99-107.


Programming Clouds for Scalability and Security: A...

Documents

Transcript of Programming Clouds for Scalability and Security: A...