Mit der Einfuehrung von Client-Server-Architekturen ist nicht selten die Abloesung der Mainframe-Landschaft durch Netzloesungen verbunden. Allerdings werden heute noch viele Neuimplementierungen so installiert, als muesse die alte Architektur noch immer als Vorbild gelten. Warum das nicht so ist und welche wesentlichen Veraenderungen durch den Einsatz von Transaktionsmonitoren erreicht werden koennen, zeigt Hanns-Martin Meyer* in seinem Beitrag.
Hinter Downsizing, Rightsizing und Client-Server-Computing verbirgt sich vor allem das Ziel, moeglichst viele Applikationen vom zentralen Mainframe zu nehmen. Klassische Grossrechneranwendungen sollen ganz oder zumindest teilweise auf PCs und Unix-Systeme verlagert beziehungsweise reimplementiert werden.
Allerdings werden diese transferierten Anwendungen oft genauso monolithisch designed und implementiert wie ihre Pendants auf der Mainframe-Seite. Das geschieht dann, wenn die komplette Anwendungssoftware auf dem PC und lediglich die Datenbank auf einem gemeinsamen Server-Rechner laeuft.
Vorteile aus der alten in die neue Welt uebernehmen
Abgesehen von der Moeglichkeit, ein Graphical User Interface (GUI) zu nutzen, ist damit nicht viel gewonnen. Im Gegenteil, man holt sich noch einige zusaetzliche Probleme heran. Wie ist das Netzwerk- Management einer solchen Architektur bei mehreren hundert oder gar tausend Benutzern zu beherrschen? Wie lassen sich (zum Beispiel aufgrund gesetzlicher Aenderungen) zum Stichtag X Tausende von installierten PC-Softwarepaketen aktualisieren?
Eines beherrschen Mainframes bekanntlich sehr gut: Die gleichzeitige Bedienung von sehr vielen Benutzern. In der "primitiven" Client-Server-Konfiguration (siehe Abbildung 1) sind solche Grossinstallationen nicht bekannt. Auf der Basis von Unix- Servern gibt es noch recht wenige davon.
Um zu erlaeutern, warum die Massen-DV noch nicht in Client-Server- Umgebungen stattfindet, moechte ich drei Szenarien vorstellen:
1. Nicht nur, weil sie mit einem entsprechenden I/O-Verhalten ausgeruestet sind, sondern vor allem wegen der Transaktionsmonitore koennen Grossrechner Tausende von Benutzern bedienen (siehe Abbildung 2). In grossen Mainframe-Umgebungen nutzen Anwendungsentwickler ausschliesslich Transaktionsmonitore, mit denen sich die von ihnen implementierten Transaktionen aktivieren, steuern und abwickeln lassen. Der Programmierer muss sich keine Gedanken darueber machen, wie viele Benutzer diese Transaktionen gleichzeitig nutzen wollen.
Diese klassische Art hat neben der unangenehmen Tatsache, dass sie an proprietaere, nicht offene Plattformen gebunden ist, einen zweiten gravierenden Schoenheitsfehler: Sie ist monolithisch, nicht verteilbar, eben Client-Server-untauglich.
Bei der klassischen Transaktion funktioniert alles aus einer Hand (aus einem Programm): Von der Benutzer-Schnittstelle mit Praesentation und Steuerung bis zu den Datenbankzugriffen.
Darueber hinaus ist die klassische Transaktion zu gross. Sie umfasst nicht nur die atomare Aktion, bestehend aus mehreren Datenbankzugriffen, die entweder komplett oder gar nicht ausgefuehrt werden muessen, sondern sie ist ebenso eine vollstaendige Benutzerfunktion im Sinne der Anwendung. Aus Sicht der Software- Architektur waere dies aber nicht noetig.
2. PC-Software-Entwickler arbeiten voellig anders, aber nicht unbedingt besser. Man koennte meinen, sie wollten die Softwarewelt neu erfinden, doch haeufig schaffen sie nur neue Namen fuer alte Techniken. Das Problem, dass viele Anwender die gleiche Transaktion benutzen wollen, hat der PC-Entwickler nur beim Zugriff auf gemeinsame Datenbanken. Dieses Teilproblem kann fuer ihn das Datenbanksystem loesen.
Beruecksichtigt werden muss aber, dass dieser Benutzer keinen Zugriff auf gemeinsame, funktionale Ressourcen hat. Nehmen wir als Beispiel ein Verkehrs-Monitoring-System. Die Verkehrsbelastung auf einem Abschnitt eines Netzes (oder der Materialdurchfluss in einem Prozess etc.) soll aus 100 Messpunkten errechnet und visualisiert werden. Natuerlich findet die Visualisierung des Auswertungsergebnisses auf dem PC am Arbeitsplatz statt.
Nehmen wir einmal an, zur Auswertung der Messergebnisse werden 30 Datenbankzugriffe notwendig. Wird das Ergebnis an 100 Arbeitsplaetzen visualisiert und die Auswertung jeweils auf dem PC durchgefuehrt, so sind das 3000 Datenbankzugriffe. Kommen nun jede Sekunde neue Messergebnisse hinzu, so finden 3000 Datenbankzugriffe pro Sekunde statt.
Angenommen, an den 100 Arbeitsplaetzen werden 100 Strekkenabschnitte des Netzes hinsichtlich ihrer Verkehrsbelastung visualisiert, so summiert sich die Datenbankbelastung auf 300 000 Zugriffe pro Sekunde. Die Leistung, aus den Messwerten die jeweilige Verkehrslast zu ermitteln, sollte also von einem Server, abrufbar fuer viele Clients, erbracht werden. Diese Leistung besteht jedoch nicht nur aus einer Datenbankeintragung. Sie wird von einer Anwendungssoftware erbracht, die vielen Clients zur Verfuegung stehen muss.
3. Den Multiuser-Betrieb beherrschen bekanntlich die Unix-Freaks - also installieren sie einen Unix-Server und implementieren dort die Anwendungssoftware, die von vielen Clients genutzt werden soll. Die Visualisierung der Auswertungsergebnisse wird auf dem PC belassen.
Je mehr Clients in Betrieb gehen, desto schlechter wird allerdings die Performance des Unix-Servers. Die Ursache: Prozesswechsel unter Unix sind zu schwerfaellig, zu "teuer". Abhilfe koennen Threads schaffen. Damit sind Anwendungsprogrammierer in der Lage, mehrere Clients in einem Prozess zu bedienen. Die Server-Software wird Multi- client-faehig. Doch Achtung: Jetzt ist der Anwendungsprogrammierer bereits dabei, Systemprogrammierung zu betreiben.
Aus gutem Grund haben die Mainframer die beiden Programmierungstypen immer sorgfaeltig getrennt gehalten. Die Risiken fuer die Softwarequalitaet sind unueberschaubar. Und ausserdem: Das Problem, Server-Software effizient Multiclient-faehig zu machen, haben moderne Transaktionsmonitore wie Tuxedo bereits anwendungsunabhaengig geloest. Unsere Loesung lautet daher: Transaktionsmonitore in Client-Server-Architekturen einsetzen (siehe Abbildung 3). Dabei laufen die Kernapplikationen auf Server-Rechnern unter einem Transaktionsmonitor. Dazu zaehlen nur die abstrakten Business-Objekte, auf die die verschiedenen Clients unterschiedliche (grafische, numerische, tabellenartige etc.) Views haben - und nicht die Visualisierung, nicht die User- Interface-Steuerung. Der Transaktionsmonitor steuert die Lastverteilung auf verschiedene Server-Exemplare.
In Zusammenarbeit mit den beteiligten Datenbanken steuert und managt er auch die Datenbanktransaktionen als atomare Aktionen. Visualisierung, User-Interface, Integration auf der Oberflaeche ueber verschiedene Server hinweg jedoch sind auf den PCs oder Workstations implementiert. Man kann also von Mainframe-Techniken viel lernen.
In eine moderne Transaktion einer Client-Server-Architektur gehoert keine Benutzeroberflaechen-Steuerung, keine Praesentation und keine Visualisierung. Mit ihr ist ausschliesslich das von diesen Dingen abstrahierte Applikationskern-Objekt zu verwalten. Dieses ermoeglicht dann im Gegenzug, von verschiedenen Arbeitsplaetzen aus unterschiedliche Sichten (Expert-, Professional-, Casual-User-Mode etc.) auf denselben Applikationskern zu eroeffnen. Moderne Transaktionsmonitore sorgen dafuer, dass dies auch mit vielen Hunderten Clients in guter Performance moeglich ist.
Als Tatsache, die diese Behauptung untermauert, sei angefuehrt: Alle Benchmarks, die die Transaktionsrate von modernen Rechnern im Multiuser-Betrieb messen, werden aus gutem Grund von den Herstellern unter Verwendung moderner Transaktionsmonitore durchgefuehrt.
Die anzustrebende Architektur fuer insbesondere Mission-Critical- Applications hat also drei Ebenen:
- Personal Clients: die Ebene der PCs und Workstations mit den Aufgaben User Interface, Visualisierung, Productivity-Tools und persoenliche Softwarekomponenten (-objekte);
-Applikations-Server: Enthaelt die Applikationskerne, und zwar abstrakt in dem Sinn, dass diese Objekte nicht wissen, wie sie verwendet oder praesentiert werden. Die Applikationskerne haben eine zugesicherte Funktionalitaet und Verfuegbarkeit. Ihre Benutzung unterliegt strengen Regeln, der Zugang ist kontrolliert. Der Transaktionsmonitor unterstuetzt die Verfuegbarkeit fuer viele Clients und sichert atomare Aktionen zusammen mit den Daten- Servern. Die Applikationen sind organisiert in vielen, auf die Anforderungen skalierten Server-Rechnern.
- Daten-Server: heute relationale Datenbanken, spaeter objektorientiert. Aber auch Image- und Video- sowie spezialisierte Server, - spaeter eventuell auch ohne Applikations-Server, direkt angebunden an die Ebene der Personal-Clients.
Diese Konstellation bietet gegenueber der klassischen Mainframe- Architektur und gegenueber der primitiven Client-Server-Architektur entscheidende Vorteile:
1. Die Trennung von "freiem und geregeltem" Betrieb. In Mission- Critical-Applications sind immer Teile, die streng geregelt ablaufen muessen (Gesetze, zu beachtender Geldwert etc.). Andererseits sollte der Benutzer die angebotenen Werkzeuge und neuen Tools frei zu seinem Vorteil einsetzen koennen (siehe Abbildung 4). Beides ist in der vorgeschlagenen Architektur moeglich, aber streng getrennt, und das erst ermoeglicht Mission- Critical-Applications unter Nutzung moderner Tools.
2. Unbegrenzte Skalierbarkeit.
3. Die Heterogenitaet wird zum Prinzip erhoben. Technologien koennen sowohl auf der Personal-Client-Seite als auch auf der Applikations-Server-Seite eingebracht werden, solange benoetigte Schnittstellen zwischen beiden Ebenen eingehalten werden. Aber Vorsicht: Homogenitaet bezueglich Plattformen anzustreben, ist kein Ziel, sondern eine Sackgasse! Bisher war IBM dominierend, heute ist Microsoft fuehrend, morgen sicher ein anderer. Und der Wechsel der Marktfuehrerschaft vollzieht sich in immer kuerzeren Zyklen.