Unter dem Begriff Legacy-System wird ein in sich geschlossenes Altsystem verstanden. Die Grundlagen solcher Anwendungen können vielfältig sein, beispielsweise Mainframe-Applikationen oder Datenbanksysteme ohne gängige Schnittstelle. Ihnen gemeinsam ist häufig, dass keine Unterstützung für moderne Softwareentwicklungssysteme vorhanden ist.

Zwei typische Beispiele sollen dies illustrieren: Für alte Host-Systeme existieren in der Regel keine Java-Ausführungsumgebungen. Dadurch kann man dort keine modernen Applikations-Server laufen lassen oder Schnittstellen mit den modernen Java-Produkten realisieren. Ein anderes Problem besteht in der Anbindung von Programmfragmenten. So ist es aufwändig, vorhandene Cobol-Programme direkt aus .NET- oder JEE-Anwendungen anzusprechen.

Warum Altanwendungen ändern?

Die Altanwendungen selbst laufen in den meisten Fällen sehr robust und effizient; sie haben sich über Jahrzehnte hinweg bewährt. In den meisten Fällen ist es nicht praktikabel, diese Systeme durch modernere Applikationen zu ersetzen. Eine solche Umstellung ist nicht nur technisch herausfordernd, sie rechnet sich auch betriebswirtschaftlich nicht. Aus funktioneller Sicht besteht auch selten eine Notwendigkeit, diese Systeme auszutauschen, da sie den Anforderungen gerecht werden. Das Problem mit Altanwendungen besteht darin, dass die Realisierung neuer Anforderungen nur mit hohem Aufwand möglich ist. Dazu gehört erstens die Einführung neuer Geschäftsprozesse, die neue Masken, angepasste Anwendungslogik und eventuell auch neue Datenbankstrukturen erfordern. Zweitens sind aber auch einfache Wartungsmaßnahmen, wie etwa die Aktualisierung von Betriebssystem-Komponenten oder das Verlagern von Infrastrukturelementen, aufwändig.

Die Ursachen hierfür liegen nur mittelbar in dem angesprochenen Problem der fehlenden Unterstützung moderner Entwicklungswerkzeuge. Das Hauptproblem besteht oft darin, kompetente Mitarbeiter zu finden, welche die neuen Anforderungen umsetzen können. Neben dem Know-how für die in die Jahre gekommene technische Infrastruktur ist vor allem das Wissen um die Interna des Altsystems eine sehr knappe Ressource. Wenn eine Anwendung über 20 Jahre gewachsen ist, dann ist meist davon auszugehen, dass der Code nur schwer verständlich und kaum überschaubar ist.

Integrieren statt Ersetzen

Aufgrund dieser Probleme ist es reizvoll, neue Anforderungen in einer modernen Anwendung umzusetzen und die Altanwendung als Drittsystem anzukoppeln. Ein typisches Szenario ist ein bestehendes Logistiksystem, das auf einem Host-System in der Programmiersprache Cobol implementiert wurde. Um dieses um neue mobile Eingabegeräte zu erweitern, bietet es sich an, eine neue Anwendung unter Einsatz der Java Enterprise Edition (JEE) oder von .NET-Techniken zu realisieren. Diese neue Anwendung verwaltet die mobilen Geräte und schickt die Daten dann an das Altsystem, das damit immer noch für die eigentliche Logistik zuständig ist.

In einem anderen typischen Szenario ist die gesamte Anwendungslandschaft in eine neue Architektur zu migrieren. Dies kann eine dienstorientierte Architektur (SOA = Service-orientierte Architektur) sein, in der die einzelnen Anwendungen wiederverwendbare Dienste anbieten. Diese werden über eine uniforme Schnittstelle wie etwa einen Prozessinterpreter orchestriert. Eine Altanwendung lässt sich indes meist nicht so umbauen, dass sie der neuen Architektur entspricht. Es sind daher Adapter zu realisieren, die sich dann in die neue Zielarchitektur einbinden lassen.

Für die Kopplung der Altanwendung mit den neuen Systemen benötigt man eine Schnittstellentechnik, eine so genannte Middleware. Deren Wahl führt natürlich wieder zu einer Abhängigkeit von einer Technik. Um das Risiko zu verringern, bietet es sich an, eine Technik mit hohem Verbreitungsgrad zu wählen, die nicht von einer bestimmten Programmiersprache oder von sonstigen technischen Rahmenbedingungen abhängig ist. Aus strategischen Gründen sollte sie auch nicht an einen Hersteller gebunden sein.

Diese Anforderungen gelten insbesondere für Web-Techniken. Die Kombination von HTTP und TCP/IP stellt ein einfaches Kommunikationsprotokoll dar, welches auf prinzipiell allen Systemen unterstützt wird. Als Datenformat ist XML geeignet. Es erlaubt die Übertragung semistrukturierter Daten, die aufgrund ihrer einfachen Grammatik mit wenig Aufwand verarbeitbar sind. Diese Kombination von Übertragungsprotokoll HTTP und Datenformat XML stellt einen Web-Dienst dar. Der Client schickt eine Anfrage per HTTP an den Dienstanbieter und erhält die Antwort als XML-Nachricht. Um die Schnittstelle eines Web-Diensts zu beschreiben, können XML-Schemadefinitionen (XSDs) benutzt werden. Mit XSDs lassen sich sowohl die Grammatik als auch die fachlichen Dateninhalte von XML-Nachrichten genau spezifizieren.

Die Grafik "Legacy-Integration" stellt eine Anwendungslandschaft dar, in der Altanwendungen über Web-Dienste integriert sind. Die Anwendungen auf den Mainframes benötigen einen Adapter, um Funktionen als Web-Dienst anzubieten. Frontend-Anwendungen können für synchrone Aufrufe direkt auf die Web-Dienste zugreifen. Für asynchrone Aufrufe bietet sich der Einsatz eines Enterprise Service Bus (ESB) an, der intern auf einem Nachrichtendienst aufsetzt.

Soap-basierende Web-Dienste

Häufig wird der Begriff Web-Dienst direkt mit dem Einsatz des Industriestandards Soap verknüpft. Soap ist ein XML-basierendes Netzprotokoll, das für den Austausch von Daten zwischen dem Client und dem Web-Dienst konzipiert ist. Basierend auf Soap existieren inzwischen viele weitere Techniken, die es ermöglichen, höherwertige Web-Dienste anzubieten. Eine grundlegende Technologie ist die Web Services Description Language (WSDL). Sie ermöglicht es, die Schnittstelle eines Web-Dienstes zu spezifizieren. Hierzu gehören die fachlichen und technischen Datenformate der Soap-Nachrichten, die Bindung der Soap-Nachrichtenteile an das Übertragungsprotokoll (meist HTTP) und die technischen Zugriffsinformationen, insbesondere die URL, unter welcher der Web-Dienst zugänglich ist.

Eine Schnittstellenbeschreibung mit WSDL selbst ist recht komplex und nur mit Werkzeugen handhabbar. Neben einer guten Dokumentation der Schnittstelle bietet sie aber insbesondere die Möglichkeit, automatisch Hilfsklassen für den Zugriff auf den Web-Dienst oder auch für dessen Implementierung zu erzeugen. Der Entwickler muss sich dann nicht mehr um die technischen Details wie den Einsatz von HTTP und die Konvertie-rung von Daten in und aus XML kümmern (siehe Grafik "WSDL-Funktionen").

Um Soap-basierende Web-Dienste auch finden zu können, sind diese in einem Verzeichnisdienst anzumelden. Die Technik Universal Description, Discovery and Integration (UDDI) bietet einen solchen Dienst an. Neben der Schnittstelle sind in einem UDDI-Verzeichnis auch die Dienstsemantik und die Organisation, welche den Web-Dienst zur Verfügung stellt, beschrieben.

Nachteile von Soap

Das Hauptargument für den Einsatz Soap-basierender Web-Dienste war das Versprechen der Interoperabilität. Aufgrund der Einfachheit der verwendeten Techniken HTTP und XML sollten beliebige Clients ohne Schwierigkeiten auf einen Web-Dienst zugreifen können. Die Realität sah anders aus. Der Zugriff funktionierte häufig nur dann, wenn Clients und Dienstanbieter die gleichen Produkte einsetzten. Bei unterschiedlichen Produkten ergaben sich technische Probleme, die kaum lösbar waren. Dies hat Soap einen schlechten Ruf eingebracht.

Die Hauptursache für die technischen Probleme war, dass Soap zwei unterschiedliche Stile anbietet, um seinen Body mit Nutzdaten zu füllen: ausgerichtet am Dokument und ausgerichtet am Methodenaufruf (RPC). Beim dokumentenartigen Stil wird der Body einfach mit einer XML-Nachricht gefüllt, deren Aufbau mit einer XSD spezifiziert werden kann. Beim RPC-Stil dagegen wird ein spezieller XML-Dialekt benutzt, der sich an den Programmiersprachen der Client- und Dienstanbieterimplementierungen orientiert.

Schon an den Eigenschaften der beiden Stile erkennt man, dass der dokumentenartige Stil für eine programmiersprachenunabhängige Kopplung zu bevorzugen ist, welche die Vorteile von XML als Nachrichtenformat ausnutzt. Da aber die vorhandenen Werkzeuge, insbesondere in ihrer Anfangsphase, nur den RPC-Stil unterstützten, wurde dieser eingesetzt. Die dann auftretenden Inkompatibilitäten waren Folge der unterschiedlichen Interpretation, wie die XML-Daten mit den Implementierungen zu verknüpfen sind.

Um die Probleme mit der Interoperabilität zu lösen, wurde die Web Services Interoperability Organization (WS-I) gegründet. Sie besteht aus etwa 130 Mitgliedern, von denen rund 70 Prozent Produkthersteller sind. Ein Ergebnis der WS-I ist das Basic Profile, das inzwischen in der Version 1.1 vorliegt und Lösungen für mehr als 200 Interoperabilitätsprobleme mit den aktuellen Soap-Techniken enthält. Werden Soap-basierende Web-Dienste eingesetzt, sollten Unternehmen darauf achten, dass die benutzten Produkte konform zu den WS-I-Spezifikationen sind. Des Weiteren sollten sie stets den dokumentenartigen Stil verwenden.

Die WS-*-Vielfalt

Basierend auf dem recht einfachen Soap-Format wurden viele weitere Techniken entwickelt, die einen Web-Dienst um höherwertige Funktionen anreichern. Da die meisten Spezifikationen mit "WS-" beginnen, hat sich der Begriff WS-* etabliert, um die große Menge an Techniken zu benennen. Neben den eher technischen Diensten werden insbesondere von der Organization for the Advancement of Structured Information Standards (Oasis) Datenformate für bestimmte fachliche Anwendungsdomänen spezifiziert.

Zusammenfassend kann man sagen, dass für Soap-basierende Web-Dienste viele weitere Techniken zur Verfügung stehen. Ihr Einsatz ist allerdings selten einfach und die Interoperabilität meistens gering.

Mit Rest ist alles einfacher

Aufgrund der angesprochenen Interoperabilitätsprobleme und der Komplexität der fortgeschritteneren auf Soap aufsetzenden Techniken formierte sich das Bedürfnis nach einfacheren Alternativen für Web-Dienste. Die aktuell interessanteste Alternative ist Rest. Das Kürzel steht für Representational State Transfer und bezeichnet einen Architekturstil für verteilte Systeme, der sich am World Wide Web orientiert und von Ray Fielding im Rahmen seiner Dissertation erstellt wurde. Die Idee dahinter besteht darin, dass alle Elemente in einer Anwendungslandschaft Ressourcen sind, die einen eindeutigen Bezeichner haben, nämlich ihre URL. Die Schnittstelle dieser Ressourcen enthält nur die Standard-HTTP-Aktionen: Put zum Anlegen, Get zum Lesen, Delete zum Löschen und Post zum Ändern. Diese uniforme einfache Schnittstelle für alle Ressourcen erleichtert natürlich die Entwicklung neuer Anwendungen und die Wartung einer Anwendungslandschaft. Es muss allerdings klar sein, dass dieser Architekturstil nicht der gewohnten dienstorientierten Architektur entspricht. Üblicherweise erzeugt man eine Rechnung, indem man bei der Buchhaltungssoftware eine entsprechende Operation mit den erforderlichen Parametern aufruft. Bei Rest führt man ein Put mit einer geeigneten URL aus. Die Rechnungsdaten werden dabei übergeben. Nach dem Put ist die Rechnung unter der gleichen URL über Get verfügbar.

Interessanterweise lassen sich Soap und Rest auch kombinieren. Der Grund hierfür besteht darin, dass Soap nur ein Nachrichtenformat ist und Rest keinerlei Anforderungen an das Nachrichtenformat stellt. Die höherwertigen Dienste, die auf Soap aufsetzen, lassen sich aber in der Regel nicht verwenden. Der große Nachteil beim Einsatz von Rest zur Integration von Altsystemen besteht darin, dass es keine festen Standards gibt. Insbesondere in einer großen Anwendungslandschaft kann dies zum Problem werden, da die Entwicklungsabteilung selbst für die Interoperabilität ihrer Integrationslösungen sorgen muss.

Ist HTTP wirklich eine gute Idee?

Die Grundmotivation für Web-Dienste ist der Einsatz von HTTP als einfache Middleware, die auf allen Systemen zur Verfügung steht. Der Einsatz von HTTP birgt aber auch einige Nachteile, derer man sich bewusst sein sollte, bevor man sich dafür entscheidet: HTTP bietet keine Transaktionsunterstützung. Wird also über HTTP eine unternehmenskritische Operation wie etwa eine Lagerbestellung ausgeführt, dann lässt sich diese nicht wieder zurückrollen. Beim Einsatz von Soap lassen sich zwar Transaktionen integrieren. Das Aufsetzen der Infrastruktur ist aber anspruchsvoll, und die Anwendungen müssen angepasst werden. Die Einfachheit von HTTP als Middleware geht so verloren.

Beim Einsatz von HTTP werden Daten direkt zwischen Clients und Server übertragen. Die Adresse des Servers muss dem Client bekannt sein. Damit sind Clients und Server eng aneinander gekoppelt, wodurch die Wartbarkeit erschwert wird. Man kann zwar über DNS den Web-Servern logische Namen geben, die sich an den Diensten der Server orientieren. Dies schafft eine Entkopplung. Sie ist aber recht starr und vermischt die Anwendungsverwaltung mit der Verwaltung der technischen Infrastruktur.

Ein weiterer Nachteil: HTTP bietet nur eine synchrone Kopplung. Der HTTP-Request wird bearbeitet, das Ergebnis wird dem Anfragenden zurückgegeben. Wenn große Operationen in der Altanwendung ausgeführt werden, kann das mehrere Minuten lang dauern. Die meisten Web-Server und Kommunikationsbibliotheken haben aber knappe Timeout-Einstellungen. Ein zusätzliches Problem besteht darin, dass bei Auftreten eines Timeouts der Aufrufer nicht wissen kann, ob die Operation nun ausgeführt wurde oder nicht.

Alle aufgeführten Probleme beim Einsatz von HTTP lassen sich mit dem Einsatz eines Nachrichtendienstes wie zum Beispiel Websphere MQ oder Active MQ vermeiden. Nachrichten werden in Transaktionen dem Nachrichtendienst übergeben und von diesem wieder ausgeliefert. Sender und Empfänger lassen sich über eine ESB-Architektur (ESB = Enterprise Service Bus) entkoppeln. Die Interaktion ist asynchron. Allerdings bindet man sich mit einem Nachrichtendienst auch an einen Hersteller. Durch den Einsatz unabhängiger Schnittstellen wie etwa Java Message Service (JMS) lässt sich diese Abhängigkeit reduzieren, aber nicht beseitigen. (wh)