Traditional software solutions use managed servers and containers, and scale via larger servers and multi-threading.

Today’s systems demand new requirements, because they are deployed on everything (mobile, cloud clusters etc.), have to benefit from multicore processors, show low response time (milli, or micro-second), are 100% uptime (highly available), and deal with big data (petabytes).

Going Reactive

Coherent approach to systems architecture is needed. Reactive Systems meet the following requirements;

  • Responsive,
  • Resilient,
  • Elastic,
  • and Message Driven.
Image for post
Image for post

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.

The Data Distribution Service for Real-Time Systems (DDS) is an Object Management Group (OMG) machine-to-machine middleware “m2m” standard that aims to enable scalable, real-time, dependable, high-performance and interoperable data exchanges between publishers and subscribers.

Publish-Subscribe

Publish-subscribe architecture of DDS promotes a loose coupling in space and time. It provides 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.

Image for post
Image for post

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.

Data-Centric Architecture of DDS

In 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).

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.

Fault Tolerance

A failure is an unexpected event within a service that prevents it from continuing to function normally.

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.

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.

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.

Replication

Replications is executing a component simultaneously in different places. It offers scalability and resilience.

  • Incoming workload can be distributed across multiple instances of a component (sharding) by using content-filtered topics of DDS.
  • Incoming workload can be replicated to multiple subscribers which process the same requests in parallel.
Image for post
Image for post

Isolation

Isolation provides 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.

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.

Elasticity

Elastic systems stay responsive under varying workload. They react 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. Thus, it is possible to achieve elasticity in a cost-effective way.

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.

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. System integration is done one component at a time without impacting other components.

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 blocking with a WaitSet.

Image for post
Image for post

Event-Driven

Events are 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 asynchronously. DDS provides listeners to monitor delivery related events and to notify applications when these events occur.

Location Transparency

It is decoupling in space, enabled through asynchronous message-passing. With dynamic discovery, DDS components support mobility, then we do not have to define a static system topology upfront. This makes it possible for the management of failure to work with the same constructs and semantics across a cluster or within a single host.

Non-Blocking

It 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.

Responsiveness

Responsive 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.

High Concurrency

High concurrency by design makes use of multicores without changes. DDS middleware allows creating multiple subscribers or publishers to increase concurrency. Thus, it provides responsiveness.

Performance

DDS enables low latency and high throughput under heavy load. It specifies a compact data encoding on the wire, supports asynchronous notification mechanisms, keeps data copies to a minimum, and allows controlling timing, communication channel priority and resource utilization for real-time systems.

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.

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.

Below is my presentation based on this post, which is in summary about the principles on designing reactive systems and how to benefit from DDS middleware to achieve message-driven reactive systems with responsiveness, resilience, and elasticity.

Reactive Systems with OMG’s Data Distribution Service DDS

This blog post and the presentation is based on The Reactive Manifesto and MilSOFT DDS implementation.

Originally published at tech.aozturk.me on January 26, 2015.

Written by

Software development engineer. Distributed systems enthusiast. #data, #iot, #mobile, #scalability, #cplusplus, #java https://github.com/aozturk

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store