5.1 Schwierigkeiten bei der Entwicklung:

BOA vs. POA

Einige Probleme bereitete die Implementierung der automatischen Benachrichtigung der Applets bei CORBA-Events durch den ASManagementAgenten. Wie in Kapitel 3.3 bereits beschrieben, erfolgt die Kommunikation zwischen Applets und dem ASManagementAgenten über die CORBA Kommunikationsmechanismen. Applets definieren eigene PushConsumer -Objekte, die sie beim Start dem zugehörigen ASManagementAgenten übergeben, welcher anschließend eingehende Events an diese Objekte (und damit an die Applets) weitergibt. Die PushConsumer -Instanzen der Applets ,,leben`` jedoch weiterhin bei den Applets selbst. Damit der ASManagementAgent die push(...) -Methoden der Applet-PushConsumer überhaupt aufrufen kann, muß das Applet daher als CORBA-Objekt-Server agieren, d.h. den PushConsumer über den Object Adapter instanziieren und beim ORB (Object Request Broker ) registrieren. Erst dann kann eine Methode dieses Objekts außerhalb des Applets, in diesem Fall vom ASManagementAgenten, benutzt werden.
Leider treten dabei mit dem verwendeten ORB VisiBroker 3.0 Probleme auf, wenn dazu der CORBA 2.0 konforme Basic Object Adapter (BOA) verwendet werden soll. Aufgrund der Unterspezifikation des BOAs in der Version 2.0 von CORBA ergänzen viele ORB-Hersteller ihre Produkte um proprietäre Lösungen, um diese Spezifikationslücken zu schließen. Im Falle von VisiBroker 3.0 wird zwingend eine installierte und konfigurierte Version des Gatekeeper , einer proprietären IIOP Firewall von Inprise/Visigenic, vorausgesetzt, bevor ein Applet mit Hilfe des BOAs ein Objekt verfügbar machen kann. Dies ist jedoch unerwünscht.
Glücklicherweise unterstützt VisiBroker 3.0 jedoch bereits den (ausführlicher spezifizierten) Portable Object Adapter (POA) der CORBA 3.0 Spezifikation, welcher den Einsatz des Gatekeepers unnötig macht. Die Registrierung der PushConsumer beim ORB durch die Applets erfolgt daher durch eine Instanz des POA.