Einsatz von XML-Technologien zur Geschäftsprozess-Integration. Die Anbindung von Dienstleistern aus der Versicherungswirtschaft an das Branchennetz „Kfz- Schadenservices“

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

Der Autor

Vorwort

1 Einleitung
1.1 Problemstellung
1.2 Ziel der Arbeit
1.3 Aufbau der Arbeit

2 Allgemeine Grundlagen
2.1 Betriebswirtschaftlich-organisatorische Grundlagen
2.1.1 Geschäftsprozess
2.1.2 E-Business
2.1.3 Enterprise Application Integration
2.1.4 Business to Business Application Integration
2.2 Informationstechnische Grundlagen
2.2.1 Integrationsansätze
2.2.1.1 Anforderungen an Integrationswerkzeuge im B2B-Bereich
2.2.1.2 Integrationstechnologien
2.2.1.3 Topologien von Integrations-Systemen
2.2.1.4 Architektur von Integrations-Systemen
2.2.2 XML-Technologien
2.2.2.1 XML - Extensible Markup Language
2.2.2.2 DTD und XML Schema
2.2.2.3 XPath
2.2.2.4 XSLT – Extensible Stylesheet Language Transformation
2.2.2.5 XQuery
2.2.2.6 Digitale Signaturen in XML

3 E-Business Integration
3.1 Integrationstreiber
3.1.1 Heterogenität der Systeme
3.1.2 Dynamisches Unternehmensumfeld
3.1.3 ERP-Integration
3.1.4 B2B-Integration
3.1.5 E-Commerce
3.1.6 Fusionen und Akquisitionen
3.2 Ebenen der Integration
3.2.1 Präsentations-Integration
3.2.2 Prozess-Integration
3.2.3 Anwendungs-Integration
3.2.4 Daten-Integration
3.3 Realisierung von Integrationsprojekten
3.3.1 Theoretische Vorgehensweise und Praxis
3.3.2 Erfolgsfaktoren
3.3.3 Wirtschaftlichkeitsbeurteilung
3.4 Integration mit XML
3.4.1 Probleme des inner- und zwischenbetrieblichen Datenaustauschs
3.4.2 XML versus traditionelles EDI
3.4.3 XML-Standards im Bereich des E-Business
3.4.4 Electronic Business XML und die Universal Business Language

4 Die Anbindung eines Dienstleisters an das „Kfz-Schadennetz“
4.1 Vorstellung des GDV
4.1.1 Das „Kfz-Schadennetz“ des GDV
4.1.2 Der GDV-Standard
4.1.2.1 Release 2000
4.1.2.2 Release 2003
4.2 Der Beispielprozess „Fakturierung und Versand von Produkten“
4.2.1 Der Geschäftsprozess „Fakturierung und Versand“
4.2.2 Informationstechnische Unterstützung
4.2.3 Schwächen des Vorgehens mit statischer Transformationslogik

5 Konzept zur dynamischen Transformation
5.1 Anforderungsdefinitionen
5.2 Workflow-Ebene
5.3 Transformations-Ebene
5.3.1 Dynamisches XSLT
5.3.2 XSLT-Objekte
5.3.3 Zusammensetzen der Objekte - „Assembler“
5.3.4 Konfiguration
5.3.4.1 Konfiguration über die Objektauswahl:
5.3.4.2 Konfiguration über Präferenzen:
5.3.5 Zusammenfassung der Transformationsprozesse
5.3.6 Dokumentation – „Docwriter“
5.3.7 Allgemeine Anwendbarkeit
5.4 Aspekte der Implementierung
5.5 Betrachtung der Wirtschaftlichkeit

6 Implementierung der dynamischen Transformation
6.1 Quell- und Zieldokumente
6.2 Die Konfiguration der Transformation
6.3 Aufbau der XSLT-Objekte
6.4 Die Transformation
6.5 Die Funktionsweise des Assemblers
6.6 Automatische Erzeugung der Dokumentation

7 Zusammenfassung und Ausblick

Quellenverzeichnis

Abbildungsverzeichnis

Abbildung 2.1: Abteilungsübergreifende Geschäftsprozesse

Abbildung 2.2: Der Weg zum E-Business

Abbildung 2.3: Geschäftsmodelle im E-Business

Abbildung 2.4: Enterprise Application Integration

Abbildung 2.5: B2B-E-Commerce

Abbildung 2.6: Punkt-zu-Punkt-Verbindung

Abbildung 2.7: EAI-Hub und Bus-Struktur

Abbildung 2.8: Bausteine einer EAI-Architektur

Abbildung 2.9: Wohlgeformtes XML-Dokument

Abbildung 2.10: XSL-Transformation

Abbildung 2.11: Signieren eines XML-Dokuments

Abbildung 2.12: Testen eines signierten XML-Dokuments

Abbildung 3.1: Ebenenmodell für die E-Business Integration

Abbildung 3.2: Struktureller Rahmen für Erfolgsfaktoren bei Integrationsprojekten

Abbildung 3.3: Integrationskosten

Abbildung 4.1: Beispielprozess Schadensregulierung

Abbildung 4.2 Der Nachrichtentyp „Schadenmeldung“

Abbildung 4.3: Ausschnitt Geschäftsprozess „Fakturierung und Versand“

Abbildung 4.4: Schematische Darstellung der IT-Systeme

Abbildung 4.5: XSL-Transformation der Daten aus dem Produktionssystem

Abbildung 5.1: Workflow im Soll-Konzept

Abbildung 5.2: Dynamisches XSLT

Abbildung 5.3: Aufbau eines Objekts

Abbildung 5.4: Erzeugen des Ziel-Stylesheets

Abbildung 5.5: Kopiervorgang zur Erzeugung eines Ziel-Stylesheets

Abbildung 5.6: Aufbau eines Konfigurationsdokuments

Abbildung 5.7: Transformationsprozesse in der Soll-Situation

Abbildung 5.8: Erzeugen der Dokumentation

Abbildung 5.9: Vorgehensmodell der Implementierung

Abbildung 5.10: Kostenvergleich Soll-Ist

Abbildung 6.1 Das Quelldokument

Abbildung 6.2 Nachrichtentyp 005, Kalkulation

Abbildung 6.3 Zieldokument für VUA

Abbildung 6.4 Zieldokument für VUB

Abbildung 6.5 Standardkonfiguration für Nachrichtentyp 005

Abbildung 6.6 Format der Schadennummer im Quelldokument

Abbildung 6.7 Konfigurationsdokument für VUA

Abbildung 6.8 Konfigurationsdokument für VUB

Abbildung 6.9 Objekt „Zahlenformatdefinitionen“

Abbildung 6.10 Objekt „RootTemplate“

Abbildung 6.11 Konfiguration, Dokumentation und Verwendung von Parametern

Abbildung 6.12 Objekt „Zugriffspfaddefinitionen“

Abbildung 6.13 Objekt „DatumUhrzeitErmitteln“

Abbildung 6.14 Objekt „Variablendefinitionen“

Abbildung 6.15 Objekt „4001“

Abbildung 6.16 Objekt „Header“

Abbildung 6.17 Objekt „4300“ – Kalkulation / Rechnung

Abbildung 6.18 Objekt „4900“ – Anhang

Abbildung 6.19 Benötigte Dateien für die Transformation

Abbildung 6.20 Ziel-Stylesheet „export_VUA_005.xsl“

Abbildung 6.21 Der Nachrichtentyp 005 für VUA

Abbildung 6.22 Der Nachrichtentyp 005 für VUB

Abbildung 6.23 Präferenzen – Konfiguration und Umsetzung

Abbildung 6.24 Dokumentation für das RootTemplate für VUA

Abbildung 6.25 Dokumentation für die Satzart 4900 für VUA

Abbildung 6.26 Dokumentation für die Satzart 4900 für VUB

Hinweis zur Quellenangabe

Im Text wird hinter dem Titel der Abbildung ggf. auf die Quelle hingewiesen. Abbildungen ohne diese Angabe wurden zur Illustration vom Autor selbst erstellt.

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Der Autor

Torben Müller hat in den Jahren 2002 bis 2007 an der Universität Kassel Wirtschaftswissenschaften mit dem Schwerpunkt Verwaltungs- und Wirtschaftsinformatik studiert. Seine beiden praxisnahen Diplomarbeiten schrieb er jeweils in Kooperation angesehenen Unternehmen aus der Automobilbranche. Mittlerweile arbeitet er bei einem IT-Dienstleister der Automobilindustrie im Bereich der Systemanalyse und Prozessautomatisierung. Neben seiner akademischen Laufbahn besitzt er Erfahrung in den Bereichen IT- und Softwarearchitektur, Software-Engineering, verteilte Systeme sowie Internet- und Datenbanktechnologien.

Reaktionen zu diesem Buch nimmt er gerne per E-Mail (torbenmueller@me.com) entgegen. Auch ist es möglich, auf diesem Weg die Quelltexte aus diesem Buch für eigene Experimente zu beziehen und Fragen direkt an den Autor zu stellen.

Vorwort

Das vorliegende Buch gibt eine anonymisierte und erweiterte Version meiner Diplomarbeit wieder, die zur Erlangung des akademischen Grades Diplom Ökonom angefertigt und von den Gutachtern des Fachgebiets Wirtschaftsinformatik der Universität Kassel im Januar 2006 mit der Note 1,0 bewertet wurde.

Die Themengebiete rund um die Integration von Geschäftsprozessen über Unternehmensgrenzen hinweg sind heute so aktuell wie sie es im Jahr des Entstehens der Diplomarbeit waren. Auch die XML-Technologien finden heute im Zusammenhang mit der B2B-Integration Anwendung. Gerade in kleinen und mittelständigen Unternehmen bieten die Standardtechnologien eine kostengünstige Alternative zu kommerziellen Integrationslösungen.

Die Arbeit verliert durch ihre Anonymisierung nicht an Wert. Das auf einer dynamischen Datentransformation basierende Konzept zur Integration von Geschäftsprozessen, bei denen XML-basierte Daten unterschiedlichen Formats ausgetauscht werden, ist übertragbar und branchenübergreifend anwendbar. Für dieses Buch wurde die Originalarbeit um ein Kapitel ergänzt, welches eine technische Umsetzung des Konzepts zur Transformation XML-basierter Daten mittels XSLT vorstellt. Das Buch ist damit auch für Praktiker interessant.

Ich möchte an dieser Stelle all denen meinen Dank aussprechen, die einen Beitrag zum Gelingen dieser Arbeit geleistet haben. Insbesondere danke ich meinem Vater, der als Lektor geschätzte Arbeit leistete.

Kassel, im Sommer 2009 Torben Müller

1 Einleitung

Geschäftsprozesse werden heute durch Anwendungssysteme unterstützt. Einzelne Aktivitäten innerhalb von Geschäftsprozessen werden vielfach von unterschiedlichen Anwendungen abgebildet. Optimale funktionsbereichübergreifende Prozessabläufe und ein hohes Maß an Automatisierung lassen sich zumeist durch die Integration der unterstützenden Anwendungssysteme erreichen. Die Integration beschleunigt und rationalisiert die Informationsflüsse innerhalb eines oder zwischen mehreren Unternehmen. Ein erster Ansatz war der gemeinsame Zugriff auf zentrale Daten durch mehrere Anwendungen. Heute steht zunehmend die Integration und Automatisierung von umfassenden Geschäftsprozessen - auch über Unternehmensgrenzen hinweg - im Vordergrund.

Die Konzepte der Enterprise Application Integration (EAI) bzw. Business to Business Application Integration (BBAI) liefern einen Beitrag zur Lösung der Integrationsprobleme. Für den innerbetrieblichen oder zwischenbetrieblichen Datenaustausch zwischen Anwendungssystemen hat sich die Extensible Markup Language (XML) als Standard einen Namen gemacht.

Diese Arbeit zeigt den Einsatz von XML-Technologien, insbesondere XSLT, zur Geschäftsprozess-Integration am Beispiel der Anbindung von Dienstleistern an Versicherer über das Branchennetz „Kfz-Schadenservices“ des GDV.

1.1 Problemstellung

Durch historisch gewachsene Strukturen bildeten sich in den Unternehmen viele voneinander unabhängige, zumeist inkompatible, Anwendungssysteme. Die heterogene Anwendungslandschaft ist unflexibel, wenn es darum geht, sich laufend verändernde Geschäftsprozesse mit wechselnden Geschäftspartnern zu unterstützen. Heterogene Anwendungssysteme sind nicht interoperabel, d. h. sie können nicht von Haus aus miteinander kommunizieren, Daten austauschen und interagieren.

Innerhalb der Geschäftsprozesse zwischen Dienstleistern wie Prüfgesellschaften und Versicherungsunternehmen werden Daten über den Gesamtverband der Deutschen Versicherungswirtschaft (GDV) in Form von Geschäftsdokumenten ausgetauscht. Diese Daten werden von den Empfängern oft in einem anderen Format erwartet, als sie vom Absender vorliegen oder erzeugt werden. Dies erfordert eine Transformation. Zudem stellen verschiedene am Markt agierende Unternehmen differenzierte Ansprüche an die genauen Inhalte der Geschäftsdokumente.

1.2 Ziel der Arbeit

Diese Arbeit soll die Grundlagen der Themengebiete EAI und BBAI erarbeiten. Aktuelle Integrationsansätze und Integrationstechnologien sowie Topologien und eine Architektur von Integrationssystemen sollen vorgestellt werden. Es sollen mögliche Motive für die Integration von Anwendungssystemen und Prozessen aufgezeigt und ein Überblick über das Konzept der Enterprise Application Integration gegeben werden. Im Kontext der E-Business-Integration wird auf Aspekte der Realisierung von Projekten, Erfolgsfaktoren und die Wirtschaftlichkeit eingegangen. Die Technologien auf Basis der Extensible Markup Language (XML-Technologien) sollen mit traditionellem Electronic Data Interchange (EDI) verglichen werden, und es soll aufgezeigt werden, wie aktuelle XML-Technologien zum Datenaustausch in einem B2B-Integrationsszenario beitragen können.

Im Rahmen des Praxisteils der Arbeit wird ein wieder verwendbares Konzept für die flexible Transformation von in XML-Notation vorliegenden Daten entwickelt, welches das Potenzial hat, die oben angesprochenen unternehmensübergreifenden Geschäftsprozesse für die Verbindung unterschiedlicher Unternehmen in Hinblick auf die dafür nötige Datentransformation optimal zu unterstützen. Dies ist Voraussetzung, dass Unternehmen ihren Kunden eine elektronische Anbindung anbieten und flexibel auf Kundenwünsche reagieren können. Es soll gezeigt werden, dass eine flexible und konfigurierbare Transformation von XML-Daten zwischen unterschiedlichen Formaten und Formatvarianten mit Hilfe von XML-Technologien kostengünstig realisierbar ist.

1.3 Aufbau der Arbeit

Die Arbeit besteht aus einem Theorie- und einem Praxisteil. Der Theorieteil umfasst die Kapitel 2 und 3. Im zweiten Kapitel werden zunächst die betriebswirtschaftlichen sowie die informationstechnischen Grundlagen des Themenbereichs vorgestellt. Darauf aufbauend werden im dritten Kapitel „E-Business-Integration“ vertiefend Aspekte der Integration von Anwendungssystemen und Geschäftsprozessen beleuchtet. Neben der Darstellung von möglichen Gründen für die Integration und deren verschiedenen Ebenen ist auch die Realisierung von Integrationsprojekten Gegenstand dieses Kapitels. In Hinblick auf den Praxisteil wird die Eignung von XML-Technologien für die Unterstützung der Integration von Anwendungssystemen und Prozessen - auch in Bezug auf unternehmensübergreifende Geschäftsprozesse - bewertet.

Der Praxisteil besteht aus den Kapiteln 4 bis 6. Im vierten Kapitel wird zunächst das „Kfz-Schadennetz“ des Gesamtverbands der Deutschen Versicherungswirtschaft und ein beispielhafter Geschäftsprozesse mit seinen technischen Schnittstellen zwischen einem Anbieter für Unfallgutachten und Versicherungsunternehmen vorgestellt. Es wird gezeigt, wie Geschäftsdokumente im XML-Format mit Hilfe von statischem XSLT in ein vom GDV akzeptiertes Format transformiert werden und welche Schwächen dieses Vorgehen mitbringt.

Im fünften Kapitel wird das im Zuge dieser Arbeit entwickelte Konzept zur flexiblen Unterstützung der Datentransformation vorgestellt, welches die Schwächen der Verwendung von statischem XSLT aufgreift. Das sechste Kapitel stellt schließlich eine mögliche technische Umsetzung des Konzepts unter Einsatz von XSLT vor. Damit steht ein erweiterbares Rahmenwerk für die XML basierte Datentransformation breit. Im siebten Kapitel werden die Ergebnisse der Arbeit zusammengefasst. Abschließend wird ein Ausblick gegeben.

2 Allgemeine Grundlagen

In diesem Kapitel werden allgemeine Grundlagen beschrieben, die für das Thema der Arbeit, die elektronische Geschäftsprozess-Integration, von Bedeutung sind. Dabei werden betriebswirtschaftlich-organisatorische und informationstechnische Aspekte behandelt.

Der Abschnitt „Betriebswirtschaftlich-organisatorische Grundlagen“ erläutert die Begriffe Geschäftsprozess, E-Business, Enterprise Application Integration und Business to Business Application Integration.

Dagegen werden im informationstechnischen Teil Technologien, Topologien und eine Architektur von Integrationsansätzen beschrieben. Der Praxisteil der Arbeit beschäftigt sich mit der Geschäftsprozess-Integration auf Basis der XML-Technologie. Folglich nehmen die grundlegenden Elemente dieser Technologie einen besonderen Platz ein.

2.1 Betriebswirtschaftlich-organisatorische Grundlagen

In der Literatur besteht derzeit keine Einigung über die genaue Definition von E-Business oder Enterprise Application Integration (EAI). Die meisten Autoren verbinden mit EAI nur die unternehmensinterne Integration und grenzen den Begriff von der zwischenbetrieblichen Integration ab, andere verstehen unter demselben Begriff die Integration verschiedener Systeme auch über Unternehmensgrenzen hinweg. Durch die Unterscheidung zwischen einer internen und einer zwischenbetrieblichen Anwendungsintegration kann der Problembereich strukturiert werden [MaSc02, 171]. In den folgenden Abschnitten werden aus diesem Grund neben dem Geschäftsprozessbegriff die Begriffe E-Business, Enterprise Application Integration und B2B Application Integration (BBAI) erläutert und abgegrenzt.

2.1.1 Geschäftsprozess

Der klassische organisatorische Aufbau der Unternehmen ist durch die Aufteilung des gesamten Unternehmens in voneinander getrennte Funktionsbereiche und durch eine hierarchische Gliederung der Organisationseinheiten geprägt. Diese funktionale Organisation folgt dem Taylorismus. Die methodischen Grundsätze sind horizontale und vertikale Spezialisierung, Akkordlohnsysteme und die Normierung von Arbeitsobjekt, Arbeitszeit und Arbeitstätigkeit [Tayl13]. Die funktionsorientierte Organisationsform der Unternehmen dominierte bis Anfang der 90er Jahre, als die Prozessorientierung mit Schlagworten wie Business Process Reengineering (Hammer/Champy, 1995) in den Fokus der betriebswirtschaftlichen Betrachtung rückte. Über die einzelnen Funktionsbereiche wurde eine Prozesssicht gelegt. Geschäftsprozesse werden heute auf die Kunden ausgerichtet und reichen über die Grenzen der einzelnen Abteilungen hinweg.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Abteilungsübergreifende Geschäftsprozesse

Im Folgenden werden mehrere Definitionen für den Geschäftsprozess-Begriffs vorgestellt, die verschiedenen Aspekten einen unterschiedlichen Schwerpunkt beimessen, sich inhaltlich jedoch nicht gegenseitig ausschließen.

Hammer und Champy definieren einen Geschäftsprozess als „Bündelung von Aktivitäten, die einen oder mehrere Inputs benötigen und für den Kunden ein Ergebnis von hohem Wert erzeugen [HaCh95, 52].“ Davenport und Short definieren den Begriff als spezielle Reihenfolge von Aktivitäten, an deren Ende eine Leistung/ein Produkt für bestimmte Kunden oder Märkte entstanden ist [DaSh90]. Nach Scheer ist ein Geschäftsprozess „eine zusammengehörende Abfolge von Unternehmensverrichtungen zum Zweck einer Leistungserstellung. Ausgang und Ergebnis des Geschäftsprozesses ist eine Leistung, die von einem internen oder externen Kunden angefordert und abgenommen wird [Sche02, 3].“ Eine aktuelle Definition bieten Schmelzer und Sesselmann: „Geschäftsprozesse sind funktionsübergreifende Verkettungen wertschöpfender Aktivitäten, die von Kunden erwartete Leistungen erzeugen und deren Ergebnisse strategische Bedeutung für das Unternehmen haben [ScSe04, 46].“

Zusammenfassend kann man sagen, dass Geschäftsprozesse durch verknüpfte Aktivitäten über mehrere Funktionseinheiten im Unternehmen hinweg einen oder mehrere Inputs in eine Output-Leistung verwandeln, die einen Wert für einen Kunden darstellt. Dabei kann es sich um einen internen Kunden im Unternehmen oder um einen externen Kunden handeln.

Weitgehend Einigkeit besteht in der Frage, welche Ziele bei der Gestaltung der Geschäftsprozesse zu erreichen sind. Die Unternehmen befinden sich heute unter einem immer stärkeren Wettbewerbsdruck. Gründe dafür sind u. a. die zunehmende Markttransparenz, die Globalisierung, kürzere Technologie- und Produktzyklen, Kostendruck, Wertewandel und gesättigte Käufermärkte [ScSe04, 1].

Als größtes Ziel des Geschäftsprozessmanagements steht dabei die Kundenzufriedenheit im Vordergrund. Davon lassen sich die Erhöhung der Prozessqualität und die Reduzierung der Durchlaufzeiten direkt als Ziele ableiten. Ein weiteres für das Unternehmensergebnis wichtiges Ziel ist die Reduzierung der Prozesskosten. Geschäftsprozessmanagement ist ein geeignetes Konzept, um auf die wachsenden Anforderungen an Zeit, Qualität, Kosten und Flexibilität zu reagieren und die erforderlichen Anpassungen vorzunehmen [ScSe04, 2].

Die Geschäftsprozesse machen vor den Mauern der Unternehmen nicht Halt. Bezieht man in den Geschäftprozess auch externe Unternehmen ein, spricht man auch, im Falle der Lieferantenbeziehung, von Supply Chain Management bzw., im Falle der Kundenbeziehung, von Customer Relationsship Management [StHa02, 211].

2.1.2 E-Business

Die schnelle und flächendeckende Ausbreitung des Internets und dessen Anwendung im ökonomischen Bereich brachte einige moderne Begriffe hervor, die aus dem Alltag und dem Anwendungskontext entstanden sind und wissenschaftlich noch nicht klar definiert sind.

Auch der Begriff E-Business ist in der Literatur trotz der Verbreitung der Informations- und Kommunikationstechnologie zur Unterstützung der Geschäftsprozesse nicht eindeutig definiert und wird je nach Autor vielfach unterschiedlich abgegrenzt. Im Folgenden werden einige Definitionsversuche vorgestellt.

„E-Business kann man als einen Sammelbegriff für Geschäfte verstehen, die unter Nutzung von elektronischen Medien abgewickelt werden, insbesondere von Internet-Technologien und dem World Wide Web [Schö01, 66].“

„Electronic Business ist allgemein definiert durch die Implementierung von Geschäftsverfahren, die nur durch Einsatz von IT-Anwendungen und insbesondere die Kommunikation über Inter- Intra- Extra-Net implementiert werden können [PaEh01, 30].“

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Der Weg zum E-Business (Vgl. [ScKö01])

Neben dem Begriff E-Business wird auch oft der Begriff E-Commerce verwendet, welcher heute als Teilgebiet des E-Business gesehen wird. "E-Business schließt E-Commerce mit ein und integriert mittels neuer Medien sowohl die Austauschverhältnisse zwischen Unternehmen und Kunden bzw. Unternehmen und Geschäftspartnern als auch die internen Koordinationsmechanismen [Stäh01]." Stähler stellt weiter dar, dass sich E-Business nicht nur innerhalb eines Unternehmens, sondern ganz besonders über die Unternehmensgrenzen hinaus erstreckt. Andere Begriffsbestimmungen schränken E-Commerce ein und sehen darin alle Transaktionen mit einer Betonung zum Konsumenten. Diese Art von Transaktionen betrifft Unternehmen und Endverbraucher und zielt auf den Kauf und Verkauf von Produkten im Internet ab.

Nachdem die „Mauern“ zwischen den Abteilungen nach dem Übergang von der funktionalen zur prozessorientierten Organisation gefallen sind, verschwinden durch E-Business auch die Grenzen zwischen den Unternehmen. Die (elektronischen) Geschäftsprozesse sind nicht mehr auf ein Unternehmen begrenzt sondern unternehmensübergreifend.

In Abhängigkeit der beteiligten Geschäftspartner kann E-Business in verschiedene Geschäftsmodelle eingeteilt und abgegrenzt werden. Dabei werden grundsätzlich drei Gruppen unterschieden:

- Business (B): Unternehmen
- Consumer (C): Konsument
- Administration (A): Öffentliche Verwaltung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Geschäftsmodelle im E-Business (in Anlehnung an [HeSa99, 23])

Für den Begriff Consumer wird synonym auch der Begriff Customer (Kunde) verwendet. Aus diesen drei Gruppen lassen sich sechs mögliche Beziehungen für einen Geschäftsprozess bilden (Vgl. Abbildung 2.3):

- Business to Business (B2B): „Business to Business heißt ein Bereich von Anwendungen, welche den Geschäftsverkehr zwischen Geschäftspartnern entlang der Wertschöpfungskette betreffen [Schö01, 68].“ Dabei handelt es sich um die älteste Form des E-Business. Diese Art von Geschäftsbeziehungen ist oft langfristig angelegt [Merz99, 20]. Sie besitzt das größte Geschäftsvolumen im Vergleich zu den restlichen Formen. Zum B2B-Bereich gehört die Steigerung der Effizienz der elektronischen Kommunikation durch die Integration bestehender Systeme bei Lieferanten und Kunden [HoZi00, 47]. Ein typischer elektronischer Marktplatz im B2B-Bereich ist der der Zulieferer in der Automobilindustrie
- Business to Consumer (B2C): Ein Unternehmen (Verkäufer) und ein Konsument (Käufer) schließen ein Geschäft elektronisch ab. Der Hauptverband des Deutschen Einzelhandels schätzt für 2005 einen E-Commerce-Umsatz von 14,5 Milliarden Euro in Deutschland [HDE04]. Als Beispiel dient der Online-Händler amazon.com
- Business to Administration (B2A): Elektronischer Handel zwischen Staat und Unternehmen. Ein Beispiel ist die elektronische Abhandlung von öffentlichen Ausschreibungen
- Administration to Administration (A2A): Zwei verschiedene Staaten oder zwei staatliche Institutionen arbeiten auf elektronischem Weg zusammen. Dieses Geschäftsmodell hat meist keinen kommerziellen Charakter. Beispiele sind die Zusammenarbeit von Zollbehörden verschiedener Länder oder der elektronische Austausch von Daten der Meldeämter
- Administration to Consumer (A2C): Der Handel zwischen Staat und Bürger. Die Begriffe E-Administration oder E-Government werden synonym verwendet. Dieser Bereich ermöglicht es dem Bürger, beispielsweise Anträge elektronisch zu stellen oder eine Steuererklärung elektronisch einzureichen
- Consumer to Consumer (C2C): C2C bedeutet schließlich den Handel zwischen Konsumenten. Den größten Bereich in diesem Geschäftsmodell machen die Online-Auktionen aus. Als Beispiel kann das erfolgreiche Online-Auktionshaus ebay genannt werden.

2.1.3 Enterprise Application Integration

Aktuell werden in der Literatur unter dem Schlagwort Enterprise Application Integration (EAI) die Gestaltungsmöglichkeiten zur Integration von Anwendungssystemen diskutiert [Holt03, 45]. Ähnlich wie bei dem Begriff E-Business ist auch der Begriff Enterprise Application Integration nicht eindeutig definiert. Das erfordert einige Begriffsabgrenzungen.

Allgemein wird der Begriff der Integration sehr breit verwendet und bedeutet die „Wiederherstellung des Ganzen“ [Dude01, 839]. So bedeutet er beispielsweise in der Mathematik ein Verfahren zur Berechnung von Flächen (Integralrechnung). In der Wirtschaftsinformatik ist die Integration ein zentraler Begriff. Er bedeutet die Herstellung des Ganzen durch die Integration betrieblicher Anwendungssysteme mit ihren Schnittstellen. Das „Ganze“ ist in diesem Zusammenhang die betriebliche Realität. [Kaib02, 10] Eine Motivation zur Integration kann die Hoffnung sein, der Nutzen des Ganzen sei höher als die Summe der Nutzen seiner Teile. Anwendungssysteme sind Software- und Hardwaresysteme, die die Automatisierung informationsverarbeitender Aufgaben unterstützen. Ziel ist die Lenkung betrieblicher Prozesse oder die Erstellung von Informationsdienstleistungen. [Kaib02, 11]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Enterprise Application Integration (in Anlehnung an [Kell02, 7])

Die folgenden Definitionen zeigen exemplarisch die vielfältigen Beschreibungen des EAI-Begriffs.

„EAI is the unrestricted sharing of data and business processes among any connected applications or data sources in the enterprise” [Lint00, 39].

EAI ist die „Integration von Anwendungen über unterschiedliche technische und logische Infrastrukturen hinweg [BuCP01, 9]“. Dabei sind die Techniken und Prozesse von individueller Software und auch von Standardsoftware so miteinander kombinierbar, „dass Geschäftsprozessdaten im Format und Zusammenhang jederzeit ausgetauscht werden können, ohne dass dabei die Bedeutung der Daten verändert wird bzw. verloren geht [BuCP01, 9]“.

Nach Keller geht es bei EAI darum, heterogene Anwendungen eines Unternehmens so zu integrieren, dass sie sich möglichst so verhalten, als wären sie von Anfang an für den Zweck entworfen worden, die Geschäftsprozesse eines Unternehmens zu unterstützen [Kell02, 5]. „EAI (Enterprise Application Integration) beschleunigt und rationalisiert die Informationsflüsse innerhalb eines Unternehmens. […] Damit zielt EAI auf die Rationalisierung innerhalb des Unternehmens. […] Das Akronym EAI ist zu einem Sammelbegriff für viele Kategorien von Softwarelösungen geworden, die sämtlich etwas mit der Integration heterogener Lösungen innerhalb eines Unternehmens zu tun haben [Kell02, 7]“. Die Beziehungen zwischen den zu integrierenden Aufgaben und die dabei betriebenen Anwendungssysteme sind im Falle von EAI innerbetrieblich [MaSc02, 171]. EAI wird auch als „Rückgrat der unternehmensweiten Informationsverarbeitung“ [BuCP01, 11] bezeichnet.

Die in der Literatur anzutreffenden Definitionen zielen hauptsächlich auf eine Softwareschicht ab, die eine Kommunikation verschiedener Anwendungen ermöglicht [ScWi02, 8]. Kaib sieht dagegen in EAI einen umfassenden Ansatz für die operative Integration von Geschäftsprozessen durch die kontrollierte, flexible und rasch ausbaubare Integration multipler Anwendungen [Kaib02, 79]. EAI ist somit kein Produkt sondern vielmehr ein Ansatz, eine Kombination aus Architektur, Technologie und Methodik.

Je nach Ausrichtung kann nach vertikaler oder horizontaler Integration unterschieden werden. Ein horizontal integriertes Informationssystem bezieht sich vor allem auf die Verbindung der Teilsysteme in der betrieblichen Wertschöpfungskette [Kaib02, 18]. Es ermöglicht Informationen auf gleicher Ebene entlang eines Geschäftsprozesses über verschiedene funktional gegliederte Bereiche auszutauschen. Dies ermöglicht beispielsweise auf der operativen Ebene die Integration vom Kundenangebot über die Beschaffung und Produktion bis hin zum Vertrieb. [Schö01, 15] Die vertikale Integration unterstützt hingegen in erster Linie die Datenversorgung der Planungs- und Kontrollsysteme aus dem Administrations- und Dispositionssystemen heraus [Kaib02, 19]. Ein vertikal integriertes System erlaubt, Informationen zwischen verschiedenen Ebenen auszutauschen [Schö01, 15]. Dabei ist der Informationsfluss von unteren zu oberen Ebenen größer als umgekehrt. „Grössere Daten und Informationsmengen werden verdichtet, um sie für die jeweils oberen Ebenen in passender und übersichtlicher Form aufzubereiten.“ [Schö01, 16]

Ein weiteres Unterscheidungsmerkmal der Integration von betrieblichen Anwendungssystemen liegt im Zeitpunkt der Integration. Findet die Integration durch die vollständige Neuentwicklung eines umfassenden Anwendungssystems oder durch die Entwicklung integrationsfähiger Einzelkomponenten (Componentware) statt, spricht man von einer Ex-ante-Integration. Die Integration findet zeitlich vor der Implementierung statt. Die Ex-post-Integration meint im Gegensatz dazu die nachträgliche Integration bereits vorhandener Anwendungssysteme. [Kaib02, 20] Diese Arbeit beschäftigt sich im Wesentlichen mit dem Fokus von EAI, der nachträglichen Integration.

2.1.4 Business to Business Application Integration

Bezüglich der Integrationsreichweite kann zwischen der innerbetrieblichen (EAI) und der zwischenbetrieblichen Integration unterschieden werden. Bei der innerbetrieblichen Integration beschränkt sich die Betrachtung auf ein rechtlich selbstständiges Unternehmen, auch wenn mehrere Standorte des Unternehmens betroffen sind [Kaib02, 19]. Die Aspekte der externen Integration werden unter dem Begriff B2B Application Integration (BBAI) diskutiert. Ziel ist es die Unternehmensgrenzen zu überbrücken. [Schu03, 3]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: B2B-E-Commerce (in Anlehnung an [Kell02, 6])

„Die zwischenbetriebliche Integration reicht vom elektronischen Datenaustausch über die Nutzung gemeinsamer Datenbestände und von dem Zusammenfassen und Verlagern gemeinsamer Aufgaben bis hin zur automatischen Abwicklung zwischenbetrieblicher Vorgänge [Kaib02, 20].“ Bei der Business to Business Integration werden die Wertketten von Unternehmen durch Kommunikationstechnik verbunden, wodurch Beschleunigungs- und damit positive Kosteneffekte entstehen [Kell02, 11]. „B2B-E-Commerce rationalisiert den Handel zwischen Unternehmen [Kell02, 6].“ Linthicum definiert BBAI wie folgt: „[B2B Application Integration] is, at its foundation, the mechanism and approaches to allow partner organizations, such as suppliers and consumers, to share information in support of common business events [Lint01, 10].”

Die Idee, Geschäfte zwischen Unternehmen elektronisch abzuwickeln, ist nicht neu. Die ersten Versuche starteten vor mehr als 20 Jahren mit Electronic Data Interchange (EDI) zum elektronischen Austausch von Handelsdokumenten. Gegenwärtig steht die Etablierung semantischer Standards im Mittelpunkt des Interesses. Der erste branchenunabhängige und international gültige Standard war EDIFACT (Electronic Data Interchange for Admninistration, Commerce and Transport). Mit EDIFACT können Inhalte strukturierter Geschäftsdokumente, zum Beispiel eine Rechnung, elektronisch übertragen werden. [Kaib02, 93] Für kleinere und mittelständische Unternehmen war diese Lösung oft zu teuer und zu komplex. Zudem war sie nicht für alle Unternehmen zugänglich. Abhilfe könnte hier die Extensible Markup Language (XML) schaffen. Auf diese Technologie wird im informationstechnischen Abschnitt dieses Kapitels und im Abschnitt 3.4 (Integration mit XML) näher eingegangen.

Das Merkmal von BBAI ist, dass sowohl die Aufgabenbeziehungen als auch die Beziehungen zwischen den Anwendungssystemen überbetrieblich sind. Liegt dagegen eine überbetriebliche Beziehung von Anwendungssystemen ohne Aufgabenbeziehung vor, spricht man von Application Service Providing (ASP). [MaSc02, 172]

2.2 Informationstechnische Grundlagen

Die Geschäftsprozesse der Unternehmen werden durch Informationstechnik unterstützt. Fokus dieser Arbeit ist dabei die Integration verschiedener Informationssysteme. In diesem Abschnitt werden einige wichtige informationstechnische Grundlagen für die Integration von Informationssystemen erläutert.

2.2.1 Integrationsansätze

Die Anforderungen an Integrationswerkzeuge im Bereich B2B, aktuelle und bedeutende Integrationstechnologien, Topologien und eine Architektur von EAI-Lösungen werden in den folgenden Abschnitten dargestellt. An verschiedenen Stellen wird dabei von EAI gesprochen. Die Lösungsansätze und Technologien sind jedoch in der Regel analog auch auf BBAI anwendbar. Integrationsprodukte unterstützen zunehmend sowohl die unternehmensinterne als auch die zwischenbetriebliche Integration von Anwendungssystemen [Kaib02, 211].

2.2.1.1 Anforderungen an Integrationswerkzeuge im B2B-Bereich

Als Anforderungen an erfolgreiche elektronische Kommunikation zwischen Unternehmen können folgende Punkte genannt werden (in Anlehnung an [Merz99, 313; SDLD02, 81]):

- Die Interoperabilität muss die Kommunikation zwischen unterschiedlichen Rechnerplattformen gewährleisten. Unterschiede in der Hardware und Betriebssystemen der beteiligten Partner müssen überbrückt werden
- Als Kohärenz bezeichnet man den inneren oder äußeren Zusammenhang von Informationen. Die Systeme müssen ein standardisiertes Vokabular verwenden
- Flexibilität. Softwaresysteme müssen flexibel an neue Situationen angepasst werden
- Die Skalierbarkeit stellt die Verfügbarkeit auch bei einem hohen Aufkommen von Transaktionen pro Zeiteinheit sicher
- Zuverlässigkeit, Transaktionssicherheit und Fehlerbehandlung. Die Bereitstellung von Kontrolldiensten muss die Überwachung der Kommunikation ermöglichen
- Fähigkeit zur Kombination synchroner und asynchroner Schnittstellen
- Integration heterogener EAI-Ansätze (typisch bei B2B Application Integration)

2.2.1.2 Integrationstechnologien

Integration strebt fachlich begründete Funktionalitäten an. Technische Besonderheiten der zu integrierenden Systeme sollen weitgehend verborgen bleiben. Eine große Bedeutung kommt dabei der Middleware zu. Middleware ist anwendungs­un­abhängig und fungiert als Softwareschicht zwischen betrieblichen Anwendungen und verbirgt deren Komplexität. Sie basiert auf offenen Schnittstellen und Protokollen und stellt Dienste für eine transparente Kommunikation in einem heterogenen und verteilten Umfeld zur Verfügung. [Kaib02, 102] Derzeit sind im Rahmen von EAI-Lösungen folgende Middleware-Technologien im Einsatz [SDLD02, 74]:

- Standardisierte Datenbankzugriffsmechanismen (z. B. ODBC oder JDBC)
- Funktionsaufruforientierte Middleware (Remote Procedure Call, z. B. RPC)
- Komponentenorientierte Middleware (Object Request Broker, z. B. CORBA)
- Nachrichtenorientierte Middleware (Message Broker, z. B. MQ-Series)
- Transaktionsorientierte Middleware

Datenzugriffsorientierte Middleware ermöglicht einen transparenten Zugriff auf heterogene Daten über eine einheitliche Schnittstelle. Somit ist es möglich auf verteilte Datenbanken über eine integrierte Datensicht zuzugreifen. ODBC (Open Database Connectivity) von Microsoft und JDBC (Java Database Connectivity) von JavaSoft sind zwei Beispiele für APIs (Programmschnittstellen), über die auf verschiedene Datenquellen zugegriffen werden kann. Für die Anwendung ist die Datenanbindung weitgehend transparent, sie empfängt die Daten in einer für sie verständlichen Form.

Ein Remote Procedure Call (RPC) ruft aus einer Anwendung heraus eine Funktion einer entfernten Anwendung über ein Netzwerk auf (funktionsorientierte Middleware). Dieser Mechanismus beruht auf dem Client/Server-Modell und ermöglicht eine gemeinsame und transparente Nutzung von Programmfunktionen über Rechnergrenzen hinaus. [Kaib02, 105] Transparent bedeutet in diesem Zusammenhang, dass es für den Entwickler keinen Unterschied zu einem lokalen Prozeduraufruf macht, wenn er eine entfernte Prozedur aufruft [Schm05, 49]. RPCs sind einfach, schnell und effizient. Sie bilden die Grundlage der höher entwickelten Objekt Broker (Object Request Broker). [Kaib02, 105] Mit der Entwicklung objektorientierter Programmiersprachen entstand die Möglichkeit Methoden entfernter Objekte aufzurufen, was zu den Objekt Brokern führte [Schm05, 49]. Zu nennen sind der Standard im Bereich der ORB-Technologie, die Common Object Request Broker Architecture (CORBA) der Object Management Group (OMG), COM+/DCOM (Distributed Component Object Model ) von Microsoft und die Enterprise Java Beans (EJB) von Sun. Die ORB-Technologie unterscheidet sich von RPCs vor allem in der gesteigerten Anzahl und Mächtigkeit der angebotenen Dienste. [Kell02, 87] Diese komponentenorientierte Middleware findet ihren Ursprung in der objektorientierten Softwareentwicklung. Verschiedene Objekte sollen transparent über Netzwerke, Programmiersprachen, Betriebssysteme und Anwendungen hinweg interagieren können.

Nachrichtenorientierte Middleware (MOM) besteht aus der Weitergabe von Nachrichten. Typische Dienste von Produkten aus diesem Bereich sind das Anlegen, Weiterleiten, Ausliefern und Speichern von Nachrichten. Diese Art ist die erste Form von Middleware, deren grundlegende Charakteristik die asynchrone Kommunikation ist [Schm05, 50]. MOM spielt bei EAI-Lösungen eine große Rolle. Die meisten EAI-Lösungen basieren auf MOM-Produkten. Nachrichten sind eine sehr allgemeine Form der Kommunikation und sind daher gut für lose gekoppelte Systeme geeignet. In MOM-Produkten wie z. B. MQ-Series von IBM sind oft schon Vorkehrungen für Transaktionen und Mechanismen gegen den Verlust von Nachrichten enthalten. [Kell02, 86] Anwendungen interagieren, indem sie Nachrichten in eine Warteschlange (Queue) ablegen beziehungsweise aus einer Warteschlange abrufen und verarbeiten. In diesem Fall müssen die Anwendungen nicht kontinuierlich miteinander verbunden sein. [Schm05, 50]

Um kritische Geschäftsprozesse zuverlässig zu unterstützen, spielt die Transaktionssicherheit eine wesentliche Rolle. Eine durchzuführende Transaktion kann entweder erfolgreich abgeschlossen oder fehlerhaft beendet werden. Im letzten Fall wird der Ausgangspunkt wiederhergestellt und die Transaktion muss wiederholt werden. Jede Transaktion muss den ACID-Kriterien genügen. Das ACID-Prinzip beschreibt eine Transaktion durch folgende Eigenschaften: Atomarität, Konsistenz, Isolation und Dauerhaftigkeit. [Kell02, 97] Transaktionsorientierte Middleware gewährleistet die zuverlässige Verarbeitung von Transaktionen und optimiert den Transaktionsdurchsatz [Kaib02, 111].

Auch Application-Server spielen in EAI-Lösungen eine Rolle. Sie sind in erster Linie keine Integrationsprodukte, ihre Backend-Integrationsfähigkeit macht sie aber interessant für EAI-Lösungen [Lint00, 150]. Sie stellen eine Laufzeitumgebung für Anwendungslogik und Mechanismen zur Kopplung von Web-Anwendungen an dahinter liegende Anwendungssysteme bereit [Kaib02, 140]. Als Standard für Application-Server hat sich die Java 2 Plattform, Enterprise Edition (J2EE) von Sun entwickelt.

Microsoft bietet einen Integration-Server BizTalk auf Basis der .NET Plattform an. Hauptaufgabe des BizTalk-Servers ist die auf Nachrichten basierende Kommunikation zwischen den beteiligten Prozessen [Baum05, 10]. Integration-Server stellen Transformations- und Routinefunktionen für ein- und ausgehende Nachrichten bereit [MaSc02, 173]. Um einen universellen Datenaustausch, unabhängig von Rechner- und Anwendungsgrenzen, zu ermöglichen, wird als Nachrichtenformat eine XML- oder eine Textdatei verwendet [Baum05, 10]. Die Lösung von Microsoft verfolgt einen dezentralen Ansatz, verschiedene BizTalk Server kommunizieren dezentral anhand standardisierter Austauschformate. Annähernd alle EAI-Lösungen bieten XML-Schnittstellen. [Holt03, 46]

Neben den oben schon vorgestellten Java-Technologien J2EE und JDBC ist eine Vielzahl von weiteren für Integrationslösungen nützlichen Technologien aus der Java-Welt verfügbar. Remote Method Invocation (RMI) ist das Java-Pendant zu RPCs und erlaubt den Aufruf verteilter Java-Applicationen über ein Netzwerk. Die Java Connector Architecture (JCA) ist eine API zur Integration von heterogenen Anwendungen in die Java-Plattform. Der Java Message Service (JMS) unterstützt das Versenden und Empfangen von Nachrichten (MOM). Java Servlets und Java Server Pages (JSP) unterstützen die Präsentation von Informationen auf dem Client. Die Enterprise Java Beans (EJB) sind hingegen serverseitige Komponenten für die Abbildung von Geschäftslogik.

Auch Web Services werden immer häufiger im EAI-Bereich eingesetzt. Ein Web Service ist ein über ein Netzwerk erreichbarer Dienst, auf dessen Funktionalitäten über Standard-Internettechnologie zugegriffen werden kann. Im Sinne dieser Definition sind bereits Aufrufe von Webseiten, die das Durchsuchen von Inhalten auf Basis von HTTP und HTML ermöglichen, einfachste Web Services. Das Konzept der Web Services bietet jedoch deutlich mehr. Der Nachrichtenaustausch mit anderen Anwendungen erfolgt durch XML-basierte Nachrichten über Standard-Internettechnologien. Dies ermöglicht den plattformunabhängigen Aufruf entfernter Methoden über das Internet. [Schm05, 81] Die Web Service-Technologie bietet Dienstanbietern die Möglichkeit (Netz-) Dienste in Verzeichnissen zur Verfügung zu stellen. Zur Registrierung von Web Services und dem dynamischen Auffinden dient Universal Description, Discovery and Integration (UDDI) als Verzeichnisdienst. Ein Dienstkonsument kann daraufhin aus diesem Verzeichnis eine Dienstbeschreibung in Form eines WSDL-Dokuments (Web Services Description Language) beziehen und den Dienst nutzen. Der Ansatz der Web Services ähnelt sehr dem CORBA-Ansatz. Für CORBA existieren viele unterschiedliche Standards, anstatt der ursprünglich von der OMG angestrebten Konsistenz. Aus diesem Grund bieten die Web Services eine höhere Interoperabilität. [Lang04, 20] Für die Kommunikation zwischen Service-Anbieter und Service-Konsument dient das webbasierte Protokoll SOAP. SOAP definiert Syntax, Semantik und Reihenfolge der Nachrichten zwischen den einzelnen Kommunikationspartnern [Schm05, 37].

2.2.1.3 Topologien von Integrations-Systemen

Die Topologie bezeichnet bei einer EAI-Architektur die Struktur der Verbindungen mehrerer Anwendungen untereinander. Sollen verschiedene Anwendungen miteinander verbunden werden, ist dieses leicht durch Punkt-zu-Punkt-Verbindungen über Schnittstellen realisierbar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6: Punkt-zu-Punkt-Verbindung

Die Benutzung von nicht zentral koordinierten Nachrichtentechniken oder entfernten Methodenaufrufen ermöglicht nur einfache Punkt-zu-Punkt-Verbindungen zwischen zwei Systemen [Schm05, 24], wie sie in Abbildung 2.6 verdeutlicht werden. Nimmt die Anzahl der miteinander zu verbindenden Anwendungen zu, so steigen der Erstellungs- und der Wartungsaufwand für die Schnittstellen stark an [ScWi02, 8]. Punkt-zu-Punkt-Verbindungen und das dadurch entstehende Schnittstellen-Chaos sind oft das Resultat einer unzureichenden Planung von Informationssystem-Architekturen [Kaib02, 68]. Dieser Nachteil traditioneller Integration zeigt den Bedarf nach einer zentral steuernden Instanz, die die Vielzahl von Verbindungen verwaltet und kontrolliert [Schm05, 25]. Eine übergreifende Integrationsschicht geht über einzelne Integrationsprojekte hinaus und verringert die Komplexität des Gesamtsystems. EAI-Lösungen zeichnen sich durch das Vorhandensein einer zentralen Instanz aus, über die möglichst alle Verbindungen hergestellt werden. [Kaib02, 85] Die heute unter dem Begriff Enterprise Application Integration diskutierten Systeme stellen somit eine Weiterentwicklung traditioneller Integrationsansätze dar. Ruh definiert diesen neuen Ansatz als „die Schaffung von betrieblichen Anwendungssystemen durch die Kombination einzelner Anwendungen unter Verwendung einer gemeinsamen Middleware“. [Schm05, 25]

Zentrale Lösungen unterstützen die semantische Integration von Informationssystemen, da die Nutzung zentraler Bibliotheken neben einer syntaktischen Vereinheitlichung auch eine eindeutige Bedeutung der verwendeten Komponenten garantiert [Holt03, 46]. Häufig wird zur Lösung des Problems ein EAI-Hub (auch Hub-and-Spokes genannt; Hub - engl.: Nabe, Knotenpunkt) oder eine Bus-Struktur eingesetzt. Im Fall der Hub-and-Spokes-Technologie bildet ein Server als EAI-Hub das Zentrum, über das die integrierten Anwendungen miteinander verbunden werden. Der Server stellt die EAI-Funktionalität vollständig und redundanzfrei zur Verfügung. [Kaib02, 86] Dadurch verringert sich die Anzahl der Schnittstellen zwischen Anwendungssystemen bei einer Zwei-Wege-Kommunikation von n*(n-1) auf n*2. Der Aufwand für die Erstellung und Wartung der Integration sinkt durch die reduzierte Komplexität des gesamten Systems. [ScWi02, 9] Es wird davon ausgegangen, dass der Aufwand gemessen in Entwicklungs- und Wartungszeit in Abhängigkeit von der Anzahl der Schnittstellen mindestens linear steigt [Holt03, 45].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.7: EAI-Hub und Bus-Struktur

Bei der Bus-Struktur werden die Funktionalitäten auf die verbundenen Funktionseinheiten aufgeteilt und dezentral verwaltet. Die Vorteile dieser Variante liegen in einer höheren Performanz durch dezentrale Einheiten. Nachteile ergeben sich aus einem höheren Verwaltungsaufwand und der möglichen Redundanz von Funktionen. [Kaib02, 87]

2.2.1.4 Architektur von Integrations-Systemen

Der Architektur-Begriff wird in der Wirtschaftsinformatik als die Beschreibung von Strukturen verstanden. „Gegenstand der EAI-Architektur ist die Untermenge aller Informationssysteme des Unternehmens, die über die Verbindung zur zentralen EAI-Instanz Teil der integrierten Lösung ist.“ [Kaib02, 84] Das Ergebnis der Integration ist ein globales Integrationskonzept im Sinne einer EAI-Architektur. Eine EAI-Architektur identifiziert die Systemkomponenten, beschreibt die Beziehungen zwischen diesen Komponenten und präsentiert Standards und Richtlinien für das Design einzelner Komponenten. Die Anforderungen an die EAI-Architektur leiten sich aus den Unternehmenszielen ab. [Booz01, 21]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.8: Bausteine einer EAI-Architektur (in Anlehnung an [Booz01, 22])

Der zentrale Bestandteil von EAI-Lösungen ist die Middleware [Kaib02, 102]. Diese kann man als Softwareschicht zur Kommunikation zwischen zwei oder mehreren Anwendungssystemen verstehen. Die Middleware übernimmt dabei die Aufgabe, die Komplexität von Quell- und Zielsystemen zu verbergen (siehe Abschnitt 2.2.1.2 - Integrationstechnologien). Die Kern-Funktionalität der Middleware ist die Überwindung der technischen Heterogenität zwischen verschiedenen Anwendungssystemen [Schm05, 28]. Entscheidend ist dabei, dass die verwendete Middleware die Komplexität der interagierenden Anwendungssysteme vollständig verbirgt [Schm05, 30] und dem Entwickler somit ermöglicht, sich auf die Umsetzung der Anwendungslogik zu konzentrieren [Schm05, 49].

Das Kommunikationsmodell beschreibt den synchronen oder asynchronen Nachrichtenaustausch zwischen den Anwendungen. Die synchrone Kommunikation erfordert, dass der Sender einer Anforderung auf die Antwort warten muss, bevor er intern mit der Verarbeitung fortfahren kann. Während der Bearbeitung ist der Sender blockiert. Bei der asynchronen Kommunikation besteht keine Abhängigkeit von interner Verarbeitung und der Kommunikation bei Sender und Empfänger. Der Sender kann die Bearbeitung sofort nach dem Versenden seiner Nachricht fortführen. [Schm05, 55; Booz01] Das Warten des Senders bei der synchronen Kommunikation ist nötig, weil die sendende Anwendung in diesem Fall die Antwort für die Weiterverarbeitung benötigt [Schm05, 55]. Dies ist z. B. bei dem Aufruf einer Webseite durch einen Web-Browser der Fall. Damit der Web-Browser die gewünschten Informationen darstellen kann, muss er nach dem Aufruf der entsprechenden Webseite auf die Antwort des Webservers warten. Ist keine unmittelbare Reaktion des Kommunikationspartners nötig, kann ein asynchrones Kommunikationsmodell zum Einsatz kommen. Der Vorteil asynchroner Kommunikation besteht darin, dass die Verbindung der Kommunikationspartner nicht verlässlich sein muss und die Systeme zeitlich entkoppelt werden können. [Schm05, 58]

Die Integrationsmethode beschreibt den Ansatz, wie eine Anforderung oder Nachricht von einem Sender zu einem Empfänger übertragen wird. Dabei können zwei verschiedene Methoden unterschieden werden. Beim „Messaging“ erstellt der Sender eine Nachricht, die alle zur Ausführung der aufgerufenen Aktion benötigten Daten und Kontrollinformationen enthält. [Booz01] In diesem Fall enthält die vom Sender erzeugte Nachricht also sowohl Informationen über die angeforderte Aktion als auch die notwendigen Daten, um die Aktion auszuführen [Schm05, 61]. Die Nachrichten sind anwendungsunabhängig, was zu einer hohen Flexibilität führt. Die Verbindungen von Nachrichten zu Anwendungen sind jedoch nicht transparent. [Booz01] Der Entwickler kann nicht immer problemlos feststellen, welche Anwendung welche Nachrichten verarbeiten kann [Schm05, 62]. Die Methode erfordert also eine gute Dokumentation oder spezielle Dienste, die diese Aufgabe übernehmen. Im anderen Fall kommuniziert der Sender alle benötigten Daten über eine anwendungsspezifische Schnittstelle, die genau definiert, welche Methoden von einer anderen Anwendung aufgerufen werden können [Schm05, 63]. Der Vorteil liegt in der Selbsterklärung der Schnittstellen bezüglich der verfügbaren Funktionen [Booz01]. Die Schnittstelle ist im Gegensatz zu einer Nachricht fest mit der Anwendung assoziiert und klar sichtbar [Schm05, 63]. Veränderungen und Erweiterungen sind dagegen problematisch [Booz01].

Die Dienste sind schließlich funktionale Erweiterungen eine EAI-Architektur. Sie unterstützen beispielsweise die Middleware oder die Kommunikationsfähigkeit, speichern Metadaten, bieten Versionsmanagement von Objekten und Nachrichten, stellen Authentisierungs- und Autorisationsmechanismen bereit, transformieren Informationen, sichern die Konsistenz von Daten und unterstützen den Workflow. [Booz01] EAI-Lösungen implementieren diese Dienste meist in unterschiedlichem Ausmaß und in Individuallösungen, die keinen gängigen Technologiestandards folgen. Heutige EAI-Produkte sind zumeist komplexe und proprietäre Insellösungen. Dieser Umstand führt dazu, dass eine Interoperabilität zwischen EAI-Systemen verschiedener Hersteller meist nicht gegeben ist oder nur aufwändig realisiert werden kann. [Schm05, 30] Außerdem ist dies vor dem Hintergrund der zwischenbetrieblichen Integration kritisch zu sehen.

Während die klassische EAI-Architektur durch eine zentrale EAI-Instanz geprägt ist, setzen Service-orientierte Architekturen auf verteilte Dienste (Services). Unter dem Schlagwort Service Oriented Architecture (SOA) wird derzeit ein Architekturkonzept diskutiert, das das Potenzial hat Geschäftsziele und Informationstechnik in Einklang zu bringen. Ein Service modelliert dabei ein Stück Geschäftslogik und kann von Anwendungen über seine fachlich definierte Schnittstelle aufgerufen werden. Im Vordergrund steht die fachliche Beschreibung der Services. Wie diese im Inneren realisiert sind, bleibt verborgen. Ein Repository speichert alle grundlegenden Informationen über die verfügbaren Services. Aufgabe von SOA ist es, „Anwendungen zu entkoppeln und von ihrer heterogenen Hard- und Software zu abstrahieren.“ [WeBe05, 13] Komplexe Geschäftsprozesse lassen sich durch eine Aneinanderreihung von Aufrufen voneinander unabhängiger, lose gekoppelter Services realisieren. Der Mehrwert von SOA gegenüber proprietären Lösungsansätzen (DCOM, CORBA, J2EE) liegt in einer effektiven Steuerung der auf der SOA aufbauenden Geschäftsprozesse durch die Entkopplung von Anwendungen und Geschäftsprozessen. [Egel05, 20] Insbesondere global operierende Unternehmen oder solche mit weit verstreuten Mitarbeitern profitieren von Service-orientierten Lösungen. Das Netz erscheint als eine für alle überall verfügbare Einrichtung für Services. [Bieb04, 19]

Die Integration von Anwendungen und die Interaktion, Kommunikation, Ablaufkontrolle und Orchestrierung (Aneinanderreihung) von Services übernimmt der für eine SOA zentrale Enterprise Service Bus (ESB) [WeBe05, 13]. Er stellt - selbst als ein verteiltes System - eine Infrastruktur zur Verbindung von Anwendungen und Services bereit. Auf einem ESB sollten die Anwendungen nicht direkt kommunizieren. Anwendungsentwickler können sich auf fachliche Inhalte konzentrieren, während der ESB u. a. die Integrationskomponente bereitstellt. [Dege05, 17] In Verbindung mit einer SOA werden häufig die in Abschnitt 2.2.1.2 beschriebenen Web-Services und XML-Technologien (siehe folgenden Abschnitt) verwendet.

In heutigen EAI-Lösungen spiegeln sich diese neuen Technologien bisher nur in Ansätzen wider. Zahlreiche Arbeiten beschreiben zwar die Möglichkeiten Service-orientierter Architekturen innerhalb des EAI-Bereichs, verweisen allerdings auch auf viele offene Probleme in den Bereichen der Prozesssteuerung, Transaktionsüberwachung, Sicherheit und der Kapselung mit Benutzeroberflächen. [Schm05, 33]

2.2.2 XML-Technologien

Die XML-Technologie hat ein hohes Potenzial im Bereich des Datenaustauschs. Auch im Integrationsprojekt des Praxisteils dieser Arbeit kommt diese Technologie zum Einsatz. Um die Extensible Markup Language (XML) herum gibt es eine Vielzahl peripherer Technologien z. B. zur Beschreibung, der Abfrage und der Transformation von in XML-Notation gespeicherten Daten. In diesem gesonderten Abschnitt werden die wichtigsten XML-Technologien vorgestellt.

2.2.2.1 XML - Extensible Markup Language

XML ist ein vom World Wide Web Consortium (W3C)^[1] verabschiedeter Standard zur Erstellung maschinen- und menschenlesbarer Dokumente in Form einer Baumstruktur. XML definiert die Regeln (Syntax) für den Aufbau solcher Dokumente. Ist ein Dokument syntaktisch korrekt, spricht man von einem wohlgeformten Dokument. XML ist von der Generalized Markup Language (SGML) abgeleitet und ist zu SGML konform, aber wesentlich weniger komplex und dient der Notation der Syntax von Metasprachen: XML ist „eine textbasierte Meta-Auszeichnungssprache für Beschreibung, Austausch, Darstellung und Manipulation von strukturierten Daten“ [Holt03, 42]. Es existiert bereits eine Vielzahl von Metasprachen, die sich nicht auf die Darstellung von Dokumenten im World Wide Web (WWW) beschränken. Der Einsatz von XML geht über das WWW hinaus. XML kann als Basistechnologie für offene Datenformate und den einfachen, plattform- und anwendungsübergreifenden Datenaustausch eingesetzt werden. [FrSu00a, 3]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.9: Wohlgeformtes XML-Dokument

Erst wenn die XML-Datei korrekt ist und erfolgreich „geparst“ werden konnte, kann die XML-Datei angezeigt oder weiterverarbeitet werden. Ein XML-Parser übersetzt den Text der XML-Datei in eine neue Struktur, z. B. in einen Syntaxbaum, der die Elementen und ihre Hierarchie abbildet. Es gibt zwei verschiedene Modi in Bezug auf XML-Parser: SAX (Simple API for XML) und DOM (Document Object Model). Der SAX-Modus ist ein schnelles und einfaches Verfahren zum Parsen, bei dem eine nachträgliche Manipulation der XML-Datei nicht möglich ist. Im DOM-Modus wird aus der XML-Datei hingegen ein Dokumentenbaum erstellt, über den der Zugriff auf alle XML-Elemente und deren Inhalt auch nach dem Parsen möglich ist. [Seeb04, 39]

2.2.2.2 DTD und XML Schema

Bei wohlgeformten XML-Dokumenten definiert der Parser ein XML-Element erst dann, wenn er auf eines stößt. Mit einer DTD (Document Type Definition) kann ein Dokument näher beschrieben werden. In der DTD werden definierte Elemente und deren Attribute festgelegt und der formale Aufbau der Dokument-Instanz beschrieben. [FrSu00a, 18] Die DTD ist selbst nicht mit der XML-Syntax konform und muss in einer eigenen Sprache geschrieben werden. Zudem kann eine DTD nicht sehr strikt beschreiben, wie eine XML-Datei aussehen darf. Abhilfe schafft hier das erheblich erweiterte XML-Schema. XML-Schemas beschreiben formal syntaktische Anforderungen an XML-Dokumente und sind selber in XML formuliert [Holt03, 43]. XML-Schema ermöglicht die Beschreibung beliebiger Datenstrukturen [Klev04, 19], bietet auch für komplexe Anwendungen geeignete Konstruktionen zur Entwicklung komplexer Datenstrukturen und gestattet einen komponentenorientierten Aufbau von Schema-Dokumenten [SkWi04, 12]. Ein XML-Dokument wird als gültig bezeichnet, wenn es den Regeln seiner DTD oder seinem XML-Schema entspricht. Sowohl DTD als auch XML-Schema sind Empfehlungen des W3C.

2.2.2.3 XPath

Die Anfragesprachen XML Path Language (XPath) wurde ebenfalls vom W3C entwickelt. XPath liegt in Version 2.0 als Arbeitsentwurf vor. Die Sprache dient dazu Teile eines XML-Dokumentes zu adressieren und wird in beherbergenden Sprachen wie XSLT und XQuery eingesetzt. Bei XPath handelt es sich nicht um eine XML-Anwendung, d. h. XPath wird nicht in der XML-Syntax beschrieben. Es handelt sich um eine Pfadbeschreibungssprache, deren Aufgabe die Beschreibung von Teilen von XML-Dokumenten ist. [Bong04, 239] Der Ausdruck institutionen/datensatz/name adressiert die Textknoten innerhalb aller Elemente mit der Bezeichnung name im obigen Beispiel.

2.2.2.4 XSLT – Extensible Stylesheet Language Transformation

XSLT ist eine weitere XML-Technologie. Der Standard wird vom W3C verabschiedet und liegt als Arbeitsentwurf in der Version 2.0 vor. XSLT dient der Transformation der Struktur eines XML-Dokuments in eine andere Struktur. [HeSe, 22; Holt03, 44] Die Transformationsregeln werden in einem XSLT-Stylesheet, welches wiederum selbst ein XML-Dokument ist, abgelegt. Für den Austausch von Informationen im XML-Format, wie es im B2B-Bereich erforderlich ist, müssen XML-Quellformate oft in anders strukturierte Zielformate überführt werden. [Bong04, 25]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.10: XSL-Transformation (in Anlehnung an [Bong04, 28])

Für die Transformation selbst muss ein XSLT-Prozessor eingesetzt werden, welcher die XSLT-Stylesheets interpretiert und auf ein XML-Dokument anwendet. Eine weitere mit XSLT verwandte Sprache ist XSL-FO (XSL Formatting Objects). XSL-FO dient der Beschreibung eines Dokuments mit Formatierungsanweisungen und Stilangaben.

[...]

---

^[1] Verweise zu Empfehlungen und Arbeitsentwürfen des W3C zu den angesprochenen XML-Technologien befinden sich im Quellenverzeichnis unter Online-Ressourcen.