MÜNCHEN: Middleware erweist sich mehr und mehr als die lang gesuchte Problemlösung beim Einsatz von verteilten Applikationen - vor allem wenn es um die Verbindung zwischen vorhandenen und neu entwickelten Anwendungen geht. Auch Softwarehäuser und Systemintegratoren, die Middleware-Lösungen in Unternehmen implementieren, kommen laut Jürgen Wasem-Gutensohn* zu einer ähnlichen Bewertung.Ed Acley, Research Director Middleware Services bei IDC, faßt die aktuelle Situation in diesem Markt so zusammen: "Die Anwender kaufen zunehmend Middleware, um die Komplexität von verteilten Applikationen in heterogenen Umgebungen zu reduzieren." Unterstützt wird diese Aussage durch aktuelle Marktdaten. Demnach war 1997 ein hervorragendes Jahr für den Middleware-Bereich. Der Umsatz stieg um 28 Prozent auf etwas mehr als 1,7 Milliarden Dollar. Auch in den nächsten Zukunft können die Hersteller mit einer ähnlich positiven Geschäftsentwicklung rechnen. Für das Jahr 2002 prognostiziert IDC ein Middleware-Marktvolumen von sieben Milliarden Dollar.
Electronic Business als Treibstoff
Diesen allgemeinen Trend bestätigt auch Mike Gilpin, Senior Analyst bei der Giga Information Group: "Aus Gesprächen mit Anwendern wissen wir, daß sich eine stetig wachsende Zahl von Unternehmen im Bereich Electronic business engagiert. Dies fördert ganz massiv die Nachfrage nach Middleware-Lösungen. Denn diese bewirken, daß alle Elemente der informationstechnischen Infrastruktur reibungslos miteinander kommunizieren können - und das sowohl unternehmensintern als auch via Internet mit Geschäftspartnern, Lieferanten und Kunden. Der Integrationsbedarf wird demnach dramatisch ansteigen."
Ordnung ins Komponentenchaos bringen
Historisch betrachtet ist Middleware aus einer Vielzahl unterschiedlicher Ansätzen entstanden. Diese werden nun nach und nach geordnet und strukturiert. Verantwortlich dafür zeichnen die heute auf dem Markt angebotenen Produkte. Deren Hersteller orientieren sich zunehmend an Industriestandards wie Com/DCom (Distributed Component Object Model) und Corba (Common Object Request Broker Architecture) und bieten die dazu kompatiblen Softwarekomponenten an. Aber auch die Forderung der Anwender nach einer optimierten Kooperation bisher getrennter Systemwelten und Plattformen ist eine weitere Triebfeder für eine einheitlich gestaltete Middleware.
Unter dem ökonomischen Druck in den Unternehmen, ihre Effizienz so weit wie möglich zu steigern, wird die Integration von bisher inkompatiblen Softwarekomponenten zu einer der großen Herausforderungen der aktuellen IT-Landschaft. Denn Mainframe-Umgebungen sollen mit der Microsoft-Welt kommunizieren, und Standardlösungen müssen auf bestehenden, individuellen Unternehmenslösungen aufbauen und sie auch weiterhin nutzen.
Neue Entwicklungen, etwa in den Bereichen Electronic Business, Multimedia und Web, müssen mit vorhandenen Applikationen in Einklang
gebracht werden. Unternehmen benötigen daher durchgängige Lösungen vom Mainframe über Unix- oder NT-Server bis zum Desktop.
"Middleware ist eine Integrationstechnologie, die es Anwendern
ermöglicht, ihre komplexen IT-Landschaften effektiver zu nutzen", erklärt Angelika Siffring, Product Managerin bei der Software AG in Darmstadt. "Eine heterogene IT-Architektur, wie sie typisch für nahezu alle größeren Unternehmen ist, erfordert Konzepte und Lösungen zur Verringerung der Komplexität und zum Schutz getätigter Investitionen", so Siffring weiter.
Integration als Schlüsselaufgabe
Die an den Integrationsprozeß geknüpften Erwartungen überschreiten jedoch die Leistungsfähigkeit der klassischen Middleware bei weitem, denn alle Elemente der IT sind hier zu berücksichtigen. So müssen beispielsweise heute Mainframe-Datenbanken auch per Web Transaktionen verarbeiten können, und klassische Entwicklungsumgebungen benötigen Schnittstellen zu Standardanwendungen wie SAP R/3. Und völlig neue Werkzeuge, etwa in den Bereichen Web und Electronic business, müssen auch die aktuellen Technologien wie Java oder DCom, abdecken. Dabei ist es notwendig, den Anwendern Migrationspfade von ihren bestehenden Systemen aufzuzeigen, damit bisherige Investitionen soweit wie möglich geschützt bleiben.
Fragt man Systemintegratoren oder Softwarehäuser nach ihrer Definition von Middleware, bildet für sie der
Integrationsaspekt immer einen zentralen Punkt. Für Dr. Stefan Ried, Project Consultant bei Intershop Communications in Hamburg, schafft Middleware erst die Connectivity zwischen "alten" und "neuen" Systemen. Volker Hahn, Geschäftsführer von Hahn Informatik in Stuttgart, weist auf die historischen Wurzeln von Middleware hin: "Der Bedarf nach Middleware ist maßgeblich deshalb entstanden, weil sich die Client/Server-Architektur konsequent in Richtung drei- und mehrschichtiger Applikationen entwickelt hatte. Dabei geht es nahezu immer um die Integration mehrerer Hardwareplattformen mittels Software. Und die IT-Verantwortlichen müssen den Legacy-Code in ihre neuen Anwendungen einbinden", erläutert Hahn weiter.
Datenbankzugriff für jeden
Unter dem Begriff Middleware werden in der Regel so unterschiedliche Softwaretechnologien wie Datenbank-Gateways, Transaktionsmonitore, Remote Procedure Calls, Messaging oder Object Request Broker zusammengefaßt. Erst mit deren Hilfe können heterogene Systemwelten und Anwendungen untereinander verknüpft werden. Middleware liefert also eine logische Software-Schicht, die Betriebssystem und Anwendungssoftware mittels einer Two-, Three- oder Multi-Tier-Client/Server-Architektur miteinander verbindet. Erst eine derartige Infrastruktur bildet die Basis für die Verteilung von Anwendungssystemen.
Datenbank-Gateways und Transaktionssysteme mit herstellerspezifischen Schnittstellen befinden sich in Großunternehmen seit geraumer Zeit im Einsatz. Dort haben sie sich vielfach gut bewährt. Ihre Stärke ist die ausgezeichnete Performanz; ihre Schwäche: eine hohe Komplexität verbunden mit starren, unflexiblen Strukturen. Aufgrund ihrer proprietären APIs (Application Programming Interfaces) lassen sie sich jedoch nur sehr schwer an moderne Standardsoftware und individuell programmierte Anwendungen anbinden. Um sie der üblichen Komponentenarchitektur anzupassen, wird daher die entsprechende
Middleware zukünftig eine maßgebliche Rolle spielen.
Auf deren Basis wird es nämlich in Zukunft möglich sein, Komponenten unabhängig von einer bestimmten Applikation zu entwickeln und sie später in Anwendungen zu verwenden, die während der Entwicklung noch gar nicht bekannt waren. Die Grundlage dafür bildet eine standardisierte Middleware, die ein möglichst reibungsloses, rechner- und plattformübergreifendes Zusammenwirken verteilter Softwarebausteine ermöglicht.
Zwei miteinander konkurrierende Komponententechnologie
Nun ist aber das Komponentenmodell keine Erfindung der Softwarehersteller. IT-fremde Branchen, allen voran die Automobilindustrie und die Elektrotechnik, haben schon seit langem erkannt, daß der Einsatz mehrfach verwendbarer Bauteile und
-gruppen eine flexiblere und effizientere Produktion ermöglicht.
Die heutzutage eingesetzte Komponenten-basierte Middleware orientiert sich entweder an Microsofts DCom- oder am Corba-Modell der Object Management Group (OMG).
Diese sogenannte Componentware wird nach Einschätzung des amerikanischen Marktforschungsunternehmens Giga Information Group einer der zentralen Trends im Middleware-Markt der nächsten Jahre darstellen: "Die Komponententechnologie wird die Middleware-Lösungen ganz massiv beeinflussen, wobei Microsofts DCom-Ansatz in Richtung Com+ und Java-Beans unter dem Codenamen Glasgow weiterentwickelt wird", mutmaßt Giga-Mann Mike Gilpin. "Ab dem nächsten Jahr werden wir dann Enterprise-Java-Beans in funktionierenden Anwendungen auf Servern sehen. Es gibt eine zunehmende Nachfrage nach einer Interoperabilität zwischen DCom und Corba, da eben beide Standards auf unterschiedlichen Ebenen im Rahmen von unternehmensweiten Applikationen zum Einsatz kommen werden", so Gilpin weiter.
Diese Einschätzung wird auch von Softwarehäusern und Systemintegratoren geteilt. So meint etwa Volker Hahn: "Zunächst einmal sind Middleware und die Komponentenarchitektur grundsätzlich verschiedene Dinge. Der Ansatz der wiederverwendbaren Bausteine bietet jedoch insoweit Vorteile, als daß wir im Rahmen einer Middleware-Strategie gleichzeitig auch eine Komponentenentwicklung betreiben."
Autofirmen stellen auch keine Reifen her
Rolf Heiler, Geschäftsführer der Heiler Software GmbH, ebenfalls aus Stuttgart, ergänzt diese Ausführungen: "Lösungen ohne Komponententechnologie sind schon heute weder finanzierbar noch termingerecht einzuhalten. Eine Entscheidung gegen
Komponententechnologie wäre vergleichbar mit dem Entschluß von Mercedes-Benz, zukünftig die Reifen für seine Fahrzeuge selbst herzustellen. Merceces als Reifenproduzent wäre ein mindestens so irritierender Gedanke wie der, daß SAP zukünftig ein eigenes Betriebssystem für R/3 entwickelt", macht Heiler deutlich.
Komponenten, vor allem Middleware, begrenzen die sich immer mehr verflachende Produktionstiefe der Lösungsanbieter. Damit ist gewährleistet, daß diese Softwareunternehmen sich auf Ihre eigentliche Kernkompetenz konzentrieren können. "Qualität, Kosten und zeitliche Verfügbarkeit einer Gesamtlösung werden von Komponententechnologie positiv beeinflußt", so Heiler weiter.
Middleware beim ZDF
Erste Anwender haben bereits überzeugende Erfahrungen mit Komponenten-basierter Middleware gesammelt. So arbeitet das ZDF in Mainz seit geraumer Zeit an verschiedenen Middleware-Projekten. Unter anderem geht es dabei um die Integration des Mainframe-gestützten Redaktionssystems in moderne Desktop-Umgebungen und in ein Intranet. Bereits Realität ist der Datenbankzugriff über 3270-Terminals und via Web-Browser. Auf diese Weise lassen sich die umfangreichen vorhandenen Informationen ohne aufwendige Neuentwicklungen weiter nutzen.
"Middleware ist eine Art Klebstoff, mit dem wir bestehende Anwendungslogik mit neuen Services verbinden", erklärt Dr. Helmut Kleinoeder, der beim ZDF das Projekt leitet. "Die Komponenten sind die Technologie der Zukunft, denn anders ist die
Softwareentwicklung gar nicht mehr finanzierbar", resümiert Kleinoeder.
Middleware: Windows-Zugang zum Mainframe
EntireX erweitert die DCom-Middleware um Message-Broker-Funktionalität. Damit lassen sich Kapazität, Verfügbarkeit und Zuverlässigkeit traditioneller Unix- und Mainframe-Architekturen für die Welt der sogenannten Componentware zugänglich machen.
Ouelle: Software AG ComputerPartner
Komponenten-basierte Middleware: Zwei Ansätze
DCom-Architektur (oben): Über einen lokalen Object Proxy, einen standardmäßigen Bestandteil von Windows 95, 98 und NT auf dem Client-System, wird ein Call über das Netzwerk an den Com-Stub auf dem Server weitergeleitet.
Bei Corba (unten) vermitteln zwei sogenannte Repositories - Interface und Implementation Repository - die Client-Anfragen zum Server.
Ouelle: Software AG ComputerPartner
Informationsarchitektur
Middleware fungiert als eine logische Software-Schicht zwischen Betriebssystem und Anwendungssoftware. Sie verbindet damit Module unterschiedlicher Herkunft und bildet eine standardisierte Grundlage für den Einsatz von Komponentenarchitekturen.
Ouelle: Software AG ComputerPartner
*Jürgen Wasem-Gutensohn ist Redakteur bei der Agentur PR-Com in Martinsried bei München