この章では、アプリケーションをサーブレットとして運用する基本的な手順を解説します。サーブレットやサーブレットコンテナそのものについての説明はしませんので、あらかじめ調べておいてください。
WebObjectsはJ2EEに準拠しており、EJBやサーブレットを組み込めるほか、WebObjectsアプリケーションをサーブレットとして運用することができます。WebObjectsアプリケーションをサーブレットにすると、サーブレットコンテナで一サーブレットとして運用することになります(図7.1.1[サーブレットの流れ])。サーブレットコンテナとはサーブレットアダプタ(WOServletAdaptor
)が通信を行います。
図: サーブレットの流れ
WebObjectsサーブレットは運用の幅を広げます。サーブレットコンテナには様々な実装があり、目的や用途に応じて選択肢が豊富にあります。動作に必要なファイルをすべて一つのパッケージにまとめることもでき、WebObjectsをインストールすることなくMac OS X以外のプラットフォームで運用することもできます。WebObjectsには他プラットフォームへのインストーラが用意されていませんので、サポート対象外でも他プラットフォームで運用できるのは大きなメリットです。
一方、MonitorやwotaskdなどのWebObjectsの運用ツールは使えません。WebObjectsは複数のインスタンスを含む負荷分散をサポートし、ブラウザからアプリケーションを管理できます。サーブレットでは一つのインスタンスしか運用できず、そのままでは負荷を分散できません。ある程度はサーブレットコンテナ側で対応可能ですが、大規模のアプリケーションを運用する場合はサーブレットよりもMonitorで運用するのが確実です。
Monitorの運用と同じく、1サーバマシンにつき1ライセンスが必要になります。サーブレットコンテナで複数のプロセスを起動して負荷分散する場合でも、WebObjectsサーブレットを運用するマシンの台数分のライセンスになります。
Xcodeに同梱されているWebObjectsには、はじめからライセンスキーが登録されています。サーブレットのプロジェクトを作るときには、このライセンスキーを使います。ライセンスキーは/System/Library/Frameworks/JavaWebObjects.framework/Resources/License.keyに保存されています。
サーブレットコンテナによって様々な運用方法があり、そのうちXcodeではアプリケーションディレクトリとWAR (Web ARchive) ファイルのビルドをサポートしています。この他にもEAR (Enterprise ARchive)ファイルなどのWebアプリケーション用フォーマットがありますが、Xcodeがサポートしていないフォーマットを使う場合は、ビルドしたアプリケーションを手動で変換する必要があります。
どちらのフォーマットも必要なファイルをすべて含められるので、ビルドしたアプリケーションをサーブレットコンテナの所定の位置にコピーするだけでインストール・運用することができます。この場合はWebObjectsをインストールする必要がなく、他プラットフォームでも運用しやすくなります。
運用方法はプロジェクトの作成時に選択するか(図7.2.1[運用方法を選択する])、「Application Server」ターゲットの次のビルド設定を変更します。
SERVLET_SINGLE_DIR_DEPLOY
SERVLET_TRUE_WAR
図: 運用方法を選択する
アプリケーションをサーブレットコンテナ向けのディレクトリ構成にビルドします。
Application/ WEB-INF/ classes/ Extensions Application.woa lib/ JavaWOJSPServlet_client.jar Library Frameworks/ LICENSE tlds/ WOtaglib_1_0.tld web.xml
上記のうち、次のファイル・ディレクトリはWebObjectsをMonitorで運用する場合のディレクトリ構成を移したものです。
/Library/WebObjects/Extensions
のJARファイルがここに入ります。
サーブレットコンテナによっては、アプリケーションのフォーマットをEARやWARに限定しています。アプリケーションディレクトリをコピーしただけでは運用できない可能性がありますから注意してください。アプリケーションディレクトリをWARファイルに手動で変換することもできますが、最終的にWARファイルが必要であれば、プロジェクト作成時にWARファイルでの運用を選択しましょう。どちらもディレクトリ構造が異なるだけで、含まれるファイルは同じです。
WAR (Web ARchive)ファイルは、Webアプリケーションの各種リソースをまとめたファイルです。WARファイルのフォーマットに沿って、アプリケーションディレクトリとは若干異なるディレクトリ構成にビルドされます。/Library/WebObjects/Extensions
のJARファイルと、フレームワークのJARファイルがすべてlibディレクトリに含まれます。
サーブレットでは運用環境の他にも違いがありますが、スレッド以外は開発上あまり問題にならない細かいものです。標準のアプリケーションもサーブレットも、まったく同じコードで動作します。
WOServletAdaptor
)が使われます。
System.out
, System.err
はサーブレットコンテナのログに出力されます。
Application.main()
は呼ばれません。サーブレットを運用する場合のクラスパスは、Monitorで運用する場合とまったく変わってきます。大抵のサーブレットコンテナは、クラスパスをJava VMとは別に管理しています。クラスパスはサーブレットコンテナによって異なりますが、Tomcatでは次の順序でJARファイルを検索します。
アプリケーションをWARファイルとしてビルドすると、フレームワークを含めたすべてのJARファイルが/WEB-INF/lib以下に置かれます。
サーブレットを開発する上で、通常のWebObjectsアプリケーションとの最も大きな違いがスレッドの扱いです。通常のWebObjectsアプリケーションでは、次の条件下でスレッドセーフを保証しています。
WOAllowsConcurrentRequestHandling
がオフに設定されている場合。複数のHTTPリクエストを同時に受けたとき、この項目がオンになっていれば並行に処理しますが、オフになっていると一つずつ順に処理します(実質的にシングルスレッドで動作するので、パフォーマンスはオン時より落ちます)。
対してサーブレットではスレッドセーフが保証されません。WebObjectsに限らずWebアプリケーションをスレッドセーフにするのは難しいのですが、実装上の指針をいくらか挙げておきます。
synchronized
にします。
lock()
/unlock()
します。ロックしている間、データベースに接続するスレッドが一つに限定されます。ただし、あくまで同一プロセス内のみの制限です。他アプリケーションインスタンスまでは適用されません。
Mac OS Xには/Library/JBossというディレクトリがありますが、JBossを含めサーブレットコンテナは何もインストールされていません(Mac OS X ServerにはJBossがインストールされています)。お好きなサーブレットコンテナをインストールしておいてください。
プロジェクトを始める前に、プロジェクトで使用する(標準以外の)フレームワークのJARファイルを/Library/WebObjects/libにコピーしてください(JARファイルはフレームワークの「Resources>Java」ディレクトリに入っています)。サーブレットのプロジェクトではこのパスからJARファイルを検索します。
/Library/WebObjects/libには、あらかじめ次のフレームワークのJARファイルが含まれています。
新しくサーブレットのプロジェクトを作るには、通常のWebObjects Applicationのアシスタントの途中でいくつかチェックボックスをオンにするだけです。
「J2EE Integration」のウィンドウまでアシスタントを進め(図7.4.2.1[J2EE Integration])、次の項目をチェックします。
WARファイルの代わりに「Deploy as a Sigle Servlet Directory Deployment」をチェックしても構いませんが、この章ではWARファイルを前提に進めます。
図: J2EE Integration
WebObjectsのライセンスキーを入力します(図7.4.2.2[ライセンスキーの入力])。ライセンスキーは/System/Library/Frameworks/JavaWebObjects.framework/Resources/License.keyに保存されています。
図: ライセンスキーの入力
web.xmlファイル(サーブレットコンテナで使うアプリケーション設定ファイル)のテンプレートです。ビルド時にはテンプレートからweb.xmlファイルが生成されます。テンプレートはプロジェクトディレクトリのServlet Resources/WEB-INFディレクトリにあります。
サーブレットをResinで運用する場合は、テンプレートのjdbc/DefaultDataSource
(130行あたり)をコメントアウトしてください。コメントアウトしておかないと動作しません。
<resource-ref> <description> The data source to be used by EOF. If there are multiple data sources, then the definition below must be used to configure which JDBC URL (Model) should use which data source. If EOF should use a JDBC driver directly, this section must be commented out </description> <res-ref-name>jdbc/DefaultDataSource</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref>
プロジェクトをビルドすると、ビルド設定のSERVLET_WEBAPPS_DIR
で指定されたパスにサーブレットが生成されます(デフォルトは/Library/JBoss/3.2/deploy)。通常のWebObjectsアプリケーションとは異なり、buildディレクトリには生成されませんので注意してください。JBoss以外のサーブレットコンテナでテスト、もしくはインストールする場合はSERVLET_WEBAPPS_DIR
の設定を変更するといいでしょう。
また、ライセンスキーを間違えていると起動しません。次のエラーメッセージが表示されたら、ライセンスキーを確認してください。
com.webobjects.foundation.NSForwardException [java.lang.RuntimeException] \ Invalid serial number: <WOApplication>: Cannot be initialized.: Invalid \ serial number: <WOApplication>: Cannot be initialized.
サーブレットには次のURLでアクセスできます。
http://host:port/AppName/WebObjects/AppName.woa
最初のAppName
は、サーブレットコンテナのwebapps以下のアプリケーションディレクトリ名です。例えばTomcatをローカルホスト・ポート8080で起動し、WOWARServlet.warをwebapps以下に展開すると、URLは次のようになります。
http://localhost:8080/WOWARServlet/WebObjects/WOWARServlet.woa
Mac OS X以外のプラットフォームで動作しているサーブレットコンテナにも、同様の手順でインストールできます。
SERVLET_WEBAPPS_DIR
のパスに生成されたWARファイルを、サーブレットコンテナのwebappsディレクトリにコピーします。
% java -xvf App.war
ターゲットの編集ウィンドウを開きます。アプリケーションと同名のターゲットを選択し、メニューから「プロジェクト」>「アクティブターゲット"..."を編集」を選択するか、ターゲットをダブルクリックします(図7.4.4.1[ターゲットを選択])。
図: ターゲットを選択
SERVLET_SINGLE_DIR_DEPLOY = NO SERVLET_STUB_WAR = NO SERVLET_TRUE_WAR = YES SERVLET_DEPLOY_LICENSE = <your deployment license> SERVLET_WEBAPPS_DIR = /Library/JBoss/3.2/deploy
プロジェクトにJavaWOJSPServlet.frameworkを追加します。右クリックメニューから「追加」>「既存のフレームワーク...」を選択するか(図7.4.4.2[既存のフレームワークを追加])、メニューから「プロジェクト」>「プロジェクトに追加...」を選択し、/System/Library/Frameworks/JavaWOJSPServlet.frameworkを追加します。
図: 既存のフレームワークを追加