Wie bereits angekündigt werde ich in den nächsten Wochen erläutern, wie man im Java-Ökosystem RMI sicher betrieben kann.

Wie ich bereits geschildert habe existieren zwei verschiedene Methoden, Remote Objects in der Registry zu finden - einer ist, die API der Registry direkt zu benutzen, der andere, über JNDI daruf zuzugreifen. Es stellt sich heraus, dass JNDI nur funktioniert, wenn die Registry TLS nicht benutzt. Damit ist zwar die Benutzungsphase immer noch abgesichert, nicht jedoch die Initialisierungsphase des Registrierens und des Lookup der Objekte. Man kann - abhängig von den jeweiligen individuellen Anforderungen mit dieser Einschränkung leben - besser wäre es aber, auf den ausschließlichen Gebrauch der direkten API zu setzen und Teile bestehender Anwendungen, die immer noch JNDI benutzen auf diese API umzustellen.

Aus diesem Grund habe ich ein altes OpenSource-Projekt wiederbelebt. Dieses Projekt ermöglicht es - kurz gesagt - einen Compute-Server zu erstellen, der auf verschiedene Nodes deployt werden kann. Dann kann ein Anwender von einer zentralen Anwendung aus Compute-Aufträge auf diese Nodes verschoben werden, die auf den Nodes ausgeführt werden und deren Ergebnisse an die Anwendung zurückgemeldet werden. Die neue Qualität hier ist, dass das Feature von RMI, benötigte Klassen nachladen zu können, bis zum Exzess ausgereizt wird: Auf den Compute-Nodes existieren erst einmal gar keine anwendungsspezifische Klassen - sie werden durch die Anwendung, die einen der früher bechriebenen HTTPS-Server für Bytecode realisiert, zur Verfügung gestellt.

Dadurch realisiert man extrem flexible Compute Nodes, die in der Lage sind, ohne Änderung an der Node oder ihrer Software neue Funktionalitäten zu supporten - immer dann, wenn die eigentliche Anwendung neue Features unterstützt. Dadurch muss nur noch die Anwendung gewartet und aktualisiert werden - Nach jedem Update kann die Anwendung neue Funktionalitäten auf die Compute-Nodes auslagern, deren Software muss dafür jedoch nicht angepasst werden.

Allerdings war es notwendig, die API dazu zu ändern und von der Benutzung von JNDI weg zur Benutzung der direkten API der Registry hin zu ändern. Diese neue Version steht nun in einem entsprechenden Codeberg-Repository zur Verfügung. Eine erste Anwendung, die diese Version nutzt ist dWb+ ab Version 4.4pre2 build 11256.

Genaueres zu den Hintergründen ist in diesem Artikel zu finden.