Last modified: Jan./23rd/2003; Since: June/1st/2002
Java はクライアント／サーバー環境（分散環境）のサーバ側で実行することができます。CGIと同じですね。現在の Java は、サーバサイドのウェブ・アプリケーション、分散環境での利用が主流です。ブラウザなどの、プログラム実行能力のないクライアント（シン・クライアント）で、インターネット越しにサーバ・マシンにアクセスし、 サーバ・マシン上で Java アプリケーションの処理を実行できます。
Web Application は、ウェッブ上のサーバにおいて実行されるアプリケーションであり、実行するサーバはアプリケーション・サーバと呼ばれます。Java はネットワーク環境との親和性が高く、ウェッブ・アプリケーションといえば、サーバ・サイドで実行される Java アプリケーションのことだといってよい状況にあります。
本稿では、Java のサーバサイドで実行される規格である、サーブレット、JSP (Java ServerPages) について解説します。
インターネット上の WWW は、サーバ上に置いた文書をクライアントからアクセスして閲覧するサービスの名称です。通信には HTTP (HyperText Transfer Protocol) と呼ばれる規約（プロトコル）を用い、文書を公開するサーバは HTTP サーバ（Web サーバ）と呼ばれます。HTTP サーバは、クライアントから URL 要求を受け取ると、対応する文書を返します。クライアントは、 URL を HTTP サーバに送信して、返された文書をダウンロードして自分の PC に一時的に保管し、それをブラウザで閲覧します。
このような単純な仕組みからなるウェッブの世界は、動きのない予め決まった文書だけからなる静的なものです。これに動きを付けるには、JavaScript のようなプログラミング言語や Flush のようなリッチなメディアを文書と一緒にダウンロードしてクライアント側で実行するか、Perl などので書かれたものをサーバ側で実行し、その処理結果を返すかの何れかの方法がとられます。
クライアント側で実行が必要になる場合、クライアント側に当該言語の実行環境が備わっていないと、なにもできません。一方、サーバ側で実行する場合、クライアントが受け取る処理結果は静的な文書と同じなので、サーバ側に当該言語の実行環境を備えておけば、全てのクライアントにサービスを提供できます。この点で、Perl をはじめとする言語により、CGI (Common Gateway Interface) と呼ばれる仕組みが広く使われてきました。
CGI は、HTTP サーバのモジュールとして用意され、要求を受け取った HTTP サーバは、当該サービス用のプロセスを立ち上げて処理し、処理結果をクライアントに返します。一つの処理ごとに、プロセスの立ち上げ／終了が必要になります。プロセスというのは、メモリ上を占有し、コンピュータ制御の実行経路をロードする一つの単位です。一般に、複数のプロセスによって CPU は競合状態にあり、 OS がそれらの実行可能状態にあるプロセスに対して適宜 CPU の実行を割り当て（ディスパッチ）ます。
プロセスの開始と停止は、メモリ領域へのロードと占有された領域の解放、OS への登録、ディスパッチなどのオーバーヘッドが必要となり、コンピュータにとってはコスト（負荷）の高い処理です。そのため、CGI の場合は、クライアント要求の増大によるシステム資源の圧迫は深刻であり、処理速度、安定性、拡張性などの点で、大規模システムには不適切です。
CGI の問題を解決しようとして登場したのが、サーバサイド・スクリプティングです。これは、個々の要求を、サーバ上に常駐するプロセス内のスレッドとして実行するものです。これから説明する Servlet/JSP は Java によるサーバサイド・スクリプティングです。他に PHP や Microsoft の規格がありますが、大型案件のほとんどは Java と言ってよい趨勢にあります。
サーバーにインストールし、サーバ上で実行される Java アプリケーションをサーブレット (Servlet) と呼びます。クライアントが HTTP サーバに要求を送ると、アプリケーション・サーバに渡されて、サーブレットが実行され、結果がクライアントに返されます。アプリケーション・サーバは、いったんサーバ上で起動すると、メモリ上に常駐し続け、クライアント要求ごとにスレッドを開いて処理します。
サーブレットは Java の構文どおりに記述するために、 HTML などの応答を出力するには、いちいち print メソッドを記述する必要があります。これは面倒でバギーな作業です。 HTML などの文書の記述を容易にするために登場したのが JSP (Java Server Pages) です。 JSP も実行時には、アプリケーション・サーバの内部的にサーブレットに変換されたものが使われることになります。
サーブレットや JSP によって利用されるオブジェクトは JavaBeans と呼ばれる規約に従って開発することが多くなります。JavaBeans 仕様は、もともと Swing などの GUI アプリで、再利用性を高めるための共通規格という意味合いで登場したものです。通常の Java クラスと同じ構文なのですが、 JavaBeans 仕様に従ったモジュールを特に、 Java Bean, bean と呼びます。ウェッブ・アプリケーションにおけるこれらのオブジェクトの役割は、ビジネス・ロジックの実装、ＤＢへの連携を専らとします。
一般に、実行ロジックは bean に記述し、その表示を JSP で行い、クライアント要求をサーブレットが制御します。これをモデル２アーキテクチャと呼びます。モデル２アーキテクチャは、Model/View/Control (MVC) というデザインパターンに則っており、それぞれに bean/JSP/Servlet が対応します。
WWW では、ネットワーク構成のプロトコルは TCP/IP を用い、文書交換のプロトコルに HTTP を使っている。クライアントはインターネット上のホストと TCP/IP を用いて接続／通信し、要求／応答を HTTP でやり取りしている。このとき、クライアントからの要求を処理するホストを WWW サーバ、 HTTP サーバと呼び、ホストで稼動する daemon として実装される。
WWW では、クライアントがインターネット越しのホストに HTTP 要求を送り、ホストで稼動している http daemon が応答します。たとえば、URL 要求に対して、対応するウェブページを返します。
CGI では、 HTTP 要求に対応するリソースが Perl などの実行可能なものであれば、 http daemon は、対応する処理環境に制御を渡し、その実行結果をクライアントに返します。
Serlet/JSP/bean の場合は、Java を実行可能なバーチャル・マシーン (JavaVM) が必要です。これを、アプリケーションサーバと呼びます。HTTP サーバは、アプリケーションサーバに制御を渡します。
HTTP サーバは、現在は Apache が主流であり、ベンダー各社も Apache ベースで HTTP サーバ製品を開発しています。Microsoft の IIS もかなり多くの割合を占めます。
Web サーバに対して、Web アプリケーションを実行する能力を備えたものを、 Web アプリケーション・サーバと呼ぶ。 HTTP サーバが受けた要求をアプリケーション・サーバに渡して、処理結果を応答として返すので、サーブレットの実行には、 HTTP サーバと アプリケーション・サーバが必要になる。多くのアプリケーション・サーバは、 HTTP サーバの機能も備えており、サーブレット実行可能な HTTP サーバをアプリケーションサーバと呼んでも良い。但し、信頼性／可用性／保守運用性／拡張性の観点から別のマシンに分けておくことも多いらしい。主なものに、 Apache Tomcat, IBM Webspere Application Server (WAS) などが挙げられる。特に、 Apache Tomcat は Apache Softwere Foundation の Jakarta プロジェクトが開発しているオープン・ソース・ソフトウェアであり、無料で入手できます。
CGI は、クラインアント要求ごとに HTTP サーバによってメモリ上に展開されて、対応する処理系が実行する。一般に、メモリロードは負荷の高い作業である。サーブレットはサーバにインストールし、いったんメモリ上に展開されるとそのまま常駐する。クライアント要求に対してはスレッドが作成されてそこで処理される。そのため、最初の一回を除くと負荷の高いメモリ・ロードが無くなり、 CGI に比べると処理が高速になる。
CGI で多く使われている言語に、文書処理スクリプト言語である Perl が挙げられる。これはスクリプト言語の完成形とも呼ばれる、高機能で完成度の高い言語だが、そもそもは UNIX 上での文書処理用に開発されたものであり、ヘビーなアプリケーション開発には向かない。一方、サーブレットに使う Java はオブジェクト指向の汎用言語であり、分散環境／ネットワークとの親和性が高く、高度なロジックを実装しやすい。
Java は最近の流行であるために、ワークロードを割きやすい、開発環境が整っているなどのメリットも挙げられます。
アプリケーションサーバは、 Apache の Jakarta プロジェクトが開発している Tomcat があります。 Apache Tomcat の最新版は２００２年５月現在で 4.0.3 です。これは、 Sun Microsystems のJ2EE (JavaServer Web Development Kit) にも同梱され、 "implementation reference" という地位が与えられています。
ベンダー各社が注力しており、競合製品が多数ある分野ですが、 IBM の Webspear Application Server (WAS) があり、こちらは J2EE 完全対応を謳っておいます。
個人のローカルな PC で試したい場合は、IDE （統合開発環境）に含まれている場合もあります。たとえば、 IBM Webspear Studio Application Developer (WSAD) には WAS の簡易版がテスト環境として含まれます。
サーバにサーブレットを置いて稼動させるためには、Java Servlet 仕様に適合している必要があり、個別的詳細の指定は Deployment Descriptor (DD) 文書を記述します。これは XML 文書であり、その文書型を Sun Microsystems が定義しています。ルート要素は web-app、公開識別子 (FPI) は -//Sun Microsystems, Inc.//DTD Web
Application 2.3// で、 DTD の URL （システム識別子）は http://java.sun.com/dtd/web-app_2_3.dtd です。この DTD 宣言は次のようになります：
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
これはバージョン 2.3 の DTD 宣言ですが、全ての Web アプリケーション DD は、 2.2 の DTD もサポートするように求められています。
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
いずれにせよ、アプリケーションサーバであるホストに、 Java Servlet 仕様の要求を満たすディレクトリ構造を作り、そのホスト独自の設定を web.xml に記述することが最低限度の設定になります。
他にも、サーバとして必要な構成情報は別途設定する必要があるのは、言うまでもありません。