BACKGROUND

Die Migration von Mainframe-Altsystemen auf neuere Plattformen hat viel Aufmerksamkeit auf sich gezogen, da Unternehmen auf verteilte und webfähige Softwarelösungen umsteigen müssen. Es wurden verschiedene Ansätze untersucht, die von der Umhüllung bestehender Systeme mit webfähigen Softwareschichten bis hin zu 1: 1-Konvertierungsansätzen für die Konvertierung von Programmen in COBOL in 4GL reichen. Daher enthält die aktuelle Literatur viele verwandte Erfahrungsberichte. Da Migration ein Problem ist, seit die ersten Unternehmenssysteme veraltet sind, gibt es zu diesem Thema viel Arbeit. Beispielsweise haben Forscher verschiedene Methoden entwickelt, um Systeme von ihrer ursprünglichen Technologie auf neuere Technologien wie Cold Turkey, Chicken Little und Renaissance zu migrieren. Diese Methoden beziehen sich jedoch nicht explizit darauf, wie Systeme zu SOA migriert werden. Um dieses Problem zu lösen, haben Forscher eine serviceorientierte Migration und Wiederverwendungstechnik (SMART) für die Auswahl von Migrationsstrategien entwickelt. Es gibt jedoch keine Tools, mit deren Hilfe Entwickler sie anwenden können. Darüber hinaus berücksichtigt SMART bei dieser Art der Migration nicht die SOA-Grenzqualität als Hauptsorge. Eine weitere COBOL-SOA-Migrationsmethode ist SOAMIG, die im Gegensatz zu SMART sowohl eine Migrationsmethode als auch Werkzeuge bereitstellt. Die Migrationsmethodik besteht aus vier Phasen, und jede dieser Phasen kann in mehreren Iterationen ausgeführt werden. Die Grundidee von SOAMIG besteht darin, das ursprüngliche System mithilfe mehrerer Übersetzungswerkzeuge in ein SOA-orientiertes System zu verwandeln. Zum Beispiel wird vorgeschlagen, ein Tool zu verwenden, das COBOL-Code in Java-Code übersetzt, der einfacher als Web-Service verfügbar gemacht werden kann. Dieser Ansatz kann sich jedoch negativ auf die Qualität der SOA-Grenze auswirken, da der COBOL-Code unter Verwendung veralteter Entwurfskriterien entworfen wurde und diese Art von Tools das System nicht neu gestaltet. Darüber hinaus gibt es in COBOL Längenbeschränkungen für Routinennamen und Kommentare, die möglicherweise in die SOA-Grenze übersetzt werden, was auch ein Qualitätsproblem für die SOA-Grenze darstellen kann. In diesem Zusammenhang ist die Migration von Legacy-Systemen zu SOA ein Anliegen, während gleichzeitig qualitativ hochwertige Service-Schnittstellen erreicht werden, anstatt die Systeme nur zu "webisieren". Harry Sneed erforschte gleichzeitig die automatische Konvertierung von COBOL-Programmen in Web-Services und die Messung der Qualität von Service-Schnittstellen. Der Autor stellt ein Werkzeug zur Identifizierung von COBOL-Programmen vor, die möglicherweise bedient werden. Das Tool basiert auf dem Sammeln von Code-Metriken aus der Quelle, um die Programmkomplexität zu ermitteln, und schlägt dann vor, ob Programme umschlossen oder überarbeitet werden sollen. Daher bestimmt die Komplexität der Programme die Auswahl der Migrationsstrategie. Wie bereits berichtet, plant Sneed, die daraus resultierenden Service-Schnittstellen mit einer eigenen Metrik-Suite zu überprüfen, die 25 Quantitäts-, 4 Größen-, 5 Komplexitäts- und 5 Qualitätsmetriken umfasst. Der Autor stellt auch ein Rahmen und Richtlinien für die Migration eines Altsystems zu SOA vor, die darauf abzielen, eine SOA-Grenze zu definieren, die nur die "optimalen" Dienste und eine angemessene Granularität aufweist. Der Rahmen besteht aus drei Stufen. In der ersten Phase werden die Hauptkomponenten des Altsystems und ihre Interaktionen mithilfe von UML modelliert. In der zweiten Stufe werden Serviceoperationen und Serviceprozesse identifiziert. In der dritten Stufe werden identifizierte Service-Elemente nach einer vordefinierten Taxonomie von Service-Typen (z. B. CRUD-Services, Infrastructure-Services, Utility-Services und Business-Services) zusammengefasst. Während der zweiten und dritten Stufe werden Softwareanalysten durch Clustering-Techniken unterstützt, die automatisch ähnliche Dienstvorgänge und Dienste des gleichen Typs zusammenfassen. Diese Arbeit stellt einen Vergleich verschiedener Migrationsansätze vor. Zwei von ihnen zusammen mit ihren Pro-Profis sind in der Community gut bekannt, während der andere ein neuer Ansatz ist, der darauf abzielt, die Profis der beiden vorherigen Migration ohne ihre Nachteile zu erreichen. Im folgenden Abschnitt wird die für diese Analyse verwendete Fallstudie erläutert.

Fallstudie

Der in dieser Arbeit untersuchte Fall besteht aus einem datenzentrischen System, das aus mehreren Subsystemen zur Verwaltung von Datensätzen besteht, die sich auf Einzelpersonen beziehen, einschließlich vollständiger persönlicher Informationen, Beziehungen, Arbeitshintergrund, erhaltener Vorteile usw. Das System ist in COBOL geschrieben, läuft also auf einem IBM-Mainframe und greift mit etwa 0,8 PetaBytes auf eine DB2-Datenbank zu. Andererseits gibt es einige COBOL-Programme, die auf historische Daten über die VSAM-Methode (Virtual Storage Access Method) zugreifen, eine Speicher- und Datenzugriffsmethode, die in einer Reihe von IBM Mainframe-Betriebssystemen zum Einsatz kommt. Darüber hinaus wird auf einige COBOL-Programme nur über ein Intra-Net über 3270-Terminalanwendungen zugegriffen, während andere Programme in CICS-Transaktionen (Customer Information Control System) zusammengefasst und von Webanwendungen verwendet werden. CICS ist ein Transaktionsmanager, der für eine schnelle Verarbeitung mit hohem Volumen entwickelt wurde. Dadurch können mehrere Programme als atomare Aufgabe organisiert werden. In diesem Fall bestehen diese Programme aus Geschäftslogik- und Datenbankzugriffen, meist Eingabevalidierungen bzw. Abfragen.
Tabelle 1: Eigenschaften der wichtigsten Systemtransaktionen nach der Mainframe-Last in Bezug auf ausgeführte Aufrufe im Januar 2010.

tablesrt2MM

Zur Veranschaulichung wird in Tabelle 1 eine kurze Übersicht von nur 6 Transaktionen angezeigt. Diese zeigt die Anzahl der nicht kommentierten Quellcodezeilen2, die Anzahl der durchgeführten SQL-Abfragen und die Anzahl der Zeilen und Dateien, die einer Transaktion zugeordnet sind. Wenn ein Programm P1 ein Programm P2 aufruft oder eine Kommunikationsbereichsdefinition C (COMMAREA) importiert oder eine SQL-Definition S enthält, heißt es, dass P1 P2 oder C bzw. S zugeordnet ist. Im Durchschnitt hatte jede Transaktion 18 Dateien, umfasste 1803 Codezeilen und führte 6 SQL-SELECT-Anweisungen aus.

BACKGROUND

Die Migration von Mainframe-Altsystemen auf neuere Plattformen hat viel Aufmerksamkeit auf sich gezogen, da Unternehmen auf verteilte und webfähige Softwarelösungen umsteigen müssen. Es wurden verschiedene Ansätze untersucht, die von der Umhüllung bestehender Systeme mit webfähigen Softwareschichten bis hin zu 1: 1-Konvertierungsansätzen für die Konvertierung von Programmen in COBOL in 4GL reichen. Daher enthält die aktuelle Literatur viele verwandte Erfahrungsberichte. Da Migration ein Problem ist, seit die ersten Unternehmenssysteme veraltet sind, gibt es zu diesem Thema viel Arbeit. Beispielsweise haben Forscher verschiedene Methoden entwickelt, um Systeme von ihrer ursprünglichen Technologie auf neuere Technologien wie Cold Turkey, Chicken Little und Renaissance zu migrieren. Diese Methoden beziehen sich jedoch nicht explizit darauf, wie Systeme zu SOA migriert werden. Um dieses Problem zu lösen, haben Forscher eine serviceorientierte Migration und Wiederverwendungstechnik (SMART) für die Auswahl von Migrationsstrategien entwickelt. Es gibt jedoch keine Tools, mit deren Hilfe Entwickler sie anwenden können. Darüber hinaus berücksichtigt SMART bei dieser Art der Migration nicht die SOA-Grenzqualität als Hauptsorge. Eine weitere COBOL-SOA-Migrationsmethode ist SOAMIG, die im Gegensatz zu SMART sowohl eine Migrationsmethode als auch Werkzeuge bereitstellt. Die Migrationsmethodik besteht aus vier Phasen, und jede dieser Phasen kann in mehreren Iterationen ausgeführt werden. Die Grundidee von SOAMIG besteht darin, das ursprüngliche System mithilfe mehrerer Übersetzungswerkzeuge in ein SOA-orientiertes System zu verwandeln. Zum Beispiel wird vorgeschlagen, ein Tool zu verwenden, das COBOL-Code in Java-Code übersetzt, der einfacher als Web-Service verfügbar gemacht werden kann. Dieser Ansatz kann sich jedoch negativ auf die Qualität der SOA-Grenze auswirken, da der COBOL-Code unter Verwendung veralteter Entwurfskriterien entworfen wurde und diese Art von Tools das System nicht neu gestaltet. Darüber hinaus gibt es in COBOL Längenbeschränkungen für Routinennamen und Kommentare, die möglicherweise in die SOA-Grenze übersetzt werden, was auch ein Qualitätsproblem für die SOA-Grenze darstellen kann. In diesem Zusammenhang ist die Migration von Legacy-Systemen zu SOA ein Anliegen, während gleichzeitig qualitativ hochwertige Service-Schnittstellen erreicht werden, anstatt die Systeme nur zu "webisieren". Harry Sneed erforschte gleichzeitig die automatische Konvertierung von COBOL-Programmen in Web-Services und die Messung der Qualität von Service-Schnittstellen. Der Autor stellt ein Werkzeug zur Identifizierung von COBOL-Programmen vor, die möglicherweise bedient werden. Das Tool basiert auf dem Sammeln von Code-Metriken aus der Quelle, um die Programmkomplexität zu ermitteln, und schlägt dann vor, ob Programme umschlossen oder überarbeitet werden sollen. Daher bestimmt die Komplexität der Programme die Auswahl der Migrationsstrategie. Wie bereits berichtet, plant Sneed, die daraus resultierenden Service-Schnittstellen mit einer eigenen Metrik-Suite zu überprüfen, die 25 Quantitäts-, 4 Größen-, 5 Komplexitäts- und 5 Qualitätsmetriken umfasst. Der Autor stellt auch ein Rahmen und Richtlinien für die Migration eines Altsystems zu SOA vor, die darauf abzielen, eine SOA-Grenze zu definieren, die nur die "optimalen" Dienste und eine angemessene Granularität aufweist. Der Rahmen besteht aus drei Stufen. In der ersten Phase werden die Hauptkomponenten des Altsystems und ihre Interaktionen mithilfe von UML modelliert. In der zweiten Stufe werden Serviceoperationen und Serviceprozesse identifiziert. In der dritten Stufe werden identifizierte Service-Elemente nach einer vordefinierten Taxonomie von Service-Typen (z. B. CRUD-Services, Infrastructure-Services, Utility-Services und Business-Services) zusammengefasst. Während der zweiten und dritten Stufe werden Softwareanalysten durch Clustering-Techniken unterstützt, die automatisch ähnliche Dienstvorgänge und Dienste des gleichen Typs zusammenfassen. Diese Arbeit stellt einen Vergleich verschiedener Migrationsansätze vor. Zwei von ihnen zusammen mit ihren Pro-Profis sind in der Community gut bekannt, während der andere ein neuer Ansatz ist, der darauf abzielt, die Profis der beiden vorherigen Migration ohne ihre Nachteile zu erreichen. Im folgenden Abschnitt wird die für diese Analyse verwendete Fallstudie erläutert.

Fallstudie

Der in dieser Arbeit untersuchte Fall besteht aus einem datenzentrischen System, das aus mehreren Subsystemen zur Verwaltung von Datensätzen besteht, die sich auf Einzelpersonen beziehen, einschließlich vollständiger persönlicher Informationen, Beziehungen, Arbeitshintergrund, erhaltener Vorteile usw. Das System ist in COBOL geschrieben, läuft also auf einem IBM-Mainframe und greift mit etwa 0,8 PetaBytes auf eine DB2-Datenbank zu. Andererseits gibt es einige COBOL-Programme, die auf historische Daten über die VSAM-Methode (Virtual Storage Access Method) zugreifen, eine Speicher- und Datenzugriffsmethode, die in einer Reihe von IBM Mainframe-Betriebssystemen zum Einsatz kommt. Darüber hinaus wird auf einige COBOL-Programme nur über ein Intra-Net über 3270-Terminalanwendungen zugegriffen, während andere Programme in CICS-Transaktionen (Customer Information Control System) zusammengefasst und von Webanwendungen verwendet werden. CICS ist ein Transaktionsmanager, der für eine schnelle Verarbeitung mit hohem Volumen entwickelt wurde. Dadurch können mehrere Programme als atomare Aufgabe organisiert werden. In diesem Fall bestehen diese Programme aus Geschäftslogik- und Datenbankzugriffen, meist Eingabevalidierungen bzw. Abfragen.
Tabelle 1: Eigenschaften der wichtigsten Systemtransaktionen nach der Mainframe-Last in Bezug auf ausgeführte Aufrufe im Januar 2010.

tablesrt2MM

Zur Veranschaulichung wird in Tabelle 1 eine kurze Übersicht von nur 6 Transaktionen angezeigt. Diese zeigt die Anzahl der nicht kommentierten Quellcodezeilen2, die Anzahl der durchgeführten SQL-Abfragen und die Anzahl der Zeilen und Dateien, die einer Transaktion zugeordnet sind. Wenn ein Programm P1 ein Programm P2 aufruft oder eine Kommunikationsbereichsdefinition C (COMMAREA) importiert oder eine SQL-Definition S enthält, heißt es, dass P1 P2 oder C bzw. S zugeordnet ist. Im Durchschnitt hatte jede Transaktion 18 Dateien, umfasste 1803 Codezeilen und führte 6 SQL-SELECT-Anweisungen aus.