© Excellent backgrounds/Shutterstock.com
„Reactive Programming“ unter der Lupe

Allzeit bereit


Im Sommer 2013 hat eine Gruppe von Softwareentwicklern um Jonas Bonér das „Reactive Manifesto“ veröffentlicht [1]. Es beschreibt vier Eckpfeiler für „neue Architekturen“, um die Anforderungen an moderne Systeme zu erfüllen. Inzwischen haben mehr als viertausend Personen das Manifest online unterschrieben, darunter auch ich. Mit wachsender Bekanntheit haben die Diskussionen um das Manifest und seine Ideen zugenommen, durchaus auch ­kritisch (z. B. [2]). Viel spannender als das Manifest selbst und die Frage, ob es sinnvoll und gut formuliert ist oder nicht, sind aber seine Ideen, die Trends, die es aufgreift und die Lösungsansätze, die es formuliert. Und genau darum soll es in diesem Artikel gehen.

„Klassische“ Geschäftsanwendungen schreiben Daten in eine relationale Datenbank und können sie später wieder herausholen. Sie sind transaktional: Wenn man eine Änderung erfolgreich gespeichert hat, ist sie sofort für alle Benutzer sichtbar. Sie bestehen aus Schichten. Wenn ein Request das System erreicht, erhält er einen Thread. In diesem Thread erfolgt dann die Verarbeitung – Validierung, Datenbankzugriff, Geschäftslogik und schließlich Serialisierung der Antwort. Das Ganze erfolgt typischerweise in einer einzigen Transaktion, die typischerweise am Thread hängt.

Das Ganze läuft in einem Application Server und wird (in der Java-Welt) durch Frameworks unterstützt – EJB, Spring, Hibernate/JPA, JSF etc. Und wenn man Ausfallsicherheit braucht oder die Rechenleistung skalieren will, nimmt man mehrere Server und verbindet sie zu einem Cluster. Diese „klassische“ Architektur ist im Kern seit dreißig Jahren unverändert. Es ist im Wesentlichen die Architektur von Mainframesystemen – wenn auch mit Kapselung und einer bunteren Oberfläche. Es gibt eine zentrale Datenbank, die „die Wahrheit“ enthält. Und der Rest des Systems bereitet empfangene Daten für die Datenbank auf oder präsentiert den Anwendern (oder Web Services etc.) Daten aus der Datenbank.

Das ist natürlich eine vereinfachte Sicht, aber viele Systeme werden mehr oder weniger nach diesem Paradigma gebaut. Und das Ganze funktioniert. Oft sogar nicht einmal schlecht. Warum also etwas daran ändern?

„non-blocking“ schont Ressourcen

Zunächst einmal geht die „klassische“ Architektur ziemlich verschwenderisch mit Threads um. Jeder Request läuft in seinem eigenen Thread und blockiert diesen, bis die Verarbeitung abgeschlossen ist. Gerade bei Geschäftsanwendungen entfällt oft nur ein kleiner Teil der Zeit auf Geschäftslog...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang