Anwendungsintegration durch Webservices

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Listings

1 Webservices - Mehrwert für Anwendungsintegration?

2 Anwendungsintegration
2.1 Begriffliche Abgrenzung
2.2 Entstehung und heutige Bedeutung
2.2.1 Integrationsziele
2.2.2 Historische Entwicklung
2.2.3 Die Rolle von Electronic Data Interchange
2.2.4 Anwendungsintegration heute
2.3 Kommunikationsmodell: Synchron versus Asynchron
2.4 Integrationsansätze
2.4.1 Präsentationsintegration
2.4.2 Integration von Daten
2.4.3 Funktionsbasierte Integration
2.5 Integrationstopologien
2.5.1 Point-to-Point
2.5.2 Hub-and-Spoke
2.5.3 Bus / Pipeline
2.6 Ausgewählte Middleware als Beispiel für Integrationsplattformen
2.6.1 Grundlegende Differenzierungskriterien
2.6.2 CORBA - Die Common Object Request Broker Architecture
2.6.3 Enterprise Java Beans
2.6.4 Das (Distributed) Component Object Model

3 Webservices - Eine Einführung
3.1 Grundlegende Funktionsweise
3.2 Einsatzmöglichkeiten

4 Die Webservices-Technologie
4.1 XML - normierte Auszeichnungssprache als technologische Grundlage
4.2 Discovery - Das Auffinden von Webservices
4.2.1 UDDI - Grüne Seiten für Webservices
4.2.2 WSIL
4.3 Description - Selbstbeschreibende Dienste
4.3.1 WSDL
4.3.2 Ergänzende Beschreibungsansätze
4.3.2.1 User Interfaces
4.3.2.2 Weitere Beschreibungssprachen
4.4 Packaging - Die Übertragungsprotokolle
4.4.1 SOAP
4.4.2 Ergänzungen des SOAP Protokolls
4.5 Transport - Wege zur Verteilung
4.5.1 HTTP
4.5.2 Alternative Transportwege
4.6 ebXML - Konkurrierendes Framework oder Ergänzung?
5 Werkzeuge zur Entwicklung von Webservices

5.1 Java 2 Enterprise Edition
5.1.1 Die J2EE Architektur
5.1.2 Die Entwicklung von Webservices mit J2EE
5.2 Microsoft .NET
5.2.1 Die Vision hinter .NET
5.2.2 .NET Framework und Services
5.2.3 .NET Server
5.3 Vergleichende Betrachtung: J2EE versus .NET

6 Der Einsatz von Webservices zur Integration heterogener Welten
6.1 Einordnung von Webservices in das Integrationsschema
6.2 Webservices - Ein Paradigmenwechsel?
6.3 Prämissen beim Einsatz von Webservices zur Anwendungsintegration
6.3.1 Standardisierung
6.3.2 Interoperabilität
6.3.3 Verbreitungsgrad
6.3.4 Sicherheit
6.3.5 Transaktionsunterstützung
6.3.6 Quality of Service
6.3.7 Weitere Faktoren
6.4 Weitere technische Gesichtspunkte
6.5 Webservices und heutige Middleware
6.6 Betriebswirtschaftliche Faktoren
6.7 Integration innerhalb von Unternehmensgrenzen
6.8 Organisationsübergreifende Integration

7 Webservices zwischen Vision und Wirklichkeit

Anhang A: Listings

Anhang B: Ergänzende Abbildungen

Literaturverzeichnis

Eidesstattliche Erklärung

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abb. 1: Systematisierung der Integration

Abb. 2: EDI Übertragung

Abb. 3: Integrationsstufen von EDI

Abb. 4: AI Markt Deutschland

Abb. 5: Multistep Process Integration

Abb. 6: Point-to-point Schnittstellenspaghetti

Abb. 7: Hub-and-Spoke Architektur

Abb. 8: Bus / Pipeline Architektur

Abb. 9: Die CORBA Architektur

Abb. 10: Das EJB Modell

Abb. 11: Funktionsweise von Webservices

Abb. 12: Vorteile durch WS

Abb. 13: Potentielle Einsatzgebiete von WS

Abb. 14: Die Beziehung zwischen SGML, HTML und XML

Abb. 15: Bücher in HTML (s. a. Listing 3)

Abb. 16: Aufbau eines WSDL Files

Abb. 17: WSUI Implementierung

Abb. 18: SOAP Aufbau

Abb. 19: ebXML Geschäftsprozess

Abb. 20: Die J2EE Architektur

Abb. 21: Das .NET Framework

Abb. 22: WS Investitionen

Abb. 23: Entwicklung des AI Marktes

Abb. 24: Denial of Service Attacke

Abb. 25: Service Broker

Abb. 26: Beispielhafte EDI Rechnung

Abb. 27: Rechnung in XML

Abb. 28: UDDI Datenstruktur

Abb. 29: CORBA Domain Interfaces

Tabellenverzeichnis

Tabelle 1: Vergleich von Ansätzen zur funktionalen Integration

Tabelle 2: Charakteristika von Systemarchitekturen

Tabelle 3: Spezifische WS Technologien

Tabelle 4: Sicherheitsanforderungen an Webservices

Tabelle 5: Vergleich bisheriger Middleware mit Webservices

Tabelle 6: Erschwerende Faktoren von IEI

Listings

Listing 1: Bücher in XML

Listing 2: Beispielhafte DTD

Listing 3: Abb. 15 in HTML

Listing 4: Beispielhafter Visual Basic Webservice

Listing 5: Gekürztes WSDL File des Beispiels

Listing 6: SOAP Request des Beispiels

Listing 7: SOAP Response des Beispiels

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 zwischen-betrieblicher 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.

Abbildung in dieser Leseprobe nicht enthalten

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 Realisierungs-zeit 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.¹⁷

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).²⁷

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 können Kosten von bis zu 100.000 US-$

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: EDI Übertragung 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 Durchdringungsgrad versprechen, gerade für kleine und mittlere Unternehmen

Abbildung in dieser Leseprobe nicht enthalten

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

(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.⁴²

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 nicht alle benötigten Funktionalitäten ab: Noch

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: AI Markt Deutschland 2000 Metagroup / E-Business und EAI / 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 Integrations-software 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.⁴⁹

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.⁵⁷

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.⁵⁸

Abbildung in dieser Leseprobe nicht enthalten

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.

Abbildung in dieser Leseprobe nicht enthalten

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

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.⁶² 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.⁶⁴

Abbildung in dieser Leseprobe nicht enthalten

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

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.⁶⁵

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.

Abbildung in dieser Leseprobe nicht enthalten

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.⁶⁸

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 Laufzeit die Verteilung einzelner Komponenten auf mehrere Rechner unterstützen soll“.⁸¹ Bezogen auf den Funktionsumfang und die Fähigkeiten zur dynamischen Erweiterung sind Lösungen dieses Typs die besten Integrationsplattformen, welche im Folgenden an den Beispielen CORBA, Enterprise Java Beans (EJB) und COM vorgestellt werden.

2.6.2 CORBA - Die Common Object Request Broker Architecture

Der CORBA Standard ist das Ergebnis eines aus über 850 Firmen bestehenden Konsortiums namens Object Management Group (OMG).⁸² Schätzungsweise 60 unterschiedliche Implementierungen des CORBA Standards waren Ende 2001 am Markt und mindestens 1000 Großunternehmen nutzen CORBA zum heutigem Zeitpunkt.⁸³

CORBA ist gegenwärtig der leistungsfähigste und komplexeste Middleware Ansatz am Markt und tritt mit dem Ziel an, Interfaces für interoperable, sprachunabhängige SW unter Nutzung der Objekttechnologie zur Verfügung zu stellen.⁸⁴

Von Objekten bereitgestellte Schnittstellen werden in einer eigenen abstrakten, programm- und sprachunabhängigen Beschreibungssprache, der CORBA Interface Definition Language (IDL), beschrieben, CORBA ist also selbstbeschreibend. Das Herzstück von CORBA bildet der Object Request Broker (ORB). Durch ihn sind Funktionen eines Objekts dynamisch (Methoden sind beim Aufruf nicht bekannt und werden vom ORB gesucht) und statisch (bekannte Objekte) aufrufbar und CORBA Dienste zugänglich.⁸⁵ Die Suche beim dynamischen Methodenaufruf erfolgt mittels eines Schnittstellenverzeichnisses, das Metadaten deklariert, die von den Clients benutzt werden können. Die in CORBA realisierte Trennung von Objekt und Implementierung ermöglicht einfachere SW Wiederverwendung, da Änderungen in einer Schnittstelle nicht zwangsläufig deren Gegenpart betreffen.⁸⁶

Der ORB wird noch weiteren CORBA Diensten begleitet. Die komplette CORBA Architektur verdeutlicht die Abbildung auf der nächsten Seite.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 9: Die CORBA Architektur

Die Object Services stellen optionale, betriebssystemähnliche Funktionen bereit. Darunter können Dienste zur Datenspeicherung, zum Datenzugriff, zur Transaktionssicherung und zur Zugriffsverwaltung eingruppiert werden. Die Common Facilities erfüllen ähnliche Aufgaben wie die Object Services, allerdings anwendungsnäher und auf die Bedürfnisse spezieller Anwender zugeschnitten (z. B. Druckdienste). Domain Interfaces enthalten Branchen- und Betriebstypen spezifische Dienste (z. B. Dienste für die Fertigung, vgl. Abb. 29 im Anhang B).⁸⁷

Die Funktionsweise von CORBA lässt sich derart beschreiben: Der ORB erhält einen Request von einem Client und wandelt diesen in die IDL um. Anschließend sucht der ORB einen Service der die Anfrage bearbeiten kann. Nach Bearbeitung erfolgt die Rückübermittlung des Ergebnisses an den Client. Dabei unterstützt der ORB Transparenz, wodurch Entwickler in der Lage sind, serverseitig Änderungen vorzunehmen, ohne dass die Clients davon betroffen sind.⁸⁸

Um Interoperabilität zwischen den Implementierungen verschiedener Hersteller zu gewährleisten, kommunizieren ORBs miteinander über das General Inter ORB Protocol (GIOP) Protokoll, somit ist eine Nutzung mehrerer ORBs nebeneinander möglich.⁸⁹ Bis zur Version 3, die 1999 veröffentlicht wurde, bot CORBA kein Komponentenmodell und arbeitete nur mit synchroner Kommunikation. Beides wurde mit der neuen Version beseitigt. CORBA unterstützt jetzt XML zur Verteilung von Komponenten über Plattformgrenzen hinweg und bietet eine Spezifikation zum Umgang mit Firewalls, wodurch die Möglichkeit des Einsatzes im Internet Eine weitere Neuerung ist Minimum CORBA, welches die Verwendung von CORBA auf PDAs und Handys gestattet.⁹⁰

2.6.3 Enterprise Java Beans

Die in der Version 2.0 vorliegenden Enterprise Java Beans (EJB), die 1998 auf den Markt kamen, stellen einen Teil von Suns Java 2 Enterprise Edition (J2EE) dar, die in Abschnitt detaillierter 5.1.1 behandelt wird.

EJBs definieren ein serverseitiges Komponentenmodell mit dem Geschäftsobjekte entwickelt werden können. Anforderungen wie Sicherheit, Persistenz und Transaktions-integrität finden dabei automatisch Berücksichtigung, so dass sich Entwickler ausschließlich mit der Geschäftslogik auseinandersetzen müssen. EJBs sind nicht eigenständig ausführbar, sondern laufen innerhalb einer Laufzeitumgebung (Container) ab, der vom EJB Server bereitgestellt wird. Der EJB Server oder allgemein Application Server verkörpert das zentrale Element der Architektur. Hierbei handelt es sich um eine Systemsoftware, die zum einen EJB Container verwaltet und zum anderen die o. g. Dienste und die Funktionalität der Beans (Komponenten) bereitstellt. Mittels des Containers ist bspw. der Zugriff auf Datenbanken realisierbar.⁹¹

Eine Bean kapselt die Geschäftslogik und existiert in drei Varianten: Entity Beans, Session Beans und Message driven Beans. Entity Beans modellieren Geschäftsobjekte, die wiederum Objekte der wirklichen Welt abbilden (z. B. einen Kunden).⁹² Diese sind persistent und entsprechen im einfachsten Fall der Zeile in einer Datenbank. Sessions Beans sind für die Durchführung von Geschäftsabläufen zuständig. Sie beschreiben Interaktionen die zwischen Entity Beans stattfinden, also konkrete Anwendungsfälle. Session Beans greifen z. B. auf Daten zu, um Listen zu erstellen, die auf Entity Beans beruhen (bspw. Liste aller Kunden).⁹³ Session Beans existieren in zwei Ausprägungen: Zustandsbehaftet (Stateful), wenn Informationen eines Clients während einer Sitzung gespeichert werden müssen und zustandslos (Stateless). Nach Beendigung einer Sitzung wird eine Session Bean wieder gelöscht.

[...]

---

¹ Vgl.: o. V. / Silverstream / 2001 / S. 1.

² Vgl.: Alexander / Webservices & Cebit / 2002 / S. 1.

³ Vgl.: Arndt / XML-Webservices / 2002 / S. 1.

⁴ Vgl.: Sailer / EAI - Anforderungen / 2001 / S. 208f.

⁵ Vgl.: Irani / Implementing WS / 2001 / S. 3.

⁶ Vgl.: Mertens / Informationsverarbeitung / 1997 / S. 81.

⁷ Vgl.: Rohde / Komponentensysteme / 1999 / S. 99.

⁸ Vgl.: Fochler / EAI Verständnis / 2001 / S. 2.

⁹ Vgl.: Ruh / EAI / 2001 / S. 3.

¹⁰ Vgl.: Weitzel / E-Business mit XML / 2001 / S. 6.

¹¹ Vgl.: Ferstl / Wirtschaftsinformatik / 1994 / S. 198ff.

¹² Vgl.: Zahavi / EAI with CORBA / 2000 / S. 21.

¹³ Vgl.: Assendorf / EAI Tools / 2001 / S. 23.

¹⁴ Vgl.: Mertens / Informationsverarbeitung / 1997 / S. 9f.

¹⁵ Vgl.: Sellentin / Informationssysteme / 2000 / S. 11.

¹⁶ Vgl.: Mertens / Informationsverarbeitung / 1997 / S. 10f. und Krcmar / Integration / 1991 / S. 6f.

¹⁷ Vgl.: Winkeler / EAI vor E-Business / 2000 / S. 19.

¹⁸ Vgl.: Ferstl / Wirtschaftsinformatik / 1994 / S. 196 und Sailer / EAI - Anforderungen / 2001 / S. 210.

¹⁹ Vgl.: Österle / Integration / 1996 / S. 5.

²⁰ Vgl.: Winkeler / EAI vor E-Business / 2000 / S. 13.

²¹ Vgl.: Assendorf / EAI Tools / 2001 / S. 25 und ebenso Rohde / Komponentensysteme / 1999 / S. 93.

²² Vgl.: Griffel / Componentware / 1998 / S. 10.

²³ Vgl.: Bienhaus / Realisierung verteilter Systeme / 2000 / S. 5; Griffel / Componentware / 1998 / S. 32.

²⁴ Vgl.: Orfali / Instant CORBA / 1998 / S. 13.

²⁵ Vgl.: Griffel / Componentware / 1998 / S. 18 als auch S. 32 und Österle / Integration / 1996 / S. 16.

²⁶ Vgl.: Griffel / Componentware / 1998 / S. 45 und S. 23.

²⁷ Vgl.: Sellentin / Informationssysteme / 2000 / S. 24ff. sowie Krcmar / Integration / 1991 / S. 9.

²⁸ Vgl.: Zbornik / Netzwerke / 1996 / S. 82f.

²⁹ Unter ‚syntaktisch’ wird technisch mögliche Zusammenarbeit verstanden, ‚semantisch’ bezeichnet das inhaltliche, logische Verständnis.

³⁰ Einen ausführlichen Überblick über die Entwicklung bietet Cannon / EDI Guide / 1993 / S. 45ff.

³¹ Vgl.: Georg / EDIFACT / 1993 / S. 9 und S. 22 sowie Zbornik / Netzwerke / 1996 / S. 39 und S. 85.

³² Vgl.: Georg / EDIFACT / 1993 / S. 34f. und Scheckenbach / Web - EDI / 1999 / S. 1.

³³ Vgl.: Cannon / EDI Guide / 1993 / S. 16.

³⁴ Vgl.: Seffinga / EDI - Stand und Potentiale / 1996 / S. 7 und o. V. / EDI für alle / 2000 / S. 1.

³⁵ Vgl.: Neuburger / EDI Durchbruch / 1997 / S. 2.

³⁶ Vgl.: Seffinga / EDI - Stand und Potentiale / 1996 / S. 85.

³⁷ Vgl.: Georg / Elektronischer Geschäftsverkehr / 1995 / S. 93.

³⁸ Vgl.: o. V. / EDI für alle / 2000 / S. 1.

³⁹ Vgl.: Scheckenbach / Web - EDI / 1999 / S. 1f.

⁴⁰ Ein Beispiel hierzu findet sich unter http://www.ecin.de/edi/xml/edi-xml-beispiel/xml_demo.htm .

⁴¹ Extensible Markup Language; Vgl. Kapitel 4.1.

⁴² Vgl.: Buxmann / Web EDI / 2001 / S. 20ff. und o. V. / XML-EDI / 1997 / S. 4ff.

⁴³ Vgl.: Metagroup / E-Business und EAI / 2001 / S. 6f. und Assendorf / EAI Tools / 2001 / S. 19.

⁴⁴ Vgl.: A.T.Kearney / WS Market / 2002 / S. 6.

⁴⁵ Vgl.: Metagroup / E-Business und EAI / 2001 / S. 6f.

⁴⁶ Vgl.: Schätzle / EJB / 2002 / S. 2.

⁴⁷ Vgl.: Rautenstrauch / Integration Engineering / 1993 / S. 124f. und Koch / EJB 2.0 / 2001 / S. 2.

⁴⁸ Vgl.: Winkeler / EAI vor E-Business / 2000 / S. 22.

⁴⁹ Vgl.: Fochler / EAI Verständnis / 2001 / S. 2.

⁵⁰ Vgl.: Linthicum / EAI / 1999 / S. 136.

⁵¹ Vgl.: Winkeler / EAI vor E-Business / 2000 / S. 9.

⁵² Vgl.: Ruh / EAI / 2001 / S. 19 und S. 22f.

⁵³ Vgl.: Ferstl / Wirtschaftsinformatik / 1994 / S. 203 sowie Krcmar / Integration / 1991 / S. 6.

⁵⁴ Vgl.: Rohde / Komponentensysteme / 1999 / S. 96f.

⁵⁵ Vgl.: Riehm / Integrationsinfrastruktur / 1996 / S. 56 und Linthicum / EAI / 1999 / S. 24.

⁵⁶ Vgl.: Mertens / Informationsverarbeitung / 1997 / S. 1 als auch Linthicum / EAI / 1999 / S. 28f.

⁵⁷ Vgl.: Linthicum / B2B Integration / 2000 / S. 27 sowie Ruh / EAI / 2001 / S. 27.

⁵⁸ Vgl.: Ruh / EAI / 2001 / S. 27ff und S. 32f.

⁵⁹ Vgl.: Ruh / EAI / 2001 / S. 33f als auch S. 38.

⁶⁰ Vgl.: Sellentin / Informationssysteme / 2000 / S. 26.

⁶¹ Vgl.: Linthicum / B2B Integration / 2000 / S. 70f.

⁶² Konnektoren bieten standardisierten Zugriff auf die zu integrierenden Systeme

⁶³ Vgl.: Winkeler / EAI vor E-Business / 2000 / S. 24 sowie S. 32.

⁶⁴ Vgl.: Assendorf / EAI Tools / 2001 / S. 20.

⁶⁵ Vgl.: Winkeler / EAI vor E-Business / 2000 / S. 12f.

⁶⁶ Bsp.: Das Anlegen eines neuen Lieferanten in einer Legacy Anwendung führt zur Anlage im ERP und SCM System.

⁶⁷ Vgl.: Assendorf / EAI Tools / 2001 / S. 20.

⁶⁸ Vgl.: Assendorf / EAI Tools / 2001 / S. 20f.

⁶⁹ Vgl.: Riehm / Integrationsinfrastruktur / 1996 / S. 126 und Österle / Integration / 1996 / S. 11.

⁷⁰ Vgl.: Ruh / EAI / 2001 / S. 3.

⁷¹ Rohde / Komponentensysteme / 1999 / S. 101.

⁷² Vgl.: Riehm / Integrationsinfrastruktur / 1996 / S. 28; Österle / Integration / 1996 / S. 18.

⁷³ Vgl.: Bienhaus / Realisierung verteilter Systeme / 2000 / S. 4 und S. 117.

⁷⁴ Vgl.: Serain / Middleware/ 1999 / S. 9 sowie S. 30.

⁷⁵ Vgl.: Haase / Kommunikation / 2001 / S. 7f.

⁷⁶ Vgl.: Riehm / Integrationsinfrastruktur / 1996 / S. 79f und Linthicum / EAI / 1999 / S. 125.

⁷⁷ Vgl.: Rock - Evans / DCOM Explained / 1998 / S. 53.

⁷⁸ Vgl.: Serain / Middleware/ 1999 / S. 15.

⁷⁹ Vgl.: Linthicum / EAI / 1999 / S. 123.

⁸⁰ Vgl.: Ruh / EAI / 2001 / S. 54 und S.57f.

⁸¹ Vgl.: Sellentin / Informationssysteme / 2000 / S. 25.

⁸² Vgl.: Haase / Kommunikation / 2001 / S. 78.

⁸³ Vgl.: Alexander / CORBA Eminenz / 2001 / S. 1 und Linthicum / EAI / 1999 / S. 180.

⁸⁴ Vgl.: Mowbray / CORBA / 1997 / S. 10; Sellentin / Informationssysteme / 2000 / S. 18.

⁸⁵ Vgl.: Linnhoff - Popien / CORBA / 1998 / S. 28ff. und S. 35.

⁸⁶ Vgl.: Orfali / Instant CORBA / 1998 / S. 10f.

⁸⁷ Vgl.: Linnhoff - Popien / CORBA / 1998 / S. 36; Orfali / Instant CORBA / 1998 / S. 23f.

⁸⁸ Vgl.: Mowbray / CORBA / 1997 / S. 43.

⁸⁹ Vgl.: Alexander / CORBA Eminenz / 2001 / S. 1 und Linthicum / EAI / 1999 / S. 180.

⁹⁰ Vgl.: Stal / Episode 3 / 2000 / S. 1.

⁹¹ Vgl.: Schätzle / EJB / 2002 / S. 4.

⁹² Vgl.: Monson - Haefel / EJB / 2001 / S. 159.

⁹³ Vgl.: Monson - Haefel / EJB / 2001 / S. 26 und S. 225.