Nach einer Erhebung, die im Auftrag der IBM bei 2700 europaeischen Unternehmen durchgefuehrt wurde, haben bereits sehr viele Anwender die Weichen in Richtung Client-Server gestellt. Danach setzt knapp ein Drittel diese Technologie in irgendeiner Form ein. Darueber hinaus befinden sich laut Studie 17 Prozent in der Implementierungs- und 14 Prozent in der Pilotphase ihres Client-Server-Projekts; 22 Prozent planen den Umstieg.

Konterkariert werden solche Einschaetzungen und Erhebungen durch erste Erfahrungswerte mit der C/S-Technik. So hat die Sound View Financial Group herausgefunden, dass die Realisierung aller wesentlichen Felder innerhalb der C/S-Technik (System-Management, Komplexitaet, Sicherheit, Konfiguration, Software-Einsatz, Recovery, Werkzeuge, Kosten, Backup, Distributed Storage) bis auf das Backup 1995 im Vergleich zum Vorjahr als schwieriger erachtet wird. In das gleiche Horn stoesst Trend Research mit einer Untersuchung, die 172 Client-Server-Anwender umfasst. Bei 81 Prozent kam es zu deutlichen Terminverzoegerungen, 73 Prozent hatten Probleme mit dem Netzwerk, 68 Prozent beklagten mangelndes internes Know-how, 67 Prozent unerwartet hohe Kosten, 64 Prozent eine unzureichende Ressourcen-Planung und immerhin 62 Prozent Probleme bei der Integration in bestehende Infrastrukturen.

Das Marktforschungsinstitut Ovum hat wiederum herausgefunden, dass die neue Technik in puncto Funktionalitaet bisher hinter den Erwartungen zurueckblieb. Das gilt fuer so verschiedene Punkte wie Effektivitaet, den Zugriff auf Daten, die Flexibilitaet, den Einsatz neuer Anwendungen, Skalierbarkeit des Netzes, Hardwarekosten oder die Kontrolle ueber die PC-Benutzung.

Komplexitaet wird sehr oft unterschaetzt

Wieso driften Erwartungen und Realitaet auseinander? Genauer besehen ist Client-Server keine Technik, sondern lediglich ein Konzept, das erst einmal in Technik umgesetzt werden muss. Kraeftig unterschaetzt wird bereits die Komplexitaet dieses Vorhabens. Immerhin geht es darum, fuer eine durchgehende Programm-zu- Programm-Kommunikation unterschiedliche Hardwareplattformen wie Mainframes, Unix-Server, Gateways und PCs mit meist unterschiedlichen Datenformaten einzubeziehen, verschiedene Datenbanksysteme einzubinden und auch noch unterschiedliche Protokollwelten bei der Programmentwicklung zu beruecksichtigen.

Letztendlich muss sich der Anwender bei der Realisierung seines Projekts auf alle Ebenen des Netzwerks konzentrieren: von der Verkabelungs- ueber die Netzwerkkomponentenebene bis hinauf zur Anwendungsschicht. Anbieter, die Client-Server nur als Hardwarekonfigurationskonzept herausstellen, das lediglich die Verbindungsstrukturen zwischen PCs und Server-Systemen definiert, koennen dieser Anforderung ebensowenig gerecht werden wie Software- Anbieter, die in diesen Projekten vornehmlich eine anwendungsspezifische Herausforderung waehnen. Client-Server ist mehr. Es handelt sich um eine komplexe Schnittstellen- und Software-Architektur, die es erlaubt, Anwendungen und Daten zwischen verschiedenen Systemplattformen zu verteilen.

Unterschaetzt werden meist die Probleme, die mit der Verteilung von Daten und Anwendungen einhergehen. Parallele Verarbeitungsprozesse wollen beherrscht sein.

Das ist bei der Komplexitaet der Wechselbeziehungen zwischen den einzelnen Systemen mit ihren Reaktionsmoeglichkeiten und eventuellen Fehlersituationen keine leichte Aufgabe. Zudem fehlen angemessene Systemwerkzeuge, um die Verteilung zu meistern und parallel eine uebergreifende Transaktionssicherheit im Verbund zu gewaehrleisten. Insbesondere die Softwareverteilung im Netz ist nur ueber Konfigurations-Management und eine daran gekoppelte Bestandsverwaltung moeglich. Doch die vorherige Erfassung von Hard- und Softwarekomponenten sowie -lizenzen kann viel Zeit in Anspruch nehmen - in grossen Netzen sogar mehr als ein Jahr.

Weil der Anwender auch innerhalb der Client-Server-Architektur nur selten ohne redundante Datenbestaende auskommt, muessen zudem unterschiedliche Aktualitaetszustaende der Daten bewerkstelligt werden. Kurz: Das Fuehren und die Verwaltung verteilter Datenbestaende und Anwendungen bereiten - zumindest in grossen Installationen - noch betraechtliche Schwierigkeiten.

Erstreckt sich die verteilte Architektur ueber eine Weitverkehrsverbindung, tauchen weitere Hindernisse auf. Konventionelle Bandbreiten sind zwar kostenguenstig, verkraften aber nur schwer den aus der verteilten Verarbeitung resultierenden Verkehr. Die Parallelitaet von Verarbeitungsprozessen laesst sich also kaum ueber die Weitverkehrsstrecke bewerkstelligen - es sei denn, der Anwender setzt auf teure breitbandige Verbindungen oder haelt die gleiche Software auch entfernt vor.

Dementsprechend gehen nach Angaben von Trend Research zur Zeit noch die meisten Anwender mit eher gebremstem Elan daran, die Client-Server-Technik im WAN-Umfeld zu installieren. Lediglich 21 Prozent der befragten Unternehmen haben ueberhaupt eine Client- Server-WAN-Installation in irgendeiner Form realisiert; 45 Prozent haben sie noch nicht einmal auf absehbare Zeit geplant.

Auch der Aufwand fuer Anwendungsentwicklung ist groesser als viele annehmen. Die Zahl geeigneter Werkzeuge, die dem Anwender effektiv bei der Programmierung von C/S-faehigen Anwendungen helfen, ist noch vergleichsweise gering. Zwar steht sogenannte Middleware zur Verfuegung, die bei der Programmierung das tiefe Eintauchen in die technischen Details verschiedener Betriebssysteme, Hardware- Plattforme und Kommunikationsprotokolle ersparen soll, doch gibt es hier noch Bedarf an verlaesslichen Standards.

Als verbindende Kommunikationsmechanismen stehen RDAs (Remote Data Access), RPCs (Remote Procedure Calls), MOMs (Message-oriented Middleware) und ORBs (Object Request Broker), darueber hinaus APPCs (Advanced Program to Program Communication) und Sockets zur Verfuegung. So kann sich der Anwender bei der Auswahl nur an der mehr oder weniger starken Marktpraesenz der einzelnen Middleware- Varianten orientieren - eine mit Blick auf die Investitionssicherheit unsichere Wahl.

Auch das System-Management der C/S-Installation birgt noch ungeloeste Probleme. Einzelne Management-Aufgaben wie Router-, Hub- , Gateway- und Server-Management werden von gesonderten und zudem meist herstellerspezifischen Systemloesungen abgedeckt. Entsprechend schwierig ist die Integration unter einer gemeinsamen Plattform wie IBM Netview oder HP Openview. Als kleinster gemeinsamer Nenner fuer die Ueberwachung und Verwaltung der C/S- Installation steht dann nur ein beschraenkter Vorrat an SNMP- Funktionen (Simple Network Management Protocol) zur Verfuegung.

Die umfassende Integration kann nach Aussagen von Marktkennern bis zu fuenfmal so teuer werden wie die Summe aller Management- Komponenten. Fuer das Performance-Management der Installationen steht bis heute keine Loesung zur Verfuegung. Ebenso ist die Verwaltung der Komponenten in Echtzeit bis heute nicht moeglich.

Der Wechsel in die Client-Server-Welt wird auch durch die Personalsituation erschwert: Das DV-Personal trennt sich nur ungern von der gewohnten Technik und versierte C/S-Spezialisten sind teuer. Wie sehr der Anwender den Einstieg in die C/S-Welt bremst, fuehrt eine US-Studie vor Augen, die das US-Fachblatt "Datamation" gemeinsam mit der Broker-Firma Cowen & Company durchgefuehrt hat. Von rund 2400 befragten Mainframe-Anwendern sagten 38 Prozent aus, dass sie den Problemen und Kosten einer Umstellung lieber aus dem Weg gingen. 27 Prozent haben Muehe, Vorteile der C/S-Technik zu sehen, 15 Prozent finden nicht die geeignete Software fuer den Wechsel. Dieses Ergebnis ist um so erstaunlicher, als man den USA gegenueber Europa immer noch einen technologischen Vorsprung von neun bis zwoelf Monaten einraeumt.

Nach ersten Erfahrungen mit Client-Server-Installationen schwindet auch immer mehr die Hoffnung, Geld sparen zu koennen. Zwar sinken die MIPS-Kosten (MIPS = million instructions per second) und Plattenspeicher fuer Workstations und PCs sind wesentlich guenstiger zu haben als fuer den Mainframe, doch der Kostenvorteil wird allzu oft durch redundante Datenbestaende und replizierte Datenbanken - und damit durch einen erhoehten Speicherbedarf - aufgezehrt.

Zwar machen die MIPS-Kosten im C/S-Umfeld nur rund ein Fuenfzigstel der Mainframe-Kosten aus. Weil aber in einer konsequent verteilten Architektur das gesamte Netz sozusagen zum Backbone wird, ist dafuer das Zwanzig- bis Vierzigfache an Prozessorleistung erforderlich.

All diese Erfahrungen haben dazu gefuehrt, dass die meisten Unternehmen trotz grundsaetzlicher Zustimmung genauer ueber ihr C/S- Engagement nachdenken. Allgemein wird eine langsame und wohldurchdachte Migration von der zentralistischen zur verteilten Netzwerkwelt favorisiert. Der Mainframe gilt als Ausgangspunkt fuer eine sanfte Migration, dem Downsizing.

Zu diesem Ergebnis kommt auch Trend Research: 51 Prozent streben danach mittlerweile eine sanfte Migration an, immerhin 22 Prozent der Befragten halten den Mainframe sogar mittelfristig fuer eine wesentliche Informations- und Verarbeitungsbasis im Netz.

Langsam migrieren heisst, Zeit zu gewinnen, bis der Markt verlaessliche Hilfsmittel fuer eine vollstaendig verteilte Verarbeitung und Datenhaltung im Netz bietet. Wenig Vertrauen wird vor allem der dezentralen Datenhaltung entgegengebracht, hier verlassen sich viele Anwender weiterhin auf die Sicherheit des Mainframes.

Auch bei der sanfteren Migration in die Client-Server-Welt will jeder Schritt gut durchdacht sein, um Fehlinvestitionen soweit wie moeglich auszuschliessen sowie Kosten und Aufwand im Plan zu halten. Dabei koennen die einzelnen Migrations-Etappen wie folgt aussehen:

-die Investitionen in die Kosten der dezentralen Struktur genau abschaetzen;

-die Integrationsfaehigkeit der installierten Systeme - Hardware wie Software - pruefen;

-die Anwendungsentwickler rechtzeitig schulen;

-erst einmal Front-end-Loesungen anstreben;

-replizierte Datenbanken aufbauen;

-ein logisch einheitliches Datenbank-Management-System entwickeln;

-verschiedene Aktualisierungsgrade auf unterschiedlichen Servern bedenken;

-die Anwendungsfunktionen modellieren;

-objektorientierte Loesungen anstreben sowie

-fuer mehr Verarbeitungssicherheit durch genuegend Redundanz und Vermaschung sorgen.

Trotz der kleineren Migrationsschritte haelt man unter Kennern der Technik wenig von der alternativen Portierung von Mainframe- Anwendungen in die C/S-Welt, weil dadurch lediglich die starren hierarchischen Strukturen festgeschrieben werden - eine Verfahrensweise, die den Spielraum fuer innovative Loesungen erheblich einschraenkt. Deshalb kommt der Anwender in der Regel an einer Neustrukturierung der Host-Anwendungen nicht vorbei.

Dieser Einschnitt ist auch ratsam, weil sich mit der Portierung nur Teile der Terminal-orientierten Programme uebernehmen lassen, und auch nur dann, wenn zuvor modular programmiert wurde. Der grosse Rest muss aufwendig neu programmiert werden. Auch GUI- Loesungen (GUI = Graphical User Interface), objektorientierte Programmierung und manchmal sogar echte Client-Server-Faehigkeiten koennen daran nicht viel aendern.

Als geeignetes Server-Betriebssystem fuer den ersten Migrationsschritt haben Marktkenner Unix ausgemacht. Laut IDC soll Unix im Jahr 1998 einen Marktanteil von 39 Prozent im Client- Server-Umfeld auf sich vereinen, gefolgt von NT mit 29 Prozent. Glaubt man dieser Prognose, werden andere Betriebssysteme fuer den Midrange-Bereich wie VMS (fuenf Prozent) und OS/400 (zwei Prozent) nur eine untergeordnete Rolle spielen. Und die geeignete Hardwareplattform fuer den C/S-Einsatz? Hier hat die Sound View Financial Group unterschiedliche Plattformen getestet und zwischen 5 (am besten) und 1 (am schlechtesten) bewertet. Dabei wurden im einzelnen Aspekte wie Kosten, Verfuegbarkeit, Sicherheit, Support und Service genauer untersucht.

Das beste Gesamtergebnis (3,6) erreichte Hewlett-Packard (Unix), gefolgt von den IBM-Systemen AS/400 und RS/6000 (jeweils 3,5). Mit gleicher Bewertung schlossen Sun Microsystems und Pyramid Technology ab. Sequent Computer Systems (3,4), PC-LAN (3,2), DEC mit Unix (3,1) und DEC mit VMS (2,8) folgten vor HP System 3000 (2,6) und Tandem (2,3). Auch nach den beliebtesten Datenbanken wurde gefragt. Hier rangiert Oracle mit 51 Prozent unangefochten an der Spitze. Sybase brachte es in der Gunst des Anwenders auf 25 Prozent, IBMs DB2 auf 13 Prozent, Informix auf 3 Prozent und CA/Ingres auf spaerliche 2 Prozent.

Objektorientierung schon im Visier

Weitblick sollte der Anwender trotz allmaehlicher Migration auch in anderer Hinsicht beweisen: bei der Auswahl der richtigen Middleware und der Programmiertechnik. Denn mit objektorientierter Programmierung soll der Aufwand fuer die Erstellung von Anwendungen und fuer die anschliessende Wartung in Zukunft drastisch sinken.

Das Resultat der objektorientierten Programmierung, sogenannte Geschaeftsobjekte, sind kleine selbstaendige Einheiten, die alles beinhalten, was aus Anwendersicht zum Verarbeitungsablauf und zur Darstellung notwendig ist: vom Programmcode ueber die Daten bis hin zu den Praesentationsfunktionen. So programmiert, sind Geschaeftsobjekte gemaess dem Bausteinprinzip flexibel kombinierbar. Einzelne Objekte koennen dabei ihre Eigenschaften flexibel auf andere uebertragen. Sie koennen zudem Daten an andere Objekte liefern oder von dort anfordern. Damit aehnelt das Baukastenprinzip der Geschaeftsobjekte dem des C/S-Prinzips.

Dementsprechend sieht Ovum den Marktanteil der Object-Request- Broker-Middleware von nur einem Prozent 1994 auf 16 Prozent im Jahr 2000 wachsen. Parallel dazu soll Message-oriented-Middleware (MOM) von fuenf auf 30 Prozent zulegen, berichten die Marktforscher. Optimisten gehen von einem Durchbruch der neuen Programmiertechnik und der Middleware-Ansaetze schon im Jahr 1997 aus.

Zwar werden RDAs (Remote Data Access) auch weiterhin ihren Markt haben. Doch ihr Anteil wird nach Einschaetzung von Ovum von 91 Prozent im Jahr 1994 auf 41 Prozent im Jahr 2000 sinken. Dann naemlich wird der datenzentrierte Ansatz von RDA - auf die zentrale Datenbank wird via Database-Gateway und SQL zugegriffen - nicht mehr zeitgemaess sein. Auf diesen Trend gilt es sich fruehzeitig einzustellen.

Eine Koexistenz von "alter" und neuer Technik ist durchaus moeglich. Denn sequentiell erzeugte Anwendungen koennen mit Programmiersprachen wie Object Cobol in objektadaequater Form, als Wrapper, eingepackt werden. Auf diese Weise wird der Cobol-Code vom Programm wie ein Objekt behandelt.

Echte objektorientierte Loesungen stehen zudem kurz vor der Freigabe, so beispielsweise eine OO-Cobol-Loesung fuer MVS. Im Markt verfuegbar sind bereits Corba-kompatible ORBs sowie Softwarewerkzeuge auf C++- und Smalltalk-Basis. Sie erlauben es heute zumindest, Objekte der gleichen Sprache miteinander zu verbinden.

"Migrieren mit Bedacht", nur so kann nach den ersten Erfahrungen die Devise fuer den Eintritt in die C/S-Welt lauten. In einer Zeit, in der schon Veraenderungen an der Netzinfrastruktur erhebliche Einschraenkungen oder zumindest zwischenzeitlich hohe Kosten fuer ein paralleles Kommunikationssystem fuer das Unternehmen mit sich bringen, will die Migration zur C/S-Technik gut durchdacht sein. Immerhin sind dabei alle Ebenen des Kommunikationssystems "Netzwerk" betroffen. Ein allmaehlicher Wechsel scheint hier der beste Installationstakt zu sein.

Kurz und buendig

Ernuechterung haelt bei Client-Server-Pionieren Einkehr: Von 172 Anwendern klagen in einer Umfrage 82 Prozent ueber Terminverzoegerungen, 73 Prozent haben Netzwerkprobleme. Vor allem Installationen, die sich ueber Weitverkehrsnetze erstrecken, bereiten den Usern Kummer. Da der Trend zu flexiblen Client- Server-Umgebungen dennoch nicht aufzuhalten ist, gilt es nun, eine langsame, wohlorganisierte Migration hinzubekommen. Das besondere Augenmerk ist dabei auf die Auswahl der Werkzeuge zu richten: auf Entwicklungs-Tools, Middleware und die richtige Programmiertechnik.

*Bernd Steinhoff ist freier Journalist in Wiesbaden.