Middleware: COM versus Corba/Ein Überblick über Technik und Anwendung

In heterogenen Umgebungen geht nichts ohne Middleware

13.03.1998

Heute definiert sich Middleware allgemein als ein Bündel aus Protokollen, Schnittstellen und Programmen, die dafür sorgen, daß Anwendungen, Daten und Menschen auf einem Rechner sowie ü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. So wurde die elektronische Nachrichtenvermittlungsstelle zur Grundlage für Middleware-Anwendungen, etwa Workflow-Systeme und Groupware.

In der Kommunikation zwischen Anwendungen sind ablauforientierte Methoden wie Transaktionssysteme (TP-Monitore) oder Datenbank-Anwendungen und nachrichtenorientierte Systeme zu unterscheiden. Bei letzteren tauschen Programme nach dem Vorbild von E-Mails Nachrichten aus, lösen damit aber gleichzeitig Aktionen aus. In diese Kategorie gehören Produkte, die auf Remote Procedure Calls (RPCs) beruhen, und vor allem alle Objekttechniken. Die Trennung ist nicht immer ganz scharf, denn mit RPCs lassen sich durchaus Transaktionen organisieren. Eine Randgruppe bilden die Bildschirm-Emulationen, wobei die Clients, in der Regel PCs, wie klassische Terminals für Großrechner oder Midrange-Hosts eingesetzt werden.

Die bedeutendste Datenbank-Middleware ist die Abfragesprache, insbesondere SQL. Hier werden von einem Client-System oder von einem Anwender übers Netz vom Datenbank-Server Informationen abgerufen. Kompliziert wird dieses Verfahren, wenn der Endanwender nicht mehr wissen soll, von welchem der angeschlossenen Server, auf denen teilweise unterschiedliche Datenbank-Systeme arbeiten, die Information abgerufen wird. Hier helfen entweder fest definierte Gateways oder flexiblere Lösungen wie Microsofts auf ei- nem offenen SQL-Standard basierendes Schnittstellen-Bündel Open Database Connectivity (ODBC) und neuerdings das ebenfalls aus Redmond stammende OLE-DB.

OLE-DB geht weit über den ODBC-Ansatz hinaus. Über diese Komponente lassen sich Daten nicht nur abrufen, sondern über Scripting-Sprachen auch Anwendungen erstellen. Über solche Programme sind darüber hinaus nichtrelationale Informationen wie Texte oder Videosequenzen integrierbar.

Insofern kann OLE-DB als das Microsoft-Konzept für die im Web-Zeitalter geforderte multimediale Datenhaltung gelten. Während Informix, Oracle und IBM solche nichtstrukturierten Datentypen über objektrelationale Datenbanken (Stichwort: Universal Server) in ihre Datenbank-Systeme holen, läßt Microsoft solche Informationen - vereinfacht gesagt -, wo immer sie sich in einem Windows-Netz befinden. Sie werden bei Bedarf über eine OLE-DB-Anwendung eingebunden. Auch Sybase arbeitet hier mit Middleware, allerdings auf Basis der als besonders schnell geltenden Gateways.

Von anderen Anwendungen unterscheidet sich Middleware durch die Nähe zur Netzwerktechnik. Entsprechend der dort üblichen Funktionseinteilung nach dem OSI-Modell konzentriert sie sich auf die vier oberen Schichten und darunter besonders auf die Ebenen sechs und sieben für Darstellung und Anwendung. Dabei setzt Middleware jedoch immer auf tiefere Schichten auf. Dafür ist ihr Kommunikations-Layer zuständig (siehe Abbildung). Man kann sagen, daß Middleware eine Netzinfrastruktur auf Anwendungsebene herstellt.

Ihren Boom verdankt die Middleware der Open-Systems-Bewegung, die Ende der 80er Jahre im Unix-Umfeld entstand. Deren zentrales Ziel, die 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 bis dato 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 Techni-ken laufen dem Open-Systems-Trend entgegen - ein zu Beginn des Jahrzehnts wichtiges Argument - und sind zudem nur punktuell einsetzbar. Eine ausgedehnte DV-Umgebung braucht daher viele solcher Lösungen, wodurch sich das Komplexitätsproblem verschärft. Es gibt auch heute noch einen großen Markt für derartige Punkt-zu-Punkt-Lösungen, weil sie oft leistungsfähiger sind als etwa objektorientierte Middleware-Standards.

Dennoch wurde 1992 von den Anwenderunternehmen die Einführung eines ersten Standards durch die Open Software Foundation (OSF) als willkommene Hilfe zur Handhabung ihrer heterogenen DV-Landschaften begrüßt. Das Konsortium machte den Begriff Middleware populär und stellte mit dem Distributed Computing Environment (DCE) eine offene Infrastruktur für heterogene DV-Umgebungen vor. Im Kern handelt es sich dabei um einen Remote Procedure Call (RPC) mit begleitenden Dien-sten, die etwa durch vereinheitlichte Adreßnamen (Naming Services) dafür sorgen, daß Funktionsaufrufe über heterogene Netze hinweg ohne großen administratorischen Aufwand möglich sind. DCE gilt noch heute als Inbegriff der Middleware, während sich das darauf aufbauende Distributed Management Environment (DME) nie etablieren konnte.

Microsoft entdeckt einen neuen Markt

Gleichzeitig mit der Einführung des ersten Standards entdeckte Microsoft die mit dem Middleware-Konzept verbundenen Chancen. Firmenchef Bill Gates verkündete die Absicht, Windows werde durch die Windows Open Services Architecture (Wosa) zum universalen Client für den unternehmensweiten Einsatz avancieren.

Einige Wosa-Komponenten verschwanden rasch in der Versenkung. Dazu gehört "Windows at Work", bei dem geplant war, das Betriebssystem in Heim- und Büro-PCs einzubauen. (Es wurde jetzt dank dem abgespeckten "Windows CE"-Betriebssystem und preisgünstigerer Prozessorleistung wieder ausgegraben.) Auf Anhieb durchgesetzt hat sich dagegen die ODBC-Komponente. Die Datenbank-Middleware beruht auf einem Treiberkonzept, das Microsoft-Anwendungen den Zugang zu den großen Unternehmensdatenbanken verschaffte. Seit etwa einem Jahr propagiert Microsoft aber bereits den ODBC-Nachfolger OLE-DB.

Middleware wird vermarktbar

Die Lawine war losgetreten, so daß sich nun auch Anbieter Gehör verschaffen konnten, deren Middleware sich zuvor nicht vermarkten ließ, weil ihre Produkte keinen zugkräftigen Namen trugen. So hatte die Darmstädter Software AG bereits Ende 1990 ein Paket von Lösungen für heterogene Umgebungen geschnürt, die sie "Entire Function Server Technology" nannte.

Die SAG bezweckte, "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, etwa zu SQL-Anbindungen und anderen Datenbank-Gateways. Daher zählen heute Datenbankspezialisten wie Sybase und Oracle zu den großen Middleware-Anbietern. Doch inzwischen hat sich die Software AG wieder auf ihr Know-how besonnen und Microsofts DCOM-Technik auf Unix sowie auf Mainframes portiert. Die entsprechenden Dienste sollen im Rahmen der in "Entire X" umbenannten Middleware-Produkte auf den Markt kommen.

Schon länger im Kielwasser von Microsoft schwimmt Intersolv mit einer Vielzahl von ODBC-Treibern. 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 auf sie 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.

Objekte und Komponenten

Für die Middleware besonders zukunftsträchtig wurde die 1990 in aller Stille gegründete Object Management Group (OMG). Programm der Herstellerorganisation war ursprünglich, eine industrieweit anerkannte Definition dessen aufzustellen, was ein Objekt ist. Schon bald wurde diese Absicht um das Ziel erweitert, Techniken zu schaffen, die heute "Wrapping" heißen und mit denen sich Altanwendungen als Objekt in andere Umgebungen einbinden lassen.

Das bekannteste Ergebnis der OMG-Bemühungen ist die inzwischen als Standard geltende Common Object Request Broker Architecture (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.

Gerangel um Corba und DCOM

Als Herausforderer des Corba-Standards haben sich 1996 die Microsoft-Technik Distributed Component Object Model (DCOM) beziehungsweise deren Ausprägungen OLE und Active X herauskristallisiert. Heute reklamiert die Gates-Company, daß ihre Technik etwa gleichzeitig mit Corba, nämlich 1992 entstanden sei. Tatsächlich ist damals die Aufgabe von OLE, Microsoft-eigene Desktop-Anwendungen zu integrieren, auf die Windows-Software anderer Hersteller ausgedehnt worden. Außerdem war die Anwendungskommunikation bis zur Freigabe von Windows NT 4.0 auf einen Rechner begrenzt. Corba dagegen war von Anfang an für die Anwendungskommunikation in heterogenen Netzen konzipiert.

Entsprechend ihrer Satzung hat die OMG versucht, gemeinsam mit Microsoft 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 jedoch dafür, DCOM von der Software AG auf andere Plattformen portieren zu lassen und dort mit Corba in Konkurrenz zu treten. Die publizitätsträchtige Gründung einer Active X Group durch Microsoft innerhalb des Standard-Konsortiums The Open Group hat nach über eineinhalb Jahren ihrer Existenz die Verbreitung von Active X auf möglichst viele Plattformen noch immer nicht in Angriff genommen.

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.

Die leise Rückkehr der Transaktionssysteme

Transaktionen leiden allerdings unter dem Nachteil, daß sie bei einer Unterbrechung von neuem aufgesetzt werden müssen. Hier schufen in den vergangenen zwei Jahren asynchrone TP-Varianten wie IBMs "MQ Series" Abhilfe. Wie bei Workflow-Systemen können Anwendungen in einer Art "Postfach" darauf warten, bis der Benutzer Zeit findet, sie weiterzubearbeiten. Inzwischen hat auch Microsoft diesen Markt erkannt und bietet ein System mit der Bezeichnung "Transaction Server" an. Außerdem dehnt sich die Auseinandersetzung um Corba oder COM inzwischen auch auf dieses Feld aus, weil die Anbieter von Transaktionssoftware im Rahmen von Produktmodernisierung auf diese Transport- mechanismen zurückgreifen. So verwendet etwa Tuxedo-Eigner Bea Systems in Kürze Corba auf Unternehmensebene und bindet Microsoft-Systeme über eine ursprünglich von Digital Equipment geschriebene Corba-COM-Brücke ein. 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 unfle- xibel 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 Replika- tionsmechanismen (beide gehören ebenfalls zur Middleware) technische Wege wiesen, die inzwischen die Reputation von Workflow-Systemen stark aufgewertet haben. Außerdem hat inzwischen die Workflow Management Coalition eine Reihe von Schnittstellen definiert, mit deren Hilfe sich Anwendungen einbinden lassen. 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.

Angeklickt

Die Diskussion um die Broker-Techniken von Microsoft und der Object Management Group (OMG) sind eine an den Realitäten vorbeizielende Verengung des Themas Middleware. Dieses umfaßt ein Anwendungsspektrum, zu dem E-Mail-Funktionen, Workflow und Datenbankzugriffe ebenso gehören wie Transaktionsverarbeitung, Web-Integration und Netzdienste. Gegeben hat es Middleware lange bevor Anfang der 90er Jahre der Begriff geprägt wurde. Im Rahmen des damals beginnenden Client-Server-Booms wuchs sich die Integration heterogener Systeme zum dringlichen Problem aus.

Middleware-einsatz

-Am Front-end: E-Mail, Workflow, Groupware, Terminal-Emulationen.

-Datenzugriffe: Gateways, Datenbank-Zugriffsmethoden (SQL, ODBC, OLE-DB), Datenreplikation, Datentransformation und -verdichtung (Data-Warehousing).

-Transaktionen: Funktionsanrufe (RPCs), asynchrones Messaging und Queuing, Transaktionsverarbeitung, Objektkommunikation (Object Request Broker),

-World Wide Web: Schnittstellen vom Web zu anderen Anwendungen, etwa durch Common Gateway Interface (CGI) und Internet Inter ORB Protocol (IIOP), E-Business (Corba, Active-X etc.).

-Netzdienste: Verzeichnisse, Naming-Services, Persistenzprüfungen, Sicherheits- und Zugriffsmechanismen.