Als State-of-the-Art in der Anwendungsentwicklung gilt das Client-Server-Konzept. Nachdem die Trennung von Daten und Applikationen vielerorts schon praktiziert wird, steht bei der Verteilung der eigentlichen Anwendungen, so Günther Tolkmit*, deren Selbständigkeit wieder auf dem Spiel. Riskiert wird eine Abhängigkeit von der jeweiligen Netzwerktopologie.
Der Begriff Client-Server-Konzept erfreut sich zunehmender Attraktivität; er wird bestimmt von der Wunschvorstellung, Anwendungen beliebig über ein Netzwerk von heterogenen Rechnern verschiedener Größenordnung zu verteilen. Insbesondere erhofft sich der Anwender davon, die Präsentationsstärke und einfache Bedienbarkeit von Einzelplatzrechnern (PCs) mit den Möglichkeiten von Großrechnern verbinden zu können.
Doch wie oft schon geschehen, läuft man auch hier mit der
Euphorie über technologische Möglichkeiten Gefahr, potentielle Nachteile zu übersehen. Nachdem mit relationalen und relationalorientierten Datenbanksystemen die Anwendungen immer datenunabhängiger wurden, stellt sich in Client-Server-Konzepten die Frage, ob die Programme nun von der Netzwerktopologie abhängig werden. Objektorientierte Datenbanksysteme können dazu beitragen, diese Gefahr zu vermeiden.
Ein Client-Server-Szenario: Der Kunde betritt ein Reisebüro, um sich über sein nächstes Urlaubsziel beraten zu lassen. Für eine grobe Zielauswahl "wandert" der Reisebürovertreter zusammen mit seinem Klienten auf dem Bildschirm seines Arbeitsplatzrechners über topologische Landkarten zum Beispiel des Mittelmeerraumes. Zumindest die Attribute Sonne und Wasser sollen erfüllt sein. An besonders interessanten Stellen wird durch einen Mouseklick ein Fenster aktiviert, das die Klimawerte dieser Gegend in einem Balkendiagramm zusammengefaßt darstellt.
Kommt es zu einer Entscheidung für den Ort, ist das Urlaubshotel das nächste Ziel der Nachfrage. Auf Aufforderung erscheint eine Liste der ortsansässigen Hotels, nach Kategorien sortiert. In weiteren Fenstern können dann besondere Eigenschaften der Hotels wie Swimmingpool und Sauna eingeblendet werden oder aber die Suche nach einem Hotel geschieht über andere Kriterien, beispielsweise Kinderfreundlichkeit.
Nach Vorauswahl des Hotels steht jetzt die Frage der Anreise an. Dazu werden die möglichen Flugverbindungen in die Landkarte eingeblendet. Auf diese Weise kommt es zur Flugbuchung. Da es sich lohnt, auch einen Mietwagen zu bestellen, fließt auch diese Information in den Reisevorschlag ein. Nun wird die eigentliche Reisebuchung durchgeführt. Nach einigen weiteren Adjustierungen bekommt der Kunde seine fertigen Reiseunterlagen ausgedruckt und überreicht.
Was ist hierbei technologisch abgelaufen? Die Vorauswahl des Reiseziels könnte auf dem lokalen Arbeitsplatzrechner durchgeführt worden sein. Aber schon die Liste der Hotels stammt wahrscheinlich von dem Zentralrechner des Reisebüros, der diese Daten weltweit vorhält. Die Flugverbindungen kommen dann aus dem Reservierungsrechner der Fluglinie. Dieser Reservierungsrechner könnte im direkten Kontakt mit dem Reisebüro- und Autovermietungsrechner stehen. Beim eigentlichen Buchungsvorgang würden dann all diese Rechner zur Reisebestätigung beitragen.
Wie hat sich der Reisebürovertreter gegenüber dem System verhalten? Er hat in den Objekten Reise, Reiseziel, Hotel, Flugverbindung und Mietwagen "gedacht" und völlig unabhängig von dem zugrundeliegenden Rechnernetzwerk gehandelt. Für ihn hatte das System ein einziges "Gesicht", ein Single System Image. Das ist das Ziel aller sogenannten Client-Server-Konzepte.
In Bezug auf das zu implementierenden Computersystems kann zur Lösung des oben beschriebenen Szenarios von verschiedenen Designansätzen ausgegangen werden.
Der heute vorherrschende Ansatz ist die Implementierung der Anwendung auf dem Arbeitsplatzrechner, dem Client, und die Implementierung der Datenbank auf einem Zentralrechner, dem Server.
Der Flaschenhals dieses Designs läßt sich sofort identifizieren: die Leitung zwischen Client und Server. Ein kleines Rechenexempel soll dies weiter verdeutlichen: Die Hotelliste aus unserem Beispiel wird vom Datenbankserver angefordert. Die dazu notwendige Eingabenachricht möge 100 Bytes lang sein. Die Ausgabeliste umfasse pro Hotel ebenfalls 100 Bytes, und im Durchschnitt müssen zwei Seiten ä 20 Zeilen durchblättert werden. Das ergibt insgesamt j100 Bytes und damit folgende Übertragungszeiten: bei einer 9600-Baud-Leitung (Baud = Bits/s):
9600:8 = 1200 Bytes/s.
4100:1200 = 3,4 Sekunden bei einer 64 000-Baud-Leitung:
64 000:8 = 8000 Bytes/s.
4100:8000 = 0,5 Sekunden
Also selbst bei für heutige Verhältnisse schnellen Fernleitungen von 64 KB ergeben sich alleine für die Übertragung erhebliche Zeiten. Die Rechnung läßt sich leicht fortsetzen, in dem Komplexität der Transaktionen und Paketvermittlungsdienste einbezogen werden.
Leitungsgeschwindigkeit ist nicht realisierbar
Diese kleine Rechnung zeigt deutlich die konzeptionelle Schwäche des Designansatzes "Trennung der Anwendung von der Datenbank" auf. Insbesondere in Fernnetzen werden sich die für dieses Client-Server Prinzip notwendigen Leitungsgeschwindigkeiten auf längere Zeit nicht verwirklichen lassen.
Für die Realisation heutiger Client-Server-Konzepte nach dem Prinzip "Trennung der Anwendung von der Datenbank" sind ausschließlich relationale Datenbanken denkbar ungeeignet. Streng relationale Datenbanken zeichnen sich aufgrund des Zwangs zur Normalisierung - mindestens die erste Normalform muß erfüllt sein - auf der physischen Ebene durch eine Vielzahl von Einzelobjekten (Tabellen) aus, die in komplexen Beziehungen, abgebildet über Referenzintegritäts-Bedingungen, zueinander stehen. Vorausgesetzt, daß das Client-Server-System nach dem Paradigma "Trennung der Anwendung von der Datenbank" verwirklicht werden soll, werden die Schwächen relationaler Datenbanken deutlich:
Durch die Normalisierung entsteht eine Vielzahl von Tabellen, die schon in einer lokalen Anwendung schwer zu handhaben ist. In einer verteilten Anwendung wie bei einem Client-Server-Konzept kann dies zur Falle werden, was Leitungsverkehr, globale Optimierung (im Falle des Zusammenspiels von Hotel- und Flugcomputer) und globale Sperrverwaltung anbetrifft. Die Pflege von Referenzintegritäten über Rechnergrenzen kann praktisch zum "Alptraum" werden.
Wie oft in der realen Welt. treten auch in diesem Beispiel rekursive Beziehungen auf. Diese sind aus prinzipiellen Gründen im relationalen Modell nicht adä uat behandelbar.
Übrigens werden jetzt Kenner von relationalen DBMS einwenden, daß der erste Schwachpunkt durch die Ausnutzung des View-Konzeptes umgangen werden kann. Das stimmt weitgehend - für den Lesefall. Doch im Änderungsmodus muß nach heutigem Stand auf die Behandlung der Basistabellen zurückgegangen werden. Und die Pflege der Referenzintegrität über Rechner enzen hinweg wird immer problematisch bleiben - ganz zu schweigen von der globalen Sperrverwaltung.
Der Ausweg aus dieser Misere ist leicht zu erkennen. Es kommt nicht darauf an, die Anwendung von der Datenbank zu trennen, sondern die Anwendung selbst zu verteilen.
Statt also aus der Anwendung auf dem lokalen Arbeitsplatzrechner des Reisebüros bei der Zuummenstellung der Flugverbindungen auf die Tabellen Kalender, Ort, Flugverbindung, Fluggesellschaft einzeln zuzugreifen, wird nur noch der Auftrag "Auflisten der möglichen Flugverbindungen" an den Reservierungscomputer geschickt. Dieser sendet dann die angeforderte Übersicht zurück, nachdem er sie in einem weiteren Anwendungsteil auf dem Großrechner zusammengestellt hat.
Diese Client-Server-Anwendung wird also für die Ausführung in mehreren Teilen auf mehreren Rechnern entworfen. Nur nach welchen Kriterien werden jetzt solche Anwendungen in mehrere Teile geschnitten? Laufen wir hier nicht Gefahr, mangels anderer Designkriterien die Netzwerktopologie in die Anwendung "einzubauen"? Wird es also in Zukunft." Netzwerk- statt Datenabhängigkeit in unseren Programmen heißen? Dies gilt es auf jeden Fall zu vermeiden.
Lösen wir uns vom Denken in heutigen Client-Server-Architekturen, so ist der erfolgversprechende Lösungsansatz verblüffend einfach: Der Endanwender des Reisebüro-Informationssystems denkt in Objekten wie Reise, Hotel, Flug, Buchung. Das drückt sich - sogar in der Oberfläche auf seinem Arbeitsplatzrechner aus - durch die Verwendung entsprechender grafischer Symbole (Ikonen), beispielsweise durch ein Flugzeug für Flugverbindung oder ein Gebäude für Hotel.
Also ist es doch naheliegend, auch die Anwendung objektorientiert aufzubauen. Damit ergeben sich intuitiv zuverlässige Entwurfskriterien für eine werteilte Anwendung.
Bei der Implementierung dieser Programme benutzt man nun konsequentorientierte Datenbanksysteme lösen viele der oben beschriebenen Probleme klassischer Client-Server-Ansätze.
Integritätsprüfung aus dem Programm ausgelagert
Das Prinzip der Kapselung erlaubt das Design verteilter Anwendungsprobleme, ohne die Abhängigkeit von der Netzwerktopologie einzuführen. Die Anwendung "denkt" in Objekten, wo auch immer diese residieren oder ausgeführt werden. Außerdem ermöglicht das Prinzip der Objektidentität die Implementierung praktikabler Sperrverwaltungen, wobei sicherlich optimistische Sperrprotokolle den
Vorzug erhalten werden.
Darüber hinaus werden auf grund des Methodenprinzips die Integritätsprüfungen aus dem Programm ausgelagert. Last, not least hilft das Prinzip der Messages, das Nachrichtenvolumen und damit den Leitungsverkehr in praktikablen Grenzen zu halten.
Dabei stellen sich dann Referenzintegritäts-Bedingungen nur als eine relativ kleine Submenge dar.
*Günther Tolkmit ist Product-Marketing-Director bei der Software AG,
Darmstadt.