Client-Server stellt nach der Batch- und Dialogverarbeitung nunmehr eine dritte grundsaetzliche DV-Strategie dar. Der Ausdruck gibt aber die Realitaet unvollstaendig wieder: Es fehlt der Mittelbau, das Verbindungsstueck zwischen den beiden Endpunkten Client und Server. Da diese Middleware fuer die Konzeption von Client-Server-Architekturen entscheidend ist, lohnt sich ein Blick auf das Marktgeschehen.

Wahrscheinlich wird Middleware einfach deshalb ignoriert, weil niemand eine klare Definition dafuer kennt. Einige Beispiele (Zitate aus Veroeffentlichungen) stuetzen diese These: "Middleware ist alles, was nicht Client oder Server ist" - "Allgemein einsetzbare Schnittstelle fuer Datenzugriff" - "Open Interfaces fuer eine Multivendor-Umgebung" - "Datenzugriff zu Unternehmensdaten ueber LAN beziehungsweise WAN" - "Strategische Voraussetzung fuer verteilte Verarbeitung".

Middleware-Angebot wird zunehmend groesser

Jedes einzelne Statement ist sicherlich richtig. Hinter den Zitaten verstecken sich unterschiedliche Ueberlegungen, die bei der Produktkategorisierung naeher erlaeutert werden. Klar ist jedenfalls, dass unter Middleware nicht einfach Netz- Betriebssysteme mit ihren Protokollen zu verstehen sind, sondern dass Middleware-Produkte heute eine stabile Technik zur Verbindung lokaler Workstations mit entfernten Datenhaltungssystemen sind. Middleware kann aber mehr, als nur den Datentransport vom Client zum Server und zurueck zu gewaehrleisten. Dies ist zwar die heute ueberwiegend angebotene Funktionalitaet, aber in zunehmendem Masse kommen zusaetzliche Services hinzu.

In Client-Server-Architekturen benoetigen PC-Anwendungen nicht nur entfernte Daten von dezentralen Servern im LAN oder von zentralen Mainframe-Servern (haeufig ueber WANs miteinander verbunden), sondern auch Informationen vom Nachbar-PC, den Datenaustausch innerhalb von Workgroups, die Weitergabe von Arbeitsergebnissen etc. Erst die beliebige Kommunikation der eingebundenen Geraete macht eine Client-Server-Konzeption so nuetzlich fuer das Unternehmen. Wer gesehen hat, wie Anwender, befreit vom Zwang einer strengen Transaktionsverarbeitung, froehlich miteinander kommunizieren, wird den wahren Wert einer Client-Server- Architektur erkennen und Middleware-Produkte mit entsprechendem Funktionsumfang mit Begeisterung einsetzen. Der richtige Begriff dafuer lautet "Client-Service-Konzept", da Clients beliebige Leistungen in Anspruch nehmen koennen. Groupware-Programme sind typisch fuer diese Art von Middleware. Da der Nutzen fuer die Anwender offensichtlich ist, wird dieses Marktsegment stark wachsen.

Unter Middleware laesst sich auch eine Schnittstelle fuer den Datenzugriff auf entfernte Datenbanken oder File-Systeme verstehen. Die meisten heutigen Middleware-Produkte haben die eindeutige Aufgabe, den Datenzugriff vom Client auf eine SQL- Datenbank zu ermoeglichen. Leider gibt es keine einheitlichen Schnittstellen, sondern fast ausschliesslich proprietaere, die sowohl von der Anwendung als auch von der Middleware bedient werden muessen. Grundsaetzlich dienen diese Interfaces aber nur zur Uebernahme der Datenanforderungen von der Applikation. Diese werden an die Datenbank weitergeleitet, und die Antworten kommen wieder zurueck. Da weder die Client- noch die Server-Schnittstellen genormt sind, werden Middleware-Produkte dieser Art danach beurteilt, wie viele unterschiedliche Schnittstellen sie bedienen koennen.

Bidirektionaler Zugriff ist noch selten realisiert

Auf einer etwas hoeheren Stufe sind Schnittstellen anzusiedeln, die den Zugriff auf heterogene DB-Systeme erlauben und dabei vor der PC-Anwendung die unterschiedlichen DB-Schnittstellen verstecken. Dadurch schauen alle Zieldatenbanksysteme fuer die Anwendung gleich aus - was eine erhebliche Erleichterung bei der Programmierung bedeutet. Datenbank-Gateways sind typische Vertreter dieser Produktlinie. Die technische Realisierung erfolgt in der Regel mit Hilfe von Remote Procedure Calls (RPCs) beziehungsweise mit einer Programm-Programm-Schnittstelle (Advanced Program-to-Program Communication = APPC). So lassen sich zum Beispiel SQL- Unterschiede zwischen verschiedenen DB-Systemen bewaeltigen. Die Schnittstellen uebersetzen die SQL-Anforderungen fuer das Zieldatenbanksystem und kuemmern sich um den Datentransport. Durch den Einsatz rechneruebergreifender Transaktionsmonitore lassen sich verteilte Transaktionen realisieren (Distributed Transaction Processing).

Eine eigentlich sehr wichtige, aber doch nur selten verfuegbare Funktion ist der bidirektionale Zugriff. Dabei fungiert ein Server als Client und umgekehrt. So kann sich zum Beispiel ein Mainframe Daten von einem dezentralen LAN-Server holen. Das "Database Gateway" von Micro Decisionware und der "Open Server" von Sybase sind Produktbeispiele dafuer.

Offenheit bedeutet im Zusammenhang mit Middleware eine einheitliche Schnittstelle zwischen Client und Server fuer den Datenzugriff auf entfernte Datenbanken. Die Herausforderung besteht darin, eine Schnittstelle zu definieren, die die heute vorhandene Vielzahl von Client- Programmen bedienen kann. Auf der Back-end-Seite muss eine Vielzahl unterschiedlicher DB-Systeme unterstuetzt werden, von denen heute jedes ueber eine proprietaere Schnittstelle verfuegt.

Am Markt zeichnet sich folgende Entwicklung ab:

- Schnittstellen-Definition:

Open Database Connectivity (ODBC) von Microsoft koennte der Standard in der Windows-Welt werden. Alle PC-Anwendungen und alle Standard-PC-Tools wuerden das ODBC-API nutzen, alle Programmierer nur noch in einem API geschult. Alle Middleware-Produkte und Server-Datenbanken muessten ueber ODBC-Treiber verfuegen. Neben ODBC gibt es noch eine zweite Schnittstelle mit den gleichen Anspruechen: Idapi aus der Borland-IBM Umgebung hat im Gegensatz zu ODBC noch Erweiterungen fuer hierarchische Datenstrukturen. Realisierungen werden aber erst ab Ende 1993 erwartet.

- PC-Standardprodukte werden angepasst:

Diese Produktanpassungen finden zur Zeit statt. Alle namhaften Hersteller haben ihre Absicht erklaert, ODBC-Support fuer die Windows-Welt zu liefern. Idapi-Support ist erst langsam im Entstehen. In diesem Zusammenhang stellt sich die Frage, warum zwei Schnittstellen erforderlich sind. Die Antwort ist einfach: Weil unterschiedliche Anforderungen nicht mit einem Produkt geloest werden koennen.

- Kundennutzen:

Der Nutzen offener Schnittstellen ist zwar eindeutig, haengt aber doch sehr stark vom Funktionsumfang der Schnittstelle ab. Naturgemaess ist das Potential von ODBC ein Kompromiss, so dass die Schnittstelle sicherlich in einigen Faellen Rationalisierungserfolge bringen wird. Andererseits wird es aber eine Reihe von Anwendungen geben, die mit den verfuegbaren Funktionen nicht auskommen. Es gibt zwar eine "Pass-Through"- Funktion, um beliebige SQL-Statements absetzen zu koennen. Dadurch erfolgt aber eine feste Bindung an das Zieldatenbanksystem, und der Vorteil einer offenen Schnittstelle geht verloren. ODBC und auch Idapi werden also Hilfe bieten, aber nicht alle Herausforderungen loesen koennen.

Beide Schnittstellen unterstuetzen den Remote Data Access (RDA), eine heute uebliche und stabile Technik des Datentransportes. Verteilte Datenbanken dagegen sind technisch wesentlich komplexer und werden bisher selten angewandt. Aber auch sie benutzen Middleware-Produkte zur Realisierung komplexer Funktionen. Es existieren bereits erste Realisierungen mit offenen Schnittstellen.

Erwaehnenswert ist das Distributed-Relational-Database-Architecture (DRDA-)Konzept der IBM, dessen Schnittstellen offengelegt sind. Die entsprechende Middleware-Komponente ist "DDCS/2" zur Verbindung von "DB2/2" und "DB2/6000" mit den IBM-Mainframe- Datenbanken. DDCS/2 unterscheidet sich von anderen Middleware- Produkten dadurch, dass keine Host-Komponente erforderlich ist, da eine direkte Integration in DB2 realisiert wurde. Letztendlich koennte DDCS/2 das Middleware-Standardprodukt fuer verteilte Datenbanken werden.

Produkte dieser Art erlauben den Zugriff auf beinahe beliebige Datenquellen auf unterschiedlichsten Plattformen; auf Daten, die heute im Unternehmen vorhanden sind, die nicht umgeformt werden und auch nicht in SQL-Datenbanken gespeichert sein muessen. Eine beachtliche Loesung hat Big Blue mit dem "Information Warehouse Framework" geliefert.

Der fuer den Anwender sichtbare Nutzen ist die einheitliche Schnittstelle: Das Produkt arbeitet immer mit SQL-Aufrufen (versteckt in der Anwendung oder offen) und hat trotzdem Zugriff auf beliebige Datenhaltungssysteme, auch auf Nicht-SQL-DB- Loesungen. Ein wichtiger Vertreter dieser Produktgruppe ist "EDA/SQL" von Information Builders wegen seiner grossen Schnittstellen-Vielfalt (mehr als 45 Datenhaltungssysteme fuer mehr als 35 Betriebssysteme) und zahlreichen SQL-Translater- Funktionen.

Die heute und demnaechst verfuegbaren Produkte konzentrieren sich im Kern auf eine Funktion: Zugriff auf entfernte Datenhaltungssysteme mit mehr oder weniger komplexen Schnittstellen und Funktionalitaeten. Ein weitgehender strategischer Ansatz waere, mit Client-Server-Architekturen von der zentralen zur dezentralen Informationsverarbeitung zu kommen. Dazu gehoert aber mehr, als nur Daten zu verteilen, naemlich

- eine hohe Verfuegbarkeit und Verlaesslichkeit,

- Herstellerunabhaengigkeit,

- Faehigkeit zur Verarbeitung grosser Datenmengen,

- kurze Antwortzeiten sowie

- zentrale Kontrollpunkte fuer dezentrale Verarbeitung. Alles in allem all das, was heute in der Mainframe-Welt eine Selbstverstaendlichkeit ist.

Diese strategischen Anforderungen koennen nur voll-integrierte Produkte erfuellen, die wahrscheinlich zunehmend von den Datenbankherstellern geliefert werden. Die Integration muss dabei alle drei Welten umfassen: Client, Server und Middleware. Dies uebersteigt zwar die reine Middleware-Funktionalitaet, ist aber erforderlich, um Downsizing-Konzepte auf Unternehmensebene verwirklichen zu koennen. Ein Beispiel fuer diese Art von Produkten ist "Sybase System 10" mit der Datenbank "SQL Server" im Mittelpunkt und mit den Teilkomponenten "Navigation Server", "Omni SQL Gateway", "Replication Server" und "Control Server".

Damit werden unterschiedliche Services geboten:

- die Erhoehung der Systemkapazitaet durch verteilte, parallele Verarbeitung,

- die Kommunikation zwischen Front- und Back-end auch in einer heterogenen Welt,

- die Datenverteilung und Wiederholbarkeit im Fehlerfall oder bei Ausfall einer Hardwarekomponente,

- Kapazitaetsplanung und -design, schnelles Daten-Back-up, Ueberwachung und Tuning sowie

- eine zentrale Kontrolle von verteilten Systemen.

Middleware-Produkte sind von zwei unterschiedlichen Herstellertypen verfuegbar: erstens von Spezialisten fuer Middleware und zweitens von Datenbankherstellern.

Zur ersteren Gruppe gehoeren:

- Information Builders mit EDA/SQL (Enterprise Data Access). Typisch fuer dieses Produkt ist die Vielzahl der unterstuetzten Schnittstellen (Netzprotokolle, Datenhaltung und Betriebssystem), die Uebersetzung von SQL-Statements in die jeweilige DML des - auch nicht relationalen Zieldatenbanksystems und die Faehigkeit, einen Join zwischen Tabellen beziehungsweise Files heterogener Datenhaltungssysteme durchzufuehren.

- Techgnosis mit "Sequelink" zur Verbindung unterschiedlichster Plattformen miteinander und insbesondere auch zur Einbindung der Macintosh-Umgebung in ein integriertes Netz. Das Ziel besteht im optimalen Transport von Nachrichten. Dabei werden weder SQL- Statements umgeformt noch Zieldatenbanksysteme emuliert.

- IBM mit DDCS/2 und dem Versuch, mit einer grundlegenden Konzeption (DRDA) offene Schnittstellen und Funktionen fuer verteilte Datenbanken in heterogener Umgebung zu schaffen. Der zur Zeit uebliche Weg ist aber der Einsatz der CICS-Familie (zum Beispiel "CICS/OS2") als rechneruebergreifende Kommunikationssoftware. Unterstuetzt werden folgende Kommunikationsformen: Transaction Routing, Function Shipping, Asynchronous Processing, Distributed Transaction Processing sowie Distributed Program Link.

- SNI bietet mit der "Data-Base-Access (DBA)"-Produktfamilie eine DB-unabhaengige Loesung mit einer einheitlichen Benutzer- Schnittstelle fuer den entfernten Datenzugriff. Verteilte Transaktionsverarbeitung wird mit "UTM/UTM-D" und "UPIC" realisiert.

- Micro Focus offeriert mit "Application-to-Application- Interface" (AAI) ebenfalls eine Moeglichkeit, unterschiedlichste Anwendungen in einer heterogenen Umgebung miteinander zu verbinden.

- Micro Decisionware (MDI) mit "Database Gateway" und der Anbindung an den "SQL Server" von Microsoft beziehungsweise Database. Damit sehen entfernte Datenbanken fuer die Anwendung wie eine lokale SQL-Server-DB aus, und die Programmierung wird vereinfacht. Mit Hilfe von RPCs kann auch auf nicht- relationale Datenbanken am Host zugegriffen werden. Zusaetzlich wird der bidirektionale Modus (Mainframe wird Client) unterstuetzt.

Zur zweiten genannten Gruppe gehoeren Firmen wie

- Gupta mit "SQL Network", das entfernte Datenbanken wie "SQL Base" aussehen laesst und typische Client-Server-Funktionen wie Vorwaerts- und Rueckwaertsblaettern im Cursor unterstuetzt. Mit "SQL Host" erfolgt der Zugriff auf Mainframe-Datenbanken wie DB2.

- Sybase bietet mit dem Produkt "Open Server" aehnliche Funktionalitaet wie "EDA/SQL". "Open Gateway" unterstuetzt Anwendungen beim Zugriff auf entfernte Datenbanken durch Emulation der SQL-Server-Funktionalitaet.

- Oracle, Ingres und Informix offerieren Gateway-Produkte fuer den transparenten Zugriff auf Mainframe-Datenbanken wie DB2 oder SQL/DS.

- Die Software AG hat mit "En- tire Function Server" ebenfalls eine weitreichende Verbindung heterogener Welten im Programm. Das Kernstueck ist der "Entire Broker" mit einer einheitlichen, systemunabhaengigen Schnittstelle (API) zur Verteilung von Daten und Funktionen.

Client, Middleware und Server, das Dreigestirn der zukuenftigen Informationsverarbeitung, werden die Konzepte und Realisierungen der kommenden Generation von Anwendungen praegen. Middleware wird dabei eine dominierende Rolle spielen.