メニューボタン
IBMi海外記事2013.06.19

RPG対PHPのディベート

Paul Tuohy 著

オブジェクト指向プログラミングを学んでコードをきれいにする

ウェブ・アプリケーションとモバイル・アプリケーションの開発にサーバー・サイド開発言語を選択する

ウェブ・アプリケーションやモバイル・アプリケーションを開発する際に、IBM iのプログラマはRPG(とCGIDEV2を組み合わせる)かPHPを使ってサーバー・サイドのロジックを大量に記述します。ここ数年私がよく疑問に思うのはこのスクリプト言語のどちらを自分が好きなのかということです。個人的な好みでこの質問に答えるのは簡単なのですが、なぜどちらか一方なのか、なぜもう一方ではないのかについて最終的な結論を出すのは少々難しいのです。
本稿では、サーバー・サイド開発言語をウェブ・アプリケーションやモバイル・アプリケーションの開発に選択する場合に考慮すべきいくつかの点を説明します。また、RPGとPHPの強みと弱みにも触れてすべてを広い視野からみてみたいと思います。

木と森を区別する

まずはサーバー・サイド言語の全体像と詳細を見るところからはじめましょう。ウェブ・アプリケーションやモバイル・アプリケーションは5250アプリケーションのようには動作しません。したがって、どのスクリプト言語を使用したいと思っているかにかかわらず、ウェブ・アプリケーションがどのように動作するのかについていくつか知っておかなければならないことがあります。ウェブ・アプリケーションがどのように動作するのかを知っておくことで、スクリプト言語を使用して解決する必要のある問題に関する洞察も得られます。以下のことについて知っておく必要があります。

  • 階層設計
  • ウェブ・サーバーがすること
  • ステートレス
  • インタフェースの設計と保守
  • Ajax (Asynchronous JavaScript and XML)の使用 - 特にモバイル・アプリケーションの場合

階層設計

階層設計の概念は、インタフェースをビジネス・ロジックやデータベースなどの設計から切り離すことに関係しています。階層設計では基本的には、プログラム中の他のコンポーネントに影響を与えることなくコンポーネントを追加したり修正したりすることができます。この概念の最もわかりやすい例はモバイル・コンピューティングでしょう。理論的には、うまく設計された階層アプリケーションでは、モバイル・インタフェースを追加することでアプリケーションのビジネス・ロジックのデータベース・コンポーネントを変更する必要が生じてはいけません。新しいインタフェースを導入したらそのインタフェースが既存のビジネス・ロジックなどを利用するだけです。このアプローチの実装には通常、モデル・ビュー・コントローラ(MVC: Model-View-Controller)の設計を使用します。
もちろん、どの程度まで階層設計が可能かは既存のアプリケーションがどの程度整理された構造になっているのかに依存します。もうひとつの大事な要因は、アプリケーションのモダン化あるいは改善のためにサード・パーティー製のアプリケーションを使用しているか否か、もし使用している場合そのサード・パーティー製のアプリケーションがどのようにインタフェースを実装しているかです。そのようなサード・パーティー製アプリケーションの多くはRPGとPHPの両方の選択肢を提供していることは注目に値します。

ウェブ・サーバー

ウェブ・サーバー(この場合IBM i)の機能は、データを(通常はウェブ・ページの形式で)クライアント(たとえばブラウザ、モバイル・アプリケーション、Ajaxリクエスト)に送り届けることです。CGIDEV2もPHPも共にシステムが提供しているApacheサーバーを利用しています。また、PHPを使用するにはZendサーバーに加えてPHPからIBM iへのZendポートも必要です(PHP用に他のポートを使用することもできますが、それには構成や設定が追加で必要となります)。
ウェブ・サーバーを構成するということは、リクエストがどのように作られるのか、アイテムはどこに保存されるのか、セキュリティーの設定はどうすれば良いのか、などといったことを明確にするということを意味します。ウェブ・サーバーへリクエストが送られると最終的にはサーバーがクライアントへドキュメント(データ)を返すことになります。リクエストはサーバーに保存されているドキュメント(たとえばIFSのディレクトリに保存されているHTMLドキュメント)を取り出したいのかもしれませんし、スクリプトを実行したい(たとえばプログラムを呼び出したい)のかもしれません。これによりクライアントに返されるドキュメントが動的に作成、構築されます。
スクリプトを呼び出す必要があるということは、何らかの作業が行われているということを意味します。たとえばデータベースからのデータの取り出しやビジネス・ロジックの適用、あるいはその両方などです。これによりスクリプト言語についての質問がいくつか生じます。HTMLやデータベース、ホスト言語呼び出しなどとどれくらいうまく統合できるのでしょうか。

ステートレスの世界

ステートレスとはブラウザとサーバー・ジョブの間に永続的な接続が存在しないということです。 理論的には、ブラウザやクライアントからの各リクエストを異なるジョブが処理するかもしれません。したがって、スクリプトはリクエストが常に同じクライアントから来るとは仮定できないので、スクリプトは呼び出し間で特殊なステップを使用してクライアントからの変数値(ステート情報)を保存しなければなりません。この情報は、クライアントからのリクエストを処理する可能性のある任意のサーバー・ジョブに対してすぐに利用可能な状態になっていなければなりません。
となるともう一つの疑問がわいてきます。スクリプト言語は永続性をどのように処理しているのでしょうか。ステートレスの記述が昔どこかで見たことがあるような印象を与えるのであれば、それは私と同じくらいプログラミング経験が長いということで、しかもSystem/34やSystem/36上のMRTプログラムのかすかな記憶がおありということかもしれません。もちろん、これはサード・パーティー製アプリケーションを使用することの大きな恩恵の一つではあります。自動的に永続性を処理してくれるからです。

綺麗な絵を描く

ウェブ・インタフェースを設計して保守するにはHTML、カスケーディング・スタイル・シート(CSS: Cascading Style Sheet)、JavaScriptの専門知識がある程度必要です。アプリケーション中で使用するAjaxの量によっては、JavaScriptの基本的な理解以上のことを求められる場合もあります。
ユーザー・インタフェース(ウェブ・ページやモバイル・アプリケーション)を実装することは、かつてほどはとっつきにくいものではありません。むしろ、フロント・エンドのコーディングを支援してくれるフレームワークや開発ツールの選択肢がたくさんあって私たちは甘やかされているのです。しかもjQueryやExtJSなどといったフリーで利用できるライブラリを使用することで、(ウェブ・ページの中身の操作とAjax呼び出しの処理の両方で) JavaScriptの複雑性を大幅に簡素化できます。

Ajax

Ajaxはブラウザとサーバー間の非同期通信のための手段です。Ajaxを使用すると、JavaScriptの関数はウェブ・ページを使用中にサーバー上のスクリプトと「会話」をすることができます。
Ajaxは最もモダンなウェブ開発の中心にあるものであり、HTML5やJavaScriptに基づいたモバイル開発にとってはほとんど必須のものです。またAjaxを使用するには、JavaScript Object Notation (JSON)またはXMLを使用してクライアントとサーバー間でやり取りされる情報をフォーマットするための実際上の知識も必要となります。

簡易比較

CGIDEV2とPHPの両方を使って、どこにでも見られる「hello world」のプログラムと同等のものを見てみましょう。CGIDEV2はドキュメントをメモリ上で構築してウェブ・サーバーに送信するメカニズムを有しています。このテクニックを使用するには、HTMLのテンプレート・ドキュメントとRPGプログラムが必要となります。図1で、テンプレートは標準のHTMLドキュメントで、CGIDEV2によって認識される2つの特殊なディレクティブがあります。

  • 呼び出しAで、top はセクション名です(その前にある/$でそれがわかります)。これはDDSにおけるフォーマット名と等価です。
  • 呼び出しBで、today は変数名です(前後の/%と%/でそれがわかります)。
  • H仕様(呼び出しC)は束縛ディレクトリを示し、そのディレクトリにはCGIDEV2サービス・プログラム用のエントリが含まれています。
  • 2つのinclude ディレクティブ(呼び出しD)は、CGIDEV2で必要なプロトタイプの定義を含んだソース・メンバーを示しています。
  • 呼び出しEでは、getHTMLIFSプロシージャがHTMLテンプレート・ドキュメントをメモリにロードしています。
  • updHTMLVar プロシージャ(呼び出しF)はtoday 変数の値を変更します。
  • wrtSectionプロシージャ(呼び出しG)はドキュメントの中身をメモリに書き出し、特殊値*finiがあるために、ドキュメントをウェブ・サーバーに送り返します。するとサーバーがさらにそれをクライアントに返します。

これと同様の動作をするPHPを図2に示します。PHPはHTMLとやり取りする方法が柔軟です。PHPをHTML中に埋め込むこともできますし(呼び出しA)、プログラムの実行中にHTMLを構築することもできます。PHPの命令をHTMLに埋め込むときは、必要なPHPコードを<?phpディレクティブと?>ディレクティブで囲むだけです。図2に示す例では、説明するまでもないprint操作を使ってDate関数から帰ってきた値を提供しています。

CGIDEV2とは

CGIDEV2はフリーのツールキットで、ウェブ・サーバーの入出力処理、外部で記述されたHTML、データの処理と検証、メッセージのフォーマットと処理、エラー処理とレポート、デバッグなどといった様々な機能の取り扱いを支援する機能を提供するサービス・プログラムで構成されています。CGIDEV2が世の中に出てから長い年月がたち、時代の課題に応えてきています。大小さまざまな企業がCGIDEV2を中心に完全なウェブのプレゼンスを構築してきました。(メル・ロスマン氏がツールを開発した頃、それがどれくらい業界にインパクトを与えるのかわかっていたのだろうか、と思います。)
CGIDEV2はその名前の中にCGIという部分を含んでいますが、実際にはCGIのプログラミングではありません。CGIDEV2の中心となっているのは、CGI APIの複雑さを取り扱う必要がないことを保証するということです。CGI APIは舞台裏でこっそり使用されていますが、その奇妙な特異性に正面から取り組む必要はないのです。CGIDEV2のソースコードの全てと、チュートリアルおよびサンプル・アプリケーションをeasy400.netからダウンロードすることができます。

なぜCGIDEV2を使うのか

CGIDEV2は非常に学習しやすい開発環境です。つまりRPGなのです。必要なのはCGIDEV2のサブプロシージャを理解することだけです。そのうちの5つはごく短時間で使えるようになりますし、さらにそのうちの3つのgetHTMLIFS()、updHTMLVar()、wrtSection()はすでに図1で見ていますので。「ウェブ」プログラムをRPGやCGIDEV2で書くのは、5250でプログラムを書くのに比べると単純でずっと簡単です。
RPG内でCGIDEV2プログラムを書こうとしているわけですから、プログラムはもちろんデータベースやホストの言語呼び出しに対して容易なアクセスを提供しています。プログラムはサーバー・ジョブ内で実行されることになることを覚えておいてください。ユーザーがブラウザからログオフしてもジョブが終了するとは限りません。
CGIDEV2のもう1つの利点はその高速性です。クライアントがリクエストをどれくらいすばやく作成するのかに応じて、1つのジョブで複数のリクエストに対応することができます。

なぜCGIDEV2を使用しないのか

CGIDEV2を試しに使ってみるにはIBM iシステムにアクセスする必要があります。CGIDEV2のインストールは簡単です(ライブラリを回復して設定プログラムを実行すればサーバーなどを構成してくれます)が、開発環境、開発用マシンのセキュリティーの強固さ、ネットワークやファイヤーウォールの懸案によっては、いまからやろうとしていることがアルマゲドンをもたらすものではないことを責任者に説得するのが難しいかもしれません。(これが、私がイライラすることの1つだとわかりますか?)
お使いの環境でステートレス用の独自のソリューションを考案する必要が生じるでしょう。それには通常、各クライアントに対してユニークなIDを生成するテクニックとそのIDをクライアントに保存するメカニズム(クッキーまたは隠しフィールドを使用)、およびキュー、ファイル、またはユーザー空間(私が好むのはこの方法)を使用してステート情報をサーバー上に保存する方法を開発することが必要です。これは難しいことではありませんし例もたくさん入手可能ですが、このテクニックを開発し、その必要が生じたときに求められた通りに実装する必要があります。
CGIDEV2は他のスクリプト言語に比べるとHTMLにはそれほど強固に統合されていませんので、ドキュメントを生成する際には想像力を発揮しなければならないときがあります。HTMLテンプレートも複雑になる可能性があります。また一部の機能(たとえば電子メールの送信、JSONのフォーマット)は他のスクリプト言語では標準とみなされていますが、CGIDEV2では追加でアプリケーションをダウンロードして統合しなければなりません。
CGIDEV2はニッチな製品なので(つまりIBM i上でしか動作しません)、他のウェブ・ソリューション程には多くの例やツールやフレームワークが見つからないでしょう。しかしCoralTree Systems社のRenaissance Framework(http://www.renaissanceframework.com/)はCGIDEV2上に構築された素晴らしいフリーのフレームワークです。

なぜPHPか

PHPは1990年代中ごろに「Personal Home Pageツール」として始まってから長い歴史を持っています。(ところで、PHPの意味は今や「PHP: Hypertext Preprocessor」という再帰的頭字語になっています。) PHPはオープン・ソースの解釈実行型のスクリプト言語で、ウェブ・プログラミングに主眼を置いて設計されています。ブラウザからの入力の処理、例外の配列処理(RPGにもこれがあればと思います)、多数の組み込み関数など強固な言語機能を備えています。(RPGなどのような)プロシージャ・スタイル、オブジェクト指向(OO)スタイル、あるいはその両方を使用してPHPを記述することができます。プロシージャ・スタイルではRPGのプログラマはPHPをすばやく習得でき、それから必要があればOOスタイル側に簡単に入っていけます。

なぜPHPを使うのか

PHPはウェブ開発用の言語の中で最も人気のある言語です。その人気の高さは習得のしやすさにあるからだとする人もいます。試しに使ってみるのに必要なのは、PCと自由に利用可能な無数のAMP (Apache、MySQL、Perl/PHP/Python)のソリューション・スタックのうちの1つで、これらは自分のPC上でスタンドアロンのPHPサーバーを実行するのに使用します。ソリューション・スタックを使用することで、IBM i上では何もする必要もなくPHPのスキルを磨くことができます。システムからデータを取り出すこともできます。
最終的にはPHPをIBM i上で試してみたくなるでしょう。IBM iはV5R4以後、Zend Serverがプレインストールされています。PHPを使い始めるにはZend Serverを起動するだけでよいのです。
PHPはHTMLともうまく統合されています。つまりPHPはウェブを念頭に置いて開発されたのです。このような人気があって広く使用されている言語に対してはフレームワーク、開発ツール、例が豊富にあるはずだと期待されることでしょう。IBM Rational Developerと同様のEclipseベースのPHPのIDEであるZend Studioのフリー・コピーを入手することさえできます(zend.com)。私はまだ試していませんが、Zend StudioをRational Developerのプラグインとしてインストールすることもできます。
またPHPは$_SESSIONという特殊な配列を使用することでステートレスを処理する組み込みのメカニズムも有しています。PHPは複数のプラットフォーム上で利用可能なので、対処しようとしている問題のほとんど全てを解決するのに役立つ情報がウェブ上に豊富に見つかります。またIBM i以外のPHPサーバー上で動作するアプリケーションと同様に、IBM i上にインストールして実行可能なオープン・ソースの完全なアプリケーションも多数あります。

なぜPHPを使用しないのか

PHPは習得するのが簡単な言語ではありますが、スキルを構築するには時間的投資を必要とする新しい言語です。PHPのスキル構築と、HTML、CSS、JavaScriptなどの習得を同時に行うのは少々気が遠くなるかもしれません。
前述のとおりPHPは解釈実行型の言語ですからすばやく実行できますが、その実行速度はコンパイルされたプログラムには決してかないません。PHPから直接データベースにアクセスするにはSQLを使用する関数を使用します。しかしSQLの速度にどれくらいついていけていますか?お使いのデータベースはSQLアクセスに対してどれくらい準備ができていますか?
PHPからRPGプログラムを呼び出すのはどうでしょう。PHPから直接呼び出すことができる関数がいくつか提供されていてそれを使用することができますが、それはRPGからプログラムを呼び出すほど簡単ではありません。もうひとつの方法はRPGプログラムをSQLのストアード・プロシージャとしてラップし、それをデータベース関数を使って呼び出すというものです。

RPGかPHPか

ウェブ・アプリケーションやモバイル・アプリケーションの開発にどちらのスクリプト言語を私が使用するかというと、答えは両方です。どちらを使用するかはスクリプトに何をさせたいかによります。複雑なHTMLの構成が必要な場合はPHPの方を使いたいと思います。スクリプト中にビジネス・ロジックやデータベースへのアクセスが多数含まれる場合はRPGを使う方を選びます。スクリプトがAjaxのリクエストに応答するのであればどちらもあまり差はありません。JSONやXMLの応答をフォーマットするにはRPGでもPHPでも簡単です。
最初はPHPで生成されたのにRPGプログラムを呼び出すAjaxを含んでいるページも珍しいことではありません。アドバイスさせていただくとすると、それぞれのジョブに適したツール使うということです。実現しようとしていることが何であれ、その要件に一番合致した言語を選択して使用してください。RPGとPHPを組み合わせて使っても構いません。RPGとCLを切り替えて使用するよりはRPGとPHPを切り替えて使った方が容易でしょう。

あわせて読みたい記事

PAGE TOP