Client und Server enthalten nach der Corba-Spezifikation je ein durch den
IDL-Compiler generiertes Stück Programmcode als Aufsatz: Der IDL-Stub für den
Client und der IDL-Skeleton für den Server.
Die Aufgabe des Stubs und des Skeletons besteht nun darin, die im abstrakten
IDL-Code beschriebene Schnittstelle in die jeweils verwendete
Programmiersprache umzusetzen.
In einer C++-Implementation würde dies zum Beispiel bedeuten, daß eine Datei
hello_world.idl durch den IDL-Compiler in hello_worldC.cc (den
Client-Stub) und hello_worldS.cc (den Server-Skeleton) sowie eine
gemeinsam verwendete Headerdatei hello_world.hh erzeugt wird (Abb.2).
Diese Dateien werden dann auf Client- und Serverseite in den Programmcode
eingebunden.
In der laufenden verteilten Anwendung ist es nun Aufgabe des Stubs und
des Skeletons, über Kommunikation mit dem ORB den entfernten in einen lokalen
Methodenaufruf umzuwandeln. Das bedeutet konkret, daß der Stub
dem Client alle Methoden der Serverimplementation anbietet, weshalb man ihn
auch als Proxy bezeichnet.
Durch die Definition der Schnittstelle in IDL und die Bereitstellung der aus
ihr generierten Programmcodestücke wird damit erreicht, daß sich die
Programmierung von Client und Server völlig unabhängig voneinander gestalten
läßt. Man könnte also nach der Festlegung der Schnittstelle die Implementation
der beiden Seiten verschiedenen Entwicklerteams zuweisen.
Von der Clientseite her ergibt sich damit allerdings folgender Nachteil: Der Client muß von Beginn an ``wissen'', welche Methoden die Serverimplementation bereitstellt, die Aufrufe können also nur statisch ausgeführt werden. Aus diesem Grund wurden der Corba-Spezifikation Mechanismen zur Unterstützung dynamischer Aufrufe beigefügt. Diese sind im wesentlichen das Interface Repository (IR) und das Dynamic Invocation Interface (DII).
