6.3.6 Factories

  Ein Factory-Objekt unterscheidet sich architekturell nicht von einem anderem CORBA-Objekt. Der Unterschied zu gewöhnlichen Objekten liegt ausschließlich in der Semantik. Ein Factory-Objekt stellt Methoden bereit, um dynamisch neue Objekte zu erzeugen. Meist ist ein Factory-Objekt nur für das Erzeugen von Objekten einer bestimmten Klasse zuständig. Beispielsweise wird ein Objekt FilesystemFactory Managementobjekte für Dateisysteme kreieren. Auch zu Beziehungsklassen kann es Factories geben. Das Eingehen einer Beziehung entspricht dem Instantiieren der Beziehungsklasse. Exportiert z.B. ein NFS-Server ein Dateisystem, muß das Factory-Objekt ExportOptionsFactory ein Objekt der Klasse ExportOptions anlegen.

Da das Erzeugen von Objekten vom Mechanismus der entsprechenden Implementierungssprache abhängt, ist die Entwicklung eines generischen Factory-Objekts nicht möglich, das beliebige CORBA-Objekte anlegen kann. Auch der CORBA Lifecycle-Service standardisiert nur das Verschieben, Kopieren und Löschen von Objekten. Neben dem Erzeugen von Objekten und deren Registrierung und Aktivierung beim BOA übernehmen die Factories des Prototypen noch weitere Verwaltungsaufgaben. Aus Performancegründen werden die dynamischen Objekte nur transient registriert, d.h. eine Lokalisierung über den Smart Agent ist nicht möglich. Die Factory verwaltet über ein einfaches Verzeichnis (Hashtable) ,,ihre`` Objekte selbst. Die Funktionen einer Factory werden am Beispiel des Objekts AccountFactory vorgestellt. Dessen IDL-Beschreibung enthält Abbildung 6.16.

  

Abbildung 6.16: IDL-Beschreibung: AccountFactory.idl

62#62

Die Methode create() dient zum Anlegen einer neuen Benutzerkennung. Gleichzeitig wird ein Managementobjekt der Klasse Account erzeugt, im internen Verzeichnis abgelegt und dessen IOR an den Aufrufer zurückgegeben. Durch die Methode open() kann ein Client die IOR eines Account-Objekts über das eindeutige Attribut Name von der Factory erfragen. Eine Liste aller IORs, die die Factory verwaltet, wird von der Methode list() zurückgegeben. Schließlich dient die Methode delete() zum Entfernen einer Kennung aus dem Verzeichnis der Factory. Zusätzlich wird das dynamische Objekt gelöscht, in dem es beim BOA abgemeldet wird. An dieser Stelle muß sorgfältig zwischen dem Löschen der Benutzerkennung auf dem System und dem Löschen des zugehörigen Agentenobjekts unterschieden werden. Ersteres wird erreicht, indem die Managementanwendung die Operation delete() auf dem Agentenobjekt ausführt, das seinerseits das UNIX-Kommando rmuser aufruft. Wenn das Agentenobjekt hierauf versucht, durch die BOA-Methode deactivate_obj() sich selbst zu deaktivieren, erzeugt der ORB eine Ausnahme für die Managementanwendung, auch wenn die Methode delete() das Attribut «oneway» besitzt. Aus diesem Grund muß der Manager anschließend das Agentenobjekt explizit über die Methode delete() der Factory löschen.

Die Implementierung der Klasse AccountFactoryImpl ist im Anhang B zu finden. Die Factory-Objekte werden, wie in Abschnitt 6.3.5 beschrieben, vom Server-Programm SystemAgentServer.java kreiert und als persistente CORBA-Objekte registriert. Der Konstruktor der Factory erzeugt für alle auf dem System bereits bestehenden Benutzerkennungen transiente Agentenobjekte. Die Managementanwendung (siehe 6.4) bindet sich an die Factory, um eine Liste aller IORs für die Account-Objekte zu erhalten. Zum Lesen bzw. Verändern der Attribute einer Kennung greift sie schließlich direkt auf das zugehörige Account-Objekt zu.

Für sehr dynamische Managementobjekte wie Prozesse oder Druckjobs ist es äußerst problematisch, in Echtzeit zugehörige Agentenobjekte bereitzustellen. Ein Polling der Prozeßtabelle in kurzen Abständen durch ein Factory-Objekt würde zu immensen Ressourcenbedarf des Agenten führen, wenn gleichzeitig Agentenobjekte angelegt bzw. gelöscht werden müssen. Eine mögliche Lösung ist das Bereitstellen der Objekte bei Bedarf, d.h. wenn eine Anfrage des Managers vorliegt. Eine andere Möglichkeit ist die Aktualisierung in größeren Abständen. Dabei besteht aber die Gefahr, daß der Manager über ein Agentenobjekt versucht, auf ein bereits nicht mehr existierendes Managementobjekt zuzugreifen.

In den letzten Abschnitten wurde gezeigt, wie CORBA-Agentenobjekte Managementinformation und -funktionalität der Klassen des Objektmodells implementieren können. Im folgenden Abschnitt wird die Abbildung von asynchronen Meldungen auf den CORBA Event-Service dargestellt.