Middleware

"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

Autor