Entwicklung von COBOL-Applikationen unter Visual Studio

Rund fünf Billionen Dollar stecken weltweit in Legacy-Anwendungen. Es versteht sich, dass Unternehmen Investitionen in diesen Größenord-nungen nicht einfach abschreiben können. Vor allem in größeren Organisationen laufen die Kernprozesse daher nach wie vor über COBOL-Applikationen – ausgereifte, bewährte und zuverlässige Lösungen, die niemand ohne Not dem Risiko einer Neuentwicklung aussetzen möchte.

Die meisten IT-Leiter sind ohnehin froh, wenn wenigstens an einer Front Ruhe herrscht. In COBOL vorhandene Prozesse in anderen Sprachen neu zu formulieren, wäre außerdem wenig effizient; es wäre schon aufgrund der Code-Menge wirtschaftlich nicht vertretbar, würde die Softwareent-wicklung für Jahre blockieren und brächte schließlich keinerlei zusätzlichen funktionellen Nutzen. Anderseits: die Zeiten, in denen in der IT fundamental unterschiedliche technologische Ansätze einfach nebeneinander existieren konnten, sind unwiderruflich vorbei.

Systeme wollen heute integriert sein, womit sie nur den ihnen zugrunde liegenden, hochgradig integrierten Geschäftsprozessen folgen. Eine Lösung für die Warenwirtschaft muss heute reibungslos und eng mit einer für den Online-Vertrieb zusammenarbeiten können, auch wenn die eine in COBOL, die andere in J2EE oder .NET erstellt worden ist. Dabei muss die Integration selbstverständlich auf Applikationen-Ebene erfolgen, denn mit einer halbautomatischen Kommunikation per Filetransfer wird sich kein Unternehmen mehr abfinden.

Tatsächlich arbeiten diese Technologien längst sehr eng zusammen, beispielsweise wenn COBOL-Anwendungen die Abbildung von Geschäftsprozessen übernehmen und die Umsetzung am Front-End Java oder Visual Basic überlassen. Oder umgekehrt, wenn J2EE- oder .NET-Anwendungen auf die Legacy-Applikationen zugreifen und von ihnen nicht nur Daten, sondern auch Algorithmen abrufen. Nachdem in den letzten Jahren vor allem die Verbindung von COBOL mit Java und J2EE ausgebaut wurde, hat nun auch die Integration von COBOL in die in Europa weniger dominante .NET-Welt nachgezogen.

Um es kurz auf einen Nenner zu bringen: COBOL ist heute eine vollständige .NET-Sprache, die sich ohne Einschränkungen des gesamten .NET-Frameworks bedienen kann. COBOL funktioniert heute unter .NET nicht anders als .NET-Sprachen wie C# oder VB.NET. COBOL-Spezialist Micro Focus hat seine Entwicklungsumgebung Net Express bereits auf diese Integration in .NET ausgerichtet. Sie erstreckt sich sowohl auf die Ebene der IDE als auch auf Deployment und Laufzeit.

Die Integration von COBOL in .NET umfasst natürlich auch die Verwendung von Microsofts Visual Studio .NET als Entwicklungsoberfläche. Auch der COBOL-Entwickler arbeitet mit dieser IDE, nutzt die gleichen Werkzeuge (Editor, Debugger usw.) wie seine Kollegen. Wichtige, aus der Net Express IDE bekannte Funktionen und Tools wie z.B. der CBL2XML Wizard oder der OpenEsql Assistant wurden in die Microsoft Oberfläche integriert.

Damit kann der COBOL-Entwickler zunächst einmal die Gesamtheit der Features einer modernen Entwicklungsumgebung für seine Programmiersprache nutzen. Vor allem müssen bei einer gemischtsprachlichen Entwicklung nicht mehr unterschiedliche IDEs verwendet werden – es gibt nur einen gemeinsamen Editor, einen Debugger usw. für alle Sprachen. Natürlich sind damit auch für COBOL moderne Programmierfeatures wie IntelliSense verfügbar, also die Auflistung von verfügbaren Parametern einer Methode und die Aufnahme neuer Klassen in einem Programm.

Die gewünschten Informationen können im aktuellen Kontext gesucht, Sprachelemente direkt in den Code eingefügt und vervollständigt werden. Alle Möglichkeiten, die das .NET-Framework bietet, stehen auch für COBOL zur Verfügung, bestehende COBOL-Anwendungen können ohne Änderung nach einer Recompilierung weiterverwendet werden. Ein prozedurales, also ein nichtobjektorientiertes COBOL-Programm, wird dabei vom .NET-COBOL-Compiler in eine COBOL-Klasse umgesetzt und der Haupteinstiegspunkt als Methode abgebildet.

Die Integration in die .NET-Welt geht so weit, dass COBOL-Klassen von Klassen anderer .NET-Sprachen erben können, was auch in umgekehrter Richtung funktioniert. Diese hohe Integration hat weit reichende Auswirkungen für die praktische Entwicklungsarbeit mit COBOL unter .NET. So lassen sich Web Forms, Win Forms oder die Datenbankanbindung mit ADO.NET in vollem Umfang durch COBOL-Programme nutzen.

Besonders deutlich wird die Neuerung bei der Entwicklung von GUIs: Das Erstellen von grafischen und Web-basierten Oberflächen kann nun auch in COBOL mit Hilfe des Visual Studio Werkzeugs Forms-Designer erfolgen. Mit Hilfe des Designers werden die Formulare in der gewohnt komfortablen Weise erstellt, anstelle von C# oder VB wird aber von Net Express ein .NET-konformer COBOL-Code erzeugt, der anschließend auch manuell verändert und angepasst werden kann. Der (COBOL-)Entwickler erhält damit wieder die Möglichkeit, Anwendungen unter .NET vollständig in COBOL abzubilden und muss für die Erstellung von GUIs nicht mehr den Umweg über proprietäre Maskengeneratoren oder über andere Sprachen wie etwa VB nehmen, was natürlich weiterhin ebenfalls möglich ist.

Das Deployment von COBOL-Anwendungen unter .NET ließ sich mit Net Express auch bisher schon problemlos realisieren. Benötigt wird dazu, wie immer bei .NET, eine Laufzeitumgebung, die im .NET Frame-work Redistributable Package zur Verfügung gestellt wird und die die Common Language Runtime (CLR) und andere notwendige .NET Fra-mework-Komponenten enthält. COBOL-basierte .NET-Anwendungen benötigen auch eine COBOL-Laufzeitumgebung für die Abbildung der nicht .NET-sprachspezifischen Funktionen, zum Beispiel für das COBOL-Dateihandling. Diese Laufzeitumgebung stellt der Application Server bereit.

Die COBOL-Programme können in der Regel ohne Änderungen im Source-Code einfach recompiliert und als Managed Code unter .NET ausgeführt werden. Net Express erzeugt mit seinem COBOL-Compiler aus dem vorhandenen COBOL-Code nicht wie sonst in der COBOL-Welt üblich einen direkt ausführbaren Maschinencode, sondern Byte-Code gemäß der Microsoft Intermediate Language (MSIL). Die Programmaus-führung erfolgt dann innerhalb des .NET-Frameworks unter der Common Language Runtime (CLR), ihr obliegt das Memory Management, Threading, Error Control, Überwachung der Typen-Konformität usw.

Alle Vorteile der .NET-Architektur kommen auch COBOL zugute. Die Anwendungen, egal in welcher Sprache geschrieben, basieren auf dem gleichen .NET Framework,.Damit verhält sich COBOL in der .NET-Welt genauso wie andere .NET-Sprachen. Es ist auf dieser Grundlage ohne weiteres möglich, gemischtsprachige Anwendungen zu entwickeln, die beispielsweise COBOL, C#, VB.NET, C++ und ASP.NET verbinden. Anwender können dabei Komponenten unterschiedlicher Programmiersprachen nach Belieben kombinieren und so deren jeweilige Stärken gezielt nutzen, also zum Beispiel die Berechnung eines Versicherungstarifs mit COBOL vornehmen, den Benutzer-Dialog mit C# und eine eventuelle Web-Anbindung mit ASP.NET realisieren.

COBOL-Datentypen werden dabei auf .NET Datentypen abgebildet; eine OO COBOL-Klasse bildet dabei die Schnittstelle zwischen existierendem COBOL-Code und Nicht-COBOL-Programmen. Auch die Mischung von prozeduraler und objektorientierter Programmlogik ist auf dieser Basis ohne weiteres möglich. Die COBOL-Applikationen haben ja vollen Zugriff auf .NET Framework-Klassen. Was haben die Unternehmen von der Integration einer "alten" Program-miersprache in eine neue Applikations-Plattform? Eine COBOL-Renaissance in dem Sinne, dass Entwickler für die Erstellung neuer Anwendungen nun wieder massenhaft COBOL einsetzen, ist nicht zu erwarten. Vielmehr geht es darum, die enormen Werte, die noch immer in tausenden von COBOL-Applikationen stecken, besser nutzen zu können als dies in den letzten Jahren möglich war. Dazu muss COBOL ein integraler Bestandteil der modernen Applikations-Plattformen werden.

Die Integration von COBOL in das .NET-Framework erstreckt sich auch auf die Anbindung von Datenbanken mit ADO.NET. Embedded SQL aus COBOL-Applikationen lässt sich in unterschiedlicher Weise auf ADO.NET abbilden:

Ohne Code-Änderungen kann die Anbindung an die ADO-Schnittstelle über die traditionelle EXEC SQL Syntax erfolgen, mit der sich SQL-Anweisungen in den COBOL-Code eingebetten lassen. Ein Pre-Compiler löst die Statements auf und unterstützt dabei den direkten Aufruf von ADO.NET-Klassen.

Alternativ kann ADO.NET direkt adressiert werden, indem man das neue Statement "EXEC ADO" in den Code eingefügt, das anschließend vom Pre-Compiler gemäß den ADO.NET-Konventionen umgesetzt wird.

Auf beiden Wegen lässt sich die ADO.NET-Technologie ohne native API-Programmierung nutzen und damit SQL-Datenbanken wie Microsoft SQLServer oder Oracle ansprechen. Dabei kann sich COBOL die ADO.NET DataSets über Sprachgrenzen hinweg mit anderen .NET-Anwendungen teilen. Mit dem OpenESQL Assistant steht außerdem ein neues graphisches Werkzeug für die Arbeit mit ADO.NET zur Verfügung, mit dem die ADO-Statements per Mausklick deklariert werden können.