Bartolomeo Sorrentino
He is a Principal Software Architect with over 25 years of experience. He is an active contributor to the open source ecosystem. He leads several OS projects and contributes to many others.
A journey in Reactive world, explaining differences between various meanings of word “Reactive” … in order to better understand this new and interesting both architectural and development approach.
A Software Architect with over 25 years of experience.
CTO in Softphone and Cofounder of SoulSofware company.
an active contributor to the open source eco-system. https://github.com/bsorrentino
http://soulsoftware-bsc.blogspot.it/
https://twitter.com/bsorrentinoJ
https://www.linkedin.com/in/bartolomeosorrentino
The Reactive Manifesto
Published in 2014 the Reactive manifesto refers to Reactive System as system that are more flexible, loosely-coupled and scalable.
Such system must be:
The Reactive Manifesto introduces a
"tech. agnostic shared vocabulary"
that will help us to better understand the concepts that we will meet during our knowledge acquisition path:
The main terms are:
To build a Reactive system it is not mandatory switching to reactive programming, even if using it will help you to fully apply the reactive nature of your system.
Typically reactivity can be smoothly introduced depending on the Use Cases that we are analysing.
We could consider reactive also a system that partially apply reactive patterns
Service must behave reactively i.e. be able to handle and react to incoming messages, but It is not forced to rely on particular reactive middleware or need to be implemented using reactive programming
(i.e. internally service logic could be performed in synchronous way )
RESTFul api are commonly used to enforce synchronous flow, but a service that accepts command through REST call and return results through events is definitely a reactive service.
(Main strategy on which db services are focusing to become reactive)
Going reactive provides a solution when it comes to specific types of high-load or multi-user systems like:
Reactive systems represent the higher level of ‘reactivity’.
This level implies specific design and architectural decisions that allow building resilient, flexible, and responsive applications.
Essentially a Reactive System is a Message Driven Distributed System on which will be applied architectural patterns and used tools to enforce elasticity and resiliency
To simplify we can collapse all concepts in one meaningful sentence:
A reactive system is a distributed system designed upon asynchronous data flows
(aka Component)
When we speak about a distributed system we image a bunch of services & applications interconnected between them.
We can define a Reactive Service a service that :
Services we mean the Business Services belonging to back-end architecture
Applications we mean the Consumer Apps belonging to front-end architecture
(aka Reactive Runtime)
Another Reactive aspect that often is confused and/or mixed with reactive system one, is the reactive execution environment or more in general a reactive runtime.
This concerns how/what a process can help/provide an/to application or service to be as much reactive as possible
(i.e. responsive, elastic, resilient)
(rise of asynchronous)
This is one of the most discussed aspect of reactive world because differently from the past seems that to achieve reactiveness (faster, better, cheaper) we don’t need to deal with concurrency and multi threads anymore but with asynchronicity and immutability.
(rise of multi-core )
The One-Thread-Per-Request Model was designed when single-core CPUs were the norm and with rise of multi-core processors the best way to use them is to reduce the "IO Waiting" and here comes into play reactive asynchronous model (& programming)
(MessageLoop & non-blocking I/O)
Basic idea behind reactive runtime is to create an internal event driven architecture based on few of threads managing messages loop and non-blocking I/O that completely (as much as possible) hides concurrency and threads management in favor of asynchronicity and immutability.
Multi threads != Asynchronous
Less stressed threads work better that many lazy threads
(Native vs Middleware)
Currently there are available several reactive runtime, some are purely native reactive implementation others are middleware/framework that extend/adapt existent ones
(unveiled)
1) Fluently
(use Builder Pattern)
2) Fluently + Functional
(use and abuse of lamdba)
3) Fluently + Functional + Asynchronous
(use MessageLoop and Scheduler)
Here the famous design patterns that everyone known.
but not always everyone apply
Here the only patterns need to be reactive:
Iterator:
To iterate over data in one way
Observer:
To handle and process data
Builder:
To achieve fluently and expressive code
The Marble Diagram
A great way to represent stream processing
The Core of the RX that enable stream processing through function composition
You have to know how properly applying them to achieve the powerful of RX
By Bartolomeo Sorrentino
A journey in Reactive world, explaining differences between various meanings of word “Reactive” … in order to better understand this new and interesting both architectural and development approach.
He is a Principal Software Architect with over 25 years of experience. He is an active contributor to the open source ecosystem. He leads several OS projects and contributes to many others.