Software- Architekturen
Event driven Architekture
Haupteigenschaften:
- Ereignisse werden mit publish-subscribe-Paradigma verteilt
- Aktuelle Verarbeitung: Ereignisse werden gleich versand und nicht lokal
gespeichert (im Gegensatz zu Batchverarbeitung)
- Asynchron: Der Sender wartet nicht auf den Empfänger
- push-Paradigma: Ereignisse werden weitergereicht [MH2014]
- Ereignisontologie: Ereignisse werden klassifiziert, Empfänger können sich Ereignisse einzelner Typen oder einer Kategorie bestellen.
- komplexe Ereignisse: System versteht und überwacht Ereignisse
- lose Kopplung zwischen Publisher und Subscriber, eine Komponente kann leicht ausgetauscht werden
- Leistung wird im Verbund von einfachen Aktorem erreicht. Das Gesamtverhalten des Systems habe ein selbstorganisierendes (emergentes) Verhalten [MH2014]
Weitere Vorteile:
- Replikation ist einfach möglich
- Die Daten werden zwischen mehreren Rechenknoten verteilt. Ein Clustermanager kontrolliert, daß alle Anwendungskomponenten laufen und startet gegebenfalls Anwndungskomponenten nach
- Einfache Testbarkeit
- Komponenten können durch Stimulatoren ersetzt werden
- Auf Ereignisquellen und Datenströme können wie SQL kombinierbare Operationen und Filter angewendet werden z.B. map, reduce, filter, select
Konstruktion:[MH2014]
- imperativ
- DSL wie Gpars
- implizite Ermittlung durch Introspektion von Programmstrukturen und Abläfen
Fehlerbehandlung: [MH2014]: Bei vielen Ereignissen kommen auch sehr unwahrscheinliche Ereignisse vor und müssen berücksichtigt werden.
Allerdings können zur Not auch Verarbeitsungskomponenten neu gestartet werden
Herausforderungen: [MH2014]:
- Selbstorganisation
- manchmal modellierbar aber schwer zu durchschauen
- Fehlersuche: Methode Aufzeichnung und Replay nach einem fixen Snapshot
Anwendungen
- Telekommunikation
- Systemsteuerung/Automatisierung
- Verarbeitung von großen Datenmengen in kurzer Zeit [MH2014]
Charakteristik:
- massiv parallele Systeme mit vielen Nutzern und latenzfreie Service level Agreements - an Semaphoren blockierte Threads gehen nicht mehr [MH2014]
- reaktive Anwendungen wollen eine lineare Skalierbarkeit Ereichen, gemäß dem Amdahlschen Gesetz muss der nichtparallelisierbare Anteil minimiert oder ganz vermeiden werden [MH2014]
Links
- Wikipedia über ereignisgesteuerte Architektur
- [MH2014] Michal Hunger: "Reactive (functional ) Programming" Javaspektrum 2/2014
- Reactive Manifesto
Weiterführend
- [Amsd11] E. Amsden, A Survey of Functional Reactive Programming, Rochester Institute of Technology, 2011
- [CQRS] M. Fowler, Command Query Responsibility Segregation, 14.7.2011,
- [Hung11] M. Hunger, Disruptorangriff: Hochperformanter Java- Code bringt Prozessoren an ihr Limit?, in: JavaSPEKTRUM, 6/2011
- [Hung12a] M. Hunger, Clojure-lntema, in: JavaSPEKTRUM, 4/2012
- [Hung12b] M. Hunger, GPars, in: JavaSPEKTRUM, 5/2012
- [Hung13] M. Hunger, Funktionale Handhabung von Containern:
Java 8 & Streams, in: JavaSPEKTRUM, 3/2013
Implementierungen
- [Rx] The Reactive Extensions, Microsoft
- RX-Wiki
- [RXEX] Rx-Beispiele
RxJava
RxJava Wiki
Client schickt komplexe Anfrage an Server, dieser zerlegt diese und nutzt mögliche Parallelität - anstatt der Client demserver eine suboptimale Reihenfolge aufzwingt. [MH2014]
- [ChHu13] B. Christensen, J. Husain, Functional Reactive in the Netflix API with RXJava, 4.2.2013
- [HuBr14] J. Husain, H. Brumleve, Netflix’s Reactive Programming Model via Rx, 27.1.2014
- [Nur14] T. Nurkiewicz, Turning Twitter4J into RxJava's observable, 1.9.2014,
- [RxJavaOps] RxJava-Operationen, RxJava Operations
Vert.x
Blockierende Operationen werden durch Callbacks ersetzt - mit EventLoop
- [Dirk13] Beispielanwendung: J. Dirksen, 4.12.2013
- [Vertx]Vert.x Homepage
- [VertxGitHub] VertxGitHub
- [Wolff12] E. Wolff, 1.6.2012
Akka
ist ein verteiltes Aktor-Framework
- [AM] Aktorenmodell
- [Krass13] M. Krassers Blog, 16.12.2013,
Introduction to Akka persistence
- [Past13] Akka-Uberblick: M. Pastor, Reactive Applications, 2013
Reactor
ist eine Infrastuktur für ereignisbasierte Anwendungen
- [Bris13a] Einführung von J. Brisbin, 13.5.2013,
- [Brisb13b] J. Brisbin, Webinar Replay: Reactorgoes GA, 17.12.2013
- [Reactor] GitHub, Reactor auf GitHub
- [Wolff13] E. Wolff,Reactor - Asynchrones Framework von SpringSource 27.5.2013
Beispiele
- LMAX Einzelhandels Finanzhandelsplatform
- [MF]:
JVM, Event Driven, in-Memory
Informatik- und Netzwerkverein Ravensburg e.V
Rudolf Weber