Der Begriff Client-Server (C/S) läßt sich allgemein als ein Modell zur Anwendungsentwicklung verstehen. Präziser formuliert, handelt es sich bei Client-Server um eine Lösung, die eine Rollen- und Aufgabenverteilung zwischen Client und Server, dem Dienenden und dem Bedienten, definiert.

Entsprechend ihrer Rollenverteilung müssen sich beide miteinander austauschen. Das heißt, der Client muß in der Lage sein, Anfragen an den Server zu richten, und dieser wiederum muß die Anfragen beantworten können. Die Qualität der Anfrage und der Antwort definiert die jeweiligen Ebenen sowie die Vor- und Nachteile von C/S-Technologien.

Die einfachste Ebene des C/S-Computing stellt - wenn auch nur aus rein akademischer Sicht - die Nutzung eines File-System-Servers dar. So ermöglicht zum Beispiel ein Netware-Server den Austausch von Dateien über verschiedene Arbeitsstationen hinweg. Der Client, die Arbeitsstation, richtet Anfragen an den Server.

Wichtig bei diesem C/S-Modell ist die Qualität der Kommunikation. Im Fall eines File-System-Servers haben sich Client und Server auf der Ebene der Dateioperation wie "Öffne Datei" oder "Lies die nächsten 500 Byte" zu unterhalten.

Die Nachteile dieser untersten Ebene des C/S-Modells kommen im Kontext von komplexeren Operationen wie zum Beispiel einer Datenbankoperation zum Tragen. Da sich das Protokoll zwischen Client und Server auf der Ebene der Dateioperation befindet, laufen erhebliche Datenmengen zwischen beiden über das Netz. Gerade im Kontext von Dbase-, Btrieve- oder Isam-Lösungen (Index- sequential Access Method) entstehen hier, verursacht durch die zunehmende Komplexität der Anwendungslösungen und eine ständig wachsende Zahl von Anwendern im Netzwerk, Performance- und Stabilitätsprobleme.

Zusätzliche Schwierigkeiten kommen bei diesen netzwerkorientierten Anwendungen dann auf, wenn eine Arbeitsstation, der Client eine Datenbankoperation nicht vollständig abarbeiten kann. Die Folge ist eventuell, daß Informationen auf seiten des Client zwar als verarbeitet gelten (zum Beispiel die Aktualisierung einer Indexdatei), die Operation auf seiten des Servers wie etwa die Aktualisierung der Datenbank aber nicht beendet ist. Da das Protokoll auf der Ebene der Dateioperation eine entsprechende Benachrichtigung an die Client-Station nicht erlaubt, sind inkonsistente Datenbestände nahezu unausweichlich.

Die Qualität einer C/S-Lösung ergibt sich folglich aus der Qualität des Protokolls. Im Fall einer Netzwerkanwendung, die die Datenbanken zentral auf einem File-System-Server verwaltet, ist die Qualität so niedrig anzusetzen, daß dieses Anwendungsmodell im allgemeinen das Attribut einer C/S-Lösung nicht erlangt.

Diese Probleme lassen sich durch eine qualitative Veränderung des Protokolls in den Griff bekommen, wie dies bei SQL-basierten Datenbank-Management-Systemen (DBMS) der Fall ist. Sie setzen sich zunehmend auch im PC-Desktop-Umfeld durch und gelten als klassische Vertreter des C/S-Modells der ersten Generation.

Dabei führt der Client seine Anfragen nicht mehr auf der Ebene der Dateioperation, sondern auf dem Level der Datenbankoperation durch (zum Beispiel: "Öffne Datenbank", "Ändere Datensatz" etc.). Die Ebene des Protokolls befindet sich nicht mehr auf der physischen Beschreibungsebene der Dateistrukturen, sondern auf einer logischen Schicht der Datenbankstrukturen.

Der Datenbank-Server ist dann für die gesamte Datenbank einschließlich der Indexdateien verantwortlich. Die Folge ist, daß die Anwendung stabiler wird und sich ein deutlicher Gewinn an Verarbeitungsgeschwindigkeit verzeichnen läßt. Denn die Menge der Informationen, die zwischen Client und Server transportiert wird, reduziert sich erheblich.

Das Implementierungsmodell einer C/S-Lösung der ersten Generation läßt sich wie folgt darstellen:

Die Client-Anwendung übernimmt mit Ausnahme von Datenbankoperationen alle Aufgaben, angefangen vom Benutzer- Interface bis hin zur Anwendungslogik und den Geschäftsregeln. Auf der Server-Seite existiert ein "intelligentes" DBMS, das die erforderlichen Datenbankoperationen auf dem nötigen Abstraktionsniveau bereitstellt. Im Rahmen von SQL-DBMS wären hier die Delete-, Insert-, Update- oder Select-Befehle zu nennen.

Die Vorteile liegen auf der Hand: Der Server führt auf der Datenbank Dateioperationen als eine geschlossene (atomare) Einheit aus und garantiert deren Erfolg. Der Ausfall einer einzelnen Client-Station kann daher nicht mehr die Integrität der gesamten Anwendungslösung gefährden.

Eine C/S-Anwendung der ersten Generation löst also zahlreiche Schwierigkeiten, die in einer expandierenden DV-Infrastruktur auftreten. Dennoch bleiben Probleme bestehen, die sich aus dem ständigen Wachstum und dem immer neuen Informationsbedarf ergeben. Das Hauptproblem ist, daß bei einer C/S-Lösung der ersten Generation die Geschäftsregeln auf seiten des Client implementiert werden müssen.

Das führt bei größeren Anwendungslösungen, die sich aus mehreren eigenständigen Programmen auf unterschiedlichen Plattformen zusammensetzen, zu Redundanzen von Quellcode. Daraus entstehen Wartungsprobleme, da jede Änderung einer Geschäftsregel die Notwendigkeit der Nachpflege eventuell mehrerer Quellcode-Basen mit den entsprechenden Kosten nach sich zieht.

Das Erweitern der Leistungsmerkmale einer Anwendungslösung führt im Rahmen eines Client-Server-Systems der ersten Generation immer zu einem Wachstum an Code und Ressourcenbedarf des Clients. Daraus folgt ein eventuelles Aufrüsten der Hardwareressourcen bei allen Client-Stationen oder gar ein Betriebssystem-Wechsel, da die Plattform die steigenden Anforderungen an eine Lösung nicht mehr trägt.

Diese ständig wachsenden Anforderungen sind mittlerweile zu einem entscheidenden Problemfaktor solcher Anwendungslösungen geworden. Für dieses Phänomen ist ein eigenständiger Begriff, "Fat Client", entstanden. Zudem erlebt bereits eine Vielzahl solcher C/S- Lösungen eine nicht mehr verantwortbare Kostenexplosion.

Diese Tatsache gehen die SQL-Hersteller durch Mechanismen wie Stored Procedures an: Geschäftsregeln, die auf dem Server implementiert sind und die dieser je nach Ereignis wie Update, Delete oder Insert ausführt. Die Vorteile sind klar: Ein Teil der Geschäftsregeln muß nur einmal implementiert werden und kann sofort allen Clients des Datenbank-Servers zur Verfügung stehen.

Das Einrichten und Testen von Stored Procedures ist in der Praxis allerdings schwierig und bisweilen nicht mit den verfügbaren Werkzeugen des Compiler-Herstellers zu bewerkstelligen. Zudem müssen sie in klassischen System- oder Hochsprachen wie C, C++, Cobol oder Rexx implementiert werden. Manche SQL-Hersteller haben ihren SQL-Servern deshalb eigene Script-Sprachen mit auf den Weg gegeben, die es ermöglichen sollen, einen besseren Integrationsgrad sowie eine bessere Wartbarkeit dieses Codes zu ermöglichen.

Betrachtet man die beiden beschriebenen C/S-Modelle genauer, so lassen sich eindeutig drei logische Ebenen oder Schichten ausmachen:

-Benutzer-Interface und Interaktionsmodell,

-Geschäfts- und Anwendungsregeln sowie

-Datenbankzugriff beziehungsweise -Management.

Im Rahmen einer Netzwerkanwendung sind alle drei Schichten auf der Client-Seite implementiert. Das C/S-Modell der ersten Generation lagert die dritte Ebene aus und überträgt die Verantwortung für die Datenbank einem "intelligenten" DBMS, das auf dem Server installiert ist. Manche SQL-Hersteller geben zusätzlich die Möglichkeit, mit Hilfe von Stored Procedures einen kleinen Teil der zweiten Schicht, die Geschäftsregeln, ebenfalls auf den Datenbank-Server und damit physikalisch an einen anderen Ort auszulagern.

Bei C/S-Lösungen der zweiten Generation hingegen werden die drei logischen Schichten einer Anwendungslösung physikalisch eins zu eins abgebildet. Dadurch haben C/S-Lösungen der zweiten Generation auch die Bezeichnungen Drei-Schichten-Modell oder Three Tier Model erhalten. Die Grundidee des C/S-Modells der zweiten Generation besteht also wiederum darin, die Qualität des Protokolls zu verbessern, mit dem Client und Server kommunizieren und sich gegenseitig Aufgaben zuteilen.

Der Client richtet in diesem Modell keine Anfragen mehr an den Server, die auf der Ebene der Datei- oder Datenbankoperation liegen. Seine Anfragen an den Server befinden sich vielmehr auf einer höheren, abstrakteren Ebene, die durch die Geschäftslogik definiert ist.

Ein Beispiel: Der Client richtet den Auftrag "Lösche Kunde Nr. 1410-65" an den Server. Der Server hat dann nicht nur den Löschvorgang, sondern auch alle damit verbundenen Prüfungen und Folgeoperationen zu veranlassen. Der Server kennt also alle Geschäftsregeln und führt diese aus.

Die Server erhalten eine neue Bedeutung

Damit erlangt die Server-Seite eine neue Bedeutung. Solche Rechner werden deshalb als Applikations- oder in einer einfacheren Form als Transaktions-Server bezeichnet. Diese Bezeichnung resultiert aus der geänderten Aufgabenverteilung.

Im Rahmen einer solchen Lösung ist auf Client-Seite nur noch das Benutzer-Interface zu implementieren. Die Anwendungslogik und vor allem die Geschäftslogik sind auf einem zentralen Server, dem Applikations-Server, implementiert.

Durch diese Form der Aufgaben- und Rollenverteilung ist es beispielsweise bei der Erweiterung einer bestehenden Anwendungslösung nicht mehr notwendig, die Client-Stationen aufzurüsten. Denn der zusätzliche Ressourcenbedarf stellt sich zum erheblichen Teil an einer zentralen Stelle, dem Applikations- Server, ein.

Ebenso ist es möglich, verschiedene Client-Plattformen kostengünstig zu bedienen, da auf der Client-Seite nur das Benutzer-Interface installiert werden muß. Eine Änderung der Geschäftsregeln läßt sich an einer zentralen Stelle realisieren, ohne daß irgend etwas an den Client-Stationen zu unternehmen wäre.

In der DV-Praxis werden Applikations-Server als sogenannte Workgroup-Server bereitgestellt. Das heißt beispielsweise, die Vertriebsgruppe hat einen lokalen Server installiert, der die relevanten Geschäftsregeln und eventuell ein "lokales" DBMS-System zur Verfügung stellt.

Workgroup-Server basieren normalerweise auf OS/2 oder Windows NT, historisch bedingt finden sich hier aber auch Unix-Derivate. Die lokalen Workgroup-Server sind mit einem DBMS-Back-end oder via Netzwerk untereinander verbunden.

Viele Wünsche sind noch unerfüllt

Die Implementierung von Applikations-Servern gestaltet sich derzeit noch aufwendig, da noch kein Baukasten bekannt ist, der es erlauben würde, solche Server schnell und effizient zu implementieren. Die einzige Ausnahme ist der von Alaska Software angekündigte "Galaxy Application Server".

In der Regel kommt derzeit eine Vielzahl von Werkzeugen zum Einsatz - meist C- oder C++-Entwicklungspakete. Diese sind mit sogenannten Middleware-Produkten wie "MQ Series" von IBM oder "EZ- RPC" von Noblenet gekoppelt, um eine plattformübergreifende Ausführung von Funktionalitäten zu gewährleisten. Auch etwas komplexere und teilweise proprietäre Ansätze über Remote-OLE, DSOM oder Transaktions-Server sind zu finden.

Wünschenswert wäre allerdings eine Art Baukasten, der fertige Schnittstellen-Modelle, Kommunikationsprotokolle, Datenbankzugriff, Synchronisation, Authentifizierung etc. anbietet, um den Anwendungsentwickler in seiner Arbeit zu entlasten.

Wer sein bestehendes Datenbanksystem mit mehr Logik, etwa Geschäftsregeln, ausstatten will, sollte über die Möglichkeit des Einsatzes von Applikations-Server-Systemen nachdenken. Daraus resultieren grundsätzlich eine verbesserte Wartbarkeit sowie Skalierbarkeit der erstellten Anwendungen und damit eine bessere Kostensituation.

Das trifft besonders auf heterogene Netzwerke zu, in denen Client- Stationen mit unterschiedlichen Betriebssystemen ausgestattet sind. Bei komplexen Anwendungen erlaubt die "natürliche" Trennung in Benutzer-Interface, Geschäftslogik und Datenbankzugriff zusätzlich eine effizientere Software-Entwicklung, da sich die verschiedenen Aufgaben eindeutig verschiedenen Entwicklergruppen zuteilen lassen.

Angeklickt

Client-Server-Systeme sind nach allgemeinem Verständnis State-of- the-Art-Anwendungslösungen, die durch leistungsfähige Client- Architekturen mit grafischen Benutzeroberflächen sowie einen oder mehrere Datenbank-Server im Back-end geprägt sind. In einschlägigen Fachpublikationen finden sich aber auch zunehmend Begriffe wie "Applikations-Server", "Three Tier Model" oder "Client-Server der zweiten Generation". Was verbirgt sich hinter diesen Begriffen, und worin liegen die Vorteile, Nachteile und Unterschiede der jeweiligen Ansätze?

Glossar

Xbase: Xbase ist eine sehr leistungsfähige Sprache, die durch ihren hohen Abstraktionsgrad und die nahtlose Datenbankintegration glänzt. Die bekanntesten Vertreter sind Dbase, Foxpro und Clipper. Leider wird Xbase meist mit den dahinterstehenden DBF-Datenbanken gleichgesetzt. Das gilt aber nicht mehr und unterschlägt sogar die wesentlichen Merkmale von Xbase wie Leistungsfähigkeit und Einfachheit der Sprache.

Btrieve: Btrieve ist ein häufig angewandtes netzwerkorientiertes Datenbanksystem, das im PC-Desktop-Bereich der wohl bekannteste reine ISAM-Vertreter (Index-sequential Access Method) war.

Isam: Die Index-Sequential Access Method steht für die beiden obengenannten Vertreter und bezeichnet das Verfahren, nach dem hier Datenbank-Management betrieben wurde.

Front-end: Im Rahmen einer Anwendungslösung ist die Schnittstelle zum Benutzer das Front-end, da es ihm gegenüber sichtbar ist.

Back-end: Als Back-end wird meist das Datenbank-Management-System verstanden, da es dem Benutzer gegenüber meist "unsichtbar" ist.

DSOM: Das Distributed System Object Model ist ein Programmiersprachen-unabhängiges Objektkapselungsmodell, das IBM, angelehnt an den Corba-Standard der Object Management Group (OMG), auf den wichtigsten Plattformen wie OS/2, Windows, AIX, OS/400 und MVS implementiert hat und anbietet.

*Steffen Pirsig ist Technischer Leiter bei der Alaska Software GmbH in Frankfurt.