In der Fachliteratur machte einst das griffige Wort vom "Fat Client" die Runde, was Client-Server-Anwendungen anbelangte. Alles, was mit dem Schlagwort "Remote Data Access" zu umschreiben war, galt als einfach zu implementieren. Der "fette Client" haelt schlicht die komplette Applikationslogik vor und greift remote auf einen Daten-Server zu. Um dies zu steuern, entwickelten sich verschiedene Arten von Middleware als Verbindungsteil zwischen dem Server und dem Client.

Die Open Database Connectivity (ODBC) zum Beispiel basiert auf Ueberlegungen einer Gruppe mit der Bezeichnung SQL Access Group (SAG). Die dort teilnehmenden Datenbankanbieter wollten Formate und Protokolle standardisieren, mit denen sich vom Client her auf alle moeglichen Datenbanken zugreifen lassen sollte. Die Unternehmen wurden sich jedoch nicht in saemtlichen Punkten einig. Gruppenmitglied Microsoft entschloss sich auf Basis der bereits vorliegenden Ergebnisse zum Alleingang und schuf die ODBC- Schnittstelle. Noch heute gilt der ODBC-Treiber als eines der ersten Middleware-Produkte, das es unter Windows-Applikation erlaubt, auf verschiedenste Datenbanken zuzugreifen.

Bald kamen immer mehr Treiber fuer Datenbankanwendungen auf den Markt. So bietet beispielsweise das US-amerikanische Softwarehaus Intersolv heute eine umfassende Produktpalette in diesem Segment an. Zusaetzlich entwickelten die DB-Hersteller proprietaere Treiber nur fuer bestimmte Client-Server-Konstellationen. Sie gelten als teilweise schneller, da sie genauer auf die spezielle Client- Server-Kombination zugeschnitten sind. Eine zweite Generation von ODBC-Treibern kann hier jedoch leistungsmaessig mithalten.

Parallel dazu entstand im Middleware-Bereich Gateway-Software, erlaeutert Franz Fasching, Technical Consultant Public Relations von CA Computer Associates. Diese Gateways gestatten es, auf Fremddatenbanken zuzugreifen. Der Applikation wird in diesem Fall vorgegaukelt, sie greife beispielsweise auf eine Oracle- Datenbank zu, obwohl die Daten in einer DB2 stehen. Das Gateway erkennt in diesem Fall, dass die Abfrage nicht an eine Oracle-Datenbank gerichtet ist, sondern an die DB2, und leitet sie entsprechend weiter: Der Request geht umformatiert an die DB2, wird bearbeitet und dann reformatiert dem Client zurueckgesandt. Fast alle DB- Hersteller fuehren Gateways im Programm - vor allem fuer Mainframe- DBs und Datenbanken des Mitbewerbs. Die Landschaft ist heterogen.

Die Auswirkungen der Fat-Client-Computing-Idee auf die Anwendungen sind vielschichtig. Bei einer Applikation mit vielen Transaktionen und kleinen satzweisen Verarbeitungen stehen viele Requests an den Server an. Jede dieser Anfragen muss ueber das Netz geleitet werden, was zu einer erheblichen Belastung fuehren kann.

Aus diesem Grunde geht der Trend zum kooperierenden Processing. Dieses Konzept beinhaltet, dass auf der Datenbankseite nicht allein ein DB-Server, sondern auch ein Applikations-Server arbeitet. Auf der Client-Seite sind benutzerorientierte Arbeiten wie das Editieren angesiedelt, die datennahe Logik liegt auf der Server- Seite.

Services sind Teil der Infrastruktur

Bei Remote Procedure Calls (RPCs) liegt die vom Client aufzurufende Funktion auf einem Server. Die Open Software Foundation (OSF) hat hierzu das Konzept des Distributed Computing Environment (DCE) vorgelegt. Es bildet eine Infrastruktur, in der die entsprechenden Services enthalten sind, um sinnvoll RPCs zu fahren.

Einige Anbieter entwickelten Loesungen, bei denen die Datenbank- Server von RPC-Logik freigehalten werden. Sie schufen Datenbankprozeduren, die heute in allen gaengigen relationalen Datenbank-Management-Systemen (DBMS) verfuegbar sind. Eine "Stored Procedure" etwa ist prozeduraler Code, der ueber Trigger oder von einem Programm aus als Funktionsaufruf angesteuert werden kann. Der urspruengliche Fat Client wird durch Auslagerung entlastet. Auch hier dominieren proprietaere Loesungen, da keine Normierungen vorliegen. Sie sind auch in den naechsten zwei bis drei Jahren nicht zu erwarten, heisst es in der Szene.

RPCs laufen synchron ab. Seit geraumer Zeit wird darueber diskutiert, ob nicht ein asynchrones Verfahren sinnvoller waere. Ein Weg hierzu sind Message Oriented Methods (MOMs). Sie stellen als Client eine Anfrage in die Warteschleife des Servers, der sie dann sukzessive abarbeitet.

Objektorientierte Alternativen

Parallel zu den traditionellen relationalen Verfahren entwickelten sich objektorientierte Ansaetze. Bei ihnen steht die Idee der Kapselung im Vordergrund, die sowohl Funktionalitaet als auch die entsprechenden Datenzugriffe in sich birgt. "Client-Server und Objektorientierung beissen sich ueberhaupt nicht", meint dazu Georg Heeg, Inhaber der Georg Heeg Objektorientierte Systeme aus Dortmund. Auch ein Objekt koenne quasi als "Mini-Server" aufgefasst werden. Zu klaeren ist dann aber, welche Objekte auf dem Client und welche auf dem Server angesiedelt werden muessen. Heeg fuehrt drei Kriterien an. Als wichtigstes nennt er Datenschutz und technische Sicherheit. Sensible Objekte in dieser Beziehung sind auf dem Client fehl am Platze. Nach dem zweiten, dem Volumenkriterium gehoeren vor allem umfangreiche Objekte auf den Server. Drittens sollten alle gleichzeitig von verschiedener Seite zu nutzenden Objekte auf dem Server gelagert sein.

Mit der gesamten Thematik befasste sich sehr frueh die Object Management Group (OMG). Sie entwickelte den Standard Common Object Request Broker Architecture (Corba). Dieses Konzept basiert auf der Idee des Brokers: Er weiss, wo sich die Objekte physikalisch befinden und wie sie angesprochen werden. "Man koennte dies von der Vorgehensweise her mit einem Unternehmen mit Durchwahltelefon vergleichen", vergleicht Heeg. Wisse der Anrufer, welchen Teilnehmer (Objekt) er wuenscht, ist die direkte Durchwahl die schnelle Methode, ansonsten dient die Telefonzentrale mit einer Weiterleitung.

Der Client hat in verschiedenen Schichten lokal und im Netz derartige Object Broker zur Verfuegung, und wenn mit einem solchen Objekt ueber einen Funktionsaufruf gearbeitet werden soll, dann suchen und finden es die Broker. In dieser Architektur muss der Client nicht unbedingt der Front-end-Client sein, auch ein Server kann innerhalb einer solchen Architektur als Client fungieren.

Relationale und objektorientierte Methoden konkurrieren insofern nicht, meint CA-Mitarbeiter Franz Fasching, als sie auf verschiedenen Philosophien beruhen. Die Entscheidung fuer eines der Paradigmen muss grundsaetzlich im Rahmen des Gesamtkonzeptes fallen, erst dann steht die Frage nach der notwendigen Middleware an.

Bei RPCs kann es sein, dass je nach Anwendung noch sehr viel selbst programmiert werden muss.

Software-Ingenieure, die in den letzten Jahren von den Hochschulen kamen, sind durch ihr Studium objektorientiert ausgerichtet. Praktiker, die jahrelang prozedural gearbeitet haben, sehen zwar die Vorteile der Objektorientierung, erkennen aber gleichzeitig die Problematik einer Umstellung. Das von ihnen praktizierte strukturierte Vorgehen bedingt eine ganz andere Denkweise.

Der Weg vom prozeduralen zum objektorientierten Denken ist nicht ganz einfach. "Prinzipiell schafft der Entwickler in beiden Vorgehensweisen Modelle der realen Welt, die auf dem Computer abgebildet werden", erlaeutert Heeg. Konzeptionell steht auf der einen Seite eine DV-technische, auf der anderen Seite eine begriffliche Sicht. Die begriffliche Sicht existiere voellig unabhaengig davon, ob sie DV-technisch konventionell oder objektorientiert realisiert werde. Bei der objektorientierten Vorgehensweise aber entstehe - so Heeg - wenn sie gut gemacht sei, "eine Eins-zu-eins-Abbildung der begrifflichen Sicht", waehrend die konventionelle Vorgehensweise dies nur annaeherungsweise vollbringe.

Fuer diese Begrenzung sei die Trennung von Funktion und Information verantwortlich. Ein Datum ohne funktionalen Bezug sagt ebensowenig aus wie ein Vorgang ohne Daten.

Deutliche Vorteile bringt Objektorientierung Experten zufolge, wenn groessere Datenaenderungen vorzunehmen sind. Betreiber konventioneller Datenbanken hatten - die Presse berichtete ausfuehrlich - beispielsweise mit der Postleitzahlen-Umstellung hart zu kaempfen.

Bei einer Umstellung auf die objektorientierte Vorgehensweise ist eine ausgefeilte Migrationsstrategie vonnoeten. Die Mitarbeiter muessen weitergebildet werden, und es muessen Bereiche im alten System abgegrenzt werden, die sich fuer einen Umstieg besonders eignen und die daher zuerst umgestellt werden sollten.

Kurz & buendig

"Fat Clients" halten die Applikationslogik vor und greifen remote auf die Daten-Server zu. Zur Verbindung von Client und Server entwickelten sich verschiedene Middleware-Techniken. Hierher gehoert die Open Database Connectivity (ODBC). Der Middleware- Auswahl muss jedoch die Entscheidung zwischen herkoemmlicher relationaler und objektorientierter Datenbanktechnik vorausgehen. Client-Server-Loesungen vertragen sich auch mit objektorientierten Datenbanken. Ein Objekt kann quasi als "Mini-Server" betrachtet werden.

*Horst-Joachim Hoffmann ist freier Fachjournalist in Muenchen.