Publicitas Ltd.によって実施されたNACAプロジェクトで、400万行のCOBOLプログラムが自動的に同等のJavaプログラムに変換された。この会社によると、毎年の支出を合計で300万ユーロ削減でき、NACAプロジェクトで利用したこのツールをGPLライセンスでリリースしたそうだ。
Didier Durand氏とPierre-Jean Ditscheid氏は、先週開催されたJazoon09においてプレゼンテーションを実施した。これはオンラインで見ることができる。
Pierres氏は、「コード変換コンパイラ」のアーキテクチャについて次のように述べた。
- たくさんのレベルでのキャッシュが、古いアプリケーションの新たなJavaバージョンのパフォーマンスを最大化するのに役立つ。これらのキャッシュによって、Java変換されたトランザクション処理やバッチ処理はメインフレームで利用していたCOBOLよりも優れたパフォーマンスを発揮する。
- すべてのプログラム変数構造体(COBOLのCOMMAREA)をあらかじめメモリ上に配置しておくことで、パフォーマンスが改善されるとともに、実行中システムがフリーズしてしまうガベージコレクションを最小限に抑えることができる。
- Javaのオブジェクトによる強力なオブジェクト指向アーキテクチャによって、コンパイラによる制御を最大限活用できる。たとえば、それぞれのCOBOLプログラムは、ひとつのJavaクラスになり、その存在がコンパイラによって実行時ではなくコンパイル時にチェックされる。私たちのもののように400万行のコードからなるアプリケーションで、すべてのタイプミスを継続的インテグレーションによって検出しようとする場合には、とても有効なのだ。
- Eclipse IDEとの強固な統合により開発者の生産性を最大限引き上げられる：私たちは、古いCOBOLプログラムをEclipseからデバッグし編集するためのプラグインを開発さえした。
- 古いCOBOLプログラムと新しく変換されたJavaプログラムが行単位で対応している。社内の開発者が迷子になることがない：もともとのCOBOLバージョンとまったく同じ構造をもつJavaアプリケーションを手に入れることができるのだ。
- SunのJVMとともにIBMのJVMをサポートすることでストアド・プロシージャも変換可能だ。
- 異なるキャラクタ・セットとエンコーディング方式(EBCDIC)をメインフレームとLinuxでサポート。データのソートに関するあらゆる方式をサポート。
- 複数のレベルでのCOBOLのデータ構造を、Javaで利用されるUTFエンコーディング(1文字で2バイト)とは独立してJavaで完全に管理
- 含まれるフレームワーク(JVMそのもの、Apache、Tomcatなど)がアプリケーションから透過的
- 等々...
一方、Didiper氏は、このようなプロジェクトの主要な側面について、次のように力説した。
- 主要な推進力としての経済的な動機: 数百万(スイスフランまたはユーロ)のメインフレーム環境から、信じられないぐらい安価で機動力のあるLinuxのIntelベース・サーバー群への移行。大きな経費の節約(私たちの場合は、年間300万ユーロ)は、プロジェクトの投資回収をプロジェクト完了を待たずに早期に行える。私たちのような会社にとってオープンソースのよいところは、非常に低価格であることだ。
- テクノロジーで人々を動かす：プロジェクトが完了した時に非常に興味深い仕事を得るであろう人々に、初期段階で実際にそのことを示したことにより、成功できたのだと思う。このことによって、この人たちから、プロジェクトに対する完全な協力をえることができた。
- 同等の機能を必須とする：このような方式で移行を行うことにより、最終的なターゲットを数ヶ月議論するといったことを避けることができる。多くの場合、100%自動の移行が可能であり、コード変換に品質の主要な要因がある。
- ビッグバン方式ではなく、多くのやり直し可能なステップを実行する： このような数千(数万)の新たなステップの完全な移行は、一足飛びに行おうとすると、絶対に成功しない。ゴールへ絶え間なく少しずつ進むプロセスが、よりよいアプローチだ。よい結果として次のようなことがある：小さなステップは、問題が起こったとしても局所的な小さなトラブルしか起こさない。この方式では、ユーザはずっと辛抱強くなる。私たちの経験ではそうだった...。
これらのツールはダウンロード可能で、配布物には次のものが含まれる。
今日配布しているツール(v1.0)のzipパッケージには次のものが含まれる。
- Doc: ツールとライブラリの詳細を説明した一連のドキュメント。欠けている点の指摘など、このドキュメントに関するあなたからのフィードバックは、ドキュメントの改善のために欠かせない。
- NacaTrans (GPLライセンスで、約83,000行のコードと690のJavaクラスからなる): COBOLで書かれた400万行の私たちのPUB2000アプリケーションを100%自動でJavaに変換してくれたコード変換ツール。大部分をコンパイラの技術に基づいている。(100%有効なものと仮定し)COBOLプログラムの構造を解析し、XML形式で構造を表してから、最終的にNacaRTのランタイム・ライブラリ(このライブラリ自体はJLibに依存している)のファンクションをコールしたり、クラスを利用したらするJavaコードを生成する。この新しく生成されたJavaコードは、とても注意深く設計されている：それぞれのCOBOLの行から、意図的に対応するJavaの一行を生成している。これは、移行後のJavaプログラムの構造を理解しないければならない元々のアプリケーションの開発者や保守担当者がメンテナンスしやすいように、COBOLのコードと可能な限り似たものにしようとしているからだ。すべてのCOBOLの構文のパターンが完全に保証されるわけでは、もちろんない。しかし私たちの400万行のコードとそのほかのアプリケーションにおけるテストで、NacaTransにより現在カバーするCOBOLの範囲は、すでにかなり広汎なものになっていることが示されている。まだサポートしていない構造に関して、あなた方からフィードバックを受け取ることでカバー範囲を広げていきたいと願っている。
- NacaRTとJlib (LBPLライセンスで約153,000行のコードと890のJavaクラスからなる): アプリケーションの実行時のすべてのトランザクション処理を提供する２つのランタイム・ライブラリ。これらは、IBMのCICSのような古典的なトランザクション・モニタのすべての機能をエミュレートする。これらは、同時にCOBOLのすべての構成要素をサポートする(たとえば、複数のマスクデータ表現を含むCOMMAREA構造やCOMP-Xといった特定のデータフォーマットの管理など)。
- NacaRTTest (GPLライセンス): コード変換によるアウトプットを、参照するCOBOL構成要素に対してテストをするためのテスト・スイート。コード変換アルゴリズムの一部を検証する方法だ。NACAの新しいユーザにとって、これはスタート地点だ：これをインフラストラクチャで実行することで、パッケージのインストールに自信をもつことができるだろう。
COBOLには、50年にわたる歴史や、2500億行におよぶ現役のコードがあるので、このようなツールには、かなりの市場があるように思われる。