Mit Middleware ist eine zusätzliche Schicht in einer komplexeren Software-Struktur gemeint, deren Aufgabe es ist, die Zugriffsmechanismen auf unterhalb angeordnete Schichten zu vereinfachen und die Details deren Infrastruktur nach außen hin zu verbergen. Dazu stellt die Middleware Funktionen zur Verteilung sowie Dienste zur Unterstützung der Anwendung bereit. Dahingehend ist das Ergebnis einer Middleware die Entlastung der Anwendungsprogramme und außerdem, durch eine höhere Produktivität den Entwicklungsprozess zu optimieren.
Man unterscheidet zwei verschiedene Kategorien von Middleware: kommunikationsorientierte sowie anwendungsorientierte Middleware. Die kommunikationsorientierte Middleware stellt zunächst eine logische Infrastruktur zur Kommunikation bereit. Die anwendungsorientierte Middleware bietet über den Rahmen der Kommunikation hinaus eine Erweiterung der Laufzeitumgebung, Dienstkomponenten sowie ein Komponentenmodell. Durch den Aufwand einer zusätzlichen Schicht trägt die Einführung einer Middleware nicht positiv zu einer höheren Performance des Gesamt-Systems bei. Bekannte Middleware-Produkte sind die MQSerie von IBM, der Websphere Application Server oder die SAP Exchange Infrastructure von SAP.
Die konkrete Ausgestaltung und Komplexität einer Middleware hängen im Wesentlichen von den Diensten, die sie der Anwendung zur Verfügung stellt. Die implementierten Middleware-Technologien sind daher auch unterschiedlich, da es diesbezüglich keine exakten Vorgaben gibt. Das Software Engineering Institute ( SEI) geht zum Beispiel bei der Kategorisierung von Middleware davon aus, TP- Monitore, Message oriented Middleware ( MOM), Remote Procedure Calls ( RPC) und Object Request Broker ( ORB) explizit zu unterscheiden. Hier zeigt sich auch, dass sich im Umfeld von Middleware eine ganze Reihe von Standardisierungen durchgesetzt hat. Die vorliegenden Erläuterungen gehen von einer Einteilung in folgende Kategorien aus: Kommunikationsorientierte Middleware und anwendungsorientierte Middleware.
Kommunikationsorientierte Middleware definiert die Infrastruktur zur Kommunikation verteilter Anwendungen über ein verteiltes System. Hier gehören die grundlegende Erweiterung der Kommunikationsinfrastruktur durch Dienste und Laufzeitaspekte wie u.a. Threads, Techniken zur Datentransformation (Marshalling, Formate) und Mechanismen zur Fehlerbehandlung zu den Aufgaben.
Die Abbildung zeigt, dass kommunikationsorientierte Middleware direkt als eigenständige Schicht auf dem Betriebssystem aufsetzt und dessen Funktionalität flexibel ergänzt. Ein wesentliches Element ist die Behandlung von unterschiedlichen Datenformaten, damit alle beteiligten Komponenten die zu verarbeitenden Daten gleich interpretieren können. Die Aufbereitung der Daten in ein Format zur Übertragung wird als Marshalling bezeichnet, währenddessen die Wiederherstellung von Daten Unmarshalling genannt wird. Ein Beispiel in diesem Zusammenhang ist die Common Data Representation ( CDR) von CORBA.
Die Middleware kann sowohl synchrone wie asynchrone Kommunikationsmodelle unterstützen, und ist vollkommen unabhängig von der Anwendung für die diese Dienste bereitgestellt werden. Dabei wird häufig synchrone Middleware in Umgebungen mit hoher Interaktion zwischen den Anwendungen eingesetzt. Die Verbindung des Kommunikationsmodells mit einem Programmierparadigma wird durch ein Programmiermodell hergestellt. Als Programmierparadigmen kommen vorwiegend das prozedurale sowie das objektorientierte Paradigma zum Einsatz, so dass die Middleware die folgenden Programmiermodelle verwendet:
- Remote Procedure Calls (RPC), prozedural, entfernter Aufruf einer Prozedur, unterstützt synchrone Kommunikation.
- Remote Method Invocation ( RMI), objektorientiert, Basis ist Java, unterstützt synchrone Kommunikation.
- Message Oriented Middleware (MOM), ein Nachrichten-orientiertes Modell, Prinzip der Warteschlangen, unterstützt die asynchrone Kommunikation.
Anwendungsorientierte Middleware ergänzt die kommunikationsorientierte Middleware um eine Laufzeitfunktionalität, Spezifische Dienste für die Anwendungsschicht sowie häufig auch um ein Komponentenmodell.
Die Abbildung verdeutlicht das Prinzip der Anwendungsorientierten Middleware.
Die Laufzeitumgebung bietet in Ergänzung der Strukturen eines verteilten Betriebssystems u.a. die Verwaltung von Verbindungen, Konzepte zur Nebenläufigkeit, Verfügbarkeits-Szenarien bei Ausfall einer Komponente sowie erweiterte Sicherheits-Funktionen.
Eine anwendungsorientierte Middleware stellt implizit über die Laufzeitumgebung sogenannte Dienste zur Verfügung, auf die mittels spezieller Programmierschnittstellen ( API) zugegriffen werden kann. Mögliche Dienste können sein: Namensdienste, z.B: Interoperable Naming Service ( INS), Sitzungsverwaltung, Persistenzdienste oder Transaktionsverwaltung.
Die Komponentenmodelle definieren Anwendungsobjekte als Komponenten und stellen diese für eine Komponenten-Laufzeitumgebung bereit. Bekannte Komponentenmodelle sind J2EE oder . NET.
Anwendungsorientierte Middleware lässt sich hinsichtlich ihrer konkreten Implementierungen in folgende Technologien unterscheiden:
- Object Request Broker (ORB), basiert auf dem Programmiermodell für den entfernten Aufruf von Methoden, bietet flexible Dienste an jedoch ohne eine eigene Laufzeitumgebung, ein Beispiel ist CORBA.
- Application Server, unterstützen die Logik der Anwendung (Middle-Tier), stellen eine Kommunikationsinfrastruktur, flexible Dienste sowie zusätzlich eine Laufzeitumgebung und ein Komponentenmodell zur Verfügung.
- Komponenten-basierte Middleware, ergänzen Application Server zu einer geschlossenen Verteilungsplattform mit zugehörigen Komponentenmodellen, Bekannte Umgebungen sind J2EE, die .NET- Plattform mit den Komponentenmodellen COM und DCOM oder CORBA mit dem Komponentenmodell CCM.
Ein typisches Beispiel für den Einsatz kommunikationsorientierter Middleware zeigt die Abbildung im Zusammenhang mit verteilten Systemen. Ursprünglich bieten verteilte Systeme - auch als Rechnernetze bezeichnet- nur grundlegende Kommunikationsdienste sowie einfache Maßnahmen zur Sicherung und Fehlerbehandlung. Setzt dabei eine Anwendung direkt auf dem Protokollstack des verteilten Systems auf, ist das sicherlich vorteilhaft für eine hohe Performance, bedeutet aber gleichzeitig einen hohen Aufwand in der Implementierung und Steuerung. Hier kann durch Definition einer Middleware - als eine zusätzliche Software-Schicht - die Komplexität aus Sicht der Anwendung minimiert werden. Hier wird also durch die Middleware das logische Muster der Interaktion zwischen den Partnern in verteilten Systemen definiert, so dass die ursprüngliche Infrastruktur der Anwendung selbst verborgen bleibt. Dabei werden von der Middleware sowohl asynchrone wie synchrone Formen der Kommunikation unterstützt. Das Beispiel zeigt auch die für die Anwendung sogenannte Intelligente Aufruf- Schnittstelle (auch IDL, Interface Definition Language). Die Middleware definiert darüber hinaus Funktionalitäten wie die Nebenläufigkeit von Anwendungen und die Verwaltung von Daten, die Sicherheit und das Management sowie die Verwaltung von Namen und Verzeichnisdiensten.
Die Ansätze der Hersteller von Middleware sind ganz unterschiedlich. Während beispielsweise .NET von Microsoft ganz auf die Integration von Middleware und Betriebssystem baut, gehen andere Hersteller wie IBM oder Sun den umgekehrten Weg der Trennung von Middleware und Betriebssystem, um eine Interoperabilität mit verschiedenen Herstellern gewährleisten zu können. Auch sind die unterstützten Konzepte abhängig vom jeweils bedienten Marktumfeld, was für eine gewisse Vielfältigkeit von Middleware spricht. Andererseits können geschützte Implementierungen eines bestimmten Herstellers zur Abhängigkeit von dessen Produkt führen. Letztendlich ist Middleware ein entscheidendes Merkmal einer spezifischen Software-Architektur. Abschließend noch eine kurze Zusammenstellung populärer Middleware-Produkte: SAP Exchange Infrastructure, IBM MQSerie, WebSphere Application Server (IBM), CORBA (Object Management Group, OMG), Enterprise Service Bus (Oracle) und Tibco (TIBCO).