WebObjectsチュートリアル

WebObjectsはJ2EEに準拠しており、EJBやサーブレットを組み込めるほか、WebObjectsアプリケーションをサーブレットとして運用することができます。WebObjectsアプリケーションをサーブレットにすると、サーブレットコンテナで一サーブレットとして運用することになります(図6.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をインストールする必要がなく、他プラットフォームでも運用しやすくなります。

運用方法を設定するには、プロジェクトの作成時に選択するか、既存のプロジェクトのターゲットを編集します(図6.2.1[運用方法を選択する])。

図: 運用方法を選択する

アプリケーションディレクトリ

アプリケーションをサーブレットコンテナ向けのディレクトリ構成にビルドします。

アプリケーションディレクトリ

Application/
    WEB-INF/
        classes/
        Extensions
        Application.woa
        lib/
            JavaWOJSPServlet_client.jar
        Library
            Frameworks/
        LICENSE
        tlds/
            WOtaglib_1_0.tld
        web.xml

上記のうち、次のファイル・ディレクトリはWebObjectsをMonitorで運用する場合のディレクトリ構成を移したものです。

Extensions: /Library/WebObjects/ExtensionsのJARファイルがここに入ります。
Library: プロジェクトに追加したフレームワークがここに入ります。
LICENSE: WebObjectsの運用ライセンスキーを記述したファイルです。

サーブレットコンテナによっては、アプリケーションのフォーマットをEARやWARに限定しています。アプリケーションディレクトリをコピーしただけでは運用できない可能性がありますから注意してください。アプリケーションディレクトリをWARファイルに手動で変換することもできますが、最終的にWARファイルが必要であれば、プロジェクト作成時にWARファイルでの運用を選択しましょう。どちらもディレクトリ構造が異なるだけで、含まれるファイルは同じです。

WARファイル

WAR (Web ARchive)ファイルは、Webアプリケーションの各種リソースをまとめたファイルです。WARファイルのフォーマットに沿って、アプリケーションディレクトリとは若干異なるディレクトリ構成にビルドされます。/Library/WebObjects/ExtensionsのJARファイルと、フレームワークのJARファイルがすべてlibディレクトリに含まれます。

Monitorでの運用との違い

サーブレットでは運用環境の他にも違いがありますが、スレッド以外は開発上あまり問題にならない細かいものです。標準のアプリケーションもサーブレットも、まったく同じコードで動作します。

アプリケーションはサーブレットコンテナで動作します。Monitor/wotaskdは使いません。
サーブレットはシングルプロセスのJava VM上で動作します。MonitorではアプリケーションインスタンスごとにJava VMプロセスを起動します。
サーブレットでもMonitorでもマルチスレッドで動作しますが、サーブレットではスレッドセーフが保証されていません。
Webサーバアダプタはサーブレットアダプタ(WOServletAdaptor)が使われます。
Javaのクラスパスはサーブレットコンテナに依存します。
WOContextの代わりに、そのサブクラスであるWOServletContextが使われます。サーブレットの情報はWOServletContextから取得できます。
WebObjectsのセッションはサーブレットのセッションに保存されます。
System.out, System.errはサーブレットコンテナのログに出力されます。
Application.main()は呼ばれません。

クラスのロード

サーブレットを運用する場合のクラスパスは、Monitorで運用する場合とまったく変わってきます。大抵のサーブレットコンテナは、クラスパスをJava VMとは別に管理しています。クラスパスはサーブレットコンテナによって異なりますが、Tomcatでは次の順序でJARファイルを検索します。

環境変数CLASSPATH
Webアプリケーションの/WEB-INF/classes
Webアプリケーションの/WEB-INF/lib/*.jar
$CATALINA_HOME/common/classes
$CATALINA_HOME/common/endorsed/*.jar
$CATALINA_HOME/common/lib/*.jar
$CATALINA_HOME/shared/classes
$CATALINA_HOME/shared/lib/*.jar

アプリケーションをWARファイルとしてビルドすると、フレームワークを含めたすべてのJARファイルが/WEB-INF/lib以下に置かれます。

スレッド

サーブレットを開発する上で、通常のWebObjectsアプリケーションとの最も大きな違いがスレッドの扱いです。通常のWebObjectsアプリケーションでは、次の条件下でスレッドセーフを保証しています。

単インスタンス(シングルプロセス)内。複数のインスタンスや分散運用も含めたスレッドセーフは保証しません。
WOAllowsConcurrentRequestHandlingがオフに設定されている場合。複数のHTTPリクエストを同時に受けたとき、この項目がオンになっていれば並行に処理しますが、オフになっていると一つずつ順に処理します(実質的にシングルスレッドで動作するので、パフォーマンスはオン時より落ちます)。
対象はWebObjectsがデフォルトで使うオブジェクトのみ。例えば独自にEOEditingContextを生成した場合、WebObjectsはそのEOEditingContextのスレッド管理には関知しません。

対してサーブレットではスレッドセーフが保証されません。WebObjectsに限らずWebアプリケーションをスレッドセーフにするのは難しいのですが、実装上の指針をいくらか挙げておきます。

WebObjects Builderでキーを作成するときに、インスタンス変数と一緒にアクセサメソッドを定義します。必要であればアクセサメソッドをsynchronizedにします。
EOEditingContextを生成する場合は、必ずlock()/unlock()します。ロックしている間、データベースに接続するスレッドが一つに限定されます。ただし、あくまで同一プロセス内のみの制限です。他アプリケーションインスタンスまでは適用されません。
クラスメソッドになっているアクセサメソッドを使うタイミングに注意してください。

サーブレットの運用

アプリケーションをサーブレットとして運用する

メリットとデメリット

ライセンス

運用方法

アプリケーションディレクトリ

WARファイル

Monitorでの運用との違い

クラスのロード

スレッド