Es gibt derzeit nur wenige Produkte, von denen nicht behauptet wuerde, sie unterstuetzten Client-Server-Verarbeitung. Bei Licht betrachtet, verfluechtigen sich die Versprechungen der Hersteller jedoch oftmals ebenso wie der Nebel im Sonnenschein. Dennoch gibt es interessante Ausnahmen. Dieser Bericht und die nachfolgende Marktuebersicht sollen als Orientierungshilfe dienen.

Von Johann Baumeister*

In der Datenverarbeitung lassen sich mindestens drei Verarbeitungsvarianten separieren, die aber nicht alle dem Client- Server-Prinzip entsprechen:

- Terminalemulation: Beim traditionellen Ansatz der Grossrechnertechnik und bei zeichenbasierenden Unix-Anwendungen existiert die Aufteilung in verschiedene Komponenten nicht. Die Programme laufen vollstaendig in der Umgebung des Zentralrechners und haben Datenzugriff, Applikationslogik und Praesentation an allen Stellen im Code verwoben. Die Praesentation erfolgt durch dumme Terminals oder PCs mit Terminalemulationen. Viele der Host- basierenden Abfragewerkzeuge oder Reportgeneratoren sind hier anzutreffen. Der Gedanke von Client-Server-Verarbeitung ist dieser Kategorie fremd.

- Remote Presentation: Hier erfolgt die Visualisierung der Daten auf einem intelligenten Geraet (PC, X-Terminal). Die Applikations- und Datenzugriffslogik werden auf dem Server abgearbeitet. Dieses Konzept unterstuetzen zum Beispiel PC-basierte Werkzeuge fuer Abfrage oder Reports, die die Daten in der Regel grafisch ansprechender aufbereiten.

- Remote Data Management: In der naechsten Stufe verbleibt nur noch der Datenzugriff auf dem Server. Praesentation und unter dem Einsatz von Standard-Middleware auch ein Grossteil der Verarbeitung erfolgen auf dem Client.

In traditionellen Programmen (3GL, SQL) besteht eine Anwendung haeufig aus einer Sammlung von einzelnen Routinen (Funktion, Subroutine, Unterprogramm). Die Entscheidung ueber die Struktur der Anwendung - und damit die Bildung von Unterprogrammen - wurde haeufig nach den Vorstellungen der Entwickler getroffen.

Programme in einzelne Module aufteilen

Als allgemeine Regel lehrte man jahrelang: "Wenn ein bestimmter Code mehrmals benoetigt wird oder spaeter wiederverwendet werden kann, so bilde eine Subroutine." Ziel war die Reduzierung von Sourcecode und Entwicklungsaufwand.

Dieser Ansatz ist sicherlich nicht falsch. Wenn modulare und portable Anwendungen fuer Client-Server-Umgebungen entwickelt werden sollen, ist es jedoch angebracht, ein Programm nach Benutzer-Schnittstelle, Datenbankzugriff und Applikationslogik aufzuteilen.

Jedes der Module laesst sich in kleinere Bestandteile zerlegen. So wird beispielsweise die Praesentation der Daten haeufig in User- Interface-(UI-)-abhaengig und -unabhaengig aufgeteilt.

Hinter der Applikationslogik verbergen sich die grundlegenden Regeln und Vorgaben des Programms. Der Part Datenzugriff sorgt dafuer, dass die Datenbestaende gefunden und gespeichert werden. Hier ist festzulegen, ob die Daten lokal gehalten werden oder der Zugriff durch den Einsatz von Middleware auf eine entfernte Datenbank erfolgt. Dabei sind noch die Sonderformen der verteilten Datenhaltung (Distributed Database) oder replizierte Datenhaltung zu unterscheiden.

Die Aufteilung in mehrere Bausteine hat enorme Vorteile: Es ist fuer den verarbeitenden Anteil (Applikationslogik) einer Anwendung unerheblich, wie die Ausgabe realisiert ist - ob ueber MS-Windows, X-Windows, Motif, Macintosh, einem X-Terminal, grafisch, zeichen-, zeilen- oder blockorientiert, auf einem lokalen Bildschirm oder uebers Netz etc. Ebensowenig spielt es eine Rolle, woher die Daten kommen und wie sie im Datenbanksystem gespeichert sind.

Fuer die Entwicklung von Client-Server-Umgebungen werden eine Vielzahl von Produkten angeboten, fuer deren Klassifizierung es mehrere Moeglichkeiten gibt: die Hard- oder Software-Umgebung, die Zielgruppe, die Problemstellung, die Methodik (3GL, 4GL, 5GL, prozedural, ereignisorientiert, objektorientiert) etc. Bei allen Betrachtungen muss nach den Produktklassen Back-end-Datenbank, Kommunikations-Middleware sowie Entwickler- oder Benutzer-Front- end unterschieden werden. Jede dieser Gruppen laesst sich noch weiter differenzieren.

Dabei ist die Vielfalt der Front-end-Werkzeuge sicherlich am groessten. Sie koennen grob in Endbenutzerwerkzeuge mit keiner oder nur wenig Programmierung und in Werkzeuge fuer den Entwickler eingeteilt werden. Neben Abfragewerkzeugen und Reportgeneratoren zaehlen Management-Informations-Systeme zu den Programmen des Anwenders.

Abfragewerkzeuge: Wenn hier von Client-Server die Rede ist, wird stets vorausgesetzt, dass eine Datenbank involviert ist. Sicher benoetigt man nicht fuer alle Belange echte Client-Server- Verarbeitung. Haeufig genuegt auch ein einfacher Berichtsgenerator oder ein Query-Werkzeug. Eine Query ist eine Abfrage an das Datenbanksystem. In ihrer Definition wird versucht, das Problem zu beschreiben und nicht den Loesungsweg. So zum Beispiel im SQL- Aufruf "select Kunde from Kundenstamm where kundenort = Muenchen". SQL (Structured Query Language) ist ein Vertreter von Query- Sprachen par excellence. Die meisten Midrange- und Mainframe- Datenbanken unterstuetzen mittlerweile SQL-Databases durch Kommandozeilen, so dass bei dieser Gruppe SQL als kleinster gemeinsamer Nenner zu betrachten ist.

Bei der Konzeption von SQL stand daher der Abfragecharakter im Mittelpunkt. Der Benutzer wurde damit erstmals befaehigt, eigene Auswertungen ohne Programm-Know-how oder aequivalente Kenntnisse zu erzeugen. Er muss "lediglich" die SQL-Syntax sowie die Namen der Tabellen, Felder etc. kennen und anwenden koennen.

Datenbankabfrage mit Dialogunterstuetzung

Einfacher wird es, wenn der Anwender die benoetigten Parameter aus Auswahllisten zusammenstellt und so seine Abfrage aufbaut. Statt "... from Kundenstamm" einzutippen, erhaelt er nun eine Auswahlbox mit den Namen aller Tabellen (= Satztypen) und selektiert die gewuenschte Tabelle. Gleiches gilt fuer die Felder (= Spalten) und die Relation (=, >, < etc.). Haeufig wird in einem zweiten Fenster die korrespondierende SQL-Syntax eingeblendet.

Nach wie vor muss der Benutzer allerdings die Namen seiner Felder und Tabellen kennen. Und nicht immer sind diese so aufschlussreich wie in diesem Beispiel. Ein logischer Schritt ist es, hier Aliasnamen zu vergeben. Das Einrichten kann uebrigens auch durch einen Administrator vorgenommen werden, der den detaillierten Aufbau der Datenbank mit all ihren Feldern und Tabellen kennt. Beispiele fuer Abfragewerkzeuge mit Dialogunterstuetzung sind "Intersolv Q+E Database-Editor" (Intersolv, vormals Q+E), "Powerviewer" (Powersoft), "Quest" (Gupta) oder "CA-Qbyx" (Computer Associates).

Management Informations Systeme (MIS): MIS lassen sich gewissermassen als eine spezielle Variante von Abfragesystemen mit programmierbaren Ausgaben ansehen. Der Benutzer wird in die Lage versetzt, Daten aus verschiedenen Perspektiven zu betrachten und in Relation zueinander stellen. Dabei ermoeglichen sie die Konzentration auf das Wesentliche. Werte lassen sich dynamisch in Gruppen zusammenfassen (Konsolidieren) oder bezueglich ihrer Herkunft verfolgen (Drill-down).

Dies geht weit ueber die Moeglichkeiten von Kalkulationsprogrammen mit ihren "Was-waere-wenn"-Verfahren hinaus. Neben den Begriffen MIS und EIS (Executive Information Systems) taucht mittlerweile ein neuerer Terminus auf: Business Intelligence Software. BIS- Werkzeuge sind Standardprodukte mit EIS-Funktionalitaet. Anders als diese erfordern sie allerdings keine Programmierung. Dahinter steckt die Erkenntnis, dass die Einfuehrung von herkoemmlichen EIS- beziehungsweise MIS-Instrumenten immer mit Entwicklungsaufwand einhergeht. Verbunden damit hinken die erstellten Loesungen den Anforderungen in der schnellebigen Geschaeftswelt immer hinterher. Einige gaengige BIS- beziehungsweise MIS-Produkte sind: "Forest & Trees" (Trincicz), "Lightship" (Pilot Software), "Focus" (Information Builders) oder "Powerplay" (Cognos).

Sollten Abfragen regelmaessig benoetigt werden, macht es Sinn, deren Definitionen zu speichern und bei Bedarf wieder abzurufen. Damit kommen wir zum Feld der Reportgeneratoren (Berichtsgenerator).

Reportgeneratoren: Ihr Einsatzzweck liegt im Erzeugen von Berichten. Dabei werden haeufig auch weiterfuehrende Informationen oder komplexere Ablaeufe benoetigt, als von den Abfragewerkzeugen bereitgestellt werden. Die Berichtsgeneratoren sind in jedem Fall programmierbar und enthalten eine Makrosprache oder aehnliches. Auch lassen sich damit weitaus komplexere Listen erstellen, als dies mit den Abfrage-Tools moeglich ist. So eignen sich manche Vertreter dieses Genres auch fuer Aufgaben wie das Schreiben von Formbriefen, das Drucken von Adressaufklebern oder Rechnungen.

Fliessender Uebergang zwischen den Tools

Verfuegbar sind Berichtsgeneratoren in verschiedenen Auspraegungen. Benoetigen die erzeugten Berichte das steuernde Programm als Runtime-Umgebung, muss es auch beim Anwender vorhanden sein. Andernfalls sind als Ergebnis ausfuehrbare Programme (EXE-Dateien) erforderlich. Eine weitere Variante ist es, den Generatorcode zusammen mit der eigenen Anwendung in DLLs zu packen, die sich von den meisten der verfuegbaren Windows-Applikationen aufrufen lassen. Ein entsprechendes Produkt ist zum Beispiel "Win QL" von Data Access.

Eines jedoch tun Berichtsgeneratoren nicht: Sie fuehren keine Aenderung an den Datenbestaenden durch, sondern bieten nur Hilfe beim Auswerten und beim Listenaufbau. Der Uebergang zwischen den Tools allerdings ist fliessend. Von daher ist die hier vorgenommene Einteilung nur als grober Richtwert zu betrachten. Oben erwaehnter Intersolv Q+E Database Editor ist zum Beispiel auch in der Lage, Daten zu veraendern.

Unter die Rubrik der Reportgeneratoren fallen beispielsweise "Crystal report" (Crystal Services), "Report Smith" (Borland), "Quest" (Gupta) oder "Impromptu" (Cognos).

Diese Werkzeuge sind allerdings nicht fuer den Endbenutzer gedacht, sondern gehoeren in die Hand des Entwicklers.

Damit sind wir bei der Gruppe der Entwicklungswerkzeuge: Hier ist das Angebot um ein Vielfaches komplexer. Der Trend zu 4GL-, 5GL- und objektorientierten Werkzeugen ist unverkennbar. Die Produkte dieser Kategorie kombinieren haeufig Tools zum interaktiven Aufbau der Oberflaeche (Interface Builder) mit Generatoren fuer Reports und Menues sowie einer Programmiersprache. Bei Anwendungen neueren Datums treten allerdings die Module Menuegenerator und Maskengenerator in den Hintergrund, was darin begruendet liegt, dass sich die Architektur moderner Applikationen nicht einfach in einen Menue- und Maskenbaum pressen laesst.

Der Entwickler erstellt in einem ersten Schritt die Oberflaeche und bindet den benoetigten Code daran. Das Programmiermodell ist ereignisgesteuert (event driven). Produkte, die sich hier einen Namen gemacht haben, sind "SQL Windows"

(Gupta), "Powerbuilder" (Powersoft), "Enfin" (Easel) oder als Low- end-Produkt "Visual Basic" und "Access" (Microsoft). Einige weitere besondere Features bieten beispielsweise:

- "Open Insight" von Revelation Technologies, das ein Repository beinhaltet;

- "Visual Works" von Parcplace, das vollstaendig auf Smalltalk basiert;

- "Uniface" von Uniface, das viele Betriebssysteme und zudem mehrere Oberflaechen unterstuetzt, sowie

- "Progress" von Progress mit seinem hohen Portabilitaetsgrad.

Da fuer 5GL-Sprachen noch kein Standard existiert, implementiert jeder Hersteller eigene Dialekte. Sie sind im allgemeinen nicht so flexibel und performant wie 3GL-Sprachen. Daher, und um vorhandenen Code weiterzuverwenden, besitzen die Entwicklungsumgebungen Schnittstellen fuer externe Routinen. In Windows- und OS/2-Umgebungen sind dies die DLLs (Dynamic Link Libraries).

Middleware: Eine zentrale Rolle bei verteilten Systemen nimmt die Middleware ein. Dieser Begriff hat sich mittlerweile fuer die Kommunikationssoftware herausgebildet. Middleware ist jedoch mehr als nur reine Netzwerksoftware.

Sie bewaeltigt auch Aufgaben, die die Anwendung entlasten: So stellt sie beispielsweise bei verteilten Datenbanksystemen das Transaktionskonzept bereit. Zudem werden Applikationsanforderungen den im Netzverbund bestehenden Datenquellen zugeordnet. Vereinfacht ausgedrueckt, muss ein Anwendungsprogramm nicht wissen, wo die von ihm bearbeiteten Informationen liegen oder wie deren Struktur aussieht.

Auch wenn der Middleware bisher wenig Bedeutung zugekommen ist, darf nicht uebersehen werden, dass sie die Basis jeglicher Client- Server-Verarbeitung darstellt. Wie sonst sollen sich Programme in unabhaengige Bausteine trennen lassen, wenn keine zuverlaessige Kommunikations-Schnittstelle zwischen ihnen existiert.

Als ein Standard fuer die Anbindung von Windows-PCs hat sich mittlerweile ODBC (Open Database Connectivity) etabliert: ein einheitliches Interface fuer die Kommunikation mit der Datenbank beziehungsweise dem Entwicklungs- oder Front-end-Werkzeug. Beim Zugriff und der Manipulation der Daten unterstuetzt es den Standard SQL. ODBC wird fuer alle gaengigen Datenbanken und eine Vielzahl von Front-ends angeboten. An einer Portierung auf Unix wird gearbeitet.

Eine Reihe von Herstellern bietet ODBC-Treiber an, die ohne spezielle Netzwerksoftware der Datenbankanbieter operieren - etwa "Open Link" von Diva, Nuernberg -, was zu niedrigeren Kosten und weniger Installationsaufwand fuehrt.

Einen aehnlichen Weg beschreitet SNI mit "Database-Access". Auch SNI ermoeglicht die Anbindung von entfernten Datenbanken wie beispielsweise Sesam und UDS ohne weitere Netzsoftware. Techgnosis hat mit "Seque Link" schon in der Vergangenheit eine Palette von Datenbanken im Zugriff. Durch deren neugeschaffene ODBC-Schicht bietet der Hersteller nun Anschluss zu Unix, AS/400, MVS, VAX/VMX und VM. Die ODBC-Komponente fungiert hierbei als Mittler zwischen dem Seque-Link-Gateway und der ODBC-Applikation.

Mit der "Database Library" von Q+E bietet Intersolv eine DLL mit einer Sammlung von Funktionen. Diese sind, analog der DLL- Spezifikation, von jedem DLL-faehigen Produkt anzuwenden.

Als Kommunikationskomponente wird dabei auf den eige-

nen ODBC-Treiber aufgesetzt. IBMs Beitrag zur Middleware,

"DRDA", sollte beim Zugriff auf Mainframe-Datenbanken in Erwaegung gezogen werden. Daneben existieren Gateways von diversen Herstellern (etwa EDA/SQL).

GUI-Builder: Eine weitere Klasse von Werkzeugen sind die Interface Builder. Je nach Produkt erlauben sie die Definition von portablen Oberflaechen. Die Programme lassen sich dann, ohne Neucodierung, auf andere Oberflaechen uebertragen. Je mehr GUIs unterstuetzt werden, desto besser ist dies natuerlich fuer einen spaeteren Einsatzzweck. Umgekehrt kostet ein solch universelles Vorgehen Laufzeit oder ist haeufig nicht auf die letzten Neuerungen abgestimmt.

Mit "Open UI" (Open Software Associates) beispielsweise lassen sich Applikationen ohne Aenderungen am Code zwischen Unix- Plattformen, OS/2, Windows, dem Macintosh und ASCII-Terminals uebertragen. Die Programmierung kann mit C, C++, Ada oder Pascal durchgefuehrt werden. Einige weitere Produkte sind "iX Build" (Ixos), "XVT" (XVT Software), "Dialog Manager" (ISA), "Grit" (Gft), "JAM" (JYACC), "Tele Use" (Telesoft) oder die "Zinc Application Framework" (Zinc Software). Neue Ansaetze: Nach den Client-Server-Tools der ersten Generation folgen nun Programme, die auch den Aufbau von verteilten Applikationen ermoeglichen. Ein anderer Ansatz besteht darin, die Benutzeranwendung aus der Kombination bestehender Module, gepaart mit wenig Eigenentwicklung, zusammenzustellen. "Axiant" (Cognos), "Visual Appbuilder" (Novell), "Team Enterprise Developer" (Symantec) oder der Appbuilder "Delphi" (Borland) zaehlen zu den neuesten Vertretern.

Softwarebus als Kommunikationsbasis

Diese Component-Ware-Produkte beruhen auf dem Gedanken, dass die Anwendungen der Zukunft nicht mehr monolithische Programme sein werden, sondern vielmehr eine Kombination kleiner und flexibler Software-ICs. Eine Appware-Applikation besteht demnach aus der Kombination von vorgefertigten Bausteinen, den Appware Loadable Modules (ALM), die ueber einen Software-Bus, den Appware, kommunizieren. Aehnlich einem Hardware-Bus, der Signale zwischen den Hardwarekomponenten uebertraegt, fungiert dieser Bus als Verbindung zwischen seinen Stationen, den ALMs.

Das Augenmerk sollte bei der Auswahl geeigneter Produkte auch auf folgende Aspekte gerichtet werden: Welche Plattformen (Betriebssystem, Hardware) unterstuetzt das Werkzeug? Koennen mehrere Entwickler parallel im Netz arbeiten? Enthaelt das Tool Hilfen zum Projekt-Management oder zur Versionskontrolle? Gehoert ein Repository oder zumindest ein Data Dictionary zum Produktumfang? So unterstuetzen zum Beispiel "Team Windows" (Gupta) oder "PVCS" (Intersolv) das Projekt-Management durch Versionskontrollsysteme. Auch Data Dictionaries oder Repositories (zum Beispiel bei "Open Insight") finden Einzug in die Entwicklerpakete.

Fuer die Auswahl eines Tools ist der Einsatzzweck wichtig. Sollen eine Applikation neu erstellt, die existierenden Host- Datenbestaende aber beibehalten werden, laesst sich das mit Tools bewerkstelligen, die Remote Presentation oder Remote Data Management unterstuetzen. Sind jedoch leistungsschwache Geraete (PCs mit 286- oder 386SX-CPU und 2 MB RAM) im Einsatz, wird das Modell des Remote Data Management in der Regel ausscheiden, denn ein Grossteil der Verarbeitung erfolgt auf dem Anwendergeraet - was gleichzeitig die zentrale Server-Station entlastet.

Die oben und in der Marktuebersicht erwaehnten Tools erheben nicht einmal annaehernd den Anspruch auf Vollstaendigkeit. Aufgrund der grossen Zahl der Produkte ist das auch nicht moeglich. Vielmehr wurde versucht, jene Produkte mit einzubeziehen, die entweder eine grosse Verbreitung im Markt besitzen oder quasi als Prototyp fuer die jeweilige Rubrik betrachtet werden. Darueber hinaus sollten hoffnungsvolle neue Ansaetze, also Tools der zweiten Generation, Beachtung finden.