5.1.3 Die CORBA-Implementierung DSOM

Distributed SOM (DSOM) ist eine Erweiterung von SOM. Sie erlaubt letztendlich Anwendungen, auf Objekten in verschiedenen Adreßräumen und auf unterschiedlichen Rechnern Operationen aufzurufen. Damit wird die Entwicklung einer verteilten Anwendung mit SOMobjects überhaupt erst ermöglicht. Die wichtigsten Unterschiede zwischen SOMobjects 2.1 und SOMobjects 3.0 betreffen Änderungen/Ergänzungen bezüglich dieses Frameworks.

Eine DSOM-Laufzeitumgebung ist in Abbildung 5.2 dargestellt. Sie besteht mindestens aus vier Komponenten:

• Einem Clientprogramm;
• Einem Serverprogramm, welches Client-Requests bedient. DSOM stellt ein ,,generischen`` Serverprogramm (somdsvr) und einen Server (somossvr), der benutzt werden kann, wenn SOMobject Object Services eingesetzt werden sollen, zur Verfügung. Auch applikationsspezifische Serverprogramme können entwickelt und eingesetzt werden.
• Dem DSOM-Dämonprozeß somdd, der das Serverprogramm startet und die Verbindung zwischen Client und Server herstellt; Der somdd läuft auf demselben Rechner, auf dem auch das Serverprogramm läuft.
• Einem Name Server, mit dessen Hilfe ein Client Objekte (insbesondere Factories) finden kann. Läuft der Name Server auf einem anderen Rechner als das Serverprogramm, so muß auch dort ein somdd gestartet worden sein.

  

Abbildung 5.2: Die DSOM-Laufzeitumgebung

Das Serverprogramm enthält, neben den Objekten der eigentlichen Anwendung, drei Laufzeitobjekte:

• Ein ImplementationDefObjekt, beschreibt das Programm, welches den Server implementiert (Aktivierung, Pfadname, Server-ID). Einerseits identifiziert ein ImplementationDefObject eindeutig einen Server in der DSOM-Laufzeitumgebung, andererseits benötigt das Serverprogramm selbst dieses Objekt, um das Verhalten seines Server Objects (s. u.) beeinflussen zu können. Ein Serverprogramm kann ,,sein`` ImplementationDefObject aus dem Implementation Repository holen.
• Das Server Object ist eine Instanz der Klasse SOMDServer. Es stellt den Clients über seine Schnittstelle Dienste zum Erzeugen und Löschen von Objekten im Serverprozeß zu Verfügung. Der Object Adapter (s. u.) benutzt Methoden des Server Objects, um Objektreferenzen aufzulösen (um Objekte innerhalb des Serverprozesses zu identifizieren). Außerdem kann mit der Methode somdRefFromSOMObj eine Objektreferenz zu einem SOMObject erzeugt und damit dieses Objekt als Zielobjekt für Aufrufe von Clients beim Object Adapter angemeldet werden. Diesen Vorgang nennt man das Exportieren eines Objektes. Das Serverobjekt ist also auch an der Weiterleitung von Methodenaufrufen an Zielobjekte beteiligt.
• Der SOM Object Adapter ist die wichtigste Schnittstelle zwischen dem Serverprogramm und der DSOM-Laufzeitumgebung. Die Klasse des SOM Object Adapter ist von der abstrakten Klasse BOA (Basic Object Adapter, der Standard-CORBA Object Adapter), abgeleitet. Die Hauptaufgabe des Object Adapter ist, Requests zu empfangen, an Zielobjekte weiterzureichen und Responses an die aufrufenden Clients zurückzugeben.

Innerhalb eines Clientprogramms muß ein ORB-Object vorhanden sein. Es handelt sich dabei um eine Instanz der DSOM ORB-Klasse, die die CORBA-konforme ORB-Schnittstelle implementiert. Bei der Initialisierung wird eine solche Instanz automatisch erzeugt. Es stellt dem Client Methoden zur Verfügung stellt, entfernte Objekte zu finden, zu erzeugen, zu löschen. Insbesondere erhält ein Client mittels des ORBs Objektreferenzen auf Objekte, welche Basisdienste anbieten (Interface Repository, Name Service). Außerdem bietet es Methoden an, die für die dynamische Aufrufschnittstelle benötigt werden. Auch im Serverprogramm kann der ORB genutzt werden.