Upload
abdullah-ozturk
View
299
Download
3
Tags:
Embed Size (px)
Citation preview
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