Unter der Bezeichnung EAI werden Ansätze zur Schaffung einer einheitlichen Anwendungsarchitektur unter Einbezug von heterogenen Systemen entwickelt. EAI Produkte ist Software, die verschiedene Anwendungen eines Unternehmens integriert. Der Begriff EAI ist dabei geprägt durch die Integration heterogener
Anwendungen und die damit mögliche Kopplung von einzelnen Prozessen zu komplexen Geschäftsprozessen. EAI wird also dazu eingesetzt, um aus einer heterogenen Systemlandschaft ein verteiltes System darzustellen. Dieses verteilte System soll als Ergebnis so ausgelegt werden, dass die Kommunikation der
einzelnen Anwendungen über eine oder zumindest wenige Schnittstellen erfolgt.
[...]
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
1. Enterprise Application Integration (EAI)
1.1. Definition
1.2. Historie von Architekturen
1.3. Ziele von
2. Ansätze von
2.1. Integrationsmodelle
2.2. Vorteile
2.2.1. Vorteile für den Anwender
2.2.2. Technische Vorteile
2.3. Risiken/Nachteile
3. Ausblick
Literaturverzeichnis
Abbildungsverzeichnis
Abbildung 1: Entwicklung von Architekturen betrieblicher Informationssysteme
Abbildung 2: Die drei Ebenen der horizontalen Integration
Abbildung 3: Integrationsmodell - Datenbankintegration
Abbildung 4: Integrationsmodell - Applikationsintegration
Abbildung 5: Integrationsmodell - Präsentationsintegration
Tabellenverzeichnis
Tabelle 1: Architekturebenen betrieblicher Informationssysteme
Tabelle 2: Vorteile von EAI aus Sicht des Anwenders
Tabelle 3: Technische Vorteile von EAI
Tabelle 4: Nachteile und Risiken von EAI
1. Enterprise Application Integration (EAI)
1.1. Definition
Unter der Bezeichnung EAI werden Ansätze zur Schaffung einer einheitlichen Anwendungsarchitektur unter Einbezug von heterogenen Systemen entwickelt.[1] EAI Produkte ist Software, die verschiedene Anwendungen eines Unternehmens integriert. Der Begriff EAI ist dabei geprägt durch die Integration heterogener Anwendungen und die damit mögliche Kopplung von einzelnen Prozessen zu komplexen Geschäftsprozessen. EAI wird also dazu eingesetzt, um aus einer heterogenen Systemlandschaft ein verteiltes System darzustellen. Dieses verteilte System soll als Ergebnis so ausgelegt werden, dass die Kommunikation der einzelnen Anwendungen über eine oder zumindest wenige Schnittstellen erfolgt.[2]
1.2. Historie von Architekturen
Die Entstehung der heterogenen Unternehmensanwendungen ist in den meisten Fällen historisch gewachsen. So existieren oftmals komplexe Architekturen von IT-Systemen in Unternehmen, die auf Grund der steigenden Anforderungen nach Vernetzung von Prozessen viele Nachteile mit sich bringt. Die Entwicklung von Architekturen betrieblicher Informationssysteme seit Entstehung der Computertechnik zeigt folgende Abbildung:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Entwicklung von Architekturen betrieblicher Informationssysteme[3]
1.3. Ziele von EAI
EAI hat nun das Ziel in den verschiedenen Architekturen von betrieblichen Informationssystemen, die Informationsflüsse zu beschleunigen und zu rationalisieren.[4] Es sollen die unterschiedlichen Anwendungen konsolidiert und koordiniert werden. Damit wird einerseits die Schaffung eines einheitlichen Zugriffs und andererseits eine Konsistenzsicherung der Daten fokussiert.[5] Und mehr noch: EAI soll die Entwicklung neuer Technologien trotzt heterogener Informationssysteme ermöglichen. Dafür werden die existierenden Anwendungen für eine neue Strategie nach ausgerichtet.[6] Um diese Ziele zu erreichen stellt EAI sogenannte Softwarelösungen bereit. Unter eine EAI-Softwarelösung ist ein Sammelbegriff von Lösungen zu verstehen, die sämtlich etwas mit der Integration heterogener Lösungen innerhalb eines Unternehmens zu tun haben. Dabei sind die Lösungen jedoch stark davon abhängig, welche Art von Architektur bzw. Problem in einem Unternehmen gelöst werden soll. Selbst diese Lösungen variieren dann noch stark, obwohl sie alle unter den Begriff EAI-Softwarelösungen fallen.[7]
2. Ansätze von EAI
2.1. Integrationsmodelle
Die angesprochenen Softwarelösungen werden nun unter dem Begriff der Ansätze von EAI weiter vertieft. Doch zuvor auf diese Lösungen eingegangen werden kann, sind die verschiedenen Architekturebenen für betriebliche Informationssysteme zu erklären:
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1: Architekturebenen betrieblicher Informationssysteme[8]
Anhand dieser Festlegung kann die Integrationsthematik anhand von zwei Arten erläutert werden – der horizontale und der vertikale Integration. Die vertikale Integration verbindet einzelne Prozesse und bildet so komplexe Geschäftsprozesse. Dadurch können Prozessbrüche in der Verarbeitung und Entwicklung eliminiert und der Automatisierungsgrad gesteigert werden. Die horizontale Integration hingegen verbindet verschiedene Anwendungssysteme, die bislang getrennt betrachtet wurden. Damit werden Geschäftsabläufe optimiert und neu erschlossen.[9]
Die zuletzt genannte horizontale Integration erfordert eine tiefere Erklärung, denn hier ist das Ziel eine möglichst effektive Unterstützung der übergreifenden Geschäftsprozesse herzuleiten. Das wiederum erfordert eine mehrstufige Integration auf der horizontaler Ebene:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Die drei Ebenen der horizontalen Integration[10]
Die Integration auf der Anwendungsebene wird als Enterprise Integration Application bezeichnet. Alle Integrationen auf dieser Ebene sind auf die Aspekte der Heterogenität, der Autonomie und der Verteilung zurückzuführen. Je nach Grad der Autonomie der integrierten Komponenten, Grad der Heterogenität zwischen Komponenten und der Grad der Verteilung treten unterschiedliche Integrationsmodelle auf:[11]
- Datenbankintegration
- Applikations- / Funktionsintegration
- Präsentationsintegration
Eine Integration auf der Ebene der Datenbanken erfolgt über sogenannte Middle-ware-Technologien[12]. Die Informationssysteme werden bezügliche der zugrundeliegenden Datenbanken direkt integriert. Das erlaubt die Möglichkeit über Datenbank Konnektoren[13] direkt auf die Datenbank zuzugreifen.[14] Weiterhin greifen alle beteiligten Applikationen auf ein einheitliches Datenmodell zu. Damit können Redundanzen vermieden werden, wobei die Semantik jedoch für alle beteiligten Applikationen gleich bleibt. Daraus wird klar, dass bei diesem Konzept der Datenaspekt im Mittelpunkt steht. Das Konzept dient so typischerweise dem gemeinsamen Gebrauch und den Abgleich von redundanten Daten zwischen den verschiedenen Anwendungen. Ein entscheidender Vorteil liegt dabei darin, dass vorhandene Datenbanksysteme nicht modifiziert oder neu implementiert werden müssen.[15] Folgende Abbildung zeigt solch eine Datenbankintegration:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3: Integrationsmodell - Datenbankintegration[16]
Werden Altanwendungen[17] über eine Middleware integriert handelt sich um eine Integration auf der Anwendungsebene (Funktionsintegration). Erfolgt der Zugriff auf die Daten über definierte Schnittstellen, so werden häufig Technologien wie Remote Procedure Call[18] (RPC) oder Remote Method Invocation[19] (RMI) eingesetzt.[20] Dadurch wird vermieden, dass in verschiedenen Altanwendungen identische Funktionen implementiert werden müssen. Zudem werden so Schnittstellen zur Datenübergabe vermieden in den jeweiligen Altanwendungen vermieden. Zusätzlich bietet es die Möglichkeit durch Wiederverwendung und einen flexiblen Austausch der Anwendungsfunktionalitäten die Anwendungslogik optimierend zu beeinflussen. Die Funktionsintegration erlaubt die gemeinsame Nutzung von vorhandenen Funktionalitäten, inklusive der dazugehörenden Integritäts- und Plausibilitätsprüfungen. Diese können sowohl durch andere Systeme genutzt aber auch flexibel zusammengefügt werden. Damit erhöht dieses Integrationsmodell die Flexibilität und Effizienz des Informationssystems im Bezug auf Änderungen der Geschäftsprozesse.[21] Die Abbildung zeigt eine Anbindung von zwei Altanwendungen über eine Middleware:
[...]
[1] Vgl. Stahlknecht et al (2005), S. 328.
[2] Vgl. Keller (2002), S. 9.
[3] In Anlehnung an: Conrad et al (2006), S. 2.
[4] Vgl. Keller (2002), S. 11.
[5] Vgl. Conrad et al (2006), S. 6.
[6] Vgl. Gimpeliovskaja (2005).
[7] Vgl. Keller (2002), ebd. S. 11.
[8] Vgl. Conrad et al (2006), ebd. S. 3f.
[9] Vgl. Conrad et al (2006), S. 4.
[10] In Anlehnung an: Conrad et al (2006), ebd. S. 5.
[11] Vgl. Conrad et al (2006), ebd. S. 17.
[12] Unter Middleware wird eine systemnahe Software verstanden, die als zusätzliche Schicht zwischen Betriebssystem und Anwendungssoftware gelegt wird. Ihr Haupteinsatzgebiet sind heterogene Netze. Der Benutzer hantiert über eine Middleware mit einer einheitlichen Benutzeroberfläche. Vgl. Stahlknecht et al (2005), S. 75f.
[13] Datenbank-Konnektoren sind Technologien wie Java Database Connectivity (JDBC) oder auch
Open Database Connectivity (ODBC).
[14] Vgl. Conrad et al (2006), S. 18.
[15] Vgl. O.V. (2008b).
[16] In Anlehnung an: Conrad et al (2006), S. 18.
[17] Altanwendungen werden häufig auch als sogenannte Legacy Systeme bezeichnet.
[18] RPC = Remote Procedure Call; dient zum Aufruf von entfernten Funktionen eines anderen Adressraumes.
[19] RMI = Remote Method Invocation; dient zum Aufruf entfernter Methoden eines anderen Adressraum.
[20] Vgl. Conrad et al (2006), S. 18.
[21] Vgl. O.V. (2008c).
- Citation du texte
- Heiko Ennen (Auteur), 2008, Enterprise Application Integration, Munich, GRIN Verlag, https://www.grin.com/document/117180
-
-
-
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X.