Hilfe aus der SOA-Welt

Wege zur Cloud-Integration

05.12.2011
Von Christian Tüffers

Am Enterprise Service Bus führt selten ein Weg vorbei

Cloud Computing ist eine konsequente Weiterentwicklung des SOA-Konzepts (Service-oriented Architecture). Das legt den Gedanken nahe, auch die Cloud-Legacy-Integration mit weiterentwickelten SOA-Instrumenten ins Werk zu setzen. Berücksichtigt man die Doppelperspektive aus Daten- und Prozesssicht, dann gibt es prinzipiell zwei Integrationswege:

  • Legacy-Systeme per Datenaustausch an die Cloud anzubinden;

  • Anwendungen per Enterprise Service Bus (ESB) zu integrieren.

Die erste Option entspricht der engeren Datensichtweise, der ESB dagegen repräsentiert die umfassendere Prozessperspektive. Reicht eine einfache punktuelle Verbindung zwischen Cloud- und Legacy-Anwendung aus, kann manchmal ein einfacher Dateitransfer die kostengünstigere Integrationsalternative sein. Das ist allerdings nur der Fall, wenn die beiden Applikationen nicht synchronisiert werden müssen - zum Beispiel, wenn Materialbestände in einer alten Mainframe-Datenbank aus einem logistischen Cloud-Service nur in größeren zeitlichen Abständen als Wareneingang gebucht werden müssen.

Mehr als ein Fünftel der befragten Unternehmen führen Cloud-Applikationen in ihrem IT-Service-Portfolio. Die meisten Installationen laufen in einer öffentlichen IT-Wolke.
Mehr als ein Fünftel der befragten Unternehmen führen Cloud-Applikationen in ihrem IT-Service-Portfolio. Die meisten Installationen laufen in einer öffentlichen IT-Wolke.

In den allermeisten Fällen müssen Cloud- und Legacy-Anwendung in Echtzeit miteinander interagieren. Dann führt kein Weg am ESB vorbei. Der Begriff ESB kam vor knapp zehn Jahren im SOA-Umfeld auf und bezieht sich auf eine Schicht aus verschiedenen Softwarewerkzeugen, die zwischen den diversen Enterprise-Applikationen dolmetschen. Idealerweise ermöglicht der ESB, dass verschiedene Anwendungen reibungslos miteinander kommunizieren können, ohne dass dafür Code-Änderungen an den beteiligten Anwendungen notwendig sind. Das gilt sowohl für den Datenaustausch als auch für den wechselseitigen Funktionszugriff zwischen den Anwendungen. Die wichtigsten Mittel dafür sind hauptsächlich Web-Services auf Basis von XML sowie SOA-typische Messaging-Formate.

Steht kein ESB zur Verfügung, muss für jede Einzelinteraktion zwischen zwei Anwendungen eine exklusive Punkt-zu-Punkt-Schnittstelle programmiert werden - eine extrem aufwendige Angelegenheit. Der Zugriff auf Mainframe-basierende Legacy-Anwendungen lässt sich dabei über spezielle Adapter wie beispielsweise den Transaktionsmonitor CICS umsetzen. Die Lösung unterstützt diverse Programmiersprachen und Protokolle aus der Großrechnerwelt, darunter Cobol, PL/1 und Assembler. Mit CICS lassen sich Transaktionen unter Mainframe-Betriebssystemen wie MVS sozusagen in einen Web-Service einpacken. Sie sind in dieser Form dann auch für Cloud-Anwendungen konsumierbar. Zusammen mit den ESB-Messaging-Funktionen gelingt es damit in vielen Fällen auch, eine Brücke zwischen Mainframe-typischer Stapelverarbeitung und der ereignisorientierten Cloud-Arbeitsweise zu schlagen.

Wenn nichts hilft: Legacy-Systeme lassen sich umbauen

Die wenigsten Unternehmen müssen in Sachen Legacy-Cloud-Integration bei null anfangen. Vielerorts sorgen ESBs bereits seit Jahren für die interne Anwendungsintegration. Prüfen sollte man allerdings, ob der jeweilige ESB-Anbieter auch geeignete Konnektoren für die Cloud-Anbindung bereitstellt, etwa für das Session- und Transaktions-Management. Mittlerweile bieten einige ESB-Hersteller sogar Cloud-spezifische Konnektoren an, zum Beispiel einen Adapter für Salesforce.com.

Gleichwohl: Auch ein ESB ist kein Allheilmittel. Manche Legacy-Anwendung widersetzt sich hartnäckig dem externen Zugriff auf ihre Kernfunktionen - ursprünglich war einfach keine Öffnung nach außen vorgesehen. Dann muss das Legacy-System selbst angepasst werden, was wiederum oft mit einem tiefgreifenden Umbau der zugrunde liegenden Softwarearchitektur einhergeht. Für die Legacy-Anpassung empfehlen sich im Wesentlichen drei Ansätze:

  • Beim Re-Factoring wird die Architektur punktuell angepasst, um Cloud-relevante Funktionen neu zu kapseln und auf diese Weise einen externen Zugriff zu ermöglichen. Wichtig dabei: Re-Factoring verändert die Programmfunktionen als solche nicht. Aus der Blackbox-Sicht bleibt alles wie vorher.

  • Unter Re-Writing versteht man das Neuschreiben der kompletten Legacy-Anwendung. Sowohl Funktions- als auch Architekturänderungen sind in diesem Fall möglich.

  • Der Begriff Re-Platforming fasst unterschiedliche Tools und Methoden zur automatischen Portierung einer Legacy-Applikation auf eine andere Plattform zusammen, beispielsweise von Cobol/Mainframe auf .NET/Microsoft oder Java/Linux. Ratsam ist Re-Platforming allerdings nur, wenn die betreffende Anwendung (respektive die durch sie abgebildeten Prozesse) tatsächlich eins zu eins erhalten bleiben soll. Denn die Programmiersprache und die Plattform sind zwar neu, aber an der eigentlichen Softwarestruktur ändert Re-Platforming nichts.

Zur Startseite