Die Idee ein Framework zu entwickeln, dass ganz auf Messages zur Kommunikation zwischen den Komponenten basiert, ist interessant. Ich habe schon verschiedene Ansätze in der Java-Welt gesehen, z.B. Versuche, das in JavaEE mit JMS zu bauen. Letztlich ist das in der Java- und JVM-Welt ein eher selten verwendeter Ansatz, aber z.B. Erlang-Software basiert komplett auf diesem Prinzip, wobei natürlich effiziente Messaging-Mechanismen vorausgesetzt werden müssen.
Das Akka-Toolkit oder Akka Framework setzt diese Idee nun in konsequenter Weise für die Java- und JVM-Welt um, wobei es natürlich am besten in seiner nativen Sprache, also in Scala verwendet wird. Die Idee ist, eine effiziente massive Parallelisierung hinzubekommen und durch assynchrone Kommunikation die Komponenten weitestgehend zu entkoppeln. Typisch in der Scala-Welt ist es, dass man unveränderliche (deep immutable) Objekte in den Messages verschickt, um Änderungskonflikte und Fehler zu vermeiden, wenn dasselbe Objekt an mehreren Orten gleichzeitig verwendet wird. Veränderbare Objekte in den Messages sollte man vermeiden, außer man kennt das Framework und die Multithreading-Thematik sehr gut und weiss was man tut und es ist aus Performance-Gründen wirklich ein so großer Vorteil, dass der zusätzliche Entwicklungs- und Testaufwand gerechtfertigt ist. Dabei ist noch zu sagen, dass sich solches Verhalten kaum testen lässt, weil das Zeitverhalten in den Tests nie genau das im ungünstigsten Fall auf dem Produktivsystem sporadisch auftretende Zeitverhalten ist. So können in schlecht oder fahrlässig programmierten Applikationen noch Fehler lauern, die erst irgendwann auf dem Produktivsystem auftreten und die sich dann noch schlecht einordnen lassen. Genau deshalb sollte man hier auf Nummer sicher gehen und nur deep-immutable Objekte in Messages verschicken.
Für die Parallelisierung von Software gibt es grundsätzlich verschiedenen Ansätze. Mehrere getrennte Prozesse sind attraktiv, weil die Trennung sauber ist und man nur bei der Kommunikation überhaupt aufpassen muss. Dafür sind sie etwas schwergewichtiger als Threads und vor allem ist der Aufwand für de Kommunikation größer. Mehrere Threads zu verwenden hat den Vorteil, dass man dasselbe Memory benutzt und deshalb Daten einfacher getauscht werden können. Dafür steigen auch die Risiken, wenn mehrere Zugriffe auf dasselbe Objekt gleichzeitig stattfinden und mindestens einer davon schreibend ist.
Akka verwendet sogenannte Aktoren (engl. Actors), die einen Memory-Footprint von unter 1 k haben sollen, weshalb man etwa eine Million Actors durchaus gleichzeitig im Memory haben kann. Nun werden diesen Actors Messages geschickt, die etwa Methodenaufrufen in der (synchronen) objektorientierten Denkweise entsprechen, aber assynchron sind. Das heißt, dass der Sender die Message verschickt und dann fertig ist. Sie wird in einer Warteschlange für den passenden Actor eingereih und dann irgendwann abgearbietet. Nun hat so ein Actor nicht permanent einen Thread zugewiesen, sondern es gibt einen Threadpool. Actors mit einer nicht-leeren Warteschlange werden dann einem Thread im Threadpool zugewiesen und so abgearbeitet.
Schreibe einen Kommentar