Sprachunabhängige Verwaltung von
atomaren Objekten des RelaX-Objektraums

DIPLOMARBEIT

Rheinische Friedrich - Wilhelms - Universität Bonn

Michél E.R. Wack

April 2002

Vorwort

Die vorliegende Arbeit entstand im Rahmen meiner freien Mitarbeit in dem Projekt RelaX des Instituts für Systemtechnik (ab 1.1.1992 Institut für Systementwurfstechnik SET) in der Gesellschaft für Mathematik und Datenverarbeitung mbH (GMD) in Sankt Augustin.

Die Betreuung der Arbeit übernahmen Herr Prof. Dr. K.-H. Böhling (Universität Bonn, GMD), Herr Dr. Reinhold Kröger (GMD) und Herr Dipl.?Inform. Michael Mock (GMD), die mir in vielen Gesprächen mit Ratschlägen und wertvollen Hinweisen zur Seite gestanden haben und denen ich auf diese Weise danken möchte.

Weiterhin möchte ich Frau Susanne Zigann für Ihre Unterstützung bei der Erstellung des Manuskriptes danken. Besonderen Dank schulde ich auch Frau Dagmar Faßbender für das genaue Korrekturlesen der Arbeit. Zu erwähnen sind außerdem die zahlreichen Diskussionen die ich mit Herrn Marcus Greuel im Vorfeld der Arbeit führte, welche mir beim Entwurf des AOM sehr geholfen haben.

Michél E.R. Wack
Bonn, im April 2002

Inhaltsverzeichnis

Inhaltsverzeichnis ... II
Abbildungsverzeichnis ... IV

1. Einleitung ... 1
    1.1. Verteilte Systeme ... 2
    1.2. Fehlertoleranz ... 6
    1.3. Objektkonzept ... 14
    1.4. Systemarchitektur ... 24
    1.5. Der RelaX Transactional Object Manager ... 31
    1.6. Inhaltlicher Überblick ... 36

2. Entwurf des AOM ... 37
    2.1. Einleitung ... 37
    2.2. Anforderungen an den AOM ... 40
        2.2.1. Funktionale Anforderungen ... 40
        2.2.2. Nichtfunktionale Anforderungen ... 58
    2.3. Die Basisschnittstelle des AOM ... 63
        2.3.1. Virtual Segment Manager VSM ... 63
        2.3.2. Generische Transaktionsunterstützung GTU ... 65
    2.4. Grobentwurf ... 68
    2.5. Atomare Segmente ... 72
    2.6. Objektrepräsentation ... 74
        2.6.1. Langobjekte ... 75
        2.6.2. Cluster ... 78
        2.6.3. Kurzobjekte ... 94
    2.7. Aktive Objekte ... 95
        2.7.1. Aktivieren eines Objektes ... 100
        2.7.2. Passivieren eines Objektes ... 103
        2.7.3. Erzeugen eines Objektes ... 105
        2.7.4. Zerstören eines Objektes ... 107
    2.8. Objektaufruf ... 109
    2.9. Naming ... 116
    2.10. Der aktive Objektraum ... 120

3. Implementierung ... 122
    3.1. Implementierungsumgebung ... 123
    3.2. Modulstruktur ... 126
    3.3. Initialisierung ... 131
    3.4. Repräsentierung der Detailstrukturen ... 133
    3.5. Bereitstellung eindeutiger Identifikatoren ... 140
    3.6. Beispiel ... 142
    3.7. Testhilfen ... 149
    3.8. Größe der Moduln ... 152

4. Vergleich mit anderen Konzepten ... 153
    4.1. Extended C++ ... 153
    4.2. Avalon/C++ ... 156
    4.3. SOS ... 158
    4.4. Amadeus ... 160
    4.5. Der AOM im Vergleich ... 163

5. Zusammenfassung und Ausblick ... 167

6. Literaturverzeichnis ... 170

Abbildungsverzeichnis
Abb. 1: Schichten eines verteilten Systems ... 4
Abb. 2: Struktur eines allgemeinen verteilten Systems ... 5
Abb. 3: Zustandsdiagramm von Transaktionen ... 11
Abb. 4: Zwei-Phasen-Sperrprotokoll ... 12
Abb. 5: Hierarchie objektbasierter Sprachen ... 14
Abb. 6: Beispiele zur Einordnung objektorientierter Sprachen ... 17
Abb. 7: Speicheraufbau und Fluß der Objektversionen ... 21
Abb. 8: Architektur eines modernen verteilten Systems ... 24
Abb. 9: RelaX-Architektur ... 26
Abb. 10: Logische Struktur eines Ressource-Managers ... 28
Abb. 11: Zugriffs- und Commit Folge ... 29
Abb. 12: Struktur des RelaX Transactional Object Managers TOM ... 31
Abb. 13: Anforderungsmodell für den AOM ... 37
Abb. 14: Lebenszyklus eines Objektes ... 40
Abb. 15: Charakterisierung eines atomaren Objektes ... 44
Abb. 16: Referenzen auf atomare Objekte ... 45
Abb. 17: Adressierung im aktivem Speicher ... 46
Abb. 18: Avalon-Klassen für persistente Objekte ... 47
Abb. 19: Lebenszyklus eines persistenten Objektes ... 51
Abb. 20: Klassen von Schnittstellen des AOM ... 57
Abb. 21: Durchschnittliche Objektgröße ... 61
Abb. 22: AOM Grobstruktur ... 68
Abb. 23: Implementierungsarchitektur des AOM ... 70
Abb. 24: Allgemeines passives Objektformat ... 75
Abb. 25: Abstrakte Struktur eines Langobjekt-Headers ... 76
Abb. 26: Objektstatusfeld ... 77
Abb. 27: Cluster mit Listenstruktur ... 79
Abb. 28: Cluster mit Feldstruktur ... 80
Abb. 29: Cluster mit dynamischer Struktur ... 81
Abb. 30: Slots als lineare Liste ... 82
Abb. 31: Slots als Hash-Tabelle ... 83
Abb. 32: Slots als B-Baum ... 83
Abb. 33: Mögliche Strukturen eines Slots ... 84
Abb. 34: Grobstruktur des Cluster-Datenbereichs ... 86
Abb. 35: Aufbau eines Cluster-Header ... 88
Abb. 36. Clusterstatusfeld ... 88
Abb. 37: Clusterseiten im aktiven Speicher ... 90
Abb. 38: Clusterseiten im aktiven Speicher ... 91
Abb. 39: Adreßraum mit aktiven Clustern ... 92
Abb. 40: Struktur der Clusterebene ... 93
Abb. 41: Struktur aktiver Objekte ... 95
Abb. 42: Varianten der Objektreferenz ... 96
Abb. 43: Code Hash Eintrag ... 102
Abb. 44: Aufbau UID ... 117
Abb. 45: Adressierungspfad kurzer Objekte ... 118
Abb. 46: Verfeinerung des aktiven Objektraums ... 120
Abb. 47: Prototyp der Invoke-Funktion ... 124
Abb. 48: Die wichtigsten Moduln des AOM ... 126
Abb. 49: Repräsentierung des Objektstatusfeldes ... 134
Abb. 50: Implementierungsstruktur des Objektstatusfeldes ... 134
Abb. 51: Repräsentierung der Objektnamen ... 135
Abb. 52: Implementierungsstruktur des Objektstatusfeldes ... 136
Abb. 53: Implementierungsstruktur eines Langobjekt-Headers ... 137
Abb. 54: Implementierungsstruktur eines Cluster-Header ... 138
Abb. 55: Größen der PC++-Beispielklassen ... 145
Abb. 56: Repräsentierung des PC++-Beispiels ... 146
Abb. 57: Beispiel DCL-Datei ... 147
Abb. 58: Aktivierte PC++-Objekte ... 148
Abb. 59: Größe der Moduln ... 152

1. Einleitung

Die vorliegende Diplomarbeit wurde im Rahmen des Projekts RelaX (Reliable distributed applications support on UNIX) der Gesellschaft für Mathematik und Datenverarbeitung mbH (GMD) in Sankt Augustin angefertigt. Inhalt des Projekts ist die Entwicklung von Konzepten, Prototypen und Evaluationswerkzeugen, die die Erstellung verläßlicher, verteilter Applikationen erleichtern und beim Auftreten von Hardware- und Kommunikationsfehlern sowie bei bestimmten logischen Fehlern flexibel reagieren [KMSL90]. RelaX ist eine Weiterentwicklung des PROFEMO Projektes [NGJK85]. Als wesentliche Anwendungsgebiete von RelaX sind integrierte Informationssysteme in Bereichen wie CAD, Software Engineering, Bürosysteme und CIM anzusehen. Durch einen innovativen Ansatz werden Konzepte aus den Bereichen Betriebssysteme, Programmiersprachen und Datenbanken in RelaX vereint. Die Entwicklung neuer Anwendungen wird durch persistente Objekte unterstützt, die auf mehreren Stellen verteilt sein können und mittels Transaktionen bearbeitet werden, um gemeinsame Objektbenutzung und Fehlersituationen einfach und sicher handhaben zu können.
Im folgenden wird der Entwurf und die prototypische Implementierung des Active Object Managers AOM beschrieben, der sowohl den sprachunabhängigen Zugriff auf langlebige, synchronisierte und recoveryfähige Objekte implementiert und koordiniert als auch den Transfer von Objekten zwischen dem aktiven und dem permanenten Speicher verwaltet.

1.1. Verteilte Systeme

Die letzten Jahrzehnte lassen einen deutlichen Wandel der Mikroelektronik sichtbar werden, der sich sowohl in einem stetig fallenden Preis-Leistungsverhältnis als auch in einer veränderten Sicht von Rechensystemen manifestiert. Ständige Neuerungen in der Halbleiter? und Kommunikationstechnologie sowie veränderte Anwenderbedürfnisse führen nicht nur zu neuen Anwendungsbereichen, sondern auch zu neuen Forderungen an heutige und zukünftige Betriebssysteme [Mull89]. Die frühen Batch-Systeme sind Time-Sharing-Anlagen gewichen, die wiederum von den heute verwendeten Workstations und Personal Computern verdrängt werden.

Dezentralisierte Strukturen mit erhöhten Forderungen an die Wirtschaftlichkeit führen unter anderem zu Zielsetzungen wie erhöhter Parallelarbeit, gemeinsamer Benutzung von Ressourcen und verbesserter Verfügbarkeit. Nicht zuletzt dieses Anforderungsprofil hat zur Entwicklung von Netzwerkbetriebssystemen beigetragen, welche sich dadurch auszeichnen, daß Rechner mit lokalen Betriebssystemen, erweitert durch eine Netzwerkfunktionalität, durch ein geeignetes Kommunikationsmedium verbunden sind. Netzwerke fallen also in die Klasse der sogenannten lose gekoppelten Systeme, die keinen gemeinsamen Adreßraum besitzen und nur durch Nachrichtenaustausch kommunizieren. In der Regel ist es bei diesen Systemen so, daß der Benutzer eine Menge von Einzelrechnern sieht und daher zwischen lokalen Operationen, also solchen auf den eigenen Betriebsmitteln, und entfernten oder auch remote Operationen auf entfernten Betriebsmitteln unterscheiden kann oder sogar muß. Trotz der steigenden Popularität dieser Systeme erhöht sich die Komplexität der Programmerstellung unter anderem durch zusätzliche, aus der räumlichen Trennung resultierenden Fehlersituationen. Es können einzelne Rechner ausfallen, ohne daß dies einen Gesamtsystemausfall zur Folge haben muß, und es können bei der notwendigen Kommunikation Nachrichten verloren gehen.

Die beschriebene Charakterisierung führt schnell zu einer weiteren fundamentalen Forderung an Betriebssysteme: Transparenz. Allgemein versteht man unter dem Begriff der Transparenz die Fähigkeit oder Eigenschaft, die interne Beschaffenheit eines Gegenstandes oder einer Sache nach außen zu verbergen. Im Bereich der Rechensysteme werden verschiedene Formen der Transparenz unterschieden. Die Zugriffstransparenz ermöglicht mit identischen Operationen ganz allgemein den Zugriff sowohl auf lokale als auch auf entfernte Objekte. Durch die Ortstransparenz kann auf Objekte ohne Kenntnisse des Aufenthaltsortes zugegriffen werden. Die Eigenschaft der Transparenz ermöglicht es, dem Benutzer die Sicht eines einheitlichen, zentralen Systems zu vermitteln und damit das Vorhandensein einer Menge von vernetzten Rechnern zu verbergen.

Es stellt sich die Frage, welche Eigenschaften eine Menge vernetzter Rechner von einem verteilten System unterscheiden. Nach Tanenbaum [Tane90] zeichnet sich ein verteiltes Betriebssystem dadurch aus, daß der Benutzer eines solchen die Sicht eines einheitlichen konventionellen Systems hat, obwohl dieses auf mehreren unabhängigen Zentraleinheiten oder Rechnern läuft. Der Anwender sieht also ein virtuelles Uniprozessorsystem (siehe dazu auch Abbildung 2). Mullender [Mull89; SPG91] erweitert diese Definition und gibt eine Liste von Symptomen an, die für ein verteiltes System charakteristisch sind. Danach besteht ein verteiltes System aus bestimmten Komponenten mit definierenden Eigenschaften: Mehrere, unabhängige Prozessorelemente, im folgenden auch als Knoten oder Stellen bezeichnet, bilden ein Gesamtsystem. Eine Kommunikationseinrichtung verbindet die Knoten und ermöglicht damit den Austausch von Nachrichten und die Synchronisation zwischen parallel ablaufenden Prozessen. Das Gesamtsystem muß so konstruiert sein, daß der Ausfall einer einzelnen Komponente (Prozessor, Speicher etc.) nicht den Ausfall des ganzen Systems zur Folge hat . Eng gekoppelte Systeme, also solche, die über einen gemeinsamen Speicher kommunizieren, bilden kein verteiltes System, da der Ausfall des Speichers zu einem Ausfall des Gesamtsystems führt. Weiterhin muß gesichert sein, daß die Stellen eines verteilten Systems unabhängig voneinander ausfallen können. Das bedeutet, daß der Ausfall einer Stelle nicht den Ausfall einer anderen Stelle induziert, sondern es vielmehr so ist, daß die überlebenden Stellen weiterarbeiten.

Die logische Verteiltheit eines verteilten Systems äußert sich in der Aufteilung von Funktionen unter den Prozessen des Systems. Zum Erbringen dieser Funktionen benötigen Prozesse Kenntnisse über den Zustand des System oder zumindest über einen Teil davon. Dieser Zustand eines verteilten Systems zu einer bestimmten Zeit ergibt sich aus den Zuständen all seiner Komponenten zu diesem Zeitpunkt, also den Zuständen der Prozesse und der Kommunikationskanäle. Es ist die Eigenart verteilter Systeme, daß es auf Dauer keine zwei Prozesse gibt, die zur gleichen Zeit die gleiche, zutreffende Sicht des Systems haben. Ein Prozeß innerhalb des Systems verfügt entweder über unvollständige, aktuelle oder über vollständige, überholte Zustandsinformationen. Diese Art eines Heisenbergschen Unschärfeprinzips für verteilte Systeme rührt daher, daß der Austausch von Nachrichten zwischen Prozessen eine nicht vernachlässigbare und oft nicht vorhersagbare Zeit benötigt. Um einen anderen Prozeß des verteilten Systems über den eigenen momentanen Zustand zu informieren, muß ein Prozeß diese Zustandsinformation über einen Kommunikationskanal senden. Der informierte Prozeß empfängt die Information erst nach geraumer Zeit, wenn sich der Zustand des anderen Prozesses bereits wieder verändert haben kann. Zum wesentlichen Charakteristikum eines verteilten Systems kann man also die Ungewißheit erheben, der Entscheidungen von Prozessen aufgrund möglicherweise unzutreffender und voneinander abweichender Zustandsinformationen unterliegen [HeHo89]. Zur Durchsetzung der beschriebenen Eigenschaften ist eine verteilten Kontrolle notwendig, d.h. daß (bestimmte) Betriebssystemfunktionen durch Kooperation mehrerer Prozesse erbracht werden, von denen jeder aber nur einen Teil des für die Kontrolle notwendigen Gesamtzustandes kennt. Insbesondere sind die auftretenden komplexen Fehlersituationen in einem verteilten System durch das System selbst zu behandeln, so daß dadurch die Vorteile solcher Systeme nutzbar gemacht werden, ohne dabei aber die Komplexität einer Anwendung zu erhöhen.

Im allgemeinen lassen sich in einem verteilten System vier unterschiedliche Schichten identifizieren, wobei jede ihrerseits in mehrere Teilschichten aufgegliedert sein kann. Abbildung 1 verdeutlicht den Sachverhalt:

[...]