© Excellent backgrounds/Shutterstock.com
Java Magazin
Wie sich reaktiv im Code widerspiegelt

Von „Enterprise“ zu „Reactive“

Nicht mehr zu übersehen ist das zunehmende Interesse an der Entwicklung reaktiver Anwendungen - spätestens seit Ausgabe 5.2014 des Java Magazins, die es zum Titelthema machte. Viele Entwickler nehmen reaktiv aber bisher nur als vages Versprechen wahr, ohne eine konkrete Vorstellung davon zu haben, was auf Codeebene die wesentlichen Unterschiede zum gängigen Vorgehen, also in der Regel Java EE, ausmacht. Diesen Unterschieden wollen wir uns in diesem Artikel widmen.

Lutz Hühnken


Die Grundlagen reaktiver Systeme sind im Reaktiven Manifest [1] beschrieben und in vier Schlagworten schnell zusammengefasst: Ziel ist die Antwortbereitschaft des Systems, erreicht durch Elastizität und Widerstandsfähigkeit, auf Grundlage einer nachrichtenbasierten Kommunikation. Auf die erläuternden Hintergründe der einzelnen Begriffe soll hier nicht eingegangen werden, dafür sei auf das Manifest selbst verwiesen.

Nun liegt es in der Natur eines Manifests, dass es sehr grundsätzliche Forderungen aufstellt, aber darüber vage bleibt, wie diese technisch im Detail umzusetzen sind. Für den Java-Entwickler stellt sich also die Frage, wie sich reaktiv im Code widerspiegelt.

Serverseitige Java-Entwicklung, egal mit welchen Frameworks, spielt sich in der Regel im Java-EE-Umfeld ab. Zumindest das Servlet-API, das ja auch Teil von Java EE ist, wird höchstwahrscheinlich die Grundlage des verwendeten Web- oder REST-Frameworks sein. In der Tat gibt es nun in der reaktiven Entwicklung einige grundlegende Unterschiede dazu. Deren Unkenntnis führt zu Missverständnissen und Verwirrung, daher ist es sinnvoll, sich im Vorhinein mit einigen technischen Aspekten reaktiver Entwicklung vertraut zu machen. Ob bewusst oder nicht, die Erfahrung mit Java EE führt dazu, dass viele Dinge als gegeben angesehen werden, die aber in der reaktiven Welt so nicht mehr vorhanden sind. Es heißt also vor allem: Abschied nehmen von einigen vertrauten Konzepten.

Tschüss, Thread per Request

Das Servlet-API basiert im Grunde auf einem Thread-per-Request-Modell. Jedem Request, der eintrifft, wird ein eigener Thread zugewiesen – sei es ein neuer oder einer aus einem begrenzten Pool. Dieser Thread wird den Request abarbeiten (Abb. 1).

Um moderne Multicore-Prozessoren besser auszunutzen, ergänzen reaktive Systeme das Threadmodell um eine weitere Ebene, mit feinerer Granularität. Unterschiedliche Bibliotheken haben dafür unterschiedliche Ansätze. Prominenteste Vertreter auf der JVM sind Vert.x Verticles [2] und Akkas Aktoren [3]. Als allgemeiner Begriff für die Einheit einer Aufgabe unterhalb des Threadlevels hat sich „Task“ eingebürgert, in gewohnter Bevorzugung des Englischen wird also, unabhängig von der konkret zum Einsatz kommenden Bibliothek, von „Task Level Concurrency“ gesprochen.

Verdeutlichen lässt sich dies am einfachsten anhand einer Webanwendung. Der offensichtlichste Gegensatz zu „Thread per Request“ ist der Event Loop. In einem Event-Loop-Modell gibt es einen einzigen Event-Loop-Thread. F...

Java Magazin
Wie sich reaktiv im Code widerspiegelt

Von „Enterprise“ zu „Reactive“

Nicht mehr zu übersehen ist das zunehmende Interesse an der Entwicklung reaktiver Anwendungen - spätestens seit Ausgabe 5.2014 des Java Magazins, die es zum Titelthema machte. Viele Entwickler nehmen reaktiv aber bisher nur als vages Versprechen wahr, ohne eine konkrete Vorstellung davon zu haben, was auf Codeebene die wesentlichen Unterschiede zum gängigen Vorgehen, also in der Regel Java EE, ausmacht. Diesen Unterschieden wollen wir uns in diesem Artikel widmen.

Lutz Hühnken


Die Grundlagen reaktiver Systeme sind im Reaktiven Manifest [1] beschrieben und in vier Schlagworten schnell zusammengefasst: Ziel ist die Antwortbereitschaft des Systems, erreicht durch Elastizität und Widerstandsfähigkeit, auf Grundlage einer nachrichtenbasierten Kommunikation. Auf die erläuternden Hintergründe der einzelnen Begriffe soll hier nicht eingegangen werden, dafür sei auf das Manifest selbst verwiesen.

Nun liegt es in der Natur eines Manifests, dass es sehr grundsätzliche Forderungen aufstellt, aber darüber vage bleibt, wie diese technisch im Detail umzusetzen sind. Für den Java-Entwickler stellt sich also die Frage, wie sich reaktiv im Code widerspiegelt.

Serverseitige Java-Entwicklung, egal mit welchen Frameworks, spielt sich in der Regel im Java-EE-Umfeld ab. Zumindest das Servlet-API, das ja auch Teil von Java EE ist, wird höchstwahrscheinlich die Grundlage des verwendeten Web- oder REST-Frameworks sein. In der Tat gibt es nun in der reaktiven Entwicklung einige grundlegende Unterschiede dazu. Deren Unkenntnis führt zu Missverständnissen und Verwirrung, daher ist es sinnvoll, sich im Vorhinein mit einigen technischen Aspekten reaktiver Entwicklung vertraut zu machen. Ob bewusst oder nicht, die Erfahrung mit Java EE führt dazu, dass viele Dinge als gegeben angesehen werden, die aber in der reaktiven Welt so nicht mehr vorhanden sind. Es heißt also vor allem: Abschied nehmen von einigen vertrauten Konzepten.

Tschüss, Thread per Request

Das Servlet-API basiert im Grunde auf einem Thread-per-Request-Modell. Jedem Request, der eintrifft, wird ein eigener Thread zugewiesen – sei es ein neuer oder einer aus einem begrenzten Pool. Dieser Thread wird den Request abarbeiten (Abb. 1).

Um moderne Multicore-Prozessoren besser auszunutzen, ergänzen reaktive Systeme das Threadmodell um eine weitere Ebene, mit feinerer Granularität. Unterschiedliche Bibliotheken haben dafür unterschiedliche Ansätze. Prominenteste Vertreter auf der JVM sind Vert.x Verticles [2] und Akkas Aktoren [3]. Als allgemeiner Begriff für die Einheit einer Aufgabe unterhalb des Threadlevels hat sich „Task“ eingebürgert, in gewohnter Bevorzugung des Englischen wird also, unabhängig von der konkret zum Einsatz kommenden Bibliothek, von „Task Level Concurrency“ gesprochen.

Verdeutlichen lässt sich dies am einfachsten anhand einer Webanwendung. Der offensichtlichste Gegensatz zu „Thread per Request“ ist der Event Loop. In einem Event-Loop-Modell gibt es einen einzigen Event-Loop-Thread. F...

Neugierig geworden?


    
Loading...

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