ASPEKTE DES EMPIRISCHEN SOFTWARE ENGINEERING IM UMFELD VON ENTERPRISE APPLICATION INTEGRATION LÖSUNGEN

Transkript

1 ASPEKTE DES EMPIRISCHEN SOFTWARE ENGINEERING IM UMFELD VON ENTERPRISE APPLICATION INTEGRATION LÖSUNGEN Daniel Reitz, Andreas Schmietendorf, Reiner Dumke Evgeni Dimitrov, Jens Lezius, Thomas Schlosser Arbeitsgruppe Softwaretechnik Software Measurment Laboratory (SMLab) Otto-von-Guericke-Universität Magdeburg Fakultät Informatik Institut für Verteilte Systeme Postfach 4120, Magdeburg T-Systems Nova GmbH, Entwicklungszentrum Berlin, KG STE T-Systems Nova EZ Berlin Postanschrift: Postfach 652, Berlin Hausadresse: Wittestr. 30H, Berlin

2 2

3 3 Abstrakt Die kommenden Jahre werden durch einen ständigen Wandel von Geschäftsprozessen geprägt sein, welche durch Informationssysteme effizient zu unterstützen sind. So genannte Enterprise-Application-Integration-Lösungen (kurz EAI) spielen in diesem Kontext eine zunehmend wichtigere Rolle, dem sich auch das Software-Engineering stellen muss. EAI-Lösungen zeichnen sich durch eine intelligente Vorgehensweise bei der Realisierung benötigter Schnittstellen zwischen den zu integrierenden Anwendungen aus. Während auf technischer Ebene eine weitgehende Entkopplung der zu integrierenden Anwendungen angestrebt wird, sollen Geschäftprozesse möglichst variabel zusammengeschaltet werden können. Die Vision ist es neue Integrationsanforderungen auf der Basis bestehender technischer Lösungen einfach konfigurieren zu können und notwendige Entwicklungsarbeiten auf ein Minimum zu beschränken. Im Rahmen dieses Preprints werden potentielle Einflusskriterien aufgezeigt und auf ausgewählte Notationen, Methoden und Tools zur Unterstützung des Software Engineering von EAI-Lösungen eingegangen. Darüber hinaus werden erste im praktischen Umfeld gewonnene empirische Erfahrungen wiedergegeben, die wesentliche Aufgaben auf dem Gebiet der technologiebezogenen- als auch Grundlagenforschung zur Effizienz komplexer Systeme implizieren. Die vorliegende Arbeit wurde in Kooperation zwischen dem Software Messlabor der Ottovon-Guericke-Universität Magdeburg und der Kompetenzgruppe System- und Technologieentwicklung des EZ Berlin innerhalb der T-Systems International erarbeitet.

4 4

5 5 Inhaltsverzeichnis 1 EINFÜHRUNG UND MOTIVATION 9 2 VERFÜGBARE LÖSUNGSANSÄTZE IM EAI-UMFELD Historische Entwicklung der EAI Schichtenmodell der Applikationsintegration Integrationslevel Datenaustausch mit XML Dienste von EAI-Lösungen Produkte im EAI-Umfeld 18 3 MIDDLEWARETECHNOLOGIEN FÜR DEN EAI-EINSATZ Kommunikationsformen Datenbankzugriffsmechanismen und -middleware Remote Procedure Call (RPC) Distributed Object Middleware Messageorientierte Middleware Komponentenorientierte Middleware Web Services Middlewareeinsatz in EAI-Projekten 31 4 BEISPIELE PRAKTISCHER IMPLEMENTIERUNGEN IM EAI-UMFELD Realisierung eines Common Information Bus Überblick zur Architektur der Integrationslösung Details der Integrationsapplikation Der CIB Agent EAI-SIM Anforderungen Realisierungskonzept Beschreibung der Lösung Ausblick und Weiterentwicklung 39 5 VORGEHENSWEISE ZUR IMPLEMENTIERUNG VON EAI-LÖSUNGEN Überblick zum Vorgehen Phasen eines Integrationsprojektes 41

6 6 6 MESS- UND BEWERTUNGSANSÄTZE FÜR EAI-LÖSUNGEN Potentielle Bewertungsaspekte Produktbewertung Prozessbewertung Ressourcenbewertung Aufwand- und Nutzensbetrachtungen von EAI-Projekten Verwendung von Integration Points Nutzensbetrachtungen Empirische Schnittstellenbetrachtungen Empirische Analysen einer EAI Integrations-Applikation Analyse der Version Analyse der Version Bewertung und Erkenntnisse Performanceanalyse einer EAI Integrations-Applikation Ziele und verfügbare Arbeiten Performancegerechte EAI-Entwicklung EAI-konformes Lastmodell Testdurchführung Ausgewählte Ergebnisse 65 7 ZUSAMMENFASSUNG 67 QUELLENVERZEICHNIS 68 ANLAGEN 70

7 7 Abbildungsverzeichnis Abbildung 1: Applikations- und Schnittstellen Spagetti 10 Abbildung 2: Unternehmensapplikationen mit EAI-Plattform 11 Abbildung 3: EAI-Schichtenmodell 13 Abbildung 4: Level der Integration 15 Abbildung 5: AIM Key Market Segments Forecast; in Millions USD 19 Abbildung 6: Lizenzumsatz im EAI-Markt bis Abbildung 7: Einordnung der Middleware in das OSI-Schichtenmodell 20 Abbildung 8: Kommunikationsbus für verteilte Anwendungen 21 Abbildung 9: Synchrone Kommunikation 22 Abbildung 10: ODBC-Kopplungsarchitektur [Conrad 1997] 23 Abbildung 11: Funktionsweise von RPC 24 Abbildung 12: OSF DCE Architektur 25 Abbildung 13: Die OMG Objekt Management Architektur (OMA) 26 Abbildung 14: Message-Queue basierte Kommunikation 27 Abbildung 15: EJB Architektur 28 Abbildung 16: Web Service Architektur 30 Abbildung 17: AIM Key Market Segments, License Sales 2001 in Mio. US-Dollar 31 Abbildung 18: Übersicht zur System-Architektur 33 Abbildung 19: Prinzip der Softwarearchitektur der Integrationsapplikation 34 Abbildung 20: Architektur des CIB-Agenten 35 Abbildung 21: EAI-SIM Homepage 38 Abbildung 22: EAI-SIM Webanwendung 39 Abbildung 23: Vorgehensweise zur Implementierung einer EAI-Lösung 40 Abbildung 24: Prinzip zur Ermittlung der Integration Points 50 Abbildung 25: Ungerichteter Graph mit 4 Knoten und 6 Kanten 52 Abbildung 26: potentielle Schnittstellen im Peer-to-Peer Netz und bei einer EAI-Lösung 53 Abbildung 27: Anzahl der Systeme und Schnittstellen 54 Abbildung 28: Ausprägung der verwendeten Session Beans 55 Abbildung 29: Ausprägung der verwendeten Entity Beans 56 Abbildung 30: Zusammenhang zwischen Bean-Klasse und Home-Interface 56 Abbildung 31: Umfangsanalyse von Session Beans (kurz SB) 57 Abbildung 32: Ausprägung der Entity Beans 58 Abbildung 33: Verhältnis zwischen Remote-Interface und Bean-Klasse 58 Abbildung 34: Session Bean und Bean-Klasse 59 Abbildung 35: Entity Bean und Bean-Klasse 60 Abbildung 36: Session Bean und Remote Interface 60 Abbildung 37: Entity Beans und Remote-Interfaces 60 Abbildung 38: Generisches Lastmodells der EAI-Anwendung 63 Abbildung 39: Übersicht zu genutzten Hard- und Softwaresystemen 64 Abbildung 40: Ergebnisse des Benchmarks (hier Laufzeit der Nachricht) 65

8 8 Tabellenverzeichnis Tabelle 1: Bespiele für CORBA-Services 26 Tabelle 2: Beispiele für EJB-Container Dienste 29 Tabelle 3: Vorschläge für die Analyse der Produktfeatures 47 Tabelle 4: Vorschläge für die Analyse der Produktperformance 47 Tabelle 5: Vorschläge für die Ermittlung der Plattformkosten 48 Tabelle 6: Ergebnis der Schnittstellenanalyse 53 Tabelle 7: Verweilzeiten der Bearbeitung (alle Zeiten der Tabelle in ms) 66

9 9 1 Einführung und Motivation Die zunehmende Globalisierung und Dynamisierung der Märkte ruft weiträumig agierende Unternehmen hervor, die innerhalb so genannter VACs (Value Added Communities) ihre wirtschaftlichen Zielstellungen verfolgen (siehe dazu auch [Means 2000]). Im Rahmen sowohl strategischer als auch zeitweiser Partnerschaften (dies impliziert auch eine Zusammenarbeit auf Anforderung) erfolgt eine gemeinsame Vermarktung von Produkten, die Integration von Produktions- und Lieferantenbeziehungen, der gemeinsame Zugriff auf Informationen und Services beteiligter Unternehmen sowie der Zugriff auf technische und auch auf menschliche Ressourcen. Wenngleich diese Form der Zusammenarbeit auch schon vor vielen Jahrzehnten angestrebt wurde, ermöglichen erst der Einsatz und vor allem die Integration rechnergestützter Informationssysteme die effiziente Umsetzung dieser Idee. Da die im Rahmen von VACs agierenden Unternehmen typischerweise eine gewachsene Anwendungslandschaft mitbringen und eine Neuentwicklung vorhandener Softwareanwendungen keine wirtschaftlich vertretbare Lösung darstellt, gilt es vorhandene und zukünftige Anwendungen so zu gestalten, dass diese mit anderen IT-Systemen auf der Basis standardisierter Schnittstellen interagieren können. Mit derartig integrierten Systemen sind sowohl unternehmensweite als auch unternehmensübergreifende Geschäftsprozesse möglichst durchgängig zu gestalten. In diesem Zusammenhang wird dann von so genannten EAI-Lösungen gesprochen. Die folgende ins Deutsche übersetzte Definition charakterisiert derartige Systeme noch einmal zusammenfassend (in Anlehnung an [Juric 2002, S. 12]): Mittels EAI können Daten und Geschäftsprozesse auf der Basis netzwerkbasierter Applikationen oder Datenquellen unternehmensweit genutzt werden. Frühe Software- Programme, wie z.b. Bestands- und Personalverwaltung, Verkaufssysteme und Datenbanksysteme, wurden weitgehend unabhängig voneinander entwickelt, ohne die potentiellen Interaktionen zwischen diesen Systemen zu berücksichtigen. Diese wurden unter Verwendung der jeweils aktuellen Technologien auf spezielle Kundenbedürfnisse hin entwickelt, wobei häufig proprietäre Systeme entstanden. Mit dem zunehmenden Wachstum der Unternehmen und der Erkenntnis, Daten und Funktionen einer Applikationen austauschen und unternehmensweit nutzen zu können, erfolgte die Investition in entsprechende EAI-Lösungen. Die letzten Jahrzehnte waren insbesondere durch die fortwährende Entwicklung immer neuer Applikationen geprägt, welche häufig nur ausgewählte Funktionen eines umfassenden Geschäftsprozesses berücksichtigen. Somit entstand in vielen Firmen eine große Anzahl an unabhängig voneinander entwickelten proprietären und autonomen Anwendungen (teilweise mit eigener Datenhaltung), die ausschließlich über direkte Punkt-zu-Punkt (Peer-to-Peer) Verbindungen miteinander kommunizieren. Mit Abbildung 1 soll ein so genanntes Spagetti- Netzwerk beispielhaft dargestellt werden. Die dort aufgeführten Abkürzungen haben dabei die folgenden Bedeutungen: CRM Customer Relationship Management, ERP Enterprise Ressource Planning und SOP Sales Order Processing. Der Nachteil einer solchen Struktur liegt in einer kaum noch zu beherrschenden Systemkomplexität. Bedingt durch die dezentralistischen Datenhaltungen der einzelnen Applikationen können Redundanzen an Daten und Funktionalitäten entstehen, die Inkonsistenzen möglich machen. Änderungen und Erweiterungen am System mit neuen Technologien, Applikationen oder Produkten sind sehr aufwendig und erschweren damit die Integration weiterer Systeme (beispielsweise bei Akquisitionen, Fusionen und Globalisierungsprojekten) und die Skalierbarkeit bei neuen Anforderungen. Je größer die Anzahl der verschiedenen Systeme ist, desto höher werden die Kosten für die Administration und Wartung; die Sicherheit, die Stabilität und die Performance und damit auch der Time-to-Market Wert können sich verschlechtern.

10 10 Abbildung 1: Applikations- und Schnittstellen Spagetti Aktuelle Herausforderungen liegen im Zusammenschluss vorhandener, aber auch in neu zu entwickelnden Systemen. Dabei wird sowohl die Integration unternehmensinterner Systeme angestrebt als auch die Integration von Systemen über Unternehmensgrenzen hinaus. Ebenfalls im Fokus stehen die Integration der Nutzerzugänge durch die Verwendung webbasierter Portale und die Möglichkeit, für Kunden auf ausgewählte Informationen zuzugreifen. In diesem Zusammenhang spielen so genannte Multi-Channel-Zugänge (z.b. WAP, Web, PDA,...), welche die Verwendung unterschiedlichster Endgeräte ermöglichen, eine wesentliche Rolle. Mit der Implementierung von Enterprise Application Integration Lösungen werden die folgenden konkreten Zielstellungen verfolgt: Integration heterogener Systemwelten, Vermeidung von redundanten Daten und Funktionalitäten, Minimierung der Systemkomplexität, Steigerung der Änderbarkeit, Erweiterbarkeit und Skalierbarkeit des Gesamtsystems, Vereinfachung der Wartung und Administration, Automatisierung und Dynamisierung von Geschäftsprozessen, Zentralisierung der Kontrolle durchgeführter Zugriffe, Optimierung der GP-Performance (time to market), Vereinfachte Anbindung an Zulieferer, Partner und Kunden (B2B, B2C), Senkung der Gesamtkosten. Erreicht werden kann das durch die Einführung einer zentralen Integrationsschicht und die Ersetzung der vielen Punkt-zu-Punkt Verbindungen durch jeweils eine Schnittstelle pro System zur EAI-Plattform (siehe Abbildung 2). Die Datenhaltung wird zentralisiert und ein einheitliches Datenformat zum Nachrichtenaustausch eingeführt. Erst dadurch entsteht die Möglichkeit systeminterne und systemübergreifende Geschäftsprozesse computergestützt zu modellieren und dann automatisiert ablaufen zu lassen. Das Unternehmen kann flexibler auf Anforderungsänderungen reagieren.

11 11 ERP E-Commerce CRM Legacy Systeme EAI-Plattform Kunden Datenbank SOP Produkt Datenbank Call Center Abbildung 2: Unternehmensapplikationen mit EAI-Plattform Im Zusammenhang mit der Implementierung von EAI-Lösungen gewinnen die Themenstellungen der Konvergenz zunehmend an Bedeutung. Konvergenz bezieht sich auf die Nutzung von Diensten über Länder-, aber auch Unternehmensgrenzen hinaus. Ein Kunde möchte z.b. an verschiedenen Orten der Welt seine wohlbekannten Dienste (z.b. Weiterleitung der im Home-Office eingehenden Anrufe) vorfinden und die Leistungen nur auf einer Rechnung nachvollziehen können. Unternehmen müssen sich diesen Anforderungen aus technologischer und geschäftlicher Sicht stellen. Dementsprechend sind konvergenzsichernde Technologien und Geschäftsmodelle zu etablieren. Der Fokus sollte dabei auf der Kundensicht liegen. Die Konvergenz-Landschaft wird durch die Kundenanforderungen getrieben, die mittels durchgängiger und integrierter Netzwerke und Services zu erfüllen sind. Dabei ist eine wachsende Anzahl potentieller Endgeräte zu unterstützen. Der vorliegende Preprint dient, ausgehend von einer verbalen Beschreibung grundlegender EAI-Technologien, als eine erste Übersicht zu möglichen empirischen Analysen in diesem Bereich. Erste Ansätze und industrielle Untersuchungen verdeutlichen die Prägnanz für die Anwendung derartiger Technologien und fokussieren den Forschungsbedarf für die Systembeherrschung unter den Bedingungen gewählter Komplexitätsmodelle.

12 12 2 Verfügbare Lösungsansätze im EAI-Umfeld Nach der Einführung im vorhergehenden Abschnitt soll als Nächstes auf den Begriff EAI etwas näher eingegangen werden. Dazu gehört ein kurzer historischer Abriss über die Entwicklung der EAI, die Vorstellung von involvierten Technologien, Integrationsstrategien und auf dem Markt angebotenen Produkte für EAI-Lösungen. 2.1 Historische Entwicklung der EAI 1 In den fünfziger und sechziger Jahre waren Anwendungen in Unternehmen noch sehr einfach gestrickt, was Funktionalität und Umfang betraf. Eine Zusammenarbeit zwischen den Applikationen war damals nicht notwendig bzw. sinnvoll. Durch Einführung von Festplattenspeichern und Datenbanktechnologien Ende der Sechziger, Anfang der Siebziger, konnten Programmierer direkt auf Informationen zugreifen, ohne den Umweg über sequentielle Dateien gehen zu müssen. In dieser Zeit wurde damit begonnen, über die Integration von Unternehmensdaten nachzudenken. In den Achtzigern begann man immer mehr den Wert und die Notwendigkeit von Applikationsintegration zu verstehen. In dieser Zeit entstanden einige der Middlewaretechnologien, die teilweise auch heute noch genutzt werden (RPC 1982, CORBA 1989). Viele der Anwendungen aus den siebziger Jahren mussten an die neuen Herausforderungen der IT-Abteilungen der Untenehmen angepasst werden. Durch die Versuche, bestehende ältere Systeme zu integrieren, kam allerdings die Neuentwicklung zu kurz. Ein Großteil der bestehenden Energien wurde darauf ausgerichtet, existierende Applikationen mit immer neuen benötigten Features auszustatten. Zwei neue Technologien sollten Anfang der neunziger Jahre antreten, um die Probleme der Applikationsintegration zu lösen: Enterprise Ressource Planning 2 (ERP) und Data Warehousing 3. Beide haben verschiedene Ausrichtungen. ERP integriert die operationalen Aspekte eines Unternehmens und Data Warehousing die anfallenden Daten. Die Weiterentwicklung dieser Technologien und die Entstehung von neuen (z.b. messageorientierte Middleware Mitte der Neunziger) resultiert in der EAI, wie wir sie heute vorfinden. Dazu gehören beispielsweise Strategien wie das Supply Chain Management (SCM), die Business-to-Business Integration (B2B) sowie die Business Prozess Integration (BPI). 2.2 Schichtenmodell der Applikationsintegration Eine automatisierte Abbildung der Geschäftsprozesse auf die IV-Struktur eines Unternehmens ist, wie schon festgestellt wurde, nur über die Integration der beteiligten Applikationen möglich. Wie man sich sicher vorstellen kann, ist dies, abhängig von der Größe des Unternehmens, ein relativ aufwändiger und kostenintensiver Prozess, da eine große Anzahl von unternehmensspezifischen Einflussfaktoren berücksichtigt werden muss. Eine einfache Install and Run - Lösung ist somit kaum realisierbar. Um den Umfang und die Komplexität der Aufgaben, die bei EAI-Projekten anfallen, besser verstehen zu können, soll hier ein Schichtenmodell vorgestellt werden, das die Aspekte der Unternehmensintegration aufeinander aufbauender Teilgebieten zuordnet und notwendige Tätigkeiten entsprechend zuteilt. 1 Quelle: William Inmon, "A Brief History of Integration." ( 2 COMMUNICATIONS OF THE ACM, February 2003/Vol. 46 No 2: Enterprise Integration with ERP and EAI 3 Siehe auch [Mattison 1996]

13 13 Abbildung 3: EAI-Schichtenmodell Abbildung 3 zeigt eine Möglichkeit für ein solches EAI-Schichtenmodell. Auf die einzelnen Ebenen soll im Folgenden etwas detaillierter eingegangen werden: Plattform-Integration Die Plattform-Integration bildet die unterste Ebene des EAI- Schichtenmodells. Auf dieser Stufe ist es notwendig, die zugrunde liegenden Hard- und Softwarearchitekturen im heterogenen Unternehmensnetzwerk miteinander zu verbinden. Integration bedeutet hier, die Kommunikation zwischen den Unternehmensapplikationen möglichst effizient und sicher zu ermöglichen. Dazu muss u.a. zwischen verschiedenen Netzwerktypen, Hardwareplattformen und Betriebsystemen mit eigenen Technologien und Strategien zum Informationsaustausch, vermittelt werden. Ein Beispiel ist hier die Umstellung eines heterogenen Firmennetzwerkes auf das einheitliche und von fast allen Systemen unterstützte TCP/IP-Protokoll. Middleware-Integration Bei heutigen Unternehmen kann davon ausgegangen werden, dass ein Grossteil der existierenden Applikationen über die schon oben erwähnten Peer-to-Peer Verbindungen direkt miteinander kommuniziert. In diesen Fällen kommt eine so genannte Middlewaresoftware zum Einsatz, die den Nachrichtenaustausch ermöglicht. Bei der Integration der beteiligten Applikationen und der damit verbundenen Ersetzung der direkten Verbindungen durch Schnittstellen zur EAI-Plattform müssen diese Middlewaretechnologien durch die EAI- Middleware ausgetauscht und die Systeme daran angepasst werden. Ist dies nicht möglich, wird es notwendig, spezielle Adapter, die die Kommunikation ermöglichen, einzusetzen. Typische Middlewareansätze sind beispielsweise DCE RCP, COM+/DCOM, CORBA und EJB (mehr zum Thema Schnittstellen und Middleware siehe Abschnitt 3). Daten-Integration Eine der Schlüsselaufgaben in EAI-Projekten ist sicherlich die Integration der verschiedenen applikationsspezifischen Datenbanken zu einer unternehmensweiten Datenbasis mit zentralisiertem Zugriff über die EAI- Plattform. Dazu ist es notwendig, dass Unternehmensdaten, inklusive dem jeweiligen Speicherort und dem Datenbankschema, für jede Applikation identifiziert und katalogisiert werden und dass ein unternehmensweites Metadatenmodell er-

14 14 stellt wird, um gezielt auf die Informationen zugreifen zu können. Soweit möglich, sollten Datenbanken zusammengefasst werden, um unnötige Redundanzen zu vermeiden und Inkonsistenzen ausschließen zu können. Eine weitere Aufgabe dieser Ebene ist die Einführung eines einheitlichen Datenaustauschformates, für das sich beispielsweise XML (siehe auch Abschnitt 2.4) anbieten würde. Applikations-Integration Auf der Höhe dieser Integrationsebene besteht nur noch eine eher abstrakte Sicht auf die zugrunde liegende IV-Struktur des Unternehmens. Hier besteht die Aufgabe darin, die Daten und Funktionalitäten der Applikationen dem Gesamtsystem zur Verfügung zu stellen. Erleichtert oder erst ermöglicht werden dadurch beispielsweise automatisierte Verbindungen zwischen dem Back-Office und dem Front-Office, B2B-Lösungen und ein integrierter Web- Auftritt. Die Integration der Applikationen auf dieser Stufe ist die Vorraussetzung für ein integriertes Unternehmen auf Geschäftsprozessebene. GUI-Integration Wenn für alle integrierten Applikationen eine zentralisierte und einheitliche Nutzeroberfläche zur Verfügung gestellt wird, spricht man von der GUI-Integration. Potentiell geeignet sind dafür Web-Technologien, die einen Zugriff über das Internet/Intranet ermöglichen. Geschäftsprozess-Integration Hierbei handelt es sich um die höchste Stufe der EAI. Um Geschäftsprozesse integrieren zu können, ist es notwendig, dass existierende Geschäftsprozesse identifiziert, kombiniert und automatisiert werden. Dazu gehört die Verknüpfung von Aufgaben, Prozeduren, Organisationen, Informationsströmen und Anwendungen, die an den verschiedenen Geschäftsprozessen beteiligt sind. 2.3 Integrationslevel Neben dem Schichtenmodell aus dem vorhergehenden Abschnitt trifft man häufig in der Literatur 4 auf die Level der Integration, bei denen die Darstellung der Komplexität der Applikationsintegration und die Verteilung der Tätigkeiten im Vordergrund stehen. Die im Folgenden kurz vorgestellten EAI-Level (siehe auch Abbildung 4) dienen zur Festlegung des Umfanges der Integration aus Sicht des Unternehmens: Data-Level EAI Data-Level EAI ist aufgrund der geringen Kosten und des damit verbundenen geringen Risikos für viele Firmen der Einstiegspunkt in die Enterprise Application Integration. Integriert wird bei diesem Level auf der Ebene der Datenhaltung (siehe Abschnitt 2.2, Daten- Integration) und umgeht damit die Stufe der Applikations-Integration. Eine Anpassung der Zielanwendungen ist in den meisten Fällen nicht notwendig. Für die Data-Level EAI existieren zwei Ansätze. Beim ersten Ansatz werden Daten zwischen Datenbanken durch die periodische oder ereignisgesteuerte Synchronisation von Datenbankinhalten ausgetauscht. Diese Lösung entspricht virtuell der Punkt-zu-Punkt Kommunikation und kann somit in fast allen Fällen eingesetzt werden. Sollen Daten zwischen Datenbanken mit verschiedenen Datenbankmodellen (z.b. relational und objektorientiert) ausgetauscht werden, muss man diese transformieren. Der zweite Ansatz geht von einer Föderation der Datenbanken aus. Dabei wird anhand einer Middleware eine Schnittstelle auf ein unternehmensweites virtuelles Datenmodell geschaffen, unter dem alle Datenbanksysteme, unabhängig vom Hersteller, vom Modell und vom Schema, 4 B. Lublinsky - Achieving the Ultimate EAI Implementation,

15 15 zusammengefasst werden. Alle Applikationen haben somit einen zentralisierten Zugriff auf alle Unternehmensdaten. Abbildung 4: Level der Integration Message-Level EAI Auf diesem Level erfolgt der Informationsaustausch zwischen den Applikationen auf der Basis von Nachrichten. Das heißt, dass die Applikationen direkt miteinander kommunizieren können, ohne den Umweg über die Datenbanken nehmen zu müssen, wobei allerdings voraussetzt wird, dass diese Art der Kommunikation von den zu integrierenden Systemen direkt unterstützt werden muss. Der Vorteil liegt hierbei in dem besser zu kontrollierenden Informationsaustausch. Message-Level EAI ist aufwendiger als die Data-Level EAI, da die Applikationen mit Mechanismen und Schnittstellen zum Austausch von Nachrichten erweitert werden müssen. Im Gegensatz zu den Punkt-zu-Punkt Verbindungen wird hier der Publish-Subscribe Ansatz verfolgt. Bei einem Business-Event veröffentlicht die auslösende Applikation eine entsprechende Nachricht im Netzwerk. Eine andere Applikation, der Abonnement, holt sich aufgrund einer speziellen Kennzeichnung die Nachricht ab und kann dann damit weiterarbeiten. Der Nachteil bei diesem EAI-Level liegt im höheren Aufwand gegenüber der Data-Level EAI und in der ebenfalls hohen Kopplung der einzelnen Systeme untereinander. Process-Level EAI Bei der Prozess-Level EAI handelt es sich um die Form der Applikations-Integration, wie sie mit diesem Artikel eigentlich dargelegt werden soll. Die Integration erfolgt hier auf Basis von Geschäftsprozessen, wobei die EAI-Middleware als Workflow-Engine fungiert und damit sozusagen den Mittelpunkt der IV-Struktur des Unternehmens bildet. Alle Unternehmens- Applikationen sind entweder direkt oder über zwischengeschaltete Adapter mit ihr verbunden. Sie hat die Aufgabe, Schnittstellen für die existierenden Anwendungen bereitzustellen, den

16 16 nachrichtenbasierten Informationsaustausch anhand definierter Geschäftsprozesse im System zu routen und die ausgetauschten Daten zwischen applikationsspezifischen Formaten zu transformieren. Es existieren zwei Ansätze für die Implementation der Process-Level EAI: Message Broker und Application Server. Während sich Message Broker rein auf das Routen der Nachrichten beschränken und damit die Geschäftsprozess-Logik in den Anwendungen belassen, verlagern Application Server diese in die EAI-Plattform. Dadurch erhöhen sich noch einmal die Flexibilität, die Erweiterbarkeit und die Skalierbarkeit des Systems, allerdings auch gleichzeitig der Aufwand bei der Umsetzung. Die Geschäftsprozess-Integration ist die am weitesten fortgeschrittene Form der EAI. Sie erlaubt es einem Unternehmen, die Effizienz von Prozessen zu steigern, Kosten zu sparen und auf Kundenbedürfnisse besser zu reagieren. Welches Level aber letztendlich eingesetzt wird, ist von den Bedürfnissen des Unternehmens und den aufzubringenden Kosten abhängig. Gerade bei kleineren Firmen mit einer überschaubaren IV-Struktur und relativ kleinem Budget kann die Integration auf Daten- oder Nachrichtenebene durchaus genügen. 2.4 Datenaustausch mit XML Mit dem Start eines EAI-Projektes in einem Unternehmen muss man sich über ein einheitliches Datenformat Gedanken machen, da ansonsten die ständigen Transformationen zwischen den proprietären Formaten die Fehleranfälligkeit und die Laufzeit von Transaktionen im System erhöhen. Als ein de facto Standard für Datenbeschreibungssprachen im EAI-Umfeld hat sich XML (extensible Markup Language) durchgesetzt. Sie ist plattformunabhängig, menschenlesbar und wird von einer großen Anzahl an EAI bezogenen Produkten und Unternehmensapplikationen mit Import- und Export-Funktionen unterstützt. XML ist an sich, auch wenn es der Name anders impliziert, keine Markup 5 -Language, sondern stellt vielmehr eine Menge von Regeln dar, um neue Markup-Languages zu erzeugen. Entstanden ist XML als eine vereinfachte Teilmenge der Standard Generalized Markup Language (SGML), welche 1987 von Dr. Charles Goldfarb, Ed Mosher und Ray Lorie aus der GML in einen Industrie-Standard (ISO 8879) überführt wurde. Von ihr stammt beispielsweise auch HTML ab. GML (Generalized Markup Language) wurde ursprünglich entwickelt, um Kennzeichen, beispielsweise für das Layout oder den Font, in Texten für das Verlagswesen zu formalisieren. Heute dienen Markups allgemein dazu, die logische Struktur eines Dokumentes vom Inhalt zu trennen. Diese Struktur wird dazu genutzt, den Zweck der enthaltenen Daten zu beschreiben. Man spricht in diesem Falle auch von Meta-Daten. Eine mit XML definierte Markup- Language besteht aus einer Anzahl von Markup Tags (Kombination aus Wörtern und Sonderzeichen zur Beschreibung des Zwecks der Daten) und einer für die Dokumente spezifischen Baumstruktur. Die Tags und die Baumstruktur (oder Content Model) werden in der DTD- Datei (DTD Document Type Definition) niedergeschrieben. Mehr zum Thema XML findet sich u.a. in [Daconta 2000]. 2.5 Dienste von EAI-Lösungen An eine moderne EAI-Plattform werden eine Menge Anforderungen gestellt. Sie sollte möglichst performant, skalierbar, offen und sicher sein. Sie sollte die Geschäftsprozessintegration genauso unterstützen wie die Business-to-Business Integration und die Integration aller Nutzeroberflächen der beteiligten Applikationen. Des Weiteren sollte sie über entsprechende Tools leicht zu administrieren sein, möglichst viele Standard-Applikationen und Hard- und 5 Extensible Markup Language Erweiterbare Textauszeichnungs/Textkennzeichnungs-Sprache

17 17 Softwarearchitekturen unterstützen, und sie sollte eine spezifische Entwicklungsumgebung mitbringen, um eine Anpassung der IV-Struktur des Unternehmens zu ermöglichen. Welche Dienste muss eine solche EAI-Lösung also anbieten, um die an sie gerichteten Bedürfnisse befriedigen zu können? Die folgende Liste stellt eine Übersicht über die wichtigsten EAI- Services dar: Plattform- und Protokollmanagement Dazu gehört die Unterstützung einer Vielzahl von Hard- und Softwareplattformen, Middlewaretechnologien im heterogenen Unternehmensnetzwerk und verschiedener Kommunikationsprotokolle. Synchronous, Asynchronous Support Je nach Aufgabenstellung kann die Nutzung eines synchronen oder eines asynchronen Datenaustausches sinnvoller sein. Des Weiteren ist es möglich, dass verschiedene Middlewarelösungen im Unternehmen im Einsatz sind, die nur eine der beiden Strategien unterstützen. Daher sollte eine EAI-Lösung Dienste zur Nutzung des synchronen oder asynchronen Datenaustausches und zur Vermittlung zwischen den beiden Technologien (Bridging) anbieten. Security Management Eine sehr wesentliche aber auch sehr komplexe und verantwortungsvolle Aufgabe ist das Security Management. Unternehmensdaten sind oftmals sehr sensibel und dürfen daher auf keinen Fall in die falschen Hände geraten. Eine EAI-Lösung hat daher die Aufgabe, wirkungsvolle Mechanismen für die Verschlüsselung von Kommunikation und Daten und zur Authentifizierung von Nutzern und Nutzergruppen anzubieten, um spezielle Bereiche und Informationen nur ausgewählten Personen zur Verfügung zu stellen. Daten Transformation und Mapping Dazu gehören Dienste zur weiter oben bereits erwähnten Umwandlung von proprietären Datenformaten in das einheitliche XML-Format, sowie Mechanismen zum Parsen von XML-Dateien und Nachrichten Daten- und Nachrichten-Persistens Die persistente Speicherung von Daten und Nachrichten in Knotenpunkten von Übertragungseinrichtungen und Servern dient zur Sicherung der Zuverlässigkeit von Kommunikationswegen und zur Wahrung der Konsistenz des Gesamtsystems beim Ausfall von einzelnen Systemen, die an der Übermittlung und Verarbeitung der Daten und Nachrichten beteiligt sind. Sollte es zu einem Ausfall kommen, so kann zur Wiederherstellung der Konsistenz mit Hilfe der gespeicherten Informationen ein Rollback durchgeführt werden. Transaktionsverwaltung Operationen auf Datenbankinhalten bestehen grundsätzlich aus einer Anzahl von schreibenden und/oder lesenden Zugriffen. Transaktionen sind Datenbankoperationen, die die ACID Eigenschaften besitzen. ACID steht für: o Atomicity Eine Operation wird entweder vollständig oder gar nicht ausgeführt. Falls eine Operation nicht vollständig ausgeführt wird, müssen alle vorgenommenen Änderungen rückgängig gemacht werden, um die Konsistenz zu wahren.) o Consistency Durch eine Transaktion darf die Konsistenz der Datenbank nicht gefährdet werden. Daher müssen nach der entsprechenden Operation Überprüfungen der Integritätsbedingungen vorgenommen werden. o Isolation Eine Person darf nur auf Daten zugreifen, die von keiner anderen Person bearbeitet werden. Sie hat damit einen exklusiven Zugriff.

18 18 o Durability Nach einer erfolgreichen Transaktion müssen die Ergebnisse der Operation persistent in der Datenbank vorliegen. Alle nachfolgenden Operationen beziehen sich damit auf den aktualisierten konsistenten Inhalt der Datenbasis. Die Transaktionsverwaltung hat die Aufgaben die ACID-Eigenschaften für Transaktionen zu garantieren und eine Abarbeitungsfolge (Scheduling) für Operationen von verschiedenen Nutzern festzulegen. Routing Services Da in einem integrierten Unternehmen die Applikationen im Idealfall nicht mehr direkt miteinander kommunizieren, hat die EAI-Plattform die Aufgabe, die Nachrichten und Informationen anhand von definierten Geschäftsprozessen weiterzuleiten. Des Weiteren sollte sie den Anwender bei der Eingabe und Definition dieser Geschäftsprozesse vorzugsweise mit einem grafischen Editor unterstützen. Load-Balancing Load-Balancing bedeutet die Aufteilung von Anfragen an gleichwertige Server, um eine möglichst gleichmäßige Lastverteilung und damit minimale Antwortzeiten zu erreichen. Error- und Exception-Handling Sollte eins der Systeme oder eine Übertragungseinrichtung ausfallen, so hat die EAI-Plattform die Aufgabe betroffene Systeme und Personen (z.b. den Administrator) zu informieren und wenn möglich, geeignete Gegenmaßnahmen zu ergreifen. Um solche Ausfälle selbständig erkennen zu können, müssen der Zustand und die Konsistenz des Gesamtsystems ständig ü- berwacht werden. 2.6 Produkte im EAI-Umfeld Bei EAI-Plattformen arbeiten oft verschiedene Einzellösungen Hand in Hand. Eine mit der Integration beauftragte IV-Abteilung oder Firma hat hier entweder die Möglichkeit, eine am Markt befindliche Komplettlösung von einem Hersteller einzusetzen und die existierende IV- Infrastruktur darauf anzupassen, oder sie verfolgt den so genannten best of breed Ansatz, bei dem mehrere Teillösungen von verschiedenen Herstellern, die auf das Unternehmen und auf die bestehende Situation am besten zugeschnittenen sind, ausgewählt und kombiniert werden. Der erste Ansatz hat den Vorteil, dass alle Komponenten aus einer Hand kommen und die Zusammenarbeit somit gewährleistet ist. Die Kosten für das Training der Mitarbeiter und für die Integration der Applikationen sind im Gegensatz zum zweiten Ansatz verhältnismäßig gering. Nachteilig dabei ist aber, dass Teilkomponenten, die spezielle Bedürfnisse eines Unternehmens nur eingeschränkt oder gar nicht befriedigen, in den wenigsten Fällen ausgetauscht werden können. Wurde erst einmal eine Plattform ausgewählt, ist man von ihr sowie von den angebotenen Leistungen und verwendeten Technologien abhängig. Ein späterer Wechsel auf eine andere Plattform ist mit einem unverhältnismäßig hohen Aufwand verbunden. Hinzu kommt, dass aufgrund ihrer hohen Spezialisierung eine Einzellösung eine Aufgabe oft besser erfüllen kann als die Teillösungen einer EAI-Plattform, welche möglichst viele Bereiche abdecken wollen. Produkte für das EAI-Umfeld kommen typischerweise aus den Bereichen Middleware, TP Monitore, Message Broker, Application Server, Web-Portal-Software und Geschäftsprozessmodellierung. Werden von einem Hersteller diese verschiedenen Teilprodukte als eine integrierte Komplettlösung angeboten, spricht man von einem EAI-Framework (beispielsweise angeboten von Herstellern wie IBM, TIBCO oder Vitria).

19 19 Abbildung 5: AIM Key Market Segments Forecast; in Millions USD 6 Eine an der Universität Magdeburg in Kooperation mit der T-Systems GmbH durchgeführte Studienarbeit [Winkler 2002] hat das Marktpotential für Lösungen im gesamten EAI-Umfeld näher beleuchtet. Grundlage für die Untersuchung waren Studien einer größeren Anzahl unterschiedlicher Marktforschungsunternehmen, wie beispielsweise der Gartner Group, der Seeburger AG oder Wintergreen Research. Ausgehend von den Ursachen für die Notwendigkeit der Integration, der Marktsituation für bestehende EAI-Lösungen und von Trends in diesem Bereich, wurden Marktanteile aktueller EAI-Anbieter und reale und potentielle Umsätze untersucht und dargestellt. Lizenzumsatz in Mrd. US$ 20 17, ,8 4,4 2,2 0,29 0,55 1, Abbildung 6: Lizenzumsatz im EAI-Markt bis Die Abbildung 5 und die Abbildung 6 zeigen Auszüge aus den Ergebnissen der Studie. Dargestellt werden der aktuelle und der zu erwartende Umsatz mit entsprechenden Produkten im EAI-Umfeld. 6 Quelle: Gartner Dataquest. [Gartner 2001] 7 Quelle: Wintergreen Research

20 20 3 Middlewaretechnologien für den EAI-Einsatz Aufgrund der heutzutage oft verwirrenden Begriffsvielfalt stellen wir zunächst die folgende Definition an den Anfang: Definition: Middleware ist eine Menge von spezialisierten (general purpose) Diensten, die zwischen der Systemplattform (Hardware + Betriebssystem) und den Anwendungen angesiedelt sind und deren Verteilung unterstützen. Der Einsatz moderner Middlewaretechnologien ist eine der wichtigsten Vorraussetzungen für die Integration von Applikationen in heterogenen Firmennetzwerken. Durch sie wird es einer Applikation ermöglicht, auf die Daten und Funktionalitäten einer anderen Applikation zuzugreifen und das unabhängig davon, ob sich die Applikation im eigenen oder in einem Partnerunternehmen befindet. Applications Application 1 Application 2 Middleware Application-Layer Presentation-Layer Session-Layer Application-Layer Presentation-Layer Session-Layer Data transport services Transport-Layer Network-Layer Data-Layer Physical-Layer Transport-Layer Network-Layer Data-Layer Physical-Layer Data transfer Abbildung 7: Einordnung der Middleware in das OSI-Schichtenmodell 8 Geht man vom OSI-Schichtenmodell 9 für Netzwerke aus, positioniert sich die Middleware in den obersten drei Schichten: Applikation, Präsentation und Sitzung (siehe Abbildung 7). Sie definiert dabei auf Grundlage des darunter liegenden Netzwerkes die Kommunikations- Mechanismen zwischen den einzelnen Applikationen. Zum Einsatz einer Middlewarelösung muss diese auf den zu integrierenden Systemen überhaupt zur Verfügung stehen, es muss die Fachlichkeit der entsprechenden Schnittstelle im Mittelpunkt der Spezifikation bzw. des Design stehen und sie sollte über ausreichende Mechanismen zur Transaktionssicherung verfügen bzw. Möglichkeiten zur Verschlüsselung und Authentifizierung anbieten. Ein weiterer sehr wichtiger Punkt beim Einsatz einer Middlewarelösung ist die Offenheit der angebotenen Schnittstellen, da es in vielen Fällen notwendig werden kann, verschiedene Technologien zu kombinieren. In vielen Firmen existieren noch so genannte sehr spezielle Legacy-Systeme, die teilweise ihre eigene Middlewaretechnologie verwenden. Wenn diese nicht ausgetauscht oder angepasst werden können, müssen Schnittstellen zwischen den ein- 8 aus [Searin 1999, Seite 5] 9 siehe beispielsweise [Tanenbaum 1997]