Ein Translator für die COBOL-Java-MigrationUwe Erdmenger, Denis Uhlig

pro et con Innovative Informatikanwendungen GmbH, Dittesstraße 15, 09126 Chemnitzuwe.erdmenger@proetcon.de, denis.uhlig@proetcon.de

AbstractIn [1] wurden von pro et con bereits erste Ansätze der Mi-gration von COBOL nach Java dargestellt. Nach dem er-folgreichen Abschluss des Projektes SOAMIG1 sollen indiesem Beitrag die Ergebnisse im Bereich der COBOL-Migration vorgestellt werden. Neben einem Überblicküber das entstandene Werkzeug CoJaC (COBOL to JavaConverter) sollen dabei die Migration der Schnittstellen ei-nes COBOL-Programms und eine differenzierte Betrach-tung des generierten Java-Codes bezüglich seiner Wartbar-keit und Qualität im Vordergrund stehen.

1 CoJaC - COBOL to Java ConverterCoJaC besteht aus einer Reihe von Werkzeugen(toolchain), welche in ihrer Gesamtheit die Konver-tierung von COBOL-Programmen in Java-Klassenermöglichen. Alle Werkzeuge sind Entwicklungen vonpro et con. Es handelt sich dabei um Komponentender hauseigenen Software Reengineering Architecture(SRA [2]), welche für diese Funktionalität orchestriertwurden. Die folgende Abbildung zeigt einen Überblickdes gesamten Werkzeugs:

Die Ein- und Ausgaben des Werkzeugs sind mit COBOLbzw. Java vorgegeben. Als Schnittstellenformat der ein-zelnen Verarbeitungsschritte kommt bei CoJaC XML zumEinsatz. Alle Werkzeuge der SRA nutzen ein einheitlichesModell zur Abbildung von COBOL respektive Java. DieModellierung erfolgt in einem eigenen Format, welchesvom Metatool mk_obj verarbeitet und den anderen Werk-zeugen in entsprechender Form zur Verfügung gestelltwird. Bei CoJaC kommt das Modell als XML-Schema undDefinition der internen Darstellung (C++) zum Einsatz.Den Einstieg in die Verarbeitung bildet das COBOL-Frontend. Die COBOL-Programme werden analysiert undin das bereits beschriebene Zwischenformat überführt. Dieentstandene XML-Datei ist die Eingabe des Modelltrans-formators. Dieser baut auf dem regelbasierten Metawerk-zeug TransR auf. Der Transformator überführt den ihmübergebenen COBOL-Syntaxgraphen in eine Menge vonJava-Graphen und stellt diese in Form von XML-Dateienbereit. Abschließend werden diese Ausgaben durch denJava-Generator JGen und den Formatierer JFormat inJava-Quellcode überführt.

2 Realisierung der eingebetteter SystemeNeben der interaktiven Kommunikation zwischen Pro-grammen haben externe Datenbestände im Allgemeineneine große Bedeutung für produktive COBOL-Systeme.Dazu zählen unter anderem Dateien und Datenbanken.Bei der Migration eines Legacy-Systems müssen alle die-se Schnittstellen bzw. deren Zugriffsoperationen migriertwerden. CoJaC unterstützt in der aktuellen Version die Ab-bildung von COBOL-Servern in Java Webservices und dieMigration von COBOL-Dateien und embedded SQL.Bei der Abbildung der Kommunikationsschnittstellen derCOBOL-Server als Services wird auf die Möglichkeitender Java Webservices zurückgegriffen. Je ein COBOL-Server bildet einen Webservice. Für die Realisierung desServices kommt ein Bottom-Up-Verfahren zum Einsatz.Als erster Schritt des Verfahrens erfolgt eine Analyse derbisherigen Schnittstellen, welche zumeist über eine Midd-leware (z. B. TUXEDO) bedient wurden. Die Kommuni-kation findet über Messages in einem spezifischen Formatstatt. Das Message-Format wird in den COBOL-Serverndefiniert. Auf Basis dieser Informationen wird im zwei-ten Schritt der Verarbeitung eine Java-Klasse mit einerSchnittstellen-Methode generiert. Diese bedient das nachJava umgesetzte Meldungsformat. Die Methode und dieKlasse werden über Annotationen (z. B. @WebMethod,@WebService) markiert. Anschließend werden vorhande-ne Werkzeuge wie JAXWS genutzt, um den eigentlichenWebservice zu erstellen und in Betrieb zu nehmen.In COBOL gibt es Dateien verschiedener Speicherorgani-sation (sequentiell, index-sequentiell, relativ). Die Umset-

zung der Dateien aus COBOL sieht vor, die vorhandenenDateien in Datenbanktabellen zu überführen. Die Informa-tionen zu Dateinamen, Organisationsstrukturen, Schlüs-selfeldern sowie die Satzstruktur werden in einem vor-gelagerten Analyseschritt aus den COBOL-Programmenermittelt. Auf Basis dieser Informationen werden SQL-Skripte zur Erstellung der Datenbanktabellen generiert,welche die COBOL-Dateien repräsentieren. Die Migrationdes COBOL-Programms orientiert sich an der von CoJaCvorgegebenen Strategie. Die in COBOL vorhandenen Be-fehle zur Interaktion mit Dateien werden als Aufrufe vonMethoden nach Java übernommen.Auch embedded SQL wird nicht direkt übernommen, da esin Java keinen echten Präprozessor gibt, welcher die einge-betteten SQL-Kommandos umsetzen würde. Aus diesemGrund werden die vorhandenen statischen SQL-Befehle indynamisches SQL überführt. Da bei dieser Umsetzung vielorganisatorischer Code notwendig ist (Datenbankverbin-dung herstellen, Exceptions behandeln, ...), werden, ana-log zu der Umsetzung der Dateien, Funktionen in einemLaufzeitsystem bereit gestellt.

3 Wartbarkeit und CodequalitätGeneriertem Quellcode wird nachgesagt, nur schwer oderüberhaupt nicht wartbar zu sein. Dass dieses Vorurteilnicht zutrifft, wurde jedoch schon mehrfach bewiesen. Alsein Beispiel seien die aus der Programmiersprache SPLautomatisch generierten C++-Programme aus dem ProjektARNO [3] benannt. Auch für das Werkzeug CoJaC wur-de die Wartbarkeit und Lesbarkeit des Quellcodes als ei-ne wesentliche Eigenschaft des Werkzeuges definiert. Diedaraus entstehenden Vor- und auch Nachteile sollen in denfolgenden Abschnitten diskutiert werden.Ein wesentliches Konzept von CoJaC ist die Abbildungeines COBOL-Programms in ein semantisch äquivalentesJava-Programm bzw. eine Java-Klasse. Das bringt natür-lich mit sich, dass die bestehende Programmstruktur über-nommen wird. Wenn im Legacy-Code eine nach aktuel-len Gesichtspunkten ungünstige Struktur vorlag, wird die-se mit migriert. Wenn die Struktur verändert werden soll,muss sie entweder schon im Legacy-System (Sanierung)oder im neuen Java-System (Refaktorierung) vorgenom-men werden.Die COBOL-Datenobjekte werden in Java zu Objek-ten von Klassen der Laufzeitbibliothek, welche ausden COBOL-Typen abgeleitet wurden. Diese Klassenbilden die Eigenschaften der entsprechenden COBOL-Datentypen ab. Sie wurden darüber hinaus mit den ent-sprechenden Java-Standard-Typen (z. B. CharSequence,Number) verknüpft. Dadurch ist für die Weiterentwicklungdes migrierten Systems die Möglichkeit gegeben, auchnach Java-Standard zu entwickeln, ohne an das durch dieMigration vorgegebene Typsystem gebunden zu sein.Auch das Laufzeitsystem an sich ist eine wichtige Design-Entscheidung bei diesem Ansatz. Es erlaubt die Verwen-dung von kurzen und sprechenden Aufrufen in den gene-rierten Klassen, da die Implementierung der Funktionali-

tät „versteckt“ werden kann. Das hat zur Folge, dass dergenerierte Quelltext kurz und verständlich bleibt. Da dieAufrufe aber kein „reiner“ Java-Quellcode sind, wird einegewisse Bindung an das Laufzeitsystem unabdingbar. Ei-ne zukünftige Weiterentwicklung ohne die Laufzeitfunk-tionen ist aber dennoch möglich.Der gewählte Ansatz stellt einen gesunden Kompromisszwischen der Übernahme alter Strukturen und Funk-tionen in einen typschen Java-Quelltext dar. Dadurchwird der Quelltext für sowohl COBOL- als auch fürJava-Entwickler les- und wartbar. Selbstverständlich kannCoJaC an spezielle Kundenwünsche flexibel angepasstwerden.

4 ZusammenfassungAls Ergebnis des Projektes SOAMIG kann die erfolgreicheKonvertierung von COBOL-Legacy-Programmen in JavaWebservices betrachtet werden. In einer Fallstudie wur-de die Einsetzbarkeit des Verfahrens bereits nachgewiesen.Darüber hinaus ist der Ansatz, Quellcode zu erzeugen, derles- und wartbar ist, tragbar und Erfahrungen zeigen, dassder generierte Quelltext ca. die zwei- bis dreifache Zeilen-anzahl (Lines of Code) umfasst. Da aber im Verfahren be-reits Ansätze zur Strukturierung enthalten und in der Java-Welt mannigfaltig vorhanden sind, kann diese Größe alsvertretbar bezeichnet werden. Die Performance der gene-rierten Programme entspricht der neu entwickelter Java-Programme.

Literaturverzeichnis[1] Erdmenger, U.: Vom COBOL-Server zum Java-

Webservice.12. Workshop Software-Reengineering (WSR 2010),Bad Honnef 3.-5. Mai 2010In: GI-Softwaretechnik-Trends, Band 30, Heft 2,ISSN 0720-8928, S. 64 und 65

[2] Erdmenger, U.; Kaiser,U.; Loos, A.; Uhlig, D.:Methoden u. Werkzeuge für die Software Migration.In: Gimnich, R.; Kaiser, U.; Quante, J.; Winter,A. (Eds.): 10th Workshop Software-Reengineering(WSR 2008), 5.-7. May 2008, Bad Honnef.Lecture Notes in Informatics, (LNI)-Proceedings,Volume P-126, S. 83-97

[3] Erdmenger, U.: SPL-Sprachkonvertierung im Rah-men einer BS2000 Migration8. Workshop Software-Reengineering (WSR 2006),Bad Honnef 3.-5. Mai 2006In: GI-Softwaretechnik-Trends, Band 26, Heft 2,ISSN 0720-8928, S. 73 und 74

1Das vom Bundesministerium für Bildung und Forschung geförder-te Projekt SOAMIG beschäftigt sich mit der Migration von Legacy-Software in serviceorientierte Architekturen. Es wurde von pro et conInnovative Informatikanwendungen GmbH, Amadeus Germany, dem In-stitut für Softwaretechnik der Universität Koblenz-Landau (IST) undOFFIS e. V. als Partner im Verbund realisiert.