Semantische Nachbesserungen bei der Generierung von IDL-Schnittstellen

 

Die IDL-Klassenbeschreibung gibt die Beziehungen zwischen Objektklassen zwar korrekt wieder; allerdings erscheinen letztere nur indirekt als Attribute der betroffenen Objektklassen. Dies ist ein charakteristisches Beispiel für den mangelnden Reifegrad gegenwärtiger ORB-Implementierungen, da zur Zeit neue (Hilfs-) Methodenschnittstellen eingefügt werden müssen, die die Gültigkeit der Beziehungen periodisch überwachen. So überprüft beispielsweise die Methode der System-Objektklasse update_Processes(), welche Prozesse momentan aktiv sind. Für die Methoden, die ausschließlich der Verwaltung von Beziehungen zwischen Objektklassen dienen, müssen daher neue Methoden entworfen und implementiert werden. Dieses Problem resultiert aus der Tatsache, daß der CORBA Relationship Service [#!sspec97!#] zwar spezifiziert wurde, aber noch nicht Bestandteil der CORBA-Entwicklungssysteme ist. Ist dies jedoch in zukünftigen Versionen von ORB-Implementierungen der Fall, bedeutet dies eine signifikante Einsparung an Implementierungsaufwand, weil man sich dann vollständig auf bestehende generische Dienste (wie eben den Relationship Service) abstützen kann. Für das Design des Objektmodells bedeutet dies, daß die von der OMG in maschinenlesbarer Form erhältlichen IDL-Schnittstellenbeschreibungen der CORBAservices bereits zu Beginn der Modellierung mit Hilfe der Reengineering-Komponente in OMT überführt werden können und so als generische Objektklassen bereitstehen. Letztere müssen im Falle von Beziehungen lediglich mit konkreten Belegungen spezialisiert werden, um anschließend in IDL ausgegeben zu werden. Die so erzeugten CORBA-Managementobjektklassen machen dann von den bereits bestehenden Diensten Gebrauch.

Die Problematik der Abbildbarkeit von Beziehungen  hat aufgezeigt, daß der mit der Umwandlung eines leistungsfähigen OMT-Modells in verhältnismäßig ,,ausdrucksschwache`` IDL-Schnittstellenbeschreibungen einhergehende Verlust an Semantik durch die geschickte Abstützung auf CORBAservices zu großen Teilen kompensiert werden kann. Langfristig ist es daher keinesfalls nutzlos, hohen Aufwand in die Entwicklung eines reichhaltigen Objektmodells zu stecken, selbst wenn man durch die mittelfristigen Unzulänglichkeiten gegenwärtiger ORB-Implementierungen momentan lediglich einen geringen Anteil der im Objektmodell enthaltenen Semantik erhalten werden kann. Ist ein reichhaltiger Dienstumfang vorhanden, bietet sich die Verwendung des OMT-Nachfolgers Unified Modeling Language (UML)  an, welche einige Erweiterungen diesbezüglich bereitstellt. In unserem Fall erschien jedoch angesichts der Tatsache, daß bereits der OMT-Funktionsumfang nur zum Teil genutzt werden konnte, der Mehraufwand von UML nicht gerechtfertigt.

Bezüglich des Erzeugens und Löschens von Objekten bzw. der Objektverwaltung allgemein ergibt sich ein weiteres Problem: Es besteht keine zentrale Komponente (eine sogenannte Object Factory),  über die Objekte einer Klasse erzeugt, gelöscht oder zum Beispiel aufgelistet werden könnten. Eine Lösung für dieses und das obige Problem ist die Einführung von Metaklassen. Zu jeder Klasse existiert damit eine weitere Klasse, von der allerdings nur ein einziges Objekt instantiiert wird und Funktionen bereitstellt, die der Verwaltung von Objekten der Hauptklasse dienen. Da diese Überlegungen rein implementierungsbedingt sind, wird darauf verzichtet, die Metaklassen in das Objektmodell aufzunehmen.

Ein weiteres Beispiel für den Nutzen von Metaklassen wird im Zusammenhang mit der Prozeß-Klasse sichtbar: Generell gilt, daß die CORBA-Managementobjekte beim Systemstart instantiiert werden sollten. Bei statischen Objekten bzw. Objekten, die nur über eine geringe Änderungsdynamik verfügen (wie z.B. Prozessoren, Festplatten) ist dies auch kein Problem. Anders verhält es sich aber mit dynamischen Objekten, wie zum Beispiel Prozessen: Es ist nahezu unmöglich, diese Objekte mit dem realen Systemzustand konsistent zu halten, weil dazu bei jedem Start eines Prozesses ein entsprechendes Prozeßobjekt instantiiert bzw. bei Prozeßterminierung wieder gelöscht werden müßte. Durch den Zugriff auf die Prozeßobjekte über eine sogenannte ,,before/after``-Metaklasse MetaProcess kann dieses Problem gelöst werden. Sobald nun ein Zugriff auf die Metaklasse durchgeführt wird, wird der Bestand an Prozeßobjekten aktualisiert; das anfragende Objekt (in diesem Fall das Managementsystem) erhält also beim Zugriff immer den aktuellen Systemzustand.