SOA ganz pragmatisch Aber zum Glück gibt es SOA. Das Dilemma „funktionelle Leistungsfähigkeit und Kostenaspekte versus Flexibilität und Offenheit” liefert den Ansatzpunkt für einen pragmatischen Weg zur SOA. Unternehmen müssen nämlich nicht auf den einen
großen Wurf warten, auf die große Neugestaltung ihrer Anwendungslandschaft,
sondern können auch ganz bestimmte, begrenzte Aufgaben mit den Möglichkeiten dieser Architektur lösen. Dieser Pragmatismus ist dem Grundgedanken von SOA übrigens keineswegs fremd, sondern geradezu in deren „DNA” angelegt. Da eine SOA per Definition technologie-, sprach- und systemunabhängig ist, lässt sich damit auch eine vorhandene COBOL-Businesslogik, sobald sie als Service gestaltet wird, ohne weiteres in einem neuen, offenen Kontext betreiben. Der SOA ist es egal, ob die Services mit Java oder COBOL geschrieben wurden. Also muss man nur die bestehenden Algorithmen als Services verpacken und über definierte Schnittstellen anderen Systemen zur Nutzung zur Verfügung stellen.
Dieses „Nur” bedarf freilich der Interpretation. Grundsätzlich sollte man sich bei solchen Projekten immer bewusst sein, dass die SOA auf einer gänzlich anderen
„Software-Philosophie” beruht als die vorhandenen Enterprise-Applikationen, die von Haus aus eben nicht „SOA-fähig” sind. Selbst wenn sie durchgehend aus sauber strukturierten, modular aufgebauten Programmen bestehen, liegt die Herausforderung darin, in diesen Programmen jene Bestandteile zu identifizieren, die als funktionelle Services genutzt werden können, und sie anschließend herauszulösen. Eine sehr sorgfältige Analyse der bestehenden Anwendung ist dabei unerlässlich. In größeren Applikation kann man durchaus ein paar Tausen Module finden, die zwar funktionell für eine Verwendung als Service in Frage kommen, die aber technisch (noch) nicht den Kriterien eines Services entsprechen.
Mittlerweile sind kommerzielle Lösungen verfügbar, mit denen sich die richtigen Module in einer vorhandenen Enterprise- Applikation identifizieren und herauslösen lassen. So können Unternehmen, die einen IBM-Mainframe (System z) als Host-System verwenden, mit SOA Express von Micro Focus die Erstellung von Services aus bestehenden COBOL-Programmen in hohem Maße automatisieren. Die betreffenden Applikationen verwenden für die Dialoganwendungen die Transaktionssysteme CICS oder IMS. SOA Express generiert aus diesen Host-Transaktionen Services, ohne dabei Veränderungen an der jeweiligen Host-Applikation vorzunehmen. Unternehmen können damit genau das vermeiden, was sie am meisten fürchten: Eingriffe in die funktionellen Aspekte funktionierender Applikationen.
Ausgangspunkt für die Definition eines Service ist die Host-Applikation. Ein Service kann generiert werden auf Basis:
* einer Bildschirmmaske der Host-Anwendung (BMS für CICS, MFS für IMS)
* einer Datenstruktur, die jedem Transaktionsprogramm zur Verfügung gestellt wird und den Ablauf des Programms steuert (COMMAREA bei CICS, Scratch Pad Area bei IMS)
* eines protokollierten Anwender-Dialogs, der sich über mehrere Masken und auch mehrere Transaktionen erstrecken kann.
Auf diese Weise lassen sich zunächst die Funktionalität und der Umfang des zu erstellenden Service auf dem Mainframe definieren. Der Service besteht aus einer oder mehreren Transaktionen, die ihre Eingabedaten aus der entsprechenden
Maske oder dem betreffenden Datenbereich erhalten. Diese Eingabedaten und
die von der Transaktion zurückgelieferten Ausgabedaten stellen die Basis für die
Service-Schnittstelle dar, die nach außen exponiert wird. Dabei ist es durchaus möglich, den Umfang der Datenübernahme flexibel an die Anforderungen des zu erstellenden Services anzupassen. So können zum Beispiel bestimmte Felder der Maske an der Service-Schnittstelle oder einzelne Felder, die konstante Informationen enthalten, ausgenommen werden, so dass die Daten im Service-Interface nicht auftauchen. Dieses Vorgehen ermöglicht es, die Funktionalität der Transaktion für die Verwendung als Service einzuschränken, ohne die Transaktion selbst zu verändern.
Services automatisch herstellen
Bei SOA Express erfolgt die Modellierung des Service-Interfaces mit Hilfe eines grafischen Tools. Wurde zur Erstellung des Services ein ganzer Dialog mit mehreren Bildschirmen aufgezeichnet, so kann mit diesem Tool das Service-Interface definiert und anschließend festgelegt werden, welche Informationen von einer Transaktion zur anderen weitergegeben werden, ohne dass sie an der Service-Schnittstelle nach außen sichtbar werden. Dadurch entsteht eine interne Verarbeitungslogik innerhalb des Services, mit der auch Feldinhalte abgefragt und auf einen bestimmten Inhalt überprüft werden können. SOA Express generiert immer zwei Module, ein Host-Modul in COBOL und ein Modul in der Sprache des Application- Servers, auf dem der Service läuft, also entweder Java oder C# für die .NET-Welt.
Dieser Beitrag wurde geschrieben von : Rolf Becking und erschien in der SOA-Online-Ausgabe der OBJEKTspektrum im November 2008 (www.objektspektrum.de) .
LG Euer Admin
