Datenbankzugriff in offenen Rechnernetzen

Mit der zunehmenden Verbreitung von Rechnern wächst auch das Bedürfnis nach Datenfernübertragung und Datenfernverarbeitung. Da die direkte Verbindung von Rechnern oft nicht ökonomisch ist, haben sich flächendeckende Rechnernetze etabliert. Mit Hilfe standardisierter Protokolle können in offenen Rechnernetzen Rechner unterschiedlicher Hersteller und Bauart miteinander kommunizieren. Offene Rechnernetze schaffen die Voraussetzung für eine Vielzahl neuartiger, verteilter Anwendungen. Eine Schlüsselrolle zur Realisierung dieser Anwendungen fällt Datenbanksystemen zu. Nur mit ihrer Hilfe können große Datenbestände effizient und unter Einhaltung komplexer Konsistenzbedingungen abgerufen und verändert werden. Ein Beispiel für eine verteilte datenbankgestützte Anwendung wäre ein Informationssystem, das die neuesten Aktienkurse seinen entfernten Benutzern zur Verfügung stellt. In anspruchsvolleren Anwendungen können entfernte Datenbestände nicht nur abgefragt, sondern auch geändert werden. Als Beispiele ließen sich Reisebuchungssysteme, „home banking“ oder verteilte Dokumentenerstellung mit mehreren Autoren anführen. Eine zentrale Komponente solcher Anwendungen ist ein Mechanismus zum Datenbankfernzugriff (Remote Database Access — RDA). Um herstellerunabhängig zu sein, muß dieser Mechanismus auf einer offenen Netzarchitektur aufbauen. Bei einer offenen Architektur können sich die beteiligten Rechner zum einen hinsichtlich der Hardware, Software und der Betriebssysteme und zum anderen auch hinsichtlich der Datenbanksysteme unterscheiden. Die vorliegende Arbeit stellt unter Berücksichtigung bestehender Ansätze Anforderungen an einen Mechanismus zum Datenbankzugriff in offenen Rechnernetzen auf, diskutiert die dabei auftretenden Probleme und entwickelt dafür neuartige Protokolle.

Ziel dieses Kapitels ist es, Anforderungen an eine Kommunikationsunterstützung für den Datenbankfernzugriff (Remote Database Access — RDA) aufzustellen. Dieser Datenbankfernzugriff soll in einem möglichst breiten Spektrum von verschiedenen Anwendungen einsetzbar sein. Die diesbezüglichen Anforderungen werden aus den Kommunikationserfordernissen bestehender Systeme, die auf entfernte Datenbanken zugreifen, hergeleitet. Mechanismen für Datenbankfernzugriffe finden ihre Anwendung insbesondere in verteilten Datenbankmanagementsystemen (Distributed Database Management System — DDBMS), in föderativen Datenbankmanagementsystemen (Federated Database Management System — FDBMS) und in verteilten Transaktionssystemen (siehe auch [Effe87]). Um den Vergleich der Kommunikationsaspekte dieser Systeme strukturieren zu können, wird ein eigenes Modell eingeführt.

Wie in Kapitel 2 eingeführt, besteht unser Systemmodell für den Datenbankfernzugriff aus einer Menge von Knoten, die durch ein Kommunikationsnetzwerk verbunden sind. In Kapitel 2 wurden Knoten in die funktionalen Elemente Anwendungsprogramm (AP), Datenkommunikationsmanager (DCM) und lokaler Ressourcen-Manager (LRM) unterteilt. In den folgenden Kapiteln wird ein DCM-Element zur Kommunikationsunterstützung des Datenbankfernzugriffs entworfen. Zur Diskussion von möglichen Realisierungen der DCM-Funktionen ist ein Verarbeitungsmodell notwendig, welches im folgenden erläutert wird. In dem Verarbeitungsmodell werden die Knotenobjekte Prozessor, Speicher und Prozeß eingeführt. Diese Objekte ermöglichen es, die DCM-Funktionen auf einem Knoten auszuführen. Die Realisierung der DCM-Funktionen muß berücksichtigen, daß Fehler auftreten können. Fehler werden entweder durch Knoten oder durch das Kommunikationsnetzwerk verursacht. Mit Hilfe eines Fehlermodells wird im folgenden eine Klassifikation der Komponenten bezüglich ihrer Zuverlässigkeit vorgenommen. Diese Klassen sind bei der Realisierung der Verwaltungsfunktionen für verteilte Transaktionen von besonderem Interesse.

In diesem Kapitel wird ein RDA-Kommunikationselement entworfen, das die in Abschnitt 2.3.1. aufgestellten Forderungen erfüllt. Nach der Definition der zugrundeliegenden Software-Architektur werden Funktionen zur Verbindungsverwaltung, zum Transfer von Datenbankoperationen, zur Unterstützung der Datenrepräsentation und zur Transaktionsverwaltung eingeführt. Den dabei entwickelten eigenen Lösungen wird abschließend der ISO/OSI-Ansatz gegenübergestellt. Nachfolgend beschränken wir uns zunächst auf die Betrachtung eine Szenariums, in dem ein Client mit genau einem Server kommuniziert (Einzel-Server-Datenbankfernzugriff). Die Erweiterung auf einen Multi-Server-Datenbankfernzugriff geschieht in Kapitel 5.

Dieses Kapitel behandelt die Erweiterungen der Funktionalität des RDA-Kommunikationselementes, die dann nötig werden, wenn ein Client auf mehrere Server innerhalb einer Transaktion zugreift. Die Funktionalität, die die Verbindungsverwaltung, den Transfer von Datenbankoperationen und die Unterstützung der Datenrepräsentation betrifft, unterscheidet sich nicht von der in Kapitel 4 diskutierten Funktionalität des Einzel-Server-Falls. Daher wird nachfolgend ausschließlich die Transaktionsverwaltung im Multi-Server-RDA untersucht. Dabei werden verschiedene Protokolle eingeführt, die sich in dem Grad der Toleranz gegenüber bestimmten Fehlerklassen unterscheiden. Dies ist insbesondere im Hinblick auf den Einsatz der Transaktionsprotokolle in offenen Netzen interessant, da in offenen Netzen keine Annahmen über die Zuverlässigkeit der beteiligten Systeme gemacht werden können.

Die im folgenden vorgestellte Implementierung ist in Zusammenarbeit mit der Forschungsgruppe „Verteilte Anwendungen“ des Europäischen Zentrums für Netzwerkforschung der Firma IBM entstanden. Die Implementierung realisiert den ISORDA-Standard in derjenigen Version, wie er 1988 als zweite Arbeitsgrundlage (2nd Working Draft) vorlag. Der in der Programmiersprache „C“ geschriebene Prototyp läuft auf IBM PS/2 Rechnern mit dem Betriebssystem OS/2 Extended Edition 1.1. Als Datenbanksystem wurde der Database Manager von OS/2 Extended Edition 1.1 verwendet, der den SAA-Richtlinien (Systems Application Architecture) der IBM für relationale Datenbanksysteme entspricht. In der ersten Version des Prototyps wird nur der RDA-Basis-Anwendungskontext (vgl. Abschnitt 5.2.2.3.) unterstützt. Zur Zeit der Fertigstellung dieser Arbeit wird gerade der RDA-CCR-Anwendungskontext realisiert. Im Kommunikationselement ist dies schon teilweise implementiert (z.B. in der SACF-Funktion), Client und Server müssen noch erweitert werden. Vorerst werden keine verteilten Transaktionen vom Kommunikationssystem unterstützt. Ein Client kann zwar grundsätzlich verschiedene Verbindungen zu verschiedenen Servern aufbauen, doch liegt die Kontrolle dieser Verbindungen dann in der Verantwortung des Client bzw. des Anwendungsprogramms und nicht in der des Kommunikationssystems. Abb. 61 auf Seite 162 zeigt die Software-Struktur des Prototyps, wie sie im folgenden besprochen wird. Der Client enthält ein Anwendungsprogramm (AP), das über eine spezielle Schnittstelle (API) sich der Dienste bedient, die durch das RDA-Kommunikationselement zur Verfügung gestellt werden. Das RDA-Kommunikationselement besteht aus den Dienstelementen ACSE, ROSE und später CCR, der sie integrierenden Funktion SACF, einer Betriebssystem-Einbettung (OSI-BSE), Schnittstellen zum Client/Server und den tieferen Schichten (Stubs) sowie einer Funktion, die diese Elemente in der richtigen Reihenfolge aktiviert und die Kommunikation zwischen diesen unterstützt (Scheduler/Router). Der Server wandelt die vom Kommunikationssystem empfangenen Dienstaufrufe in DBMS-Aufrufe um und schickt entsprechende Resultate über RDA-Dienste zurück.

In der vorliegenden Arbeit wurden Anforderungen und Realisierungsmöglichkeiten für eine auf dem Client/Server-Modell basierende Kommunikationsunterstützung für den Datenbankfernzugriff in offenen Netzen erarbeitet. Als Basis für die Anforderungsanalyse diente eine Klassifikation der Kommunikationseigenschaften bestehender Systeme. Dafür wurde ein eigenes Modell entwickelt, mit welchem die Kommunikation in verteilten Datenbanksystemen, föderativen Datenbanksystemen, verteilten Transaktionssystemen und im RDA dargestellt wurde.