Der Markt verlangt immer mehr nach offenen Systemarchitekturen, die vorhandene IT-Investitionen integrieren und die Kompatibilitaet mit den Neuanschaffungen sicherstellen (Interoperabilitaet) sowie aufgrund von implementierten offenen Regelwerken beziehungsweise deren Standard-Schnittstellen dem Anwender tatsaechlich die freie Produktwahl ermoeglichen. Die Loesung, so Ingo Claussen*, heisst Middleware.
Middleware-Produkte haben ihre Bezeichnung daher, dass sie die Schicht zwischen Anwendungs- und Systemsoftware-Ebene bilden. Dazu gehoert auch, dass sie all jenen Anwendungen ueber Application Programming Interfaces (APIs) produktspezifische Dienste anbieten, die ueber die entsprechenden API-Implementierungen verfuegen. Ueber diese Schnittstellen unterstuetzen Middleware- Produkte Client-Server-Architekturen sowie deren unternehmensweites Zusammenwirken. Damit werden die heterogenen Systeme ueber Middleware aus Sicht des Anwenders zu einem Gesamtsystem zusammengefuegt.
Beispiele fuer Middleware-Produkte sind in diesem Sinne standardisierte Benutzeroberflaechen, definierte Mechanismen fuer den Datenaustausch zwischen Applikationen beziehungsweise Objekten, Objektkonvertierungen, Datenbankzugriffe, ueber APIs geoeffnete und unterschiedlich einsetzbare Mail- und Ablagesysteme, Vorgangsbearbeitung sowie einheitliche Netzwerk- Services wie fuer Dateiverwaltung und Drucken im Netz.
Middleware-Ansaetze hat es in integrierten Loesungen immer schon gegeben. Sie waren jedoch nur herstellerbezogen und arbeiteten mit streng unter Verschluss gehaltenen APIs. Damit wurde es praktisch unmoeglich, dass die am Markt angebotene Software sich dieser Middleware-Produkte bedienen und mit den anderen Anwendungen zusammenarbeiten konnte. Das wurde erst moeglich durch die Offenlegung herstellereigener Definitionen sowie die Implementierung von offenen Standard-APIs internationaler Normungsgremien in die Middleware.
Architekturen fuer eine einheitliche Middleware
Die 80er Jahre waren bei vielen Unternehmen gekennzeichnet durch traditionelle zentrale
Groder verteilte Systeme nur flankierend zugeordnet wurden. In dieser Zeit entstanden ueberall Inseln der mittleren Datentechnik, die schliesslich durch einen immer groesseren PC-Wildwuchs ergaenzt wurden, da PC-Beschaffungen haeufig ad hoc und unabgestimmt erfolgten.
Einheitliche Regelungen fuer Produktentscheidungen waren ebenso selten, wie ein Datenaustausch mit anderen Abteilungen erwogen wurde. Da viele der PCs eher aus Prestigegruenden gekauft wurden, spielten auch technisch-funktionale Gesichtspunkte eine eher nachgeordnete Rolle.
Dadurch ergaben sich Wissensinseln mit zueinander inkompatiblen Loesungen. Der Datenaustausch war schwierig, da es keine Informationskanal-Systeme, dafuer aber unterschiedliche Protokolle gab. Diese babylonischen Verhaeltnisse wurden zum Teil zunaechst durch herstellerspezifische Kommunikationsvereinbarungen ueber einheitliche Protokolle und Austauschformate, spaeter dann mehr und mehr durch die Implementierung offener Standards unabhaengiger Normungsgremien in Ordnung gebracht. Dabei spielt Middleware - nicht nur im Desktop- Bereich - eine Schluesselrolle.
Einheitliche Praesentationen der Anwendungen werden immer wichtiger. Ueber das Middleware-Produkt "Praesentation" wird das Lernen neuer Anwendungen durch Erinnerung und Intuition beschleunigt und die Bestrebung "Einmal lernen, ueberall nutzen" unterstuetzt. Anbieter von Betriebssystemen fuer intelligente Arbeitsplaetze haben sich darauf eingestellt und die Window-Manager im Betriebssystem als Middleware eingebunden. Beispiele sind Microsofts MS-Windows, der Presentation Manager fuer OS/2 von der IBM und die X-Window-Umgebung in der Unix-Welt.
Mit solchen Benutzerumgebungen definieren die Hersteller eine Basis, auf die alle Applikationsanbieter aufsetzen muessen. Fuer die Anwender hat das den Vorteil, dass die Anwendungen hinsichtlich look and feel vereinheitlicht sind.
Weiterhin sind teilweise auch Schnittstellen und Mechanismen fuer den Datenaustausch zwischen den Applikationen definiert, die fuer Kompatibilitaet von Anwendungen innerhalb der Front-end-Systeme sorgen. Schliesslich werden diese Clients mit Konventionen unterschiedlichen Leistungsumfanges an Server angebunden, die ihnen Middleware-Funktionen als Server-Dienste erbringen. Beispiele hierfuer sind TCP/IP, NFS, LU 6.2, CPI-C, LAN Manager, Client-Server-Produkte mit den Schnittstellen gemaess Wosa von Microsoft etc.
Ueber diese APIs kommuniziert die Front-end-Applikation mit dem korrespondierenden Middleware-Back-end auf dem Server, integriert dessen Funktionen in den eigenen Anwendungsprozess und erweitert damit seinen originaeren Leistungsumfang. Aufgrund der unterschiedlichen Anforderungen muessen diese APIs je nach Bedarfsfall sowohl einen moeglichst einfachen Zugriff auf Grundfunktionen ermoeglichen als auch die komplette Funktionalitaet der Middleware bereitstellen.
Middleware fuer Server-Systeme
Server leisten ihren Clients ad hoc Dienste wie das Versenden von Nachrichten und Dokumenten, binden die elektronischen Nachrichten an entsprechende Postdienste an, unterstuetzen gemeinsame Kalender und schlagen die Verbindung zu anderen Abteilungs- und Host- Systemen.
Wo der dedizierte Service ueber ein API von unterschiedlichen Anwendungen genutzt werden kann, wandelt er sich zur Middleware. Dies ist zum Beispiel dann der Fall, wenn der Mail- Transportservice neben der Mail-Oberflaeche auch anderen Anwendungen zugaenglich wird. Aus dem Nachrichtenaustausch von Benutzern wird ein universelles elektronisches Messaging-System mit einem breiten Anwendungsfeld. Das Spektrum reicht dabei von einfachen Anwendungsformen, wie etwa der Moeglichkeit, direkt aus einem Programm heraus Post zu versenden oder zu empfangen, bis hin zu komplexen Groupware-Applikationen wie Gruppenkalendern oder Workflow-Loesungen.
Uebergreifende Middleware-Ansaetze
Wie ausgefuehrt, zielen viele Middleware-Produkte auf konkrete Plattformen. Anders ist es mit den OSF-Techniken Distributed Computing Environment (DCE) und Distributed Management Environment (DME) fuer verteilte Datenverarbeitung.
DCE stellt lokalen Applikationen Komponenten wie den Remote Procedure Calls (RPC), ein verteiltes Dateisystem, ein Directory nach X.500 und Sicherheitsdienste zur Verfuegung. Damit ermoeglicht die Technik ueber einheitliche Regeln den Zugriff auf verteilte Ressourcen und laesst das Netz aus Sicht des Anwenders als ein System erscheinen. Da diese Schnittstellen offengelegt und nicht auf eine Plattform fokussiert sind, sondern auf allen abgebildet werden koennen, offeriert DCE einen ganzheitlichen Ansatz fuer systemunabhaengige Middleware.
Aehnliches gilt fuer DME. Damit soll eine Umgebung fuer das Management verteilter Systeme und Anwendungen geschaffen werden. Das Konzept geht von miteinander kommunizierenden Objekten aus, wobei als einheitliches API fuer die Objekt-Objekt- Kommunikation die Common Object Request Broker Architecture (Corba) der Object Management Group benutzt wird. Nach den Corba- Richtlinien implementierte Objekte sind in der Lage, innerhalb eines Netzes mit anderen Objekten gleichen Designs zusammenzuarbeiten.
Schliesslich werden neue Online-Transaction-Processing- (OLTP-)Technologien, basierend auf Standards offener Systeme, und Client-Server-Architekturen kuenftig ueber verteilte Transaktionsmonitore neue OLTP-Applikationen ermoeglichen, die innerhalb einer Transaktion alle auf verteilten Servern residierenden Ressourcen im Unternehmen einbinden, die im Rahmen einer Aufgabenstellung genutzt werden muessen.
Informations-Manager haben heute die globale Integration ihrer Organisation im Auge. Einheitliche Middleware soll dafuer sorgen, dass die Anwender auf alle Ressourcen zugreifen koennen, die sie fuer ihre Arbeit benoetigen. Bei den dafuer noetigen APIs sollte der Anwender in Erwaegung ziehen, dass nur international anerkannte Standards die Gewaehr bieten, dass Entscheidungen nicht ueber den Haufen geworfen werden muessen, wenn die Technik sich aendert oder der Anbieter Konkurs anmelden muss.
Applikationen ohne Schnittstellen zu Middleware-APIs muessen Middleware-Funktionen (F1-F3) redundant selbst erbringen.
*Ingo Claussen ist Marketing-Mitarbeiter der Siemens-Nixdorf Informationssysteme AG in Paderborn.