Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

03.04.2006

Die Spaghetti-Falle droht auch bei SOA

Eerko Weeke 
Legacy-Systeme sollte man über eine Datenintegrationsschicht in Service-orientierte Architekturen einbinden.
Wer alte Punkt-zu-Punkt-Verbindungen in eine Servicearchitektur überträgt, dem droht ein Integrations-Spaghetti (oben). Eine Datenintegrationsschicht ordnet (unten).
Wer alte Punkt-zu-Punkt-Verbindungen in eine Servicearchitektur überträgt, dem droht ein Integrations-Spaghetti (oben). Eine Datenintegrationsschicht ordnet (unten).

Eine Service-orientierte Architektur (SOA) schafft Beweglichkeit in der Organisation von Geschäftsprozessen bei gleichzeitiger Unabhängigkeit von der Technik. Die Grundidee, Unternehmensfunktionen zu ordnen und als Menge voneinander unabhängiger Dienste (Services) zur Verfügung zu stellen, klingt verlockend, jedoch sind bestehende Applikationen in der Regel nicht servicefähig. Vielmehr müssen sie in irgendeiner Form in das neue Konzept integriert werden.

Warum Integrationsschicht?

• Bei einer SOA-Architektur wird zur erfolgreichen Anbindung von Legacy-Systemen eine Datenintegrationsschicht empfohlen.

• Sie vermeidet ein Service-Spaghetti, das entsteht, wenn Services direkt auf Legacy-Systeme aufsetzen.

• Die Datenintegrationsschicht kann zusätzlich Ordnung in ein zwischen den Legacy-Systemen bestehendes Schnittstellen- Spaghetti bringen.

• Gleichzeitig sollte sie sich so verhalten wie jeder andere Serviceteilnehmer (zum Beispiel vollständige Kapselung).

• Die Datenintegrationsschicht kann im Kern über eine Transformations-Engine verfügen, die Ähnliches leistet wie die Broking- und Conversion-Ebene bei EAI-Tools.

Fazit

Wer in SOA die Zukunft seiner IT-Architektur sieht, kommt nicht umhin, seine Legacy- Systeme zu integrieren. Dabei ist die Verlockung groß, Ser- vices einfach direkt auf Alt- anwendungen aufzusetzen, also dort direkt Methoden oder Daten aufzurufen, ohne diese vorher unter einem Service- aspekt aufzubereiten. Dies widerspricht jedoch dem Ordnungsgedanken einer SOA und führt zu einem nicht mehr wartbaren Service-Spaghetti, das die Dimensionen eines Integrations-Spaghetti weit übertreffen kann. Zu empfehlen ist stattdessen die Verwendung einer Datenintegra- tionsschicht, über die Legacy-Systeme SOA-gerecht angekoppelt werden.

Falsch: Punkt-zu-Punkt

Da sich Funktionen bestehender Anwendungen relativ einfach mit Hilfe von Tools als Web-Service auslegen lassen, könnte man auf die Idee kommen, Services direkt auf die Applikationen zugreifen zu lassen. Das Ergebnis wäre allerdings ein Ser- vice-Spaghetti, bei dem auf eine Altanwendung von den unterschiedlichsten Services aus zugegriffen würde.

Punkt-zu-Punkt-Schnittstellen würden ersetzt durch Servicebeziehungen; die Komplexität, die vorher durch Punkt-zu-Punkt-Schnittstellen verursacht wurde, würde zu einhundert Prozent in eine SOA-Infrastruktur verlagert. Wichtige mit SOA verbundene Themen wie "lose Kopplung", "Kapselung", "Wiederverwendung" und "verteilte Entwicklung" wären ebenso in Frage gestellt wie die Wartbarkeit der Infrastruktur, etwa wenn sich bei einem der Altsysteme etwas ändert.

Produktivitätschancen verspielt

Darüber hinaus geht der Blick für eine evolutionäre Entwicklung verloren, bei der die Produktivität einer bestehenden IT-Infrastruktur, die weitgehend auf Legacy-Systemen basiert, nicht nur gewahrt, sondern gesteigert werden kann - bei gleichzeitiger Integration in eine ordnende SOA. Denn solange Legacy-Systeme noch über Punkt-zu-Punkt-Schnittstellen miteinander kommunizieren und damit noch ein Integrations-Spaghetti besteht, kann bereits durch die Schaffung von Ordnung allein auf diesem Level ein erhöhter Nutzen erreicht werden.

Wird bei einer SOA als Kern ein Enterprise Service Bus (ESB) verwendet, so bietet sich zur An- bindung von Legacy-Systemen die Einführung einer Datenintegrationsschicht als Serviceteilnehmer an. Während der ESB Aufgaben wie Kommunikationsvermittlung, Nachrichtenführung, die Bereitstellung von Informationen für alle Serviceteilnehmer sowie grundlegen- de Web-Service-Unterstützung übernimmt, erfüllt die Datenintegrationsschicht Anforderungen wie die Zusammenführung verteilter oder komplexer Datenstrukturen im Rahmen der Legacy-Systeme sowie den nativen Zugriff auf herstellerspezifische Systeme.

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.

Für eine Übergangszeit kann die Transformations-Engine der Datenintegrationsschicht sowohl für EAI- als auch für SOA-Aufgaben genutzt werden. Ein Vorteil, denn solange unternehmensweite Applikationsabläufe beziehungsweise Workflows in Legacy-Systemen keines Eingriffs bedürfen, können diese per Transformations-Engine und Activity-Monitoring im ESB als automatisierte und schnell durchlaufende Prozesse weiter forciert werden.

Wer derzeit auf Legacy-Ebene noch über ein Schnittstellen-Spaghetti zwischen den Applikationen verfügt, wird nicht darum herum kommen, mit den Werkzeugen und Methoden, die ihm eine Transformations-Engine im Rahmen einer Datenintegrationsschicht und Teil einer SOA zur Verfügung stellt, die vorhandenen Legacy-Systeme anzubinden. Dabei spielt es keine Rolle, ob SOA per Single-Vendor- oder Multi-Vendor-Strategie eingeführt wird. Dadurch, dass stets gemeinsame Standards verwendet werden, ist eine Interoperabilität immer sichergestellt. (ue)