Je vollmundiger die Versprechungen zum Client-Server Computing klingen, um so mehr entlarven sie ihre Autoren: Ihnen dient das vielbeschworene Schlagwert oftmals allein dazu, über die schwierigen Schritte zur anwenderfreundlichen Informationstechnologie kühn hinwegsehen zu können. Wer derzeit von Client-Server spricht, beschreibt nichts als den Idealfall.
Das Ideal ist gekennzeichnet durch einen Client, dessen Nachfrage nach Informationen (Daten) oder Rechenprozeduren im Rahmen seiner Arbeit mit dialoggesteuerten Applikationen vom DV-System problemlos verstanden und wunschgemäß beantwortet wird.
Daß dieser Idealfall noch weit entfernt liegt, zeigt die DV-Realität allerorten: Die Anwendung muß, obwohl dies eigentlich nicht zu ihren Aufgaben als Client gehört, die Begrenzungen und inkonsistenten Verhaltensmuster des DV-Systems antizipieren und auf sie steuernd einwirken, um die gewünschten Dienstleistungen auch zu erhalten. Der Client, gleichsam der Kunde im Endbenutzerbereich, ist demnach vom informationstechnologischen Service her noch lange nicht König, wie es das Sprichwort zu Recht verlangt.
Skeptische Gemüter verstehen Client-Server-Computing weniger als starres Ziel, sondern eher als eine Wegbeschreibung von einer meist zentralen DV zu einer anwenderorientierten DV-Architektur. Die gewaltige Realisierungslücke, die zwischen beidem klafft, läßt sich in folgendes Bild fassen: Will der DV-Client eine Datenbankabfrage starten, so ist dies heutzutage vergleichbar mit dem Besucher eines Restaurants, der ein Menü bestellt und dazu der Bedienung das Rezept samt Kochanweisung diktieren muß.
Der Kunde innerhalb einer funktionierenden Client-Server-Architektur entspräche demgegenüber einem Gast, der sein Menü von der Speisekarte wählt und sich danach nicht mehr darum sorgen muß, ob auf seine Bestellung auch eine genießbare Mahlzeit folgt. Überträgt man dies auf die Situation in komplexen DV-Architekturen, so behindert gleichsam das Fehlen einer eindeutigen "Menükarte" sowie allgemeinverbindlicher Regeln zur Erfüllung einer "Bestellung" die eigentliche Aufgabenbearbeitung des Endanwenders.
Anwender verfügen nur über rudimentäre Hilfen
Die Vision vom Client-Server-System darf somit nicht darüber hinwegtäuschen, daß dem Anwender als Client bislang nur rudimentäre Hilfen wie Remote Procedure Calls über die zahlreichen Stolperstellen hinweghelfen, die beispielsweise bei Datenbankabfragen mit verteilten Daten auftreten.
Daß mit dem Aufbau von Client-Server-Architekturen eine Erhöhung der Endbenutzer-Produktivität erzielt werden kann, ist gleichwohl unstrittig. Client-Server soll den Einsatz von dialogorientierten, interaktiven Applikationen mit grafischer Benutzerführung auf PCs oder Workstations ermöglichen und damit die dialogfeindlichen Terminal-Emulationen ablösen.
Bedenkt man, daß herkömmliche Terminals hauptsächlich deshalb mit äußerst knapper Funktionalität ausgestattet sind, um möglichst wenig Mainframe Leistung in Anspruch zu nehmen, so sind die hardwareseitigen Voraussetzungen des benutzerfreundlichen Computings vergleichsweise problemlos zu realisieren. Am Standort des zukünftigen Clients muß zusätzliche Prozessorleistung installiert werden. Leistungsstarke und zunehmend preiswerte PCs beziehungsweise Workstations können die diesbezüglichen Bedürfnisse schon heute weitgehend befriedigen. Wesentlich komplexer und problematischer stellt sich die Lage bei der serverseitigen Umsetzung der Client-Server-Vision dar: Denn dort muß eine weitläufige, heterogene Hardwarelandschaft über Netzwerke miteinander verbunden und integriert werden.
Da die Migration zu offenen Systemen hier nur sukzessive erfolgen kann, müssen die neuen Applikationen auf der Client-Seite notgedrungen zunächst mit den vorhandenen alten Datenbeständen zusammengeschaltet werden. Erst allmählich können diese Datenbestände dann auf moderne relationale Datenhaltungs- und -Management Systeme umgestellt werden.
Für die Programmentwickler ergibt sich hieraus die Maxime der größtmöglichen Adaptierbarkeit der grafikfähigen Anwendungen für verschiedene Systemumgebungen in bezug auf die Datenabfrage, -berechnung und -präsentation. Die Konsequenzen dieser allseitigen Flexibilität sind einschneidend:
- Wurde bislang für alphanumerische Terminals satzorientiert entwickelt, muß für die grafischen Multi-Window-Oberflächen auf PCs und Workstations mengenorientiert programmiert werden.
- Um nicht mehr prozedural, sondern ereignisorientiert entwickeln zu können, benötigt der Applikationsdesigner eine Entwicklungs- und Sprachumgebung; herkömmliche Window-Tool-Kits, die an die tausend Einzelfunktionen beinhalten, sind für hochstrukturierte Vorgehensweisen zu unübersichtlich.
- Um in bezug auf Änderungen in den Datenbeständen flexibel genug zu sein, muß die eingesetzte Sprachumgebung die dynamische Gestaltung des Fenster-Designs im Verhältnis zu den jeweiligen Datenmengen erlauben. Die endgültige Größe und das Layout der Fenster oder einzelner Display-Objekte wird damit erst zur Laufzeit festgelegt.
(wird fortgesetzt)
*Wolfgang Ziekursch ist Leiter Produkt Management bei der Ingres GmbH.