Profound Logic社、Node.jsおよびCOBOLの新たな方向性を探り出す
IBM iコミュニティでオープン ソースの話題が頻繁に話されるようになるにつれて、Node.jsについての話を耳にすることが多くなりました。その一方で、COBOLは、エンタープライズ ビジネス アプリケーションの80％がこの頑強なコードで動いている割には、あまり注目が集まらなくなっているようです。モダナイゼーションへの取り組みを先導するIBM iベンダーの1つである、Profound Logic社は、これら両方の言語を自身の製品ロードマップに組み込んでいます。Profound社CEOのAlex Roytman氏は、なぜそうするのか、なぜ今なのかについて説明しています。
まずは、Node.jsから始めましょう。オープン ソース ソフトウェアに対するIBM iのサポートは、近年強化されていますが、オープン ソースはIBM iにとって目新しいものというわけではありません。Apache HTTP Server、Java、PHP、MySQL、Rubyは、そうした例としてよく知られています。他の言語と比べると、Node.jsには、他にはない1つの特長があります。それは、クライアントとサーバーとの両方で使用できる点です。そのため、バックエンドとフロントエンドとで別々の開発チームを作らなくても済みます。これはグリーンスクリーン開発の利点と同様とみなしてもよいかもしれません。もちろん、違いは、グリーンスクリーンはある種のデータ処理の場面でのみ効率的であり、それ以外の場面では好まれていないということです。
「弊社ではRPGをサポートしており、それを強力な言語と考えていますが、なかにはRPGは自社に合う環境ではないと判断している企業もあります。そうした企業では、より適したコードへのマイグレーションを考えています」とRoytman氏は述べます。
そうした企業にとって有意義なことは、古いRPGコードのメンテナンスに費やす時間と、RPGを扱うスキルを持ったプログラマを探すのに費やす時間が少なくて済むことです。多くの企業が言うところによれば、これらは、最も苛立たしい作業だということです。2015年末にProfound Logic社が実施した調査によると、IBM iのショップでは、最大の懸念事項として、コードのメンテナンスと、RPGスキルを見つける難しさとの2つが挙げられているとのことです。
Roytman氏は、Node.jsがIBM iコミュニティに与える影響はかなり大きいだろうと予想しています。
「すべてのRPGショップがすべてのコードをNodeに変換し始めるとは思いませんが、一部のRPGショップにとっては適切なことなのかもしれません」と彼は述べます。成功の鍵の1つは統合です。そして統合の鍵になるのは、Roytman氏によれば、Profound社がIBM iショップのために作成したNode.jsフレームワークなのだそうです。
Profound社のNode.jsフレームワークでは、5250プログラムが1つの開発パラダイム内でグラフィカル アプリケーションを呼び出すことが可能です。これはサイロが異なると開発のタイプも異なるのとは対照的です。
RPGまたはCLプログラムは直接Nodeプログラムを呼び出すことができ、また、NodeプログラムはRPGまたはCLプログラムを呼び出すことができます。そのようにできるのは、Node.jsで開発された新しいアプリケーションは、グリーンスクリーン ディスプレイまたはグラフィカル ユーザインターフェースのいずれかにより開発された、既存のRPGアプリケーションに依存している傾向が強いいためです。そうしたインターフェースは、Profound社の用語でリッチ インターフェースと呼ばれています。
「Node.jsは、すぐさま統合できてしまうものではありません」とRoytman氏は語気を強めます。「Nodeは、IBM iでは通常、独立した環境に置かれています。Nodeは5250セッションの外部でRPGプログラムを呼び出すことができますが、ステートフルな環境に何百、何千ものスクリーンが組み込まれた巨大アプリケーションでは、Nodeを差し込むだけというわけにはいきません。弊社では、既存のIBM iシステムから、システム稼働中に、どのようにしたらシステムの一部を移動できるかについて把握しています。」
Node開発コミュニティは、オープン ソース特有のやりかたで、コミュニティで作成されたコードを活用しています。そして、そうした「packages」と呼ばれるパッケージが、IBM iの開発で利用できるようになっています。利点としては、コードのパッケージを使用することで、記述やテストに必要となるコード全体の量を減らせることです。また、ゼロからコードを記述する場合に起こりがちな「車輪の再発明」を避けることができます。
Profound社が開発してきたNode.jsツールは、このフレームワークだけではありません。同社ではRPGからNode.jsへの変換ツールの開発も行っています。
RPGはバックエンドの開発言語であるため、コードがモノリシックであったり、最新のコードであれば実現できることが、できなかったりするケースに遭遇することも珍しいことではありません。そうしたことこそが、メンテナンスに手がかかるコードたる所以であり、そうした古いコードを稼働させ続けてきたこれまでの努力に代わる選択肢として、IBM iのショップがマイグレーションを検討したくなるのも無理のないことかもしれません。
Nodeスキルがある企業の場合は、既存のコードをNodeコードに変換することで、コードのメンテナンスや理解がしやすくなります。
RPGからNode.jsへの自動変換は、まだボタンを押せばできるという段階には至っていません。
「不可能な任務のようにさえ思えますが、弊社ではそれを行いつつあります」とRoytman氏は述べます。もっとも、現時点ではそうした変換機能は準備万端というわけではないようです。Profound社では、このツールは同社のスタッフが顧客サービス業務の際に使用すると述べています。Roytman氏に言わせれば、デモとproof of concepts（概念実証）に使える段階ということのようです。
「例外というものは避けられないため、自動変換ではコードの90％しか処理できません。残りの10％は手作業で変換を行う必要があります」とRoytman氏は述べます。
RPGコードは最新のモジュラー型コードである必要はありませんが、このツールは固定形式のRPGの変換を行うものです。System/36の時代からの、かなり旧式の内部記述ファイルの処理は想定されていません。また、変換では、データベース アクセスが標準方式で行われていることが必要です。標準方式でないアクセスは誰もが認めるより頻繁に行われているようです。もちろん、自動でのRPGからNode.jsへの変換プロセスでは、スパゲッティ コード（血統の疑わしいコード構成）は、JavaScript出力においても、同じように絡み合ったままで出力されます。
「弊社では、お客様とは1対1での対応を行います。製品をパッケージ化しておいて、お客様に変換ボタンを押してやってみてくださいと言う、というような対応は行いません。」 Roytman氏は変換ツールについてそう述べます。「弊社では、機能の説明のために、関係各社に対してデモを行ってきました。概念実証が行われ、そのうち各社が評価をしてくれると思っています。
COBOLのモダナイゼーション
Profound社は、何年にも渡って、モダナイゼーション事業に取り組んできました。そのなかで、COBOL開発が依然として業務に必要不可欠であり続けているIBM iのショップのIT管理者と話をする機会が何度もありました。そのような機会があまりに多かったことから、Profound社では、COBOLのモダナイゼーションが事業目標の1つに加えられるに至っています。
「弊社のCOBOLプリプロセッサを使用することで、COBOLアプリケーションへのRich UIおよびOpen Accessのメリットを拡大できます」とRoytman氏は述べます。「代わりの「compile」コマンドと弊社のOpen Access Handlerを使用するだけで、それらの企業は、RPGアプリケーション向けに作成できたのと同じ、最新のWebおよびモバイル グラフィカル インターフェースを簡単に構築できるようになります。」
現在、Profound Logic社の一部の顧客で、COBOLプリプロセッサのベータテストが行われているとのことです。
アクティブなインスタンスおよびセッションの管理
顧客フィードバックによってソフトウェア開発者が動かされ、既存製品に新機能が取り入れられることはよくあります。今回のケースでは、Profound UIの実装の管理およびデプロイを支援するソフトウェアの開発に、Profound社の顧客が直接、影響を与えました。今回、強化された機能は、アクティブなインスタンスおよびセッションを管理するためのコマンド ライン インターフェース ツールであり、これはProfound UIのすべての顧客が利用できるようになっています。今回の機能強化プロジェクトをリードしたのは、Scott Klement氏であり、その名前は、多少でも関心を持っているすべてのRPGプログラマにとっておなじみの名前です。Profound社ではこの機能をWork with Profound UIと呼んでいます。
この機能は、多くのIBM iユーザに親しまれている、IBMのWork with Active Jobsコマンドと多くの点で似ています。Work with Active Jobsになじみがあれば、この機能がグリーン スクリーン セッションの管理と同じように有用であることに気付くことでしょう。Profound社では、その機能はWebおよびモバイル インターフェース セッションの管理には適さないと考えていました。各種のタスクのためにさまざまな種類のジョブを立ち上げるためです。そこでKlement氏は、HTTPインスタンス、5250からスクレイプされたインタラクティブ ジョブ、アプリケーション ジョブ、コントローラ ジョブ、およびステートレス ジョブ間の管理、編成、および識別を行うツールの設計に着手しました。
このツールの機能には、どのユーザが使用しているか、いつ使用しているか、どのリソースが使用されているかといった、Profound社のアプリケーションについてどんなことが起こっているかを表示する機能があります。たとえば、HTTPインスタンスを管理し、任意のシステムでProfound UIがどのように動作しているかを判定できます。顧客にとって有用な機能ですが、Roytman氏は、Profound社ではこの機能を、顧客のサポートにおいて、サポートのリクエストに関して情報収集を行う際に使用していると述べています。
「このツールは、CPU使用率のようなシステム パフォーマンスの問題の解決方法を模索していた弊社のお客様から生まれたものです」とRoytman氏は述べます。「この機能はWork with Active Jobでは提供されない、役に立つ必要な詳細情報を提供してくれます。」
Work with Profound UI Instancesツールは、Profound UIの既存の顧客であれば、追加費用なしで利用できます。
