The principles of reactive systems and how OMG's Data Distribution Service (DDS) middleware supports them. Based on the blog post: http://tech.aozturk.me/reactive-systems-with-dds/

1. REACTIVE
SYSTEMS
with
OMG’s Data Distribution Service (DDS)
Abdullah Ozturkbased on The Reactive Manifesto

2. INTRODUCTION
• Traditional software solutions;
• Use managed servers and containers,
• Scale via larger servers and multi-threading.

3. Today’s Requirements
• However, today’s requirements demand new
technologies;
• Deployed on everything (mobile, cloud clusters etc.),
• Thousands of multicore processors,
• Low response time (milli-, or even micro-second),
• 100% uptime (highly available),
• Big data (petabytes).

4. GOING REACTIVE
• Coherent approach to systems architecture is needed.
• Reactive Systems meet these requirements;
• Responsive,
• Resilient,
• Elastic
• and Message Driven.

5. Reactive Systems
• Reactive Systems are more flexible, loosely-coupled
and scalable.
• They are easier to develop and amenable to change.
• They are significantly more tolerant of failure and
when failure occurs they meet it with elegance.
• Reactive Systems are highly responsive, giving users
effective interactive feedback.

6. Publish-Subscribe
• Publish-subscribe architecture of DDS promotes a loose
coupling in space and time.
• No shared mutable state, synchronization and blocking
operations.
• Publishers and subscribers can join and leave to a data
domain anytime, express their intent by topics.
• Loosely coupled design of DDS allows better scalability.

7. Loose-Coupling
• Loose coupling and location independence make it
possible to scale out the system onto multiple nodes.
• By location transparency, topology of the application
becomes a deployment decision.
• It enables distributed systems that are easier to
design, implement, integrate, deploy and maintain.

8. Data-Centric Architecture
• Components interact through production and consumption of
data.
• DDS middleware employs a data-centric integration model to
decouple applications.
• DDS middleware knows your data, allows filtering, and
provides tailored data management through Quality-of-
Services (QoS).

9. RESILIENCE
• The system stays responsive in the face of failure.
• Resilience is achieved by replication, containment,
isolation and delegation.
• Failures are contained within each component, isolating
components from each other.
• Parts of the system can fail and recover without
compromising the system as a whole.
• High-availability is ensured by replication where necessary.

10. Bulkhead Pattern
• In the bulkhead pattern, a system is built up from
safe compartments that prevents the classic problem
of cascading failures.
• DDS provides fully isolated components in which
failures can be captured, encapsulated as messages,
and sent off to other components that can decide how
to respond.

11. Fault Tolerance
• A failure is an unexpected event within a service that prevents it
from continuing to function normally.
• DDS middleware provides fault tolerance;
• By providing historical data in last value caches to late joiners.
• Makes data survive application, or system failures by
durability quality of service.
• Monitors the presence, health and activity of DDS entities.
• Handles redundant data sources and failover by ownership.

12. No Single Point of Failure
• Scalability is typically limited by the introduction of
bottlenecks or synchronization points within the
system.
• Loosely coupled DDS applications without central
brokers have no single points of failure.

13. Replication
• Executing a component
simultaneously in different places.
It offers scalability and resilience.
• Incoming workload can be
distributed across multiple
instances of a component by
using DDS content-filtered topics.
• Incoming workload can be
replicated to multiple subscribers
which process the same requests
in parallel.

14. Isolation
• Decoupling, both in time and space.
• DDS entities have independent life-cycles—they do
not need to be present at the same time or at the same
process for communication to be possible.
• It is enabled by adding asynchronous boundaries
between the components, communicating through
message-passing.

15. Reliability
• DDS middleware provides that the right data is
delivered reliably and in real-time to the right
subscriber applications.
• Applications that respond to events need to do so in a
timely manner, even in the presence of failure.
• Deadline QoS of DDS enforces expected time
requirements, and time based filter QoS controls
data delivery rates.

16. ELASTICITY
• Stays responsive under varying workload.
• Reacts to changes in the input rate by increasing or
decreasing the resources allocated to service.
• No contention points or central bottlenecks in DDS,
resulting in the ability to shard or replicate
components and distribute inputs among them.
• Achieves elasticity in a cost-effective way.

17. Scalability
• Scalability is achieved by adding more computing
resources (elasticity) without redesigning or
rewriting the application.
• Its performance is measured by the ratio of
throughput gain to resource increase.
• A system based on DDS is capable of being easily
expanded or upgraded on demand by adding more
publishers and subscribers.

18. Message-Driven
• A message is an item of data that is sent to a specific
destination.
• In a message-driven system using DDS, addressable
recipients (subscribers) await the arrival of messages and
react to them, otherwise lying dormant.
• A message can contain an encoded event as its payload.
• With the message-driven design of DDS, it is easier to
extend, evolve and maintain applications, it gives more
flexibility and reduces maintenance cost.

19. Asynchronous
• It means that the processing of a request occurs at an
arbitrary point in time.
• DDS middleware ensures loose coupling, isolation,
location transparency, and provides the means to
delegate errors as messages.
• DDS allows the application a choice either get notified
asynchronously by attached listeners, or wait data in
blocking.

20. Event-Driven
• Events—discrete pieces of information describing facts.
• DDS middleware notifies the user application of relevant
events i.e. arrival of data, QoS violations, entities
matched, liveliness changed, deadline missed, and
sample lost/rejected.
• DDS provides listeners to monitor delivery related events
and to notify applications when these events occur.

21. Location Transparency
• Decoupling in space, enabled through asynchronous
message-passing.
• If all components support mobility, then we do not
have to define a static system topology upfront.
• Makes it possible for the management of failure to
work with the same constructs and semantics across a
cluster or within a single host.

22. Non-Blocking
• Allows the caller the option to do other work rather
than be blocked waiting on the resource to become
available.
• Non-blocking communication allows recipients to
only consume resources while active, leading to less
system overhead.
• Non-blocking operations (read/write) of DDS make
the application to be responsive at all times and
efficient use of existing resources.

23. RESPONSIVENESS
• The system responds in a timely manner if at all
possible.
• Responsiveness is the cornerstone of usability.
• Responsive systems establish reliable upper bounds
so they deliver a consistent quality of service.

24. High-Concurrency
• High concurrency by design makes use of
multicores without changes.
• DDS middleware allows creating multiple subscribers
or publishers to increase concurrency.

25. Performance
• DDS enables low latency and high throughput under
heavy load.
• Specifies a compact data encoding on the wire.
• Supports asynchronous notification mechanisms.
• Keeps data copies to a minimum.
• Allows controlling timing, communication channel
priority and resource utilization for real-time systems.

26. Platform Independence
• DDS provides tools as common building blocks for solving the
complex problems arising in a distributed environment.
• Supports type safety by using a platform independent language.
• Standardized well-defined APIs help ensure maximum
portability.
• Provides programming language independence.
• Provides operating system and hardware independence.
• Enables on the wire interoperability by a standard wire protocol.

27. Conclusion
• Reactive Systems apply design principles.
• The largest systems in the world rely upon
architectures based on these properties.
• OMG’s DDS middleware makes it possible to design
and develop reactive systems.

28. Thank You
• Questions?
Abdullah Ozturk
Technical Lead, MilSOFT DDS