Anwendungsintegration durch Webservices

CLR - Common Language Runtime COM - Component Object Model CORBA - Common Object Request Broker Architecture CPA - Collaboration Protocol Agreement CPP - Collaboration Protocol Profile CRM - Customer Relationship Management DBMS - Database Management System DCOM - Distributed Component Object Model DIME - Direct Internet Message Encapsulation DLL - Dynamic Link Library DOS - Disk Operation System DSIG - Digital Signature DTD - Document Type Definition EAI - Enterprise Application Integration ebXML - E-Business extensible Markup Language ECMA - European Computer Manufacturers Association EJB - Enterprise Java Beans ERP - Enterprise Ressource Planning EDI - Electronic Data Interchange FTP - File Transfer Protocol GIOP - General Inter ORB Protocol HTML - Hypertext Markup Language HTTP - Hypertext Transfer Protocol

IEI - Inter Enterprise Integration IL - Intermediate Language IIOP - Internet Inter-ORB Protocol IT - Informationstechnologie J2EE - Java 2 Enterprise Edition JDBC - Java Database Connectivity JIT - Just in Time KMU - Kleine und mittlere Unternehmen MIME - Multipurpose Internet Mail Extensions MS - Microsoft MSH - Message Service Handler MTS - Microsoft Transaction Server NAICS - North American Industry Classification System OASIS - Organization for the Advancement of Structural Information Standards ODBC - Open Database Connectivity OLE - Object Linking and Embedding OMG - Object Management Group ORB - Object Request Broker RMI - Remote Method Invocation RPC - Remote Procedure Call SCM - Supply Chain Management SGML - Standard Generalized Markup Language SLA - Service Level Agreement SMTP - Simple Mail Transfer Protocol SOAP - Simple Object Access Protocol SSL - Secure Socket Layer SunONE - Sun Microsystems Open Net Environment SQL - Structured Query Language SW - Software SWA - SOAP with Attachments SWIFT - Society for Worldwide Interfinancial Transfer TCP / IP - Transfer Control Protocol / Internet Protocol UDDI - Universal Description, Disovery and Integration

UDP - User Datagram Protocol USML - UDDI Search Markup Language UN - United Nations UNSPSC - UN Universal Standards Products and Services Classification URL - Uniform Ressource Locator USML - UDDI Search Markup Language W3C - World Wide Web Consortium WS - Webservice (s) WSCL - Web Service Conversation Language WSCM - Web Service Component Model WSDL - Web Service Description Language WSEL - Web Service Endpoint Language WSFL - Web Service Flow Language WS-I - Web Services Interoperability Organization WSIA - Web Services for Interactive Applications WSIL - Web Service Inspection Language WSML - Web Service Markup Language WSRP - Web Services for Remote Portals WSUI - Web Service User Interface WSXL - Web Service Experience Language XLT - extensible Stylesheet Language Transformation XML - extensible Markup Language XSD - XML Schema Definition

1 Webservices - Mehrwert für Anwendungsintegration?

Wenn sich IT-Systeme heutzutage nicht schnell genug an neue Unternehmensstrategien oder Rahmenbedingungen anpassen können lähmen sie den Betrieb. Eine schnelle Reaktionsfähigkeit ist demnach unabdingbar - permanent entstehen neue Märkte, die Nachfrage ändert sich, neue Services entstehen. Es gilt, den Spagat zwischen möglichst hoher Flexibilität und Unterstützung des laufenden Geschäftsbetriebs zu bewältigen. Architekturen müssen dazu wandlungsfähig sein, heutige Systeme verfügen jedoch nur sehr begrenzt über die geforderte Beweglichkeit. Die zunehmende Vernetzung von Unternehmen verlangt eine Kooperation von IT-Systemen in ständig wechselnden Kombinationen. Dabei richtet sich das Interesse zunehmend auf die Integration mit Geschäftspartnern, problematisch daran ist aber, dass bis zu 80% unternehmensinterner Systeme bisher noch nicht online fähig sind und ein stark wachsendes Bedürfnis besteht, diesen Zustand zu ändern. ¹ Insbesondere der E-Business Bereich begünstigt solche Anliegen und mit dessen Hilfe eröffnen sich weltweit neue Perspektiven für Unternehmen aller Branchen und Größen. Leistungsfähigkeit und Geschwindigkeit der digitalen Datenübertragung machen es möglich, auf Anforderungen und Präferenzen der einzelnen Kunden und Partner schneller und wirksamer eingehen zu können als jemals zuvor, was von sinkenden Kosten für Hardware und Bandbreite unterstützt wird. Konsequenz ist, dass Geschäftsprozesse gegenwärtig nicht mehr an eigenen Unternehmensgrenzen enden, sondern darüber hinausgehen und eine Vielzahl an Geschäftspartnern miteinbinden. Für die Realisierung dieses Vorhabens sind mächtige Integrationswerkzeuge erforderlich, damit auf die sich kontinuierlich ändernden Anforderungen flexibel reagiert werden kann. Deren Effizienz und Effektivität ist, besonders beim unternehmensübergreifendem Austausch von Geschäftsinformationen, vom Standardisierungsgrad der verwendeten Verfahren abhängig. Auch wenn zwischenbetrieblicher Informationsaustausch seit langem technisch realisierbar ist, basiert dieser zumeist auf proprietären Verfahren und ist mit hohem Aufwand verbunden.

So genannte Webservices (WS) die im Mittelpunkt der diesjährigen Cebit standen, könnten ein adäquates Werkzeug sein, um diese Trends einfacher als bisher unter Nutzung ubiquitärer Standards umzusetzen. Die WS-Technologie verspricht eine

intelligentere Nutzung des Internets: Bislang sind dort vor allem Daten auf Webseiten verknüpft, WS sollen einen Schritt weitergehen und neben den Daten auch Programme vernetzen. ²

Einige Analysten vergleichen die Entwicklung von WS mit dem Übergang von maschinennaher Assembler Programmierung auf Programmiersprachen der 4. Generation oder mit dem Schritt von MS-DOS zu Windows. Weitere Argumente für den Einsatz von WS liefern die Auguren der Gartner Group: Sie gehen davon aus, dass WS im Jahr 2004 die dominante Softwarearchitektur verkörpern werden. ³ Diese Aussagen verdeutlichen die großen Hoffnungen und Erwartungen in die neue Technologie.

Ziel dieser Arbeit ist es, Antworten auf die Fragen „Inwieweit kann die noch junge WS-Technologie schon heute bei der Realisierung von Aufgaben im Bereich der unternehmensinternen und -übergreifenden Anwendungsintegration zum Einsatz kommen?“ und „Welchen Mehrwert bietet ein derartiger Einsatz gegenüber anderen Technologien?“ zu finden. Dazu bedarf es neben einer Ausarbeitung der Unterschiede zwischen WS und anderen heutigen Architekturen einer Beurteilung der Eignung von WS für unternehmenskritische Anwendungen, sowie einer technischen und betriebswirtschaftlichen Bewertung der Technologie. Zudem wird aufgezeigt, wie die weitere Entwicklung von WS sich auf Anwendungsintegration (AI) auswirken könnte.

Im ersten Teil der Arbeit wird sowohl die Entstehung und heutige Bedeutung der AI systematisch erarbeitet, als auch ein Überblick über die derzeit bedeutendsten Standards gegeben. In den folgenden Kapiteln wird dem Leser die Welt der WS näher gebracht. Hierzu dient der 3. Abschnitt als generelle Einführung in Funktionsweise und Anwendungsbereiche. Darauf aufbauend werden in Kapitel 4 die Grundlagen der Technologie erörtert. Ein Vergleich des WS-Frameworks mit der ebXML Initiative beendet das Kapitel. Im 5. Kapitel rundet eine vergleichende Betrachtung von Werkzeugen zur Erstellung von WS den technischen Teil der Arbeit ab. Der 6. Teil liefert eine detaillierte Analyse der Eignung von WS zur Integration unternehmensinterner und -externer Anwendungen. Das 7. und letzte Kapitel schließt die Arbeit mit einem kurzen Resümee ab.

2 Anwendungsintegration

Innerhalb dieses Kapitels soll der Begriff Anwendungsintegration erläutert werden. Dazu erfolgt, nach einigen definitorischen Vorbemerkungen, ein Überblick über die Ziele und historische Entwicklung der AI. Die darauf folgenden Abschnitte befassen sich mit der in Abb. 1 gezeigten Integrationsbreite und -tiefe sowie mit den Methoden der Integration. Das Kapitel endet mit einem Überblick über die wichtigsten technischen Hilfsmittel der Integration.

Abb. 1: Systematisierung der Integration Nach: Mertens / Informationsverarbeitung / 1997 / S. 2.

2.1 Begriffliche Abgrenzung

Eine einheitliche Definition von AI existiert derzeit noch nicht. Die Ovum Group definiert AI folgendermaßen:„Application Integration combines the technologies and processes that enable custom-build (...) applications to exchange (...) information in formats and contexts that each understands“. Die Butler Group bewertet AI als „requirement to integrate into new business processes the functional behavior or business rules of disparate systems or components of them as well as, but not just, the data that underlies them“. Dagegen hat AI für die Gartner Group die schlichte Bedeutung von „making independently designed systems work together“. ⁴ In dieser Arbeit soll der Begriff AI derart aufgefasst werden: AI strebt eine umfassende, zentralisierte Integration auf Daten-, Anwendungs- und Prozessebene durch Kombination der Funktionalität bestehender Applikationen an. Dies geschieht unter

Zuhilfenahme von Middleware (vgl. Kapitel 2.6). Aufgabe der AI ist demnach die Verbindung von verteilten Anwendungen. Diese bestehen aus mehreren Prozessen, die - zumindest teilweise - auf mehreren, vernetzten Rechnern laufen und miteinander interagieren. Dabei sollte sich die Anwendung so verhalten, als liefe sie auf einem Rechner und damit das Netzwerk vor dem Entwickler und Benutzer verbergen. Prinzipiell sind drei Szenarien denkbar, an denen AI ansetzen kann: (1) indem man eigene, bereits vorhandene Anwendungen zusammenführt, (2) die Verknüpfung von SW anderer Unternehmen mit der eigenen IT-Landschaft (Ex Ante Integration) und (3) die Entwicklung neuer SW mit dem Ziel, diese in vorhandene Applikationen einzubinden (Ex Post Integration). ⁵

Wegen teils divergenter Anforderungen und Ziele (vgl. Kapitel 2.2.1) erfolgt eine Unterteilung des Begriffs AI nach der Integrationsbreite in Enterprise Application Integration (EAI), die Verbindung von Software (SW) innerhalb eines Unternehmens und in Inter Enterprise Integration (IEI), die Zusammenführung von Applikationen mehrerer Unternehmen. Mertens versteht unter IEI „korrespondierende Programme so auszulegen, dass die Datenflüsse weitgehend automatisierbar sind, klassische Post sich erübrigt und letztlich die EDV Anlagen der Unternehmen miteinander arbeiten oder gar miteinander verhandeln“. ⁶ Gewichtige Probleme und damit erschwerende Faktoren bei IEI sind die abzustimmenden Differenzen zwischen einzelnen Unternehmensstrukturen, ein höherer Grad an Heterogenität und verschärfte Ansprüche an Sicherheitsmechanismen. ⁷

AI ist ein Vorhaben, das die intensive Verbindung von betriebswirtschaftlichem Wissen mit IT Know-How erforderlich macht: Der technische Aufwand bei der Integration von Anwendungen beträgt häufig nur 30% des gesamten Prozesses. Die restlichen 70% beziehen sich auf organisatorische Änderungen oder Absprachen, wie z. B. die Anpassung von Geschäftsabläufen oder damit verbundene Change Management Ansätze. ⁸ Diese Aspekte bleiben hier jedoch unbeachtet, da vornehmlich der technische Aspekt der Integration untersucht werden soll.

2.2 Entstehung und heutige Bedeutung

Anschließend an die Bestimmung der Ziele, die Unternehmen mit AI verfolgen, wird ein knapper Abriss der Geschichte der Integration wiedergegeben. Daran anknüpfend wird ausführlicher auf den Electronic Data Interchange (EDI) Standard eingegangen, der den ersten standardisierten unternehmensübergreifenden Datenaustausch ermöglichte und auch heute noch für viele Firmen die einzige Form der externen Integration darstellt. Ein weiterer Grund für die genauere Beschreibung von EDI ist, dass es eine geeignete Richtlinie für die Entwicklung neuer IEI Ansätze bietet. Ein Blick auf die derzeitige Situation der AI beendet den Abschnitt.

2.2.1 Integrationsziele

Das wohl vorrangigste Ziel der AI ist die Schaffung durchgängiger IT-Unterstützung von Geschäftsabläufen, welche sich an Prozessen und nicht an Abteilungsgrenzen orientieren. Die Integration sollte dabei schnell und einfach umzusetzen sein. ⁹ Ein solches Vorgehen erlaubt automatisierte Prozessketten, die zu einer schnelleren Verarbeitung führen, da nichts mehr ‚vergessen’ werden kann. Es wird geschätzt, dass 70 - 95% aller Daten, die in ein System neu einzugeben sind, mehrfach erfasst werden, obwohl sie bereits an einem anderen Ort vorhanden sind. Aus diesem Grund ist die Zusammenführung von Einzelsystemen zu befürworten, woraus eine Verringerung des manuellen Eingabeaufwands resultiert, denn Programme können sich aus dem Datenpool anderer Anwendungen bedienen. ¹⁰ Die Folge ist eine Erhöhung der Datenqualität, da Fehler durch Mehrfachnutzung der Daten schneller erkannt werden. Ein derartiges Vorgehen führt demnach auch zur Verminderung von Redundanz, wodurch Inkonsistenzen, mehrfache Prüfungen und Korrekturen von Daten vermindert und gleichzeitig die Wirtschaftlichkeit erhöht werden kann. Damit wird die Schaffung einer einheitlichen, integrierten Sicht auf Daten aus unterschiedlichen Systemen angestrebt. Jedoch können im Störfall redundante Komponenten als Fallback dienen, auch kann eine parallele Nutzung mehrerer Systeme zu verbesserter Performance führen. Demzufolge sollte Redundanz nicht völlig beseitigt werden, stattdessen ist eine Bestimmung des optimalen Grades an Redundanz nötig. ¹¹

Durch die Integration von Altanwendungen (Legacy Applications) mit anderen Programmen kann deren Lebensdauer erhöht werden. Besonders unter dem Aspekt des Investitionsschutzes - man denke nur an die hohen Kosten, die entstanden sind um Altsysteme Jahr 2000 fähig zu machen - ist dies ein bedeutendes Ziel. Legacy Anwendungen sind oft das Rückgrat der IT einer Organisation, ihre Integration also unabdingbar, obwohl die Realisierung vielmals problematisch ist, da Altanwendungen selten dokumentiert und meist hochkomplex sind. Erschwerend kommt hinzu, dass solche Anwendungen meist proprietäre Datenformate benutzen und keine Mechanismen für den Import und Export von Daten zur Verfügung stellen. ¹² AI führt zudem zu einer Verlängerung der Lebensdauer von SW, Aufwendungen für Neuentwicklungen können entfallen und folglich sind Kosteneinsparungen erreichbar.

Weitere Ergebnisse eines konsequenten Einsatzes von AI sind erhebliche Potenziale zur Erreichung von Qualitäts- und Wettbewerbsvorteilen. ¹³ Auch wird die Realisierung von modernen betriebswirtschaftlichen Konzeptionen, wie z. B. der elektronischen Kostenplanung erst durch integrierte Anwendungslandschaften möglich. ¹⁴ Aber AI ist nicht frei von Problemen und Nachteilen, die zu steigenden Anforderungen an die IT-Administration führen: Hohe Investitionskosten und die lange Realisierungszeit von AI Projekten bedingen vielfach, dass die Integration nicht vollständig umgesetzt wird; fehlerhafte Eingaben können bei mehrfach verwendeten Daten weitreichende Konsequenzen nach sich ziehen; Programmänderungen und damit verbundene Tests werden mit zunehmendem Integrationsgrad immer komplexer. Auch ist der Datenaustausch zwischen Anwendungen häufig mit einem Informationsverlust, bedingt durch inkompatible Datenmodelle, Typen oder Schnittstellen verbunden. ¹⁵ Durch die oben stehenden Merkmale besteht die Notwendigkeit, zukünftige Erwartungen besser zu antizipieren, da ansonsten tiefgreifende Eingriffe in die IT-Architektur einer Unternehmung angebracht sein könnten. ¹⁶ Als spezielle Triebkräfte und Anforderungen von IEI können zusätzlich folgende Trends identifiziert werden: Für unternehmensübergreifenden Datenaustausch werden integrierte Prozesse benötigt, demnach ist die erfolgreiche Durchführung von EAI häufig Voraussetzung für den Einsatz von IEI. Durch globale Zusammenarbeit wird

eine hohe Verfügbarkeit der Systeme - möglichst 24 Stunden am Tag - erforderlich. Wichtigstes Ziel von IEI ist die Ermöglichung von Realtime Datenaustausch durch den gerade im Bereich Supply Chain Management (SCM) Geschwindigkeitsvorteile und höhere Flexibilität zum Tragen kommen. 17

2.2.2 Historische Entwicklung

Der Beginn der automatisierten Datenverarbeitung in den 60er Jahren war gekennzeichnet von der Automatisierung einzelner Aufgaben. Diese Lösungen werden als Insellösungen bezeichnet. Anwendungen liefen auf Großrechnern, die als zentrale Plattform dienten, also in einem homogenen und damit leicht zu integrierendem Umfeld. ¹⁸ Die vorherrschende Technik der Integration stellten eigenentwickelte Punkt-zu-Punkt Verbindungen zwischen einzelnen Anwendungen dar, die sich vorwiegend auf den reinen Datenaustausch beschränkten.

Vor allem die Anforderungen nach höherer Performance und Skalierbarkeit förderten die Entwicklung verteilter Systeme nach dem Client/Server Modell. Die Verfügbarkeit mehrerer Betriebssysteme und unterschiedlichster SW führten im weiteren Zeitablauf zu einer oft unkoordinierten Entwicklung ohne Blick auf die Zukunft, wodurch eine Vielzahl von miteinander nicht kompatiblen Anwendungen entstand. ¹⁹ Enterprise Ressource Planning (ERP) Systeme sollten Abhilfe schaffen, indem ein einziges SW-Paket alle relevanten IT-Systeme zu einem einzigen vereinigt. Die vorgefertigten Module die ein ERP System bietet, decken allerdings nicht alle Geschäftsprozesse ab oder unterstützen Prozesse, die ein Alleinstellungsmerkmal des Unternehmens beinhalten, nur unzulänglich. Studien von PriceWaterhouseCoopers kamen zu dem Ergebnis, dass ERP Systeme nur bis zu 40% der benötigten betrieblichen Funktionen bieten. ²⁰ Daher herrschen in heutigen Unternehmen Architekturen vor, in denen eine Vielzahl von Standardlösungen wie Customer Relationship Management (CRM), SCM, E-Procurement und ERP Systeme neben Legacy Applikationen und Eigenentwicklungen zum Einsatz kommen. Das Resultat ist eine zunehmend heterogene IT-Landschaft mit Systemen, die nie gemeinsam entworfen und für eine reibungslose Zusammenarbeit entwickelt wurden. Um das gegenseitige Miteinander von SW umzusetzen wurde sog Middleware entwickelt (Vgl.: Kapitel 2.6.), die Mechanismen

zur Verfügung stellt, um AI zu vereinfachen und eine Abkehr von Punkt-zu-Punkt hin zu Many-to-Many Beziehungen ermöglicht. Im Vordergrund steht dabei nicht mehr die reine Datenintegration, vielmehr wird versucht ganze Geschäftsprozesse zu integrieren. ²¹

SW ist mittlerweile zu einem komplexen Produkt geworden, das Anforderungen aus verschiedensten Bereichen genügen muss, daher wird fortlaufend nach leistungsfähigen Konzepten zur Vereinfachung gesucht. ²² Früh wurde erkannt, dass SW Entwicklung einfacher ist, wenn man Programme in einzelne Bausteine zerlegt, einzeln testen und entwickeln kann. Erst durch eine derartige Aufteilung wird Wiederverwendung von SW-Bausteinen realisierbar. Neben den o. g. Aspekten sind daher noch zwei weitere Merkmale zu nennen, die solche Entwicklungen möglich machen und AI beeinflussen: Zum einen das Paradigma der Objektorientierung und zum anderen der Komponentenansatz. Die Objektorientierung bezeichnet die Zerlegung von SW in Objekte und beruht im Wesentlichen auf drei Säulen: Die Kapselung, bezeichnet das ‚verstecken’ von Daten und Code hinter einer Schnittstelle. ²³ Die Polymorphie besagt, dass derselbe Funktionsaufruf unterschiedliche Effekte haben kann (z. B. hat configure_yourself() bei einem Druckerobjekt anderes Verhalten zur Folge als bei einem Datenbankobjekt). ²⁴ Letztlich kann durch die Vererbung aus einem Objekt ein neues Objekt erstellt werden, welches Merkmale des alten Objekts beinhaltet. Die Objektorientierung geht von abgeschlossen Systemanforderungen aus, die keiner Dynamik unterliegen, zudem sind Schnittstellen oft eng mit der zugrunde liegenden Systemtechnik verknüpft, womit der geringe Erfolg der Wiederverwendbarkeit erklärt werden kann. ²⁵

Das auf der Objektorientierung aufbauende Komponentenparadigma verspricht eine schnelle und hochwertige Komposition von Anwendungen aus vorgefertigten und konfigurierbaren Bausteinen (Plug & Play Funktionalität) und wird damit der Forderung nach Interoperabilität und Wiederverwendung weitaus mehr gerecht als es bei der Objektorientierung der Fall ist. ²⁶ Auch bei Komponenten ist die Kapselung ein zentraler Punkt, allerdings spielt hier die Granularität eine entscheidende Rolle: Objekte

können von beliebiger Granularität sein und sich aus mehreren Objekten zusammensetzen, was zu komplexen Netzwerken von abhängigen Objekten führt. Komponenten hingegen sind Bausteine zur Lösung bestimmter Aufgaben, ihre Granularität ist daher nicht beliebig wählbar, u. a. weil eine zu fein gewählte Granularität zu einem erhöhten Kommunikationsbedarf zwischen Komponenten führt und ein absinken der Leistung mit sich bringt. Auch bestehen bei Komponenten keine Abhängigkeiten, man spricht hier eher von gegenseitiger Nutzung. Dies ermöglicht einzelne Komponenten zu ersetzen, ohne dass andere davon betroffen sind (man spricht hierbei von loser Kopplung, welche den Grad der Abhängigkeit von Komponenten untereinander beschreibt). 27

2.2.3 Die Rolle von Electronic Data Interchange

EDI bezeichnet den zumeist unternehmensübergreifenden Austausch von Geschäftsdaten in einer standardisierten und maschinenlesbaren Form. Durch EDI wurde das erste Mal die elektronische Kommunikation ohne Medienbrüche über Unternehmensgrenzen hinweg realisiert. Haupteinsatzbereiche von EDI sind der Austausch kommerzieller Geschäftsinformationen und der elektronische Transfer von Kapital und technischen Informationen. ²⁸ Mit ANSI X12 (1983) und EDIFACT (1987) wurden erstmals von Hard- und SW unabhängige syntaktische und semantische ²⁹ Standards geschaffen, die Kommunikation zwischen Unternehmen erst ermöglichten - eine Novität in der damaligen IT-Welt. ³⁰ Parallel zu den beiden Standards existieren noch eine Vielzahl von nationalen und branchenspezifischen Subsets (ca. 200 allein von EDIFACT, wie bspw. SWIFT), die den Datenaustausch für Unternehmen erschweren, da sie untereinander nicht kompatibel sind. ³¹ Welche Nutzeffekte die Einführung von EDI hatte, wird durch Studien des amerikanischen Verteidigungsministeriums offensichtlich, die zu dem Ergebnis kamen, dass die Fehlerquote beim elektronischen Datenaustausch 1:3 Mio. beträgt, bei manuellen Verfahren liegt diese bei 1: 300. Rationalisierungspotenziale mit Hilfe von EDI ergeben sich durch die Senkung des Transaktionsaufwands um bis zu 70%, die

Reduzierung von Durchlaufzeiten um 50% und der Kapitalbindung um 30%. ³² Weitere Vorteile sind höhere Qualität und Vollständigkeit der Daten. ³³ Die Funktionsweise von EDI verdeutlicht die folgende Abbildung. Eine beispielhafte EDI Rechnung zeigt Abb. 26 im Anhang B.

Der Einsatz von EDI stellt jedoch hohe Ansprüche: Erhebliche Investitionen für spezifische Hard- und SW und ein hoher Administrationsaufwand sind zum Einsatz von EDI unumgänglich. ³⁴ Allein für die Übermittlung von 125.000 EDI Nachrichten

Abb. 2: EDI Übertragung

können Kosten von bis zu 100.000 US-$

Nach: Zbornik / Netzwerke / 1996 / S. 82. anfallen. ³⁵ Diese Aufwendungen könnten ein Grund dafür sein, weshalb EDI in vielen Unternehmen oft nur durch äußeren Druck eingeführt wurde. ³⁶ Trotz der hohen Kosten ergaben Analysen die Möglichkeit einer sinnvollen Nutzung von EDI bereits ab zehn Vorgängen pro Monat. ³⁷ Die Verwendung von EDI lässt sich, wie Abb. 3 zeigt, in fünf Integrationsstufen mit steigenden Nutzeffekten einteilen. Ungeachtet der Vorteile betreiben bisher

erst 5% aller Unternehmen EDI. Daher besteht noch ein großer Aufholbedarf und ein ebenso großes Rationalisierungspotenzial, das nicht unerschlossen bleiben sollte. Neue Einsatzmöglichkeiten und einen höheren

Abb. 3: Integrationsstufen von EDI Seffinga / EDI-Stand und Potentiale / 1996 / S. 10. Durchdringungsgrad versprechen, gerade

für kleine und mittlere Unternehmen (KMU), WebEDI und Internet EDI. Unter ersterem ist die Eingabe von EDI Daten über ein Web-Frontend zu verstehen, wodurch einseitig die Kosten für eine eigene EDI Lösung entfallen. ³⁸

Ein wichtiger Nutzenfaktor von EDI, die Vermeidung von Medienbrüchen, wird hierbei jedoch aufgegeben. ³⁹ Internet EDI bezeichnet die Nutzung von EDI unter Zuhilfenahme des Internets als Transportweg, was erhebliche Kostenvorteile verspricht. Technologien wie XML/EDI versprechen eine Ausweitung von EDI, die über eine reine Nutzung des Netzes als Transportweg hinausgeht, wobei vollständige Interoperabilität zum herkömmlichen EDI gewährleistet wird. ⁴⁰ In einem Repository werden Bedeutung und Definitionen von EDI Elementen gespeichert und mittels Templates lassen sich EDI Standards auf XML ⁴¹ Dokumente übertragen. Die Vorzüge von XML/EDI lassen sich in fünf Thesen zusammenfassen: Es erfolgt (1) eine Öffnung der Netze, (2) die Weiterverarbeitung von Daten wird durch XML vereinfacht, (3) führt zu höherer Flexibilität, (4) erleichtert die Konvertierung und führt (5) zu einer Senkung von Kommunikationskosten. 42

2.2.4 Anwendungsintegration heute

Eine Studie der Metagroup ergab, dass erst 15% der deutschen Unternehmen (n = 1018) sich mit EAI beschäftigen. Im Gegensatz dazu ist

die Durchdringung in den USA weitaus höher. Das könnte durch den mit 70% äußerst hohen Marktanteil von SAP und den noch sehr

zersplitterten EAI Markt begründet sein. Da SAP ein hoch integriertes Produkt darstellt sehen viele Unternehmen keinen Bedarf für AI. ⁴³ Wie bereits Kapitel 2.2.2 gezeigt hat, decken ERP Systeme Abb. 4: AI Markt Deutschland 2000 Metagroup / E-Business und EAI /

nicht alle benötigten Funktionalitäten ab: Noch

2001/ S. 3.

heute sind vorwiegend in Großunternehmen bis zu 50% der Programme auf Mainframes und anderen geschlossenen Systemen im Einsatz. ⁴⁴ Zu deren Integration ist AI durchaus zu befürworten. Es ist jedoch anzunehmen, dass ERP Systeme zentraler Baustein von IT-Architekturen bleiben werden. Hauptantriebskräfte der Integration sind bei deutschen Unternehmen vor allem die Realisierung integrierter ERP Lösungen und die

Anbindungen von CRM Suiten an vorhandene Back-End SW. Die Integration von E-Business und SCM Anwendungen, also vorwiegend IEI, wird bisher als weniger bedeutend empfunden. ⁴⁵

Gegenwärtig sind große betriebliche Informationssysteme gekennzeichnet durch hohe Datenmengen, starke Belastung der Clients, stark ausgeprägte Anforderungen an Zuverlässigkeit und Sicherheit, sowie zumindest teilweise sehr komplexe fachliche Logik. Außerdem weisen sie oft eine lange Lebensdauer auf. ⁴⁶ Heutige Integrationssoftware muss mit o. g. Punkten umgehen können, Unabhängigkeit von Plattformen und Programmiersprachen bieten und zukunftsorientiert sein. ⁴⁷ Zudem sollte die Anzahl an Schnittstellen zur Integration bestehender Systeme minimiert werden und eine Orientierung an Unternehmensprozessen statt an Systemen und Applikationen erreicht werden. ⁴⁸

Durchschnittlich haben sich Ausgaben für eine AI Lösung nach 6 Jahren amortisiert. Wie hoch die Bedeutung der heutigen AI ist zeigen folgende Aussagen: Ausgaben für Integrationssoftware belaufen sich durchschnittlich auf 35% der IT-Budgets. Vergleicht man den Anteil von SW-Neuentwicklungen und Integrationsmaßnahmen ist festzustellen, dass mittlerweile die Integration bestehender Anwendungen einen höheren Stellenwert einnimmt als die Entwicklung neuer SW. 49

2.3 Kommunikationsmodell: Synchron versus Asynchron

Die Verständigung zwischen SW kann auf zwei Arten erfolgen: Synchron oder asynchron. Das Vorliegen synchroner Kommunikation besagt, dass bei der Kommunikation von zwei Anwendungen die sendende Anwendung nach dem verschicken von Daten auf die Antwort des Empfängers warten muss. Das Programm ist demnach bis zur Beendigung des Austauschprozesses blockiert. Bei auftretenden Problemen, wie z. B. Netzwerk- oder Serverausfällen führt dies zu Verzögerungen und schlimmstenfalls zum Absturz der wartenden SW.

Vorteilhaft an der anderen Alternative, der zeitversetzten (asynchronen) Kommunikation ist es, dass zwischen der sendenden und empfangenden Anwendung keine dauerhafte Verbindung herrschen muss. Somit können beide Programme in ihrem Programmablauf

fortfahren und blockieren sich nicht gegenseitig. Die Verarbeitung der empfangenen Daten erfolgt dabei zu einem beliebigen Zeitpunkt, z. B. erst dann, wenn sich die Anwendung im Leerlauf befindet. ⁵⁰

Die Nachteile der synchronen Kommunikation sind gleichzeitig die Vorteile der asynchronen Kommunikation. Daraus ergibt sich eine bessere Eignung der asynchronen Verständigung für AI.

2.4 Integrationsansätze

Bei jeder Art von Integration ist zunächst das Ausmaß der Veränderung zu erfassen. Dies kann durch Integrationsbreite (EAI oder IEI) und -tiefe systematisiert werden. Die Integrationstiefe beschreibt die Ebene auf der Integration stattfindet. ⁵¹ Eine mögliche Einteilung kann in Präsentation-, Daten- und Funktionsintegration erfolgen.

2.4.1 Präsentationsintegration

Die Präsentationsintegration stellt die einfachste Möglichkeit der Integration dar. Typischerweise wird ein Front-End (z. B. eine Terminalanwendung) durch ein neues User Interface (bspw. eine Web-Oberfläche) ersetzt. Dabei ist es auch möglich, mehrere Altanwendungen mittels einer neuen Oberfläche zu einer scheinbar integrierten Anwendung zusammenzuführen. Vorteilhaft hierbei ist die einfache und schnelle Durchführbarkeit der Integration, da bei diesem Typ meist gute Dokumentationen vorliegen oder die Oberfläche selbsterklärend ist. Zudem gibt es eine Vielzahl an Werkzeugen, die einen Großteil der Arbeit übernehmen (sog. Screen scraping Tools). Nachteilig ist, dass Integration nur auf der Präsentationsebene erfolgt, Daten und Geschäftslogik (die Umsetzung von realen Geschäftsprozessen in Programmcode) werden nicht zusammengeführt, zusätzlich kann es durch die Einführung einer neuen SW-Schicht zu Performanceverschlechterungen kommen. ⁵²

2.4.2 Integration von Daten

Die Integration von Daten beschreibt die gemeinsame Nutzung und logische Zusammenführung von Daten. Dieser Ansatz wurde erstmals mit der Einführung von Datenbankmanagementsystemen (DBMS) in den siebziger Jahren ermöglicht. ⁵³ Mit Hilfe der Integration von Daten können Mehrfacheingaben und Inkonsistenzen, verursacht durch Redundanzen, vermieden werden. ⁵⁴ In der einfachsten Form, der Datenintegration, werden Daten automatisch an andere Systeme übergeben (bspw. per Filetransfer oder Batch-Jobs). Ein einfacher Ansatz zur Datenintegration ist die Replikation. Dieser Begriff bezeichnet die Bereitstellung gleicher Daten an mehreren Standorten. Das kann asynchron, also zu festen Zeitpunkten oder synchron, d. h. gleichzeitig mit der Änderung im Original vorgenommen werden. Dadurch wird eine Optimierung der Datenverfügbarkeit, höhere Zuverlässigkeit und Performance des Gesamtsystems, sowie eine Begrenzung der Netzwerklast angestrebt. Problematisch bei der Replikation ist, dass in der Geschäftslogik, aber nicht in der Datenbank hinterlegte semantische Strukturen bei dieser Form von AI nicht mit abgebildet werden und es folglich zu Inkonsistenzen kommen kann. ⁵⁵ In einer weiteren Entwicklungsstufe, der Datenstrukturinformation, werden Daten in gemeinsamen Datenbanken gehalten, wobei hier i. d. R. eine virtuelle Datenbank vorliegt. ⁵⁶

Allerdings ist die Datenintegration kein einfaches Unterfangen, denn in großen Unternehmen sind oft mehrere hundert Datenbanken und tausende von Tabellen zu verknüpfen, die z. T. proprietäre Formate aufweisen und exotische Schnittstellen anbieten. Auch sind spätere Änderungen oft nur schwer durchzuführen bzw. kritisch zu bewerten, da bei der Datenintegration eine enge Kopplung der DBMS vorgenommen wird. 57

2.4.3 Funktionsbasierte Integration

Ein Großteil der IT-Budgets wird für die Entwicklung von Geschäftslogik aufgewendet. Deren Integration stellt den flexibelsten und zugleich aufwendigsten der hier vorgestellten Ansätze dar. Zur Realisierung dieses Typus existieren drei verschiedene Ansätze. Erstens Data Consistency Integration, dabei liegt der Schwerpunkt auf der

Veränderung von Daten durch Anwendungscode (z. B. legt die Funktion NewCustomer () einen neuen Kunden in einem DBMS an). Zweitens die Multistep Process Integration (analog auch Straight-through processing), die Prozesse innerhalb eines Workflows über mehrere Anwendungen hinweg automatisiert. Man spricht in diesem Fall auch von vertikaler Integration. 58

Abb. 5: Multistep Process Integration In Anlehnung an: Ruh / EAI / 2001 / S. 32. Der letzte Ansatz, die Plug and Play Integration (synonym Integration von Komponenten) stellt den schwierigsten und komplexesten, aber auch flexibelsten Ansatz dar. SW wird hierbei mit einfach zu verstehenden Interfaces versehen, über die der flexible Austausch von Daten durchführbar ist, ohne immer wieder Änderungen an den Applikationen selbst vornehmen zu müssen. ⁵⁹ Im Idealfall lassen sich bestehende Programme einfach als Komponenten in die Architektur einfügen, vielmals fehlen aber geeignete Schnittstellen, so dass eine Anpassung der Systeme erforderlich ist, die die Schnittstellen bereitstellt (Wrapping). ⁶⁰ Kritisch zu bewerten ist die hohe Zeitintensität dieses Typs: Bei manchen Anwendungen kann dieses Vorgehen sogar eine vollständige Neuprogrammierung zur Folge haben. ⁶¹

Ein Vergleich der drei vorgestellten Ansätze bietet die folgende Tabelle.

Tabelle 1: Vergleich von Ansätzen zur funktionalen Integration Quelle: Ruh / EAI / 2001 / S. 35.

2.5 Integrationstopologien

Als letztes Systematisierungskriterium soll die Integrationstopologie (Anordnung und Anzahl der Schnittstellen) untersucht werden. Es wird im Wesentlichen zwischen drei Alternativen unterschieden.

2.5.1 Point-to-Point

Die Point-to-Point Architektur entspricht weitgehend dem ursprünglichen Ansatz der AI, nämlich dem Einsatz individueller Schnittstellen zwischen jeweils zwei Anwendungssystemen. Die Verbindung von Anwendungen erfolgt über Konnektoren, die sowohl erworben als auch selbst entwickelt werden können und bei deren Verwendung die Schnittstelle des betroffenen Systems nicht angepasst werden muss. Ist der Einsatz von Konnektoren nicht möglich, ist die Schaffung einer entsprechenden Schnittstelle erforderlich. 62 Positiv an dieser Topologie ist der i. d. R. hohe Datendurchsatz und die damit einhergehende hohe Performance zu bewerten. Anwendung findet diese Architektur vor allem bei einer geringen Schnittstellenanzahl, weil dann die Vorteile vollständig zum Tragen kommen und die Kosten weit unter denen für andere Systematiken bleiben. ⁶³ Jedoch wachsen mit zunehmender Anzahl an Systemen (n) die Schnittstellen exponentiell (Die Anzahl der möglichen Schnittstellen ergibt sich aus den Ausdruck (n * [n-1]) bzw. n * [(n-1)/2] unter der Bedingung, dass die Schnittstelle in beide Richtungen arbeitet), es entsteht das sog. Schnittstellenspaghetti. 64

Abb. 6: Point-to-point Schnittstellenspaghetti Demnach ist die Point-to-Point Topologie für komplexe Integrationsaufgaben ungeeignet. Eine solche Architektur ist oftmals das Ergebnis von im Zeitablauf

gewachsenen Strukturen, d. h. es erfolgt keine Reorganisation der vorhandenen Systeme. Nachteile dieses Ansatzes sind ein hoher Pflegeaufwand für Schnittstellen, eine suboptimale Nutzung der Ressourcen, ein hoher Aufwand bei der Integration neuer Anwendungen und häufig inhomogene und inkonsistente Daten. 65

2.5.2 Hub-and-Spoke

Hub-and-Spoke ist eine Weiterentwicklung der o. g. Topologie und basiert auf einem zentralen Broker, der den Datenverkehr steuert und überwacht. Entsprechend bestimmter Regeln ⁶⁶ nach denen der Broker handelt, können Nachrichten an verschiedene Anwendungen übermittelt werden. Dadurch sind komplexe Datenverteilungsszenarien denkbar. ⁶⁷ Die

nebenstehende Abbildung zeigt, wie Anwendungen gleichberechtigt auf eine zentrale Informationsdrehscheibe, die als Hub bezeichnet wird, zugreifen. Die wichtigsten Vorteile dieser Architektur sind eine minimale Schnittstellenanzahl (n Schnittstellen), sowie eine zentrale Verwaltung und Abbildung von Prozessen. Abb. 7: Hub-and-Spoke Architektur Als Nachteile können mögliche Performance- und Verfügbarkeitsengpässe durch hohe Belastung des Hubs ausgemacht werden.

2.5.3 Bus / Pipeline

Dieser Typus ist vor allem für 1:n oder n:1 Szenarien interessant und arbeitet nach dem

Publish & Subscribe Prinzip. Informationen einer Anwendung werden auf den Bus geschickt (Publish), andere Anwendungen wissen, ob sie die Daten benötigen und nehmen sie ggf. auf (Subscribe). Die Aufgabe des EAI Tools besteht in der Überwachung

des Datenverkehrs auf dem Bus. Im Gegensatz

zu der Hub & Spoke Architektur entfällt bei dieser Topologie die eventuelle Performanceschmälerung durch den Hub, was eine höhere Zahl von Sender- und Empfängersystemen ermöglicht. 68

2.6 Ausgewählte Middleware als Beispiel für Integrationsplattformen

Die Integration von Applikationen unter derselben Systemsoftware stellt hohe Erwartungen an die Entwickler. Sobald zusätzlich heterogene Betriebssysteme ins Spiel kommen, nimmt die Komplexität nochmals zu. Als Hilfsmittel zur Verringerung der Komplexität kommt Middleware ins Spiel, die als ‚Enabler der Integration’ bezeichnet werden kann. ⁶⁹ Middleware ist anwendungsunabhängige SW, deren primäres Ziel der Abbau von technischen und konzeptuellen Inkompatibilitäten ist. ⁷⁰ Der Begriff kann weiterhin definiert werden als „Softwareschicht, die Dienstleistungen für die Integration in einer heterogenen Umgebung erbringt“. ⁷¹ Middleware stellt Mechanismen zur Kommunikation von Prozessen über Netzwerke und zur Überwindung von Barrieren zwischen Systemen als auch zur Behandlung von Fehlern und Ausfällen dieser Systeme bereit. Eine entscheidende Aufgabe von Middleware ist die Gewährleistung von Transparenz, d. h. die Komplexität des verteilten Systems wird gegenüber Entwicklern und Anwendern verborgen. Zusätzlich stellt Middleware betriebssystemnahe Funktionen wie Sicherheits- und Transaktionsdienste zur Verfügung. Daneben sollte eine leistungsfähige Middleware Plattform (1) synchrone und asynchrone Kommunikation unterstützen, (2) Tools zum Transformieren von Daten beinhalten und (3) Mechanismen (Adapter) zur Verfügung stellen, mittels der andere Anwendungen integriert werden können. ⁷²

Trotz der Integrationsvereinfachung durch Middleware sind weitreichende Kenntnisse der Objekttechnologie und der Entwicklung verteilter Systeme unabdingbar, um Anwendungen erfolgreich zusammenzuführen. ⁷³

Im Folgenden wird nach einer kurzen Klassifizierung von Middleware eine rudimentäre Einführung in einige bedeutende Ansätze von Middleware gegeben.

2.6.1 Grundlegende Differenzierungskriterien

Obwohl nachrichtenbasierte Kommunikation (Messaging) die älteste Middleware Idee darstellt, gibt es noch keinen Standard für dieses Konzept. ⁷⁴ Prozesse kommunizieren hierbei über den Austausch von Nachrichten. Daher reichen für die einfachste Art der Verständigung zwei Befehle aus: Send und Receive. ⁷⁵ Messaging kann synchron oder asynchron mit Hilfe von Message Queues erfolgen. Letztere ergänzen das Konzept des Messaging durch Queue Manager, die Speicherung und Weiterleitung von Messages übernehmen. ⁷⁶

Remote Procedure Calls (RPC) wurden Mitte der 80er Jahre entwickelt und sind Mechanismen die, wenn sie aufgerufen werden, eine Funktion auf einem entfernten System ausführen und das Resultat an den aufrufenden Rechner zurückgeben. ⁷⁷ Der RPC, der stets synchron abläuft, ist Grundlage vieler anderer Technologien, unter anderem dem Distributed Component Object Model (DCOM) und der Common Object Request Broker Architecture (CORBA). Grundlegende Idee solcher Middleware ist, bei der Kommunikation von verteilten Prozessen dieselben Techniken wie bei lokalen zu verwenden. ⁷⁸ Problematisch bei RPCs ist die Ausführungsgeschwindigkeit: Ein einzelner Call benötigt zur Ausführung 10.000 - 15.000 Instruktionen. Diesem Aufwand stehen positiv die Einfachheit des Mechanismus und die anspruchslose Programmierung der Aufrufe gegenüber. ⁷⁹

Database Access Middleware bietet Mechanismen zum Zugriff auf Datenbanken. Weiterhin werden Funktionalitäten wie Data Sharing, Data Synchronization und Data Warehousing unterstützt. Beispielhaft sei für diesen Typ ODBC oder JDBC (Open bzw. Java Database Connectivity), als Middleware zum Datenzugriff erwähnt. Transaction Processing Monitors sind ein Middleware Typus, der die Integrität von komplexen Transaktionen sichert und die dazu nötigen Features wie Rollback, Fehlerbehandlung, Replikation und vieles mehr zur Verfügung stellt. ⁸⁰ Als letztes ist die Distributed Object Technology zu nennen. Hierbei unterliegen „Schnittstellen und Implementierungen einem objektorientierten Modell, das zur