REACTIVE SYSTEMS

with OMG’s Data Distribution Service (DDS)

Abdullah Ozturkbased on The Reactive Manifesto

INTRODUCTION

• Traditional software solutions;

• Use managed servers and containers,

• Scale via larger servers and multi-threading.

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

GOING REACTIVE

• Coherent approach to systems architecture is needed.

• Reactive Systems meet these requirements;

• Responsive,

• Resilient,

• Elastic

• and Message Driven.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

High-Concurrency

• High concurrency by design makes use of multicores without changes.

• DDS middleware allows creating multiple subscribers or publishers to increase concurrency.

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.

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.

Thank You

• Questions?

Abdullah OzturkTechnical Lead, MilSOFT DDS