Mechanismen für den dynamischen Methodenaufruf

Die Notwendigkeit, einen Methodenaufruf dynamisch zu gestalten, ist in vielen Szenarien denkbar. Konkret könnte man sich etwa ein Programm vorstellen, mit dem sich die einzelnen Methoden einer Serverimplementation interaktiv anzeigen lassen, und dann diese durch Aufruf antesten. Ein solches Programm würde ein leistungsfähiges Debug-Werkzeug darstellen. Ein erster Schritt zu einem solchen Tool soll im praktischen Teil meiner Arbeit durch das Itool aufgezeigt werden.
An diesem Beispiel wird jedoch schon klar, wie ein solches Programm arbeiten würde und welche Mechanismen die Corba-Implementation bereitstellen muß:

• Es muß zunächst eine Institution geben, die über die vorhandenen Server informiert und auf Anfrage eine Objektinstanz zurückgibt.

• Hat man nun eine Referenz auf einen Server, so benötigt man in der Regel Informationen über die von diesem Objekt bereitgestellten Methoden. Da dabei auch die notwendigen Typ- und Modulinformationen benötigt werden, ist es sinnvoll, die Daten aller bereitgestellten Schnittstellen in einer zentralen ``Auskunftsstelle'' zu sammeln. Diese müßte damit alles an Informationen anbieten, was sich im statischen Fall in den einzelnen IDL-Dateien der Objekte befindet.

• Es muß nun schließlich möglich sein, aus den Informationen der Auskunftsstelle einen gültigen Methodenaufruf zu konstruieren und die dazugehörigen Rückgabeparameter auszulesen.

 

Abbildung 3: Dynamischer Methodenaufruf in Corba: An die Stelle des Stubs treten das IR und das DII

Tatsächlich werden die beiden Punkte von verschiedenen Einrichtungen in der Corba-Installation übernommen: Der Naming Service ordnet dem Servernamen ein konkretes Objekt zu, das Interface Repository fungiert als Schnittstellendatenbank und das Dynamic Invocation Interface sorgt schließlich für die Abarbeitung dynamischer Funktionsaufrufe bei einem vorgegebenen Objekt. Wir wollen diese drei Einrichtungen nun genauer betrachten.