サーブレット／JSPをほかの言語と比較する：基礎から学ぶサーブレット／JSP（2）（4/5 ページ）

» 2003年02月08日 00時00分公開

ASP（Active Server Pages）

　ASPはWindows＋IIS（Internet Information Server／Services）／PWS（Personal

Web Server）上で動作するサーバサイド処理環境で、1998年以降、Windows系OSの急速な普及を追い風に爆発的な普及を遂げた技術でもあります。当時のWindows 98において標準モジュールとしてバンドルされ、エンドユーザーが手軽に使用できるようになった点も看過できない普及要因であったといえましょう（ただ、その後Windows MeやXP Home Editionにおいて、PWSのサポートが外れたことでいささかの混乱を招いたのも事実です）。

　JSPによく似たHTML埋め込み型言語で、<%～%>で区切られた中にソースコードを記述し、その処理結果のみがクライアント側に応答として返されます。

　以下に、ASPにおける単純なサンプルを挙げておくことにしましょう。

<%@ Language="VBScript" %>
<html>
<head>
<title>Hello, World!!</title>
<body>
<% Response.Write "Hello,World!!" %>
</body>
</html>

sample.asp

開発性の観点から

　ASPは、ことに小規模開発系のアプリケーションでは極めて高い開発性を保証します。Microsoft社ならではのコンパクトかつ、エンドユーザーの要件に直結したオブジェクトモデルと豊富なCOMコンポーネント群の存在は、従来の原始的なアルゴリズムまでを意識した「専門的な」プログラミングの世界に、ビジネスロジックに集中した「いかに機能を組み立て、並べるか」というむしろ「脚本家的な」要素を強く現出させたといえます。

（1）HTML埋め込み言語である
　JSPや、後述するPHPにも共通した特性です。CGIが出力に際して、print命令を連ねなければならなかったのに対し、ポストCGIのこれら技術はベースがHTMLですから、単純な出力のためにプログラムを組む必要はありません。極端な話、静的なレイアウトの部分だけならば、プログラムをなんら知らないエンドユーザーでも変更できる「可能性がある」ことを意味しますし、プログラマにとっても、高い記述容易性を保証します。

（2）7種類の組み込みオブジェクト
　ASPではApplication、Session、Request、Response、Server、ObjectContext、ASPErrorといった7種類の組み込みオブジェクトが用意されており、あらかじめ宣言などを必要とせず、ASPコード内で使用することが可能です。これら組み込みオブジェクトは、Webアプリケーションに必要なクライアント／サーバ間の入出力、アプリケーション・セッションの管理機能を担い、CGIでは個々のコード内で一から記述しなければならなかった内容を端的に記述できるようになっています。

　これら組み込みオブジェクトは、JSPにおいても暗黙オブジェクトという形で、ほぼ同等の形で提供されています。

（3）豊富なコンポーネント群
　ASP開発において最も注目すべき点は、COM（Component Object Model）とのシームレスな連携でしょう。データベースとの一元的なインターフェイスを提供するADO（ActiveX Database Object）やファイルシステムの操作・アクセスを可能とするFSO（FileSystem Object）をはじめ、Microsoft社、サードベンダを問わず、提供される豊富なCOMコンポーネントは、限りなくプログラムレスなコーディングを可能とします。ASP普及にはいくつかの要因がありますが、1つにはこのCOMコンポーネントが早期から豊富にそろえられていたという点は看過できない大きなポイントといえましょう。

　ただし、Javaが多くのライブラリを標準的なクラスライブラリとして実装しているのに対し、ASPにおいては、多くが外部コンポーネントとしてコアパッケージから切り離されていることから、使用に当たっては個別にインストール作業を必要とするという回りくどさはあります。

（4）COMとScriptLets～部品開発の観点から～
　なるほど、COMはASP開発を強力に支援する看過すべからざる存在です。しかし、COMの開発——即ち、自ら主体的に部品化を行うという観点からは、少々事情が異なってきます。

　1つに、COMがあくまでVBやC++、Javaなどをベースとして構築されるべきアーキテクチャであった点。これら言語はかつてのCやアセンブラに比べれば、はるかに平易ではあるものの、平均的なASP開発者にとっては決して取っ付きやすいものではありません。極端な話、開発者は「ただ部品化を行うためだけに新たな技術を1つ習得しなければならなかった」のです。ところが、JSP＆サーブレットにおける部品化技術JavaBeansは、その名のとおり、Javaで記述することのできる純正のクラスです。つまり、JSPやサーブレットを習得した知識「そのまま」に、部品化の作業を行うことができるのです。

　また、このことはもともとがコード本体に組み込まれたロジックをあらためて部品化したいという場合にもかかわってきます。すなわち、ASPからCOM化する場合には開発者は「VBScriptからVBへの移植」を行わなければなりません（いかにVBScriptとVBとが似通った技術であるといっても、それは決して容易なことではありません）。しかし、JSP＆サーブレットに組み込まれたロジックをJavaBeans化する場合には、JavaからJavaへの変換です。もちろん、部品化するに当たっての再設計は必要となるものの、言語構文的にはなんらの負荷を開発者に与えません。

　なお、ASPでもVBScriptなどのスクリプト言語で直接部品化を行うことができるScriptLetsという技術がないわけではありません。しかし、VBScriptがそうであったように、ScriptLetsはスクリプトをベースとしたインタプリタ式のしくみです。COM呼び出しのオーバーヘッドと処理パフォーマンスの劣化という2つの観点からは、決して無批判に採用すべきしくみではないでしょう。また、構文的にもあくまで簡易な部品化を意図したものであり、部品自体をさらに拡張・実装するといった、部品再利用の手段は備えていません。

（5）スパゲッティコードの危険性
　これはASPに限った話ではありません。PHP、JSPなど、いわゆるHTML埋め込み型（ページインライン）のプログラミングモデルを採用した時点で、構造的に内包していた問題であるといえます。すなわち、ページインラインモデルは、コードをHTMLレイアウト上に自由に埋め込めるというそのメリット故にロジックが複雑となり、HTMLレイアウトの中に深く食い込まれたときにコードの可読性が極端に劣化するという半面を持ちます。

　JSP＆サーブレットにおいては、その機能分担が明確であることからあらかじめロジックとレイアウトとを分離した設計を行うことが可能ですが、ASP・PHPにおいては、インクルードファイル化、もしくはCOM・PEARクラスなどで部品化するくらいしか選択肢が与えられていません。

　また、JSPでは極力コード部分を少なくするために、式（Expression）やディレクティブ、アクションタグなどの独自のしくみが豊富に用意されていますが（これらの詳細については別述します）、ASPでは<%=～%>で表される省略形と、JSPに比べればはるかに貧弱なディレクティブがあるのみです。

パフォーマンスの観点から

（1）プロセスは常に1つ
　CGIの項でも述べたとおりです。ASPのコードはASP実行エンジンが動作する唯一のプロセス上で動作しますので、ユーザー数の増加にもシステムリソースをさほど消費せずに済みます。

　ただし、プロセスが1つであるということは、半面で実行エンジン上の1スレッドが異常終了した場合にサーバ全体に影響が及んでしまう可能性があるということと表裏でもあります。しかし、この点についても、ASPでは考慮された設計が行われており、ここはJSP＆サーブレットやPHPにはない特性であるといえます。

　すなわち、ASPではアプリケーションの重要度に応じて、アプリケーションの分離度を設定することができます。分離度を低く設定した場合（すべてのスレッドを同一プロセスで実行した場合）、アプリケーションの障害がサーバ全体に波及する可能性がありますが、リソースの消費は少なくて済みます。一方、分離度を高く設定した場合（アプリケーション単位にプロセスを分離した場合）、リソースの消費は膨らみますが、一方でアプリケーションの障害がほかに及ぼす影響は小さくなります。いずれを選択するかは、個々の状況に応じた判断ですが、こうした重み付けの管理ができる点は、ASP（IIS）ならではの機能であるといえましょう。

（2）インタプリタ言語としての制約
　ASPが使用言語を自由に選択できるというのは、あくまで「COMに対応した」「スクリプト言語」の範囲においてです。スクリプト言語、つまりは、インタプリタ（逐次翻訳）型の言語しか、ASPでは扱うことができません。

　ASPはバージョン2.0から3.0への改善の中で（あるいはIIS 4.0から5.0へのバージョンアップの中で）、大幅なパフォーマンスの向上を果たしていますが、実行時に逐次翻訳していくインタプリタの制約は厳然として存在します。

（3）遅延バインディングとしての制約
　これは、むしろASPというよりも、変数宣言を強制しない（VBScriptに代表される）スクリプト言語全般の問題でもあります。

　変数宣言を「強制しない」ということは、変数宣言を「必要としない」ことと同義ではありません。つまり、VBScriptは変数をユーザーによって明示させることを必要としない代わりに、実行時に自動的にデータ型を判定し、それに見合った適量のメモリを自動的に割り当てているのです（遅延バインディング）。このことは処理上のあいまいさを生み出すというだけではなく（データ型の誤判断など）、実行時のオーバーヘッドを増大させるものでもあります。

　対するJSP＆サーブレット（Java）の世界では、変数・データ型の宣言は必須です（事前バインディング）。つまり、実行に先立って最適なリソースが確保されているということであり、処理上のあいまいさを排除すると同時に、実行時のオーバーヘッドも極小化します。

可搬性の観点から

　昨今ではUNIX上で動作する環境も提供され始めているとはいうものの、その互換性を考えれば、ASPは原則、Windowsに特化したアーキテクチャであるといえましょう。

　ただ、クロスプラットフォームの観点を度外視するとしても、ASPアプリケーションの可搬性は以下の点で問題をはらんでいます。

（1）COMインストールの必要性
　開発性の項でも述べたように、COMは使用に当たってあらかじめインストール（レジストリ登録）の必要があります。つまり、COMに依存するアプリケーションでは、単純にコードをコピーしただけではほかのサーバ環境で動かせないことを意味します。

　一方のJSP＆サーブレットの世界では、関係するクラスライブラリもアプリケーション内に含めた「.war（Web Archive Resources）」ファイルとしてアプリケーションを提供することができますので、「.war」ファイルをコンテナ上にコピーする以上の手間を必要としません。

（2）設定はIIS上で行う必要がある
　JSP＆サーブレットがデプロイメント・ディスクリプタ（web.xml）と呼ばれるXML形式のファイル上で一連のアプリケーション設定を記述できるのに対し、ASPのアプリケーション設定はIIS上（メタデータやレジストリ）で行います。つまり、サーバ間移動に際しては、必ず一連の設定作業を「一から」行わなければならないことを意味します。