DSOM Version 2.1 ist ein CORBA1.1-konformer Object Request Broker. Dieser Abschnitt behandelt, wie die Bestandteile der CORBA-Spezifikation bei DSOM implementiert wurden.
- Objektreferenzen:
Ein beim ORB registriertes Objekt wird durch seine Objektreferenz identifiziert. Bei DSOM kann eine Objektreferenz verschiedene Formate haben, die jedoch alle das gleiche Objekt kennzeichnen:
- Eine Instanz der Klasse SOMDObject, die die Lokalisierungsinformation des Objekts beinhaltet.
- Ein Binärformat zum ,,transportieren`` der Objektreferenz (z.B. als Parameter von Methodenaufrufen).
- Eine String-Form, um die Objektreferenz z.B. in einer Datei speichern zu können.
- Ein Proxy-Objekt, auf dem Clients Methoden aufrufen können.
Abbildung 2.6:
Erzeugen einer Proxy Klasse
 |
Damit ein Client Methoden auf einem Zielobjekt aufrufen kann, muß er Zugriff auf ein entsprechendes Proxy-Objekt haben. Clients erhalten Proxy-Objekte als Rückgabeparameter von diversen Methodenaufrufen. Das eigentliche Erzeugen der Proxies im Adressraum des Clients erfolgt automatisch zur Laufzeit (vgl. auch Kapitel 6). Dazu muß zunächst eine Proxy-Klasse generiert werden. Dies geschieht mittels Multiple Inheritance von der Klasse SOMDClientProxy und der Klasse des Zielobjekts. Das Erzeugen einer Proxy-Klasse ist in Abbildung 2.6 dargestellt.
Bei der Proxy-Klasse wird jede von der Klasse des Zielobjekts geerbte Methode automatisch so überschrieben, daß ein Aufruf zu dem entfernten Zielobjekt weitergeleitet wird. Dadurch werden Methodenaufrufe, die der Client auf seinem lokalen Proxy-Objekt macht, in Wirklichkeit von dem Zielobjekt auf dem Server ausgeführt.
Zur Eindeutigkeit von Objektreferenzen ist zu sagen, daß zwischen Objekten und Referenzen eine 1:n Beziehung vorliegt. Das heißt, eine Referenz zeigt zwar immer auf genau ein Objekt, ein Objekt kann aber durch mehrere Referenzen repräsentiert werden. Es ist z.B. denkbar, daß zwei unterschiedliche Objektreferenz-Strings auf das gleiche SOM-Objekt zeigen (zur String-Form von Objektreferenzen vgl. auch Kapitel 6).
DSOM Version 2.1 ist nicht CORBA2.0-konform und ist daher nicht mit anderen CORBA-Implementierungen interoperabel. Dies bedeutet, daß DSOM-Objektreferenzen nicht von den ORBs anderer Hersteller interpretiert werden können.
- Interface Definition Language (IDL):
Die SOM-IDL umfaßt den Sprachumfang der CORBA-IDL. Die IDL-Definition eines Objekts (Interface Declaration) besteht aus folgenden Bestandteilen:
- Datentypen. Es können sowohl die Basis-IDL-Typen (string, short, long, unsigned short, unsigned long, float, double, char, boolean, octet und any) als auch zusammengesetzte Datentypen verwendet werden.
- Operationen. Definitionen von Methoden, deren Parameter zusätzlich zu ihrem Typ die Kennzeichnung in, out oder inout haben.
- Attributes sind die nach außen zugänglichen Instanzvariablen der Objektklasse.
- Exceptions sind Datenstrukturen, die bei ,,Ausnahmefällen`` innerhalb von Methodenaufrufen an den Aufrufer zurückgegeben werden.
Man kann jedoch in einer sogenannten Implementation Section der IDL-Datei zusätzliche Information mit angeben, die mit der CORBA-IDL nicht spezifiziert werden kann. Beispiele dafür sind:
- Private Instanzvariablen, die zwar von den Methoden einer Klasse verwendet werden können, auf die Clients jedoch keinen direkten Zugriff haben und die somit eigentlich nicht Bestandteil der Schnittstelle der Klasse sind.
- Passthru statements, mit denen veranlaßt werden kann, daß Anweisungen wie z.B. #include oder typedef-Statements in die erzeugten Templates oder Header-Dateien eingefügt werden. Ein Anwendungsbeispiel ist das Einfügen von Typdefinitionen, die nicht in IDL-Format vorliegen, in die Implementierungstemplates.
- Sogenannte Modifiers wie der Name der DLL, die die Klasse
enthält, den Namen der Metaklasse der Klasse oder die Kennzeichnung
von ererbten Methoden, die überschrieben werden. Der Name der DLL
muß deshalb in der IDL-Datei (und somit im Interface Repository) angegeben werden, damit von der SOM-Laufzeitumgebung die DLL bei Bedarf (z.B. bei einem Request zum Erzeugen eines Objekts in einem Serverprozeß) geladen werden kann.
- Ein wichtiger Bestandteil einer SOM-IDL Definition ist die Releaseorder der Methoden einer Klasse. Durch sie wird die Reihenfolge der Methoden in den vom Compiler erzeugten Datenstrukturen festgelegt. Durch eine konsistente Releaseorder kann erreicht werden, daß die Implementierung einer Klasse sich ändern kann, ohne daß die Client-Programme neu compiliert werden müssen.
In CORBA 1.1 wird nur eine Sprachabbildung zwischen IDL und C definiert. SOMObjects unterstützt diese Abbildung, hat aber zusätzlich ein Language Mapping für C++.
- Client-Aufrufschnittstellen:
DSOM unterstützt sowohl die statische als auch die dynamische Aufrufschnittstelle.
Die statische Aufrufschnittstelle wird mit den durch den SOM-Compiler erzeugten Client-Stubs realisiert. DSOM ermöglicht jedoch auch dynamische Methodenaufrufe, die von Clients zur Laufzeit konstruiert und abgesetzt werden können (Dynamic Invocation Interface). Dadurch können Anwendungen Methoden auf Objekten aufrufen, ohne daß bei der Übersetzung ein Client-Stub für die Objektklasse dazugebunden wurde. Ein dynamischer Methodenaufruf besteht aus der Objektreferenz des Zielobjekts, der Methode, die aufgerufen werden soll, und den Parametern für den Methodenaufruf.
Dynamische Methodenaufrufe müssen explizit konstruiert werden, indem die Parameter für den Aufruf in eine speziell dafür vorgesehene Datenstruktur, die sogenannte NVList (Named Value List) eingetragen werden. Als Quelle für die Beschreibung der Methoden und ihrer Parameter dient das Interface Repository.
Dynamische Methodenaufrufe können entweder synchron (mit invoke) oder asynchron (mit send) ausgeführt werden.
- ORB-Schnittstelle:
DSOM implementiert die ORB-Schnittstelle. Über sie erfolgt die Umwandlung zwischen Objektreferenzen und Strings. Außerdem dient sie zum Erzeugen von NVLists im Zusammenhang mit dem Dynamic Invocation Interface.
- Server:
CORBA definiert vier Alternativen für die Zuordnung von Objekten zu Serverprogrammen:
- 1.
- Ein Shared Server beinhaltet mehrere Objekte.
- 2.
- Ein Unshared Server ist lediglich für ein einziges Objekt zuständig.
- 3.
- Ein Server per Method erzeugt für jeden Methodenaufruf einen eigenen Prozeß.
- 4.
- Ein Persistent Server wird im Gegensatz zu den anderen drei Möglichkeiten nicht automatisch aktiviert, wenn ein Methodenaufruf für ihn eintrifft, sondern muß explizit durch ein entsprechendes Kommando gestartet werden.
DSOM startet ein Serverprogramm, wenn ein Client eine Verbindung zu dem entsprechenden Server aufnehmen will. Dabei kann der Anwendungsprogrammierer jeden der vier CORBA-Aktivierungsmechanismen implementieren (vgl. [IBM 94f] S. 6 - 69).
DSOM stellt ein generisches Serverprogramm (somdsrv) zur Verfügung. Dieses registriert sich automatisch bei der DSOM-Laufzeitumgebung, wenn es gestartet wird.
Im Implementation Repository werden alle Server und die von ihnen unterstützten Objektklassen registriert. Dazu kann entweder ein Kommando (regimpl) oder eine Programmierschnittstelle verwendet werden. Dadurch kann der ORB die durch die Server implementierten Objekte lokalisieren,(de-)aktivieren und Methodenaufrufe an sie weiterleiten. Der Aufbau des Implementation Repository wird in Kapitel 6 näher beschrieben.
- Object Adapter:
Der Object Adapter ist die Schnittstelle zwischen den Servern und dem ORB. DSOM hat den Basic Object Adapter (BOA) aus der CORBA-Spezifikation implementiert. Allerdings existiert dieser nur als abstrakte Klassendefinition und kann nicht instanziiert werden. Eine Unterklasse des BOA ist der SOM Object Adapter (SOMOA). Dieser stellt neben der Möglichkeit, Server und ihre Objekte beim ORB zu registrieren (durch Erzeugen von Objektreferenzen), zusätzliche SOM-spezifische Funktionalität bereit, um Methodenaufrufe an Zielobjekte zu vermitteln. Der SOMOA ruft dabei für jeden Request die Methode somdDispatchMethod des SOMDServers auf, die den Methodenaufruf an das eigentliche Zielobjekt weiterleitet. Durch Überschreiben der Methode somdDispatchMethod kann anwendungsspezifische Funktionalität in die Verarbeitung von Requests integriert werden (s. auch Kapitel 5).
