2. www.luxoft.com
About author
Orkhan Gasimov
Software Developer
Over 13 years in software development field
Participated in full-cycle application development, leading development
groups with hands-on experience in a variety of programming languages
and technologies including solution design and architecture
Applied practical usage of Java, C#, C/C++, Perl, PHP, JavaScript and
other programming languages. Designed desktop, mobile and web
applications from consumer products to N-tier systems
4. www.luxoft.com
Scaling up Scaling out
• More price with each step
• Greater risk of hardware failure
causing bigger outages
• Limited upgradeability in the
future
• One unit for everything
• Much cheaper than scaling
vertically
• Easier to run fault-tolerance
• Easy to upgrade
• Parallel units enable parallel
execution
Scaling
7. www.luxoft.com
Reactive Manifesto
Application requirements have changed dramatically in recent years
A few years ago a large application had
- tens of servers
- seconds of response time
- hours of offline maintenance
- gigabytes of data
Today
- applications are deployed on everything from mobile devices to cloud-based clusters
- users expect millisecond response times and 100% uptime
- data is measured in Petabytes
8. www.luxoft.com
Reactive Manifesto
Today's demands are simply not met by yesterday’s software architectures
A coherent approach to systems architecture is needed
All necessary aspects are already recognized individually
We want systems that are
- Responsive
- Resilient
- Elastic
- Message Driven
We call these Reactive Systems
9. www.luxoft.com
Reactive Manifesto
Responsive: The system responds in a timely manner if at all possible. Responsiveness
means that problems may be detected quickly and dealt with effectively.
Resilient: The system stays responsive in the face of failure. Any system that is not
resilient will be unresponsive after a failure.
Elastic: The system stays responsive under varying workload. Reactive Systems can
react to changes in the input rate by increasing or decreasing the resources allocated to
service these inputs.
Message Driven: Reactive Systems rely on asynchronous message-passing to establish a
boundary between components that ensures loose coupling, isolation and location
transparency. This boundary also provides the means to delegate failures as messages.
10. www.luxoft.com
Reactive Manifesto
Large systems are composed of smaller ones and therefore depend on the Reactive
properties of their constituents. This means that Reactive Systems apply design principles
so these properties apply at all levels of scale, making them composable.
13. www.luxoft.com
Akka vs JavaEE
No application server is required
Vanilla JVM and core Java is enough
JVMs can be stacked up to a Cluster
Akka offers Actor Model instead of Object Oriented Model
- Actors are workers
- Objects are objects
Actors are parallelized by default
23. www.luxoft.com
Progress Condition
We want so called Progress Condition. These are actual non-
blocking guarantees.
We want applications to behave
- Parallel
- Asynchronous
- Non-blocking
- Without deadlocks, starvation and live-locks
- Without race conditions
25. www.luxoft.com
Actor Model
An actor is a computational entity that, in response to a message it receives, can
concurrently:
- send a finite number of messages to other actors;
- create a finite number of new actors;
- designate the behavior to be used for the next message it receives.
There is no assumed sequence to the above actions. They could be parallel!
The Actor Model philosophy says ”everything is an actor”.
This is similar to the ”everything is an object” philosophy, but object-oriented
software is typically executed sequentially, while the Actor Model is inherently
concurrent.
27. www.luxoft.com
Actor Model
Actors are objects which encapsulate state and behavior
They communicate exclusively by exchanging messages which are placed
into the recipient’s mailbox
View them as persons
While modeling a solution with actors
- envision a group of people and assign sub-tasks to them,
- arrange their functions into an organizational structure
- and think about how to escalate failure
28. www.luxoft.com
Actor System
Actors come in systems and never alone
Actors form hierarchies
Actor can start child actors and supervise them
Splitting tasks brings in smaller and more manageable tasks
32. www.luxoft.com
API is very easy
Create the ActorSystem
Actor is a class extending UntypedActor and overriding onReceive
method
Use ActorSystem::actorOf method to create actors
- Each actor can create child actor using getContext().actorOf method
To send a message to Actor ActorRef::tell method is used
- you should have ActorRef (actor reference) which you will get on actor
creation or you can lookup/search for it by path
36. www.luxoft.com
Mailboxes
Akka comes shipped with a number of mailbox implementations
- Unbounded (default)
- Bounded
- [U/B] Non-Blocking
- [U/B] Priority
- [U/B] Stable Priority (FIFO)
- [U/B] Control Aware
- Unbounded Single Consumer Only
38. www.luxoft.com
Other Features & Available Modules
Futures – functional promises that are used to retrieve the result of some concurrent operation
Agents – provide asynchronous change of individual locations
Remote – enable remote actor messaging between actor systems over the network
Cluster – turn actor systems into a single cluster over the network
I/O – module carries API for the implementation of network protocols and building higher
abstractions
Camel – actors can now exchange messages with other systems over large number of protocols
& APIs such as HTTP, SOAP, TCP, FTP, SMTP or JMS, to mention a few
Streams – stream processing API
HTTP – a full server- and client-side HTTP stack on top of akka-actor and akka-stream. It's not a
web-framework but rather a more general toolkit for providing and consuming HTTP-based
services.