2. Abgrenzung Enterprise Application Integration

Das primäre Ziel einer Enterprise Application Integration, folgend EAI genannt, ist die Verknüpfung existierender und neuer Applikationen in einer heterogenen IT-Landschaft. Diese Verknüpfung wird auf der Basis gemeinsamer Daten, Funktionen oder auch Geschäftsprozesse realisiert. So wird ein Datenaustausch zwischen den Applikationen ohne Medienbruch ermöglicht. Ein Integrationsserver stellt dabei ein Software-Paket, also ein EAI-Produkt, zur Realisierung einer beschriebenen Komponentenverknüpfung dar.

Die möglichen Formen einer Enterprise Integration unterscheiden sich in Bezug auf die Reichweite der zu realisierenden Geschäftsprozesse:

A2A (Application to Application) – der Geschäftsprozess wird innerhalb des Unternehmens oder der Organisation realisiert,

B2B (Business to Business) – der Geschäftsprozess wird zwischen verschiedenen Unternehmen bzw. Organisationen umgesetzt, beispielsweise über das Internet,

B2C (Business to Customer) – in dieser Form einer Integration wird der Endkunde in den Geschäftsprozess integriert, beispielsweise ein browserbasierter Webclient.

2.1 EAI Integrationsarten

Die Integration innerhalb eines Systems wird in verschiedene Arten der Integration unterteilt:

Innerhalb einer Datenintegration nutzen Anwendungen denselben Datenbestand und tauschen Daten über ein festgelegtes Format aus. Eine beispielhafte Umsetzung einer Datenintegration wäre eine Schnittstelle für XML oder CVS.

Eine Dialog- bzw. GUI-Integration ermöglicht durch den Einsatz der Web-Technologie eine funktionale Trennung von Benutzereingaben sowie eine Zusammenfassung der Daten in Frames. Eine beispielhafte Umsetzung einer Dialogintegration wäre die Realisierung eines Portals mit einem Portlet für Suchfunktionalität und einem weiteren Portlet für einen Blog auf einer Website.

Bei einer Funktionsintegration stellen die verschiedenen Anwendungen ein API (Application Programming Interface) zur Verfügung. Somit kann eine Anwendung die Funktion einer anderen Anwendung ausführen. Diese Art der Integration ist häufig, aber nicht zwingend, synchroner Natur, da diese auf Interaktion zwischen anfragendem Client und antwortendem Server stattfindet.

Eine Komponentenintegration stellt eine Erweiterung einer Funktionsintegration dar. Diese findet bei großen Applikationen Anwendung, wobei die Komponenten eine Bündelung von Funktionen darstellen, mit anderen Worten, die verteilte Funktionalität ist in unterschiedlichen Adressräumen (auf verschiedenen Servern) lokalisiert. Eine solche Integration kann beispielsweise auf Basis von COM/DCOM, CORBA oder EJB-Containern (J2EE) realisiert werden. Je nach Komplexität kann dies mittels eines einfachen Plug-ins, eines Integrationsservers (verwaltet alle Daten und Funktionsaufrufe, Verbindung über Scriptsprache) oder eines Containers umgesetzt werden. Eine beispielhafte Umsetzung einer Komponentenintegration wäre eine J2EE-Architektur mit EJB-Containern für die Datenverarbeitung und einem JSP-Container für die Dateneingabe/Oberfläche (verwenden EJB-Methoden).

Folgende Abbildung verdeutlicht die möglichen Technologien zur Umsetzung einer erweiterten Funktionsintegration:

Abbildung 1: Erweiterte Funktionsintegration

Quelle: in Anlehnung an [Fletscher/Waterhouse], S.43

 RMI (Remote Method Invocation) des Herstellers SUN ist eine Art Java-RPC Mechanismus, um mit entfernten Objekten zu kommunizieren und deren Methoden aufzurufen (siehe J2EE) und nutzt keine nachrichtenbasierte Kommunikation, sondern direkte Verbindungen zur Client/Server-Kommunikation,

 CORBA (Common Object Request Broker Architecture) des Herstellers OMG ist ein Framework für verteilte Software-Komponenten für unterschiedliche Programmiersprachen (siehe CORBA) und nutzt einen nachrichtenbasierten Message Broker,

 DCOM (Distributed Component Object Model) des Herstellers Microsoft macht COM-Objekte über das Netz zugänglich (siehe .NET), unter Verwendung eines binären Protokolls über TCP/IP oder SOAP,

 RPC (Remote Procedure Call) ermöglicht entfernte Methodenaufrufe innerhalb eines Netzwerks,

 Web-Services unter Verwendung von SOAP, RPC-XML oder REST (im weitesten Sinne, konkrete Untersuchung folgt in folgenden Kapiteln) können einen

nachrichtenbasierten Enterprise Service Bus, nachfolgend ESB genannt, nutzen.

Die letzte vorgestellte Art einer Integration ist die Prozessintegration. In diesem Fall durchläuft ein Prozess alle notwendigen Applikationen, die von einer Prozesssteuerung aufgerufen werden. Dabei werden Teilprozesse so gesteuert, dass die Daten und der Status des übergeordneten Prozesses an die nachfolgende Applikation weitergegeben werden. Die Steuerung wird von einer Zwischenschicht (beispielsweise einem ESB), nachfolgend als Middleware bezeichnet, übernommen, die Daten und Ablauf standardisiert und kontrolliert. Folgende Abbildung verdeutlicht das Konzept einer Prozessintegration innerhalb einer verteilten Umgebung[2]:

Abbildung 2: Prozessintegration

Quelle: in Anlehnung an [Fletscher/Waterhouse], S.44

Kapitel 5.11 beschreibt die Aspekte der Umsetzung einer Prozessintegration innerhalb einer dienstorientierten Architektur detailliert.

2.2 EAI Architekturen

Das folgende Kapitel erläutert die geläufigsten Architekturtechnologien Point-to-Point, Hub & Spoke, Bus-oriented sowie Distributed Objects.

2.2.1 Point-to-Point

Diese Form der Architektur unterscheidet nicht zwischen Client und Server, da die beteiligten Applikationen direkt miteinander verbunden werden, um (auch wechselseitig) auf benötigte Daten zuzugreifen. Unidirektionale und bidirektionale Schnittstellen werden häufig auf Basis von XML-Dokumenten, die manuell ausgetauscht werden, implementiert. Resultierend ergibt sich ab einem gewissen Grad an Komplexität des Systems eine hohe Anzahl an zu realisierenden Schnittstellen, deren Wartungsaufwand einen eindeutigen Nachteil darstellt.

2.2.2 Hub & Spoke

Das zentrale Element dieser Architektur ist ein Message Broker – ein Hub umgeben von Speichen (Spoke) -, der die Kommunikation über Schnittstellen zwischen Message Broker und der Anwendung innerhalb des Systems verwaltet. Der Implementierungsaufwand ist für den Grad an Flexibilität des Systems überschaubar. Die Anzahl der Schnittstellen entspricht der Anzahl an beteiligten Anwendungen innerhalb des Systems. Als Nachteil gilt der so genannte Flaschenhalseffekt – die Leistungsfähigkeit des Systems ist abhängig vom Server. Diese Art der Architektur ist in der Unternehmenswelt weit verbreitet und wird in der Literatur oft als Best Practice bezeichnet.

2.2.3 Bus-oriented

Ein Bus stellt über Schnittstellen (zwischen Anwendungen und Bus) die zentrale Verbindung zwischen den beteiligten Anwendungen eines Systems dar. Hier werden durch Master/Slave-Kategorisierungen der Teilnehmer Daten und Funktionen ausgetauscht. Dies ermöglicht die Auflösung komplexer Strukturen sowie eine effiziente Lastenverteilung. Auch hier entspricht die Anzahl der Schnittstellen der Anzahl an beteiligten Anwendungen innerhalb des Systems.[3]

2.2.4 Distributed Objects

Diese Form der Architektur im weitesten Sinne kennt kein zentrales Element, da autonome Objekte dezentral über das System verteilt werden. Diese werden ebenso autonom über Schnittstellen angesprochen. Hierzu kann eine komponentenorientierte oder nachrichtenorientierte Zwischenschicht (Middleware) verwendet werden. Komponenten-orientierte Middleware stellt ein erweitertes RPC-Konzept dar und ermöglicht den Datenaustausch mittels synchroner Kommunikation über standardisierte Schnittstellen und Protokolle. Nachrichtenorientierte Middleware stellt weniger eine Anwendungsplattform dar, sondern tauscht Daten auf Basis von Nachrichten (Datenfolge, die von Anwendung gelesen wird) aus.

Verteilte Architekturen können grob betrachtet (Aspekt der Dienstverzeichnisse mit Schnittstellenbeschreibungen nicht betrachtet) als erste Realisierungen einer SOA betrachtet werden.[4]

2.3 Technologien einer EAI

Im folgenden Kapitel werden die möglichen Technologien zur Umsetzung einer EAI-Integration, und damit einer verteilten Architektur, vorgestellt. Die einzelnen Ausprägungen der Eigenschaften einer Technologie wie...