Das SOM Interface Repository Framework

Das Interface Repository ist eine Datenbank, in der die IDL-Definitionen der Objektklassen gespeichert werden können. CORBA 1.2 nennt u.a. folgende Gründe für das Anlegen einer solchen Datenbank (vgl. [OMG 93] S. 128):

• Der ORB braucht die IDL-Definitionen für die Interpretation von Methodenaufrufen. Insbesondere um:
  • Parameter zu überprüfen,
  • die Korrektheit von Vererbungshierarchien sicherzustellen,
  • die Interoperabilität zwischen ORBs zu unterstützen.
• Außerdem kann das Interface Repository von Clients für verschiedene andere Aufgaben eingesetzt werden. Beispielsweise um:
  • Komponenten für eine CASE-Umgebung bereitzustellen (z.B. Interface Browser),
  • aus den Schnittstellendefinitionen Language Bindings zu erzeugen (z.B. IDL-Compiler)
• Desweiteren spielt das Interface Repository eine wichtige Rolle beim Dynamic Invocation Interface.

Die IDL-Definitionen der Klassen werden durch den SOM-Compiler im Interface Repository registriert. Das Interface Repository selbst ist in Form von ,,flat files`` realisiert, die in der Umgebungsvariable SOMIR angegeben werden. Diese Dateien ergeben zusammen eine logische Datenbank. Durch entsprechendes Setzen der SOMIR-Variable kann man erreichen, daß unterschiedliche Anwendungen ihr eigenes separates Interface Repository verwenden oder verschiedene Sichten auf die Daten innerhalb eines Interface Repositories haben.

Der Zugriff auf eine Information im Interface Repository erfolgt über die Methoden der Objektklassen des Interface Repository Frameworks.

 

Abbildung 2.7: Die Containment-Beziehungen im Interface Repository

Die Klassen des Interface Repository Frameworks entsprechen im wesentlichen den Bestandteilen einer IDL-Quelldatei:

1.

Contained. Alle Objekte, die im Interface Repository enthalten sind, müssen von dieser Klasse abgeleitet sein. Die Klasse hat folgende Methoden:

• describe liefert die IDL-Spezifikation der (von Contained abgeleiteten) Klasse
• within liefert alle Container-Objekte, in denen das Objekt enthalten ist

2.

Container. Alle Objekte im Interface Repository, die andere Objekte enthalten, müssen von dieser Klasse abgeleitet sein. Die Klasse hat die Methoden:

• contents liefert den ,,Inhalt`` (d.h. die enthaltenen Objekte) des Containers
• describe_contents beschreibt den Inhalt des Containers (die entsprechenden IDL-Definitionen)
• lookup_name lokalisiert ein bestimmtes Interface-Repository-Objekt anhand seines Namens

3.

ModuleDef. Eine Instanz dieser Klasse existiert für jedes Modul, das in einer IDL-Datei definiert ist. Ein Modul ist ein eindeutiger Namensraum für IDL-Konstrukte.

4.

InterfaceDef. Eine InterfaceDef-Instanz existiert für jede SOM-Klasse.

5.

AttributeDef. Eine Instanz dieser Klasse existiert für jedes Attribut einer Klasse.

6.

OperationDef. Jede Methode einer Klasse wird durch ein OperationDef-Objekt repräsentiert.

7.

ParameterDef. Diese Objekte geben Auskunft über die Parameter von Methodenaufrufen.

8.

TypeDef. Eine Instanz dieser Klasse existiert für jede typedef, struct, union und enum Datenstruktur in einer IDL-Datei.

9.

ConstantDef-Objekte repräsentieren die in IDL-Deklarationen enthaltenen Konstanten.

10.

Exception. Ein Objekt existiert für jede definierte Ausnahme, die bei einem Methodenaufruf auftreten kann.

11.

Repository. Eine Instanz dieser Klasse repräsentiert das gesamte Interface Repository.

Die Klassendefinition (in IDL) aller beim ORB registrierten Objekte muß im Interface Repository gespeichert sein, weil der ORB diese Information zur Laufzeit benötigt.

Die Information im Interface Repository ist jedoch nicht nur dem ORB selbst zugänglich, sondern (über die beschriebene Schnittstelle) jeder SOM-Anwendung.

Speziell für Managementanwendungen ist es wichtig, die Definition der Aufrufschnittstellen von Managementobjekten zur Laufzeit ermitteln zu können (z.B. für dynamische Methodenaufrufe). Das Interface Repository kann deshalb für CORBA-basierte Managementanwendungen die gleiche Rolle spielen, wie die häufig von OSI-Plattformen zur Verfügung gestellten Metadata-Repositories, die GDMO-Definitionen für Anwendungen zugänglich machen (vgl. [IBM 95c], [HP]).