Wer sich für EAI interessiert, verfolgt damit normalerweise eine ganze Reihe von strategischen Einzelzielen (siehe Tabelle). Diese in den meist modular aufgebauten EAI-Produkten wiederzufinden ist allerdings gar nicht so leicht. Ein abstraktes logisches Referenzmodell in Form eines generischen Integrationsbusses kann jedoch helfen, die Wünsche systematisch in eine zunächst produktunabhängige Architektur umzusetzen. Von ihrem Design lassen sich dann systemnahe Aspekte ableiten und Produkte auswählen.
Solch ein Integrationsbus setzt sich aus definierten Funktionalitäten und Komponenten zusammen. Sind diese geklärt, kann der Anwender im zweiten Schritt versuchen, anhand dieses Anwendungsprofils marktgängige EAI-Lösungen durch individuelle Auswahlkriterien besser zu beurteilen. Dies ist umso nützlicher, als viele Produkte sich mittlerweile technisch stark ähneln, obwohl es natürlich im Einzelnen immer noch spezielle Features und Eigenheiten geben kann, die vielleicht genau die Anforderungen eines Unternehmens abdecken.
Wie sieht nun ein generischer EAI-Bus in der Praxis aus? Er besteht aus der Summe der Komponenten, wie sie in Form konkreter Softwaretechnologien verfügbar sind. Diese Technologien werden zu logischen Komponenten des Integrationsbusses zusammengefasst, die damit den Werkzeugkasten zum Aufbau einer EAI-Architektur bilden. So lässt sich als erstes ein Middleware-Modul identifizieren. Dieses stellt die Verbindungseinheit zwischen den Anwendungssystemen dar und enthält sämtliche Komponenten, die zum Transport und zur Transformation der Daten erforderlich sind.
Die technologische Middleware-Schicht besteht aus Transportmechanismen wie Message-Oriented-Middleware (MOM) oder Komponententechnologien (Corba, COM oder EJB) und unterstützt die notwendigen Kommunikationsformen (synchron, asynchron) und Kopplungsarten (eng, lose). Darauf aufbauend setzt eine intelligente Middleware oder auch Solution-Oriented-Middleware an, welche die Metadaten-basierenden Funktionen wie Transformation, Routing und Anreicherung der Daten in Form eines Message Brokers bereitstellt.
Die Anbindung der Systeme an den Integrationsbus erfolgt über Adapter, die das oder die API(s) der jeweiligen Systeme kapseln und zentral integrieren. Die Typen der Adapter bemessen sich nach ihrer jeweiligen Leistungsfähigkeit, die wiederum von den Möglichkeiten der integrierten Systeme abhängt. Die Palette der Adapter-Typen reicht von komplexen Standardadaptern für ERP-, CRM- und Shop-Systeme (zum Beispiel SAP, Siebel oder Commerce One) über Systemadapter für Datenbanken, File-Systeme oder Protokolle bis hin zu eigenentwickelten Adaptern mittels eines SDKs (Software Development Kit). Entscheidend für den Adapter ist das Zusammenspiel mit dem Middleware-Modul, da ein kompatibles Transportmedium verwendet und das gleiche interne Nachrichtenformat "gesprochen" werden muss. Ein leistungsfähiger Adapter für SAP R/3 oder Siebel Sales ist beispielsweise in der Lage, die Business-Objekte aus dem vorhandenen Repository in das zentrale Repository des eingesetzten Message Broker zu importieren. Dadurch wird Integration per Drag & Drop zur Realität.
Prozessmodul als ZusatzDas Prozessmodul stellt die optionale Endausbaustufe des Integrationsbusses dar und ermöglicht eine Abbildung und Steuerung von komplexen Geschäftsprozessen über die verschiedenen Systeme hinweg. Aufbauend auf den Adaptern und dem Middleware-Modul lässt sich die Ablauflogik innerhalb der identifizierten Geschäftsprozesse und Workflows definieren. Dabei werden sämtliche involvierten Regeln und Datentransformationen ebenso wie mögliche Benutzerinteraktionen zusammenfassend integriert. Dadurch wird eine saubere Trennung der Geschäftslogik innerhalb der Systeme von dem eigentlichen Geschäftsprozess ermöglicht. Prozessmodule erweitern somit die Objekt- und Datenebene der Anwendungssysteme um das Wissen über den Geschäftsablauf und ermöglichen damit eine maximale Integrationstiefe.
Das integrierende Medium zwischen Adapter, Middleware-Modul und Prozess-Modul bildet ein zentrales Repository, das sämtliche Metadaten der Integrationsszenarien enthält. Dazu gehören Datenformate, Mappings, Routing-Tabellen für Publish-and-Subscribe sowie Regeln für Transformationen und Ablauflogik. Mit diesem letzten Baustein sind alle Bestandteile des EAI-Referenzmodells benannt. Produkte können nun mit ihm verglichen werden.
*Thomas Reimer ist Leiter des EAI-Competence Centers bei der Resco GmbH in Hamburg.
Warum EAI?Die Gründe für Integration sind vielschichtig:
-Automatisierung und Optimierung von Geschäftsprozessen zur Steigerung ihrer Transparenz, Geschwindigkeit und Effizienz;
-Realisierung von komplexen E-Business-Szenarien im B-to-C-und B-to-B-Umfeld mit anwendungsübergreifenden Transaktionen (Stichwort "straight through processing");
-Integration von ERP-Systemen wie SAP oder Peoplesoft zur integrativen Öffnung von Anwendungskomponenten (beispielsweise Bestandsführungssysteme);
-Reduktion der Schnittstellenkomplexität zur Kosteneinsparung und Beschleunigung von Entwicklungsprozessen innerhalb der IT;
-Erhöhung der Wartbarkeit und Flexibilität der Anwendungssysteme durch Entkopplung und zentrale Integration über einen EAI-Bus;
-Implementierung von Mechanismen zur zeitnahen und konsistenten Synchronisation der verteilten Datenbestände innerhalb der Unternehmensanwendungen.
Abb: Innenansicht
EAI-Produkte vereinen in sich vier logische Bausteine, die zusammen einen Integrationsbus bilden. Quelle: Resco