Rolf Perschbacher Geschaeftsfuehrer der Neuron Data GmbH, Neu-Isenburg

Entwickler PC-basierter Client-Server-Anwendungen gefallen sich darin, mitleidig ueber hinterwaeldlerische Mainframe-Programmierer zu laestern, die die meiste Zeit ihres beruflichen Daseins mit der Pflege von unwartbarem Softwareschrott verbringen.

Der abfaellige Gestus soll deutlich machen, dass man sich vor den Fehlern vergangener, IBM-hoeriger Programmiergenerationen gefeit sieht. De-facto-Standards wie OLE (Object Linking and Embedding) und ODBC (Open Database Connectivity), genutzt mit Hilfe moderner Tools, sollen leicht pflegbare Software garantieren, die technologisch zukunftsoffen ist. Dieser Glaube koennte in den Umsatzhimmel fuehren, falls sich in den heute verbreiteten zweistufigen Client-Server-Architekturen (Windows-Client greift auf SQL-faehige relationale Datenbank zu) eine Loesung entdecken liesse, die komplexen kommerziellen Anforderungen weitgehend gerecht wird.

Doch dem ist nicht so. Denn die technischen Grenzen zweistufiger Client-Server-Systeme sind immer noch eng gezogen. Zweistufigkeit reicht fuer kleine, lokale Netzwerke, nicht aber fuer heterogene und verteilte Umgebungen, wie sie heute in allen groesseren Unternehmen zu finden sind. Dokumentieren laesst sich dies am Beispiel von Anwendungen, die OLE nutzen - eine runde Technologie auf dem Client, die blind gegenueber dem Server ist. Von Microsoft als Paradepferd fuer Interoperabilitaet zwischen Anwendungen hochgejubelt, entpuppt sich OLE bei genauerem Hinsehen als reines Client-Konzept fuer die dokumentenzentrierte Datenverarbeitung im Front-Office. Die Frage nach einer Objekttechnologie, die auch mit Systemen fuer das Back- Office, also die Server-Seite, interoperabel ist, bleibt ausgeklammert.

Vergleichbares gilt uebrigens fuer ODBC: Als SQL-basierter synchroner Kommunikationsmechanismus ein Flaschenhals, leidet ODBC unter den strukturellen Schwaechen aller SQL-Schnittstellen - die logische Aufteilung der Anwendung ist durch eine starre Sollbruchstelle vorgegeben. Entweder laeuft die Logik auf dem Client ab oder in Form einer Stored Procedure im Datenbank-Server.

Unternehmensweite Anwendungen, die im Zuge des Downsizings von "Legacy"-Systemen den Trend der ausgehenden 90er Jahre setzen, muessen von derartigen Begrenzungen zweistufiger Architekturen frei sein. Das laesst sich nur verwirklichen, indem Anwendungen partitioniert werden und als Business-Objekte beliebig zwischen Clients und Servern im Netzwerk verteilt werden koennen. Auf diese Weise entstehen flexibel konfigurierbare drei- oder mehrstufige Architekturen, die aus Clients im Front-Office, Servern im Back- Office und Applikations-Servern im Middle-Office bestehen und ueber Middleware integriert sind. Ein fruehes, prominentes Beispiel einer dreistufigen Architektur ist SAP R/3. Bei allen sonstigen Schwaechen - durch seine Dreistufigkeit ist R/3 so skalierbar, dass es moeglich ist, damit Hunderte von Anwendern zu bedienen.

Wenn die Zukunft der objektorientierten Entwicklung in dreistufigen Architekturen liegt, produzieren viele Anwendungsentwickler heute bereits die Software-Altlasten von morgen. Schuld daran sind nicht zuletzt die ueberschiessenden Verheissungen, die Entwicklungswerkzeugen wie Gupta, Powerbuilder oder Visual Basic gelten.

Entgegen allen Marketing-Behauptungen fehlen diesen Tools entscheidende Funktionen, um die Grundausstattung dreistufiger Client-Server-Systeme bereitstellen zu koennen. Beispielsweise koennen sie keine TP-Monitore einbinden, OLE-Objekte mit Corba- Objekten (Corba = Common Object Request Broker Architecture) auf Unix-Servern kommunizieren lassen oder gar eigene Objekte mit OLE und Corba verknuepfen. Auch die lastabhaengige Verteilung von Anwendungsbestandteilen auf verteilten Server-Systemen ist ihnen gaenzlich fremd.

So ist Skepsis geboten, wenn Software-Entwickler gemaess einem betriebswirtschaftlichen Kalkuel handeln, demzufolge 80 Prozent Windows-Marktanteil auf Client-Systemen die groesstmoegliche Marktdurchdringung bei einem optimalen Verhaeltnis von Einsatz zu Ertrag bringen. Diese Rechnung geht zukuenftig nur dort auf, wo die Windows-Welt auf Arbeitsgruppen mit maximal einigen Dutzend Anwendern begrenzt bleibt.

Sobald die Integration skalierbarer Server-Technologien gefordert ist, benoetigen Entwickler von Windows-Anwendungen jedoch Werkzeuge und Technologien, die nicht nur Client-zentrierte Standards wie OLE und ODBC unterstuetzen, sondern durch ihre Offenheit auch Interoperabilitaet zwischen heterogenen Objekt-, Netzwerk- und Systemtechnologien herstellen.