Die Spaghetti-Falle droht auch bei SOA

18.05.2006
Von Eerko Weeke

Im Kern kann eine Datenintegrationsschicht auf eine leistungsfähige Transformations-Engine aufbauen, die sich zum Beispiel über Adapter für ODBC, FTP, Messaging oder SAP mit Legacy-Systemen verbinden lässt. Risikoreiche Eingriffe in laufende Systeme sind somit nicht erforderlich. Darüber hinaus ist der Austausch von Altapplikationen einfach möglich, denn Veränderungen etwa von Schnittstellen müssen an zentraler Stelle nur einmal berücksichtigt werden. Die Services erhalten immer die gleichen Daten zurück. SOA-seitig lassen sich die Funktionen und Daten bestehender Systeme in einer sehr feinen Granularität ansprechen. Die Datenintegrationsschicht verhält sich gegenüber der bestehenden Applikationslandschaft vollkommen transparent.

Aus EAI bereits bekannt

Wer sich bisher schon mit dem Thema Enterprise Application Integration (EAI) beschäftigt hat und für eine Automatisierung seines unternehmensweiten Workflows gesorgt hat, dem wird die Transformations-Engine nicht unbekannt sein. Sie bildete im Rahmen eines EAI-Tools die Ebene für Broking und Conversion als transaktionaler Integrationsbroker und übernimmt Aufgaben wie Konvertierung, Validierung und Anreicherung von Daten.

Da Applikationen auf Feldebene nicht abgestimmt sind, müssen Datenstrukturen gegeneinander gehalten - gemapped - werden. Idealerweise geschieht dies einfach und nachvollziehbar, wenn man objektorientiert auf Ebene der Anwendungsinhalte zuordnet. Hier wie dort übernimmt die Transformations-Engine die Aufgabe, vom Inhalt abhängige Steuerungs- und Umsetzvorgänge wahrzunehmen und damit auf betriebswirtschaftlicher Ebene syntaktisch und vor allem semantisch zu arbeiten. Oft können transaktionale Integrationsbroker auf Basis von EAI-Tools zu Lieferanten von Integration-Services ausgebaut werden. So findet beispielsweise die Transformations-Engine Data Stage TX als Konvertierungs-Layer innerhalb eines Advanced ESB Einzug in die SOA-Edition der Websphere-Gruppe von IBM.