Reactive Programming versus Reactive Systems

Nicht selten besteht Unsicherheit darüber, ob von Reactive Programming oder Reactive Systems die Rede ist. Für Klarheit sorgt womöglich ein Artikel von Jonas Bonér und Viktor Klang.

In Pocket speichern vorlesen Druckansicht 1 Kommentar lesen
Lesezeit: 3 Min.
Von
  • Markus Eisele

Nicht selten besteht Unsicherheit darüber, ob von Reactive Programming oder Reactive Systems die Rede ist. Für Klarheit sorgt womöglich ein Artikel von Jonas Bonér und Viktor Klang.

Seit der Diskussion rund um Microservices und verteilte Systeme ist das Thema Reactive zunehmend auf den Konferenzen und Nachrichtenseiten zu finden. Wer im Internet nach "reactive programming" sucht, stolpert über viele interessante Beiträge. Java-Entwickler sind aber schnell aufgeschmissen und finden sich in einem Wust von JavaScript-Themen, Datenströmen und Events wieder. Wie man mit diesen Erkenntnissen Microservice-basierte Architekturen bauen soll, bleibt erst mal recht unklar. Einzig das Reactive Manifesto scheint hier ein wenig mehr Inhalt zu liefern:

"Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than disaster. Reactive Systems are highly responsive, giving users effective interactive feedback."

Nicht selten besteht Unsicherheit darüber, ob von Reactive Programming oder Reactive Systems die Rede ist. Für Klarheit sorgt womöglich ein Artikel von Jonas Bonér und Viktor Klang.

Vielleicht ist die Suche nach Reactive Programming gar nicht der richtige Weg, um weiterzukommen? Sind das, was gesucht wurde, nicht viel mehr Reactive Systems? Aber was genau ist der Unterschied? Das Reactive Manifesto versteht sich hier eher als eine gemeinsame Sprachkonvention und gibt grobe architekturelle Leitlinien. Aber was genau ist denn jetzt "Reactive"? Jonas Bonér und Viktor Klang haben sich in einem Artikel damit sehr umfangreich auseinandergesetzt und die Unterschiede verständlich herausgearbeitet.

Die wichtigsten Punkte hab ich hier mal zusammengefasst:

  • Seit 2015 gibt es ein enormes Interesse an Reactive – sowohl von kommerziellen Middleware-Anbietern als auch von Anwendern.
  • Reactive Programming ist eine bestimmte Untergruppe von Reactive Systems auf der Implementierungsebene.
  • Reactive Programming bietet Produktivität fĂĽr Entwickler – durch Leistung und Ressourceneffizienz – auf Komponentenebene fĂĽr das interne Logik- und Datenflussmanagement.
  • Reactive Systems bieten Produktivität fĂĽr Architekten und DevOps – durch Belastbarkeit und Elastizität auf Systemebene fĂĽr den Bau von "Cloud Native" oder anderen groĂźen verteilten Systemen.
  • Es ist sehr vorteilhaft, reaktive Programmierung innerhalb der Komponenten eines reaktiven Systems zu verwenden.
  • Es ist sehr vorteilhaft, Reactive Systems zu verwenden, um das System um die mit Reactive Programming geschriebenen Komponenten zu erstellen.

Der komplette Artikel umfasst mehrere Seiten und befasst sich mit allen Aspekten von Reactive im Sinne einer Sammlung von Design-Prinzipien. Das vollständige PDF (2,6 MByte) kann nach Registrierung bei Lightbend heruntergeladen werden. Es steht aber auch eine Online-Version zur Verfügung. ()