Wie offen muß oder kann eine Systemumgebung sein? Eine Grundsatzentscheidung für den Grad der Offenheit fällt, wenn das Anwenderunternehmen sich mit einem Client-Server-Konzept die nötige Infrastruktur aufbaut. Michael Kluck* zeigt die Möglichkeiten und Grenzen der verschiedenen Architekturen auf.

In den vergangenen Jahren haben sich die Anforderungen an ein modernes und bedarfsgerechtes Datenverarbeitungssystem grundlegend geändert. Mit dem Einzug kleiner und mittlerer Rechnersysteme in die Fachabteilungen und der verstärkten Nutzung von PC-Arbeitsplätzen mit einer komfortablen. Textverarbeitung und allgemeinen Bürofunktionen hat sich die Erwartungshaltung des Endanwenders gewandelt.

Umständliche Anmeldeprozeduren, unterschiedliche Bildschirmformate, Doppelerfassungen von Daten und fehlende Integrationsmöglichkeiten von Anwendungen werden zunehmend in Frage gestellt. Der Ruf nach besserer Unterstützung der individuellen Anforderungen der Sachbearbeiter wird immer lauter.

Die DV-Verantwortlichen in den Unternehmen kämpfen aber noch an einer anderen Front: Marktsituation und Vertriebsstrategien ändern sich immer schneller. Das zwingt zu organisatorischen Änderungen, die von der Datenverarbeitung flexibel und prompt abgebildet werden müssen.

Das Ziel ist eine kostengünstige, leicht an organisatorische Veränderungen anpaßbare Softwarelandschaft. Im Zeichen des Investitionsschutzes sollen sich bestehende Hardwarekonfigurationen und bereits auf dem Großrechner ablaufende Anwendungssysteme integrieren lassen. Außerdem gehört es inzwischen zum Stand der Technik, daß der Anwender an einem intelligenten Bildschirm-Arbeitsplatz bei allen Arbeitsabläufen von einer grafisch orientierten Benutzeroberfläche, Fenstertechnik und Maussteuerung unterstützt wird.

Ist dieses Ziel erreichbar? Die Antwort lautet: ja. Allerdings kann der Übergang nicht in einem einzigen Schritt vollzogen werden. Einen Grundbaustein für eine Lösung bilden Client-Server-Architekturen, mit deren Hilfe Anwendungen und Daten verteilt, Servicefunktionen auf unterschiedlichen Rechnern ablauffähig gemacht und heterogene Systemlandschaften zu einem Anwendungssystem zusammengeführt werden können.

Das Client-Server-Konzept verbindet darüber hinaus technische und organisatorische Sichtweisen. Es gibt Netzen und Anwendungen eine bestimmte Ordnung, bei der die Arbeitsstation (Client) eines Benutzers auf Rechner im Netz mit dezidierten Aufgaben (Server) zugreift und so über im Netz verteilte Daten und Anwendungen verfügen kann. Für den Benutzer ist es dabei irrelevant, wo und wie die Informationen im System zusammengestellt werden.

Die Verteilung von Verarbeitungen im Sinne einer Client-Server-Architektur setzt eine besondere Form der Modularisierung der Anwendung selbst voraus. Die Trennung von Präsentation, Anwendungslogik und Datenzugriffen ist eine Minimalanforderung, um Aufgaben im Netz verteilen zu können.

Für die übergreifende Navigation der Anwender-Systeme ist es darüber hinaus vorteilhaft, eine weiter Schicht auszulagern: die Dialogsteuerung. In vielen Fällen führen die Anforderungen auch noch zu einer Modularisierung der Anwendungslogik selbst und zwar aus funktionaler Sicht. Für eine Verteilung kann es beispielsweise sinnvoll sein, Prüfungen der Benutzereingaben auf einer programmierbaren Workstation (PWS) abzuarbeiten, die Verarbeitung der Daten aber auf dem Großrechner. Hier muß die Anwendung selbst in funktionale Bestandteile zerlegt werden.

Festgehalten werden sollte an dieser Stelle noch, daß die Architekturgrundsätze nicht nur für verteilte Systeme gelten. Auch in einem Großrechnersystem ist eine solche Modularisierung sinnvoll, um beispielsweise die Abhängigkeiten von Subsystemen zu reduzieren. Gleichzeitig eröffnet eine solche Schichtung der Software aber auch einen Migrationsweg in ein verteiltes System.

Gleichzeitig mit der Modularisierung muß für eine sinnvolle Verteilung auch die Portabilität der Anwendungen sichergestellt werden. Zumindest die Anwendungsmodule müssen auf verschiedenen Hardwareplattformen und in unterschiedlichen Betriebssystemumgebungen möglichst ohne Änderung ablauffähig sein. So kann die Software-Entwicklung kostengünstig erfolgen und gleichzeitig eine Verteilung der Anwendungsmodule nach den jeweiligen organisatorischen Notwendigkeiten möglich werden.

Diese Forderung hat Auswirkungen auf die Wahl der Programmiersprache, in der die Anwendungen realisiert werden. Auf jeder vorgesehenen Plattform muß ein entsprechender Compiler oder zumindest eine Runtime-Umgebung verfügbar sein.

Die Verteilung der Anwendungen setzt darüber hinaus eine klare und einheitliche Standardisierung der Schnittstellen zwischen den einzelnen Schichten innerhalb der Architektur voraus.

Verteilungsformen von Anwendungen

Für die Verteilung von Anwendungen in einer Client-Server-Architektur sind fünf Vorgehensweisen denkbar. Sie stellen jeweils unterschiedliche Anforderungen an die Systemumgebung, was die Art der Kommunikation der Anwendungsteile untereinander sowie die Sicherstellung der Datenkonsistenz in kommerziellen DV-Systemen betrifft.

Dezentrale Präsentation: Anwendung und Datenzugriffe liegen hier ausschließlich auf dem Server. Die Präsentation ist auf eine programmierbare Workstation (PWS) ausgelagert. Diese Verteilung setzt nur eine Systemkoppelung voraus und kann beispielsweise über eine Nettodaten-Schnittstelle sichergestellt werden. Die Sicherung der Datenkonsistenz und die Verarbeitung liegen ausschließlich auf dem Server (Host).

Dezentrale Verarbeitung mit zentraler Datenhaltung: Die Präsentation und die komplette Anwendungslogik befindet sich auf dem Client (PWS), während alle Datenzugriffe über den Server (Host) abgewickelt werden. Auf dem Server erfolgt auch die Sicherung der Datenkonsistenz. Zur Kommunikation genügt der Aufruf von Prozeduren in einem entfernten System (Remote Procedure Call, kurz: RPC). Die Zugriffsmodule können prinzipiell auch auf der PWS ablaufen. Für die Datenbankzugriffe ist dann aber zumindest die Unterstützung des entfernten Zugriffs (Remote Request) oder der Remote Unit of Work erforderlich, um die Konsistenz der zentralen Datenbasis zu gewährleisten.

Verteilte Verarbeitung mit zentraler Datenhaltung: Die Präsentation und Teile der Anwendungslogik liegen auf der PWS, der andere Anwendungsteil auf dem Server (Host). Die Kontrolle der Daten läuft nur auf dem Server ab, dort sind die Daten auch zentral gespeichert. Die enge Kopplung der Anwendungsteile und die Forderung, daß eine Störung der Kommunikation zu keinen Inkonsistenzen in der Verarbeitung führen darf, erfordern die Verwendung eines transaktionssicheren Kommunikationsprotokolls wie APPC/LU 6.2.

Dezentrale Verarbeitung mit verteilter Datenhaltung: Diese Variante entspricht der oben dargestellten zweiten Vorgehensweise, wobei hier aber die Daten auf mehrere Systeme verteilt sind beziehungsweise in mehreren Datenbanken abgelegt werden. Werden Daten während eines Verarbeitungsschrittes auf mehreren Datenbeständen gleichzeitig verändert, ist für Sicherstellung der Datenkonsistenz die Verwendung eines transaktionssicheren Kommunikationsprotokolls (zum Beispiel APPC/LU 6.2) und eine entsprechende Synchronisation der beteiligten Datenhaltungssysteme notwendig. Dies setzt die Verfügbarkeit des sogenannten 2-Phase-Commits voraus beziehungsweise die Unterstützung der Distributed Unit of Work bei Datenbanken.

Verteile Verarbeitung mit verteilter Datenhaltung: Diese Verteilungsform stellt die höchsten Anforderungen an die Art der Kommunikation, die Verteilung. im Netz sowie die Synchronisation der Datenzugriffe und ist die Verallgemeinerung der beiden zuvor behandelten Architekturen. Eine Verteilung von Anwendungen mit einer Modularisierung der elementaren Anwendungsbestandteile nach den Anforderungen einer modernen DV-Architektur muß natürlich auch einer wirtschaftlichen Kosten-Nutzen-Betrachtung standhalten. Andererseits sind die Risiken beim Einsatz neuer Technologien in einem überschaubaren und kalkulierbaren Rahmen zu halten.

Die Verteilung einer Anwendung nach dem Client-Server-Konzept unter Verwendung von intelligenten Workstations als Endgeräte für die Präsentation bietet folgende Vorteile:

- Der Einsatz von programmierbaren Workstations, (PWS) erlaubt die Nutzung einer einheitlichen, ergonomischen und standardisierten Benutzeroberfläche (CUA-Standard). Die grafisch orientierten Oberflächen mit den Möglichkeiten von Fenstertechnik und Maussteuerung bieten dem Endanwender eine komfortable Arbeitsgrundlage und verkürzen durch die Art der Bedienerführung die Einarbeitungszeiten in neue Anwendungssysteme.

- Auf der PWS ist die Einbindung von Standard-Softwarepaketen für Bürokommunikation, Textverarbeitung, Tabellenkalkulation oder Business-Grafik möglich. Dabei arbeitet der Anwender immer unter einer einheitlichen Benutzeroberfläche. Für ihn ist nicht erkennbar, ob eine Anwendung auf dem PC, dem Abteilungsrechner oder dem Mainframe abläuft.

- Die Antwortzeiten im direkten Benutzerdialog sind auf dem dezentralen System deutlich kürzer als in Großrechnersystemen. Auf der PWS kann, eine Reaktion ereignisgesteuert erfolgen, prinzipiell kann auf jeden Tastendruck oder Mausklick sofort und unmittelbar reagiert werden. Beim Großrechner dagegen waren alle eingegebenen Daten erst über das Netz weitergeleitet und zentral interpretiert. Auch die Antwort vom Host muß wiederum über das Netz an das Datensichtgerät gesendet werden.

- Durch die Verlagerung von Anwendungsteilen wird der Großrechner entlastet. Die Aufbereitung der Bildschirme oder die Plausibilisierung der Eingaben des Anwenders erfolgen dezentral. Die Arbeit wird auf eine Vielzahl intelligenter Endgeräte verteilt und führt so indirekt zu einer Verbesserung der Performance auf den Großsystemen.

- Das Preis-Leistungs-Verhältnis spricht zugunsten der dezentralen Systeme. Vergleichbare Rechnerleistung auf der PWS ist preisgünstiger als auf dem Mainframe.

- Die Verteilung der Anwendungen über mehrere Rechnersysteme erhöht auch die Verfügbarkeit. Das System ist insgesamt ausfallsicherer. Der Anwender kann zum einen bei einer Störung der Kommunikation oder des Großrechners auf seinem dezentralen System off-line die Geschäftsvorgänge weiterbearbeiten, wobei die Anwendung automatisch beim erneuten Verbindungsaufbau zum Großrechner in den Online-Betrieb übergeht. Außerdem wird es durch eine Verteilung von Services im Netz möglich, bei Ausfall eines Rechners die Dienste auf einem anderen Rechner anzufordern. Und wenn alle Stricke reißen, kann der Anwender bei Störungen im Netz sein Endgerät auch stand-alone benutzen.

- In verteilten Systemen können Services wie etwa komplexe Berechnung auf einen dafür speziell ausgelegten Rechner mit mathematischem Co-Prozessor delegiert werden.

- Der Aufbau eines verteilten Systems ist in kleinen Teilschritten möglich. Eine nach der Client-Server-Architektur entwickelte Anwendung kann beliebig verteilt werden. Dabei sind dem Ausbau der Netzstrukturen und der Funktionsänderung von Rechnerkomponenten keine Grenzen gesetzt. Client-Server-Anwendungen reduzieren die Hürden auf dem Wachstumspfad vom PC-basierten LAN zur Mainframe-Umgebung.

- Durch die Architektur läßt sich die Verteilung schneller an organisatorisch bedingte Änderungen anpassen. Bei der Dezentralisierung von Arbeitsabläufen werden die Anwendungen entsprechend auf Abteilungsrechner portiert, die Datenhaltung kann ebenfalls leicht den organisatorischen Notwendigkeiten angepaßt werden. So muß die Anwendung nicht jeweils komplett geändert werden, wenn entsprechende Anforderungen im organisatorischen Umfeld formuliert werden.

Der Client-Server-Gedanke ist durchaus nicht neu. Daher existiert bereits eine Reihe von sinnvollen Anwendungen, die für diese Architektur entwickelt wurden. In vernetzten PC-Systemen ist es heute üblich, bestimmte Aufgaben auf Server zu verlagern (Druckserver, Fileserver, Printserver, Gateway-Funktionen etc.), die von allen angeschlossenen Nutzern im LAN gemeinsam angesprochen werden können. Je mehr die Systeme aber dem PC-Bereich entwachsen und Kopplungen mit Abteilungsrechnern oder Großrechnern benötigt werden, desto weniger Ansätze existieren, um vollständig integrierte Anwendungen zu realisieren.

Die Grenzen der Architektur

Die häufigste Form der Kopplung ist - sofern der PC sein Dasein nicht als Stand-alone-System fristet - die Terminal-Emulation. In diesem Fall dient der PC als leistungsfähigerer Ersatz des "dummen" Terminals. Von einer Integration der Anwendungen ist dieser Ansatz jedoch weit entfernt, und auch der Filetransfer vom Großrechner bringt nur einen bescheidenen, zusätzlichen Schritt.

Die Zurückhaltung bei vielen DV-Verantwortlichen bezüglich der Umsetzung von Client-Server-Architekturen mit Einbezug der klassischen Mainframe-Umgebung ist nicht ganz unbegründet. Je heterogener das integrierende Umfeld ist und je höhere Ansprüche eine transaktionsorientierte Verarbeitung an Datenkonsistenz und Synchronisation stellt, desto größere Probleme sind bei der Umsetzung der Konzepte erkennbar. Als Voraussetzung für verteilte Verarbeitung gibt es, wie gesagt, ein transaktionssicheres Protokoll zur Programmverknüpfung (APPC) - im IBM-Umfeld heißt es LU 6.2 -, das sich als Quasi-Standard durchgesetzt hat. Dieses Protokoll ist heute zwar auf vielen Plattformen verfügbar und wird von fast allen Herstellern unterstützt, die Implementierung ist aber unterschiedlich und nicht immer vollständig.

Erschwerend kommt hinzu, daß die Programmierung der Schnittstelle sehr komplex ist und nicht von jedem Programmierer beherrscht wird. Oft muß eine Kommunikation zwischen zwei unterschiedlichen Rechnertypen aufgebaut werden, was Kenntnisse aus beiden Betriebssystemwelten erfordert. Hier sind Spezialisten gefragt.

Da eine leicht handhabbare, vollständig standardisierte und von allen Herstellern unterstützte Programmier-Schnittstelle zum heutigen Zeitpunkt fehlt, empfiehlt es sich, für eine kurzfristig verfügbare Lösung eine entsprechende Kommunikationskomponente zentral zu entwickeln, die aus allen Anwendungen heraus einheitlich angesprochen werden kann. In unserem Unternehmen wurde dieser Weg gewählt. Für alle Anwendungen, die unter der Infrastruktur ablaufen, wurde eine entsprechende Kommunikationskomponente entwickelt. Eine zentrale Schnittstelle übernimmt dabei die Kommunikation und die als Routing bekannte Verteilung im Netz.

Die technische Unterstützung im Bereich der verteilten Datenhaltung hat insgesamt noch nicht den Stand erreicht, um eine Verteilung in heterogenen Systemumgebungen in der Praxis einfuhren zu können. Eine transaktionssichere Verarbeitung mit automatischer Wiederherstellung konsistenter Datenbestände über verteile Datenbanken hinweg ist in homogenen Systemumgebungen heute bereits durch die Kopplung zum Beispiel von zwei DB2-Systemen möglich. Die Unterstützung von entfernten Datenzugriffen (Remote Request) und der Remote Unit of Work ist ebenfalls teilweise verfügbar, setzt aber eine zentrale Datenhaltung voraus.

Problem beim 2-Phasen-Commit

Die für verteilte Datenhaltung unter Konsistenz und Sicherheitsaspekten notwendige Unterstützung des 2-Phase-Commits ist derzeit nur herstellen spezifisch gelöst. Hier versucht zwar beispielsweise die IBM, andere Hersteller zur Unterstützung ihrer Distributed Relational Database Architecture (DRDA) zu verpflichten. Eine generelle Implementierung dieses Standards, der eine Datenkonsistenz in verteilten Systemen über heterogene Datenbanken hinweg sichern kann, wird aber frühestens in ein bis zwei Jahren verfügbar sein.

Client-Server-Architekturen können heute bereits in heterogenen Systemen umgesetzt werden. Die technische Unterstützung bei einer transaktionssicheren Kommunikation ist jedoch noch nicht optimal gelöst; auch ist der Programmieraufwand nicht unerheblich. Ein Einsatz von Standardlösungen ist hier sinnvoll. Eine Verteilung der Daten in einer heterogenen Umgebung bei gleichzeitiger Anforderung von Datenkonsistenz über mehrere Datenbanken verschiedener Hersteller hinweg wird heute noch nicht unterstützt. Eine zentrale Datenhaltung auf dem Server (Host) ist hier für die nächste Zeit noch empfehlenswert..

Wer heute vor der Entscheidung steht, Anwendungssysteme auf Basis einer Client-Server-Architektur zu entwickeln, darf aber nicht nur die technischen Restriktionen und Risiken betrachten. Auch der Software-Entwicklungsprozeß selbst unterliegt Änderungen. Die Programmierer müssen sich in neue Systemumgebungen einarbeiten, und die Werkzeuge ändern sich.

Der Dialog bei einer interaktiven Benutzerführung mit Fenstern unterscheidet sich grundsätzlich von der blockweisen Übertragung vom Terminal, auf den Großrechner. Die dafür bestehenden Richtlinien sind nur bedingt Übertragbar. Anwendungsdesign und Modularisierung bestimmen den Grad der Verteilbarkeit und haben damit unter Umständen Auswirkungen auf die Leistung des Gesamtsystems.

Bei der Einführung einer Client-Server-Anwendung stellen sich zudem Fragen nach der Sicherheit in heterogenen Netzen, dem Aufbau einer systemübergreifenden Berechtigungsadministration, sowie neue Anforderungen an das Netzwerk- und Konfigurationsmanagement. Darüber hinaus sind noch einige andere wichtige Dinge zu bedenken: Ein Konzept für die Fernwartung sollte vorhanden sein, ein entsprechender Benutzerservice aufgebaut werden, die Frage des Versionsmanagements im Netz gelöst sowie Backup-Konzept und Recovery-Verfahren festgelegt und erprobt sein. Erst dann wird ein Einstieg in die neue Technologie erfolgreich möglich sein.