20080910zh MicroFocus Serviceorientierte Architektur Enterprise-Applikationen Legacy

»manage it« als

E-Paper 5-6 2011
E-Paper 3-4 2011
E-Paper 1-2 2011
E-Paper 11-12 2010
E-Paper 9-10 2010
E-Paper 7-8 2010
E-Paper 5-6 2010

Serviceorientierte Architektur

SOA verleiht Enterprise-Applikationen neuen Schwung

Die serviceorientierte Architektur bietet die Möglichkeit, bewährte Business-Logik aus Enterprise-Applikationen für neue Aufgaben zur Verfügung zu stellen. Mit standardisierten Schnittstellen ausgestattet können Module aus COBOL-Programmen dann beispielsweise durch Web-Interfaces genutzt werden.

OA bleibt im Trend. Der Aufbau einer neuen Anwendungslandschaft, die endlich so flexibel ist, dass sie die unverzichtbare Business-Agilität auf allen Ebenen unterstützt, die wiederverwendbar und dennoch übersichtlich strukturiert ist, und die schließlich auch noch Kosten spart, ist ohne Zweifel eine interessante Option.

Die Betreiber von Enterprise-Applikationen – und das sind immerhin die Mehrzahl der größeren Unternehmen – haben in der Regel jedoch ganz andere Sorgen. Weit davon entfernt, ihre Applikationen in einer optimalen Architektur neu entwerfen und realisieren zu können, müssen sie versuchen, aus dem Vorhandenen das Beste zu machen. Diesseits der großen Entwürfe muss man sich mit den bestehenden Applikationen arrangieren. Umso mehr als zahlreiche Projekte, die in den letzen Jahren meist mit Java und J2EE alles neu und besser machen wollten, bei weitem nicht die erwarteten Ergebnisse gebracht haben. Über viele dieser mit großen Hoffnungen gestarteten Neuentwicklungen haben die betroffenen Unternehmen dann nur noch hinter verschlossenen Türen gesprochen. Am Ende war mancher Anwender froh, dass ihm für den produktiven Betrieb seine »alten« Anwendungen noch zur Verfügung standen.

Die Rückbesinnung auf die lange Zeit eher gering geschätzten Werte der Enterprise-Applikationen hat daher auch überhaupt nichts mit Nostalgie zu tun, sondern mit Pragmatismus. Immerhin stellen diese Anwendungen bewährte, zuverlässige Lösungen bereit, die auch eine große Zahl von Transaktionen und Benutzern erheblich besser verkraften als die Mehrzahl ihrer modernen Nachfolger. Vor allem aber sind in diesen COBOL- oder seltener PL1-Applikationen eine riesige Zahl von Business-Prozessen in Form von Algorithmen festgehalten. Hier wurde über viele Jahre ein enormes fachliches Know-how abgelegt, das auf einer anderen Plattform erst einmal nachgebildet werden müsste. Häufig sind die in dieser Business-Logik enthaltenen Investitionen außerdem längst abgeschrieben; sie kosten im Unterschied zu Neuentwicklungen nur noch Pflegeaufwand.

Auf der anderen Seite ist aber auch klar, dass die bestehenden Systeme in die technologische Defensive geraten sind. Dass Enterprise-Applikationen, zumal auf Mainframes, kompliziert sind und schwer zu erweitern, ist ja kein böswilliges Gerücht. In der Regel handelt es sich um abgeschlossene Systeme, auf die man nicht einfach mit einem Web-Interface oder mit einem Linux-Server zugreifen kann. Synchronisation mit PDAs, Datenintegration mit Windows-Applikationen, XML-Output – Anforderungen dieser Art sind den Enterprise-Applikationen im Grunde fremd. Für den externen Zugriff auf eine Mainframe-Anwendung müsste man eigens ein CICS-Transaktion-Gateway bauen – was in der Praxis so kompliziert ist, wie es klingt. Natürlich sind die Enterprise-Applikationen für derartige Aufgaben gar nicht konzipiert, sie sind schließlich auf Basis einer völlig anderen IT-Philosophie entstanden, aber die Welt hat sich nun mal zu ihrem Nachteil weiter gedreht.

Das Legacy-Dilemma

Damit hat sich die IT-Welt ein ärgerliches Dilemma eingehandelt: Sie wird die Enterprise-Applikationen nicht los und braucht doch immer schon auch etwas ganz anderes. Funktionelle Leistungsfähigkeit und Kostenaspekte stehen gegen Flexibilität und Offenheit. Damit schlägt die Stunde von SOA: Diese Architektur bietet nämlich die Möglichkeit, die bewährte Businesslogik in einem neuen, offenen Kontext zu betreiben. Im Grunde geht es nur darum, die bestehenden Algorithmen als Services zu verpacken und sie über definierte Schnittstellen anderen Systemen zur Nutzung zur Verfügung zu stellen. Wobei das »nur« mit dicken Anführungszeichen zu versehen ist, denn die betreffenden Applikationen sind ja keineswegs in Hinblick auf eine SOA-Architektur erstellt worden. Auch wenn Enterprise-Applikationen heute durchgehend aus sauber strukturierten, modular aufgebauten Programmen bestehen, besteht die Schwierigkeit darin, aus diesen Programmen jene Bestandteile herauszulösen, die als funktionelle Services genutzt werden können.

Dabei wird gleich ein wesentlicher Unterschied zwischen SOA und der Komponenten-Technologie beziehungsweise einem modularen Programmaufbau deutlich. Natürlich wurden immer schon bestimmte Programmteile wiederverwendbar angelegt, so dass sie zur Übernahme von abgrenzbaren Funktionen – zum Beispiel Konvertierung eines Werts – von anderen aufgerufen werden können. Solche Module und Komponenten sind jedoch immer unter technischen Gesichtspunkten erstellt worden, nicht im Hinblick auf die Kapselung von echten Geschäftsprozessschritten. Zwar erlaubt auch das Corba-Modell eine Verknüpfung von Komponenten erst zur Laufzeit, was beispielsweise die Möglichkeit bietet, aktuelle Versionen einer DLL nachträglich bereitzustellen. Die Verwendung von Komponenten in einem ganz neuen, also bei der Entwicklung noch nicht verfügbaren oder noch gar nicht bekannten Kontext, geht über das Komponenten-Konzept hinaus. Diese Flexibilität bietet erst eine Architektur, die – nicht notwendigerweise durchgängig – ihre funktionellen Bestandteile als Service zur Verfügung stellt. Die Konsumenten oder Clients dieser Services müssen dann nur bestimmten Anforderungen genügen, sich also beispielsweise identifizieren können, und die Schnittstellen richtig bedienen. Dabei sorgt die Standardisierung dieser Schnittstellen für eine Vereinfachung der Kommunikation, die in Komponenten-Architekturen wie DCOM oder Corba nicht nur reichlich kompliziert, sondern außerdem auch nicht interoperabel war. Wer DCOM einsetzte war so auf Windows beschränkt, und bei Corba war der Anwender auf den jeweiligen Hersteller angewiesen. Das SOA-Konzept reicht hier um eine entscheidende Nuance weiter.

Services erzeugen

Will man die Anwendungslandschaft eines Unternehmens serviceorientiert organisieren, kommt man nicht daran vorbei, organisatorische Vorkehrungen zu treffen. Die Services müssen nach Themenbereichen oder Gebieten geordnet und katalogisiert werden, wenn sie später sinnvoll verwendet werden sollen. Ohne ein Repository mit exakter Beschreibung, Klassifizierung, Schnittstellendefinition der Services kommt man da nicht weit.

Daneben ist die Frage der Granularität von großer Bedeutung, also die Frage, wie viel an Funktionalität in einem Service stecken soll. Baut man die Services nämlich funktional zu umfangreich, kommt man zwar mit wenigen Services aus, aber eine Wiederverwendung ist nahezu ausgeschlossen, weil der Service zu speziell ist. Packt man im Gegenteil jede kleine Aufgabe in einen eigenen Service, wird die Zahl der Services schnell unüberschaubar und deren Kombination zu etwas Sinnvollem gerät zu einer mühevollen Kleinarbeit. Es empfiehlt sich außerdem, ähnliche Funktionen zu Gruppen zusammen zu fassen und dadurch eine gewisse Struktur zu erreichen, zum Beispiel alle Services zur Behandlung eines Vertrags bei einer Versicherung.

Bleibt die Aufgabe, die richtigen Module in einer vorhandenen Enterprise-Applikationen zu identifizieren und herauszulösen. Da sich in einer größeren Applikation, und in kleine wird man diesen Aufwand ohnehin nicht investieren, gut und gern ein paar Tausend Module befinden, die (noch) nicht den Kriterien eines Services entsprechen, besteht hierin die Hauptarbeit. In jedem Fall ist dafür eine sehr sorgfältige Analyse der bestehenden Anwendung unerlässlich. Die Fragen, die dabei zu beantworten sind, lauten:

· Wo in der Anwendung versteckt sich die gesuchte Funktionalität, die als Service angeboten werden soll?

· Was gehört zum Umfang des geplanten Service an Programmen dazu?

· Wie ist diese Funktion mit der restlichen Anwendung verzahnt?

· Wo und wie müssen diese Verzahnungen gelöst werden?

· Welche programmtechnischen Veränderungen sind dafür erforderlich?

· Wie soll die Service-Schnittstelle aussehen und welche Programmänderungen bringt wiederum diese mit sich?

Da die betreffenden Applikationen meist mehrere hunderttausend Lines of Code umfassen, können diese Fragen nur mit Hilfe von leistungsfähigen Analyse-Tools beantwortet werden, zum Beispiel mit Micro Focus' Revolve. Damit kann man etwa nach bestimmten Datenfeldern suchen, Interdependenz aufzeigen und sogar die Auswirkungen von Eingriffen simulieren. Was insofern wichtig ist, als man ja nicht aus einer Applikation einfach ein Modul herauslösen und dort eine unbrauchbare Ruine hinterlassen kann; andererseits muss natürlich auch vermieden werden, dass eine bestimmte Business-Logik redundant als COBOL-Modul und als SOA-Service existiert.

Das Ergebnis von Analyse und Anpassung ist ein Service: ein Modul, das die Business-Logik der Enterprise-Applikationen enthält, also in der Praxis meist COBOL-Code, und das keine direkte Verbindung zu anderen Programmbestandteilen aufrechterhält, sondern nur noch über die standardisierten Schnittstellen mit der Außenwelt kommuniziert. Solche Services lassen sich nun auf unterschiedliche Arten implementieren:

· Die Services bleiben Bestandteil der Mainframe-Infrastruktur; sie laufen weiterhin auf dem Mainframe – andere Systeme greifen auf die dort gelagerten Services zu. So kann zum Beispiel die Transaktion einer CICS-Anwendung als Web Service angeboten werden.

· Die benötigte Business-Logik wird aus der Enterprise-Applikationen herausgelöst, auf ein anderes System portiert und hier ausgeführt. Hier kann zum Beispiel ein Teil einer Host-Applikation zur Bewertung eines Versicherungsvertrags auf einem Windows-Server als Web Service laufen, den ein Benutzer aus dem Internet aufrufen kann.

COBOL-Spezialisten wie Micro Focus stellen für beide Verfahren leistungsfähige Werkzeuge zur Verfügung, mit denen die wichtigsten Arbeitsschritte automatisiert werden können.

Durch die Transformierung von bestehender Logik in eine SOA muss das Produktionssystem nicht verändert werden, die Eingriffe und Anpassungsarbeiten sind insgesamt begrenzt, die Kosten überschaubar. Außerdem muss nicht gleich eine ganze Applikation umgekrempelt werden, man kann sich gezielt bestimmte Funktionen vornehmen, Services herauslösen und so Schritt für Schritt eine neue Architektur aufbauen. Dabei zeigt sich auch einer ihrer größten Vorteile: SOA ist nicht technologiegebunden, sie ist weder von einer bestimmte Plattform noch von Programmiersprachen abhängig. SOA funktioniert mit COBOL oder CICS genauso wie mit J2EE oder Websphere. Entgegen anders lautender Gerüchte muss man nicht einmal auf Web-Services zurückreifen.

Rolf Becking

_____________________________________________________________________

Rolf Becking ist Senior Consultant bei Micro Focus in Dortmund

Aus den CICS-Transaktionen werden die Komponenten für die Kommunikation der Services erzeugt

Die Transaktionen kommunizieren zur Laufzeit über einen Host-basieren Service mit dem Applikationsserver.

Folgen Sie »manage it«

auf Google+

Copyright © 2003-2012 ap Verlag GmbH