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 isn’t about particular technologies,
it’s 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. It’s
not enough to just use a “reactive framework”.
!15
17. Akka
•
De-facto Actor implementation for Scala
•
Replaced Scala’s 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 system’s 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