動作原理と環境の構築
本稿では、WebSphereを使って解説を進めるので、まずはWebSphereのセットアップから話を始めたい。しかしその前に、JavaServletの動作原理について、少し触れておこう。
Java Servletの動作原理
JavaServletは、HTTPサーバをアプリケーション・サーバに変身させるテクノロジである。実際には、どのような構造をしているのだろうか。
サーブレットの「レット」とは、英語で「小さいもの」を指す単語のサフィックスに使われる。日本語では指小辞というらしい。Bookletといえば小冊子を示すし、Crabletといえばカニの幼生を指す。Javaには、Appletというものがそもそも存在するが、これは「小さいアプリケーション」というような意味になる。サーブレットは「小さなサーバ・アプリケーション」といったところだろうか。
「サーブレット」と単純にいった場合、それはサーバ・アプリケーションを指す。これはサーバ上で実行されるものであり文字どおり「サーバ」が必要である。サーブレットを実行するためのサーバ・プロセスを「サーブレット・エンジン」という。
サーブレット・エンジンは、基本的にそれ単体では役に立たない。サーブレットはその画面をHTMLとしてWebブラウザに表示する。つまり、HTTPサーバが必要である。通常、多くのサーブレット・エンジンは別のHTTPサーバにプラグインして稼働する。
HTTPサーバが導入されているマシンにサーブレット・エンジンを導入すると、プラグイン・モジュールが同時に導入され、HTTPサーバの構成ファイルが書き換えられる。これがプラグインという作業であり、サーバ管理者が自分で構成ファイルを書き換えることはほとんど必要ないはずだ。
サーブレット・エンジンはサーバ・プロセスとしてサーバ・マシン上に常駐する。プラグイン・モジュールは、WebブラウザからHTTPサーバに送られてきたHTTPリクエストを、共用メモリやTCP/IPなどを使って適宜サーブレット・エンジンに転送する。
サーブレット・エンジンはリクエストが転送されてくると、該当のサーブレットをロード／初期化し、サービス・メソッドを呼び出す。繰り返し同じリクエストがきた場合、ロード／初期化の処理は必要なく、サービス・メソッドの呼び出しのみが行われる。サービス・メソッドの呼び出しは、サーバ・プロセスのスレッドによって行われる。
CGIと違い、サーバが常駐しユーザー・アプリケーションをロードすることによりリソースやパフォーマンスの面で有利である。ユーザーがHTML上で入力した内容や、操作した内容（ラジオボタンやチェックボックスの選択など）は、HTTPプロトコル上に「パラメータ」と呼ばれるデータとしてサーバに送られる。これらの情報はアプリケーション・サーバ・プロセスが読み取り、分解してUnicodeに変換した後、リクエスト・オブジェクトにセットする。JavaServletコードで取り出すには「getParameter」メソッドが使える。
WebSphereのセットアップ
一昔前のサーバ製品では、HTTPサーバ、JDK、アプリケーション・サーバ、RDBMSなどを別々に導入し、それぞれ正しく構成しないとうまく稼働しないというものが多かったが、最近のサーバ製品ではセットアップ自体も非常に簡単になってきている。
WebSphere Application Server V4.0は、IBMから発表されているJavaアプリケーション・サーバの最新版である。本稿執筆時点ではzSeries版（OS/390）とマルチプラットフォーム版、iSeries版が発表されている。今回はこの最新版を使ってサーブレットのコーディングをご紹介する。
WebSphere Application ServerV4.0 は、OS/390、Linux/390、AS/400、AIX、Sun Solaris、HP-UX、Linux（Intel版）、Windows NT／2000と非常に多くのプラットフォームで稼働可能であり、数百から数千倍のスケーラビリティを持つともいわれる。また、サーバ製品だけでなく開発環境や管理製品を1つのブランドとして提供しており、メインフレームとの連携のためのコネクタも非常に充実している。IBMのホームページから申し込めば、開発者向けのCD-ROMを手に入れることもできる（http://www.jp.ibm.com/software/websphere/を参照）。多数のHTTPサーバをプラグイン対象としているのも特徴的である。
JavaServletを実行するために必要な製品として今回利用しているものを次に一覧する。カッコ内は、略号であり覚えていただくと今後役に立つだろう。
| OS | Windows 2000 |
|---|---|
| HTTPサーバ | IBM HTTP Server V1.3.19（IHS） |
| アプリケーション・サーバ | WebSphere Application Serverアドバンスド・シングルサーバ版 V4.0（WAS） |
| Web開発ツール | WebSphere Studio V4.0（WSS） |
| Java開発ツール | VisualAge for Java V4.0（VAJ） |
WAS V4.0は、J2EE対応になったため、すべてのエディションでサーブレット、JSP、EJBの実行が可能である。WASには、利用規模によって、シングル・サーバ版、アドバンスド版、エンタープライズ版という種類があるが、今回、記事中で使用するアドバンスド版では、アプリケーション・サーバ自体にHTTPのプロセスが統合されているため、HTTPサーバなしでも稼働可能である。ただし、統合されているHTTPプロセスは、ポート番号がデフォルトでは9080であり、ポート80に変更するには若干の作業が必要である。
これらは、次のURLから試用版（現行版のみ）などがダウンロードできるので、興味がある方はダウンロードしてテストしてみてほしい（http://www.jp.ibm.com/software/download.html）。
サーバセットアップは至って簡単である。特にV3.5以降では「クイックインストール」という形態のセットアップができるようになった。Windows 2000でsetup.exeを実行するだけでHTTPサーバ、DB2 UDB（以下UDB）（アドバンスド版以上）、Java2、HTTPサーバ、アプリケーション・サーバなどが自動的に導入され、利用可能になる。V4.0では、シングル・サーバ版とアドバンスド版以上とで、若干システム管理の方法に違いがあるので、それぞれに別に解説しておく。
●シングル・サーバ版の場合
シングル・サーバ版は、アドバンスド版とほぼ同等の機能を単一サーバのみで実行できる形態のもので、開発環境やスモール環境での利用に対応するためのものである。ワークロード・マネジメント機能を使った負荷分散などはアドバンスド版以上が必要である。シングル・サーバ版には、管理サーバという考え方がなく、Webベースの管理画面が提供される。システムの構成は、C:\WebSphere\AppServer\configの下のserver-cfg.xml というXMLファイルに保存される。サーバの起動は、WASのbinディレクトリにある「startstd.bat」を起動すればよい。これで基本的には準備完了である。
●アドバンスド版、エンタープライズ版の場合
セットアップ後にやらなければいけないことがいくつかあるので、一覧しておく。詳しくは製品に付属しているマニュアルなどを参照してほしい。
（1）JDBC 2.0の使用
これは、インストール前にやっておこう。WAS V4.0は、JDBC 2.0を利用する。このため、UDBのJDBCドライバをJDBC 2.0に対応したものに交換する。交換するには、UDBを導入したディレクトリの下にあるjava12ディレクトリ下の「usejdbc2.bat」を実行すればよい。実行前にUDBのプロセスを停止する必要があるので、コントロールパネル→管理ツール→サービスを開いて、UDBのプロセスをすべて停止してから行う。
（2）リポジトリDBの作成
WebSphereでは、負荷分散のための分散環境において、設定情報を共有するためにRDBに設定情報を作成する。アドバンスド版、エンタープライズ版ではUDB（またはOracle）にこれを作成する。導入して最初のリブートでこれが行われ、初めてのサーバ起動によってDBの中身が初期化される。特に作業は必要ないが、サーバが起動できないときには知っておいた方がよい。RDBに作成されるDB名は、「WAS」である。うまく起動できない場合は、WebSphere\AppServer\logディレクトリの下のログを確認しよう。
（3）管理サーバの起動
WebSphereのサーバ・プロセスは、管理サーバとサーバ・プロセスに分かれている。管理サーバが、サーブレットやEJBのサーバ・プロセスを起動するという形態になっている。管理サーバは、管理コンソールのサーバとしても機能する。管理サーバはWASを導入したマシンの「サービス」の1つとして出てくるので、これを起動する。
（4）アプリケーション・サーバの起動
アドバンスド版以上ではワークロード分散などが可能なため、幾分複雑な構造を持っているが、カンタンに使うためにデフォルトの設定が最初から入っている。サーバは起動していない状態でセットアップが終わるので、一度手動で起動してやる必要がある。手順としては、WASの管理コンソールを起動し、「Default Server」を選択して開始ボタンを押す。
これで、WebSphere Application Server上でサーブレットとJSPを稼働させる準備が整ったことになる。ローカルでWebブラウザを起動してみて、テスト用のサンプルサーブレットを表示してみよう。
J2EEであるが故の違い
WebSphereはJ2EE対応となったため、アプリケーションの配置方法が以前と違っているので、事前に軽く触れておく。
V3.5までのWebSphereでは、J2EEのような「アプリケーション」という考えを古くから持っていたが、それ以前のWebアプリケーションを配置するために、以下のディレクトリを「単にファイルを置くだけでよい」ディレクトリとして、設定が行われていた。
| C:\に単純導入の場合 | |
|---|---|
| HTMLやJSP | C:\IBM HTTP Server\htdocs |
| サーブレット | C:\WebSphere\AppServer\servlets |
しかし、V4.0ではJ2EE対応サーバとなり、この方式がなくなってしまった。それは、J2EEでは、アプリケーションのパッケージングと配布、配置方法が決められているためである。おおまかにいうと、以下のようなことである。
HTML、JSP、XMLといった、いわゆるHTTPコンテンツに当たるものは、WARファイル（Web Application Archive）というJARに入れる。
●EJBはEJB-JARファイルに入れる
EJBにアクセスする外部プロセスが使うコードのみを入れたファイルをクライアントJARと呼ぶ。WARファイル、EJB-JARファイル、EJBクライアントJARファイルを適宜含んだファイルをさらに1つのJARファイルに入れ、これをEARファイルと呼ぶ。 アプリケーション・サーバに配置する単位はEARファイルである。
HelloWorldServletというサンプルアプリケーションは、Default Serverから参照されているアプリケーション「sampleApp.ear」に含まれている、Webアプリケーション「default_app.war」に存在する。このEARファイルは、サーバに最初から導入されており、J2EE用語でいうと「デプロイ（配置）」された状態になっており、WASの上では次の場所にファイルが展開された状態になっている。
| HTML、JSPなどのコンテンツ | WebSphere\AppServer\installedApps\sampleApp.ear\default_app.war |
|---|---|
| サーブレット | さらに下の WEB-INF\classes |
*.earや、*.warという名前であるが、これはJARファイルではなく、その名前のディレクトリに展開されている。
このディレクトリ上で、コンテンツやサーブレットなどを開発すれば、すぐ試せるし、EARファイルとしてエクスポートする機能も付いているので作業が楽である。
今回は、J2EEの話ではなく、サーブレットとJSPの解説であるし、長いので、これらを「＜コンテンツディレクトリ＞」、「＜サーブレットディレクトリ＞」と読み替えていただくこととする。
Copyright © ITmedia, Inc. All Rights Reserved.