Reactive Design Patterns - Roland Kuhn and Jamie Allen
27.09.2015 Thomas Mohme
Reactive Design Patterns
Das Buch
Reactive Design Patterns
EARLY ACCESS EDITION
Roland Kuhn and Jamie Allen
MEAP Began: March 2014, v08
Softbound print: December 2015 (est.), 325 pages, B&W
ISBN: 9781617291807
Die Rezension beruht auf der MEAP PDF Version 8 vom 23.9.2015.
Worum geht es?
Gemäß dem Titel wird das Design reaktiver Systeme, genauer gesagt verschiedene "Standard Muster" hierfür, behandelt. "Reactive Design" ist seit dem "Reactive Manifesto" von 2013, spätestens jedoch seit dessen Version 2.0 von 2014, eines der Buzzwords, die man zumindest einordnen können sollte.
Für Softwarearchitekten ist "Reactive Design" ein weiterer Lösungsansatz für komplexe Anwendungen, die hoch skalierbar sein müssen.
Der gegenwärtige Hype um das Thema scheint mir jedoch Züge anzunehmen, die kaum noch gerechtfertigt sind. Umso wichtiger ist es, sich selber ein Urteil bilden zu können, wozu dieses Buch hoffentlich beitragen kann.
Die Autoren Roland Kuhn und Jamie Allen gehören als führende Typesafe Mitarbeiter zum "inneren Zirkel" derjenigen, die den Hype maßgeblich mit begründen.
Als guter Einstieg in das Thema sei auf die Artikelserie "Reactive Programming - vom Hype zum Praxiseinsatz" auf heise-developer verwiesen.
Inhalt - Was man erwarten kann
Das Buch ist von Aufbau und Inhalt her keine 1:1 Adaption des Klassikers von Erich Gamma et al. Insgesamt beschäftigt sich das Buch deutlich mehr mit Problem Setting und Motivation (zur Implementierung einer Lösung), als der eingangs genannte Klassiker.
Während in dem Klassiker von Erich Gamma et al die dort beschriebenen Muster - nach einem einführenden Fallbeispiel - in der Art eines Nachschlagewerkes in einheitlicher Form (Intent, Motivation, Applicability, Structure, Participants, Collaborations, Consequences, Implementation) dargestellt werden und im Buch den weit überwiegenden Raum einnehmen, ist dies hier nicht der Fall.
Nach einem ähnlichen Beginn mit ebenfalls einem einführenden Beispiel werden zunächst viele Seiten dafür verwendet, die Notwendigkeit des "Reactive Design" Paradigmas zu begründen (Kapitel 2, "Why Reactive").
Das folgende Kapitel 3 ("Tools of the Trade") beginnt inhaltlich mit einer Fortsetzung des vorherigen ("The impact of choosing non-reactive tools"), deren Beispiele nicht ganz schlüssig sind . . . jedenfalls werden hier Probleme "klassischer" Architekturansätze dargestellt, die auch mit "klassischen" Mitteln durchaus vermeidbar sind.
Weiter geht es über "Functional Programming", "Responsiveness to Users" bis hin zu Vorstellungen von Techniken, die Reactive Programming ermöglichen bzw. erleichtern ("Green Threads", "Event Loops", "Communicating Sequential Processes", "Futures and Promises", "Reactive Extensions" "Actor Model"). Auf mich wirkt diese Sammlung ungeordnet.
Ab hier wird "Reactive System" in dem Buch quasi implizit mit "Actor System" gleichgesetzt. Bei den Autoren ist das nicht verwunderlich, trotzdem aber vielleicht zu einschränkend.
Im zweiten Teil des Buches ("The Philosophy in a Nutshell") wird auf 86 Seiten ausführlich auf Implementierungsstrategien und Nicht-Funktionale Anforderungen eingegangen. Im Kapitel "Message Passing" wird ein guter Überblick über dessen wesentliche Eigenschaften geliefert.
Weiter geht es mit dem Nutzen von "Location Transparency" und "Divide and Conquer". Gerade letzteres Kapitel ist mir zu allgemein gehalten. Es werden nur sehr vage Grundsätze dafür genannt, welche Kriterien im allgemeinen angewendet werden müssen, um zu einer "guten" Zerlegung zu gelangen. Nach meiner Erfahrung ist genau dies aber schon der Punkt, an dem sich die Spreu vom Weizen trennt - im Sinne von "Sackgasse" vs. gut implementierbares, testbares und dauerhaft anpassbares Design. Vielleicht würde eine tiefere Betrachtung aber auch zu sehr in Richtung Domain Driven Design (DDD) abgleiten. Wenigstens liefern die folgenden Kapitel "Principled Failure Handling" und "Delimited Consistency" konkretere Ansätze für Design-Kriterien.
Der zweite Teil des Buches schließt mit den Kapiteln "Non-Determinism by Need" und "Message Flow". Gerade letzteres liefert für Leser, die aus der "klassischen" Schule kommen, wertvolle Hinweise.
Der dritte Teil des Buches, "Patterns", umfasst (derzeit) 131 Seiten. Er beginnt mit einem Kapitel über das Testen verschiedener Aspekte von Reactive Systems, die in dieser Form in klassischen Anwendung kaum beachtet werden. Es geht hier nicht darum, wie die Business-Anwendung getestet werden kann, sondern um das Test von Eigenschaften wie "Elasticity", "Resilience" und "Responsiveness" in einem asynchronen, nicht-deterministischen System.
Schließlich gelangen wir zum Kapitel "Fault Tolerance and Recovery Patterns" (56 Seiten). Folgende Patterns werden hier behandelt:
- Simple Component
- Let It Crash
- Error Kernel
- Circruit Breaker
- Active-Passive Replication
- Multi-Master Replication
- Acitve-Active Replication
Die einzelnen Patterns werden grundsätzlich in der folgenden Strukur beschrieben:
- Problem Setting
- Applying the Pattern
- The Pattern revisited
- Applicability
Die Beschreibungen der Patterns beinhalten teilweise Hinweise, wie man ein Problem "formen" muss/kann, damit das jeweilige Pattern eingesetzt werden kann.
Die Patterns unterscheiden sich zum Teil drastisch in ihrer Komplexität und damit auch in der Ausführlichkeit der Betrachtung. Die Bandbreite reicht von abstrakten Besprechungen bis hin zu mehreren Seiten Scala-Code, bei dem einzelne If-Statements besprochen werden.
Als letztes Kapitel wurde gerade frisch "Resource Management Patterns" mit folgenden Patterns veröffentlicht:
- Resource Encapsulation
- Resource Loan
- Complex Command
- Resource Pool
- Patterns for Managed Blocking
Die einzelnen Patterns werden jeweils auf 5~8 Seiten beschrieben.
Was ich vermisse
Etliche Jahre mit Online Transaction Processing (OLTP) Systemen haben bei mir eingebrannt, immer und überall auf Konsistenzgrenzen zu achten. Bei den in den Patterns verwendeten isolierten Komponenten wird Konsistenz (aus Benutzersicht) nicht automatisch erreicht. Hier fehlen mir Anregungen, wie und zu welchen Kosten dies erreicht werden kann.
Aus der Umsetzung einiger der beschriebenen Patterns resultiert eine Menge Code. Ich vermisse Hinweise darauf, wie man diesen Code
- sauber von der Business Logik trennen kann
- so organisieren kann, dass er möglichst nicht wiederholt werden muss
Natürlich kann man sich diese Aspekte selbst im Projekt erarbeiten und ganz ohne eigenes Nachdenken kann es nicht funktionieren. Aber gerade Zeit für einfach zu vermeidende Anfängerfehler (weil man noch nicht gesehen hat, was "hinter der Kurve" kommt) möchte ich mir im Projekt ersparen.
Was mir gefiel
- Die speziellen Hinweise zum Testen reaktiver Anwendungen.
Insbesondere für diesen Bereich gibt es im Netz (und erst recht in der gedruckten Literatur) bisher so gut wie keine Tipps, wie man die qualitativen und quantitativen Aspekte einer reaktiven Anwendung nachweisen kann und welche Tücken dabei zu umschiffen sind.
Hiermit hat das Buch derzeit ein Alleinstellungsmerkmal. - Für Einsteiger in das Thema wird ausgiebig auf die Schwachstellen konventioneller Architekturen und die passenden Lösungsansätze aus der reaktiven Gedankenwelt eingegangen. Hierdurch sollte es jedem erfahrenen Entwickler möglich sein, dem Inhalt folgen zu können.
- Für Fortgeschrittene tragen die vorgestellten Patterns das entsprechende Wissen in kompakter Form zusammen. Manches davon ließe sich auch im Netz finden . . . allerdings nur mit wesentlich mehr Zeitaufwand.
Was mir nicht gefiel
- Die beschriebenen Patterns (insbesondere im Kapitel "Fault Tolerance and Recovery Patters") bzw. die Beschreibungen schwanken stark in ihrem Abstraktionsgrad.
- Die Replication-"Patterns" sind eher Strategien / Lösungsansätze, ergänzt um Realisierungsdetails, denn Patterns, wie man sie aus dem klassischen Buch kennt.
- An mehreren Stellen kann ich die Argumentation der Autoren für oder gegen bestimmte Techniken nicht vollständig nachvollziehen. Manches Problem, das in klassischen Design-Ansätzen hervorgehoben wird, lässt sich dort einfach vermeiden oder existiert (bei ungeschickten Detail-Entscheidungen) ebenso bei Reactive Design. Dies ist zum Teil aber eher eine Diskussion über die dargelegte Technik, als über das Buch.
Fazit
Mit dem Buch versuchen die Autoren, eine Lücke im Markt zu schließen - was bis jetzt nur teilweise gelingt.
Das Buch vermittelt eine Menge Wissen, wobei die Struktur m.E. (zumindest in der MEAP Version 8) noch nicht optimal ist.
Die Zielgruppe des Buches ist mir nicht klar. Mit dem relativ großen Anteil (71 Seiten) zur Motivation von "Reactive Programming" spricht es eher Einsteiger auf diesem Gebiet an. Der zu den Patterns überleitende Teil ("The Philosophy in a Nutshell", 60 Seiten) könnte außerdem auch für Fortgeschrittene interessant sein. Für Einsteiger ist manches im Pattern-Teil (131 Seiten) präsentierte allerdings harter Stoff.
Das Buch ist "Work in Progress", soll nach jetzigem Stand "early 2016" fertiggestellt werden. Kapitel über Patterns aus den Bereichen
- Message Flow
- Flow Control
- Persistence
- Writing Actors
sollen folgen. Mit ihnen dürften sich die Anteilsverhältnisse der drei Teile des Buches zueinander erheblich ändern.
In der jetzigen Form ist das Buch für Einsteiger in das Thema sicher schon interessant. Fortgeschrittene werden noch warten wollen, bis mehr Kapitel zu den eigentlichen Patterns veröffentlicht wurden.