next up previous contents
Next: 6.5.3 Erweiterung des Object Up: 6.5 Implementierung der Komponenten Previous: 6.5.1 Schnittstelle zur Datenbank

6.5.2 Erweiterung des Server-Objekts

Um alle existierenden Objektinstanzen ermitteln zu können, wurde eine Subklasse von SOMDServer entwickelt, die u.a. folgende Funktionalität bietet:

Als Grundlage für diese Server-Klasse diente der in [IBM 95a] entwickelte ITSCSOMDServer. Diese Klasse ist von SOMDServer abgeleitet und hat zusätzliche Methoden, um alle in dem Server vorhandenen Klassenobjekte und Objektinstanzen abfragen zu können:

interface ITSCSOMDServer : SOMDServer
{
  exception ITSCSERV_ERR {long errCode; char Reason[80];};
  long GetAllRegisterClasses( out sequence<string> clsList) 
                                              raises (ITSCSERV_ERR);

  long GetAllUserClasses( out sequence<string> clsList) 
                                        raises (ITSCSERV_ERR);

  long GetAllAffinityGroup(in string class_name,
               out sequence<string> clsList) raises (ITSCSERV_ERR);

  long GetClassStatus(in string class_name) raises (ITSCSERV_ERR);

  long GetClassTree(in string class_name,
               out sequence<string> clsList) raises (ITSCSERV_ERR);

  long GetInstancesForClass (in string class_name,
               out sequence<RefStruct::refData> clsList)
               raises (ITSCSERV_ERR);

  long GetClassAncestors (in string class_name,
               out sequence<string> clsList) raises (ITSCSERV_ERR);

  void verifyList(in RefLinkList refLList);

  sequence<RefStruct::refData> GetRefData();

/*additional methods*/
  sequence<RefStruct::refData> GetProxyData();

  void AddProxyToList(in string ref, in string class);

  void DeleteProxyFromList(in string ref, in string class);

  void object_created(in string server,
                      in string objref,
                      in string class);

  void object_deleted(in string objref, in string class);
}
Die Implementierung dieser Methoden ist in [IBM 95a S.71ff.] beschrieben. Die Klasse wurde um folgende Methoden erweitert:

Um Objekte (keine Proxies) bei ihrer Erzeugung automatisch zu registrieren, wurde die Methode somdRefFromSOMObj des SOMDServer überschrieben. Diese Methode wird vom Object Adapter (SOMOA) jedesmal aufgerufen, wenn in dem Serverprozeß ein neues Objekt erzeugt wird (z.B. durch somdCreateObject). Sie erzeugt eine Referenz für das neue Objekt und registriert es beim ORB. Die überschriebene Methode ruft zunächst die entsprechende Parent-Methode auf, trägt die Referenz des neuen Objekts dann in die dafür bestimmte Liste des Server-Objekts ein und erzeugt eine Ereignismeldung. Alternativ zu somdRefFromSOMObj hätte auch die Methode somdCreateObject überschrieben werden können. Allerdings ist somdRefFromSOMObj ,,allgemeingültiger`` weil damit auch Objekte registriert werden können, die z.B. über spezielle Metaklassen erzeugt werden.

Die Zerstörung von Objekten wird durch Überschreiben der Methode somdDeleteObject automatisch protokolliert, wobei der entsprechende Eintrag in der Liste gelöscht wird und ebenfalls eine Ereignismeldung verschickt wird.

Die Ereignismeldungen werden, wie in Kapitel 5 beschrieben, an das Event_Dispatcher-Objekt geschickt und von diesem an die der Plattform ,,vorgeschalteten`` Consumer-Objekte weitergeleitet.

Das Registrieren der Erzeugung und Zerstörung von Proxy-Objekten ist komplizierter, weil Proxy-Objekte innerhalb eines Serverprozesses auf unterschiedliche Arten erzeugt werden können:

Die eigentliche Konstruktion von Proxy-Objekten geschieht durch interne SOM-Funktionsaufrufe, die nicht für den Anwendungsprogrammierer zugänglich sind. Man kann also nicht durch Überschreiben von bestimmten Methoden erreichen, daß die Erzeugung bzw. Zerstörung von Proxies automatisch registriert wird.

Eine Lösungsmöglichkeit besteht darin, benutzerdefinerte Proxy-Klassen zu entwickeln, deren Instanzen sich bei ihrer Erzeugung automatisch beim Server-Objekt registrieren. Dies stellt aber einen Mehraufwand bei der Anwendungsentwicklung dar, weil nicht nur die Anwendungsklassen selbst implementiert werden müssen, sondern auch die Proxy-Klassen. Da die Implementierung von Proxy-Klassen jedoch grundsätzlich nach einem bestimmten Muster erfolgt (vgl. [IBM 94b S.66f]) könnte man sie auch durch ein entsprechendes Werkzeug automatisch generieren lassen.

Bei der Implementierung des Prototypen wurden Methoden des SOMDObjectMgr überschrieben, um Proxies zu registrieren, die mit diesen Methoden erzeugt bzw. gelöscht werden.


next up previous contents
Next: 6.5.3 Erweiterung des Object Up: 6.5 Implementierung der Komponenten Previous: 6.5.1 Schnittstelle zur Datenbank
Copyright Munich Network Management Team