Soll ein CORBA-Programm als Java-Applet in einem Browser ausgeführt werden, gelten natürlich die gleichen (Sicherheits-)Einschränkungen wie für jedes andere Applet auch:
TCP-Verbindungen dürfen nur zu dem Host aufgebaut werden, von wo das Applet geladen wurde.
Eingehende TCP-Verbindungen dürfen auch nur von dem Host akzeptiert werden, von dem das Applet geladen wurde.
Diese oben aufgeführten Einschränkungen können natürlich umgangen werden, indem das Applet signiert wird und ihm dann mehr Rechte zugewiesen werden. Diese Lösung ist aber einerseits recht aufwending, andererseits Browser-abhängig und evtl. sogar mit Kosten für ein gültiges Zertifikat verbunden.
Sollen Applets über das Internet kommunizieren, kann zusätzlich auch noch eine Firewall ein Hindernis darstellen. Meistens erlauben solche Firewalls keine von einem Server ausgehende Verbindungen zu einem Browser. Aufgrund des verwendeted IIOP-Protokolls ist es unter CORBA nicht möglich, auf einer Verbindung, die von einem Applet zu einem Server aufgebaut wird, Requests vom Server an das Applet zu übertragen - Requests werden über eine Verbindung immer nur in eine Richtung übertragen. Dies versucht die Firewall-Spezifikation (siehe [20]) zu lösen, indem sie das GIOP-Protokoll bidirektional erweitert und Callbacks während eines Methodenaufrufs über diese Verbindung zuläßt.
Ich möchte hier nur einen ganz kurzen Überblick über das Signieren eines Applets bringen, genaueres findet sich zB in [30].
Um ein Applet signieren zu können, muss es erstmal in ein Java-Archiv verpackt werden (und zwar der gesamte Code, dh auch der ORB-Teil). Danach ist ein Object-Signing Zertifikat erforderlich -- zum Testen kann eines mit signtool erstellt werden. Mit diesem Zertifikat kann nun ein Verzeichnisbaum signiert werden:
signtool -G"nickname" signtool -k"nickname" dir |
Eine Alternative zum Signieren des Applets stellt der Appligator vom JacORB (seit der Version 1.0Beta13 verfügbar) dar, der praktisch einen am Web-Server installierten CORBA-Proxy implmentiert. Dadurch kann das Applet über diesen Proxy-Server praktisch zu jedem beliebigen Host eine IIOP-Verbindung aufbauen.
Seit der Version 4.0 wird der Netscape Navigator bereits mit CORBA-Unterstützung ausgeliefert. Ursprünglich natürlich von Netscape groß beworben, so ist es in letzter Zeit doch relativ ruhig um die CORBA-Unterstützung im Navigator geworden.
Auf den ersten Blick scheint es zwar eine gute Idee zu sein, die CORBA-Implementierung direkt mit dem Browser auszuliefern -- so kann ein Java-Applet auf die CORBA-Klassen im Browser zurückgreifen und der Surfer erspart sich dadurch einiges an Download-Zeit. Aber mittlerweile scheint die im Navigator integrierte CORBA-Implementierung schon mehr Probleme zu verursachen als sie löst. Da CORBA ein offener Standard ist, gibt es natürlich nicht nur eine einzige Implementierung, sondern mehrere. Ein Entwickler kann sich nun entscheiden, die im Navigator integrierte Implementierung zu verwenden, oder aber eine andere Implementierung seiner Wahl zu verwenden.
Entscheidet man sich für die im Navigator integrierte Implementierung (eine ältere Version von VisiBroker für Java), gilt es erstmal das Problem zu lösen, dass es dafür keinerlei öffentlich zugängliche Dokumentation gibt -- außer man besitzt die entsprechende Server-Software von Visigenic oder Netscape. Weiters braucht man noch einen IDL Compiler für Java, der ebenfalls nicht inkludiert ist. Hier kann man sich mit einem IDL Compiler einer anderen CORBA-Implementierung behelfen, da zum Glück der erzeugte Java-Code auch standardisiert ist.
Will man allerdings eine andere CORBA-Implementierung verwenden, muss man den Navigator überzeugen, dass er auch die entsprechenden Class-Files verwendet. Die Applet-Parameter ORBClass und ORBSingletonClass helfen hier zwar etwas, aber scheinbar hat sich auch am Interface der org.omg Klassen einiges geändert, sodass die sicherste Möglichkeit ist, die Datei iiop10.jar im Netscape-Verzeichnis einfach zu löschen bzw. umzubenennen.