We have a DREAM

Abstract

The reactive programming paradigm has been proposed to simplify the development of reactive systems. It relies on programming primitives to express dependencies between data items and on runtime/middleware support for automated propagation of changes. Despite this paradigm is receiving increasing attention, defining the precise semantics and the consistency guarantees for reactive programming in distributed environments is an open research problem.This paper targets such problem by studying the consistency guarantees for the propagation of changes in a distributed reactive system. In particular, it introduces three propagation semantics, namely causal, glitch free, and atomic, providing different trade-offs between costs and guarantees. Furthermore, it describes how these semantics are concretely implemented in a Distributed REActice Middleware (DREAM), which exploits a distributed event-based dispatching system to propagate changes.We compare the performance of DREAM in a wide range of scenarios. This allows us to study the overhead introduced by the different semantics in terms of network traffic and propagation delay and to assess the efficiency of DREAM in supporting distributed reactive systems.

A Semantic Framework for the Design of Distributed Reactive Real-Time Languages and Applications

“…Other authors have addressed the study of semantics for reactive distributed frameworks explicitly. For example, using the DREAM middleware, researchers explore in [24] different semantics for distributed reactive systems qualitatively. Furthermore, in [23] the authors present a study for the change propagation cost implementation in DRP, description for DREAM's API and it is consistency implementation on the Java language.…”

Exploring the role of sequential computation in distributed systems: motivating a programming paradigm shift

“…• In reactive and stream programming, consistency is implicitly preserved if potentially dependent requests are grouped as a single event that is delivered to all clients: in that case, all values are guaranteed to be delivered in the same order as they are created on the server. However, if behaviors are bound separately, in general, there are no guarantees on the ordering and consistency needs to be ensured by additional means or specialized propagation algorithms [24,42].…”

“…Moreover, RP approaches tend to be specialized towards restricted classes of applications (e.g. with a single server, reactivity only on clients [4]) or adopt communication schemas that do not offer handling of concerns such as scalability and consistency [13,24,42].…”

“…Publish-Subscribe Model The ability to define flexible many-to-many communication through channels and subscriptions offers an advantage for implementing a large class of distributed systems [16]. Many approaches incorporate publish-subscribe functionality, some of them mixing it with other models [4,19,22,25,42,59]. On top of providing flexible means of connecting nodes (e.g.…”

“…Inherent in all these approaches to distributed programming is the recognition, codified in the so-called CAP theorem, that it is not possible to achieve consistency, availability and resiliency of a distributed system all at once [27]. Each approach therefore adopts some point in the design space, and optimizes some of these at the expense of others [13,42,51,57]. Because these approaches tend to address some of the concerns with hardwired functionality, a developer who wants full control to select an arbitrary point in the design space must resort to a more primitive framework.…”