Middleware bezeichnet zunächst das allgemeine Abstraktionskonzept einer Softwareschicht, die zwischen heterogenen, auf unterschiedlichen Plattformen laufenden und über Netzwerke verbundenen Anwendungssystemen und Datenquellen vermittelt und so eine Integration zu unternehmens-/ organisationsübergreifenden Anwendungen ermöglicht (siehe Abbildung 1). Darüber hinaus wird auch die Klasse aller verfügbaren Software-Technologien, die in irgendeiner Form zur Erfüllung dieser Funktion beitragen, als Middleware bezeichnet.
“Metadata is data about data; Middleware is software about software.” [Gall]
Abb. 1: Middleware als abstrakte Zwischenschicht
Entwicklungsgeschichte und Motivation
Hinter der Idee der Middleware steht die Kernproblematik der Integration von proprietären, für unterschiedliche Zwecke entwickelten, verteilten und auf unterschiedlichen Hardware/Software-Plattformen laufenden Anwendungen – sog. Legacy-Applikationen – und deren Daten. Gerade im Internetzeitalter, wo es zunehmend gilt, aus bestehenden Funktionen und Bausteinen, die in einzelnen Anwendungen realisiert sind, ganzheitliche, integrierte Gesamtanwendungen zu entwickeln, werden SW-Konzepte und -Technologien benötigt, die eine fortlaufende Anpassung und Weiterentwicklung ermöglichen und von den Details der jeweiligen Realisierung abstrahieren. Wesentliches Ziel von Middleware ist somit die Beherrschung der Komplexität bei verteilten Anwendungssystemlandschaften durch Einführung einer einheitlichen abstrakten Zwischenschicht.
Diese Grundidee geht bereits in die sehr frühen Phasen der Informatik zurück und ist auf der berühmten NATO-Konferenz 1968 [Naur, Randell 1968], die den Terminus Software-Krise hervorbrachte, als Begriff erstmals veröffentlicht. Aber erst mit stärker aufkommender Vernetzung und Verteilten Systemen und der damit verbundenen Komplexität zunehmend unternehmens- und organisationsübergreifender Anwendungen entwickelte sich Middleware ab den 1980er-Jahren zu einem wichtigen und zentralen Forschungs- und Entwicklungsgegenstand der (Wirtschafts-) Informatik. Seit den 1990er-Jahren sind eine Reihe sowohl kommerzieller als auch nicht-kommerzieller Middleware-Ansätze und Produkte verfügbar, die heute die Basis für die Entwicklung komplexer verteilter Anwendungen sind.
Anforderungen und Kernfunktionen
Middleware muss allgemein eine Reihe von Diensten und Schnittstellenfunktionen anbieten, die es verteilten Applikationen/Prozessen erlauben, über Netzwerkgrenzen hinweg zu interagieren und zu kooperieren. Wichtige Aspekte hierbei sind:
-
Bereitstellung lokaler Transparenz (Ortstransparenz), d.h. Verbergen der Verteilung sprich der Tatsache, dass die Gesamtanwendung aus mehreren verteilten Komponenten aufgebaut ist
-
Unabhängigkeit von den Details der Netzwerke und Kommunikationsprotokolle
-
Unabhängigkeit von den Details der Betriebssysteme sowie der Hardware
-
Interoperabilität unterschiedlicher Applikationen
-
Programmiersprachen-Unabhängigkeit
-
Bereitstellung eines einheitlichen, standardisierten Satzes von Schnittstellenfunktionen, die es Entwicklern und Integratoren ermöglichen, aus den verteilten Komponenten und Funktionen wieder verwendbare, portierbare und anpassbare Gesamtapplikationen zu generieren
Kategorien
Da Middleware mehr für ein Abstraktionskonzept als für eine bestimmte Technologie steht, besteht keine völlig geschlossene und einheitliche Beschreibung und Eingrenzung der damit bezeichneten Ansätze. Grundsätzliche Möglichkeiten der Unterscheidung von Middleware sind proprietäre gegenüber standardbasierten sowie asynchrone gegenüber synchronen Ansätzen.
Darüber hinaus kann Middleware bezüglich des zugrunde liegenden Paradigmas der Integration in folgende Kategorien unterteilt werden:
-
Funktionsaufruf-orientiert / Remote Procedure Call RPC / Remote Method Invocation RMI: Ermöglicht einer nutzenden Anwendung (Client) den Aufruf einer entfernten Funktion/Methode, die von einer anbietenden Anwendung (Server) über das Netzwerk zur Verfügung gestellt wird.
-
Nachrichten-orientiert / Message Broker:
Lose Kopplung von Applikationen über den Austausch von Nachrichten (Publish/ Subscribe). -
Datenhaltungsorientiert / Remote Database Access:
Anfragevermittlung an verteilte Datenhaltungssysteme / Datenbanken. -
Transaktions-orientiert / Transaction Process (TP) Monitore:
Koordiniert systemweit den Zugriff auf Ressourcen (primär Datenbanken und Dateien) über das Prinzip der Transaktion durch Einhaltung der ACID-Kriterien. -
Objektorientiert / Object Request Broker:
Erweiterung des objektorientierten Programmiermodells auf verteilte Objekte, die netzwerk- und teilweise programmiersprachenübergreifend Anwendungen verbinden (verteilte Objektmodelle). -
Komponenten-orientiert:
Setzen auf dem verteilten Objektmodell auf und erweitern dies um die Vision einer zur Laufzeit erzeug- bzw. erweiterbaren Gesamtanwendung, die im Wesentlichen durch „Verdrahtung“ von frei am Markt verfügbaren Komponenten (Business Components) entsteht.
Literatur
Britton, Chris ;Bye, Peter: IT Architectures and Middleware: Strategies for Building Large, Integrated Systems. Amsterdam : Addison-Wesley, 2004.
Gall, Nick: The Origin (Coining) of the Term Middleware http://ironick.typepad.com/ironick/2003/11/the_origin_coin.html (Abruf 30.08.2011).
Kaib, Michael: Enterprise Application Integration. Wiesbaden : Deutscher Universitäts-Verlag, 2002.
Linthicum, David S.: Enterprise Application Integration. Amsterdam : Addison-Wesley, 2000.
Naur, Peter ; Randell, Brian(Ed.): NATO Software Engineering Conference, Garmisch 1968, NATO Scientific Affairs Division, Brussels.
