Heute definiert sich Middleware ganz allgemein als ein Bündel aus Protokollen, Schnittstellen und Programmen, die dafür sorgen, daß Anwendungen, Daten und Menschen auf einem Rechner, aber auch über ein heterogenes Netz hinweg miteinander kooperieren können.
Am einfachsten erscheint die Mensch-zu-Mensch-Kommunikation. Hier ist die E-Mail die zentrale Middleware-Anwendung. Diese Funktion ist seit ihrer Einführung schon zu Beginn der Computerzeit längst in einer Weise erweitert worden, die es erlaubt, Dokumente und Anwendungen einzubinden. Auf diese Weise wurde die elektronische Nachrichtenvermittlungsstelle zur Grundlage für Middleware-Anwendungen wie Workflow-Systeme und Groupware.
In der Kommunikation zwischen Anwendungen lassen sich ablauforientierte Methoden wie Transaktionssysteme (TP-Monitore) oder Datenbankanwendungen und nachrichtenorientierte Systeme unterscheiden. Bei letzteren tauschen Programme nach dem Vorbild von E-Mails Nachrichten aus, lösen damit aber gleichzeit Aktionen aus. In diese Kategorie gehören Produkte, die auf Remote Procedure Calls (RPCs) beruhen, vor allem aber alle Objekttechniken. Die Trennung ist nicht immer ganz scharf, so lassen sich mit RPCs durchaus Transaktionen organisieren. Eine Randgruppe bilden die Bildschirm-Emulationen, wobei Clients, in der Regel PCs, wie klassische Terminals für Großrechner - oder Midrange-Hosts eingesetzt werden.
Die Mutter aller Datenbank-Middleware ist die Abfragesprache, insbesondere SQL. Hier wird von einem Client-System oder auch von einem Anwender über Netz vom Datenbank-Server Information abgerufen. Kompliziert wird dieses Verfahren, wenn der Endanwender nicht mehr wissen soll, von welchem der angeschlossenen Server, auf denen teilweise unterschiedliche Datenbanksysteme arbeiten, die Information abgerufen wird. Hier helfen entweder fest definierte Gateways oder aber flexiblere Lösungen wie Microsofts auf einem offenen SQL-Standard basierendes Schnittstellen-Bündel Open Database Connectivity (ODBC).
Von anderen Anwendungen unterscheidet sich Middleware durch die Nähe zur Netzwerktechnik, die ja auch der Kommunikation dient. Der dort üblichen Funktionseinteilung nach dem OSI-Modell entsprechend, konzentriert sie sich auf die vier oberen Schichten und dort besonders auf die Ebenen sechs und sieben für Darstellung und Anwendung. Dabei setzt sie jedoch immer auf tiefere Schichten auf. Dafür ist der Kommunikations-Layer der Middleware zuständig (siehe Abbildung). Man kann sagen, daß Middleware eine Netzinfrastruktur auf Anwendungsebene herstellt.
Die Geschichte der Middleware
Ihren Boom verdankt die Middleware der Ende der 80er Jahre im Unix-Umfeld entstandenen Open-Systems-Bewegung. Deren zentrales Ziel, Herstellerunabhängigkeit, führte zu einer ungeahnten Vielfalt an Systemen, die es nun in die neuen verteilten Client-Server-Umgebungen zu integrieren galt. Die damit verbundenen Netzwerkprobleme ließen die bislang im Vordergrund stehenden Hardware- und Betriebssystem-Diskussionen verblassen.
Viele dieser Schwierigkeiten sind mit Speziallösungen zu beheben. Im Datenbankbereich sind das zum Beispiel Gateways, die Datenbanken verschiedener Hersteller miteinander kommunizieren lasssen. Doch diese Techniken laufen dem Open-Systems-Trend zuwider - ein zu Beginn des Jahrzehnts wichtiges Argument - und sind zudem nur punktuell einsetzbar. In einer umfangreichen DV-Umgebung sind daher viele solche Lösungen vonnöten, wodurch sich das Komplexitätsproblem nur verschärft. Es gibt auch heute noch einen großen Markt für derartige Lösungen, weil sie oft leistungsfähiger sind als Middleware-Standards.
Dennoch wurde die Einführung eines ersten solchen Standards durch die in Bedrängnis geratene Open Software Foundation (OSF) von den Anwenderunternehmen als hochwillkommene Hilfe zur Handhabung ihrer heterogenen DV-Landschaften begrüßt. Das Konsortium mußte 1992 die Absicht fallenlassen, sein Microkernel-Unix "OSF/1" als industrieweiten Standard durchzusetzen, und nahm sich statt dessen vor, unter der Bezeichnung Middleware eine offene Infrastruktur für heterogene DV-Umgebungen zu schaffen. In diesem Sinne wurde der Begriff Middleware von OSF-Mitgliedsfirmen wie IBM, HP und DEC popularisiert.
Konkret verstand die OSF unter Middleware ihr Distributed Computing Environment (DCE), ein Remote Procedure Call (RPC) mit begleitenden Diensten, die zum Beispiel durch vereinheitlichte Adreßnamen (Naming Services) dafür sorgen, daß Funktionsaufrufe über heterogene Netze hinweg ohne großen administratorischen Aufwand funktionieren. DCE gilt noch heute als Inbegriff von Middleware, während sich das darauf aufbauende Distributed Management Environment (DME) nie etablieren konnte.
Im selben Jahr entdeckte Microsoft die mit dem Middleware-Konzept verbundenen Chancen. Firmenchef Bill Gates verkündete die Absicht, Windows durch die Windows Open Services Architecture (Wosa) zum universalen Client für den unternehmensweiten Einsatz zu machen.
Während von einigen Wosa-Komponenten bald keine Rede mehr war (Stichwort: Windows for Washing-Machines, Haushalts- und Bürogeräte mit eingebautem Windows) konnte sich die ODBC-Komponente auf breiter Basis durchsetzen. Die Datenbank-Middleware beruht auf einem Treiber-Konzept, das Microsoft-Anwendungen den Zugang zu den großen Unternehmensdatenbanken verschaffte. Seither gilt Datenbankanbindung als zweite große Middleware-Aufgabe.
Die Lawine war losgetreten, so daß sich nun auch Anbieter Gehör verschaffen konnten, deren Middleware sich bislang nicht vermarkten ließ, weil es keinen zugkräftigen Namen für ihre Produkte gab. So hatte die Darmstädter Software AG bereits Ende 1990 ein Paket von Lösungen geschnürt, die sie "Entire Function Server Technology" nannte und die das Ziel hatte, "die Kommunikation zwischen beliebigen Plattformen zu ermöglichen" und Mainframe-Anwendungen auf Unix-Systeme, zum Teil auf Windows-PCs, herunterladen zu können.
Während sich das damals besonders technologieorientierte Unternehmen um umfassende Lösungen bemühte, griffen die Kunden zu Produkten für vordringlichere Aufgaben, wie zu SQL-Anbindungen und anderen Datenbank-Gateways. Daher zählen heute Datenbankspezialisten wie Sybase und Oracle zu den großen Middleware-Anbietern.
Im Kielwasser von Microsoft hat sich Intersolv mit einer Vielzahl von ODBC-Treibern etabliert. Das Unternehmen versucht sich inzwischen aber zunehmend an Middleware für Data-Warehousing, wobei es darum geht, Daten aus verschiedenen Quellen zusammenzuführen und in verständlicher Weise darzustellen.
Zu den Vorformen des Data-Warehousing gehört eine weitere Middleware-Quelle, das inzwischen gescheiterte Information-Warehouse-Projekt der IBM von 1991. Darin war vorgesehen, alle Unternehmensdaten und die Zugriffsmöglichkeiten darauf in einem zentralen Repository durch Metadaten zu verwalten. Die Einbindung der SQL-Datenbanken gehörte damals zu den Aufgaben der Information Builders Inc., New York, die inzwischen im Datenbankbereich zu den wichtigen Middleware-Anbietern zählt.
Für die Middleware besonders zukunftsträchtig wurde die 1990 in aller Stille gegründete Object Management Group (OMG). Programm der Herstellerorganisation war es ursprünglich, eine industrieweit anerkannte Definition davon aufzustellen, was ein Objekt ist. Schon bald wurde diese Absicht um das Ziel erweitert, Techniken zu schaffen, die heute "Wrapping" genannt werden und mit denen sich Altanwendungen als Objekt in andere Umgebungen einbinden lassen.
Das wichtigste Ergebnis der OMG-Bemühungen ist die inzwischen als Standard geltende Common Object Request Broker Architekture (Corba). Dabei handelt es sich um ein Verfahren zur Kommunikation von Objekten über heterogene Umgebungen hinweg, wobei dem Anwender die Komplexität der DV-Landschaft verborgen bleibt. Herkömmliche Anwendungen lassen sich mit einer Corba-Schnittstelle versehen, so daß sie als Objekt unter Objekten agieren können. In gewisser Weise stellt Corba eine objektorientierte Weiterentwicklung konventioneller RPC-basierter Techniken wie DCE von der OSF dar.
Als Herausforderer des Corba-Standards haben sich im vergangenen Jahr die Microsoft-Technik Distributed Component Object Model (DCOM) beziehungsweise deren Ausprägungen OLE und Active X herauskristallisiert. Entsprechend ihrer Satzung hat die OMG versucht, mit Microsoft zusammen eine Brücke von der auf Windows-Plattformen beschränkten Active-X-Technik zu den für heterogene Umgebungen konzipierten Corba-Implementierungen zu schlagen. Die Gates-Company entschied sich statt dessen, Active X auf andere Plattformen portieren zu lassen und dort mit Corba in Konkurrenz zu treten.
Die Rückkehr der Transaktionsmonitore
Eher verschämt meldet sich inzwischen eine uralte Middleware-Klasse zu Wort: Transaktionssysteme. Obwohl kein Großanwender ohne sie auskommt, hat diese Technik den Ruf, zu Mainframe-lastig für die moderne Client-Server-Welt zu sein. Dabei hat erst die Entscheidung der IBM, ihr CICS-Produkt ab Ende 1993 für Unix anzubieten, den Durchbruch des Betriebssystems für kommerzielle Anwendungen signalisiert. Transaktionssysteme helfen seither auch in heterogenen Landschaften, Anwendungen durch die gesamte Unternehmens-DV bis hin zum Windows-PC zu lotsen.
Transaktionen leiden allerdings unter dem Nachteil, daß sie bei einer Unterbrechung von neuem aufgesetzt werden müssen.
Hier sorgten in den vergangenen zwei Jahren asynchrone TP-Varianten wie IBMs "MQ Series" für Abhilfe. Wie bei Workflow-Systemen können Anwendungen in einer Art "Postfach" darauf warten, bis der Benutzer Zeit findet, sie weiterzubearbeiten.
Workflow-Systeme gehören ebenfalls zu den Middleware-Produkten, die längst vor der Entstehung des Begriffs als Kitt zwischen unterschiedlichen Systemen dienten. Lange Jahre waren sie jedoch extrem unflexibel und nur mit hohem Programmieraufwand an die Unternehmensabläufe anpaßbar. Das änderte sich radikal, als Groupware-Produkte wie "Notes" auf Basis von E-Mail-Verfahren und datenbankähnlichen Replikationsmechanismen (beide gehören ebenfalls zur Middle- ware) technische Wege wiesen, die inzwischen die Reputation von Workflow-Systemen massiv aufgewertet haben. Außerdem wurden inzwischen durch die Workflow Management Coali- tion eine Reihe von Schnittstellen definiert, mit deren Hilfe Anwendungen eingebunden werden können. Insbesondere die Industrie bezieht zum Beispiel über Electronic Data Interchange (EDI), ein standardisiertes Verfahren für den elektronischen Geschäftsverkehr, Anwendungen ihrer Zulieferfirmen ein. Aber auch Windows- und Web-Anwendungen lassen sich über Active X in die Abläufe etwa des betriebswirtschaftlichen R/3-Pakets der SAP AG integrieren.
Middleware-Einsatz
-Am Front-end: E-Mail, Workflow, Groupware, Terminal-Emulationen.-Datenzugriffe: Gateways, Datenbank-Zugriffssprachen (SQL, ODBC), Datenreplikation, Daten-Transformation und -Verdichtung (Data-Warehousing).-Transaktionen: Remote Procedure Calls (RPCs), asynchrone DV mit Messaging und Queuing, Transaktionsverarbeitung, Objektkommunikation (Object Reqest Broker),-World Wide Web: Schnittstellen vom Web zu anderen Anwendungen etwa durch Common Gateway Interface (CGI) und Internet Inter ORB Protocol (IIOP).-Netzdienste: Verzeichnisse, Naming-Services, Persistenzprüfungen, Sicherheits- und Zugriffsmechanismen.