Fault-tolerant Distributed Reactive Programming

Mogk, Ragnar; Baumgärtner, Lars; Salvaneschi, Guido; Freisleben, Bernd; Mezini, Mira

doi:10.4230/lipics.ecoop.2018.1

Cited by 8 publications

(5 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Listing 2 implements the same average calculation from the previous section in REScala [26,37], a functional RP library in Scala. Line 1 declares a behaviour (called a signal in REScala) that holds values of type Set[Sensor].…”

Section: Acquaintance Maintenance Using Behavioursmentioning

confidence: 99%

“…In Section 2 we demonstrated the problems that arise when performing acquaintance maintenance and discovery by using RxJS [31,36] to represent stream-based reactive programming, and REScala [26,37] to represent behaviour-based reactive programming. While we consider them to be representative for the state of the art, we briefly discuss other related work.…”

Section: Related Workmentioning

confidence: 99%

“…Efficient acquaintance maintenance is offered by Scala.React [23] and Hokko [32], but they do not support distributed reactive programming. Support for inefficient acquaintance maintenance can also be found in REScala [26,37], ScalaLoci [44] and AmbientTalk/R [7].…”

Section: Acquaintance Maintenancementioning

confidence: 99%

“…Reactive programming (RP) is an emerging approach to build reactive (prosumer) applications because it offers a solution to the problems of callback hell and inversion of control that arise when programming event-driven applications [2,10]. Frameworks based on "reactive streams" such as ReactiveX [31] and Akka Streams [35] have been adopted into mainstream development, and functional RP is regularly proposed for building distributed systems [7,24,26,27,28,33,40].…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Topology-Level Reactivity in Distributed Reactive Programs

2022

View full text Add to dashboard Cite

Reactive programming is a popular paradigm to program event-driven applications, and it is often proposed as a paradigm to write distributed applications. One such type of application is prosumer applications, which are distributed applications that both produce and consume many events.We analyse the problems that occur when using a reactive programming language or framework to implement prosumer applications. We find that the assumption of an open network, which means prosumers of various types spontaneously join and leave the network, can cause a lot of code complexity or run-time inefficiency. At the basis of these issues lies acquaintance management: the ability to discover prosumers as they join and leave the network, and correctly maintaining this state throughout the reactive program. Most existing reactive programming languages and frameworks have limited support for managing acquaintances, resulting in accidental complexity of the code or inefficient computations.In this paper we present acquaintance management for reactive programs. First, we design an acquaintance discovery mechanism to create a flock that automatically discovers prosumers on the network. An important aspect of flocks is their integration with reactive programs, such that a reactive program can correctly and efficiently maintain its state. To this end we design an acquaintance maintenance mechanism: a new type of operator for functional reactive programming languages that we call "deploy-*". The deploy-* operator enables correct and efficient reactions to time-varying collections of discovered prosumers.The proposed mechanisms are implemented in a reactive programming language called Stella, which serves as a linguistic vehicle to demonstrate the ideas of our approach. Our implementation of acquaintance management results in computationally efficient and idiomatic reactive code.We evaluate our approach quantitatively via benchmarks that show that our implementation is efficient: computations will efficiently update whenever a new prosumer is discovered, or a connected prosumer is dropped. To evaluate the distributed capabilities of our prototype implementation, we implement a use-case that simulates the bike-sharing infrastructure of Brussels, and we run it on a Raspberry Pi cluster computer.We consider our work to be an important step to use functional reactive programming to build distributed systems for open networks, in other words, distributed reactive programs that involve many prosumer devices and sensors that spontaneously join and leave the network.

show abstract

Section: Acquaintance Maintenance Using Behavioursmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Acquaintance Maintenancementioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Topology-Level Reactivity in Distributed Reactive Programs

2022

View full text Add to dashboard Cite

show abstract

“…Reactive programming [3] provides abstractions for defining time-changing values (signals), event streams and their combination. In line with multitier programming, distributed reactive programming [35,36,29] allows developers to define event streams that span over different machines.…”

Section: About the Authorsmentioning

confidence: 99%

Implementing a Language for Distributed Systems: Choices and Experiences with Type Level and Macro Programming in Scala

Weisenburger

Salvaneschi

2020

Programming

Self Cite

View full text Add to dashboard Cite

Multitier programming languages reduce the complexity of developing distributed software by developing the distributed system within a single coherent code base. In multitier languages, the compiler or the runtime takes care of separating the code into the components of the distributed system. This approach enables abstraction over low level implementation details such as data representation, serialization and network protocols. The ScalaLoci programming language allows developers to declare the components of the system and their architectural relation at the type level, enabling static reasoning about distribution and remote communication and guaranteeing static type safety for data transfer across components. As the compiler automatically generates the communication boilerplate among components, data transfer among components can be modeled declaratively, by specifying the data flows in the reactive programming style.In this paper, we report on the ScalaLoci implementation and on our experience with embedding ScalaLoci's language features into Scala as a host language. We show how a combination of Scala's advanced type level programming and of Scala's macro system enable enriching the language with new abstractions for distributed systems. We describe the challenges we encountered for the implementation and report on the solutions we developed. Finally, we outline suggestions for improving the Scala macro system to better support embedding domain-specific abstractions. ACM CCS 2012The design of ScalaLoci unfolds around three major ideas. First, the distributed topology (i.e., separate locations that execute code) is explicit and specified by the programmer, who assigns code to each system component. Second, remote communication within the distributed system (i.e., with performance and failure characteristics different from local communication) is explicit and supports event-based interaction between components. Third, ScalaLoci abstractions are embedded as domain-specific features into an existing general purpose language. We lay out the design space for our language implementation and derive concrete design requirements.Explicit Specification of Distribution and Topology Some languages for distributed systems abstract over the topology, i.e., code is agnostic to the system's components and their connections. Such approach is often chosen for highly specialized programming models, e.g., streaming systems [16,62], intentionally hiding distribution. On the other end lie approaches where developers specify the topology. Distribution unavoidably becomes apparent when implementing different components, e.g., in actor systems [1]. While actor systems encapsulate components into actors, topological information is not encoded at the language level but managed explicitly by the developer.Clearly, a multitier programming model for developing generic distributed systems -similar to what the actor model offers -cannot abstract over distribution completely. To decide on the component that executes a specific part of the cod...

show abstract

Reactive Programming Extensions for Time-Sensitive IoT Applications

Peros

Hughes

2021

2021 17th International Conference on Distributed Computing in Sensor Systems (DCOSS)

View full text Add to dashboard Cite

Fault-tolerant Distributed Reactive Programming

Cited by 8 publications

References 0 publications

Topology-Level Reactivity in Distributed Reactive Programs

Topology-Level Reactivity in Distributed Reactive Programs

Implementing a Language for Distributed Systems: Choices and Experiences with Type Level and Macro Programming in Scala

Reactive Programming Extensions for Time-Sensitive IoT Applications

Contact Info

Product

Resources

About