Die vorliegende Version des Roblet®-Servers bringt im Hinblick auf einen langzeitlichen und sicheren Betrieb von Servern einige wenige Randbedingungen für der Entwicklung von Roblets® mit sich. Sie sind im wesentlichen durch den momentanen Stand der Implementierung des Servers, teilweise aber auch durch die momentane Definition der JVM bedingt.
An der Aufhebung der sich ergebenen Einschränkungen gearbeitet. Schon jetzt jedoch ist unter Beachtung der Hinweise ein störungsfreier Betrieb von Servern möglich. Dazu können zusätzlich in produktiver Umgebung weitere Maßnahmen zur Sicherung getroffen werden. Von zentraler Bedeutung ist dabei der Einsatz von VPN, SSH-Tunneln u.a.m. zur Sicherung der Integrität von Kommunikation jeder Art.
Gern geben wir über das im folgenden geschriebene hinaus weitere praktische Hinweise. Kontaktieren Sie uns einfach per Mail an genControl@genRob.com.
| Randbedingung | Ursache | Lösung | ||
|---|---|---|---|---|
| kurzfristig | mittelfristig | langfristig | ||
| Ein direktes Benutzen von Ressourcen und Bibliotheken zu Ressourcen ohne Kontrolle durch den Server darf grundsätzlich nicht geschehen - die Nutzung muß über Einheiten erfolgen | Der Server hat so keine Möglichkeit die jeweilige Ressource hinsichtlich der parallelen Nutzung durch verschiedene Roblets® zu verwalten (sofern das keine im JDK o.ä. befindliche Bibliothek tut) und für den Fall, daß der Server ein Roblet® zwangsweise beendet, welches gerade eine solche Ressource/Bibliothek benutzt, verbleibt letztere mit einer gewissen Wahrscheinlichkeit in einem inkonsistenten Zustand (da derartige Fälle in aller Regel bei der Entwicklung des Schnittstelle der Ressource bzw. der Bibliothek nicht berücksichtigt wurden). | Durch Aktivierung der Sicherheitsmechanismen wird eine Nutzung solcher Ressourchen durch Roblets® mit einer Ausnahme quittiert. Zusätzlich muß beim Start des Servers sichergestellt werden, daß keine Bibliotheken außerhalb des JDK im Klassenpfad sind, die den Zugriff auf Ressourcen ohne die Verwendung von Sicherheitsmechanismen zulassen (oftmals selbstgeschriebene Bibliotheken). | Ab der nächsten Hauptversion werden Server stets eine Nutzung von Ressourcen durch Roblets® mit einer Ausnahme quittieren. Zusätzlich muß trotzdem beim Start des Servers sichergestellt werden, daß keine Bibliotheken außerhalb des JDK im Klassenpfad sind, die den Zugriff auf Ressourcen ohne die Verwendung von Sicherheitsmechanismen zulassen (oftmals selbstgeschriebene Bibliotheken). | Es wird an der Bereitstellung eines "Stellvertreter"-JDK gearbeitet, welches den Roblets® eine "eigene Welt" vorspiegelt. Allerdings haben erste Untersuchungen gezeigt, daß das JDK und die JVM dafür noch einige "Freiheiten" und Mechanismen bereitstellen müssen. |
| Randbedingung | Ursache | Lösung | ||
| kurzfristig | mittelfristig | langfristig | ||
| Starten von Threads (java.lang.Thread) darf nur in der Threadgruppe (java.lang.ThreadGroup) des ersten Threads des Roblets® oder in untergeordneten Gruppen geschehen | Der Server verwendet die Gruppierungsmechanismen zum Betreuen der Roblets®. |
Variante A: Beim Code-Review sind alle Fälle zu untersuchen. |
Eine Lösung mit Einsatz eines speziellen, noch strikteren
Security-Managers für eine situationsabhängige Behandlung wird
momentan untersucht. Alternativ: Der Server prüft jede Klasse noch vor der Übergabe an die JVM, ob ThreadGroup eingesetzt wird und weist derartige Klassen gegebenenfalls zurück. |
Sobald das JDK eine Möglichkeit bereitstellt, die Erzeugung von Threads und das Holen von ThreadGroup-Referenzen feiner mitzuverfolgen, kann der Server automatische Korrekturen vornehmen. Ein Roblet® würde dann gar nicht mitbekommen, daß es noch andere Thread-Gruppen gibt. |
|
Variante B: Nicht unüblich ist auch eine Richtlinie für alle Entwickler, die das generelle Verbot von ThreadGroup und getThreadGroup vorsieht. Die Einhaltung kann leicht über textbasierte Suche über alle Quellen sichergestellt werden. |
||||
| Threads eines Roblet® dürfen keine Priorität höher als die des ersten Threads haben | Die Verwendung von Prioritäten höher als die initiale des ersten Threads des Roblets® kann die Funktion des Servers empfindlich beeinträchtigen. Der Server ist dann bei hoher Auslastung nicht mehr in der Lage, zuverlässig seine Arbeit zu tun bis hin zu ungewöhnlichen Ausnahmen. |
Variante A: Beim Code-Review sind alle Fälle zu untersuchen. |
Eine Lösung mit Einsatz eines speziellen, noch strikteren
Security-Managers für eine situationsabhängige Behandlung wird
momentan untersucht. Alternativ: Der Server prüft jede Klasse noch vor der Übergabe an die JVM, ob setPriority eingesetzt wird und weist derartige Klassen gegebenenfalls zurück. |
Sobald das JDK eine Möglichkeit bereitstellt, das Setzen der Prioritäten feiner mitzuverfolgen, kann der Server automatische Korrekturen vornehmen. Ein Roblet® würde dann gar nicht mitbekommen, wie die gesetzten Prioritäten tatsächlich umgesetzt werden. |
|
Variante B: Nicht unüblich ist auch eine Richtlinie für alle Entwickler, die das generelle Verbot von setPriority vorsieht. Die Einhaltung kann leicht über textbasierte Suche über alle Quellen sichergestellt werden. |
||||
| Randbedingung | Ursache | Lösung | ||
| kurzfristig | mittelfristig | langfristig | ||
| Nur von java.lang.Exception abgeleitete Ausnahmen dürfen abgefangen werden |
Ein pauschales Abfangen von java.lang.Throwable oder
java.lang.Error und Ableitungen verhindert, daß der Server
über die jeweils entstandene Situation informiert wird.
Es handelt sch dabei in alle Regel um Problemsituationen, die nicht
im Rahmen eines Roblets® geklärt werden können. Keinesfalls darf java.lang.ThreadDeath abgefangen werden, ohne danach sofort geworfen zu werden. |
Variante A: Beim Code-Review sind alle Fälle zu untersuchen. |
Der Server prüft jede Klasse noch vor der Übergabe an die JVM, ob die Klassen Throwable oder Error eingesetzt werden und weist derartige Klassen gegebenenfalls zurück. | Sobald die JVM eine Möglichkeit bereitstellt, "von außen" zu steuern, welche Ausnahmen bei Roblets® angkommen dürfen, kann diese Randbedingung aufgehoben werden. Der Server kann dann alle für seine Arbeit relevanten Typen selbst verarbeiten und so die Roblets gegebenenfalls unterstützen oder - als letzten Ausweg - beenden. |
|
Variante B: Nicht unüblich ist auch eine Richtlinie für alle Entwickler, die das generelle Verbot von Throwable und Error vorsieht. Die Einhaltung kann leicht über textbasierte Suche über alle Quellen sichergestellt werden. |
||||
| finally in Klassen einer Anwendung unerwünscht, die von Roblets® benutzt werden. | Die Verwendung von finally birgt das Risiko, daß Ausnahmen vom Typ java.lang.Error in Roblets® nicht korrekt an den Server weitergereicht werden. Dadurch kann ein inkonsistenter Zustand im Roblet® oder sogar Server entstehen. |
Variante A: Beim Code-Review sind alle Fälle zu untersuchen. |
Der Server prüft jede Klasse noch vor der Übergabe an die JVM, ob finally eingesetzt wird und weist derartige Klassen gegebenenfalls zurück. | Sobald die JVM eine Möglichkeit bereitstellt, "von außen" zu steuern, welche Ausnahmen bei Roblets® angkommen dürfen, kann diese Randbedingung aufgehoben werden. Der Server kann dann alle für seine Arbeit relevanten Typen selbst verarbeiten und so die Roblets gegebenenfalls unterstützen oder - als letzten Ausweg - beenden. |
|
Variante B: Nicht unüblich ist auch eine Richtlinie für alle Entwickler, die das generelle Verbot von finally vorsieht. Die Einhaltung kann leicht über textbasierte Suche über alle Quellen sichergestellt werden. |
||||
| Randbedingung | Ursache | Lösung | ||
| kurzfristig | mittelfristig | langfristig | ||
| finalize() in Klassen einer Anwendung unerwünscht, die von Roblets® benutzt werden | Die Verwendung von finalize()-Methoden führt teilweise zu Aktivitäten nach dem Ende eines Roblets® und sollte grundsätzlich vermieden werden. Erfahrungsgemäß können viele Module damit nicht umgehen, da sie vom Server bereits über das Ende eines Roblets® informiert wurden. Im Zuge dessen entstehen (in seltenen Fällen) schwer einzugrenzende Fehlerzustände. |
Variante A: Beim Code-Review sind alle Fälle zu untersuchen. |
Der Server prüft jede Klasse noch vor der Übergabe an die JVM, ob die Methode finalize() eingesetzt wird und weist derartige Klassen gegebenenfalls zurück. | Sobald die JVM eine Möglichkeit bereitstellt, den Prozeß der Instanzerzeugung "von außen" zu überwachen, können alle Instanzen eines Roblets® in ihrem Lebenszyklus bis hin zur Garbage-Collection betreut werden. Der Server weiß dann genau, wann auch die letzte von einem Roblet® benutzte Instanz vergangen ist und informiert entsprechend erst danach die Module über das Ende eines Roblets®. |
|
Variante B: Nicht unüblich ist auch eine Richtlinie für alle Entwickler, die das generelle Verbot von finalize() vorsieht. Die Einhaltung kann leicht über textbasierte Suche über alle Quellen sichergestellt werden. |
||||
| native in Klassen einer Anwendung unerwünscht, die von Roblets® benutzt werden. | Die Verwendung von native ist in der Roblet®-Technik nicht erwünscht, da dem Roblet®-Server durch die jetzigen JVM's keine Möglichkeit der Kontrolle eingeräumt werden kann. | Durch Aktivierung der Sicherheitsmechanismen wird eine Nutzung von native durch Roblets® mit einer Ausnahme quittiert. | Ab der nächsten Hauptversion werden Server stets eine Nutzung von native durch Roblets® mit einer Ausnahme quittieren. | Sobald die JVM eine Überwachung von native-Schnittstellen "von außen" ermöglicht, kann ein Server solche Aufrufe in den Aufruf von Modul-Funktionalität übersetzen. Dann wäre in vielen Fällen keine Fehlermeldung mehr an Roblets® nötig. |
| Randbedingung | Ursache | Lösung | ||
| kurzfristig | mittelfristig | langfristig | ||
| "Invalid class version" - neue Klassenversionen laufen nicht unter alten JDK's |
Kompiliert man eine Anwendung mit seinen Roblets® z.B. mit einem
JDK 1.6, hat aber Roblet®-Server z.B. mit einem
JDK 1.5 laufen, so weist der Server die Roblets® mit dem Hinweis
auf "Invalid class version" (o.ä.) zurück.
Das liegt ganz einfach daran, daß eine JVM 1.5 keine Klassen neuerer
Version, wie sie vom Compiler 1.6 erzeugt werden, versteht. Das hat prinzipiell nichts mit der Roblet®-Technik zu tun - das Problem tritt hier jedoch, wie auch z.B. bei RMI, Servlets etc., zutage, da Server oft meist schon (lange) auf einem Rechner laufen, während die Entwicklung von Roblet®-Anwendungen auf "schicken" neuen Rechnern mit neuesten JDK's vorgenommen wird. |
Variante A: Sicherstellen, daß alle Server mit der jeweils neuesten Java-Version laufen. Sind die Roblets® z.B. mit einem älteren JDK kompiliert, so kann der Server die Klassen trotzdem verarbeiten (es geht nur nicht anders herum). |
Die Lösung muß durch die Entwickler des JDK bzw. der JVM kommen. | |
|
Variante B: Alle Roblet® der Anwendungen müssen in der niedrigsten Klassenversion erzeugt werden, die noch von allen Roblet®-Servern eines System verarbeitet werden kann. Zu beachten ist, daß nicht nur die Klassen der Roblets®, sondern auch alle von den Roblets® benutzten in der niedrigsten Klassenversion vorliegen müssen. Der Compiler hat dazu entsprechend instruiert zu werden. Das geschieht durch die Parameter -source und noch wichtiger -target. Beispiel: -source 1.5 -target 1.5 Dabei muß -source immer kleiner (älter) oder gleich -target sein. -source gibt an, was der Compiler an Quellen zu erwarten hat; -target gibt letztlich an, was der Compiler als Klassenversion zu erzeugen hat. |
||||
