The document summarizes a presentation on reactive programming given by Steven Pember and David Fox of Cantina. It discusses what reactive programming is, the four traits of reactive systems according to the Reactive Manifesto (responsiveness, resilience, elasticity, and message-driven), and reactive technologies like Akka and Spray. It also covers actor models, how actors work, supervision strategies in Akka, and promises and futures.
2. Introduction to Reactive
Presented by
!
Steven Pember
Principal Consultant , Technical Architect at Cantina
David Fox
Principal Consultant , Technical Architect at Cantina
!2
6. The Reactive Manifesto
Written by Jonas Bon辿r with
contributions by Erik Meijer,
Martin Odersky, Greg Young,
Martin Thompson, Roland Kuhn,
James Ward and Guillaume Bort.
!6
7. tl;dr
1. WAY more traffic than just a few years ago
2. Users expect immediate response
3. Need 100% uptime
4. Large amounts of data
5. Need better models of concurrency
6. Old models like servlet showing their age
!7
14. These are all Reactive technologies
Reactive isnt about particular technologies,
its a holistic view of application architecture to support
the needs of the current generation of applications
!14
15. As developers, we need to see the whole picture
of the application, from the front-end to the back-end. Its
not enough to just use a reactive framework.
!15
17. Akka
De-facto Actor implementation for Scala
Replaced Scalas actor implementation
Team wanted to keep Scala smaller
Better as a separate framework
Used as basis of Play and Spray and many
other frameworks
!17
18. Actor
Model
Invented in 1973 by Carl Hewitt, Peter
Bishop, and Richard Steiger at MIT's AI lab
A design pattern for concurrency
Encapsulates state and behavior
Alleviates the need for locks
Allows work to be scheduled fairly
!18
21. Actor Scheduled
The actor systems scheduler
schedules the actor to run in a
thread.
!
The actor processes a message
according to its behavior
!21
22. Execution Complete
The actor state is modified.
!
The scheduler will continue to
fairly schedule the actor to run
while its mailbox has messages.
!22
24. Supervision
By default, when an actor crashes, it will
simply be restarted by the system
!
Other strategies can be employed such as:
Resume keeping state
Resume clearing state
Terminate the actor permanently
Escalate, failing the supervising actor
!24
25. Other
Features
Finite state machine mixin
Typed actor proxy for integration with nonactor-based code
Location transparency / clustering
Support for event/command sourcing
!25
26. What Are the Drawbacks?
Programming with actors is more difficult
Type safety is lost
Not as easy to compose
!26
27. Promises
&
Futures
Synchronization constructs/patterns
Allow use of values which will be eventually
available at a later point in time
Terms sometimes used interchangeably
A promise is a container to write a value to
A future is a handle used to read that value
!27