Enterprise Application Integration 1

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Enterprise Application Integration 1 im Rahmen des Seminars Softwaretechnik Jan Korves Themensteller: Prof. Dr. Herbert Kuchen Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Einleitung Grundlegende Definition, Ursachen und Anwendungsfelder von EAI Definition Enterprise Application Integration Ursachen für die Entstehung von EAI Wichtige Anwendungsfelder von EAI Architektur und Fähigkeiten von EAI-Servern EAI-Referenzarchitektur Prozessschicht Kommunikationsschicht Protokoll-Adapterschicht Weitere Funktionalitäten von EAI-Servern Funktionale Eigenschaften Nichtfunktionale Eigenschaften Integrationsmethoden Integration über die Benutzungsschnittstelle Integration über Funktionsaufrufe Integration über Datenbanken Integration über Komponenten Kommunikationsarten Synchrone Kommunikation Asynchrone Kommunikation Middleware Technische Realisierung Zusammenfassung und Ausblick Literaturverzeichnis II

3 Kapitel 1: Einleitung 1 Einleitung Der Großteil der heute in Unternehmen eingesetzten Anwendungen wurde ohne die Absicht entwickelt, Verbindungsmöglichkeiten zu anderen Systemen zu schaffen. Weiterhin bieten zugekaufte Standardsoftwareprodukte, mit Ausnahme einiger Softwareprodukte des gleichen Herstellers, meist wenige standardisierte Schnittstellen zu den in großer Zahl vorhandenen älteren, so genannten Legacy-Systemen. Untersuchungen von Deloitte and Touche haben ergeben, dass sogar ca. 75% aller Systeme eines Unternehmens Legacy-Anwendungen sind [Ju01, S. 6]. Demzufolge existiert in den meisten größeren Firmen eine Vielzahl heterogener Softwaresysteme, auch als Stovepipe Applications bezeichnet, welche zudem vorwiegend in verschiedenen Sprachen geschrieben wurden, auf unterschiedlichen Betriebssystemen eingesetzt werden und auf ungleichen Datenhaltungen basieren. Das Hauptziel einer jeden Unternehmung, wettbewerbsfähig zu bleiben und den Unternehmensgewinn zu maximieren, kann nur dadurch erreicht werden, die Informationssysteme ständig zu modernisieren und zu verbessern. Um dieses Ziel zu erreichen sowie eine gemeinsame Nutzung vieler unterschiedlicher Internetapplikationen, eine Einbindung von Standardsoftware und einen Zusammenschluss mit einem anderen Unternehmen zu ermöglichen, wird es dringend erforderlich, diese Stovepipe Applications miteinander zu verbinden. Die Kosten, die durch die Versuche entstehen, alle vorhandenen Softwaresysteme miteinander zu verbinden, sind sehr hoch. Forrester Research schätzt, dass ca. 30 Prozent aller IT-Kosten für die Integration von Unternehmensanwendungen verwendet werden, und laut der Gartner Group sind dies sogar 35% [Ka02, S. 1]. Auf Grund dieser äußerst hohen Kosten kam es zu der Entwicklung von spezieller Enterprise Application Integration-Software, kurz auch als EAI-Software bezeichnet. Mit ihr wird versucht, einzelne Insellösungen innerhalb einer Unternehmung effizient und kostengünstig zu verbinden, so dass Informationen und Geschäftslogik für alle Anwendungen gleichzeitig verfügbar werden, ohne dass alle vorhandenen Softwaresysteme durch standardisierte Systeme ersetzt werden müssen. Ziel dieser Seminararbeit ist es, die aktuell im Einsatz befindlichen Funktionalitäten von EAI-Produkten zu erläutern. Dazu werden dem Leser in Kapitel 2 zunächst grundlegende Definitionen und Begriffe nahe gebracht, während im Hauptteil in Kapitel 3 die Architektur und Fähigkeiten eines EAI-Systems beschrieben werden. Abschließend werden im 4. Kapitel die Ergebnisse der Arbeit zusammengefasst und ein Ausblick auf praktische Beispiele von EAI-Lösungen gegeben. 3

4 Kapitel 2: Grundlegende Definition, Ursachen und Anwendungsfelder von EAI 2 Grundlegende Definition, Ursachen und Anwendungsfelder von EAI 2.1 Definition Enterprise Application Integration Eine allgemeingültige Definition von Enterprise Application Integration existiert nicht. Darüber hinaus lässt sich die Definition von EAI aus zwei verschiedenen Perspektiven betrachten. Aus der Geschäftsperspektive betrachtet wird EAI als der Wettbewerbsvorteil bezeichnet, den ein Unternehmen erhält, wenn alle Anwendungen zu einem einheitlichen Informationssystem integriert werden. In dieser Seminararbeit zur Softwaretechnik steht demgegenüber aber der andere Gesichtspunkt, die technische Perspektive, im Vordergrund. Hierbei bezieht sich EAI auf den Prozess heterogene Anwendungen, Funktionen und Daten zu integrieren, um die gemeinsame Nutzung von Daten und die Integration von Geschäftsprozessen durch alle Anwendungen hinweg zu ermöglichen. Diese Integration soll hierbei ohne große Änderungen der existierenden Anwendungen und Datenbanken durch effiziente Methoden in Bezug auf Kosten und Zeit erreicht werden [Ju01, S. 4, Ke02, S. 5 und Ka02, S. 79, 80]. Weiterhin ist eine Abgrenzung zwischen Enterprise Application Integration und Business-to-Business-Electronic-Commerce sinnvoll, da die Werkzeuge, die in beiden Bereichen zum Einsatz kommen, strukturell ähnlich konzipiert sind. Der Begriff EAI beschreibt die Beschleunigung und Rationalisierung von Informationsflüssen innerhalb eines Unternehmens, während beim B2B-E-Commerce der Handel zwischen Unternehmen rationalisiert wird [Ke02, S. 6, 7]. 2.2 Ursachen für die Entstehung von EAI Die Entstehung von EAI lässt sich größtenteils auf drei verschiedene Gründe zurückführen. Zunächst ist hierbei die schnelle Verbreitung des Internets mit den damit verbundenen unzähligen Internetapplikationen, welche durch das Aufkommen vieler Internetfirmen (dot-coms) entstanden ist, zu nennen. Viele Firmen fingen während dieser Zeit damit an, die Möglichkeiten des E-Business und des Internets zu erkennen, und versuchten dementsprechend ihre Geschäftsprozesse neu zu gestalten, um sie zu automatisieren und damit Kosten zu sparen. Weiterhin entstanden zu jener Zeit sehr viele neue Firmen, deren Geschäftsmodelle ausschließlich auf dem Internet basierten, wie z. B Suchmaschinen, -Provider, Internet-Versandhändler, elektronische Auktionshäuser und Vergleichsplattformen. Nach und nach wuchs die Anzahl verschiedener Internetapplikationen in diesen Unternehmen sehr stark an, so dass es notwendig wurde, die Anwendungen miteinander zu verbinden. Dies, wie auch die Neugestaltung der Ge- 4

5 Kapitel 2: Grundlegende Definition, Ursachen und Anwendungsfelder von EAI schäftsprozesse, kann nur erreicht werden, wenn alte und neue Anwendungen integriert und existierende Systeme für Nachrichten aus dem Internet zugänglich gemacht werden, so dass alle Anwendungen, die an einem Geschäftsvorfall beteiligt sind, problemlos miteinander kommunizieren können. Laut [Ke02, S. 12] wird dies als das primäre Einsatzfeld für EAI-Technologien bezeichnet. Der zweite Trend, der sich in Unternehmen abzeichnet, ist, dass immer mehr Enterprise Resource Planning-Softwareprodukte (ERP-Softwareprodukte) anstatt selbst entwickelter Software eingesetzt werden. ERP-Software ist Standardsoftware, die von größeren Unternehmen für sekundäre Geschäftsprozesse wie Rechnungswesen, Materialwirtschaft usw. eingesetzt wird. Firmen, die solche Systeme vertreiben, sind z. B. SAP, Baan, Peoplesoft und Oracle. Die Schwierigkeit hierbei besteht darin, diese ERP- Software in die bestehende Anwendungslandschaft des Unternehmens zu integrieren. Auch dieses Problem wird aktuell mittels so genannter GlueWare, wie z. B. EAI-Tools angegangen. Unter GlueWare versteht man Software, die eine Verbindung zwischen einzelnen Softwarekomponenten schafft. Die dritte Ursache, die zur Entstehung von EAI beigetragen hat, ist das immer häufigere Auftreten von Übernahmen und Fusionen zwischen Unternehmen aller Größenordnungen. Hierbei wird meist die Strategie verfolgt, das Anwendungsportfolio des einen Fusionspartners zu behalten und die Bestände des anderen in das beibehaltene System zu integrieren [Ke02, S ]. 2.3 Wichtige Anwendungsfelder von EAI Da es mitunter sehr viele Anwendungsfelder für den Einsatz von EAI gibt, soll in diesem Kapitel nur auf die wichtigsten drei eingegangen werden. Hierzu gehören Multichannel-Architekturen, Application to Application-Integration (A2A-Integration) sowie die Geschäftsprozessintegration, welche im Folgenden näher erläutert werden [Ke02, S ]. Heutzutage besteht die DV-Landschaft in Unternehmen größtenteils aus mehreren Verkaufssystemen (Front-Office), so z. B. Vertriebskanäle wie Internet und Callcenter, welche mit einem oder mehreren Kernssystemen (Back-Office), in denen die Geschäftslogik aufbereitet wird, zusammenarbeiten. Die möglichen Architekturen, die hierbei auftreten können, werden als n:1 und n:m Multichannel-Architekturen bezeichnet. n:1 bedeutet in diesem Fall, dass n Frontend-Anwendungen mit einer Backend-Anwendung verbunden sind und n:m besagt, dass n Frontend-Anwendungen mit m Backend- Anwendungen untereinander in Verbindung stehen. Die EAI-Technologie, die hier zum Einsatz kommt, besteht aus einer Art Middleware, die eine Kommunikationsmöglich- 5

6 Kapitel 2: Grundlegende Definition, Ursachen und Anwendungsfelder von EAI keit zwischen Front-Office und Back-Office schafft. In Abb. 1 wird ein n:1 Multichannel-Szenario zum einen mit dem Einsatz und zum anderen ohne die Verwendung einer EAI-Lösung dargestellt. Während in der klassischen n:1 Multichannel-Situation ohne EAI jeweils ein eigener Kanal mit individueller Schnittstelle die Front-Office-Systeme mit dem Back-Office-System verbindet, können in der Situation mit EAI die individuellen Schnittstellen durch eine normierte Schnittstelle ersetzt werden, so dass die Erstellungs- und Wartungskosten verringert werden. Auf den Begriff Middleware sowie Transformationstechniken, Adapter und Schnittstellen wird im Verlauf des Kapitels 3 noch genauer eingegangen. normierte Transformationstechniken (T) normierte Adapter (A) normierte Schnittstellen (S) Front-Office Anw.1 Front-Office Anw.1 T A Front-Office Anw.2 Back-Office Kernanwendung Front-Office Anw.2 T A normierte Transportprotokolle (Middleware) S Back-Office Kernanwendung Front-Office Anw.3 Front-Office Anw.3 T A klassische Situation ohne EAI neue Situation mit EAI Abbildung 1: n:1 Multichannel-Situation mit und ohne EAI Quelle: [Ke02, S. 17] Unter der A2A-Integration wird das Vorgehen bezeichnet, viele Inselanwendungen eines Unternehmens, welche zudem auf unterschiedlichen Servern liegen können, zu verbinden. Das Problem dieser Maßnahme liegt darin, dass die Wartungskosten sehr hoch sein können, wenn sehr viele Verbindungen und Schnittstellen vorliegen. Im schlechtesten Fall kann es zu O(n²)-Verbindungen zwischen den Applikationen kommen, wenn jede Anwendung direkt mit jeder anderen Anwendung verbunden wird. Dies wird als Spaghetti-Kommunikations-Architektur bezeichnet. Eine EAI-Lösung als Bus- oder Hub & Spoke-Architektur bietet sich in diesem Fall an, so dass die Anzahl möglicher Verbindungen auf O(n) reduziert werden kann. Bei einer Bus-Architektur werden Informationen, die in einer Anwendung entstehen, auf einen zentralen Bus gesendet und über diesen Weg den an den Bus angebundenen Applikationen zur Verfügung gestellt. In einer Bus-Architektur gibt es keinen zentralen Server, der die Verteilung der einzelnen Nachrichten koordiniert, der zentrale Bus leitet die Nachrichten lediglich weiter und verteilt sie an die an den Bus angebundenen Systeme. Die Applikationen entscheiden hierbei selbst über die Relevanz der Informationen, und nehmen sie ggf. nach dem 6

7 Kapitel 2: Grundlegende Definition, Ursachen und Anwendungsfelder von EAI Publish/Subscribe-Prinzip, auf welches in Kapitel näher eingegangen wird, auf. Demgegenüber gibt es bei der so genannten Hub & Spoke-Architektur eine zentrale Informationsdrehscheibe, in diesem Fall einen zentralen EAI-Server, mit der alle Anwendungen und Systeme gleichberechtigt verbunden sind. Dieser zentrale EAI-Server, über die die gesamte Kommunikation der einzelnen Anwendungen abläuft, wird als Hub bezeichnet und steuert und überwacht den gesamten Datenverkehr zwischen den einzelnen Systemen [Ha02]. Abb. 2 zeigt diese 3 Architekturen noch einmal grafisch. Abbildung 2: Spaghetti-Kommunikations-, Hub & Spoke- und Bus-Architektur Ein weiteres wichtiges Anwendungsfeld, in dem EAI-Technologien gewinnbringend eingesetzt werden können, ist die so genannte Geschäftsprozessintegration. Bei der Steuerung von Geschäftsprozessen ist es notwendig, dass alle beteiligten Systeme zusammenarbeiten. EAI-Software wird in diesem Fall dazu genutzt, diese Systeme zu integrieren, indem die einzelnen Aktivitäten eines Geschäftsprozesses auf mehrere Anwendungen zugreifen können (Abb. 3). Hierbei kann es zu drei Arten der Anbindungen kommen. Dies sind die Integration über die Oberfläche, die funktionale Integration sowie die Integration über Daten. Im Kapitel 3.2 werden diese näher erläutert. Geschäftsprozess Ak. 1 Ak. 2 Ak. 3 Ak. 5 Ak. 6 Ak. 4 Anw. 1 Anw. 2 Anw. 3 Anw. 4 Abbildung 3: Geschäftsprozessintegration Quelle: [Ke02, S. 26] 7

8 3 Architektur und Fähigkeiten von EAI-Servern Den Einsatzgebieten für EAI-Technologie, die in Kapitel 2.3 angesprochen wurden, kann mit einer Lösung begegnet werden, die sich EAI-Integrationsserver nennt. In dieser Seminararbeit wird dieser Begriff für alle Arten von EAI-Lösungen gebraucht. Zunächst wird in diesem Kapitel eine EAI-Referenzarchitektur mit ihren funktionalen Eigenschaften vorgestellt. Anschließend werden weitere funktionale und nichtfunktionale Eigenschaften von EAI-Integrationsservern dargelegt. Zum Abschluss des Kapitels wird noch auf die Integrationsmethoden, Kommunikationsarten und den Begriff der Middleware näher eingegangen, da sie einer weiteren Erläuterung bedürfen. Alle diese Charakteristika sind für die Auswahl und das Design eines EAI-Integrationsservers und den damit verbundenen Kosten von enormer Wichtigkeit und sollten deswegen für jedes Unternehmen entsprechend unterschiedlich betrachtet werden. 3.1 EAI-Referenzarchitektur Die technischen Eigenschaften, die ein EAI-Integrationsserver bereitstellt, lassen sich zu einer EAI-Referenzarchitektur zusammenfassen, welche in Abb. 4 dargestellt ist. Neben dieser Referenzarchitektur kann ein weiteres EAI-Architekturmodell in [Ka02, S. 100] nachgelesen werden, welches sich aber von diesem Modell nicht grundlegend unterscheidet. In den folgenden Ausführungen werden die 3 Schichten Prozessschicht, Kommunikationsschicht und Protokoll-Adapterschicht sowie die durch sie abgedeckten Funktionalitäten näher erläutert. http Legacies Weitere Abbildung 4: EAI-Referenzarchitektur Quelle: [Ke02, S. 43] 8

9 3.1.1 Prozessschicht In der Prozessschicht können einfache Aufgaben zu komplexen Diensten miteinander verknüpft werden. Die Integration mehrerer Anwendungen entlang eines Geschäftsprozesses wird letztendlich durch diese EAI-Komponente gesteuert. Dazu werden Funktionalitäten geboten, erweiterte Geschäftslogiken zu definieren und eigene Geschäftsregeln festzulegen. Zum einen kann Geschäftslogik, die nicht in den zu integrierenden Anwendungen zur Verfügung steht, in einem EAI-Integrationsserver aus mehreren Diensten zusammengesetzt oder in den vorhandenen Servern nachprogrammiert werden. Zum anderen können Geschäftsregeln bestimmt werden, wodurch Teile eines Geschäftsprozesses abhängig von Bedingungen ausgewählt werden. Gesteuert werden diese Funktionalitäten durch einzelne Prozesse, die dazu in der Lage sind, Nachrichten zu verschicken und zu empfangen. Ein Prozess, der eine Nachricht verschickt hat, gelangt hierbei solange in einen schlafenden Zustand, bis er durch eine andere Nachricht wieder aufgeweckt wird. Weiterhin können diese Funktionalitäten, die mit der Prozessschicht abgedeckt werden, in drei verschiedene Gruppen aufgeteilt werden. Dies sind die Prozessmodellierung, die Prozesssteuerung und die Prozesskontrolle. Die Prozessmodellierung stellt die Werkzeuge zur Verfügung, um einzelne Aufgaben miteinander zu verknüpfen, Ressourcen und Reihenfolgen zuzuordnen sowie Subprozesse zu definieren. Ein denkbares Werkzeug ist das ARIS-Toolset mit den ereignisgesteuerten Prozessketten (EPK). Ferner wird im Rahmen der Prozesssteuerung die Ausführung der einzelnen Arbeitsschritte innerhalb eines modellierten Geschäftsprozesses ermöglicht. Um die entsprechenden Nachrichten nacheinander an die richtigen Anwendungen leiten zu können, bedarf es einer engen Kopplung mit der Kommunikationsschicht, welche im folgenden Abschnitt erläutert wird. Schließlich gestattet die Prozesskontrolle die automatische Protokollierung und Überwachung der Fortschritte aller Geschäftsprozesse. Auf diese Weise können Statusinformationen abgerufen werden, Alarme bei Zeitüberschreitungen definiert und statistische Analysen erstellt werden. Dieser Vorgang wird auch als Prozessmonitoring bezeichnet [Ke02, S , Ka02, S ] Kommunikationsschicht Eng mit der Prozessschicht verbunden ist die Kommunikationsschicht. Sie ist hauptverantwortlich für den Transport von Nachrichten zwischen Sendern und Empfängern, so dass die Kommunikation unter verschiedenen Anwendungen sowie der Austausch von Informationen ermöglicht werden. Zunächst ist es hierbei von Interesse, welche EAI- Infrastruktur eingesetzt und welche Kommunikationsart verwendet wird. 9

10 So lassen sich unter einer EAI-Infrastruktur die drei grundlegenden Modelle Punkt-zu- Punkt (P2P)-Infrastrukturen, Bus-Infrastrukturen und EAI-Server unterscheiden. Diese Modelle basieren auf den in Kapitel 2.3 angesprochenen Architekturen zur A2A- Integration (Spaghetti-Kommunikations-, Bus- und Hub & Spoke-Architektur) und werden in diesem Abschnitt hinsichtlich ihrer Funktionalität näher betrachtet. Eine P2P-Infrastruktur zeichnet sich dadurch aus, dass die Kommunikation über immer denselben Protokollstack zwischen zwei gleichen Teilnehmern (Peers) erfolgt. Ein derartiges Beispiel ist Distributed Computing Environment (DCE), ein Konzept für die Festlegung von Diensten und Werkzeugen, die die Erzeugung, Benutzung und Administration von verteilten Anwendungen unterstützt. Hierbei wird die Verbindung zwischen Sender und Empfänger über so genannte Remote Procedure Calls (RPCs) ermöglicht. Ein RPC ist ein Netzwerkprotokoll aus der fünften und sechsten Schicht des I- SO/OSI-Modells. Durch diesen Mechanismus kann über ein Netzwerk die direkte Kommunikation zwischen einzelnen, auf verschiedenen Systemen ablaufenden Komponenten, ermöglicht werden. Hierbei wird einer lokalen Anwendung durch so genannte Stubs die Funktionalität der entfernten Anwendung zur Verfügung gestellt. Ein Stub ist eine Kopie des entfernten Objektes, die aber nur die einzelnen Methoden als Interface bereitstellt, jedoch nicht implementiert. Aufrufe einer Methode am Stub werden über eine Middleware, welche später in Kapitel 3.5 näher erläutert wird, an das entfernte Objekt übergeben und dort ausgeführt. Bei Aufruf einer Funktion im Stub wird diese über die RPC-Laufzeitumgebung an die entfernte Anwendung übertragen, bearbeitet und das Ergebnis zurückgegeben. Für den Benutzer ist dieser Vorgang völlig transparent, er arbeitet auf entfernten Objekten mit deren Funktionen, als wären sie lokal in seiner Umgebung vorhanden. Die Middleware übernimmt dabei die Verwaltung der Objekte und die Kommunikation. Das zweite Modell Bus-Infrastrukturen, wie z. B. die objektorientierte Common Object Request Broker Architecture (CORBA), basiert auf dem Gedanken, alle Nachrichten über Adapter in eine intern einheitliche Form zu konvertieren. CORBA ist eine standardisierte, sprachunabhängige objektorientierte Middleware, die Protokolle und Dienste für das Erstellen verteilter Anwendungen in heterogenen Umgebungen, definiert. Unter anderem bietet sie Zugriff auf entfernte Objekte über entfernte Methodenaufrufe. Dieser Mechanismus ähnelt sehr stark dem Grundprinzip eines RPCs. Der Unterschied liegt neben der Objektorientierung in der Bezeichnung der Stubs sowie in der Anzahl und Mächtigkeit der angebotenen Dienste. Während bei einem RPC von Stubs (genauer Client und Server-Stub) gesprochen wird, werden diese in CORBA Client-IDL-Stub (IDL für Interface Definition Language) und Static Skeleton bezeichnet. Darüber hinaus bietet CORBA im Gegensatz zu RPC eine Fülle an weiteren Diensten. Eine Liste mit derartigen CORBA-Diensten kann in [Or96] nachgelesen werden. 10

11 Die Idee der dritten und letzten Variante einer EAI-Infrastruktur ist es, zentrale EAI- Server zu verwenden, an welche die Nachrichten übermittelt und wo sie auch zentral behandelt werden. Dies entspricht in etwa einer Hub & Spoke Architektur, wie sie in Kapitel 2.4 beschrieben wurde. Ein Beispiel für einen solchen Server ist Vitria BusinessWare. Auf diese und weitere EAI-Server wird in der an diese Ausarbeitung anschließenden Seminararbeit Enterprise Application Integration 2 detailliert eingegangen. Die Kommunikationsart ist nach den beiden Typen synchron und asynchron zu unterscheiden. Bei synchroner Kommunikation ist der Sender an den Empfänger gekoppelt und kann erst weiterarbeiten, sobald er eine Antwort vom Empfänger erhält. Der vorhin angesprochene RPC ist ein Beispiel der synchronen Kommunikation. Die asynchrone Kommunikation unterscheidet sich dahingehend, dass der Sender nach dem Verschicken seiner Nachricht nicht mehr an den Empfänger gekoppelt ist und somit an anderen Dingen weiterarbeiten kann. Eine genauere Betrachtung der einzelnen Kommunikationsstile synchroner und asynchroner Kommunikation wird in Kapitel 3.4 vorgenommen. Neben dem einfachen Transport von Nachrichten muss die Kommunikationsschicht weitere Aufgaben erfüllen. Es müssen Daten in entsprechende Formate umgewandelt als auch Synchronisationsdienste bereitgestellt werden. Die Transformation von Daten wird notwendig, wenn aus verschiedenen Datenbanksystemen Informationen ausgelesen werden und in einer standardisierten Nachricht an eine Zielanwendung weitergesendet werden sollen. Die Datensätze aus verschiedenen relationalen und objektorientierten Datenbanken müssen dann in ein einheitliches Format, wie z. B. das in EAI- Infrastrukturen am häufigsten genutzte Format XML, transformiert werden. Dazu kommen aus dem Data-Warehouse-Umfeld bekannte Extraktion-Transformation- Laden-Tools (ETL-Tools) zum Einsatz. So können Daten entweder über Algorithmen transformiert, oder durch Look-up-Tabellen auf entsprechende Schemata gemapped werden. Der alleinige Einsatz von XML bedeutet aber noch keine Normierung. Sofern XML als Format für den Inhalt von Nachrichten verwendet wird, sollte es weiterhin eine zentrale Stelle im Unternehmen sowie auch unternehmensübergreifend geben, die die Vokabulare und Dokumentenformate einheitlich festlegt. Des Weiteren dienen die Synchronisationsdienste der internen Regelung von zeitlichen Abläufen beim Nachrichtenversand. Die Verwaltung von Nachrichtenschlangen (Message-Queues) gehört dabei zu einer zentralen Aufgabe. Erreichen eine Anwendung mehrere Nachrichten zur gleichen Zeit, sind diese entweder zu verwerfen, mit Prioritäten zu versehen oder einfach nur in eine Warteschlange einzureihen. Die Länge von Schlangen muss genauso festgelegt werden, wie maximale Wartezeiten und Garantien für Weiterleitung und Zustellung von Nachrichten. 11

12 Wie in dem Abschnitt zur Prozessschicht dargelegt, können Nachrichten zum einen durch einen Prozess in der Prozessschicht entstehen und zum anderen auch extern durch einen Adapter in der Protokoll-Adapterschicht ausgelöst werden. Die Kommunikationsschicht stellt somit die zentrale Schicht dieser Referenzarchitektur dar, welche den Transport der Nachrichten erledigt und die anderen beiden Schichten verbindet [Ke02, Kap. 3, 4 und Ka02, Kap. 4] Protokoll-Adapterschicht Vervollständigt wird die EAI-Referenzarchitektur durch die Protokoll-Adapterschicht. Sie ist für die Umwandlung von externen Auslösern, wie z. B. s, http-requests, Funktionsaufrufen, Datenbankupdates und anderen externen Ereignissen in das interne Nachrichtenformat des EAI-Servers zuständig. Dafür werden in dieser Schicht wiederum Funktionalitäten, zum einen des Transports von Nachrichten und zum anderen der Datentransformation in genormte Nachrichtenformate, bereitgestellt. Der Unterschied zu der Kommunikationsschicht liegt in der Tatsache, dass diese Datentransformation zwischen einem externen System und dem EAI-Integrationsserver und nicht innerhalb des EAI-Servers stattfindet. Adapter sind Softwarebausteine, welche die Kopplung verschiedener Anwendungen ermöglichen. Da Adapter stets an die spezifischen Schnittstellen der einzelnen Anwendungen angepasst werden müssen, existiert eine Vielzahl unterschiedlicher Ausprägungen. Durch Integrationslösungen angebotene, vorgefertigte Adapter können sich dabei nur auf generelle Standards konzentrieren, da die Vielfalt der Schnittstellen von Altsystemen nicht abzubilden ist. In der Rechnerkommunikation kommen z. B. Standards wie TCP/IP, IPX, X.500 oder SPX zum Einsatz. Der Austausch von Daten kann über Standards wie OAGIS, EDIFACT, XML oder ANSI geregelt sein. Nicht jede Altanwendung muss sich zwingend eines Standards bedienen. Selbstdefinierte Datenformate und Kommunikationsmechanismen sind besonders in Altanwendungen verbreitet. So kommen in der Anwendungslandschaft von vielen Unternehmen Systeme zum Einsatz, die vor vielen Jahren geschrieben wurden und neben TCP/IP zur Kommunikation auf keine weiteren Standards zurückgreifen. Die Anpassung und Entwicklung von Adaptern ist folglich für jedes Integrationsprojekt neu durchzuführen und somit fester Bestandteil jeder EAI-Lösung [Ke02, Kap. 3,4 und Ka02, S. 100, 101]. 3.2 Weitere Funktionalitäten von EAI-Servern Nachdem im vorherigen Kapitel einige funktionale Charakteristika anhand einer EAI- Referenzarchitektur beschrieben wurden, geht es in diesem Abschnitt um weitere funktionale und nichtfunktionale Eigenschaften, die für das Design und die damit verbunde- 12

13 nen Kosten eines EAI-Softwaresystems von enormer Wichtigkeit sind und noch nicht in der EAI-Referenzarchitektur erwähnt wurden Funktionale Eigenschaften Zu den technischen Funktionalitäten, auf die bei dem Einsatz eines EAI-Systems zu achten ist, gehört die Qualität der Nachrichtenübermittlung. Im Idealfall wird eine Auslieferung der gesendeten Nachrichten vollständig garantiert. Überdies ist eine hohe Konnektivität eine weitere wichtige Fähigkeit, die ein EAI-Server bieten sollte. Unter Konnektivität wird die Möglichkeit der Verständigung des EAI-Servers mit möglichst vielen Programmier- und Betriebssystemumgebungen verstanden. Außerdem sollten weitere Aufgaben, wie die Bestimmung des Weges einer Nachricht vom Sender bis zum Empfänger (Routing), eine Ordnung in den Nachrichten für einen Überblick über alle Nachrichtentypen und -formate sowie ein Namensdienst, bereitgestellt werden. Ein Namensdienst ermöglicht die Verwendung symbolischer Namen statt technischer Bezeichner von Objekten. Daneben sind auch verschiedene Sicherheitskonzepte wichtige funktionale Eigenschaften eines EAI-Systems. In diesem Zusammenhang sind eine verschlüsselte Kommunikation, Authentifizierung und Autorisierung der Benutzer sowie ein Auditing notwendig. Bei der Authentifizierung wird versucht, die einen Dienst anfordernde Person oder anforderndes System eindeutig zu identifizieren, während bei der Autorisierung Berechtigungen geprüft werden. Das Auditing zeichnet schließlich alle Aktivitäten im Netzwerk genau auf und ermöglicht die Rückverfolgung von Angriffen. Für die Bereitstellung dieser Sicherheitskonzepte gibt es zwei Möglichkeiten. Entweder müssen sie selber implementiert werden oder es werden im Falle der Nutzung eines Integrationsservers, der auf eine spezielle Implementierung aufsetzt, dessen Sicherheitsdienste genutzt. Z. B. können bei einer CORBA-Implementierung die CORBA Sicherheitsdienste genutzt werden [Ke02, S , Ka02, S ]. Die Kosten für die Aufrechterhaltung und Wartung von EAI-Systemen sind ein weiterer wichtiger Gesichtspunkt, der bei EAI-Infrastrukturen beachtet werden sollte. Vor allem ist es von großem Interesse, eine Verfügbarkeit des Systems für 24 Stunden pro Tag, 7 Tage die Woche zu gewährleisten. Um diese ständige Verfügbarkeit zu erreichen, sollte das EAI-System über eine Lastverteilung auf mehrere Server (Load-Balancing) und eine gegenseitige Vertretung bei Ausfall (Fail-over) verfügen. Weiterhin sollten Fähigkeiten, wie Fernüberwachung von Systemen (Monitoring), Systemwiederherstellung nach Abstürzen (Recovery) sowie geeignete Mechanismen zum Auffinden und Beseitigen von Programmfehlern (Debugging) vorhanden sein. Auch eine plattformunabhängige Verteilung der Laufzeitkomponenten auf mehrere Rechner, welche sich nicht auf die 13

14 Verwaltung des Systems auswirkt (Transparente Verteilbarkeit), sollte als Kriterium für die Auswahl eines EAI-Servers beachtet werden [Ke02, S ] Nichtfunktionale Eigenschaften Zu den nichtfunktionalen Eigenschaften eines EAI-Softwaresystems zählt vor allem die Performance. Als Performance wird die Antwortzeit auf eine bestimmte Anfrage bezeichnet. Je schneller ein System auf eine Eingabe reagiert, desto besser ist die Performance. Allein im Falle einer schlechten Performance wird ein EAI-System, bei dem alle anderen funktionalen Eigenschaften sehr gut sind, nicht zum Einsatz kommen, da es von den Benutzern nicht akzeptiert werden würde. Ein derartiges Beispiel ist ein Online-Shop, der mehrere Minuten für den Aufbau einer neuen Seite braucht. Als zusätzliche nichtfunktionale Eigenschaften sind hierbei eine mögliche Performanceverbesserung durch Hinzufügen weiterer Hardware-Ressourcen (Skalierbarkeit), die Zuverlässigkeit des gesamten Systems, die Qualität der mitgelieferten Tools sowie die Markenposition des Herstellers zu nennen. Da aktuell sehr viele EAI-Anbieter vorhanden sind, ist davon auszugehen, dass ein Großteil dieser Anbieter in naher Zukunft verschwinden wird und wenige große Anbieter übrig bleiben werden [Ke02, S ]. 3.3 Integrationsmethoden Wie in Kapitel 2.3 angesprochen gibt es 3 verschiedene Methoden, nach denen vorgegangen werden kann, unterschiedliche Systeme in einem Unternehmen zu integrieren. Diese drei Methoden, bei denen die Integration über Benutzungsschnittstellen, Funktionsaufrufe und Datenbanken vollzogen wird, orientieren sich an der aus dem Software- Engineering gängigen 3-Schichtenarchitektur (Präsentationsschicht, Geschäftslogikschicht und Datenhaltungsschicht) für betriebliche Informationssysteme [Ba01], welche auch als Präsentations-, Funktions- und Datenebene bezeichnet werden können. Diese, wie auch eine technische Variante der Integration über Benutzungsschnittstellen, die so genannte Integration über Workflow, sind in Abb. 5 dargestellt. Zu Ende dieses Unterkapitels wird noch auf eine weitere, immer mehr eingesetzte Integrationsmethode, auf die Integration von Komponenten, eingegangen. Der Einsatz in einem Unternehmen beschränkt sich hierbei nicht nur auf die eine oder andere Integrationsmethode, sondern meist auf alle in verschieden starken Ausprägungen [Ke02, S. 60, 61]. 14

15 System A Benutzungsschnittstelle Anwendungskern Datenhaltung System B Benutzungsschnittstelle Anwendungskern Datenhaltung Integration über Workflow Integration der Benutzungsschnittstellen Integration über Funktionsaufrufe Integration über föderierte Datenbanken Abbildung 5: Integrationsmethoden Quelle: [Ke02, S. 60] Integration über die Benutzungsschnittstelle Bei der Integration über die Benutzungsschnittstelle wird auf die Präsentationsschicht der Anwendungen zugegriffen. Besonders alte Anwendungen bieten lediglich grafische Eingabedialoge anstelle von Schnittstellen zum Zugriff auf Funktionen an. In solchen Fällen muss die integrierende Anwendung gegenüber dem Altsystem wie ein menschlicher Benutzer auftreten, Daten in die Benutzeroberfläche einpflegen und Ergebnisse auslesen. Die Idee hierbei ist, neue Benutzungsschnittstellen auf alte aufzusetzen. Diese nehmen Daten entgegen, pflegen sie in die Benutzungsschnittstelle der Altanwendung ein, lesen die entsprechenden Ergebnisse aus und stellen sie dem Anwender auf seiner neuen Benutzerschnittstelle dar. Dies kann durch verschiedene Techniken realisiert werden. Eine dieser Techniken ist die so genannte Screen Scraping Technik. Sie liest Daten an verschiedenen Bildschirmkoordinaten oder aus Datenflüssen ab und wandelt sie in die benötigten Formate um. Die Web-Integration mit Frames ist ein weiteres Verfahren, bei dem einzelne Frames verschiedener Web-Server in einer neuen Anwendung vereint werden. Darüber hinaus eignen sich auch Workflow-Management-Tools für die Oberflächenintegration mehrerer existierender Anwendungen. Derartige Tools verwalten Instanzen von Geschäftsprozessen, die aus einer Folge von Aktivitäten bestehen. Um Informationen zwischen Benutzungsschnittstellen verschiedener Systeme entlang der Aktivitäten eines Geschäftsprozesses auszutauschen, wird in diesem Fall wiederum die Screen-Scraping- Technik eingesetzt. Das Ziel, das durch diese Integration erreicht werden soll, ist eine bessere Benutzbarkeit und Funktionalität sowie eine konsistente Führung durch die Geschäftsprozesse zu schaffen. Der Nachteil dieser Vorgehensweise liegt darin, dass nur auf die durch die 15

16 Benutzeroberfläche der Altanwendung zur Verfügung gestellten Funktionalitäten zugegriffen werden kann [Ke02, S , Ka02, S. 62, 63] Integration über Funktionsaufrufe Die Integration über Funktionsaufrufe stützt sich auf die von den Anwendungen angebotenen Funktionalitäten. Die Anwendungen stellen dabei Anbieter von Diensten dar. Geschäftsprozesse, die aus einer Vielzahl einzelner Tätigkeiten bestehen, welche von verschiedenen Anwendungen ausgeführt werden, können auf diese Weise die benötigten Funktionen direkt ansprechen und aufrufen. Einfach ausgedrückt wird aus einer Anwendung die Funktionalität einer anderen Anwendung aufgerufen. Darüber hinaus ist es von Interesse, ob eine Anwendung eine fremde Funktionalität auf demselben Rechner oder auf einem anderen Rechner aufruft. Während im ersteren Fall keine besondere Infrastruktur erforderlich ist, werden im letzteren Fall Infrastrukturen wie DCE oder CORBA benötigt, damit entfernte Methodenaufrufe genutzt werden können [Ke02, Kap. 4, Ka02, S ] Integration über Datenbanken Bei der Integration über Datenbanken wird direkt auf die von den verschiedenen Anwendungen erzeugten Daten zugegriffen. Dies geschieht ohne Umwege über die Funktions- oder Präsentationsschicht. Eine Modifikation der Datenbanken oder der Anwendungslogik der zu integrierenden Anwendung ist somit nicht erforderlich. Der direkte Zugriff auf die Datenbasen dient dem gemeinsamen Gebrauch oder dem Abgleich redundanter Daten zwischen den Anwendungen. Als technische Realisierungsmöglichkeiten bietet sich neben dem direkten Zugriff auf die Datenbestände die gemeinsame Nutzung föderierter Datenbanken über Middleware an, auf welche in Kapitel 3.5 genauer eingegangen wird [Ke02, S. 67,68, Ka02, S.63-65] Integration über Komponenten Eine weitere Integrationsform ist die Integration über Komponenten. Eine Komponente stellt in diesem Fall ein Stück Software mit einer Schnittstelle dar. Zu dieser Variante der Integration können drei verschiedene Fälle unterschieden werden [Ke02, S ]. Zunächst besteht mit einem so genannten Plug-in die Möglichkeit eine Softwarekomponente in ein anderes Softwareprodukt einzuklinken. Hierbei muss das Softwareprodukt, in das sich eingeklinkt wird, über eine vordefinierte Schnittstelle verfügen, so dass für die Nutzung der anderen Softwarekomponente eine Erweiterung (Plug-in) programmiert werden kann. Weit verbreitete Beispiele für Plug-ins sind das Adobe Rea- 16

17 der/acrobat Plug-in oder der Macromedia Flash Player für die verschiedenen Webbrowser. Darüber hinaus ist es möglich, vorgefertigte Komponenten mittels eines Klebstoffs, welcher als GlueWare bezeichnet wird, zu integrieren. Die zentrale Idee dieses Vorgehens liegt in der Tatsache, dass mehrere Softwarekomponenten über Skriptsprachen relativ schnell integriert werden können. Wie bereits in Kapitel 2.2 beschrieben wird GlueWare vorzugsweise für die Integration von ERP-Software in die im Unternehmen bereits vorhandenen Anwendungen genutzt. Als letztes Szenario ist die Integration von Komponenten in so genannten Containern von Bedeutung. Durch die Verwendung eines Containers werden dem Anwendungsentwickler bestimmte Basisdienste wie z. B. Transaktionen, Persistenz und Zugriff auf entfernte Objekte geschenkt. Der Vorteil dieses Vorgehens liegt darin, dass der Programmierer im günstigsten Fall nur noch fachlichen Code schreiben muss, um die Komponenten zu erstellen sowie miteinander zu verbinden [Ku04, S.33]. 3.4 Kommunikationsarten Wie bereits in Kapitel angesprochen lassen sich die zwei verschiedenen Kommunikationsarten synchron und asynchron unterscheiden. Dieser Abschnitt dient der Erläuterung der dazugehörigen Kommunikationsstile, welche in einem EAI-Integrationsserver Verwendung finden können [Ke02, S und S ]. Überdies können Kommunikationsvorgänge neben diesem Unterscheidungsmerkmal zusätzlich noch nach den Kriterien verbindungslos- oder verbindungsorientiert sowie direkte- oder Warteschlangenkommunikation unterschieden werden. Im Gegensatz zu diesen beiden Kriterien wird die Kommunikationsart in [Ka02, S. 103] nur nach dem unterstützten Adressierungsmechanismus (Uni-, Broad- und Multicasting) charakterisiert, welche aber nicht so ausführlich ist, und auf welche deswegen in dieser Arbeit nicht näher eingegangen wird. Verbindungsorientiert bedeutet, dass Sender und Empfänger eine Verbindung aufbauen, Nachrichten austauschen, und anschließend diese Verbindung wieder trennen. Typischerweise ist dies ein synchroner Prozess, welcher aber auch asynchron sein kann. Demgegenüber bezeichnet verbindungslose Kommunikation einen Vorgang, bei dem der Sender keine Verbindung mit dem Empfänger eingeht. Im Allgemeinen weiß der Sender in diesem Fall nicht einmal, ob jemand seine Nachricht empfangen oder verarbeitet hat. Bei direkter Kommunikation wird die Nachricht ohne Umwege direkt vom 17

18 Sender zum Empfänger übermittelt. Eine Kommunikation mit Warteschlangen bietet hingegen eine Garantie für die Auslieferung der Nachrichten. Der Vorteil dieses Modells gegenüber der direkten Kommunikation liegt in der Tatsache, dass der Empfänger nicht aktiv sein muss, wenn der Sender ihm eine Nachricht schickt [Li99, S. 115] Synchrone Kommunikation Synchrone Kommunikation bedeutet, dass die Sender nach Verschicken der Nachricht solange blockieren, bis sie eine Antwort oder ein Ergebnis vom Empfänger erhalten. Dieses Verhalten, welches auch als Request/Reply-Stil bezeichnet wird, ist nur dann sinnvoll, wenn davon ausgegangen werden kann, dass der Empfänger empfangsbereit ist und schnell antworten kann. Anderenfalls, z. B. bei Absturz des Empfängers, könnte es dazu kommen, dass der Sender auf unbestimmte Zeit auf eine Antwort wartet und sich somit keinen anderen Aufgaben widmen kann. Aufgrund dieses Nachteils wird in der Mehrzahl von EAI-Systemen nicht die synchrone, sondern die asynchrone Kommunikation verwendet. Bevor auf diese im nächsten Abschnitt eingegangen wird, werden zunächst zwei Varianten der synchronen Kommunikation vorgestellt, die synchrone Einwegkommunikation sowie das synchrone Polling. Das Spezielle an der synchronen Einwegkommunikation im Gegensatz zur normalen synchronen Kommunikation liegt darin, dass der Empfänger, bevor er die Anfrage bearbeitet, eine Empfangsbestätigung an den Sender zurückschickt. Diese Variante ist in dem Fall von Vorteil, wenn der Sender lediglich wissen muss, dass seine Anfrage angekommen ist und bearbeitet wird. Bei der anderen Variante des synchronen Pollings fragt der Sender in bestimmten Zeitintervallen nach, ob seine Anfrage erledigt wurde und somit eine Antwort zurückgegeben werden kann. In der Zwischenzeit kann der Sender seine interne Verarbeitung fortsetzen. Erst wenn diese Nachfrage Erfolg hat, arbeitet der Sender mit dem Ergebnis weiter. Beide dieser Varianten haben den Vorteil, dass die Zeit, in der der Sender nicht weiterarbeiten kann, reduziert wird. Folglich wird der eigentliche Nachteil der synchronen Kommunikation ein wenig abgeschwächt [Ke02, S.80-82] Asynchrone Kommunikation Bei asynchroner Kommunikation, auch Message Passing genannt, arbeitet der Sender nach dem Abschicken einer Nachricht bereits weiter, ohne auf eine Antwort zu warten. Die Anfrage verbleibt dann unter Umständen längere Zeit in der Anfrageschlange beim Empfänger, ohne den Prozess komplett zu blockieren. Eine solche Entkopplung ermöglicht eine sehr flexible Arbeitsweise der Anwendungen. Neben dem Begriff Message 18

19 Passing wird dies auch als fire and forget bezeichnet. Die beiden hier in Frage kommenden Varianten sind die Broadcasting- und Publish/Subscribe-Kommunikation. Beim Broadcasting schickt der Sender die Nachricht über einen öffentlichen Kanal ab. Jeder Empfänger, der Zugang zu diesem Nachrichtenmedium hat, kann die Nachrichten verwerten oder nicht. Die grundsätzliche Idee hinter der Publish/Subscribe-Kommunikation ähnelt der des Broadcastings mit dem Unterschied, dass die Nachricht nur an Empfänger zugestellt wird, die im Vorhinein diese Nachricht oder das Thema der Nachricht abonniert haben [Ke02, S und Ju01 S.345] 3.5 Middleware Middleware ist eine Software, die es unabhängigen und verteilten Software-Produkten gestattet, miteinander zu interagieren, indem sie die jeweiligen Interaktionshindernisse beseitigt und die Interaktion gegebenenfalls durch Eigenleistungen unterstützt oder mitgestaltet. Durch einen homogenisierten Zugang zum Netzwerk wird ein plattformunabhängiger Datenaustausch zwischen Anwendungen unterschiedlicher Art ermöglicht [Rö01, S.10]. Aufgrund der begrifflichen Ähnlichkeit zu dem Hauptbegriff dieser Arbeit, wird hier zunächst eine Differenzierung zur Enterprise Application Integration vorgenommen. Der Unterschied zur EAI liegt darin, dass sich Middleware auf die interne Kommunikationsinfrastruktur eines Informationssystems bezieht, während EAI auf die externe Kommunikationsinfrastruktur zwischen verschiedenen Informationssystemen bezogen ist. Daher ist Middleware im Gegensatz zu EAI nicht in der Lage Geschäftsprozesse, die auf mehrere Systeme zugreifen, abzubilden. Middleware kann deshalb auch als zentraler Bestandteil von EAI-Lösungen gesehen werden, welcher die Integration auf Datenebene unterstützt. Der Informationsaustausch wird hierbei zwischen zwei oder mehreren Anwendungssystemen innerhalb einer heterogenen IV-Landschaft ermöglicht [Ka02, S. 102]. Grundsätzlich können vier Typen von Middleware unterschieden werden. Diese sind die Nachrichten-, Komponenten-, Datenbank- und Transaktionsorientierte-Middleware [Ka02, S. 104]. Für die im Abschnitt 3.3 besprochene Integration über Funktionsaufrufe kommt die Nachrichten- und die Komponentenorientierte Middleware in Frage, während für die Integration über Datenbanken, wie der Name es schon sagt, Datenbankorientierte Middleware eingesetzt wird [Ke02, S. 86]. Nachrichtenorientierte Middleware (MoM) ermöglicht den angebundenen Anwendungen eine Kommunikation durch die Nachrichtenweitergabe über Punkt-zu-Punkt- 19

20 Verbindungen. Durch die MoM wird eine standardisierte Schnittstelle zur Kommunikation zwischen heterogenen Plattformen angeboten. Ein Client muss also nur das Format der Nachrichten kennen und kann auf diese Weise mit jeder dieser über die Middleware angebundenen Anwendung in Verbindung treten, ohne deren spezifische Schnittstellen zu kennen. Hier können Nachrichten sowohl Datenstrukturen enthalten als auch Funktionsaufrufe darstellen. Eine Integration kann also auf Daten- und Funktionsebene vollzogen werden. Die Nachrichten werden automatisch an die entsprechenden Empfänger weitergeleitet. Dazu müssen alle Teilnehmer über Adapter mit der Middleware verbunden werden. Durch den Einsatz von Adressierungskonzepten werden sowohl Punkt-zu- Punkt-Verbindungen ermöglicht als auch Gruppenkommunikation im Sinne von Broadcasting und Publish/Subscribe Diensten. Zudem verfügt das Kommunikationssystem neben den Adressierungs- und Routingfunktionen auch über Verwaltungsmechanismen für Nachrichtenschlangen (Message Queues). Die Kommunikation kann wiederum entweder synchron ablaufen oder aber asynchron [Ka02, S ]. Die meisten EAI- Lösungen basieren jedoch auf einer MoM, die sich vorwiegend der asynchronen Kommunikation bedient. Dies hat unter anderem die Gründe, dass mit asynchroner Kommunikation, welche eine sehr allgemeine Kommunikationsform ist, alle anderen Formen nachgebildet werden können sowie dass sie hervorragend für lose gekoppelte Systeme geeignet ist. Weitere Ursachen können in [Ke02, S. 86] nachgelesen werden. Komponentenorientierte Middleware, auch Distributed Object Technology (DOT) genannt, ermöglicht den Aufruf von Funktionen verteilter und heterogener Anwendungen. Zur Integration auf Funktionsebene wird nach dem Grundprinzip der Remote Procedure Calls, oder in Java der Remote Method Invocation (RMI), verfahren. Die Middleware verwaltet hierbei die Objekte und steuert die Kommunikation. Die Kommunikation findet meist synchron nach dem Request/Reply Schema statt, das heißt, der Sender blockiert solange, bis er eine Antwort erhält. Ein etablierter Standard ist CORBA. Eingesetzt wird DOT auch in Microsofts Distributed Component Object Model (DCOM/COM+) mittels versionierter Interfaces (DLL) und bei J2EE mittels Enterprise Java Beans (EJB) [Ka02, S und Ke02, S ]. Datenbankorientierte Middleware ist die klassische Middleware-Form, die über einheitliche Schnittstellen den Zugriff auf heterogene Datenbestände ermöglicht. Ziel dieser Software ist die integrierte Sicht auf verteilte Daten im Sinne einer einzelnen virtuellen Datenbank. So kann jeder Client über eine einheitliche Schnittstelle an der virtuellen Datenbank Anfragen an jede beliebige, mit der Middleware verbundene Datenbank stellen und zwar ohne sich deren Ort bewusst zu sein oder ihre spezifische Syntax zu kennen. Für den Benutzer erfolgt der Ablauf also völlig transparent. Zur technischen Realisierung wird durch die Middleware entweder direkt auf die Schnittstellen der einzelnen Datenbanken zugegriffen, oder es werden Standardschnittstellen im Sinne von Call Le- 20