next up previous contents
Next: Die Implementierung von CORBA Up: 2.3 IBM's SOMObjects Previous: Die SOM-Laufzeitumgebung

2.3.2 Die CORBA-Implementierung DSOM

DSOM ermöglicht Interprozessaufrufe zwischen SOM-Objekten, die sich auf der gleichen Maschine (Workstation DSOM) oder auf unterschiedlichen Rechnern im Netz befinden (Workgroup DSOM). Die Kommunikation wird über IPC-Mechanismen bzw. LAN-Protokolle (TCP/IP, Netbios und IPX/SPX) realisiert. Durch Ableitung aus der Klasse SOMSockets kann die Gruppe der unterstützten Protokolle erweitert werden.

Abbildung 2.5 zeigt die Basisarchitektur von DSOM.


 
Abbildung 2.5: DSOM - Basisarchitektur
\begin{figure}
\begin{center}
\mbox { \epsffile{bilder/DSOM.eps} }\end{center}\end{figure}

Auf der Serverseite befindet sich der DSOM-Dämonprozeß (somdd). Dieser hat die Aufgabe, Serverprozesse bei Bedarf zu starten und die Verbindungen zwischen Clients und Servern herzustellen.

Die Objekte sind auf Serverprozesse verteilt. Hierzu kann das mitgelieferte Standard-Serverprogramm somdsvr verwendet werden, mit dem SOM-Klassenbibliotheken dynamisch geladen werden können. Es können jedoch auch eigene Serverprogramme mit anwendungsspezifischer Funktionalität eingesetzt werden.

In jedem Serverprozeß gibt es ein Server-Objekt (SOMDServer), das folgende Aufgaben hat:

Der SOM Object Adapter (SOMOA) ist die Schnittstelle zwischen dem Serverprogramm und der DSOM-Laufzeitumgebung. SOMOA nimmt die Aufträge der Clients entgegen und sorgt für ihre Weiterverarbeitung. Dazu gehört das Interpretieren von Objektreferenzen und das Weiterleiten der Methodenaufrufe zu den entsprechenden Zielobjekten.

Die eigentlichen Zielobjekte der Clients befinden sich innerhalb des Serverprogramms. Sie stellen die Methoden zur Verfügung, die von den Clients aufgerufen werden. Die Klassenbibliotheken der Objekte sind in der Regel in Form von Dynamic Linked Libraries (DLLs) auf den Server-Rechnern vorhanden und werden bei Bedarf zu den Serverprogrammen dazugebunden.

Innerhalb eines Client-Programms muß der DSOM Object Manager vorhanden sein. Dieser ist eine Instanz der Klasse SOMDObjectMgr. Der Object Manager wird automatisch beim Initialisieren der DSOM-Laufzeitumgebung erzeugt. Der Object Manager ist notwendig, um

Der Object Manager erbringt zusammen mit dem Server-Objekt die Grundfunktionalität für die Verwaltung der verteilten Anwendungsobjekte. Diese beiden Objekte setzen bei DSOM auf den eigentlichen ORB-Schnittstellen wie dem Object Adapter auf.

Eine weitere zentrale Rolle spielt das Konzept der Proxy-Objekte. Proxy-Objekte sind Stellvertreter für Objekte, die sich eigentlich auf einem Server befinden. Ihre Klassen werden von SOM dynamisch zur Laufzeit generiert. Jede Methode einer Proxy-Klasse wird automatisch so überschrieben, daß ein Aufruf an das entsprechende Objekt auf dem Server weitergeleitet wird. Clients brauchen Proxies sowohl für die eigentlichen Zielobjekte, als auch für das Server-Objekt, um z.B. neue Objektinstanzen zu erzeugen. Ein Proxy-Objekt entspricht einer Objektreferenz auf das Zielobjekt des Proxies.

In Entsprechung zum CORBA-Standard hat DSOM außerdem ein Interface Repository, in dem die IDL-Definitionen sämtlicher Objektklassen gespeichert sind und ein Implementation Repository, in dem die Server und die von ihnen unterstützten Klassen registriert sind.



 
next up previous contents
Next: Die Implementierung von CORBA Up: 2.3 IBM's SOMObjects Previous: Die SOM-Laufzeitumgebung
Copyright Munich Network Management Team