サーブレット／JSPをほかの言語と比較する：基礎から学ぶサーブレット／JSP（2）（5/5 ページ）
PHP（PHP:Hypertext Preprocessor）
もともとがCGIのマクロ的な位置付けから発祥したPHPは、関数を主体とした平易な言語です。ASPやJSPによく似たHTML埋め込み型言語を採用し、で囲まれた部分にロジックを記述します。
以下に、PHPの最もシンプルな例を挙げてみることにしましょう。
<head>
<title>Hello, World!!</title>
<body>
<?php echo("Hello,World!!"); ?>
</body>
</html>
開発性の観点から
上述したように、PHPはその機能の大部分を、端的に分かりやすい関数という形で提供します。その種類の多さは群を抜いており、例えば、配列関数だけで約60種類の関数が提供されているという一事をもってしても、その豊富さは十分に想像いただけることでしょう。そうした意味で、PHPのコンセプトは、ASP同様、とにかく手軽にかつ端的にエンドユーザー要件を表現できることにあるといえます。
ただし、そうした関数の豊富さにもかかわらず（いや、それ故にこそ不十分とすら思われる）、重大な欠点をPHPは内包しています。
（1）構造がフラットである
Javaは「パッケージ」でクラスライブラリをカテゴライズし、命名の一意性を保障しているのに対し、PHPの関数群はあくまでフラットです。そもそも関数という性質上、クラス・オブジェクト指向の世界ではメソッドやプロパティ（フィールド）としてまとめられた機能群も、PHPではすべてばらけた状態で提供されます（それはいうなれば、フォルダという概念のないファイルシステムのようなものです）。
機能を意味的に関連付けるのは、構文規則から離れた（はなはだ信頼性に欠ける）命名規則のみであり（例えば、MySQL関数はmysql_〜で始まる、など）、拡張するに従って命名衝突の危険性は増します。また、フラットであるが故に、全体的な機能の分類を把握するのは難しく、これだけ潤沢な機能を提供しているにもかかわらず、実際に使用する側としてはどのような機能があるのか全体を把握するのが難しい（煩雑である）という、機能以前の体系的な「もったいなさ」があるのも事実です。
（2）HTTPヘッダを意識しなければならない
これは必ずしもCGIのそれと同レベルの問題であると考えるべきではありません。もちろん、PHPでもASPやJSP同様、一般的な出力のレベルでHTTPプロトコルを意識する必要はありません。しかし、例えば、リダイレクト機能、文字コードの宣言、HTTPステータスの出力など、ことにHTTPヘッダの制御にかかわる局面に至った場合、PHPではheader関数が用意されているのみなのです。これはこれだけ関数群が充実したPHPにおいては「あまりに不親切な」設計であるといわざるを得ません。
ちなみに、この点はJSP＆サーブレットではHttpServletResponseクラスなどによって、ASPでもResponseオブジェクトによってほぼ完全に隠ぺいしており、ユーザーにプロトコルを意識させる局面は少ないといえます。
パフォーマンスの観点から
パフォーマンスという見地から見たとき、PHPの特性は長所・短所含め、極めてASPに酷似しています（詳細はASPの項を参照してください）。
- プロセスは常に1つ
- インタプリタ言語としての制約
- 遅延バインディングとしての制約
ただし、2003年1月時点での最新バージョンPHP4ではインタプリタ言語としてのパフォーマンス的制約を克服するために、以下のような工夫が凝らされています。
（1）Zend Engineによる一括コンパイル処理
Zend EngineはPHP4から導入された新たな実行エンジンの名称です。Zend Engineは実行に先立って一括でコンパイル処理を行い、コンパイル済みの中間コードを実際の処理系に渡します。これによって、逐次処理によるオーバーヘッドの発生を極小化し、パフォーマンスの大幅な向上を図ります。
（2）Zend Acceleratorによるコードキャッシュ
Zend AcceleratorはZend Engineのコンパイルによって生成された中間コードをキャッシュするしくみを提供します。これによって、リクエストの都度、コンパイル処理が発生することを抑え、処理パフォーマンスを改善することができます。
このしくみは、JSPが1度目のリクエストでいったんサーブレットに変換・コンパイルされ、「.class」ファイルとして保持されるのと酷似しています。
図3 JSP、PHPの実行されるまでの流れ可搬性の観点から
可搬性の観点で、PHPのそれはASPよりもむしろJSP＆サーブレットに類似しているといえます。すなわち、以下の2点においてです。
（1）クロスプラットフォームに対応
本稿執筆時点（2003年1月時点）で、PHPはWindows、UNIXはじめ、Mac OS、Novell NetWare、OS/2などの主要なプラットフォームに対応しています。
ただし、（1）ファイルシステム関数を中心にUNIX系OS主体の機能が少なくない、（2）パス区切り文字や改行文字など環境依存の情報を吸収するしくみを持たない、などの問題（課題）は依然として残っており、いわゆるJavaでいうところの“Write Once, Run Anywhere（一度書けばどこでも動く）”の精神を実現しているというよりは、文字どおり、複数のプラットフォームに対応したという色合いが強いともいえます。
（2）XCOPYインストールが可能
PHPアプリケーションは原則、XCOPY——すなわち、フォルダのファイルシステム的なコピーによって、一連のアプリケーションをコピーすることが可能です。一連のアプリケーション設定も、php.iniと呼ばれるテキストファイル上に記述されていますので、異なるサーバに移行する場合も個別に設定の手間を必要としません。
ただし、ここで注意しなければならないのは、Javaの「.war」ファイルと異なり、PHPではアプリケーションフォルダ内に拡張モジュール（「.dll」や「.so」）を含むことができないという点です。拡張モジュールを組み込むためには、ASPのCOM同様、個別にインストール作業を行う必要があります。
One Point
PHPはUnix、Windows系など主要なOSで動作します。関数主体とした平易な言語体系は、小規模系のアプリケーションで強い力を発揮します。
総括
いかがでしたでしょうか。いささか駆け足ではありましたが、JSP＆サーブレットを主軸に置いた各技術特性の差異について、少しはご理解いただけたでしょうか。
ここで皆さんがどのような感想をお持ちになるのも（もちろん）自由ですが、1つだけ誤解していただきたくないのは、本稿があくまでどの技術が優れている、劣っているという議論を目的としているわけではないという点です。それぞれの技術に一長一短があり、また、それぞれの設計思想によって、ある局面では短所と思われる特性も異なる局面では長所となり得る場合があります。
例えば、ASPやPHPなどは変数宣言を強制しない構文的にもあいまいなスクリプト言語を採用していますが、実際のところ、これら技術がターゲットとする小規模系のシステムにおいては、それは「十分な」実装であるといえます。むしろそうした手軽な開発においては、Javaの厳密なデータ型の制約は忌避されるところであるかもしれません。
また、現時点では明らかな短所と思われる点についても、ASP.NET（ASPを「.NET Framework」に基づいて再構築した次期バージョン）、PHPの次期バージョン5ではさまざまな改良が施されており（もちろん、JSP 2.0／サーブレット2.4においても）、それは技術そのものの特性というよりも現時点でのスナップショット的な「状態」にすぎません。
そうした意味で、むしろここでは技術的な優劣というよりも、それぞれの技術の得手不得手・適用個所を相対的にとらえ、今後、JSP＆サーブレットプログラミング・設計を行っていくうえでの1つのよすがにしていただければ幸いです。
最後にまとめとして、各技術を端的に比較した総括表を挙げておくことにします。これらは、あくまで各技術が持つさまざまな側面をひとつの視点でとらえたものにすぎませんが、特性を概観した参考資料としてご覧ください。
| 項目 | JSP/サーブレット | PHP | ASP |
| 適用箇所 | ―大規模システム | ―中小規模システム | ―中小規模システム |
| 開発生産性 | ◎構造化された豊富なAPI、JSPの豊富なスクリプティング要素 | 〇豊富な関数群、平易な言語体系。但し、関数体系に難あり | ◎組み込みオブジェクトと豊富なコンポーネント。関数主体のVBScript |
| パフォーマンス | ◎コンパイル言語。プロセスはコンテナひとつ | 〇インタプリタ言語（Zendによる一括コンパイル）。プロセスはコンテナひとつ | 〇インタプリタ言語。プロセスはコンテナひとつ |
| マルチプラットフォーム・可搬性 | ◎Write Once, Run Anywhere | 〇複数プラットフォームに対応。ただし、マルチプラットフォームでの移行には注意要 | ×Windowsにのみ対応。COMインストール、IIS上の環境設定など要 |
| 保守性 | ◎JavaBeans、フィルタ、カスタムタグ、リスナなど豊富な支援技術 | △PEAR、PHPLibなどの部品化技術。但し、未だ不十分 | 〇豊富なCOM、スクリプトレット技術 |
| 分業容易性 | ◎JSP、サーブレット、JavaBeansによるMVC技法 | △テンプレート技術やPEARなどは未だ発展途上 | 〇ページインラインとCOMの切り分け。N層アーキテクチャ |
| 初期環境構築の手間 | △J2SE、Tomcatなど必要 | △Apache、PHPなど必要 | 〇ASPはIIS/PWSに組み込み |
| 言語選択の柔軟性 | ×現バージョンではJavaのみ | ×独自の言語のみ | 〇COM対応スクリプト言語の範囲で自由 |
| 障害時の影響分離度合い | △コンテナ全体に影響 | △サーバ全体に影響 | ◎影響分離度を用途に応じて変更可能 |
| 項目 | CGI | クライアントサイドスクリプト |
| 適用箇所 | ―中小規模システム | ―サーバサイド技術の補助的手段 |
| 開発生産性 | ×HTTPプロトコルの知識が必要 | ◎平易なスクリプト言語 |
| パフォーマンス | △コンパイル、インタプリタ双方あり。要求都度、プロセス起動 | 〇インタプリタ言語。クライアント-サーバ間のトラフィック発生しない |
| マルチプラットフォーム・可搬性 | △複数プラットフォームに対応。ただし、マルチプラットフォームでの移動は困難 | ×クライアントの環境に強く依存 |
| 保守性 | 〇…による豊富なモジュールの提供 | ×UIによりコードへの影響大 |
| 分業容易性 | ×純正のプログラムソース。デザイナによる編集困難 | 〇「.js」による外部ファイル化 |
| 初期環境構築の手間 | △任意のWebサーバと使用言語の実行環境が必要 | ◎スクリプト対応のブラウザのみ |
| 言語選択の柔軟性 | ◎Perl、C、シェルスクリプトなど自由 | △自由（ただし、JavaScriptが一般的) |
| 障害時の影響分離度合い | 〇サーバ本体とは別プロセスで実行 | 〇影響程度は低い |
なお、これら技術比較については、当然、この短い記事の中ですべてを表せるものではありません。構文的、周辺環境的、あるいは設計ポリシー的な観点から多岐にわたった比較分析を、拙著『JSP/PHP/ASPサーバサイドプログラミング徹底比較（http://member.nifty.ne.jp/Y-Yamada/srv/）』（技術評論社）でより詳細に試みています。興味のある方は、ぜひご覧になってみてください。
さて、概略的なお話は今回で終わり、次回からはいよいよJSP＆サーブレット環境の構築、そしてJSP構文の基本について、サンプルを交えながらご紹介していくことにします。どうぞお楽しみに。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。