FAQ (Frequently Asked Questions)

Diese Seite listet einige häufig gestellte Fragen mit den zugehörigen Antworten auf.

• Was ist der Unterschied zu OSGi bzw. Gemini?
• Was ist der Unterschied zu Distributed OSGi?
• Was ist der Unterschied zu anderen Kommunikationstechniken?
• Was ist der Unterschied zu RMI?
• Was ist der Unterschied zu Applets und Web-Start?
• Was ist mit Echtzeitfähigkeit?
• Können die Roblets® wirklich keine Unfug machen?
• Was ist mit Verschlüsselung, Authentifizierung etc.?
• Woher kommt der Begriff Roblets®?

Was ist der Unterschied zu OSGi bzw. Gemini?

OSGi steht eher orthogonal zur Roblet®-Technik, d.h. sie können sich gut ergänzen.  OSGi erkennt und verwaltet Komponenten (Bundles) in einer JVM und ermöglicht deren Nutzung durch andere Komponenten.  Die Roblet®-Technik ist eine Kommunikationstechnik, d.h. ermöglicht Datenaustausch und Verarbeitung über mehrere JVM's hinweg.

Was ist der Unterschied zu Distributed OSGi?

Distributed OSGi bietet die Möglichkeit, daß OSGi-Komponenten (Bundles) Funktionalität anderen fernen Komponenten anbieten und selbst die Funktionalität weiterer ferner Komponenten nutzen können.  Dabei können verschiedene Techniken der Netzwerkkommunikation (Remote Services) eingesetzt werden.  Die Roblet®-Technik ist eine Kommunikationstechnik, d.h. kann im Grunde mit all ihren Vorteilen im Rahmen von Distributed OSGi eingesetzt werden.

Was ist der Unterschied zu anderen Kommunikationstechniken?

Im Gegensatz zu normalen Kommunikationstechniken verschickt die Roblet®-Technik instanziierte Programmteile zu sog. Roblet®-Servern, damit sie dort laufen und deren Ressourcen nutzen können.  Damit wird quasi die Parallelität über das Multi-Threading und das Multi-Processoring auf das Multi-Hosting ausgedehnt.  Eine Roblet®-Anwendung mit ihren auf anderen Rechnern laufenden Roblets® kann man in der Praxis als eine einzige Anwendung auffassen.

Die Roblet®-Technik ist auch eine Client-Server-Technik.  Aber im Gegensatz zu normalen Kommunikationstechniken ist die Schnittstelle zwischen Client und Server nicht "in der Wolke", d.h. auf einer gedachten Linie zwischen dem Rechner des Client und dem Rechner des Servers.  Stattdessen ist diese Schnittstelle im Server zwischen den Roblets® und den Ressourcen und wird durch normale Java™-API gebildet und auch so dokumentiert.  Dadurch ist die Arbeit mit diesen Schnittstellen nicht mehr vom Zustand des Netzwerkes abhängig.

Was ist der Unterschied zu RMI?

Die Roblet®-Technik kann in der Praxis als Ersatz von RMI dienen.  Durch die Roblet®-Technik ist der Code-Upload (in Form von Roblets®) extrem vereinfacht und gleichzeitig sind zentrale Sicherheitsrisiken eliminiert.  Die Roblet®-Technik leistet die wesentlichen Dinge von RMI aber mit erheblich weniger Anfangsaufwand und Konfigurationsproblemen.  Die beiden Techniken können aber trotzdem gut parallel eingesetzt werden.

Im Detail gesehen ist RMI noch etwas mächtiger und war auch in der Anfangszeit der Roblet®-Technik die unterliegende Kommunikationstechnik.  Nur Dank RMI konnte sich die Roblet®-Technik so schnell entwickeln.  Jedoch haben verschiedene Praxisprobleme dazu geführt, daß heutzutage direkt via UDP und TCP innerhalb der Roblet®-Technik kommuniziert wird.  Die Probleme waren u.a.:

• Router sind oftmals ein Problem für RMI wegen NAT (network address translation)
• Firewalls sind ein ähnliches Problem
• Daten und Klassen werden in der Roblet®-Technik durch ihre Spezialisierung erheblich effizienter und sicherer im Netz verschoben.
• RMI bietet zwar standardmäßig eine gute Ausstattung hinsichtlich der Zugriffsmöglichkeiten von Code (Sandbox), aber keine vollständige Ablaufumgebung, die ein kontrolliertes Abbrechen von Code ermöglicht.
• RMI verwaltet gewisse Daten nur einmal per JVM, was die Arbeit und zumindest die Fehlersuche in Systemen mit verschiedenen unabhängigen Komponenten (OSGi, Tomcat, große Anwendungen etc.) deutlich erschwert.
• RMI funktioniert in manchen Umgebungen nicht (oder nicht so einfach), wo Sockets aber gehen (und die Roblet®-Technik daher nun auch) - z.B. in Applets.
• Unter RMI bringt allein ein Hello-World-Beispiel mit Code-Verschicken eine Unmenge an Nebenaufwendungen und Konfigurationen hervor und erfordert im Grunde erhebliches Tiefenverständnis.

Was ist der Unterschied zu Applets und Web-Start?

Die Roblet®-Technik arbeitet sehr gut in Applets und in Web-Start-Anwendungen, d.h. man kann sie in beiden Fällen sehr gut zur Kommunikation einsetzen.  Richtig vergleichen kann man die Roblet®-Technik nicht wirklich mit Applets oder Web-Start.  Im folgenden jedoch einige zentrale Unterschiede:

• Bei der Roblet®-Technik findet Code-Push statt im Gegensatz zu Code-Pull.  Roblets® werden zum Server gebracht.  Applets und Web-Start-Anwendungen kommen vom Server.
• Applets sind im wesentlichen auf eine Umgebung wie Browser eingeschränkt.
• In der Roblet®-Technik werden Klassen und Ressource-Dateien nur auf Anfrage bewegt.
• Roblets® sind grundsätzlich Klassen-Instanzen, die zu einem Server transportiert werden und die dann bei Bedarf den Transport von Klassen zur Folge haben.  Web-Start-Anwendungen und Applets sind keine Instanzdaten (bzw. nur eingeschränkt).
• Bei Applets und Web-Start-Anwendungen wird eine HTTP-TCP-Sitzung pro Datei benötigt.  Bei der Roblet®-Technik wird normalerweise nur eine TCP-Verbindung verwendet, was die Übertragung oft stark beschleunigt.

Was ist mit Echtzeitfähigkeit?

Echtzeitfähigkeit, wie sie z.B. in der Robotik an manchen Stellen benötigt wird, erreicht man in der Roblet®-Technik über die Module.  Genauer:  Die Module kümmern sich um diese Fähigkeit.

Dabei wurden in der Praxis bisher erfolgreich zwei Methoden eingesetzt:

1. C++-Bibliotheken mit JNI (Java™ Native Interface) angebunden und
2. Separater Prozeß mit Kommunikation per TCP/IP.

Bei der ersten Variante wird eine echtzeitfähige C++-Bibliothek mit einer (nicht-echtzeitkritischen) JNI-Schnittstelle versehen.  Dadurch kann vom Modul, d.h. aus Java™, auf die C++-Bibliothek zugegriffen werden.  JNI-Aufrufe werden von der JVM nicht unterbrochen.  In der C++-Bibliothek können auch Threads gestartet werden, die dann parallel zu den Threads der JVM laufen und von diesen auch hinsichtlich der Priorität nicht abhängen.  Ein wenige dutzend Zeilen umfassendes Beispiel inkl. Make-Dateien ist auf Anfrage erhältlich.

An der Universität Hamburg ist man den zweiten Weg gegangen.  Dort lag schon eine Roboter-Steuerung (als Linux-Programm) vor, welches eine (nicht-echtzeitkritische) TCP/IP-Schnittstelle besaß.  Das Modul brauchte nur noch auf diese Schnittstelle per (Java™-)TCP-Sockets zugreifen.  Der Prozeß der Roboter-Steuerung wurde im Betriebssystem passend priorisiert, um nicht durch die JVM gestört zu werden.

Können die Roblets® wirklich keine Unfug machen?

Roblets® laufen im Roblet®-Server in je einem eigenen Sicherheitsbereich (security domain).  Die Sicherheitsbereiche sind dabei so konfiguriert, daß ein Roblet® keinerlei Rechte hat.  Das übertrifft an Schärfe sogar die Einstellungen, die ein Applet in einem Browser hat.  Ein Roblet® kann also keine Funktionalität der Java™-Bibliothek (JDK und Erweiterungen) in Anspruch nehmen, die Sicherheitrelevanz haben.  Ein Roblet® kann Ressourcen nur über die Einheiten (Module) in Anspruch nehmen, wobei dabei auch die Rechte geregelt werden.

Will man den Grad an Sicherheit weiter treiben, so haben sich in der Praxis folgende Dinge bewährt:

• Nur stabile Java™-Versionen mit den neuesten Patches einsetzen
• Nur "vertrauenswürdige" Module einsetzen (stabile Versionen, gute Dokumentation, bekannter Hersteller oder einsehbare Quellen etc.)

Wenn man immer noch ein ungutes Gefühl hat (Punkte auch kombinierbar):

• Eigenen Java™-Sicherheits-Manager aktivieren inkl. Nutzung eigener Sicherheitsrichtlinien
• Firewall einsetzen
• Mit eigenen Betriebssystem-Nutzer mit wenigen Rechte laufenlassen
• Unter Unix-artigen Betriebssystemen:
  • chroot einsetzen
  • quota einsetzen

Was ist mit Verschlüsselung, Authentifizierung etc.?

Obwohl diese Punkte noch nicht Teil der Roblet®-Technik sind (Stand Mai 2010), gibt es trotzdem schon sehr gute Möglichkeiten für höchste Verschlüsselung und sichere Authentifizierung.  In der Praxis sind dabei nach unserem Wissen bisher 2 Techniken erfolgreich genutzt worden:

1. Tunnelung per SSH
2. VPN

Mit Hilfe von SSH läßt sich die TCP/IP-Kommunikation tunneln.  Dabei wird z.B. auf dem lokalen Rechner ein SSH-Programm derart konfiguriert gestartet, daß die auf einem bestimmten lokalen TCP-Port eingehenden Daten an ein Port auf einem anderen Rechner weitergeleitet werden und umgekehrt.  Lokal werden die Daten dabei von dem SSH-Client ver-/entschlüsselt und auf dem fernen Rechner macht das der SSH-Server.  Das kann man jetzt noch mit einem Vertreter kombinieren, um den fernen Server lokal in Verzeichnissen sichtbar zu machen.

Liegt eine VPN-Infrastruktur vor, so übernimmt diese die Sicherung der Daten.  Die Roblet®-Technik nimmt dann nicht wahr, daß die Daten verschlüsselt bewegt werden.

Woher kommt der Begriff Roblets®?

Ursprünglich wurde eine Lösung für ein Problem in der mobilen Robotik gesucht.  Erst Jahre später wurde klar, daß die geschaffene Lösung allgemeinerer Natur ist.  Eine Umbenennung wäre zu dem Zeitpunkt schon mit sehr viel Aufwand verbunden gewesen.  Außerdem fehlte die Idee für eine andere Benennung.