2. A big headache of a User-story
A story of how good actors chopped it up
and brought together all... coolly!
3. Agenda
● The background (case-study)
● Problems with user stories which span distributed applications
● How do we split this user story?
● And How do we bring all of this together?
● What Actors-based distributed framework solve ( inc brief of Akka)
● Some comments on testing such cases
● QnA
4. Three main aspects of discussion
● Object Orientation
○ Message Passing
○ Encapsulation
● Distributed (networked) objects/components/services
● Multicore machines and threading model
5. The Story
As a travel agent
I'd like to book an entire business trip
so that the busy executive has a single voucher/ref
● USP: One shot booking and single voucher
6. The Story break down
{ Return flight, Hotel, and airport transfers }
1. How can we split this story?
2. How should we prioritise these?
3. What if a new partner airline become available?
4. How do we handle these in sprints?
7. What was OO supposed to be?
https://www.thefamouspeople.com/profiles/alan-curtis-kay-637.php
Dr. Alan Curtis Kay
“..But just to show how
stubbornly an idea can hang on,
all through the seventies and
eighties, there were many people
who tried to get by with “Remote
Procedure Call” instead of
thinking about objects and
messages...”
9. Operating System
JVM Address space
Objects and methods (co-locality)
Object a (of type A) Object b (of type B)
// Some method of Class A…
{
……
B b = new B(...).
int i = 20;
String s = b.m(i)
….
}
10. Objects and methods
(distributed, yet same OS)
Object a (of type A)
Operating System
JVM Address space
Object b (of type B)
JVM Address space
Object a (of type A)
What if the called process hasn’t started yet
Or, has already exited?
11. Objects and methods
(distributed, different machines)
Operating System (machine 2)
Operating System (machine 1)
JVM Address space
Object b (of type B)
JVM Address space
Object a (of type A)
Method call,
across
machine
boundariesW
hat if the
netw
ork
is
unavailable?
12. Distributed System: requires caution
A di r ed s e s e w h e f u f
a c te di 't e k ex d a r r
yo n o p un le.
- Les La p
13. Distributed System: fallacies
- The network is reliable.
- Latency is zero.
- Bandwidth is infinite.
- The network is secure.
- Topology doesn’t change.
- There is one administrator.
- Transport cost is zero.
- The network is homogeneous.
14. Actors: Brief history and resource
● Concept brought by Carl Hewitt et. al. (1973)
● First commercial implementation
○ Ericsson’s next Generation switches: Erlang
● In the JVM world: Akka (Scala, Java)
○ Lightbend.com provides technology (open-source)
○ Akka’s Actor Model is heavily influenced by Erlang’s
● Microsoft provides Akka.NET (C#)
● Innumerable learning resources
15. Actors: What do they offer
● Actors are just like our everyday objects
● Actors work only on messages
○ One cannot call a method on an Actor
● Actors are asynchronous by intent and design
○ A response (i.e, a return value) is never guaranteed
● Actors are distributed by default (no co-locality assumed)
● An Actor is designed to work in a single threaded manner
○ (but) Several Actors can work simultaneously
○ Hundreds of thousands of Actors can co-exist
16. Actors: Mailbox of messages
https://www.safaribooksonline.com/library/view/applied-akka-patterns/9781491934876/ch01.html
Code to
handle/process
messages
Code to
handle/process
messages
17. Actors: a typical application
http://tutorials.jenkov.com/java-concurrency/concurrency-models.htmlhtml
DB
Browser
ActorSystem
● Every Actor has its
own mailbox
● Every Actor runs
some application
logic
● Each actor passes a
message, never calls
a method
19. Self-praise
● (very) old hat, but just doesn’t fade
● C -> C++ -> Java -> Scala (bash/perl)
● Only Unix/Linux, No Microsoft! :-)
● Working as a freelance backend stack developer/mentor/architect
● Integration framework (CORBA), telecom, multiplayer gaming, IoT
backend, Data Engineering/Streaming
● India, Ireland, Germany
● Intermittently Consulting/Mentoring/Hosting Workshops