Middleware:Schlüsseltechnologie zur
Werbung
Informatik-Spektrum 19: 249–256 (1996) © Springer-Verlag 1996 Hauptbeitrag Middleware: Schlüsseltechnologie zur Entwicklung verteilter Informationssysteme Markus Tresch Zusammenfassung Dem Begriff „Middleware“ liegt kein allgemein gültiges Verständnis zugrunde. In verteilten Informationssystemen bezeichnet Middleware weit mehr als nur den Schrägstrich „/“ in Client/Server.Während dieser Zwischenschicht ursprünglich hauptsächlich Kommunikationsaufgaben zugedacht waren, sieht sich ein Software-Entwickler heute einer unüberschaubaren Vielfalt von Middleware-Systemen mit unterschiedlichsten Funktionalitäten gegenüber. Dieser Artikel gibt einen umfassenden Überblick über aktuelle Entwicklungen der Middleware-Technologie und stellt diese in einem einheitlichen Rahmen dar. nem Hostrechner implementiert sind, und die Benutzer mit recht einfachen Terminals arbeiten, sind dezentrale Anwendungen auf spezialisierte Server und leistungsfähige Clients verteilt, und sogenannte Middleware – das Bindeglied zwischen Clients und Servern – übernimmt selbst umfassende Aufgaben im verteilten Informationssystem (Abb. 1). Schlüsselwörter Verteilte Informationssysteme, Client/Server, SQL-Server, CORBA, Multimedia-Schnittstelle, Data Warehousing, Transaktions-Monitore, Three-Tier-Architecture. Summary There is no widely accepted understanding of the term „Middleware“. In distributed systems, middleware denotes much more than just the slash „/“ in client/server. While originally this intermediate layer was supposed to provide mainly communication services, today’s software developers are faced with a huge variety of middleware systems, implemen- Abb. 1 Clients, Server und Middleware ting divers functionality. In this paper, we present a comprehenAls Vorteile verteilter Anwendungssysteme sind zu sive overview of actual developments in middleware technology nennen: and discuss them in a common framework. • die gute Effizienz durch problemgerechte Arbeitsteilung Key words Distributed information systems, clizwischen Client und Server, ent/server, SQL server, CORBA, multimedia interface, data wa• die hohe Flexibilität und gute Skalierbarkeit, rehousing, transaction monitors, three-tier architecture. • der Einsatz zusätzlicher Ressourcen, • die ökonomische, gemeinsame Nutzung von Ressourcen Computing Reviews Classification H.1, H.2, H.2.5, (z.B. Peripheriegeräte), C.2.4 • die Verhinderung eines zentralen Fehlerortes durch Replikation und Shadowing von Servern (no single point of failure), • die Verwendung bekannter Werkzeuge auf der Client-Seite, z.B. für die Realisierung von Benutzerschnittstellen, a0000005222 das gute Preis/Leistungsverhältnis von Hardware und Stan• 1.Einleitung dardsoftware. Seit mehreren Jahren läßt sich eine klare Tendenz weg von zentralen Mainframe-basierten Anwendungssystemen hin zur Entwicklung dezentraler Applikationen auf Client/Server-Systemen erkennen. Während zentrale Anwendungssysteme auf eiMarkus Tresch, Institut für Informationssysteme – Datenbanken, ETH Zürich, CH-8092 Zürich, Tel.: 0041 1 632 7245, e-mail: [email protected] Dem gegenüber stehen als bekannte Nachteile verteilter Anwendungssysteme: • die inhärente Komplexität der Entwicklung verteilter Anwendungen, und damit die hohen Entwicklungskosten, • die gegenüber Mainframes kleinere Leistung von Servern, die damit einen Leistungsengpaß darstellen können, • die verschärften Sicherheitsprobleme durch erhöhte ClientServer- und Server-Server-Kommunikation, M. Tresch: Middleware 249 • • die oft unzureichende Verfügbarkeit von Entwicklungs- und Wartungswerkzeugen, der größere Administrationsaufwand. In der Praxis hat sich als besonders schwerwiegendes Problem verteilter Client/Server-Anwendungssysteme die unterschätzte Entwicklungskomplexität herausgestellt. Einer der Gründe dafür ist die große Anzahl von Entwurfsalternativen, denen sich ein Entwickler solcher Systeme gegenüber sieht. Neben der Frage der Entwurfsmethodik, stellt sich also die Frage, welches die dazu notwendigen Technologien sind. In diesem Artikel gehen wir auf eine zentrale Schlüsseltechnologie ein, die wesentlich zur erfolgreichen Entwicklung verteilter Client/Server-Informationssysteme beiträgt und deren Stellenwert zunehmend an Bedeutung gewinnt: Middleware. Kapitel 2 gibt einen Überblick über den Stand der Technik klassischer Middleware-Systeme. Darauf aufbauend werden in Kapitel 3 aktuelle und neuere Entwicklungen dargestellt.Abschließend vergleichen wir in Kapitel 4 nochmals die Dienste unterschiedlicher Middleware. nikation zwischen Client und Server sowie der Zugriff auf verteilte Datenbanken bezeichnet werden. Zuerst werden die zwei grundsätzlichen Mechanismen der Client-Server-Kommunikation, Remote Procedure Call und Message Queuing, diskutiert. Danach wird auf SQL-Middleware, als die verbreitetste Form des Zugriffs auf verteilte Datenbanken, eingegangen, die meistens auf einem dieser zwei Mechanismen aufbaut. 2.1.Kommunikations-Middleware Remote Procedure Call (RPC) ermöglicht das Ausführen einer Prozedur durch einen anderen Prozeß, der auf einem entfernten Server laufen kann. Dieser einfache Basismechanismus erlaubt durch eine geringe Erweiterung des gewohnten lokalen Prozedurenaufrufs die Entwicklung verteilter Programme. So ist RPC z.B. seit Mitte der 80er Jahre die Grundlage der meisten Client/Server-Datenbanksysteme. Durch seine Einfachheit ist RPC schnell und effizient. Obwohl es auch auf Threads basierende asynchrone RPCMechanismen gibt, sind diese in der Regel auf synchrone Kommunikation begrenzt, die den Client während des Wartens auf eine Antwort des Servers blockiert. Dies setzt voraus, daß eine Netzwerkverbindung existiert und der Server zu jedem a0000005222 direkte Zeitpunkt verfügbar ist, um die Anfrage zu bearbeiten. Daß dies 2.Klassische Aufgaben von Middleware insbesondere in fortgeschrittenen Anwendungen, man denke z.B. an Mobile Computing, oft nicht gewährleistet werden kann, Die Grundbausteine verteilter Informationssysteme sind Client, liegt nahe. Server und Middleware [9, 10]. Bei Clients denkt man unmittelDes weiteren wird RPC oft als zu „low level“, d.h. zu bar an eine Fülle konkreter Systeme, z.B. an PCs,Workstations, netzwerknahe bezeichnet, und man wünscht sich mit Recht eine Laptops, Mobil-Telefone etc.Auch Server sollen hier durchaus semantisch höhere Abstraktionsebene verteilter Programmieim weiteren Sinne verstanden werden. Zu nennen wären etwa rung mit reicheren Verteilungsdiensten.An dieser Stelle setzt Workstations, Satelliten oder Informationsdienste (BörsenOSF’s Distributed Computing Environment (DCE-Standard) ticker, Newsnet etc.). an, welches nicht nur einen Konsens verschiedener Hersteller Demgegenüber sind die Vorstellungen über Middle- für RPC-Implementierungen anstrebt, sondern darauf aufbauware i.d.R. wesentlich weniger konkret. Sie beinhaltet fast imend auch erweiterte Konzepte wie verteilte Katalogs-, Sichermer eine mehr oder weniger hoch entwickelte Kommunikatiheits-, Zeit- und File System-Dienste standardisiert. Message Queuing beschreibt, im Vergleich zu RPC, onskomponente, die Clients mit Servern verbindet. Middleware die asynchrone, Mailbox-ähnliche Kommunikation. Message kann aber weit darüber hinausgehen und durch unterschiedlichste Dienste und Funktionalitäten weitere Transparenz-ebe- Queuing benötigt nicht nur einen automatisierten Mechanismus in Form eines Queue Managers, vergleichbar etwa mit einen realisieren. Typische Middleware-Dienste sind [2]: • Kommunikations-Dienste: Peer-to-peer Messaging, Remote nem mailer daemon, der Meldungen verwaltet, sondern auch Procedure Call, Message Queuing, elektronische Post, elekeine Form von Persistenz zum Zwischenspeichern der Meltronischer Datenaustausch, dungen. Da Message Queuing eine Ein-Weg-Kommunikation ist, hat der Sender, nachdem er die Meldung abgeliefert hat, • System-Dienste: Event Notification, Konfigurationsmanagement, Software-Installation, Fehlererkennung, Recovery-Koor- keine Kontrolle mehr über deren Weiterleitung an den Empdination,Authentifizierung,Verschlüsselung, Zugriffskontrolle, fänger. Obwohl Message Queuing daher für Echtzeit-An• Informations-Dienste: Directory Server, Log Manager, File und Record Manager, relationales Datenbanksystem, objek- wendungen ungeeignet ist, hat es seine Berechtigung, wenn Clitorientiertes Datenbanksystem, Repository Manager, ents und Server nur zeitweise verfügbar sind, weil sie z.B. mobil • Ablaufkontroll-Dienste: Thread Manager, Transaktionsver- über ein Modem kommunizieren, oder wenn der Server für Anarbeitung, Resource Broker, Request Broker, Job Scheduler, fragen lediglich Stapelverarbeitung kennt. Diese Form der asynchronen Kommunikations• Präsentations-Dienste: Masken- und Graphikverarbeitung, Drucker-Verwaltung, Hypermedia-Verbindungen, Multime- Middleware gewinnt zunehmend an Bedeutung für verteilte India-Aufbereitung, formationssysteme. Sie ist einerseits wesentlich flexibler als • Berechnungs-Dienste: Sortieren, mathematische Berechnun- RPC und erlaubt diverse Variationen, wie z.B. das Senden einer gen, Internationalisierung, Datenkonversion, Zeit-Manage- Meldung an mehrere Empfänger (Broadcasting) oder das Umment. und Weiterleiten von Meldungen an andere Empfänger. Darüber hinaus, bieten aktuelle Entwicklungen, wie z.B. MQSeries, Als die klassischen Aufgaben von Middleware, auf die im Rest persistente, zuverlässige Queues, mit transaktionellen Recodieses Kapitels genauer eingegangen wird, können die Kommu- very-Mechanismen. 250 M. Tresch: Middleware 2.2.SQL-Middleware für den Zugriff auf verteilte Daten diese ausgeführt, bevor die SQL-Anfrage weitergeleitet wird (Abb. 2c). Die Verwendung von erweiterbaren Servern eröffnet wichtige Möglichkeiten, den Zugriff auf Datenbanksysteme Obwohl SQL zu den verbreiteten Standards für Informationssy- durch das Dazwischenschalten eigener Software auf eine für steme gehört, ist man weit davon entfernt, damit transparent Clients transparente Art und Weise zu beobachten. Mit dieser auf relationale Datenbanksysteme unterschiedlicher Hersteller Open Server-Technologie können beispielsweise Änderungsozugreifen zu können. Große zusätzliche Anstrengungen sind perationen auf eine Datenbank protokolliert oder globale notwendig, um die Unterschiede der SQL-Dialekte, Datenbank- Transaktionen koordiniert werden[12]. hersteller, Netzwerkprotokolle, Hardware-Plattformen und ProIm Gegensatz zu SQL-Treibern, die Bestandteil des grammierschnittstellen zu überbrücken. Drei Formen von SQL- Client-Programmes sind und damit im selben Prozeß ausgeMiddleware sollen genauer betrachtet werden, welche obige Un- führt werden, sind (offene) SQL-Gateway Server selbständige, terschiede für Clients transparent machen: SQL-Treiber, SQLim Netz verteilte Systeme. Dies garantiert nicht nur bessere AusGateway Server und offene SQL-Server. führungssicherheit, sondern auch höhere Flexibilität, da darunSQL-Treiber sind die einfachste Form von SQLterliegende Datenbankserver transparent ausgewechselt werMiddleware zum herstellerunabhängigen Zugriff auf relationa- den können. le Datenbanken (vgl. z.B. Microsoft ODBC). Sie bieten eine Programmierschnittstelle für Datenbankzugriffe an, deren Aufrufe je nach darunterliegendem Datenbanksystem von einem enta0000005222 sprechenden Treiber übersetzt und ausgeführt werden (Abb. 3.Aktuelle und neue 2a). SQL-Treiber sind auf der Client-Seite zu finden, d.h. werden Middleware-Entwicklungen entweder statisch zum Client-Programm gebunden oder vom Client über eine dynamische Schnittstelle (Dynamic Invokation Aufbauend auf diesen Grundfunktionalitäten von Middleware Interface) aufgerufen. haben sich nun seit einiger Zeit neue Formen von Middleware SQL-Gateway Server laufen im Gegensatz zu SQLTreibern in einem eigenen Prozeß und kommunizieren mit dem entwickelt [8], die Kommunikationsdienste auf einer höheren Client über eine unveränderte SQL-Schnittstelle (vgl. z.B. Infor- semantischen (objektorientierten) Ebene realisieren, selbst große Datenmengen verwalten oder aufwendige Ablaufkonmation Builders EDA/SQL oder Sybase OmniCONNECT). Die trollaufgaben übernehmen. Grundidee besteht darin, daß der SQL-Gateway Server für den Client als normaler Datenbank-Server erscheint. Im Gegensatz zu einem normalen SQL-Server verwaltet der Gateway Server 3.1.Kommunikations-Middleware jedoch keine eigenen Daten, sondern übersetzt die SQL-Anfrafür verteilte Objekte (CORBA) ge in ein Datenbanksystem eines bestimmten Herstellers. Diese Aus dem Notstand, daß es kein einheitliches, kommerziell verGateway-Funktion des Servers ist für den Client vollständig fügbares und weit verbreitetes Rahmensystem für die Entwicktransparent (Abb. 2b). lung verteilter Informationssysteme gibt, ist 1989 die Object Offene SQL-Server gehen noch einen Schritt weiter Management Group (OMG) entstanden. und erlauben darüber hinaus eine für den Client transparente Die OMG geht davon aus, daß bestehende RahmenErweiterung des Servers durch benutzerspezifische Programme (z.B. Sybase OpenClient/Server). Für den Client präsentiert sich systeme zur Entwicklung verteilter Anwendungen, wie z.B. DCE, zu „low-level“ und damit ungeeignet sind. Statt dessen ein Open Server mit einer normalen SQL-Schnittstelle, da für verfolgt sie einen Ansatz basierend auf Obiekttechnologien, ihn die Erweiterbarkeit nicht sichtbar sein soll.Wird der Open Server durch benutzerspezifische Programme erweitert, werden welche mindestens drei Schlüsseleigenschaften aufweisen um eine einheitliche Sicht auf verteilte und heterogene Systeme zu Abb.2 SQL-Middleware realisieren, nämlich Datenkapselung, Polymorphismus und Vererbung. Daraus entstanden ist der CORBA-Standard, der Interoperabilität und Portabilität auf der Basis einer objekt-orientierten Spezifikation ermöglicht. Die Bestandteile von CORBA sind eine einheitliche Terminologie der Objektorientierung, ein abstraktes Objektmodell, eine Referenzarchitektur und ein gemeinsames Protokoll. Das Kernstück von CORBA ist die Object Management Architecture (OMA) [7, 11], eine Referenzarchitektur bestehend aus Standards für die folgenden Komponenten: • ein Object Request Broker (ORB) definiert den Kommunikationskern von CORBA, • Common Object Services definieren die allgemeinen und anwendungsunabhängigen System-Grundoperationen zur Verwaltung (Modellierung und Speicherung) von Objekten, wie z.B. Naming, Relationships, Persistence oder Transactions. M. Tresch: Middleware 251 • • Common Facilities definieren spezialisierte und anwendungsspezifische Funktionalitäten, die in vielen Applikationen nützlich sind, z.B. User Interface (browsing, querying, printing) oder Compound Documents, Application Objects definieren die Implementierung der Anwendungsobjekte. Der Object Request Broker (Abb. 3) ist der zentrale Mechanismus, der es Objekten erlaubt, über Netzwerk- und Betriebssystemgrenzen hinweg miteinander zu kommunizieren („Object Bus“). Die OMA-Grundannahme besteht darin, daß die Clients nur OIDs enthalten und weder Ort noch Sprache der Objektimplementierung kennen. Die physische Implementierung der Objekte (Daten und Methodencode) erfolgt auf den Servern. Bei der Kommunikation zwischen Objekten formuliert der Client ein Request, der vom Object Request Broker an den Server mit der entsprechenden Methodenimplementierung vermittelt wird. Dazu lokalisiert der ORB die Implementierung, übergibt Daten und Kontrolle an den Server, und transferiert Resultat und Kontrolle nach Abschluß der Berechnung wieder zurück an den Client. Die Sprache IDL (Interface Definition Language) wird zur programmiersprachen- und betriebssystemunabhängigen Definition der Objektschnittstelle verwendet (Syntax ähnlich C++ Headers), die anschließend in die Programmiersprache der Implementierung compiliert wird. Der CORBA-Standard ist relativ frei von Implementierungsvorgaben. Ein ORB kann z.B. eine Menge von Routinen von run-time Bibliotheken (DLL), eine Server-Maschine (separater Prozeß, der Anfragen vermittelt) oder ein Teil des Betriebssystems sein. Beispiele kommerzieller ORBs sind Iona’s Orbix, DEC’s ObjectBroker, IBM’s Distributed System Object Model (DSOM), Sun’s NEO oder HP’s ORB Plus (ORB+). CORBA ist eine semantisch höhere Kommunikationsplattform auf der Basis objektorientierter Technologien [10]. Ein erfolgreicher und akzeptierter Standard fehlt hier zur Zeit und CORBA könnte diese Lücke schließen.Als Hauptprobleme von CORBA werden vor allem die ungenügende Geschwindigkeit (die meisten ORB’s sind auf der Grundlage von RPC implementiert), die mangelnde Skalierbarkeit (welche für Abb.3 CORBA Object Request Broker 252 M. Tresch: Middleware Abb. 4 Multimediale Anfrageschnittstelle unternehmensweite Lösungen unabdingbar ist) und die geringe Stabilität und Sicherheit genannt. 3.2.Multimedia-Anfrageschnittstellen Heterogene Multimedia-Informationen sind meistens in verteilten Datenservern (Repositories) gespeichert, die für die Verarbeitung genau eines Multimedia-Datentyps spezialisiert sind, z.B. relationale und objektorientierte Datenbanksysteme, TextRetrieval-Systeme, Bilddatenbanken oder Audio- und VideoServer. Es entsteht die Notwendigkeit, diese verteilten Daten zu integrieren und als komplexe, miteinander in Beziehung stehende Objekte darzustellen, gleichzeitig aber die Daten selbst in den Repositories zu belassen, um die spezialisierte Funktionalität dieser multimedialen Datenserver zu nutzen. Abbildung 4 illustriert eine solche Middleware am Beispiel des Garlic Projektes [3, 4], welches die Integration heterogener, verteilter Multimedia-Informationssysteme in den Vordergrund stellt. Die existierenden Datenserver können in ein erweiterbares Informationssystem integriert werden, das ein globales (objektorientiertes) Schema von der Gesamtinformation mit globalen Werkzeugen (Query Browsers, etc.) verfügbar macht. Wrapper „wickeln“ Datenserver ein und verleihen ihnen damit nach außen eine einheitliche Schnittstelle. Sie haben zwei Hauptaufgaben. Sie exportieren an die Middleware eine Beschreibung der Datentypen, der aktuellen Daten und der bekannten Suchfunktionen des jeweiligen Repositories, z.B. welche Prädikate unterstützt werden oder welche Zugriffsstrukturen vorhanden sind. Diese Beschreibung wird von den Wrappern zuvor in das Datenmodell der Middleware übersetzt (im Falle von Garlic eine Variation des ODMG-93 Datenmodells). Zum andern übersetzen Wrapper Anfragen zwischen dem internen Protokoll der Middleware und dem des Datenservers. Eine offene Frage ist, ob und in wieweit Wrapper aufgrund einer deklarativen Beschreibung des Repositories automatisch generiert werden können. Die Middleware hat selbst einen eigenen Sekundärspeicher, das Metadata Repository, das dazu verwendet wird, Informationen über das integrierte Schema und über die Transformation der Daten abzulegen. Ein weiteres Repository erlaubt das Speichern eigener komplexer Objekte, die von der Middleware erzeugt und aus bestehenden Objekten zusammengesetzt wurden. Damit lassen sich neue komplexe Objekte bilden, ohne die bestehenden Systeme zu verändern. Das Laufzeitsystem der Middleware verarbeitet globaDieser Vorteil von Data Warehousing kommt insbele Anfragen an Daten, die in mehreren Repositories verteilt sind. sondere in folgenden Fällen zum Tragen: Clients sehen über dieses Laufzeitsystem eine einheitliche, objek- • Datenquellen nicht ständig verfügbar:Viele Informationen sind aus organisatorischen Gründen nicht ständig online torientierte Sicht auf alle Daten. Diese Sicht kann eine einfache verfügbar (z.B. historische Unternehmensdaten) oder die Vereinigung der Daten der Repositories sein, oder sie kann Reentsprechenden Informationsserver stehen nicht ununterstrukturierungen (Selektionen, Projektionen, Joins) enthalten. brochen und zuverlässig zur Verfügung (z.B. mobile, über Anfragen an die Middleware werden vom Laufzeitsystem in Teile Modem angeschlossene Server). Data Warehouses garantiezerlegt, die von einem einzelnen Repository verarbeitet werden ren in diesen Fällen, daß Anfragen in einem bestimmten können. Man betrachte folgendes Beispiel einer globalen Anfrage: Zeitlimit beantwortet werden. select artist, painting • Sehr große und rasch wachsende Datenquellen:Viele Inforfrom GalleryDB mationen, insbesondere solche, die automatisch gesammelt where artist = „Monet“ and reddish(Painting) werden (z.B. Satellitendaten,Aktienkursentwicklungen), wachsen derart schnell, daß real-time Anfragen nicht mehr Nimmt man an, daß die Künstlernamen in einer relationalen möglich sind. In diesen Fällen kann mittels Data WarehouDatenbank und die Bilder in einem speziellen Bilder-Repository sing ein Datenausschnitt extrahiert werden, auf dem dann (z.B. QBIC [4]) gespeichert sind, dann zerlegt die Middleware die konkreten Auswertungen ausgeführt werden. diese Anfrage in zwei Teile ‘artist = „Monet“’ und ‘reddish(Painting)’, die von der relationalen bzw. der Bilddatenbank ausgeDa Daten physisch in das Data Warehouse kopiert werden, muß wertet werden können. Die Aufgabe der Middleware ist es, den diese Art von Middleware selbst über eine möglicherweise beJoin zwischen den Resultaten zu bilden. trächtliche Sekundärspeicherkapazität verfügen. Darüber hinaus kann es durch das Kopieren von Daten in die Middleware zu Inkonsistenzen mit den Informationsquellen kommen. Eine 3.3.Data Warehousing zentrale Fragestellung ist somit, wie die Daten im Data WareData Warehousing-Middleware stellt für Anfrage- und Analyse- house als Folge von Änderungen in den Informationsquellen zwecke den Clients ausgewählte und integrierte Informationen nachgeführt werden können. bereit. Dazu werden Daten aus unterschiedlichen InformationsData Warehousing zeigt also eine starke Verwandtquellen in einer vorverarbeiteten Form physisch in das Data schaft mit materialisierten Sichten und den damit verbundenen Warehouse kopiert (Snapshot). Problemen des View-Updates, so daß viele bekannte View-UpClients stellen ihre Anfragen dann nicht mehr direkt date-Verfahren auch hier zur Anwendung kommen. Trotzdem an die Informationsquellen, sondern benutzen diese Middlewa- ist als wesentlicher Unterschied zu nennen, daß die Informatire (Abb. 5). Das Data Warehouse kann i.d.R. von den Clients onsquellen heterogen und autonom sind. nicht geändert werden (read only), sondern wird nur dann auf Monitore beobachten die Veränderung des Datenbeden neuesten Stand gebracht, wenn sich die Daten der zugrunde standes in den Informationsquellen und leiten diese falls notliegenden Informationsquellen ändern. wendig in das Data Warehouse bzw. an den Integrator weiter. Mit Hilfe eines Data Warehouses können Anfragen Die Implementierung solcher Monitore hängt wesentlich von und Analysen schneller verarbeitet werden, da Informationen den Möglichkeiten ab, die die Informationsquellen bieten, um komprimiert zur Verfügung stehen und semantische Heteroge- Updates festzustellen [6]: nitäten eliminiert wurden. Data Warehousing kann als aktive, • Handelt es sich z.B. um ein Datenbanksystem, so können auf diesem Update-Triggers definiert werden, die dem Monitor vorausschauende Datenintegration betrachtet werden, da AnVeränderungen melden (saubere aber ineffiziente Lösung). fragen nicht in Realzeit transformiert und an die Datenquellen weitergeleitet werden müssen. • Fehlt ein solcher Trigger-Mechanismus, kann der Monitor z.B. das Update Log File des Datenbanksystems inspizieren. Abb.5 Data Warehousing • Bei einer Informationsquelle, die keine solchen Datenbankfunktionalitäten hat, müssen alle Applikationen, die Daten dieser Informationsquelle verändern, so erweitert werden, daß sie bei Updates Meldungen an den Monitor senden. • Solche Veränderungen der Anwendungen sind oft unerwünscht oder nicht machbar, so daß nur noch die Möglichkeit eines Hilfsprogrammes bleibt, das in bestimmten Abständen einen Snapshot der gesamten Daten erstellt und mit früheren Snapshots vergleicht. Die Entwicklung effizienter Algorithmen zur Beobachtung von Updates in Informationsquellen ist Gegenstand aktueller Forschung. Das WHIPS-Projekt [6] untersucht beispielsweise den Ansatz, aus zwei Snapshots eine Sequenz von change-, deleteund insert-Meldungen zu generieren. Im Gegensatz zu klassischen materialisierten Sichten, ist das Data Warehouse von den Datenquellen losgekoppelt, M. Tresch: Middleware 253 was zu folgenden Warehouse-Update Anomalien führen kann: ordinator verlangt werden, auf den Subsystemen aus.Wie im Der Integrator wird von den Monitoren über Änderungen in CIM/Z Projekt vorgeschlagen, besteht ein Agent aus vier Moduden Datenquellen informiert. Stellt der Integrator in diesem len [13]: Moment fest, daß zur Modifikation des Warehouses weitere In- • Das Kommunikationsmodul verbindet den Agenten mit dem Monitor. Dies kann ein eigener Prozeß sein, der mit den Moformationen von eventuell mehreren Datenquellen erforderlich nitor und dem Kontrollmodul des Agenten z.B. über asynsind, muß er an diese Datenquellen eine Anfrage absetzen. Diechrones Message Queuing kommuniziert. se Anfrage wird auf den Datenquellen später ausgewertet, als die dazugehörende Änderung, wodurch inkorrekte Ergebnisse • Das Kontrollmodul übernimmt Protokollierung (Logging) und Recovery der eigenen Aktivitäten und stellt die korrekte im Warehouse entstehen können. gleichzeitige Ausführung mehrerer lokaler SubsystemIntegratoren nehmen die Daten von den Monitoren Transaktionen mit globalen Transaktionen ausgelöst durch entgegen und speichern diese im Warehouse. Die Datenintegraden Koordinator sicher. Die Aufgaben des Kontrollmoduls tion umfaßt die Selektion relevanter Informationen, die Transhängen davon ab, wieviel Transaktionsfunktionalität das formation dieser Informationen in das gemeinsame DatenmoSubsystem selbst anbietet. dell (z.B. Relationen), und schließlich die Integration dieser Daten. Dieser letzte Schritt ist wiedetum eine komplexe Aufgabe, • Das Beobachtungsmodul beobachtet lokale Aktivitäten des Subsystems, die für die globale Koordination relevant sind. da natürlich jeweils nicht das ganze Data Warehouse neu erstellt Wie bei Data Warehouses gilt auch hier, daß dies nur mögwerden soll, sondern die vom Monitor mitgeteilten Änderungen lich ist, falls das Subsystem eine gewisse Beobachtung inkrementell einzuarbeiten sind. zuläßt, d.h. dem Agenten alle notwendigen Informationen zugänglich macht. 3.4. Agenten und Koordinatoren • Das Ausführungsmodul führt die Operationen auf dem SubWährend bislang vor allem Middleware für die Verarbeitung von system aus. Dies bedarf der Transformation von Daten und Anfragen und für den Zugriff auf verteilte Informationssysteme Operationen zwischen dem Datenmodell des Subsystems betrachtet wurde, wenden wir uns nun Agenten und Koordinatound dem globalen Koordinationsmodell. ren zu, einer Middleware zur Kontrolle verteilter Abläufe. Agenten- und Koordinator-Middleware ist selbstverständlich Zur Illustration der Verwendung von Agenten und Koordinatoren betrachten wir eine Computer Integrated Manu- nicht auf CIM-Umgebungen begrenzt, sondern gelangt überall zum Einsatz, wo autonome, heterogene Subsysteme koordiniert facturing (CIM) Umgebung, bestehend aus mehreren autonowerden müssen.Abhängig vom Funktionalitätsumfang dieser men Teilsystemen, z.B. einem Produktionsplanungssystem Subsysteme wird der Aufbau und die Aufgabe der Agenten stark (PPS) und einem Computer Aided Design (CAD) System. Das variieren, so daß generische Agenten nur begrenzt entwickelt PPS enthält Informationen über den Produktionsablauf von Teilen. Das CAD System unterstützt den Entwurf von Teilen und werden können. CIM Subsysteme können z.B. mit Hilfe eines Klassifienthält die Konstruktionspläne. Damit gibt es eine offensichtliche Abhängigkeit zwischen diesen Systemen, die bei der Fabri- kationsschemas nach der Stufe der Erweiterungen eingeteilt werden, die der Agent zu bewerkstelligen hat [13]. Die drei orkation von Teilen ausgenützt werden muß. Zur Koordination der Operationen dieser zwei thogonalen Kriterien für die Klassifikation sind die mögliche Subsysteme wird ein Koordinator eingesetzt (Abb. 6). Die Form der Kommunikation zwischen dem Agenten und dem Hauptaufgabe des Koordinators besteht darin, mit Hilfe von Subsystem, die Möglichkeiten, Operationen auf den Daten des Agenten den konsistenten Zustand des CIM Systems zu gaSubsystems auszuführen und die Unterstützung von Atomarität rantieren. Ein Koordinations-Repository speichert lokal syund Dauerhaftigkeit von Subsystemoperationen. stemübergreifende Abhängigkeiten und protokolliert die eigenen Aktivitäten. 3.5.Transaktions-Monitore (TP-Monitore) Agenten beobachten (vergleichbar mit Monitoren eines Data Warehouses) die Aktivitäten eines Subsystems, die für TP-Monitore [5] kennt man bereits von Mainframe-Systemen (z.B. IBM’s CICS), wo sie eine robuste und effiziente Laufzeitdie globale Koordination wichtig sind und melden diese dem umgebung für transaktionsintensive On-line-Applikationen Koordinator. Gleichzeitig führen sie Operationen, die vom Ko(OLTP), wie z.B. Buchungssysteme, schaffen. Seither haben sich Abb.6 Agenten und Koordinatoren TP-Monitore stark verbreitet und werden inzwischen für fast alle Arten von Applikationen eingesetzt. Insbesondere haben sie sich von der Mainframe-Welt wegentwickelt und bilden heute eine Kerntechnologie für Client/Server-Systeme. Heutige TP-Monitore, wie z.B. Tuxedo [1] oder Encina, werden oft auch als „Betriebssystem für Transaktionen“ bezeichnet. Diese Art von Middleware verwaltet, koordiniert und überwacht Transaktionen von Clients an mehrere Server. Sie hat die Aufgabe, die ACID-Eigenschaften zu garantieren und gleichzeitig den Transaktionsdurchsatz zu optimieren. Damit ist bereits angedeutet, daß TP-Monitore vor allem zwei Aufgaben besonders gut beherrschen: Transaktionsverwaltung und Prozeßverwaltung. 254 M. Tresch: Middleware Abb.7 Transaktionsmonitore TP-Monitore sind von Grund auf für die effiziente Transaktionsverarbeitung konstruiert. Die Hauptaufgabe von TP-Monitoren ist es, die ACID-Eigenschaften von Transaktionen für alle Programme, die unter der Kontrolle des TPMonitors laufen, zu garantieren, indem TP-Monitore deren Ausführung, Verteilung und Synchronisation übernehmen. Durch die Verwendung von TP-Monitoren müssen sich die Anwendungsprogrammierer nicht um Eigenschaften wie Gleichzeitigkeit von Zugriffen, Fehlerbehandlung oder Lastbalancierung kümmern. Eigenschaften wie z. B. 2-PhaseCommit-Koordination werden durch TP-Monitore transparent gemacht. Die Prozeßverwaltung dient in erster Linie der Entlastung des Betriebssystems.Wenn viele Clients vom Betriebssystem Ressourcen (Prozesse, Kommunikationskanäle, Hauptspeicher etc.) auf den Servern anfordern, ist damit das Betriebssystem jedes noch so leistungsfähigen Servers überlastet. Da nun glücklicherweise nicht alle Clients gleichzeitig diese Ressourcen brauchen – aber wenn sie sie brauchen, dann ohne große Verzögerung – können TP-Monitore hier die notwendige Entlastung bieten. Sie unterhalten eine geringere Anzahl von gemeinsam genutzten Verbindungen mit den Servern, auf die eintreffende Transaktionen von einem Scheduler verteilt werden (Abb. 7). TP-Monitore starten solche Server-Prozesse, leiten Aufträge an die Server weiter, überwachen deren Ausführung und balancieren die Last der Aufträge. Da die Wiederherstellbarkeit eines konsistenten Zustandes nach dem Auftreten eines Fehlers eine Hauptaufgabe von TP-Monitoren ist, können diese i.d.R. nicht auf den traditionellen Kommunikationsmechanismen wie RPC oder Message Queueing basieren. Statt dessen implementieren TP-Monitore eigene, transaktionelle Client-Server-Kommunikations-Mechanismen, wie z.B. transactional RPC (TxRPC) oder persistente, zuverlässige und wiederherstellbare Queueing Systeme (vgl. MQSeries). Es entstehen damit Informationssysteme, die nicht nur horizontal über Client- und Server-Subsysteme verteilt sind, sondern auch vertikal auf drei Ebenen implementiert sind (Abb. 8).Auf der obersten Ebene (den Clients) findet in erster Linie die Präsentation der Information und die Interaktion mit dem Benutzer statt.Auf der mittleren Ebene (den Applikationsservern) ist die Anwendungslogik (Business Objects) implementiert.Auf der untersten Ebene befinden sich die Datenbankserver. Diese „3-Tier-Architecture“ (3-Ebenen-Architektur) trennt die Anwendungslogik von der Benutzerschnittstelle und der Datenverwaltung. Die Middleware implementiert anwendungsspezifische Applikationsserver. Das wohl bekannteste kommerzielle Anwendungssystem, das weitgehend dieser Architektur folgt, ist SAP R/3, bei dem es sich um eine umfassende Standard-Software mit modularer Middleware handelt, die z.B. Applikationsserver für Logistik, Personalwirtschaft, Rechnungswesen oder Produktionsplanung enthält. Da diese Applikationsserver je nach Anwendung z.B. den Charakter eines Warehouses oder eines Transaktionsmonitors haben können, liegt es nahe, daß diese auf der Basis früher beschriebener Middleware-Technologie implementiert sind. a0000005222 4.Zusammenfassung In Anbetracht der Komplexität verteilter Client/Server-Systeme ist die Verwendung von Middleware-Software der Schlüssel zur Entwicklung verteilter Informationssysteme. Middleware spielt insbesondere eine zentrale Rolle bei der Integration von Legacy-Anwendungssystemen mit Neuentwicklungen, denn Erfahrungen der letzten Jahre haben gezeigt, daß die alten Systeme nicht verschwinden und die neuen diese nicht vollständig übernehmen werden [14]. Middleware realisiert dabei, zusätzlich zu grundlegenden Kommunikationsaufgaben, vor allem drei unterschiedliche Arten von Transparenz: 1. Zugriff auf verteilte Daten, 2. Kontrolle verteilter Abläufe und 3. verteilte Applikationslogik. Abb. 8 Three-Tier-Architecture 3.6. Middleware mit Anwendungslogik (Three-Tier-Architecture) Nachdem nun gezeigt wurde, daß Middleware aufwendige Berechnungs- und Ablaufsteuerungsaufgaben übernehmen kann, besteht der nächste Schritt darin, diese Aufgaben soweit zu verallgemeinern, daß Middleware selbst einen Teil der Anwendungslogik implementiert. M. Tresch: Middleware 255 Abb.9 Einordnung von Middleware Erachtet man diese drei Dienstarten als Achsen eines Würfels mit dem fundamentalen Dienst der Kommunikation als Zentrum, läßt sich die in diesem Artikel diskutierte MiddlewareSoftware wie in Abb. 9 illustriert einordnen. Viele der in diesem Papier angesprochenen Bereiche der Middleware-Technologie verlangen nach weiterer Forschung. Grundsätzlich würde man sich wünschen, daß die Middleware der Zukunft umfassende Datenbank-Funktionalität, d.h. Datenmodell, Zugriffsstrukturen wie Indexe,Anfragesprache, Transaktionen etc. für Daten in Informationssystemen exportiert, die selbst solche Möglichkeiten nicht oder nur begrenzt haben. Der aktuelle Middleware-Markt ist ein Flickwerk verschiedenster Software. Unterschiedliche Arten von Middleware werden benötigt, um unterschiedliche Arten von Probleme zu lösen.Verteilte Informationssysteme müssen durch Einsatz verschiedenster Middleware-Software gleichzeitig entwickelt werden. Damit ist in absehbarer Zeit zu leben, denn Middleware wird kaum jemals ein einziges monolithisches „Supertool“ sein. Dr. Markus Tresch studierte Informatik an der ETH Zürich und war wissenschaftlicher Mitarbeiter in der Datenbankforschungsgruppe. Er promovierte 1994 an der Universität Ulm auf dem Gebiet der objektorientierten Datenbanksysteme.Von 1994 bis 1995 arbeitete er am IBM Almaden Research Center, Kalifornien. Er leitet heute in der DB-Forschungsgruppe der ETH Zürich den Forschungsbereich Verteilte und Multimediale Objekt-Datenbanken. a0000005222 Literatur 1. Andrade,J.M, M.T. Carges, M.R. MacBlane: The TUXEDO System: An Open On-line Transaction Processing Environment. Bulletin of the TC on Data Engineering, Special Issue on TP Monitors,Vol. 17, No. 1, March 1994 256 M. Tresch: Middleware 2. Bernstein, P.A.: Middleware: A Model for Distributed System Services. Communications of the ACM, Vol. 39, No. 2, February 1996 3. Carey, M.J., L.M. Haas, P.M. Schwarz, et al: Towards Heterogeneous Multimedia Information Systems: The Garlic Approach. Proc. 5th Int'l Workshop on RIDE-DOM, Taipei, Taiwan, March, 1995 4. Cody, W.F., L.M. Haas, W. Niblack, et al: Querying Multimedia Data from Multiple Repositories by Content: The Garlic Project. Proc. 3rd Working Conf. On Visual Databases (VDB-3), Lausanne, Switzerland, March, 1995 5. Gray, J., A. Reuter: Transaction Processing: Concepts and Techniques. Chapter 16, Morgan Kaufmann, San Mateo, 1993 6. Hammer, J., H. Garcia-Molina, J. Widom, W. Libio,Y. Zhuge: The Stanford Data Warehousing Project. Bulletin of the TC on Data Engineering, Special Issue on Materialized Views and Data Warehousing,Vol. 18, No. 2, Juli 1995 7. Mowbray, T.J., R. Zahavi: The CORBA Standard: Systems Integration Using Distributed Objects. John Wiley & Sons, New York, 1995 8. Özsu, M.T., U. Dayal, P.Valduriez (Hrsg.): Distributed Object Management. Morgan Kaufinann, San Mateo, 1994 9. Orfali, R., D. Harkey, J. Edwards: Essential Client/Server Survival Guide.Van Nostrand Reinhold, New York, 1994 10. Orfali, R., D. Harkey, J. Edwards: The Essential Distributed Objects Survival Guide. John Wiley & Sons, New York, 1996 11. Object Management Group: CORBA: The Common Object Request Broker Architecture. Revision 2.0, July 1995 2. Schaad, W., H.-J. Schek, G. Weikum: Implementation and Performance of Multi-level Transaction Management in a Multidatabase Environment. Proc. 5th Int'l Workshop on RIDE: Distributed Object Management, Taipei, March 1995 13. Wunderli, M., M.C. Norrie, W. Schaad: Multidatabase Agents for CIM Systems. Proc. 3rd Int'l Conf. On Computer Integrated Manufacturing (ICCM'95), Singapore, July 1995 14. MiddlewareSPECTRA. Spectrum Reports Ltd., United Kingdom, 1995. http ://www. aladdin.co.uk/mw_spectra/ Eingegangen am 30.04.1996, in überarbeiteter Form am 15.08.1996 Folgende Middleware Systeme wurden in diesem Artikel erwähnt.Diese Liste ist in keiner Art und Weise vollständig,sondern beschreibt eine Auswahl wichtiger Vertreter der einzelnen Kategorien. CORBA Standard DCE Standard DSOM EDA/SQL Encina Garlic MQSeries Orbix SAP R/3 Sybase OpenServer TSIMMIS Tuxedo WHIPS CICS Object Broker NEO ORB+ Object Management Group Open Software Foundation IBM Corp. Information Builders Inc. IBM Corp. IBM Almaden Research Center IBM Corp. Iona Technology Inc SAP AG Sybase Inc. Stanford University Novell Inc. Stanford Universit IBM Corp. DEC Sun HP www.omg.org www.osf.org www.software.ibm.com www.ibi.com www.software.ibm.com www.almaden.ibm.com www.software.ibm.com www.iona.com www.sap-ag.de www.sybase.com www-db.stanford.edu tuxedo.novell.com www-db.stanford.edu www.software.ibm.com www.dec.com www.sun.com www.hp.com
