Integrationsarchitekturen

Die Evolution der IT-Architekturen

18.02.2015
Von   
Bernhard Steppan arbeitet als IT-Chefarchitekt bei DB Systel GmbH (Deutsche Bahn) in Frankfurt am Main. Er hat 100+ Artikel und zahlreiche Bücher über C++ und Java verfasst. Er betreibt mehrere Blogs, unter anderem http://steppan.net, http://artouro.org und http://tourbine.com

Enterprise Application Integration

Die nächsthöhere Stufe bei der Integration von verschiedenen Produkten nennt sich "Enterprise Application Integration" (EAI). Bei dieser Art der Integration ist ein zentraler Integrations-Server der Mittler zwischen den verschiedenen Systemen. Jedes System muss einen Adapter zu diesem Integrations-Server entwickeln. Die Adapter sind hierbei durch eine Standardschnittstelle des Integrations-Servers im Gegensatz zu den vorher genannten Architekturen relativ einheitlich aufgebaut. Der Ansatz der EAI ist konservativ: Die Produkte, die integriert werden müssen, werden normalerweise nicht angepasst. Das Verfahren bewährt sich daher besonders dort, wo Legacy-Anwendungen eingebunden werden müssen, bei denen Änderungen riskant wären. Ein anderer Anwendungsfall ist die Anbindung von Standardanwendungen wie SAP, die nur mit großem Aufwand angepasst werden könnten. Eine EAI-Architektur verlagert den Integrationsaufwand von der Anpassung einer Anwendung zur Entwicklung eines speziellen Adapters.

EAI-Architekturen können als Vorstufe der serviceorientierten Architektur angesehen werden. Der größte Unterschied ist, dass bei diesem konservativen Integrationskonzept vorhandene Systeme nach Möglichkeit nicht verändert werden.
EAI-Architekturen können als Vorstufe der serviceorientierten Architektur angesehen werden. Der größte Unterschied ist, dass bei diesem konservativen Integrationskonzept vorhandene Systeme nach Möglichkeit nicht verändert werden.
Foto: Steppan

Die Nachteile der Enterprise Application Integration sind, dass die Produkte vergleichsweise kompliziert und teuer sind. Dadurch, dass bestehende Systeme in der Regel nicht aufgebrochen werden, zementiert man ihre Defizite. Das für andere Anwendungen wertvolle Know-how dieser Systeme bleibt verborgen. Der Grad der Wiederverwendung ist daher eher gering und die Adapter sind nach wie vor aufwendig zu programmieren. Ein weiterer Nachteil ist, dass sich die Services, die über den Integrations-Server angeboten werden, nicht unbedingt an den Geschäftsprozessen orientieren.

Serviceorientierung

Seit der Einführung von SOAP (Simple Object Access Protocol) haben sich Web-Services in vielen Unternehmen verbreitet. Sie sind vergleichsweise einfach zu programmieren und basieren auf der standardisierten Web Service Definition Language (WSDL) für die Serviceschnittstelle. Die WSDL gliedert eine Schnittstelle in ein definiertes Datenmodell, in Nachrichten und in Protokolle. Die Schnittstellenbeschreibung enthält zudem die Netzwerkadresse, unter der ein Service verfügbar ist. Dadurch, dass die Serviceschnittstellen aufgrund der standardisierten Schnittstellensprache WSDL beschrieben werden, ergeben sich viele Vorteile, zum Beispiel lassen sich Adapter für Service Consumer (Clients) vergleichsweise einfach entwickeln sind. Entsprechende Frameworks können sowohl die Beschreibung der Schnittstelle als auch den Rohbau von Adaptern zu großen Teilen generieren.

Solche Services fördern sehr schnell die Wiederverwendung in einem Unternehmen. Funktionen, die zuvor nur in einer Anwendung vorhanden waren, lassen sich auslagern und somit für andere öffnen.

Ohne eine entsprechende SOA-Infrastruktur besteht hier aber wieder die Gefahr, Peer-to-Peer-Architekturen mit Services aufzubauen. In diesem Fall vernetzen sich die Anwendungen wieder wild untereinander, was zu einer starken Kopplung führt. Die Folge ist, dass Migrationen ähnlich riskant sind, wie zuvor bei Peer-to-Peer-Lösungen. Als man diese Gefahr erkannt hat, hat man versucht, die Vorteile der Enterprise Application Integration mit der Serviceorientierung zu verknüpfen.