i have studied the Orleans Cloud computing research paper and made these slides . These slides will help you to understand Research Paper (Orleans Cloud Computing)

1. Orleans Cloud Computing
 Huzaifa Salman Zafar

2. Intro to Orleans cloud
computing
 Cloud computing
 Diverse clients(pc’s, smartphones, sensors etc.)
 Computation and data storage in cloud
(cloud=internet)
 Cloud systems are distributed systems
 Distributed systems
 A distributed system is a software system in
which components located on networked
computers communicate and coordinate their
actions by passing messages

3. Message Passing
 A type of communication between process
 Messages may include functions, signals, and
data packets
 Works as follows
 A message is sent to a process
 Process may be an actor

4. Actor model
 The Actor model was introduced in 1973 by
Hewitt, Bishop and Steiger.
 Mathematical model of concurrent computation
 Actor serves as basic building block of
concurrent computation.
 In response to a message received by actor,
actor can
 Make local decisions
 Create more actors
 Send more messages etc

5. Grains
 Basic programming unit
 All the code run within grains
 Isolated units of state and computation
 Communicate through asynchronous
messages
 Messages are method calls
 asynchronous messages
 Message is sent and does not need to wait for
reply
 Opposite of synchronous message passing

6. Promises
 Within a grain, promises are mechanism for
 Managing asynchronous message passing
 Local task based concurrency
 Concurrent computation
 Several threads of operation may execute
concurrently

7. Promises |continued….
 Communication between grains
 Asynchronous message passing
 Orleans messages are method calls
 Message call returns immediately with a promise
for a future result
 An application can bind code to the promise
which will execute when result arrives
 it can treat the promise like a future and
explicitly wait for a result.

8. Goals of Orleans
 Enable the developers unfamiliar with
distributed systems to build large scale
applications
 That these systems handle multiple orders of
large magnitude of growth without requiring
redesign or rearchitecture.

9. Activations
 To handle increase load on a grain
 And to provide higher system throughput
 Orleans automatically creates multiple
instantiations called activations
 The activations process independent requests for
the grain, possibly across multiple servers
 These activations cannot share memory or invoke
each other’s methods

10. Persistence
 A cloud system has persistent state that is kept
in durable storage.
 Orleans integrates persistence into grains
 Persistent grain state means
 State Changes in one activation of a grain will be
available for subsequent activations of the grain
 Multiple activations can modify grain’s state
 Orleans provides a mechanism to reconcile changes

11. Automated Scalability
 A service is scalable if increased load can be
handled by proportionally increasing server
capacity
 Techniques used for achieving scalability in
orleans
 Asynchrony and replication

12. Programming model
 Promises
 Grains execution model
 Error handling
 Grain interfaces
 Grain references
 Creating and using grains
 Grain classes

13. Promises
 Orleans uses promises as its asynchrony
communication
 Promises have life cycle
 Unresolved (expecting a result in unspecified
time)
 fulfilled (result is received, value of
promise=result)
 Resolved(fulfilled or broken is considered
resolved. ).
 Implemented as .NET types

14. Grain Execution Model
 When an activation receives a request, it
processes it in discrete units of work called
turns
 All grain code execution, runs as a turn
 Many turns belonging to different activations
may run in parallel
 But each activation executes its turns sequentially
 Hence, execution in an activation is logically
single threaded.

15. Grain interfaces
 Orleans uses standard .NET interfaces to
define the interface to grain’s services
 Grain References
 A grain reference is a proxy object that provides
access to a grain.
 A proxy object acts as an intermediary between
the client and an accessible object. The purpose
of the proxy object is to forward calls to the
accessible object only if it is not destroyed.

16. Creating and Using Grains
 For each grain interface, Orleans generates a
static factory class and an internal proxy class
 Clients use the factory classes to create, find,
and delete grains.
 The proxy classes are used by the Orleans
runtime to convert method calls into
messages.

17. Orleans runtime
 The mechanisms that Orleans provides for an
application is called Orleans runtime
 Orleans is a framework for .NET runtime that
can be used from any .NET language (C#, F#,
etc.
 Orleans can run on
 desktop machines,
 servers running Windows Server 2008,
 and the Microsoft Windows Azure cloud platform.

18. .NET Framework
 Is a software framework developed by
Microsoft that runs primarily on Microsoft
windows
 The easiest way to build apps on the Microsoft
platform
 Provides
 Large class library (Framework class library)
 A software environment known as common
language runtime (CLR)
 CLR provides security, memory management, and
exception handling etc

19. Orleans runtime (continued)
 The state of a grain is managed by the
Orleans runtime
 initialization, replication, reconciliation, and
persistence
 The programmer identifies the persistent state
and Orleans handles the rest

20. Orleans runtime (continued)
 Persistence
 Activate method, Handle requests (operate in
memory)
 Wait for completion of request , call deactivate
 Write to persistent storage
 Replication
 An activation is single threaded, so processing is
limited
 But Orleans uses grain replication –multiple
activations of a grain
 And achieve elasticity and scalability

21. Orleans runtime (continued)
 Isolation
 Activations of many different grains, as well as
multiple activations of the same grain are isolated
 all activations communicate only through
asynchronous message passing and reference
each other using grain references (proxy objects).
 This allows Orleans to place activations on any
server, even across data centers, and migrate
activations between servers, in order to balance
load

22. Orleans runtime (continued)
 Resource Management
 growing and shrinking the number of activations
of a grain
 Requests are initially randomly distributed to
existing activations
 A request arriving at an overloaded server is
rejected

23. Orleans runtime (continued)
 State Reconciliation
 If multiple activations of a grain concurrently
modify their persistent state, the changes must be
reconciled into a single, consistent state.
 a last-writer-wins strategy
 data structures (records, lists, and dictionaries)
that track updates and automatically reconcile
conflicting changes

24. Orleans runtime (continued)
 Transactions
 A transaction is created at the arrival of an initial,
external request from a client
 A transaction is completed when the request
processing finishes execution.
 It is committed when its changes are written to
durable storage

25. APPLICATIONS
 Here we discuss 3 applications
 Chirper
 large-scale Twitter-like publish-subscribe system
for distributing small text message updates within
a large network of consumers / subscribers
 Linear Algebra Library
 General purpose computations on scalars,
vectors, and matrices (including higher
dimensions as tensors).

26. Chirper
 A Chirper account is naturally modeled as a grain
 The account grain exposes three public
interfaces: IChirperAccount, IChirperSubscriber
and IChirperPublisher
 IChirperAccount
 single user account, start and stop following another
user
 IChirperSubscriber and IChirperPublisher are
used for subscription and notification activities
 An account that receives or sends large number
of messages is replicated to balance load

27. Linear Algebra Library
 The core of a linear algebra library is the
vector-matrix multiplication
 This operation is the basis for many
algorithms, including PageRank, clustering,
 vector-matrix multiply is quite simple if data is
held in memory on one machine
 Consider a web graph
 greater than 10^11 pages with more than 10^12
links
 The Web graph is the graph of the Web pages
together with the hypertext links between them.

28. Linear Algebra Library
 The computations are broken into worker
grains that own pieces of the data set.
 Special coordinator grains manage the
computation by dynamically assigning work to
worker grains

29. Large Graph Engine
 Graphs are central to web search, social
networking, and other web applications
 Large graphs pose many challenges
 they do not fit a single computer and distributed
algorithms are communications intensive
 partitioning and distributing graph data
(nodes, edges, and metadata) across many
machines
 represent a partition of the nodes by a grain

30. Large Graph Engine
 Every server hosts a small number of partition
grains, and every partition grain contains a
moderate number of graph data nodes (10^4 –
10^6)
 A graph algorithm running in a partition directly
accesses nodes in its partition
 Accesses across partitions involve sending
messages between partition grains
 it imposes no restrictions on the size of a
grain
 . Grains can hold potentially large amounts of
state

31. PERFORMANCE
MEASUREMENTS
 Chirper
 We created a synthetic network of 1,000 user
accounts
 each user following 27 random users
 ran load generator processes on multiple
machines
 each generator posting messages of varying
size
 The system can deliver approximately 7,000
chirps per second (1600 tweets per second by

32. Related Work
 Actors
 Actors are a well-known model for concurrent
programming
 Orleans extends the basic actor model with
support for replication, transactions, and
consistency
 E is an object-oriented programming language
for secure distributed computing.
 E has a concurrency model similar to Orleans

33. Related Work
 Distributed Object Models
 Enterprise Java Beans (EJB), Microsoft’s
Component Object Model (COM), and the
Common Object Request Broker Architecture
(CORBA)
 Based on distributed objects primarily
synchronous RPC
 They share Orleans’s goals of offering a
higher-level collection of abstractions that hide
some of the complexity of building distributed
systems

34. FUTURE WORK
 An on-going area of research is resource
management
 when and where should a new activation be
created, rather than reusing an existing one?
 When should an existing activation be
deactivated?
 important area for future work is in extending
Orleans to run on devices such as PCs and
smartphones

35. CONCLUSIONS
 This paper described the design and
implementation of Orleans
 actor-like model of isolated, replicated grains
that communicate through asynchronous
messages and manage asynchronous
computations with promises
 We believe that the Orleans framework can
significantly simplify the development of cloud
applications
 This is not a strong guarantee, as it is possible
to write a bad program in any language

36. CONCLUSIONS
 Cloud services achieve high throughput by
processing multiple, independent requests
concurrently
 Orleans supports a simple, single threaded
model within a grain, but permits parallelism
between grains, although limited to message
passing
 Computers and networks fail in distributed
systems, so error handling and recovery code
is fundamental.

37. CONCLUSIONS
 Cloud applications must respond to varying
and unpredictable workloads.
 Grain replication offers a simple, mostly
transparent mechanism that permits Orleans
to allocate more computing resources at
bottlenecks in an application
 Orleans is currently being used by several
projects inside Microsoft Research
 that training and education remains an
important aspect of cloud software
development

38. Thank You