Ich bitte um Entschuldigung für den denglischen Titel dieses Artikels. Ich habe vor vielen Jahren eine interessante Bibliothek gefunden, die noch aus meiner Arbeit am Institut für Neuroinformatik der TU Ilmenau heraus motiviert war.

Distributed dWb+

Aus dieser Arbeit entstand etwas, das man heutzutage wohl lowcode nennen würde: dWb+.

Diese Anwendung (die immer noch) von mir weiterentwickelt und gepflegt wird, bietet die Möglichkeiten, Module zur Datenverarbeitung miteinander zu verbinden. Über diese Verbindungen fließen Daten von Modul zu Modul und werden innerhalb dieser Module transformiert. Jedes dieser Module verfügt über definierte Ein- und Ausgänge.

Ein Rechner allein hat aber nur eine begrenzte Rechenkapazität. Dabei liegen die Grenzen nicht allein in der Anzahl möglicher Rechenvorgänge pro Zeiteinheit. Die Begrenzungen können sich ganz allgemein auf alle Arten von Ressourcen in einem Computer (wie zum Beispiel zur Verfügung stehender Arbeitsspeicher) beziehen wie auch auf konkrete physische Voraussetzung - zum Beispiel das Vorhandensein spezieller Hardware (Sensoren oder Aktoren)

Eine naheliegende Lösung für dieses Dilemma kömmte es sein, die Anwendung einfach auf mehreren Rechnern zu starten und dedizierte Module zu schaffen, die es erlauben, Daten zwischen den einzelnen Anwendungsinstanzen zu übertragen und damit die einzelinstanzen zu einer einzigen virtuellen Arbeitsumgebung zu verknüpfen.

Das hat mehrere Nachteile: die Lösung bedingt es, dass jeder eingebundene Rechner über ein entsprechendes graphisches Human Machine Interface verfügt. Weiterhin ist es schwierig, auf diese Art und Weise das Gesamtbild der Lösung im Blick zu behalten. Einzelne Aspekte sind ja bei diesem Vorgehen auf unterschiedlichen - eventuell räumlich weit auseinander befindlichen Rechnern gespeichert. Zur Änderung - dWb+ ist auch als Rapid-Prototyping Lösung vorgesehen - müssen Bediener an den einzelnen Arbeitsstationen korrdiniert werden.

Ein weiterer Kritikpunkt an dieser Lösung ist, dass die Versionen der Anwendung zwischen allen an einer bestimmten Lösung beteiligten Rechnern immer synchron gehalten werden muss. Das betrifft sowohl die eigentliche Kernanwendung, wie auch alle Module, die in einer Lösung zum Einsatz kommen. Auch das ist ein aufwändiger und fehleranfälliger Prozess.

Ich entschied mich daher - wobei das hier skizzierte Vorgehen weiterhin möglich ist - für eine andere Variante.

RMI

Ich benutzte dafür Remote Method Invocation - Javas Methode zur Verteilung einer Anwendung über mehrere Rechner hinweg. Dies hat den Charm, dass man auf anderen als dem zentralen Rechner nur einem minimale Rumpfanwendung ausrollen muss, die es erlaubt, mittels RMI Aufgaben zu empfangen. die Architektur hinter RMI erlaunt es nämlich, benötigte Klassen, beziehungsweise deren Bytecode (über das Netzwerk) bei Bedarf nachzuladen.

Damit muss die Rumpfanwendung pro Compute-Node nur einmalig ausgerollt werden. Ändert sich an der Implementierung einzelner Module etwas, muss lediglich die Kernanwendung neu ausgerollt werden - durch die Magie des RMI-ClassLoaders wird der benötigte neue ByteCode transparent und bei Bedarf an die Compute Nodes ausgerollt.

RNI hat aber leider das Problem, dass es sehr schwierig ist, damit einen gewissen - und heute als Stand der Technik erwarteten - Schutz der übertragenen Daten, wie auch der Kommunikationspartner zu gewährleisten. Das liegt unter anderem daran, dass für eine RMI-Verbindung drei verschiedene Socketverbindungen benötigt werden: Die zur Kommunikation mit der Registry, die zur Komunikation der Komponenten untereinander und (optional) die, über die die fehlenden Bytecodes der benötigten Klassen nachgeladen werden können.

Ich werde hier in loser Folge eine Reihe von Artikeln veröffentlichen, die diese Aspekte genauer beleuchten...