Oracle9iAS Containers for J2EEスタート・ガイド, リリース1.0.2.2

Oracle9iAS Containers for J2EE
スタート・ガイド
リリース 1.0.2.2
2001 年 8 月
部品番号:
部品番号 J04768-01
Oracle と Oracle のロゴは Oracle Corporation の登録商標です。Oracle9i、Oracle9i Application Server および Oracle9iAS Containers for J2EE
は、Oracle Corporation の商標です。記載されているその他の製品名および社名はその製品および会社を識別する目的にのみ使用されており、
それぞれ該当する所有者の商標です。
Copyright © 2000, Oracle Corporation
All Right Reserved
Oracle9iAS Containers for J2EE の使用
このガイドでは、Oracle9iAS Containers for J2EE（OC4J）で Java アプリケーションを開発し
デプロイするための一般的な詳細を説明します。
OC4J は、HTTP および RMI プロトコルによる接続をサポートする J2EE コンテナです。これ
らのプロトコルを通じて Servlet、JSP ページおよび EJB にアクセスします。
このガイドの内容は、以下のとおりです。
OC4J 概要
OC4J のインストール
OC4J の起動および停止
OC4J および J2EE アプリケーションの構成
Java アプリケーションのデプロイ
データ・ソースの設定
OC4J のセキュリティ
カスタム・タグ JAR ファイルの追加
リモート EJB
ロード・バランシングおよびクラスタリングによるパフォーマンスの向上
例
XML ファイル・リファレンス
FAQ および既知の障害
2
Oracle9iAS Containers for J2EEスタート・ガイド
OC4J 概要
Oracle9iAS R1.0.2.2 では、完全に Java で記述され、標準の Java Development Kit（JDK）に含
まれる Java 仮想マシン（Java VM）上で動作する Java 2 Enterprise Edition（J2EE 1.2）完全準
拠のコンテナが提供されます。OC4J はご使用のオペレーティング・システムにある標準 JDK
上で実行可能であり、Oracle9i JVM を必要としません。OC4J には独自の Web サーバーが含
まれていますが、このサーバーを Oracle HTTP Server のバック・エンドで J2EE アプリケーシ
ョンを処理するように構成することを推奨しています。
Oracle9iAS R1.0.2.2 の主な機能
Oracle9iAS R1.0.2.2 の主な機能は次のとおりです。
JDK 上で実行される Pure Java コンテナ/ランタイム
J2EE 1.2 完全準拠のコンテナ
JDK 上で実行される Pure Java コンテナ/ランタイム
コンテナ ランタイム
OC4J は完全に Java で実装され、次の機能を備えています。
1.
少ないリソースで動作－起動時には、10MB 以下のディスク領域および 12.2MB 以下の
メモリー領域で動作します。
2.
クイック・インストール－デフォルト構成のインストールは、2 分程度で終了します。
3.
JDK Java VM の活用－OC4J は、JDK 1.2.2_07 および JDK 1.3.x.x での動作が保証されて
います。各オペレーティング・システムおよびハードウェア・プラットフォーム上での
各 JDK リリースのパフォーマンス拡張および機能を活用しています。
4.
使いやすさ－標準 Java 開発ツールおよびプロファイリング・ツールをサポートしてい
ます。
5.
Sun SPARC Solaris、HP-UX、IBM AIX、Compaq Tru64、MS Windows および Linux のす
べてのオペレーティング・システムおよびハードウェア・プラットフォームで使用可能
です。
J2EE 1.2 完全準拠のコンテナ
OC4J は、JSP トランスレータ、Java Servlet エンジンおよび Enterprise JavaBeans（EJB）コン
テナを含む完全な J2EE 1.2 コンテナです。また、Java Message Service（JMS）や図 1-1 に示
す他の J2EE 1.2 仕様もサポートしています。
OC4J 概要
3
図 1-1
OC4J J2EE サポート
OC4J は、次の表 1-1 に示す標準 J2EE 1.2 API をサポートします。
表 1-1
4
Oracle9iAS J2EE サポート
J2EE 1.2 標準 API
サポートされるバージョン
Java Server Pages（JSP）
1.1
Servlet
2.2 および 2.3
Enterprise JavaBeans（EJB）
1.1 および 1.2 の一部
Java Transaction API（JTA）
1.0.1
Java Message Service（JMS）
1.0.1
Java Naming and Directory Interface（JNDI）
1.2
JavaMail
1.1.2
Java Database Connectivity（JDBC）
2.0
Oracle9iAS Containers for J2EEスタート・ガイド
J2EE 1.2 API および OC4J サポートの概要
標準 API およびこれら標準 API の OC4J サポートについては、次の項で説明します。
Java Servlet
Java Server Pages
Enterprise JavaBeans（EJB）
Java Database Connectivity（JDBC）
Java Naming and Directory Interface（JNDI）
Java Transaction API（JTA）
Java Message Service（JMS）
Java Servlet
OC4J Servlet エンジンでは、次の機能が提供されます。
Servlet 2.2 および 2.3 のサポート OC4J Servlet エンジンは、
Servlet 2.2 を完全にサポートし、
また Servlet 2.3 仕様もサポートします。Servlet 2.3 仕様は、将来の J2EE 1.3 仕様の一部です。
Tomcat との 100%の互
の互換性
の互換性 OC4J Servlet エンジンは、Apache Software Foundation が提供す
る Tomcat Servlet Engine と 100%の互換性があります。アプリケーション開発に Apache およ
び Tomcat を使用したことのある開発者であれば、アプリケーションを容易に OC4J Servlet
エンジンにデプロイすることができます。
フィルタの完全サポート OC4J では、Servlet 2.3 仕様の一部である単純なフィルタおよび複
雑なフィルタがサポートされます。具体的に言うと、フィルタとは、フィルタがマップされ
ているリソース（URL パターンや Servlet 名など）をクライアントがリクエストしたときに
起動されるコンポーネントです。フィルタは通常ラップされており、元のリクエスト・ター
ゲットの実行前または実行後にリクエスト、レスポンス、またはヘッダー値を操作します。
フィルタは、次のように設定できます。
単純（単一のリクエストに対して動作するように構成されている場合）
複雑（複数のリクエストに対して動作するように構成されている場合）
パラメータ化（入出力引数を受け付けるため）
チェーン（多数のフィルタが次々に起動されるチェーンへのデプロイ）
OC4J Servlet エンジンでは、次の機能が提供されます。
OC4J 概要
5
標準 WAR ファイル・ベースのデプロイ Servlet は、Web Application Archive（WAR）ファ
イルと呼ばれる標準形式によってパッケージされ、J2EE コンテナにデプロイされます。OC4J
では、次のツールが提供されます。
1.
いくつかの Servlet（および JSP（下記参照））を処理して WAR ファイルにパッケージ
する、WAR ファイル・パッケージング・ツール。
2.
結果の WAR ファイルを処理して 1 つ以上の OC4J インスタンスにデプロイする、WAR
ファイル・デプロイ・ツール。WAR デプロイ・ツールでは、クラスタを構成するすべ
ての OC4J インスタンスへのアーカイブの同時デプロイを可能にするクラスタ・デプロ
イも、サポートされます。
Servlet のオート・コンパイルおよびオート・デプロイ OC4J では、Servlet の自動コンパイ
ルおよび（サーバーが.WAR アーカイブを受け取る）オート・デプロイが提供されます。OC4J
は.WAR アーカイブを自動的に展開して、アプリケーションをインストールします。この機
能により、J2EE アプリケーション構築の開発、コンパイル、およびデプロイのステップが短
縮されます。
Servlet のステートフル・フェイルオーバーおよびクラスタ・デプロイ クラスタとは、ス
ケーラブルで可用性の高いサービスを透過的に提供するために、その動作を調整する OC4J
サーバーの集合を指します。Servlet は、HTTP セッション・オブジェクトを使用して、（Web
ショッピング・カートや旅行日程といった）メソッド・リクエスト間の状態を保存します。
OC4J は、IP マルチキャスト・ベースのクラスタリング・メカニズムをサポートします。こ
のメカニズムは、透過的に、つまり API のプログラム変更なしに、Servlet で Servlet セッシ
ョン状態、具体的には HTTP セッション・オブジェクトを他の OC4J インスタンスにレプリ
ケートできるようにします。
JavaServer Pages
OC4J では、JSP 1.1 準拠のトランスレータおよびランタイム・エンジンが提供されます。ユ
ーザーは、OC4J に対して Oracle JSP Translator（OJSP）も使用できます。これには、いくつ
か重要な機能があります。
JSP 1.1 の完全サポート：OC4J JSP トランスレータおよびランタイムでは、すべての JSP
ディレクティブおよびコア/標準 JSP タグのサポートを含む、JSP 1.1 の完全サポートが
提供されます。
単純タグ、ボディ・タグ、パラメータ化タグおよび協調動作タグ：OC4J では次のタグ
がサポートされます。
タグのボディが 1 度だけ評価される、単純 JSP タグ。
（イテレータ・ループなどで）タグの本文が複数回評価される可能性のある、ボデ
ィ・タグ。
タグがパラメータを受け取り表示できる、パラメータ化タグ。
6
Oracle9iAS Containers for J2EEスタート・ガイド
2 つのタグがタスクで協調動作するように設計された、特殊なパラメータ化タグで
ある、協調動作タグ。たとえば、1 つのタグでページ・スコープに値を追加し、別
のタグでこの値を検索してさらに処理することができます。
JSP キャッシング・タグ：JSP は動的 Web ページを生成するためのテクノロジなので、
キャッシングを使用して JSP で作成された Web サイトのパフォーマンスとスケーラビ
リティを向上させることができます。Oracle JSP Translator では、JSP 開発者によって特
定の JSP タグがキャッシュ可能かどうか示すことができる、標準構文が提供されます。
キャッシュは、共有 Java キャッシュ（たとえば、追加の XSL-T 変換を適用する必要が
ある場合）、または Web Cache（クライアントからのアクセスのために、最終ページが
キャッシュされる）のいずれかです。標準 JSP タグ構文を使って特定の JSP タグがキャ
ッシュ可能かどうかをタグ・レベルで示すことにより、OC4J はアプリケーション開発
者によるキャッシングの使用方法を簡素化し、また（ページ全体がキャッシュできない
場合でも）Web ページのコンポーネントをキャッシュ可能にする粒度を改善します。標
準スクリプティング拡張を使用すると、キャッシュされた JSP ページを、Oracle Web
Cache からだけでなく、Akamai 社のインターネット・コンテンツ・デリバリ・ネットワ
ーク（CDN）などからも使用できます。
標準 WAR ファイル・ベースのデプロイ：OC4J では、以下のことを行うツールも提供
されます。
J2EE 標準 Web Application Archive（WAR）ファイルに JSP ページおよび Servlet を
パッケージする。
デプロイ・ツールを使用して、1 つ以上の OC4J インスタンスに WAR ファイルを
デプロイする。WAR デプロイ・ツールでは、クラスタを構成するすべての OC4J
インスタンスへのアーカイブの同時デプロイを可能にする、クラスタ・デプロイも
サポートされます。
Enterprise JavaBeans（
（EJB）
）
OC4J では、次の機能を備えた JDK ベースの EJB コンテナが提供されます。
EJB 1.1 の完全サポートおよび EJB 2.0 の一部のサポート：OC4J EJB コンテナでは、EJB
1.1 仕様の完全サポートが提供されます。これには、Session Bean および Entity Bean の
完全サポート、Bean 管理の永続性（BMP）およびコンテナ管理の永続性（CMP）の完
全サポートが含まれています。OC4J では、標準 O-R マッピングおよび Message-Driven
Bean など、（将来の J2EE 1.3 仕様の一部である）EJB 2.0 仕様の機能も提供されます。
コンテナ管理の永続性（CMP）および Bean 管理の永続性（BMP）の完全実装：OC4J
では、Entity Bean のための完全な CMP および BMP が提供され、独自のオブジェクト・
リレーショナル（O-R）マッピング、および EJB 2.0 仕様で定められた O-R マッピング
の両方をサポートします。Oracle9iAS R1.0.2.2 の Entity Bean サポートには、多数の重要
な機能があります。
OC4J 概要
7
単純な O-R マッピング：Oracle9iAS R1.0.2.2 は、1 対 1、多対 1、および 1 対多の
オブジェクト・リレーショナル・マッピングをサポートします。O-R マッピングは、
Entity Bean のフィールドを対応するデータベース表に自動的にマッピングする機
能を提供します。さらに、ユーザーは EJB 間のオブジェクト・リレーショナル・
マッピングを指定できるので、開発者は追加作業なしで、EJB の 1 対 1 マッピング
を使用できます（これは EJB 2.0 仕様に含まれている機能です）。
複雑な O-R マッピング：単純な Bean を単純なフィールドにマップする場合を除い
ては、マッピングを行うカスタム・コードを記述せずに、あらゆる Bean をデータ
ベース表にマッピングすることは、一般に難しい問題です。そのため、ほとんどの
Entity Bean 開発は、2 つのカテゴリに分割されます。
CMP を使用する、単純な（1 対 1）オブジェクト・モデル
BMP を使用する、現実的な（より複雑な）オブジェクト・モデル
OC4J には、複雑なオブジェクト・モデルを容易にデータベース表にマッピングで
きる、O-R マッピング・システムが含まれています。このため、現実的なオブジェ
クト・モデルで CMP を使用することができます。具体的には、単純なオブジェク
トとプリミティブ（INT や CHAR など）、オブジェクト（複合オブジェクト）、
シリアライズ可能なオブジェクト（シリアライズし BLOB または CLOB に格納で
きる、複合オブジェクト）、エンティティ参照（他の Entity Bean への参照）およ
びコレクションといったタイプのフィールドを、Entity Bean 内でマッピングできる
ようになります。
動的な EJB スタブの生成：アプリケーション開発者は、ejbc、rmic、または同様の機能
を使って、クライアント・アプリケーションのために EJB スタブをプリコンパイルする
必要はありません。OC4J EJB コンテナにより、必要に応じて EJB スタブが生成されま
す。この機能により、アプリケーションおよびシステムのメンテナンスが、競合製品に
比べて著しく簡素化されます。
EAR ファイル・ベースのデプロイ：OC4J では、次の機能を実行するツールが提供され
ます。
1.
WAR および Enterprise JavaBeans を標準 J2EE 準拠の Enterprise Application Archives
（EAR
ファイル）にパッケージする。
2.
デプロイ・ツールを使用して、結果の.EAR ファイルをデプロイする。EAR ファイルは、
1 つ以上の OC4J インスタンスにデプロイ可能です。EAR デプロイ・ツールでは、クラ
スタを構成するすべての OC4J インスタンスへのアーカイブの同時デプロイを可能にす
る、クラスタ・デプロイもサポートされます。
EJB アプリケーションの簡素化されたオート・デプロイ：J2EE アプリケーションでは、
2 種類のデプロイメント・ディスクリプタ、すなわちモジュール構成ファイルがありま
す。すべてのアプリケーション・サーバーがサポートする汎用 J2EE デプロイメント・
ファイルとベンダー固有のデプロイメント・ファイルです。汎用 J2EE デプロイメント・
8
Oracle9iAS Containers for J2EEスタート・ガイド
ファイルは、アプリケーション開発者またはコンポーネント・アセンブラによって使用
されます。ベンダー固有のデプロイメント・ファイルは、アプリケーション・デプロイ
ヤによって使用されます。OC4J では、次の方法でアプリケーション・サーバー固有の
デプロイ情報をサポートします。
オート・デプロイ：オート・デプロイのシナリオでは、Oracle 固有のデプロイ情報
は、
J2EE EAR ファイルがサーバーでデプロイされたときに自動的に生成されます。
簡素化された構成のカスタマイズ：アプリケーション・サーバー固有のデプロイ情
報および構成情報を指定している一連の XML 構成ファイルを手動で編集すること
によって、Oracle 固有の構成情報をカスタマイズできます。これらのファイルには、
CMP のための表の自動生成および自動削除、セキュリティ・ロール・マッピング、
JNDI ネームスペース・アクセス、セッションの永続性とタイムアウトの設定、ト
ランザクション再試行の設定、CMP および O-R マッピング、バッファリング、キ
ャラクタ・セット、ロケール、仮想ディレクトリ、クラスタ構成、セッション追跡、
開発モードおよびデバッグ・モード設定などが含まれます。
ホット・デプロイ：アプリケーション開発者がデプロイ済みの EJB モジュールを
変更した場合、EJB の再デプロイやサーバーの再起動は必要ありません。ユーザー
は、server.xml 構成ファイルを編集するだけで十分です。その後、サーバーは、フ
ァイルを読み込んで、自動的に変更内容を認識します。
Java Database Connectivity（
（JDBC）
）
OC4J 内の JDBC サポートの主な機能は、次のとおりです。
JDBC 2.0 の完全サポート Oracle の JDBC ドライバは JDBC 2.0 に完全準拠しており、次の
機能を提供します。
データ型の完全サポート：BLOB、CLOB、キャラクタ・ストリーム、抽象データ型、
コレクションなどの拡張データ型をサポートします。Oracle9i データベース リリース 1
では、抽象データ型の継承もサポートします。
JDBC 2.0 接続プーリング：JDBC 2.0 接続プーリング機能を、完全にサポートします。
拡張機能：（Oracle データベースの障害発生時に、中間層が「フェイルオーバー」ノー
ドに接続をリダイレクトできる）透過的アプリケーション・フェイルオーバーのサポー
ト、スクロール可能な結果セット、バッチ更新、Unicode サポート、およびその他の拡
張機能があります。
Oracle8、Oracle8i、および Oracle9i リリース 1 のサポート：OC4J JDBC ドライバは、
Oracle8 R8.0.6、Oracle8i R8.1.7、および Oracle9i Release1 の各データベースで動作保証
されています。
Oracle は、
Merant JDBC ドライバ OC4J から非 Oracle データベースにアクセスするために、
パートナである Merant 社の JDBC ドライバを認定しています。
Merant は、
OC4J から Informix、
OC4J 概要
9
Sybase、Microsoft SQL Server、および IBM DB/2 の各データベースにアクセスする JDBC ド
ライバを提供しています。
Java Naming and Directory Interface（
（JNDI）
）
OC4J では、JNDI 1.2 の完全実装が提供されます。OC4J の Servlet および Enterprise JavaBeans
は、標準 JNDI プログラミング・インタフェースを使用してネーミング・サービスにアクセ
スします。OC4J の JNDI サービス・プロバイダは、XML ベースのファイル・システムで実
装されています。
Java Transaction API（
（JTA）
）
OC4J では、次の 2 つの部分で構成される JTA 1.0.1 仕様の完全実装が提供されます。
トランザクション・インタフェース：これは、トランザクション境界（デマーケーショ
ン）を可能にします。これにより、分散コンポーネントによって行われた作業が、グロ
ーバル・トランザクションにバインドされます。これは、操作のグループを、単一のグ
ローバル・トランザクションを構成するようにマークする方法です。
XA リソース・インタフェース：これは、分散トランザクションの処理を可能にする
X/Open XA インタフェースに基づいています。1 つ以上のリソース（データベースやキ
ューなど）にわたるトランザクションが、調整されます。
J2EE では、開発者が JTA による明示的なトランザクションのプログラミングを考慮する必
要はありません。（アプリケーション・デプロイメント・ディスクリプタが構成し、コンテ
ナが処理する）JDBC API および EJB API を介して、この作業が行われるためです。アプリ
ケーション開発者は、トランザクションの実装ではなく、その設計に集中することができま
す。
Java Message Service（
（JMS）
）
JMS は、Java プログラム間のメッセージ交換をサポートする J2EE メカニズムです。これに
よって、
Java は、
送信者と受信者が互いを意識する必要のない非同期通信をサポートします。
つまり、それぞれが個別に動作することが可能です。JMS では、2 つのメッセージ・モデル
がサポートされます。
Point-to-Point：これは、メッセージ・キューに基づいています。メッセージ・プロデュ
ーサが、キューにメッセージを送信します。メッセージ・コンシューマは、キューにア
タッチして、メッセージをリスニングすることができます。キューにメッセージが到着
すると、コンシューマはメッセージをデキューして、応答します。メッセージは、1 つ
のキューにのみ送信でき、1 つのコンシューマによってのみ使用されます。コンシュー
マは、オプションで、メッセージをフィルタして希望のメッセージ・タイプだけを指定
できます。
10
Oracle9iAS Containers for J2EEスタート・ガイド
パブリッシュ・サブスクライブ：これは、プロデューサがトピックにメッセージを送信
して、そのトピックに登録されているコンシューマがそれらのメッセージを取り出すモ
デルです。この場合、多数のコンシューマが同じメッセージを受信できます。
OC4J では、JMS 1.2 の完全実装が提供されます。
OC4J 概要
11
OC4J のインストール
要件
基本インストール
デフォルト構成のテスト
JSP および Servlet のクイック・スタート
Oracle HTTPServer のバック・エンドでアクセスされる OC4J の設定
要件
OC4J の現行リリースは、JDK バージョン 1.2.2_07 または 1.3.xxx 上で動作させると、さらに
安定します。Oracle9i Application Server R1.0.2.2 にバンドルされた JDK（JDK バージョン
1.2.2_07）の使用を推奨します。※Oracle9i Application Server R1.0.2.2 の一部のプラットフォ
ームでは JDK はバンドルされません。これらのプラットフォームでは別途 JDK をインスト
ールする必要があります。
ただし、Windows NT や Symantec JIT をバンドルした Java 2 環境を使用するホストでは問題
が生じる可能性があります。これらの問題を解決するには、JDK バージョン 1.3 にアップグ
レードするか、または JDK バージョン 1.2 の Symantec JIT を OC4J サーバーで使用しないよ
うにしてください。
JDK バージョン 1.3 へのアップグレード－JIT を使用禁止にするとパフォーマンスが劣
化するため、Windows NT サーバーにはこの方法をお薦めします。
Symantec JIT の使用禁止－Symantec JIT を使用しない場合、次のように OC4J サーバー
を起動してください。
java -Djava.compiler=none -jar orion.jar
OC4J は、インストール・ディレクトリ、lib/サブディレクトリ、およびデプロイされたアプ
リケーション EAR ファイル、WAR ファイル、または ejb-jar ファイルから、Java JAR フ
ァイルおよびクラス・ファイルをロードするので、OC4J を実行するために CLASSPATH にパ
スを追加する必要はありません。
基本インストール
OC4J は、Oracle9iAS Containers for J2EE CD-ROM の oc4j.zip という ZIP ファイルで配布さ
れています。このファイルを解凍して、README.TXT の指示に従ってください。この ZIP
12
Oracle9iAS Containers for J2EEスタート・ガイド
ファイルは、Oracle9i Application Server をインストールした$ORACLE_HOME ディレクトリに
インストールしてください。
Java 2 の Java 実行可能ファイル（できればバージョン 1.2.2_07）が、$PATH に存在している
必要があります。OC4J をインストールするには、以下のコマンドを実行します。
%
%
%
%
cd $ORACLE_HOME
unzip oc4j.zip
cd $ORACLE_HOME/j2ee/home
java -jar orion.jar -install
インストールが完了すると、$ORACLE_HOME/j2ee/home ディレクトリには、OC4J をデフ
ォルト構成で実行するために必要なファイルがすべて含まれています。インストールでは、
管理コンソールのコマンドライン・ツールで使用する、管理者ユーザーのパスワードの入力
が求められます。
注意:
注意 OC4J は、Sun Microsystems JDK バージョン 1.2.2_07 の tools.jar ファイ
ルと共にインストールされます。オラクル社では、当社製品にこの JAR ファイルを
含めるライセンスを Sun Microsystems 社から取得しています。ただし、ユーザーが
各自の tools.jar を使用したい場合、あるいは JDK バージョン 1.3 を使用しているた
めに問題が発生する場合は、ご使用のバージョンの JDK インストール・ディレクト
リの lib/tools.jar を j2ee/home ディレクトリにコピーしてください。この
JAR ファイルをコピーする際は、j2ee/home/lib ディレクトリではなく、必ず
j2ee/home ディレクトリにコピーしてください。
デフォルト構成のテスト
OC4J は、デフォルト Web サイトおよびデフォルト・アプリケーションを含む、デフォルト
構成でインストールされます。このため、即座に OC4J を起動してテストすることが可能で
す。
次のステップを実行して、OC4J を起動します。
1.
OC4J インストール・ディレクトリ（j2ee/home）にディレクトリを変更して、次のコ
マンドのいずれかを発行します。
java -jar orion.jar
j2ee/home/config にあるデフォルト構成ファイルで、
OC ４ J が起動されます。
java -jar orion.jar -config /mypath/server.xml
/mypath にある server.xml ファイルで、OC4J が起動されます。
OC4J のインストール
13
サーバーにより"Oracle9iAS (1.0.2.2) Container for J2EE initialized"というメッセージが出
力されます。
2.
Web ブラウザから"http://localhost:8888/"にアクセスして、OC4J をテストしま
す。デフォルトのポート番号を変更した場合は、"http://localhost:
<portnumber>/"で Web サーバーにアクセスしてください。
たとえば、Web ブラウザで http://localhost:8888/servlet/HelloWorldServlet
に接続して Web サーバーをテストすると、"Hello World"ページが返されます。
OC4J の起動および停止に関する詳細は、17ページの「OC4J の起動および停止」を参照して
ください。構成に関する詳細は、20ページの「OC4J および J2EE アプリケーションの構成」
を参照してください。
JSP および Servlet のクイック・スタート
OC4J で Web アプリケーションをデプロイするには、Servlet クラスおよび JSP ページを
j2ee/home/default-web-app ディレクトリにデプロイするか、本格的な J2EE アプリケ
ーションを WAR、
EJB-JAR または EAR フォーマットでデプロイできます。
Servlet および JSP
ページをコピーすることは、Oracle9iAS の以前のバージョンからアプリケーションを移行す
る最も簡単な方法です。
注意:
注意 J2EE 標準アプリケーションの使用は、EJB を使用する場合は必須であり、
すべての新規開発に対して推奨されます。
Servlet および JSP ページが既にある場合は、OC4J インストール・ディレクトリの
j2ee/home/default-web-app ディレクトリ以下にデプロイできます。
JSP ページは、j2ee/home/default-web-app ディレクトリ以下の任意の位置にデプ
ロイできます。http://localhost:8888/<path-to-JSP> 形式の URL でアクセス
可能です。たとえば、
j2ee/home/default-web-app/examples/Hello.jsp の JSP には、
http://localhost:8888/examples/Hello.jsp でアクセスできます。
Servlet クラスは、j2ee/home/default-web-app/WEB-INF/classes サブディレク
トリの、クラスの Java パッケージに対応するディレクトリにデプロイする必要があり
ます。たとえば、Servlet クラス my.HelloServlet は
j2ee/home/default-web-app/my/HelloServlet.class にデプロイされます。
Servlet には、http://localhost:8888/servlet/<class-name>形式の URL でア
クセス可能です。この場合、http://localhost:8888/servlet
/my.HelloServlet の URL からアクセス可能です。
14
Oracle9iAS Containers for J2EEスタート・ガイド
Oracle HTTPServer が OC4J へのリクエストをプロキシするように構成した場合（推奨構成）
（15ページの
「Oracle HTTPServer のバック・エンドでアクセスされる OC4J の設定」
を参照）
、
JSP へのアクセスを提供する URL に対して、Oracle HTTPServer の http.conf ファイルに
ProxyPass コマンドを追加する必要があります。たとえば、Oracle HTTPServer で
Hello.jsp ページにアクセスするには、次の行を httpd.conf.ファイルに追加します。
ProxyPass
ProxyPassReverse
/examples/ http://<oc4j-host>:8888/examples/
/examples/ http://<oc4j-host>:8888/examples/
Oracle HTTPServer のバック・エンドでアクセスされる OC4J の設定
OC4J および Oracle HTTP Server は、
両方とも Web サーバーとして使用できます。
Oracle HTTP
Server には、SSL など、より多くの機能があります。
Oracle HTTP Server は、プロキシ・リクエストの処理に使用します。
OC4J は、J2EE コンテナとして使用します。
Web
ブラウザ
HTTP
HTTP
Oracle HTTP Server
SSL
OC4J J2EE
アプリケーション
httpd.conf
ファイル
mod_proxy を使用して、Oracle HTTPServer から J2EE コンテナへリクエストをトンネルする
ことを推奨します。必須ではありませんが、Oracle9i Application Server が処理するすべての
ページは、SSL や Web Cache など他の Oracle9i Application Server サービスの機能を使用する
ことができます。これによって、静的ページを処理する Java リソースを節約できます。
1.
以下の行を追加して、Servlet へのリクエストなどの着信リクエストを OC4J にリダイレ
クトするように Oracle HTTPServer の mod_proxy モジュールを構成します。
<IfModule mod_proxy.c>
ProxyRequests On
ProxyPass /servlet/ http://<oc4j-host>:8888/servlet/
ProxyPassReverse /servlet/ http://<oc4j-host>:8888/servlet/
</IfModule>
これらの行は、次の構成ファイルのいずれかに追加できます。
OC4J のインストール
15
$ORACLE_HOME/Apache/Apache/conf/httpd.conf
oc4f.conf－oc4f.conf という新規ファイルを作成して、このファイルにプロキシ行を
含めることができます。これらのディレクティブが Oracle HTTP Server によって確
実に読み込まれるように、httpd.conf ファイルの適切な位置に次の行を追加してく
ださい。
"include oc4j.conf"
これによって、OC4J の構成を、httpd.conf ファイルの他の構成の詳細から分離できます。
httpd.conf ファイルにおけるエラーの発生率も低くなります。
注意:
注意 Java アプリケーションをデプロイする際は、アプリケーションを servlet/パ
ス以下にない URI にバインドしてください。Oracle HTTP Server 構成に、対応する
ProxyPass 要求を追加する必要があります。たとえば、EAR ファイルをデプロイし
て、それを URI /myApp にバインドした場合、次のプロキシ・コマンドを追加する
必要があります。
ProxyPass /myApp/ http://<oc4j-host>:8888/myApp/
ProxyPassReverse /myApp/ http://<oc4j-host>:8888/myApp/
2.
OC4J では、$ORACLE_HOME で稼動している Oracle HTTPServer とポート番号の競合が
発生する可能性があります。デフォルト・インストールでは、ポートの競合はありませ
ん。OC4J のポート番号は、デフォルトで 8888 です。Oracle HTTPServer のポート番号
は、デフォルトで 7777 です。これらの値を変更する場合、default-web-site.xml
の HTTP リスナー・ポートを Oracle HTTPServer がリスニングするポート番号以外のも
のに変更してください。
注意:
注意 OAS（Oracle Application Server）も、デフォルトでポート 8888 を使用するこ
とに注意してください。OAS から Oracle9iAS に移行する場合や、OAS と Oracle9iAS
を同じノードで実行する場合は、どちらか 1 つのサーバを別のポートをリスニング
するように変更する必要が生じることがあります。
OC4J デフォルト Web サイトのポート番号を変更するには、次のように<web-site>要
素を編集します。
<web-site port=”8888” display-name=" Default Oracle9iAS
Containers for J2EE Web Site">を<web-site port="<port>"
display-name=" Default Oracle9iAS Containers for J2EE Web Site">
に変更します。
<port>はデフォルト Web サイトに設定するポート番号です。
16
Oracle9iAS Containers for J2EEスタート・ガイド
OC4J の起動および停止
OC4J の起動
OC4J の再起動
OC4J の停止
OC4J の起動
OC4J は、起動されると、単一の標準 JDK 上で実行されます。OC4J を起動するには、OC4J
のインストール・ディレクトリ（$ORACLE_HOME/j2ee/home）に移動して、以下のコマン
ドを発行します。
% java -jar orion.jar <options>
表 1-2 に、オプションの一覧を示します。
表 1-2
OC4J モジュールのオプション
オプション
説明
-config <file>
デフォルトの server.xml 以外の構成ファイルを指定します。
-validateXML
すべての構成ファイルを厳密に検証します。構成ファイルを変更して、
その構文を検証したい場合に便利です。このオプションを指定しない場
合、検証は行なわれません。注意：このオプションでは、インターネッ
ト接続が必須です。
-out [file]
標準出力をルーティングするファイルを指定します。このファイルに、
System.out に出力されたメッセージや、Servlet ロギング・インタフェ
ースを介して送信されたメッセージは、このファイルにロギングされま
す。このオプションを指定しない場合、すべての出力は標準出力に書き
込まれます。
-err [file]
標準エラーをルーティングするファイルを指定します。System.err に
出力されたメッセージは、このファイルにロギングされます。このオプ
ションを指定しない場合、すべてのエラーは標準エラーに書き込まれま
す。
-install
サーバーをインストールして、管理者アカウントを有効にします。テキ
スト・ファイルをリライトして、入力されたパスワードを設定します。
初回のみ、使用してください。
OC4J の起動および停止
17
オプション
説明
-userThreads
ユーザー作成のスレッドからのコンテキスト検索サポートを有効にしま
す。
-quiet
標準出力を抑止します。
-version
バージョン番号を出力して終了します。
-help
ヘルプ・メッセージを出力します。
OC4J の管理
OC4J サーバーの起動後、コマンドライン・クライアント管理コンソール admin.jar からサー
バーを管理できます。構文は次のとおりです。
% java -jar admin.jar ormi://<host>:<port> <admin_id> <admin_password>
<options>
OC4J を起動しているホストでこれを実行する場合は、localhost を使用してください。
ORMI のデフォルト・ポート番号は 23791 です。管理者ユーザー名およびパスワードは、イ
ンストール時に定義しています。これらは、principals.xml ファイルに含まれています。
表 1-3 には、admin.jar の-restart および-shutdown オプションの一覧が示されていま
す。admin.jar のすべてのオプションに関する完全な説明は、表 1-5 にあります。
表 1-3 再起動および停止の管理コンソール・オプション
オプション
説明
-shutdown
OC4J サーバーを停止します。
-restart
OC4J サーバーを再起動します。OC4J コンテナが orion.jar によって
起動済みである必要があります。
OC4J の再起動
OC4J は、デプロイされたアプリケーションに対して行われた変更のほとんどを、自動的に
検出します。変更を検出すると、OC4J は、自動的にアプリケーションをリロードします。
したがって、アプリケーションの再デプロイ時に、サーバーを再起動する必要はありません。
ただし、data-source.xml、rmi.xml、principals.xml など、コンテナ・レベルの構
成ファイルを変更した場合は、OC4J を再起動する必要が生じることもあります。
OC4J を再起動または停止する場合は、admin.jar に含まれているクライアント管理コンソ
ールを使用することを推奨します。デフォルト・パラメータで OC4J を再起動するには、OC4J
インストール・ディレクトリに移動して、次のコマンドを発行します。
18
Oracle9iAS Containers for J2EEスタート・ガイド
java -jar admin.jar ormi://localhost/ <admin_id> <admin_password> -restart
このコマンドは、OC4J RMI リスナー・ポートに接続して、再起動を要求します。JVM 自体
が RMI メッセージをアクセプトしない不正な状態にあるなどの理由で、このコマンドが機能
しない場合があります。この場合は、kill または killall などの通常のオペレーティン
グ・システム・コマンドで、JVM を停止してください。
OC4J の停止
OC4J を OC4J コンテナのインストール・ディレクトリから停止するには、クライアント・コ
ンソールから以下のコマンドを発行してください。
% java -jar admin.jar ormi://localhost/ <admin_id> <admin_password>
-shutdown
このコマンドにより、コンテナが正常に停止します。コンテナが停止しない場合は、次のよ
うに force 引数を渡して強制的に停止します。
% java -jar admin.jar ormi://localhost/ <admin_id> <admin_password> -shutdown
force
この方法がうまくいかない場合は、オペレーティング・システム・コマンドで OC4J プロセ
スを強制終了してください。
OC4J の起動および停止
19
OC4J および J2EE アプリケーションの構成
XML 構成ファイルの概要
OC4J サーバーの構成
J2EE アプリケーションの構成
OC4J サーバー構成ファイルのディレクトリ構造
XML 構成ファイルの概要
各 OC4J サーバー・インスタンスには、複数の Web サイトおよび J2EE アプリケーションを
含めることができます。Web サイトは、HTTP クライアントに Web アプリケーションへのア
クセスを提供する HTTP リスナーです。アプリケーションは、EAR ファイルで定義された標
準 J2EE アプリケーションです。1 つのアプリケーションには、Web アプリケーション・コ
ンポーネント（Servlet および JSP ページ）および EJB アプリケーションの両方を含めること
ができます。Web アプリケーションを含んでいる J2EE アプリケーションは、Web サイトの
1 つが処理する URL に Web アプリケーションをバインドすることにより、Web クライアン
トからアクセスできるようになります。EJB のみを含むアプリケーションは、Web サイトの
URL にはバインドされませんが、RMI を介してアクセス可能です。これらの各コンポーネン
トの関係は、OC4J XML 構成ファイル内に記述されています。
図 1-2 は、基本的な OC4J サーバー構成ファイル、すべての Web サイト構成ファイル、およ
びロード・バランサ構成ファイルで構成される、OC4J サーバー構成を示したものです。J2EE
アプリケーション構成は、J2EE アプリケーション・デプロイおよびクライアント構成のため
の XML ファイルで構成されています。
20
1.
OC4J サーバー構成ファイル：これらのファイルは、OC4J 固有のもので、OC4J サーバ
ーを構成し、主要な J2EE 構成ファイルの位置をポイントします。これらの設定は、ユ
ーザーの J2EE アプリケーションではなく、サーバーに関連しています。
2.
J2EE アプリケーションおよびクライアントの、J2EE アプリケーション構成：これらの
ファイルは、J2EE アプリケーション固有で、J2EE アプリケーションのデプロイに使用
されます。
3.
ロード・バランサ構成：この OC ４ J 固有ファイルは、クライアントまたは Oracle
HTTPServer と OC4J サーバーとの間で使用できる、ロード・バランサの構成に使用され
ます。
Oracle9iAS Containers for J2EEスタート・ガイド
図 1-2
OC4J および J2EE アプリケーション XML ファイル
OC4Jサーバー
Webサイト
*web-site.xml
ロード・バランサ
Server Configuration Files
server.xml
principals.xml
data-sources.xml
rmi.xml
jms.xml
global-web-application.
xml
application.xml (global)
loadbalancer.xml
OC4J 構成ファイル
アプリケーション
クライアント
application.xml
orion-application
.xml
ejb-jar.xml
orion-ejb-jar.xml
web.xml
orion-web.xml
application-client.
xml
orion-application-client
.xml
J2EE 配置 XML ファイル
表 1-4 では、OC4J 内に含まれているコンポーネントおよび機能、そして、各構成ファイルが
これらのコンポーネントおよび機能にどのようにマッピングされているか、説明しています。
OC4J および J2EE アプリケーションの構成
21
表 1-4
OC4J の機能およびコンポーネント
機能/コンポーネント
機能 コンポーネント
XML 構成ファイル
OC4J 全体のサーバー構成
server.xml
OC4J セキュリティ
principals.xml
OC4J サーバーの
パフォーマンス
loadbalancer.xml
すべてのロード・バランサは、OC4J サーバーの外部
に存在します。詳細は、50ページの「ロード・バラン
シングおよびクラスタリングによるパフォーマンス
の向上」を参照してください。
OC4J JDBC サポート
data-sources.xml
OC4J 内の RMI サポート
rmi.xml
OC4J 内の JMS サポート
jms.xml
OC4J 内で定義された
Web サイト
*web-site.xml
J2EE アプリケーション
各 Web サイトは、各自の*web-site.xml ファイル
内で定義されます。接尾辞が web-site.xml である限り、
各*web-site.xml は個別に命名できます。アスタリ
スク（*）を任意の名前に置き換えてください。たと
えば、Web サイト XML ファイルを
my-web-site.xml という名前にすることができま
す。
application.xml および
orion-application.xml
*application.xml ファイルは、J2EE EAR ファイ
ルの定義に使用され、EJB JAR ファイルおよび Web
アプリケーション WAR ファイルの位置が含まれてい
ます。また、セキュリティ XML 定義ファイル
principals.xml の位置も定義します。
application.xml は、config/ディレクトリにも
存在していることに注意してください。これは、グロ
ーバルなアプリケーション定義ファイルです。
22
Oracle9iAS Containers for J2EEスタート・ガイド
機能/コンポーネント
機能 コンポーネント
XML 構成ファイル
J2EE Web
アプリケーション
global-web-application.xml は、すべての Web
サイトにバインドされている、Servlet の構成のための
OC4J 固有ファイルです。
各 Web アプリケーションのための web.xml および
orion-web.xml
*web.xml ファイルは、Web アプリケーションのデプ
ロイ・パラメータの定義に使用され、WAR ファイル
に含まれています。さらに、このファイルで、Servlet
および JSP にサブコンテキスト・マッピングを指定す
ることができます。たとえば、Servlet を<servlet>
要素に定義して、そのサブコンテキスト・マッピング
を<servlet-mapping>要素に定義します。
J2EE EJB アプリケーション
ejb-jar.xml および orion-ejb-jar.xml
*ejb-jar.xml ファイルは、EJB デプロイメント・
ディスクプリタの定義に使用され、EJB JAR ファイル
に含まれています。
J2EE クライアント・
アプリケーション
application-client.xml および
orion-application-client.xml
XML ファイルの相互関係
これらの XML ファイルのいくつかは、相互に関係があります。つまり、いくつかの XML
ファイルは、他の XML ファイル（OC4J 構成および J2EE アプリケーション）を参照します。
これらのファイルは、次のとおりです。
server.xml ファイルには、次のファイルへの参照が含まれています。
この OC4J サーバーの各 Web サイトすべての*web-site.xml ファイル。
他の各 OC4J サーバー構成ファイルの位置（図 1-2 に示されているように、
application.xml で定義される principals.xml は除く）。
OC4J にデプロイ済みの各 J2EE アプリケーションに対する、application.xml
ファイルの位置。
各*web-site.xml ファイルには、この Web サイトにバインドされている各 Web アプ
リケーションの XML ファイル（web.xml）に対する参照が含まれています。
application.xml ファイルには、principals.xml ファイルへの参照が含まれてい
ます。
OC4J および J2EE アプリケーションの構成
23
OC4J サーバーの構成
前述したように、server.xml ファイルは、OC4J サーバーの主要な構成ファイルです。こ
れは、この OC4J インスタンスに属する他の構成ファイルを参照します。server.xml ファ
イルは、図 1-3 の XML 構成ファイルを参照します。
図 1-3
server.xml 内で参照される
内で参照される XML ファイル
server.xml
|------>rmi.xml
|------>jms.xml
|------>application.xml
|
|------>data-sources.xml
|
`------->principals.xml
|------>global-web-application.xml
`------>default-web-site.xml
|------>default-web-app
`------>web-app
これら XML ファイルそれぞれの説明は、70ページの「XML ファイル・リファレンス」にあ
ります。これらのファイルの構成方法の例は、58ページの「J2EE アプリケーションの XML
構成例」に示されています。
論理サーバーおよびリスナー・ポート
OC4J の各インストールには、それぞれが独自のリスナー・ポートを持つ複数の論理 Web サ
ーバーと、RMI リスナー・ポートを持つ 1 つの論理 EJB コンテナを含めることができます。
Web サーバー構成ファイル（*web-site.xml）は、HTTP リスナー・ポートを示して
います。Web サーバーには、http://<host>:<web-server-port>形式の通常の
HTTP URL でアクセスします。デフォルト HTTP ポートは 8888 ですが、
default-web-site.xml で変更することができます。
24
Oracle9iAS Containers for J2EEスタート・ガイド
注意:
注意 通常、Web サーバーは、ユーザーがポート番号を憶えなくてもよいように、
HTTP サイトをポート 80 にデフォルト設定します。ただし、一部のオペレーティン
グ・システムでは、ポート 80 で Web サーバーを起動するためにはスーパー・ユー
ザー（管理者）権限が必要となります。OC4J では、スーパー・ユーザー権限を要
求する代わりに、
デフォルト・ポート番号を 8888 としてインストールされています。
つまり、Web サーバーへのすべてのアクセスは、ホスト名およびポート番号 8888
が伴います。
rmi.xml ファイルは、RMI リスナー・ポートを定義します。
ormi://<host>:<rmi-server-port>形式の URL で、EJB クライアント・プログラ
ムから RMI サーバーにアクセスします。デフォルト RMI ポートは 23791 です。
注意:
注意 RMI デフォルト・ポート番号（23971）と HTTP デフォルト・ポート番号（8888）
を混同しないようにしてください。
J2EE アプリケーションの構成
J2EE アプリケーションのデプロイ情報は、XML 構成ファイル内に含まれています。各アプ
リケーション・タイプには、次のようにそれぞれ独自の構成ファイルがあります。
J2EE アプリケーション・タイプ
XML 構成ファイル
Web アプリケーション
web.xml、orion-web.xml
EJB アプリケーション
ejb-jar.xml、orion-ejb-jar.xml
Web および EJB アプリケーションの組
合せ
application.xml、
orion-application.xml
クライアント
application-client.xml、
orion-application-client.xml
これらの XML ファイルについては、70ページの「XML ファイル・リファレンス」で詳しく
説明しています。
OC4J および J2EE アプリケーションの構成
25
OC4J サーバー構成ファイルのディレクトリ構造
各 OC4J サーバー構成ファイルは、図 1-4 のように config/ディレクトリに属しています。
図 1-4 構成ファイルのディレクトリ構造
config
|-------database-schemas
|
|-------ms-access.xml
|
|-------ms-sql.xml
|
|-------oracle.xml
|
`-------sybase.xml
|-------application.xml
|-------data-sources.xml
|-------default-web-site.xml
|-------global-web-application.xml
|-------jms.xml
|-------principals.xml
|-------rmi.xml
|-------secure-web-site.xml
`-------server.xml
アプリケーション構成ファイルのディレクトリ構造
J2EE アプリケーションの EAR ファイルを作成する場合、J2EE 仕様によって、クラスおよび
XML 構成ファイルを特定のディレクトリにデプロイするように指示されます。通常は、各
EAR ファイルは次のディレクトリ構造から作成されます。
図 1-5
EAR のディレクトリ構造
`-------META-INF
|
|
|-------application.xml
`-------orion-application.xml
|-------ejb.JAR
`-------web.WAR
26
Oracle9iAS Containers for J2EEスタート・ガイド
各 WAR ファイルは、次のように Web アプリケーションおよびその XML ファイルから作成
されます。
図 1-6
Web アプリケーションのディレクトリ構造
|-------WEB-INF
|
|-------web.xml
|
|-------orion-web.xml
|
`-------classes
`-------Servlet クラス
|
|-------index.html
`-------JSP ページ
各 EJB ファイルは、次のように EJB アプリケーション・クラスおよびその XML ファイルか
ら作成されます。
図 1-7
EJB アプリケーションのディレクトリ構造
|-------META-INF
|
|-------ejb-jar.xml
|
`-------orion-ejb-jar.xml
|
`-------EJB クラス
すべてのアプリケーション XML ファイルを、次のいずれかの位置で提供できます。
J2EE で指定されたアプリケーション・ディレクトリ内 － グローバル構成ファイルお
よびデフォルト構成ファイルを、アプリケーション固有の構成ファイルと分離できるた
め、こちらを推奨します。
すべての OC4J サーバーXML ファイルのある config/ディレクトリ内。
各 J2EE 固有ファイルは、OC4J 固有ファイルによって補足できることに注意してください。
たとえば、ejb-jar.xml ファイルは、Sun Microsystems 社によって定義されています。実
装固有の情報を指定するために、OC4J 固有の orion-ejb-jar.xml ファイルがオプション
で必要となる場合があります。
OC4J および J2EE アプリケーションの構成
27
Java アプリケーションのデプロイ
OC4J では、
Servlet および JSP ページを含む Web アプリケーション
（WAR ファイル）
、
Enterprise
JavaBeans を含む EJB アプリケーション（EJB-JAR ファイル）、Web および EJB アプリケー
ションをグループ化するエンタープライズ・アプリケーション（EAR ファイル）の、すべて
の J2EE アプリケーション・タイプをサポートします。J2EE 仕様では、（前項で説明した）
EAR ファイルのレイアウトが定義されています。
J2EE アプリケーションのデプロイの方法は、2 つあります。
展開ディレクトリ － ディレクトリ構造が EAR ファイルに必要な構造に類似している、
OC4J コンテナのファイル・システム上の展開ディレクトリ内に、アプリケーションを
含めます。次に、サーバー構成ファイルの一部を手動変更して、アプリケーションを登
録します。サーバーのディレクトリ・ツリーで直接作業することは、開発中には便利で
す。したがって、このタイプのデプロイは、アプリケーション開発時に使用してくださ
い。
EAR ファイル －（EJB JAR または Web WAR ファイル、あるいはその両方を含む）J2EE
準拠の EAR ファイルを作成し、デプロイします。admin.jar コマンドライン・ツール
を使用して、EAR ファイルをデプロイします。複数のサーバーにアプリケーションを
デプロイする場合、またはサーバーのファイル・システムに直接アクセスできない場合
には、EAR ファイルの作成が便利です。このタイプのデプロイは、アプリケーション
の出荷時には常に使用してください。
この項では、以下の項目をさらに詳しく説明します。
展開ディレクトリ・フォーマットのデプロイ
パッケージされた EAR ファイルのデプロイ
OC4J サーバー起動時のデプロイ
アプリケーションのホット・デプロイ
展開ディレクトリ・フォーマットのデプロイ
開発時は、クラスの変更、コンパイルおよび実行を迅速に行いたいでしょう。OC4J は、14
ページの「JSP および Servlet のクイック・スタート」に説明しているように、
j2ee/home/default-web-app ディレクトリに配置された Web アプリケーション、およ
び j2ee/home/applications ディレクトリに配置された EJB アプリケーションを、自動
的にデプロイします。
EJB または複雑な J2EE アプリケーションをデプロイするには、
ファイルを applications/
ディレクトリ下の独自のディレクトリに配置します。そのディレクトリ構造は、EAR ファイ
28
Oracle9iAS Containers for J2EEスタート・ガイド
ルに指定されているものと類似しています。
EAR ファイルでは EJB JAR ファイルまたは Web
アプリケーション WAR ファイルが存在している位置に、代わりに展開されたディレクトリ
を配置します。クラスのパッケージ構造にマッピングされるディレクトリ構造の中で、クラ
スが属する位置に、クラスを配置します。図 1-8 に、この構造を示します。
図 1-8 開発アプリケーション・ディレクトリ構造
applications
`------<appname>
|-------META-INF
|
`-------application.xml
|
|-------ejb
|
|-------EJB クラス (my.ejb.class は/my/ejb/class にマッピングされる)
|
`-------META-INF
|
`-------ejb-jar.xml
|-------web
|
|-------index.html
|
|-------JSP ページ
|
`-------WEB-INF
|
|----web.xml
|
`----classes
`-------Servlet クラス
|
(my.servlet は/my/servlet にマッピングされる)
`-------client
|-------クライアント・クラス
`-------META-INF
|-------application-client.xml
`-------orion-application-client.xml
server.xml、application.xml、*web-site.xml の各ファイルを、次のように変更します。
server.xml で、各 J2EE アプリケーションごとに、<application name=...
path=... auto-start="true">という新規エントリを追加するか、あるいは既存の
エントリを変更します。パスは、J2EE アプリケーションの META-INF の親ディレクト
Java アプリケーションのデプロイ
29
リにします。図 1-8 の例では、<appname>が"myapp"の場合、そのパスは次のようになり
ます。
<application_name="myapp"
path="/private/j2ee/home/applications/myapp"
auto-start="true" />
application.xml で<module>要素を変更し、展開ディレクトリ内に含まれる Web
アプリケーション、EJB アプリケーション、およびあらゆるクライアント・コードのデ
ィレクトリを含めるようにします。これは、<web-uri>、<ejb>、および<client>
要素を変更することになる場合もあります。これらの要素に含まれるパスは、
applications/ディレクトリからの相対パスで、各アプリケーション・タイプの WEB-INF
または META-INF ディレクトリの親ディレクトリである必要があります。"myapp"ア
プリケーション内に含まれている Web アプリケーションの<web-uri>が変更される例
を、以下に示します。
<module>
<web>
<web-uri>myapp/web</web-uri>
</web>
</module>
web-site.xml で、各 Web アプリケーションの<web-app ...>エントリを追加します。
これは、Web サイト内で Web アプリケーションをバインドするので、非常に重要です。
application 属性は、server.xml ファイルで定義している値と同じにする必要がありま
す。name 属性は、Web アプリケーションのディレクトリにします。name 属性のディレ
クトリ・パスは、application.xml の<web-uri>要素のパスに指定されている規則
と同じ規則に従うことに注意してください。
myapp Web アプリケーションの Web アプリケーション・バインディングのためには、
以下を追加してください。
<web-app application="myapp" name="myapp/web" root="/myapp" />
パッケージされた EAR ファイルのデプロイ
パッケージされた J2EE アプリケーションをデプロイすることを決定した場合、まずアプリ
ケーションをアセンブルしてから、admin.jar コマンドを使用してデプロイします。
アプリケーションのアセンブリ
アプリケーションのデプロイ
30
Oracle9iAS Containers for J2EEスタート・ガイド
アプリケーションのアセンブル
アプリケーションをアセンブルして、EAR ファイルにする必要があります。EAR ファイル
には、EJB JAR または Web WAR ファイル、あるいはその両方が含まれています。OC4J では
アセンブリ・ツールが提供されますが、これらのファイルを手動でアセンブルすることもで
きます。
手動アセンブリでは、必要なディレクトリを作成し、そのデプロイメント・ディスクリプタ
を編集し、J2EE 仕様に従って所定のディレクトリにファイルを配置します。最後に、適切な
Java ツールを実行して、アプリケーションを EAR ファイルにパッケージします。
別の方法として、OC4J では、J2EE モジュールおよびアプリケーションをパッケージする一連
の GUI アセンブリ・ツールが提供されます。OC4J では、以下の J2EE アセンブリ・ツールを
提供しています。
EAR アセンブラ（earassembler.jar）：J2EE モジュール（EJB JAR、Web アプリケー
ション、およびアプリケーション・クライアント）から、完全な J2EE アプリケーションを
アセンブルします。
EJB アセンブラ（ejbassembler.jar）
Web アプリケーション・アセンブラ（webassembler.jar）：JSP、Servlet、タグ・ラ
イブラリ、および静的コンテンツから、Web アプリケーションを作成します。
アプリケーション・クライアント・アセンブラ（clientassembler.jar）
タグ・ライブラリ・アセンブラ（taglibassemler.jar）
各ツールは、"java -jar xxx.jar"を実行することによって、個別に起動できます。
アプリケーションのデプロイ
OC4J には、J2EE アプリケーションをデプロイするためのコマンドライン・デプロイ・ツー
ル admin.jar コマンドが含まれています。このコマンドのオプションの一覧を、表 1-5 に
示します。
表 1-5 管理コンソール・オプション
オプション
説明
-shutdown
OC4J サーバーを停止します。
-restart
OC4J サーバーを再起動します。OC4J コンテナが orion.jar で
起動済みである必要があります。
Java アプリケーションのデプロイ
31
オプション
説明
-deploy
アプリケーションをデプロイ（再デプロイ）します。以下のサブス
イッチで、アプリケーション情報を提供してください。
-file：デプロイする EAR ファイルのパスおよびファイル名
-deploymentName：ユーザー定義のアプリケーション・デプロ
イ名
-targetPathapplications/：サーバー・ノードでの、アーカ
イブのデプロイ先のパス。デフォルトは applications/ディレ
クトリです。ターゲット・パスを使用することをお薦めします。こ
れは、EAR ファイルをコピーしデプロイするディレクトリです。
<target_path>が指定されない場合は、EAR ファイルは
applications/ディレクトリにコピーされます。OC4J は、EAR
ファイルの一意名を維持します。したがって、EAR ファイルを再
デプロイすると、OC4J は名前の前にアンダースコア('_')を付加し
てファイル名を変更し、他のアプリケーションの EAR ファイルが
上書きされないようにします。しかし、これが同じアプリケーショ
ンの場合は、applications/ディレクトリに各デプロイごとに別
個の EAR ファイルが含まれます。ターゲット・パスを使用する場
合には、この問題は発生しません。
-bindWebApp
<app_deploy_name>
<web_app_name>
<web_site_name>
<context_root>
指定されたサイトおよびルートに、Web アプリケーションをバイ
ンドします。
<app_deploy_name>は、-deploy オプションの
-deploymentName に使用された名前と同じアプリケーション名で
す。また、これは server.xml ファイルの<application
name=<app_name>>変数に保存されている名前と同じです。
<web_app_name>は、EAR ファイル内に含まれている.war 拡張
子なしの WAR ファイル名です。
<web_site_name>は、この Web アプリケーションがバインドさ
れる Web サイトを示す*web_site.xml ファイルの名前です。
<context_root>は、Web モジュールのルート・コンテキストで
す。
これは、<web_site_name>変数に示されている OC4J の*web_site.xml
構成ファイルに、エントリを作成します。
32
Oracle9iAS Containers for J2EEスタート・ガイド
オプション
説明
-application <name>
<command>
アプリケーション固有のコマンドおよびサブコマンド。次のサブス
イッチでさらに定義されます。
-dataSourceInfo：インストールされた DataSource オブジェ
クトに関する情報を取り出します。
-restart：アプリケーションを再起動します。このサブスイッチ
が有効であり、ファイルが前回のデプロイ以降に更新されている場
合には、オート・デプロイがトリガーされます。
-addUser <username> <password>：アプリケーションにユ
ーザーを追加します。
J2EE アプリケーション EAR ファイルのデプロイ
EAR ファイルを使用して、J2EE アプリケーションをデプロイするには、次のように
admin.jar を実行します。
java -jar admin.jar ormi://<host>:<port>
<username> <password> -deploy -file <filename>
-deploymentName <deploymentName> -targetpath <target_path>
このデプロイのステップにより、次のように server.xml にアプリケーションの新規エントリ
が作成されます。
<application name=<app_name> path=<path_EARfile> auto-start="true" />
ここで、
name 変数は、アプリケーション名です。
path 変数は、EAR ファイルのディレクトリおよびファイル名を示します。
auto-start 変数は、OC4J が再起動されたときに、このアプリケーションが自動的に
起動されるかどうかを示します。
Web アプリケーションのバインド
J2EE アプリケーションを OC4J の Web サーバーからアクセス可能にするには、Web アプリ
ケーションを明示的にバインドする必要があります。次のコマンドにより、アプリケーショ
ンが OC4J の Web サーバーにバインドされます。
java -jar admin.jar ormi://<host>:<port> <username> <password>
-bindWebApp <app_deploy_name> <web_app_name>
<web_site_name> <context_root>
Java アプリケーションのデプロイ
33
これにより、<web_site_name>変数に示されている OC4J *web-site.xml 構成ファイル
にエントリが作成されます。
OC4J サーバー起動時のデプロイ
OC4J 起動時に、アプリケーションを自動的にデプロイできます。サーバー起動時にデプロ
イするためには、server.xml および web-site.xml ファイルのアプリケーション情報を
変更します。管理コンソールが-deploy および-bindWebApp オプションで行うのと同様に、
これらのファイルを変更します。これらのオプションは、正しい情報を server.xml およ
び web-site.xml ファイルに設定します。いったん、これらの構成が XML 構成ファイルで
設定されると、orion.jar を実行して OC4J を起動した時に、アプリケーションが自動的に
デプロイされます。
server.xml で、OC4J の起動時に的にデプロイしたいアプリケーションごとに、
<application name=... path=... auto-start="true"/>の新規エントリを追
加するか、あるいは既存のエントリを変更します。auto-start 変数を true に設定す
ることによって、デプロイが行われます。
web-site.xml で、OC4J の起動時に自動的にデプロイしたい Web アプリケーション
ごとに、<web-app ...>エントリを追加します。これによって、Web サイト内で Web
アプリケーションがバインドされるため、非常に重要です。<name>は（.war 拡張子
なしの）WAR ファイル名なので、J2EE アプリケーションに含まれる WAR ファイルご
とに、1 行が必要とあります。
WAR ファイルを使用する Web アプリケーションをバインドするには、以下のエントリ
を追加します。
<web-app application="myapp" name="/private/myapp-web" root="/myapp" />
application 変数は、server.xml でアプリケーション名として設定した名前
です。
name 変数は、.war 拡張子なしの WAR ファイル名です。
root 変数は、Web サイトでのアプリケーションのルート・コンテキストを定義し
ます。たとえば、Web サイトを"http://localhost:8888"として定義している
場合、アプリケーションを開始するには、ブラウザから
"http://localhost:8888/myapp"にアクセスします。
注意:
注意 オート・デプロイが完了してから、クライアントからアクセスしてください。
すべての EAR のデプロイ、および WAR/JAR ファイルの更新を待機します。これら
の完了前にアクセスすると、クライアントからのアクセスは失敗します。
34
Oracle9iAS Containers for J2EEスタート・ガイド
アプリケーションのホット・デプロイ
OC4J では、一部の XML ファイルのタイムスタンプが変更された場合に、アプリケーション
ホット・デプロイされます。アプリケーションを再デプロイするために OC ４ J を再起動す
るのは、共通の問題です。代わりに、OC4J は、一部の XML ファイルが変更されたときに、
それを認識して、適切に再デプロイを行います。ホット・デプロイは、ある場合には有効で
すが、すべての場合に有効ではありません。それぞれの、以下のとおりです。
ホット・デプロイが発生するケース：
server.xml への手動変更
WAR および EAR ファイルへの変更
（展開ディレクトリ・フォーマットの下の）Servlet クラスおよび JSP ファイルへの変更
ホット・デプロイが発生しないケース：
default-web-site.xml への手動変更
（展開ディレクトリ・フォーマットの下の）Bean クラスへの変更
適切な XML ファイルを変更すると、サーバーはその変更を自動的に検出します。クライア
ントが次にアプリケーションにアクセスしたときに、OC4J はそのアプリケーションを再デ
プロイします。OC4J が更新をチェックしない場合は、admin.jar コンソールを使って再デ
プロイするか、あるいは OC4J サーバーを手動で再起動して再デプロイします。
データ・ソースの設定
J2EE アプリケーションは、java.sql.DataSource オブジェクトを通じてデータベースへ
の接続を取得します。データ・ソース・オブジェクトは、データベースへの接続に使用され
ます。各データ・ソースを、データベースへの接続情報を含むように設定できます。さらに、
以下の機能を提供する特別なタイプのデータ・ソース・オブジェクトを作成することができ
ます。
スケーラビリティを改善するために、データベースへの JDBC 接続プールを管理する。
EJB のコンテナ管理トランザクションをサポートするために、
Java Transaction API
（JTA）
と協調する。
data-sources.xml で、データ・ソースを指定します。実行時にこれらのデータ・ソース
の位置を特定する JNDI 名も指定します。各データ・ソースの XML 定義には、JDBC 接続文
字列、およびオプションでデータベース・アカウントが含まれます。アプリケーションは、
いったんデプロイされると、実行時に JNDI ルックアップを介してデータ・ソースにアクセ
スします。
Java アプリケーションのデプロイ
35
注意:
注意 data-sources.xml ファイルの変更後には、OC4J を再起動する必要があ
ります。
典型的なデータ・ソース設定
JDBC Thin ドライバを使用する場合は、data-sources.xml ファイルのデータベース URL にデー
タベースのホスト、ポート、および SID を提供します。<host>、<port>、および<sid>に適切
な値を挿入し、次のようにデータ・ソースを宣言します。
<data-source
class="com.evermind.sql.DriverManagerDataSource"
connection-driver="oracle.jdbc.driver.OracleDriver"
ejb-location="jdbc/myPooledDataSource"
xa-location="jdbc/myXADataSource"
location="jdbc/myDataSource"
url="jdbc:oracle:thin:@<host>:<port>:<sid>"
username="scott"
password="tiger"
/>
class エントリ：常に"com.evermind.sql.DriverManagerDataSource"クラス
を使用してください。
connection-driver エントリ：常に"oracle.jdbc.driver.OracleDriver"ク
ラスを使用してください。
ejb-location エントリ：データ・ソースへアクセスするために使用する JNDI 名を示
します。この例では、データ・ソースは、JDBC 接続プールを使用します。Servlet、JSP
ページ、JavaBeans、または EJB からプールされたデータ・ソースを取得します。
xa-location エントリ：ejb-location エントリを使用する場合には、このエントリも追
加してください。
location エントリ：接続プールを使用しない場合に、使用する JNDI 名を示します。
詳細は、39ページの「プールされてないデータ・ソースの使用」を参照してください。
url エントリ：データベースの JDBC 接続文字列。
username および password エントリ：アプリケーション・コード内に、ユーザー名
およびパスワードをハードコードするのを回避したい場合に、データベースへの接続時
に使用します。これはオプションです。コードでこれらのエントリを提供する例は、39
ページの「ユーザー名およびパスワードのエントリ」を参照してください。
次のように、アプリケーション・コードから接続を取得できます。
36
Oracle9iAS Containers for J2EEスタート・ガイド
InitialContext ic = new InitialContext();
DataSource ds = (DataSource)ic.lookup("jdbc/myPooledDataSource");
Connection conn = ds.getConnection();
... 何らかの処理 ...
conn.close();
この例では、ejb-location エントリに関連付けられた JNDI 名から、接続を取得しました。し
たがって、接続はプールから取り出され、conn.close()文は接続をプールへ返します。
JDBC OCI の使用
一般的に、JDBC OCI ドライバは、JDBC Thin ドライバより高速です。ただし、Oracle クライ
アントのインストールが必要となります。JDBC OCI を使用するには、url エントリを JDBC
OCI エントリに置き換えます。データベースの tnsname または Oracle Net Services の名前と
値のリストを提供してください。
<data-source
class="com.evermind.sql.DriverManagerDataSource"
connection-driver="oracle.jdbc.driver.OracleDriver"
ejb-location="jdbc/myPooledDataSource"
xa-location="jdbc/myXADataSource"
location="jdbc/myDataSource"
url="jdbc:oracle:oci:@tnsname"
username="scott"
password="tiger"
/>
JDBC OCI ドライバは、Database Cache を利用する際に、使用できます。これを行うには、
OC4J 起動前に、OCI_CACHE 環境変数を 1 に設定します。
Merant ドライバの使用
Merant JDBC ドライバは、異種データベースに接続するために、OC4J で使用可能です。Merant
JDBC ドライバは、Oracle データベースには接続せず、Microsoft SQL Server、Sybase、IBM DB2
など、Oracle 以外のデータベースへの接続に使用されます。OC4J と Merant ドライバを併用
する場合は、Merant に対応するエントリを data-sources.xml ファイルに追加します。
注意:
注意 Merant JDBC ドライバをインストールするには、Merant 社のドキュメントを
参照してください。
SQL Server のデータ・ソース・エントリの例を、次に示します。詳細は、『Merant DataDirect
Connect JDBC ユーザーズ・ガイドおよびリファレンス』を参照してください。
Java アプリケーションのデプロイ
37
<data-source
class="com.evermind.sql.DriverManagerDataSource"
name="MerantDS"
location="jdbc/MerantCoreSSDS"
xa-location="jdbc/xa/MerantSSXADS"
ejb-location="jdbc/MerantSSDS"
connection-driver="com.merant.datadirect.jdbc.sqlserver.SQLServerDrive
r"
username="test"
password="secret"
url="jdbc:sqlserver//hostname:port;User=test;Password=secret"
inactivity-timeout="30"
/>
DB2 データベースについては、次のサンプルを参照してください。
<data-source
class="com.evermind.sql.DriverManagerDataSource"
name="MerantDS"
location="jdbc/MerantCoreDB2DS"
xa-location="jdbc/xa/MerantDB2XADS"
ejb-location="jdbc/MerantDB2DS"
connection-driver="com.merant.datadirect.jdbc.db2.DB2Driver"
username="test"
password="secret"
url="jdbc:sqlserver//hostname:port;LocationName=jdbc;CollectionId=default
;Packag
eName=pkg1;User=test;Password=secret"
inactivity-timeout="30"
/>
Sybase データベースについては、次のサンプルを参照してください。
<data-source
class="com.evermind.sql.DriverManagerDataSource"
name="MerantDS"
location="jdbc/MerantCoreSybaseDS"
xa-location="jdbc/xa/MerantSybaseXADS"
ejb-location="jdbc/MerantSybaseDS"
connection-driver="com.merant.datadirect.jdbc.sybase.SybaseDriver"
username="test"
password="secret"
url="jdbc:sqlserver//hostname:port;User=test;Password=secret"
inactivity-timeout="30"
/>
38
Oracle9iAS Containers for J2EEスタート・ガイド
ユーザー名およびパスワードのエントリ
ユーザー名およびパスワードは、data-sources.xml ファイルで提供するか、あるいは次
のように、実行時にアプリケーション・コードから提供します。
InitialContext ic = new InitialContext();
DataSource ds = (DataSource)ic.lookup("jdbc/myPooledDataSource");
Connection conn = ds.getConnection("scott", "tiger");
... 何らかの処理 ...
conn.close();
プールされてないデータ・ソースの使用
接続プーリングが提供されるため、ほとんどの場合は ejb-location エントリに関連付け
られた JNDI 名を使用してください。ただし、クライアントごとに 1 つの接続が必要な場合
など、各自で接続をオープンしクローズしたいケースがあります。この場合は、次に示され
ているように location エントリに関連付けられた JNDI 名を使用します。
InitialContext ic = new InitialContext();
// location エントリの名前を使用
DataSource ds = (DataSource)ic.lookup("jdbc/myDataSource");
Connection conn = ds.getConnection("scott", "tiger");
... 何らかの処理 ...
conn.close(); // 接続が実際にクローズされる
Java アプリケーションのデプロイ
39
OC4J のセキュリティ
OC4J には、次のセキュリティ機能があります。
認可：異なるユーザーおよびグループに、アプリケーションへのアクセスを許可します。
EAR、WAR または EJB JAR ファイルに埋め込まれている、（汎用およびコンテナ固有
の）2 つのデプロイメント・ディスクリプタで、認可情報を提供します。
汎用のデプロイメント・ディスクリプタは、論理ロールを使用したアクセス規則を
記述します。
コンテナ固有のデプロイメント・ディスクリプタは、これらの論理ロールを、
principals.xml で定義される具体的なユーザーおよびグループにマップします。
認証：ユーザーを認証して、ユーザーを定義します。
ユーザーおよびグループを principals.xml ファイルで定義します。また、独自の Java ク
ラスを提供して、異なるストアからユーザーおよびグループ情報をフェッチできます。
機密性：暗号化通信を保証します。
OC4J を、Oracle HTTPServer のバックエンドでアクセスされるように設定することを、
お薦めします。こうすると、Oracle HTTP Server で機密性を維持できます。たとえば、
Oracle HTTP Server で SSL を使用するように構成できます。SSL モードで Oracle HTTP
Server を設定する方法については、Oracle HTTP Server のマニュアルを参照してくださ
い。
SSL を使用するように OC4J を設定することは、お薦めしません。Oracle HTTP Server
と OC4J との間の追加の SSL ハンドシェイクにより、パフォーマンスが大幅に劣化しま
す。
認可
ユーザーおよびグループは、コンテナによって認識される識別情報です。ロールは、異なる
オブジェクトへのアクセス権を示すために、各アプリケーションが使用する論理的な識別情
報です。ユーザーは、デジタル証明書に対応付けることができます。デプロイメント・ディ
スクリプタは、アプリケーションの異なる部分にアクセスするために必要なロールを示しま
す。また、論理ロールとコンテナが認識するユーザー/グループとの間のマッピングも、デプ
ロイメント・ディスクリプタによって提供されます。
ユーザー、グループ、およびロールの定義は、次の項で説明します。
ユーザーおよびグループの指定
40
Oracle9iAS Containers for J2EEスタート・ガイド
J2EE アプリケーションの論理ロールの指定
ユーザーおよびグループに対する論理ロールのマッピング
ユーザーおよびグループの指定
OC4J では、すべてのデプロイされたアプリケーションによって共有されるユーザーおよび
グループ、あるいは特定のアプリケーション固有のユーザーおよびグループの定義をサポー
トします。
共有されるユーザーおよびグループの一覧は、principals.xml ファイルにあります。
アプリケーション固有のユーザーおよびグループの一覧は、アプリケーション固有の
principals.xml にあります。principals.xml のパスは、そのアプリケーション
の orion-application.xml ファイルに示されています。
以下の principals.xml からの抜粋は、allusers というグループと、ユーザー名 guest
およびパスワード welcome のユーザーの定義方法を示したものです。guest ユーザーは、
allusers グループのメンバーとなっています。
<principals>
<groups>
<group name="allusers">
<description>Group for all normal users</description>
<permission name="rmi:login" />
<permission name="com.evermind.server.rmi.RMIPermission" />
</group>
.... 他のグループ ...
</groups>
<users>
<user username="guest" password="welcome">
<description>Guest user</description>
<group-membership group="allusers" />
</user>
</users>
</principals>
J2EE アプリケーションの論理ロールの指定
アプリケーションの論理ロールの指定
アプリケーションが使用する論理ロールを、XML デプロイメント・ディスクリプタで指定
します。アプリケーションのタイプに応じて、次のいずれかのファイルで、論理ロールを更
新してください。
WAR ファイルの web.xml
EJB JAR ファイルの ejb-jar.xml
EAR ファイルの application.xml
OC4J のセキュリティ
41
これらのデプロイメント・ディスクリプタそれぞれにおいて、<security-role>という
XML 要素によってロールが定義されます。
例 1-1
EJB JAR セキュリティ・ロール定義
この例では、ejb-jar.xml デプロイメント・ディスクリプタに VISITOR という論理ロール
が作成されます。
1.
論理セキュリティ・ロール VISITOR を<security-role>要素に定義します。
<security-role>
<description>A role for every user</description>
<role-name>VISITOR</role-name>
</security-role>
2.
このロールがアクセスできる Bean およびメソッドを<method-permission>要素で定
義します。
<method-permission>
<description>VISITOR role needed for CustomerBean
methods</description>
<role-name>VISITOR</role-name>
<method>
<ejb-name>customerbean</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
論理ロールのユーザーおよびグループへのマッピング
論理ロールのユーザーおよびグループへのマッピング
アプリケーション・デプロイメント・ディスクリプタで定義された論理ロールを、
principals.xml ファイルで定義された実際のユーザーおよびグループにマッピングしま
す。マッピングは、コンテナ固有のデプロイメント・ディスクリプタに
<security-role-mapping>要素で指定されます。
例 1-2 論理ロールの実際のロールへのマッピング
この例では、orion-ejb-jar.xml ファイルで、論理ロール VISITOR を allusers グル
ープにマッピングしています。このグループのメンバーとしてログイン可能なユーザーは、
VISITOR ロールを持つと考えられるため、customerbean のメソッドを実行できます。
<security-role-mapping name="VISITOR">
<group name="allusers" />
</security-role-mapping>
注意:
注意 論理ロールは、単一のグループ、あるいは複数のグループにマッピングでき
ます。
42
Oracle9iAS Containers for J2EEスタート・ガイド
ユーザー・リポジトリのプラグイン
OC4J コンテナのデフォルトの動作は、ユーザー名、グループ、およびパスワードを
principals.xml ファイルから読み込むことです。これは常にセキュアであるとはいえま
せん。代わりに、コンテナが、ユーザー名、パスワード、およびグループを操作するユーザ
ー・リポジトリを使用するように、指定できます。独自のユーザー・リポジトリを指定する
か、または OC4J で提供されるカスタム・ユーザー・マネージャのサンプル実装を使用でき
ます。
com.evermind.security.UserManager インタフェースのサンプル実装は、
com.evermind.sql.DataSourceUserManager で提供されます。OC4J で任意のユーザ
ー・マネージャを使用するには、次のいずれかの XML ファイルでユーザー・マネージャ・
クラス名を指定します。
単一のアプリケーションの orion-application.xml ファイル
config/ディレクトリに含まれる、すべてのアプリケーションのためのグローバル
application.xml ファイル
UserManager は、createUser()、getUser()、getGroup()などのインタフェースで
ユーザー、グループ、およびパスワードを管理します。OC4J が提供する
DataSourceUserManager クラスは、DataSource で指定されたデータベースで、ユーザ
ーを管理します。XML 構成ファイルで、データが格納される表名および列名を定義する必
要があります。以下の例に示すように、XML のプロパティ内にこれらを設定することが必
要です。アプリケーションへユーザー・マネージャを登録するには、通常、次のように
orion-application.xml ファイルに指定します。
<user-manager class="com.evermind.sql.DataSourceUserManager">
<property name="table" value="j2ee_users" />
<property name="userNameField" value="username" />
<property name="passwordField" value="password" />
<property name="dataSource" value="jdbc/OracleCoreDS" />
<property name="groupMemberShipTableName" value="second_table" />
<property name="groupMemberShipGroupFieldName" value="group" />
<property name="groupMemberShipUserNameFieldName" value="userId"
/>
</user-manager>
ユーザー・マネージャを正しく動作させるには、これらのプロパティを設定する必要があり
ます。この DataSourceUserManager は、データベースに 2 つの表が存在することを想定
しています。
ユーザー名およびパスワードのための表
ユーザーとグループの関連付けのための表
OC4J のセキュリティ
43
使用可能なグループのリストのための表が存在しないことに、注意してください。グループ
のリストは、principals.xml で指定されます。グループからロールへのマッピングは、
OC4J 固有の application.xml で指定されます。
UserManager は、親子関係のある階層の実装です。DataSourceUserManager の親は、
常にデフォルトのファイル・ベース（principals.xml）の UserManager です。ただし、
setParent()メソッドで、親を変更することができます。サンプル
DataSourceUserManager は parent.getGroups()を起動して、使用可能なすべてのグ
ループを取得します。
認証
HTTP クライアントの認証
アプリケーションのほとんどのクライアントは、Oracle HTTP Server の mod_proxy モ
ジュールを通じてコンテナにアクセスする、Web ブラウザです。OC4J では、保護された URL
にアクセスする際に、クライアントが自身を認証することが要求されます。
EJB クライアントの認証
リモート・コンテナの EJB にアクセスする場合は、このコンテナに有効な資格証明を渡す必
要があります。
スタンドアロン・クライアントは、EAR ファイルと共にデプロイされた
jndi.properties ファイルで、資格証明を定義します。
コンテナ内で実行される Servlet または JavaBean は、リモート EJB をルックアップする
ために作成された InitialContext 内で、資格証明を渡します。
JNDI プロパティ内の資格証明 jndi.properties ファイル内で、リモート EJB をルック
アップするときに使用するユーザー名（プリンシパル）およびパスワード（資格証明）を示
します。
たとえば、guest/welcome でリモート EJB にアクセスする場合、次のプロパティを定義し
ます。factory.initial プロパティは、Oracle JNDI 実装を使用することを示します。
java.naming.security.principal=guest
java.naming.security.credentials=welcome
java.naming.factory.initial=
com.evermind.server.ApplicationClientInitialContextFactory
java.naming.provider.url=ormi://localhost/ejbsamples
アプリケーション・プログラムで、リモート EJB を認証してアクセスします。
InitialContext ic = new InitialContext();
CustomerHome = (CustomerHome)ic.lookup("java:comp/env/customerbean");
44
Oracle9iAS Containers for J2EEスタート・ガイド
InitialContext の資格証明 Servlet または JavaBean からリモート EJB にアクセスするには、
次のように InitialContext オブジェクトの資格証明を渡します。
Hashtable env = new Hashtable();
env.put("java.naming.provider.url", "ormi://localhost/ejbsamples");
env.put("java.naming.factory.initial",
"com.evermind.server.ApplicationClientInitialContextFactory");
env.put(Context.SECURITY_PRINCIPAL, "guest");
env.put(Context.SECURITY_CREDENTIALS, "welcome");
Context ic = new InitialContext (env);
CustomerHome = (CustomerHome)ic.lookup("java:comp/env/customerbean")
OC4J のセキュリティ
45
カスタム・タグ JAR ファイルの追加
Bean の JAR ファイルの追加
OC4J は、標準 Servlet 2.2/2.3 の Web アプリケーション・デプロイ・ディレクトリ構造をサポ
ートします。次の操作を行うことによって、ユーザーは Web アプリケーションで利用可能な
Java クラスを作成できます。
1.
すべての Java クラス・ファイルを、/WEB-INF/classes 以下の適切なパッケージ名の
ディレクトリにコピーします。
2.
JAR ファイルを、/WEB-INF/lib ディレクトリ以下に配置します。
ユーザーの Web アプリケーションで Java クラスを利用可能になった後は、ユーザーはクラ
スにアクセスできます。たとえば、ユーザーは、JSP ページで<jsp:useBean>タグを介し
て JavaBean にアクセスできます。
カスタム・タグの追加
OC4J でタグをカスタマイズするには、次の手順が必要です。
クラスまたは JAR ファイルを、/WEB-INF/classes または/WEB-INF/lib 以下に配
置します。これにより、タグ関連クラスが、Web アプリケーションで利用可能になりま
す。
web.xml 構成ファイルで、taglib ネームスペースを設定します。たとえば、web.xml
ファイルで、"http://www.foo.com/footaglib/"を"foo.tld"にバインドできま
す。これは、オプションのステップです。
JSP ページに、taglib ディレクティブを追加します。つまり、taglib が
"http://www.foo.com/footaglib/"、taglib 接頭辞が"mytagprefix"であるとす
ると、次のディレクティブを JSP ページに追加します。
<%@ taglib prefix="mytagprefix" uri="http://www.foo.com/footaglib/" >
このディレクティブの URI は、次のいずれかをポイントできます。
web.xml ファイルで設定済みのネームスペース
.tld ファイル（/WEB-INF/foo.tld など）
/MEA-INF/taglib.tld を含む、タグ・ライブラリ JAR ファイル
（/WEB-INF/lib/myfootag.jar など）
46
Oracle9iAS Containers for J2EEスタート・ガイド
これらのステップをすべて完了すると、指定した接頭辞でタグ・ライブラリを使用できます。
たとえば、mytagprefix の URI で定義されたタグ footag を使用するには、次を指定しま
す。
<mytagprefix:footag attr1="value1" />
カスタム・タグ JAR ファイルの追加
47
リモート EJB
カスタム RMI の使用方法
JNDI プロパティ
RMI HTTP トンネリング
リモート EJB のルックアップ
カスタム RMI の使用方法
ORMI は、OC4J が使用する RMI のカスタム・ワイヤ・プロトコルです。
JNDI プロパティ
EJB を使用するアプリケーション・クライアントの JNDI プロパティに、ファクトリ、セキ
ュリティ、
および位置の設定値を指定します。
Web アプリケーションでは、
InitialContext
を使用してプロパティを取り出せます。これは、OC4J 内部では、プロパティを参照できる
ためです。外部アプリケーションでは、次の設定が必要です。
java.naming.factory.initial=
com.evermind.server.ApplicationClientInitialContextFactory
java.naming.provider.url=ormi://<hostname>/<application-name>
java.naming.security.principal=<username>
java.naming.security.credentials=<password>
RMI HTTP トンネリング
HTTP トンネリングを有効にするには、次のようにします。
1.
次の内容を global-web-application.xml に追加します。
<servlet>
<servlet-name>rmi</servlet-name>
<servlet-class>com.evermind.server.rmi.RMIHttpTunnelServlet</servletclass>
</servlet>
2.
48
RMI URL に"http:"を付加します。
Oracle9iAS Containers for J2EEスタート・ガイド
たとえば、ormi://localhost/theapp は、http:ormi://localhost/theapp となります。
リモート EJB のルックアップ
ORMI のデフォルト・ポート番号は、23791 です。jndi.properties で、URL を次のよう
に設定してください。
java.naming.provider.url=ormi://<hostname>/<application-name>
または
java.naming.provider.url=ormi://<hostname>:23791/<application-name>
リモート EJB
49
ロード・バランシングおよびクラスタリングによるパフォーマ
ンスの向上
OC4J サーバーに、ロード・バランシングおよびフォールト・トレランスを提供できます。
図 1-9 に説明するロード・バランシングは、すべてのクライアント要求を受信して、これら
の要求を既知の OC4J サーバーにリダイレクトします。ロード・バランサは、OC4J サーバー
を、着信コールを処理できるプールとして扱います。また、ロード・バランサは、セッショ
ン・コンテキストを維持するので、クライアントが再接続すると、そのリクエストは、以前
にそのクライアントを処理していた OC4J サーバーに送信されます。
図 1-9 ロード・バランシング
Oracle
HTTP
Server
Webブラウザ
ロード・
バランサ
OC4J サーバー
フォールト・トレランスは、OC4J サーバーをクラスタおよびアイランド内に存在するよう
に設定することで、提供されます。
アイランドは、2 つ以上の OC4J サーバー間で、セッション状態をレプリケートします。
OC4J サーバーの 1 つに障害が発生すると、
他の OC4J サーバーが処理を引き継ぎます。
クラスタは、アイランドの集合です。
図 1-10 は、2 つのホストにまたがる 2 つのアイランドからなる、単一のクラスタを図示した
ものです。
50
Oracle9iAS Containers for J2EEスタート・ガイド
図 1-10 アイランドのクラスタリング
ホスト
クラスタ
アイランド
ロード・バランシング
複数の OC4J インスタンスで HTTP リクエストを負荷分散する場合は、
図 1-9 のように、
Oracle
HTTP Server のバックエンドで、かつ OC4J サーバー・ファームのフロントエンドに、OC4J
ロード・バランサを構成し起動する必要があります。
高いスケーラビリティを得るために、複数の OC4J インスタンスを、単独のホストまたは複
数のホスト上の複数の JVM にレプリケートできます。インストールされた OC4J をレプリケ
ートするためには、独自のメカニズムを使用する必要があります。しかし、いったんファー
ムを設定すると、OC4J コンテナのデプロイ・ツールを使って、アプリケーションを、ファ
ーム内のすべてのマシン上に同時にデプロイし更新することができるようになります。ファ
ームの各システムでは、1 つの Oracle9i Application Server、および（J2EE コンテナのために）
複数の JVM が動作します。現行リリースでは、各サーバー上の個別の OC4J および JDK JVM
を、手動で起動する必要があります。
サーバー・ファームの構成時には、ファームのフロントエンドに、Cisco LocalDirector や BigIP
などのハードウェア・ベースのロード・バランサを使用してください。ハードウェア・ロー
ド・バランサは、ファーム内の異なる Oracle HTTP Server に HTTP リクエストを分散します。
Oracle HTTP Server と OC4J インスタンスとの間に位置するコンテナ・ロード・バランサは、
リクエストを異なる OC4J インスタンスに分散します。
セッション・ルーティング情報はコンテナ・ロード・バランサで維持されるので、デフォル
トではファーム全体でのセッション・トラッキング行われません。ファームにデプロイされ
たアプリケーションに HTTPSession オブジェクトを使用している場合は、セッションがス
ティッキーとなるように、ハードウェア・ロード・バランサを構成する必要があります。こ
れにより、同じクライアントからの接続が、ファーム内の同一のサーバーに確実にルーティ
ングされるようになります。スティッキー・セッションのタイムアウトを、HTTPSession
タイムアウトと同じ値に設定できます。
ロード・バランシングおよびクラスタリングによるパフォーマンスの向上
51
フォールト・トレランス
OC4J では、フォールト・トレランスのために、アイランドのクラスタがサポートされます。
ユーザーの特定のニーズに合わせて、クラスタリングをカスタマイズすることが可能です。
ロード・バランサが各ノードの状態をクラスタにレプリケートするので、クラスタリングに
はロード・バランサが必要です。フェイルオーバーしても、状態情報は保持されます。状態
情報は、永続ストアに保存されるのではなく、メモリーに格納されます。
OC4J では、クラスタリングを使用しない場合、RMI リクエスト/レスポンスの HTTP トンネ
リングがサポートされます。pure EJB クライアントのためのクラスタリングは、サポートさ
れていません。ただし、java.provider.url JNDI 環境プロパティで、複数のサイトを
カンマ区切りリストとして指定することにより、pure RMI/EJB クライアントのフェイルオー
バーを実現することはできます。1 つのサーバーへの接続に障害が発生した場合、クライア
ント・コンテナは、プロパティの次のサーバーに切り替えます。
注意:
注意 ロード・バランサでは、EJB ではなく Web コンポーネントのロード・バラ
ンシングが提供されます。
OC4J のフォールト・トレランスは、ステートフルおよびステートレスの両方の要求に対し
て動作します。
ステートレス・リクエスト － OC4J は、クライアントを他の作業インスタンスにリダ
イレクトします。
ステートフル・リクエスト － フェイルオーバーされたマシンで、カンバセーショナ
ル・ステートが利用可能である必要があります。カンバセーショナル・ステートは、ク
ラスタに常時伝播されます。これにより、同じアイランドの他のノードは、クライアン
トとのカンバセーションを回復できます。
クラスタリングの有効化
OC4J でクラスタリングを有効にするには、次のことを実行します。
1.
クラスタのすべてのノード上に、Web アプリケーションをインストールします。
クラスタで使用しているノードに同じ Web アプリケーションがインストールされてい
ることを、確認します。Web アプリケーションを 2 ヶ所にデプロイしたくない場合は、
両方のサーバーがアクセスできる共有ドライブにデプロイできます。クラスタのすべて
のノードを起動して、すべてのノード上で Web アプリケーションが正しく動作してい
ることをチェックしてください。
2.
52
Web アプリケーションがその状態をレプリケートするように、設定します。
Oracle9iAS Containers for J2EEスタート・ガイド
a.
orion-web.xml デプロイメント・ディスクリプタを編集します。Web サイト全体、
すなわちすべての Web アプリケーションにクラスタリングを追加したい場合は、
global-web-application.xml を編集します。
次のエントリを追加します。
<orion-web-app>
...
<cluster-config />
...
</orion-web-app>
b.
オプションで、次の項目を指定できます。
クラスタ・データを送受信するマルチキャスト・ホスト/IP アドレス（デフォ
ルトは 230.0.0.1）。
クラスタ・データを送受信するポート（デフォルトは 9127）。
クラスタ内でクラスタ・ノードを識別するための ID（数値）。デフォルトは、
ローカル・マシンの IP アドレスに基づきます。
クラスタ内のすべての OC4J サーバーに対して、このステップを繰り返します。こ
のステップにより、次の項目がレプリケートされます。
HttpSession データ（シリアライズ可能であるか、EJB 参照である場合）。
EJB が障害が発生したサーバー上にある場合は、参照が無効になることがあ
ります。
ServletContext データ。
複数のアイランドを使用する場合は、異なるマルチキャスト IP アドレスを使用して、
ネットワークにおけるマルチキャスト・パケットのスマート・ルーティングを有効にし
てください。スマート・ルーティングを使用すると、関係のないマシンに不要なパケッ
トが送信されなくなります。
たとえば、2 つのホストからなる 1 つのアイランドと、3 つのホストからなる別のアイ
ランドがある場合、異なるマルチキャスト・アドレスを構成して、各アイランドが不要
なメッセージを受信しないようにします。
3.
クラスタ・アイランドを構成します。
クラスタ・アイランドは、Web アプリケーションではなく特定のサイトに結びついてい
ます。クラスタ・アイランドを構成するには、Web アプリケーションのデプロイされる
Web サイトの*web-site.xml ファイルを編集します。<web-site>要素を変更して、クラス
タ・アイランドの数値 ID を追加します。たとえば、default-web-site.xml では、クラスタ・
アイランドは、次のように「1」として識別されます。
ロード・バランシングおよびクラスタリングによるパフォーマンスの向上
53
<web-site ... cluster-island="1" >
クラスタに 1 つ以上のアイランドが存在する場合は、異なるアイランドに属するサーバ
ーに、それぞれ異なる数値を指定します。状態はアイランド内でのみ共有されることを、
忘れないでください。
4.
各 Web サイトを構成する web-site.xml ファイルで、ロード・バランサのホストおよ
びポート番号を構成します。負荷が分散される各 OC4J ノードは、ロード・バランシン
グ・ノードに各自の位置を通知します。ホスト名は常に IP アドレスに解決されるとは
限らないので、ホスト名や localhost ではなく、IP アドレスを提供することを推奨し
ます。
各*web-site.xml の<web-site>要素の本体で、次を追加します。
<web-site ... >
...
<frontend host="balancer-host" port="balancer-port" />
...
</web-site>
次の項目を置き換えます。
balancer-host を、ロード・バランサを実行するサーバーのホスト名に置き換
えます。
balancer-port を、ロード・バランサを実行するサーバーのポートに置き換え
ます。
このホストおよびポートにより、このサイトのパブリックなホスト名が構成されます。
ポート番号にはポート 80 を推奨します。
5.
アプリケーションの/WEB-INF/web.xml ファイルで、<distributable />タグを挿
入します。
クラスタリングをテストするには、"java -jar loadbalancer.jar"を実行して、ロー
ド・バランサを起動します。次に、Web ブラウザで、ロード・バランサのホストおよびポー
トにアクセスします。異なるクライアントから同じページを何度もリクエストすると、サー
バー間で負荷が分散されます。同一のクライアントから同じページを何度も要求すると、最
初にアクセスされたサーバーが処理を行います。ロード・バランサの動作内容を表示するに
は、デバッグ・オプション -Dhttp.cluster.debug および-Dcluster.debug を true に
設定して、OC4J インスタンスを起動します。
状態のレプリケーションをテストするには、/servlet/SessionServlet にアクセスしま
す。最初のリクエストの後で、どのサーバーがこのセッションのプライマリ・サーバーにな
っているかを、チェックしてください。プライマリ・サーバーを停止して、再度リクエスト
を行ってください。異なるノードで、以前と同じセッションを受信するはずです。さらに、
カウンタも正しく更新されているはずです。
54
Oracle9iAS Containers for J2EEスタート・ガイド
ロード・バランサのデフォルト動作
デフォルトでは、ロード・バランサの動作は次のようになります。
1.
これまでサイトに接続しておらず、関連付けられたセッションもない IP アドレスから
新規のリクエストが行われると、リクエストはランダムにバックエンド・ホストに送信
されます。
クラスタ内の複数のアイランドが同じサイトを処理できる場合、1 つのアイランドがラ
ンダムに選択されます。その後、選択されたアイランド内のノードがランダムに選択さ
れ、この選択されたノードのアイランド内ですべての状態が共有されます。
2.
Web サイトにすでに接続し、カンバセーショナル・ステートが存在する IP アドレスか
らリクエストが行われると、リクエストは以前のリクエストと同じサーバーに送信され
ます。リクエストが IP アドレスに基づいてルーティングされないように指定しない限
り、こうなります。IP アドレスに基づいてルーティングされないように指定するには、
-dontUseIP コマンドライン・オプションを指定するか、または load-balancer.xml
の-ip="false"を使用します。
デフォルトでは、ロード・バランシングはクライアント・ベースであり、リクエスト・
ベースではありません。統計的に、ロード・バランシングは、同数のクライアントをア
イランド内の各ノードに転送することが期待されています。
3.
キープ・アライブ・ソケット内でリクエストが行われると、リクエストは以前のリクエ
ストと同じサーバーに送信されます。-dontUseKeepalives コマンドライン・オプシ
ョン、または load-balancer.xml の keepalives="false"によって、キープ・ア
ライブを使用しないことを指定しない限り、こうなります。
4.
セッションを持つユーザーからリクエストが行われ、そのセッションのプライマリ・サ
ーバーが応答しない場合は、リクエストは同じアイランドの他のサーバーに送信されま
す。状態がレプリケートされているので、他のサーバーにも同じユーザー状態が存在し
ます。
5.
適切なサーバーへのリクエストが失敗すると、リクエストは他のサーバーに送信されま
す。
6.
クラスタリングでは、マルチキャスト機能が必要です。ロード・バランサでは、（すべ
てのクラスタリング・サービスと同様に）マルチキャストが動作する必要があります。
マルチキャストの動作を確認するには、最初に-debug スイッチでロード・バランサを
起動して、マルチキャスト・ソケットでメッセージを正しく受信することを確認します。
-debug を使用すると、進捗状況に関する追加情報が表示されます。
複数のアイランドを使用する場合は、異なるマルチキャスト IP アドレスを使用してネ
ットワークにおけるマルチキャスト・パケットのスマート・ルーティングを有効にして
ください。
ロード・バランシングおよびクラスタリングによるパフォーマンスの向上
55
マルチキャスト・グループおよびアドレス
すべての IP マルチキャスト・グループには、グループ・アドレスがあります。IP マルチキ
ャストでは、オープン・グループだけが提供されます。つまり、グループにデータグラムを
送信するために、グループのメンバーである必要はないということです。
マルチキャスト・アドレスは、単一のホストに使用される IP アドレスと類似しており、
A.B.C.D のように記述されます。IP アドレス空間の一部がマルチキャスト用に予約されてい
るため、マルチキャスト・アドレスはホスト・アドレスと衝突することはありません。アド
レスの予約範囲は、224.0.0.0 から 239.255.255.255 です。ただし、224.0.0.0 から 224.0.0.255
までのマルチキャスト・アドレスは、マルチキャスト・ルーティング情報用に予約されてい
ます。アプリケーション・プログラムでは、この範囲外のマルチキャスト・アドレスを使用
してください。
OC4J インスタンスを実行する個別のシステムとロード・バランサを実行するシステムとの
間のいずれかのルーターが、IP マルチキャスト対応ではない場合は、ロード・バランサはイ
ンスタンスを検出しません。多数の ISP のルーターは、マルチキャスト対応ではないことに
注意してください。
ヒント
56
1.
複数のアイランドを使用する場合は、異なるマルチキャスト IP アドレスを使用して、
ネットワークにおけるマルチキャスト・パケットのスマート・ルーティングを有効にし、
特定の IP 上のトラフィックを特定のサーバーに送信するようにしてください。
2.
通常、各サイトは、1 つのアイランドによって処理されます。負荷の高いサイトは、複
数のアイランドによって処理される場合があります。状態は、アイランド内でのみレプ
リケートされます。必要なフォールト・トレランスの程度が、アイランドのサイズを決
定します。サイトの負荷が 1 つのアイランドに対して大きすぎる場合は、アプリケーシ
ョンを他のアイランドに複製します。これによって、不要な状態レプリケーションが未
然に防がれ、最適なスケーラビリティが提供されます。
3.
リクエスト・ベースのロード・バランシングを行うには、-dontUseIP スイッチを使
用します。デフォルトでは、（フェイルオーバー時を除いて）いったんセッションがノ
ードにバインドされると、同じノードへ転送し続けます。デフォルトは、（リクエスト・
ベースではなく）クライアント・ベースのロード・バランシングです。
4.
selectionType を"first"に設定すると、アイランド全体は、（ロード・バランシ
ング・サービスは提供せず）フェイルオーバー・サービスのみを提供します。これは、
1 つのサーバーのみに負荷を集中したい場合に便利です。サーバーに障害が発生した場
合、すべてのリクエストは、次のサーバーにフェイルオーバーします。
Oracle9iAS Containers for J2EEスタート・ガイド
共通の問題
1.
負荷分散された<distributable>（分散可能な）JSP から参照されるすべてのクラス
は、シリアライズ可能である必要があります。そうでない場合は、
IllegalStateException が送出されます。
2.
マルチキャスト・ホストは、224.0.0.0 から 239.255.255.255 の範囲内に存在する必要が
あります。これらアドレスの一部は、よく知られている組織によって使用されています。
3.
マルチキャストは、ISP でインターネットに接続しているコンピュータでは動作しない
場合があります。
ロード・バランシングおよびクラスタリングによるパフォーマンスの向上
57
例
次の例では、OC4J 内で J2EE アプリケーションを構成しデプロイする方法を示します。
J2EE アプリケーションの XML 構成例
J2EE EJB、Web、およびクライアントの例
J2EE アプリケーションの XML 構成例
この例では、myapp アプリケーションには、Java クライアント、JAR ファイルにアセンブル
された EJB、WAR ファイルにアセンブルされた Servlet および JSP、EJB JAR ファイルおよ
び Web アプリケーション WAR ファイルの両方を含む EAR ファイルが含まれています。
XML
構成ファイル、Java クラス・ファイル、および JSP ファイルすべての場所を示すツリー構造
が、図 1-11 に示されています。すべての構成ファイルを、アプリケーション・ディレクトリ
内の論理ディレクトリに分離することができることに、注意してください。
図 1-11 アプリケーション EAR の構造
myapp.EAR
|-------META-INF
|
`-------application.xml
|
|-------myapp-client.JAR
|
|-------META-INF
|
|
|-------application-client.xml
|
|
`-------orion-application-client.xml
|
`-------TemplateClient.class
|-------myapp-ejb.JAR
|
|-------META-INF
|
|
`-------ejb-jar.xml
|
|-------Template.class
|
|-------TemplateBean.class
|
`-------TemplateHome.class
`-------myapp-web. WAR
|-------WEB-INF
|
|-------web.xml
|
`-------classes
|
`-------TemplateServlet.class
|-------add.jsp
|-------delete.jsp
|-------edit.jsp
|-------index.html
|-------list.jsp
`-------serv.jsp
58
Oracle9iAS Containers for J2EEスタート・ガイド
application.xml の例 myapp/META-INF/application.xml ファイルは、EAR ファイル
に含まれる EJB JAR および Web アプリケーション WAR ファイルを、<module>要素内でリ
ストします。
<?xml version="1.0"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE
Application
1.2//EN" "http://java.sun.com/j2ee/dtds/application_1_2.dtd">
<application>
<display-name>myapp j2ee application</display-name>
<description>
A sample J2EE application that uses a Container Managed
Entity Bean and JSPs for a client.
</description>
<module>
<ejb>myapp-ejb.jar</ejb>
</module>
<module>
<web>
<web-uri>myapp-web.war</web-uri>
<context-root>/myapp</context-root>
</web>
</module>
</application>
web.xml の例 ファイル myapp/web/META-INF/web.xml には、Web サイト内で実行され
る EJB、Servlet、および JSP のクラス定義が含まれています。これらは、次のようになりま
す。
<?xml version="1.0"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
<web-app>
<display-name>myapp web application</display-name>
<description>
Web module that contains an HTML welcome page, and 4 JSP’s.
</description>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
</welcome-file-list>
<ejb-ref>
<ejb-ref-name>myapp/ejb/TemplateBean</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>myapp.ejb.TemplateHome</home>
<remote>myapp.ejb.Template</remote>
</ejb-ref>
<servlet>
例
59
<servlet-name>template</servlet-name>
<servlet-class>myapp.web.TemplateServlet</servlet-class>
<init-param>
<param-name>param1</param-name>
<param-value>1</param-value>
</init-param>
</servlet>
</web-app>
ejb-jar.xml の例 ファイル myapp/ejb/META-INF/ejb-jar.xml には CMP（コンテナ管
理の永続性） EJB の定義が含まれており、以下と類似しています。
<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans
1.1//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd">
<ejb-jar>
<display-name>myapp</display-name>
<description>
An EJB app containing only one Container Managed Persistence Entity
Bean
</description>
<enterprise-beans>
<entity>
<description>
template bean populates a generic template table.
</description>
<display-name>TemplateBean</display-name>
<ejb-name>TemplateBean</ejb-name>
<home>myapp.ejb.TemplateHome</home>
<remote>myapp.ejb.Template</remote>
<ejb-class>myapp.ejb.TemplateBean</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>java.lang.Integer</prim-key-class>
<reentrant>False</reentrant>
<cmp-field><field-name>col_1</field-name></cmp-field>
<cmp-field><field-name>col_2</field-name></cmp-field>
<cmp-field><field-name>col_3</field-name></cmp-field>
<primkey-field>col_1</primkey-field>
</entity>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>TemplateBean</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>NotSupported</trans-attribute>
60
Oracle9iAS Containers for J2EEスタート・ガイド
</container-transaction>
<security-role>
<description>Users</description>
<role-name>users</role-name>
</security-role>
</assembly-descriptor>
</ejb-jar>
server.xml への追加 管理コンソールを使ってアプリケーションをデプロイすると、コンソ
ールはアプリケーション EAR ファイルの場所を server.xml ファイルに追加します。これ
によって、OC4J が再起動されるたびにアプリケーションが再起動されます。OC4J 再起動時
にアプリケーションを起動したくない場合は、auto-start 変数を FALSE に変更してくだ
さい。
注意:
注意 auto-start 変数を FALSE に設定すると、管理コンソールで、アプリケー
ションを手動起動するか、あるいは Web ブラウザがアプリケーションにリクエスト
したときに、自動起動できます。
<application name="myapp" path="../myapp/lib/myapp.ear" auto-start="true" />
ここで
name 変数は、アプリケーション名です。
path 変数は、EAR ファイルのディレクトリおよびファイル名を示します。
auto-start 変数は、OC4J を再起動するたびにこのアプリケーションが自動的に再起
動されるかどうかを示します。
default-web-site.xml への追加 WAR ファイル名を指定して、（WAR ファイルでデプロイ
された）Web アプリケーションのルート・コンテキストを定義する必要があります。
default-web-site.xml を編集して、以下の記述を追加してください。
<web-app application="myapp" name="myapp-web" root="/myapp" />
name 変数は、（.war 拡張子を除いた）WAR ファイル名です。
root 変数は、
Web サイトでのアプリケーションのルート・コンテキストを定義します。
たとえば、"http://localhost:8888"として Web サイトを定義している場合、アプ
リケーションを開始するにはブラウザを"http://localhost:8888/myapp"にポイ
ントします。
クライアントの例
クライアントの XML 構成は、2 つのファイル application-client.xml および
orion-application-client.xml に含まれています。
例
61
application-client.xml ファイルには、次のように EJB への参照が含まれています。
<?xml version="1.0"?>
<!DOCTYPE application-client PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE
Application Client 1.2//EN"
"http://java.sun.com/j2ee/dtds/application-client_1_
2.dtd">
<application-client>
<display-name>TemplateBean</display-name>
<ejb-ref>
<ejb-ref-name>TemplateBean</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>myapp.ejb.TemplateHome</home>
<remote>myapp.ejb.Template</remote>
</ejb-ref>
</application-client>
orion-application-client.xml ファイルは、EJB 参照の論理名を EJB の JNDI 名にマ
ッピングします。たとえば、次のように、このファイルは application-client.xml で
定義された<ejb-ref-name>要素である"TemplateBean"を JNDI 名
"myapp/ejb/TemplateBean"にマップします。
<?xml version="1.0"?>
<!DOCTYPE orion-application-client PUBLIC "-//Evermind//DTD J2EE
Application-client runtime 1.2//EN"
"http://xmlns.oracle.com/ias/dtds/orion-application-client.dtd">
<orion-application-client>
<ejb-ref-mapping name="TemplateBean"
location="myapp/ejb/TemplateBean" />
</orion-application-client>
J2EE EJB、
、Web、およびクライアントの例
、およびクライアントの例
J2EE アプリケーションの開発後、J2EE アプリケーションの異なるモジュール（EJB、Web、
およびクライアント）を EAR ファイルにアセンブルします。この項では、EJB、Web、およ
びクライアントを持つ J2EE アプリケーションの例を示します。
次のディスクリプタ META-INF/application.xml は、WAR、EJB JAR、およびクライア
ント JAR ファイルが、J2EE アプリケーションにどのように含まれているかを示したもので
す。
<?xml version="1.0"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application
1.2//EN" "http://java.sun.com/j2ee/dtds/application_1_2.dtd">
<application>
62
Oracle9iAS Containers for J2EEスタート・ガイド
<display-name>myapp j2ee application</display-name>
<description>
A sample J2EE application that uses a Container Managed
Entity Bean and JSP's for a client.
</description>
<module>
<ejb>myapp-ejb.jar</ejb>
</module>
<module>
<web>
<web-uri>myapp-web.war</web-uri>
<context-root>/myapp</context-root>
</web>
</module>
<module>
<java>myapp-client.jar</java>
</module>
</application>
管理コンソール admin.jar を使用してクライアントからこのアプリケーションをデプロイ
するには、myapp ディレクトリで次を実行します。-file オプションで EAR ファイルを定
義し、-targetPath オプションで EAR ファイルをコピーするターゲット・パスを定義する
ことに、注意してください。EAR が存在するパスとターゲット・パスが同一なので、コピー
は発生しません。
% java -jar $J2EE_HOME/admin.jar ormi://localhost admin welcome
-deploy -file ./lib/myapp.ear -deploymentName myapp -targetPath ./lib
Auto-deploying myapp (New server version detected)...
Auto-deploying myapp-ejb.jar (ejb-jar.xml had been touched since the previous
deployment)... done.
Auto-deploying myapp web application (New server version detected)...
注意:
注意 EJB JAR ファイルは、即座に解凍されます。WAR ファイルは、Web サーバ
ーで/myapp がアクセスされたときに解凍されます。
server.xml に、以下のエントリが追加されます。
<application name="myapp"
path="/private/myapp/lib/myapp.ear" auto-start="true" />
ここで、
name 変数は、アプリケーション名です。
path 変数は、EAR ファイルの絶対ディレクトリ名およびファイル名を示します。
auto-start 変数は、OC4J が再起動されるたびに、このアプリケーションが自動的に
再起動されるかどうかを示します。
例
63
これらの追加により、（デフォルトでは）OC4J コンテナとともにアプリケーションが自動
的に起動され、myapp.ear 内のコンポーネントが更新されるたびにホット・デプロイが有
効にになります。ただし、auto-start を FALSE に設定してある場合は、アプリケーショ
ンは、使用された時に起動されるか、または手動で起動されます。次のコマンドは、myapp
アプリケーションの手動起動を示したものです。
% java -jar admin.jar ormi://localhost admin welcome -application myapp
-restart
CMP（コンテナ管理の永続性）
（コンテナ管理の永続性） EJB モジュール
ホーム・インタフェース、リモート・インタフェース、Bean クラス、および XML ディスク
リプタ（META-INF/ejb-jar.xml）で、CMP EJB モジュールを EJB JAR ファイルにパッ
ケージしてください。XML ディスクリプタは、
http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd の標準 DTD に準拠している必
要があります。
myapp EJB デプロイメント・ディスクリプタには、以下の指定が含まれています。
Entity Bean は、CMP（コンテナ管理の永続性）を使用します。
主キーは、表に格納されます。このディスクプリタによって、主キーの型とフィールド
が定義されます。
永続表が既に存在するか、あるいは application.xml で autocreate-tables が
FALSE に設定されていない限り、永続表は自動作成されます。
表名には Bean の名前が使用され、列名は ejb-jar.xml ディスクリプタのフィールド
に従って命名され、タイプ・マッピングは，
config/database-schemas/oracle.xml に従います。
Bean は、data-souce.xml で ejb-location として指定されているデータ・ソース、または
application.xml の default-data-source によって指定されているデータ・ソースを使い、
JDBC を使用してデータベースにアクセスします。
たとえば、myapp アプリケーションの ejb-jar.xml は次のようになります。
<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans 1.
1//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd">
<ejb-jar>
<display-name>myapp</display-name>
<description>
An EJB app containing only one Container Managed Persistence Entity
Bean
</description>
<enterprise-beans>
64
Oracle9iAS Containers for J2EEスタート・ガイド
<entity>
<description>
template bean populates a generic template table.
</description>
<display-name>TemplateBean</display-name>
<ejb-name>TemplateBean</ejb-name>
<home>myapp.ejb.TemplateHome</home>
<remote>myapp.ejb.Template</remote>
<ejb-class>myapp.ejb.TemplateBean</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>java.lang.Integer</prim-key-class>
<reentrant>False</reentrant>
<cmp-field><field-name>col_1</field-name></cmp-field>
<cmp-field><field-name>col_2</field-name></cmp-field>
<cmp-field><field-name>col_3</field-name></cmp-field>
<primkey-field>col_1</primkey-field>
</entity>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>TemplateBean</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>NotSupported</trans-attribute>
</container-transaction>
<security-role>
<description>Users</description>
<role-name>users</role-name>
</security-role>
</assembly-descriptor>
</ejb-jar>
EJB モジュールは、J2EE アプリケーション EAR ファイルの一部としてデプロイされます。
% java -jar admin.jar ormi://localhost admin welcome -deploy
-file ./lib/myapp.ear -deploymentName myapp
-targetPath ./lib
Auto-deploying myapp (New server version detected)...
Auto-creating table: create table TemplateBean (col_1 NUMBER not null primary
key, col_2 VARCHAR2(255) null, col_3 FLOAT null)
Auto-deploying myapp-ejb.jar (Class 'myapp.ejb.Template' had been
updated)...
done.
データ・ソースをインストールするには、データ・ソース接続ドライバ
（connection-driver 変数で指定する JDBC ドライバ）を含む JDBC JAR ファイルを、
例
65
$J2EE_HOME/lib にコピーします。次のように、data-sources.xml を変更してくださ
い。
<?xml version="1.0"?>
<!DOCTYPE data-sources PUBLIC "data source configuration"
"http://xmlns.oracle.com/ias/dtds/data-sources.dtd">
<data-sources>
<data-source
name="Oracle"
class="com.evermind.sql.DriverManagerDataSource"
location="oracle/jdbc/default/MySidDS"
pooled-location="oracle/jdbc/pool/MySidDS"
ejb-location="oracle/jdbc/container/MySidDS"
xa-location="oracle/jdbc/xa/MySidXADS"
connection-driver="oracle.jdbc.driver.OracleDriver"
url="jdbc:oracle:thin:@localhost:<port>:<mysid>"
username="scott"
password="tiger"
max-connections="300"
min-connections="5"
max-connect-attempts="10"
connection-retry-interval="1"
inactivity-timeout="30"
wait-timeout="30"
/>
</data-sources>
Web モジュール － EJB をコールする Servlet および JSP
HTML ページ、JSP、および Servlet を含む Web モジュールを、ディスクリプタ
WEB-INF/web.xml と共に、WAR ファイルにパッケージします。このファイルは、
http://java.sun.com/j2ee/dtds/web-app_2_2.dtd の標準 DTD に準拠している必
要があります。
myapp Web モジュールは、ディスクリプタで次のことを指定します。
（bind コマンドで指定する）Web サイトの位置およびルート・コンテキスト（Web サ
ーバー＋/myapp）で表示されるデフォルト・ページ
EJB ホームおよびリモート・インタフェースのスタブを検索する位置
EJB の JNDI 名
含まれる Servlet、および各 Servlet クラスの検索位置
<servlet-mapping>要素（/template）を使用した、Web サイトの位置およびルー
ト・コンテキスト（Web サーバー＋/myapp）以下のサブ・コンテキストへの、Servlet
のマッピング方法
Web サーバーは、次の項目を検索します。
WEB-INF/classes/<package>/<class>以下にある、すべての Servlet クラス。
66
Oracle9iAS Containers for J2EEスタート・ガイド
web-site.xml の<web-app name="<warfile>">によってポイントされる WAR フ
ァイルのルートにある、すべての HTML および JSP。WAR ファイルは、デプロイされ
た対応するアプリケーション EAR ファイル内にパッケージされています。
OC4J は、最初に各 JSP を.jsp から.class にコンパイルして、その後の使用のために
キャッシュします。
J2EE アプリケーション（EAR ファイル）の Web コンポーネント（WAR ファイル）を、Web
サイトにバインドするには、次のようにしてください。
% java -jar admin.jar ormi://localhost admin welcome
-bindWebApp myapp myapp-web default-web-site /myapp
これによって、default-web-site.xml に次が追加されます。
<web-app application="myapp" name="myapp-web" root="/myapp" />
myapp web.xml ディスクリプタは、次のとおりです。
<?xml version="1.0"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
<web-app>
<display-name>myapp web application</display-name>
<description>
Web module that contains an HTML welcome page, Servlet and JSP's.
</description>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
</welcome-file-list>
<ejb-ref>
<ejb-ref-name>myapp/ejb/TemplateBean</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>myapp.ejb.TemplateHome</home>
<remote>myapp.ejb.Template</remote>
</ejb-ref>
<servlet>
<servlet-name>template</servlet-name>
<servlet-class>myapp.web.TemplateServlet</servlet-class>
<init-param>
<param-name>param1</param-name>
<param-value>1</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>template</servlet-name>
<url-pattern>/template</url-pattern>
</servlet-mapping>
</web-app>
例
67
クライアント・モジュール
モジュール － EJB を起動するスタンドアロ
を起動するスタンドアロン
スタンドアロン Java クライア
ント
JAR のクライアント・モジュールを、
http://java.sun.com/j2ee/dtds/application-client_1_2.dtd の標準 DTD に
準拠するディスクリプタ META-INF/application.client.xml とともに、パッケージし
ます。
アプリケーション・クライアントの例 myapp アプリケーションにアクセスするアプ
リケーション・クライアントには、ディスクリプタがあります。このディスクリプタには、
EJB スタブ（ホームおよびリモート・インタフェース）の検索位置、およびその JNDI 名を
記述します。
<?xml version="1.0"?>
<!DOCTYPE application-client PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE
Application Client 1.2//EN"
"http://java.sun.com/j2ee/dtds/application-client_1_
2.dtd">
<application-client>
<display-name>TemplateClient</display-name>
<ejb-ref>
<ejb-ref-name>myapp/ejb/TemplateBean</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>myapp.ejb.TemplateHome</home>
<remote>myapp.ejb.Template</remote>
</ejb-ref>
</application-client>
クライアントのための JNDI プロパティ 通常のクライアントのために、JNDI プロパ
ティを設定して、初期 JNDI コンテキスト・ファクトリを検索できるようにします。
1.
hashtable 内で、JNDI プロパティを設定します。
2.
プロパティを、javax.naming.InitialContext または jndi.properties ファイ
ルに渡します。
3.
jndi.properties ファイルに渡した場合は、プロパティ・ファイルを
myapp-client.jar にをパッケージして、それが CLASSPATH 内にあることを確認し
ます。
jndi.properties:
--------------java.naming.factory.initial=com.evermind.server.ApplicationClientIn
itialContextFactory
java.naming.provider.url=ormi://localhost/myapp
java.naming.security.principal=admin
java.naming.security.credentials=welcome
68
Oracle9iAS Containers for J2EEスタート・ガイド
クライアントのマニフェスト・ファイル
クライアントのマニフェスト・ファイル 次に示すように、実行するメイン・クラス
および必要な CLASSPATH を持つマニフェストとともに、クライアントを実行可能 JAR フ
ァイルにパッケージします。このファイル内の相対パスを、慎重にチェックしてください。
manifest.mf
----------Manifest-Version: 1.0
Main-Class: myapp.client.TemplateClient
Name: "TemplateClient"
Created-By: 1.2 (Sun Microsystems Inc.)
Implementation-Vendor: "Oracle"
Class-Path: ../../../j2ee/home/orion.jar ../../../j2ee/home/jndi.jar
../../../j2ee/home/ejb.jar ../lib/myapp-ejb.jar
クライアントの実行 クライアントを実行するには、以下を実行します。
% java -jar lib/myapp-client.jar
TemplateClient.main(): start
Enter integer value for col_1: 1
Enter string value for col_2: BuyME
Enter float value for col_3: 99.9
Record added through bean
例
69
XML ファイル・リファレンス
次の項では、各 XML ファイルとその内容を簡単に説明します。
OC4J サーバー構成ファイル
J2EE アプリケーション構成
OC4J サーバー構成ファイル
server.xml
web-site.xml
principals.xml
data-sources.xml
jms.xml
rmi.xml
load-balancer.xml
server.xml server.xml ファイルには、アプリケーション・サーバーの構成が含まれてい
ます。ここで次の項目を指定します。
ライブラリ・パス
グローバル・アプリケーション、グローバル Web アプリケーション、およびデフォル
ト Web サイト
サーバーの最大 HTTP 接続数
ロギングの設定
Java コンパイラの設定
クラスタ ID
トランザクション・タイムアウト
SMTP ホスト
server.xml ファイルには、他の構成ファイルへの参照も含まれています。
特に、server.xml では次の項目を指定します。
data-sources.xml 構成が位置する場所
JMS および RMI の構成が位置する場所
70
Oracle9iAS Containers for J2EEスタート・ガイド
デフォルトおよび追加 Web サイトの位置。Web サイトの構成ファイル位置をリストす
るエントリの追加にすることによって、複数の Web サイトを持つことができます。
-default-web-site.xml は、デフォルト Web サイトを定義します。したがって、こ
れはただ 1 つだけ存在します。他の Web サイトはすべて web-site.xml 構成ファイル
で定義されます。次のように、server.xml 内で、各 Web サイトを登録します。
<web-site path="./default-web-site.xml" />
<web-site path="./another-web-site.xml" />
注意:
注意
指定されるパスは、config/ディレクトリの相対パスです。
最後に、server.xml ファイルでは、各自のアプリケーションを追加します。必要なだけの
アプリケーション・ディレクトリを持つことができ、このディレクトリは、コンテナ・イン
ストール・ディレクトリ以下にする必要はありません。
この DTD は、以下のサイトにあります。
http://xmlns.oracle.com/ias/dtds/server.dtd
web-site.xml web-site.xml ファイルには、Web サイトの構成が含まれています。次の
項目を指定してください。
ホスト名または IP アドレス、このサイトの仮想ホスト設定、リスナー・ポート
このサイトのデフォルト Web アプリケーション
このサイトの追加 Web アプリケーション
アクセス・ログ・フォーマット
ユーザーWeb アプリケーションの設定（/~user/サイト）
SSL 構成
この DTD は、以下のサイトにあります。
http://xmlns.oracle.com/ias/dtds/web-site.dtd
principals.xml principals.xml ファイルには、OC4J サーバーのセキュリティ情報が含まれて
います。デフォルトの XMLUserManager が使用する、ユーザーおよびグループ構成が定義さ
れます。
管理コンソールのユーザー名およびパスワード
ユーザー/グループの名前および説明、ユーザーの実名およびパスワード
オプションで、ユーザーの X.509 証明書
この DTD は、以下のサイトにあります。
XML ファイル・リファレンス
71
http://xmlns.oracle.com/ias/dtds/principals.dtd
data-sources.xml data-sources.xml ファイルには、使用されるデータ・ソースの構成
が含まれています。さらに、JDBC 接続の取得方法に関する情報も含まれています。データ・
ソースには、次の設定があります。
JDBC ドライバ
JDBC URL
このデータ・ソースをバインドする JNDI パス
使用するデータベースのユーザー/パスワード
使用するデータベース・スキーマ（下記の「注意」参照）
非活動時のタイムアウト
データベースの最大接続数
注意:
注意 データベース・スキーマは、自動生成される SQL を異なるデータベース・
システムで動作させるために使用します。OC4J には、タイプ・マッピングや予約
語などのプロパティを指定する XML ファイル・フォーマットが含まれています。
OC4J には、MS SQLServer、MS Access、Oracle、および Sybase のデータベース・ス
キーマが備えられています。これらを編集して、ご使用の DBMS の新規スキーマに
することができます。
この DTD は、以下のサイトにあります。
http://xmlns.oracle.com/ias/dtds/data-source.dtd
jms.xml jms.xml ファイルには、メモリー内 Java Message Service の構成が含まれていま
す。次の項目が含まれています。
JMS サーバーがバインドされる、ホスト名または IP アドレス、およびポート番号
JNDI ツリーにバインドされるキューおよびトピックの仕様
ログの設定
この DTD は、以下のサイトにあります。
http://xmlns.oracle.com/ias/dtds/jms.dtd
rmi.xml rmi.xml ファイルには、RMI（Remote Method Invocation）システムの構成が含ま
れています。
EJB へのリモート・アクセスを提供する RMI リスナーの設定が含まれています。
このファイルでは、以下の項目を指定します。
RMI サーバーがバインドされる、ホスト名または IP アドレス、およびポート番号
72
Oracle9iAS Containers for J2EEスタート・ガイド
通信するリモート・サーバー
クラスタリングの設定
ログの設定
この DTD は、以下のサイトにあります。
http://xmlns.oracle.com/ias/dtds/rmi.dtd
load-balancer.xml ロード・バランサは、クラスタに登録されている OC4J インスタンスへ、
リクエストをルーティングします。load-balancer.xml ファイルを使用して、クラスタ
リングのドキュメントに説明されているコマンド・オプションを使用せずに、ロード・バラ
ンサを構成することができます。詳細は、50ページの「ロード・バランシングおよびクラス
タリングによるパフォーマンスの向上」を参照してください。
この DTD は、以下のサイトにあります。
http://xmlns.oracle.com/ias/dtds/load-balancer.dtd
J2EE アプリケーションの構成
すべての J2EE アプリケーションは、J2EE 固有および製品固有の XML ファイルを使用しま
す。これらのファイルについて、説明します。
汎用 J2EE アプリケーションおよびコンポーネント構成 J2EE 構成ファイルは、すべての
J2EE サーバーにわたって使用される標準構成ファイルです。次の XML ファイルの構成方法
に関する情報は、J2EE 仕様を参照してください。
アプリケーション XML（application.xml） J2EE アプリケーション内に含まれる
Web または EJB アプリケーションを識別します。また、セキュリティ XML 定義ファイ
ル principals.xml の場所も識別します。
この DTD は、以下のサイトにあります。
http://xmlns.oracle.com/ias/dtds/application.dtd
EJB-JAR XML（ejb-jar.xml）
ロパティを定義します。
この JAR ファイル内の EJB に対するデプロイ・プ
この DTD は、以下のサイトにあります。
http://xmlns.oracle.com/ias/dtds/ejb-jar.dtd
Web アプリケーション XML（web.xml） このアプリケーション内の Servlet および
JSP に関するデプロイ情報が含まれています。
この DTD は、以下のサイトにあります。
http://xmlns.oracle.com/ias/dtds/web.dtd
XML ファイル・リファレンス
73
アプリケーション・クライアント XML（application-client.xml） サーバー・
アプリケーションにアクセスするための JNDI 情報、および他のクライアント情報が含
まれています。
DTD は以下のサイトにあります。
http://xmlns.oracle.com/ias/dtds/applicatiin-client.dtd
OC4J アプリケーションおよびコンポーネント構成 OC4J 固有のデプロイメント XML ファ
イルには、異なるコンポーネントのデプロイ情報が含まれています。OC4J 固有ファイルを
作成しない場合は、オート・デプロイ時に自動生成されます。これらのファイルは、手動で
編集可能です。OC4J 固有のデプロイメント・ファイルは、開発者が環境エントリ、リソー
ス参照、およびセキュリティ・ロールを、実際のデプロイ固有の値にマッピングするために
使用します。
OC4J アプリケーション・デプロイ（orion-application.xml）
OC4J EJB デプロイ（orion-ejb-jar.xml）
OC4J Web アプリケーション・デプロイ（orion-web.xml）
OC4J アプリケーション・クライアント・デプロイ
（orion-application-client.xml）
OC4J アプリケーション・デプロイ（orion-application.xml）
アプリケーション・デプロイ（
）
アプリケーション全体の構成です。次の設定が含まれています。
CMP Bean の表を自動生成および自動削除するかどうか
CMP Bean で使用するデフォルト・データ・ソース
セキュリティ・ロールのマッピング
ユーザー・マネージャの指定
JNDI ネームスペース・アクセス規則（認可）
この DTD は、以下のサイトにあります。
http://xmlns.oracle.com/ias/dtds/orion-application.dtd
OC4J EJB デプロイ（orion-ejb-jar.xml）
）
デプロイ（
EJB に対する OC4J 固有のデプロイメント・ディスクリプタです。次の設定が含まれていま
す。
タイムアウト設定
74
Oracle9iAS Containers for J2EEスタート・ガイド
トランザクション再試行設定
セッション持続設定
トランザクション分離設定
CMP マッピング
OR マッピング
ファインダ・メソッド指定
JNDI マッピング
この DTD は、以下のサイトにあります。
http://xmlns.oracle.com/ias/dtds/orion-ejb-jar.dtd
OC4J Web アプリケーション・デプロイ（orion-web.xml）
）
アプリケーション・デプロイ（
Web 設定をマッピングする、OC4J 固有のデプロイメント・ディスクリプタです。この XMI
ファイルには、次の項目が含まれています。
オート・リロード（変更チェック時間間隔を含む）
バッファリング
キャラクタ・セット
開発モード
ディレクトリ・ブラウジング
ドキュメント・ルート
ロケール
Web タイムアウト
仮想ディレクトリ
クラスタリング
セッション・トラッキング
JNDI マッピング
この DTD は、以下のサイトにあります。
http://xmlns.oracle.com/ias/dtds/orion-web.dtd
XML ファイル・リファレンス
75
OC4J アプリケーション・クライアント・デプロイ
（orion-application-client.xml）
）
この OC4J 固有デプロイメント・ファイルは、クライアント・アプリケーション用です。JNDI
マッピングおよびクライアントのエントリが含まれています。この DTD は、以下のサイトに
あります。
http://xmlns.oracle.com/ias/dtds/orion-application-client.dtd
76
Oracle9iAS Containers for J2EEスタート・ガイド
FAQ および既知の障害
OC4J 上での Javasoft 標準 JSP パッケージの使用
Servlet および JSP の開発
ネームスペース定義をデプロイする際のエラー
既知の制限
JNDI プロパティ
OC4J 上での Javasoft 標準 JSP パッケージの使用
OC4J が配布する javax.servlet.jsp.*パッケージは、Javasoft の標準パッケージではあ
りません。Javasoft の標準パッケージに置き換えて使用すると、これらのパッケージによっ
て OC4J JSP がタグ追加領域で不正な動作をします。
Servlet および JSP の開発
OC4J には、Servlet および JSP を開発モードにする機能が含まれています。たとえば、
global-web-application.xml ファイルで"development=true"を設定すると、OC4J
は Servlet ソース（.java ファイル）が変更されると同時に Servlet クラスを自動的にコンパ
イルします。Servlet は、Web ブラウザによってアクセスされるとコンパイルおよび実行され
ます。これは、「開発モード」での実行として知られています。開発サイクルが終了したら、
このフラグをオフにしてください。
ネームスペース定義をデプロイする際のエラー
orion-application.xml では、<namespace-access>要素は JNDI ネームスペースの異
なる側面を定義します。ただし、アプリケーションで orion-application.xml を定義し
て admin.jar によってデプロイすると、この要素は初期化されず、<namespace-access>の
デフォルト値が使用されます。
対処法ははっきりしていません。<namespace-access>定義を正しく初期化するには、次
のことを行ってください。
1.
アプリケーション EAR ファイルを admin.jar によってデプロイします。
2.
application-deployments ディレクトリからデプロイされたアプリケーション・フ
ァイルを消去すると、アプリケーションがホット・デプロイされます。
FAQ および既知の障害
77
この作業は、アプリケーションで最初に行うだけです。その後は、<namespace-access>
要素が正しく読み込まれます。
既知の制限
OC4J JTA では、2 フェーズ・コミットが提供されません。さらに、OC4J は、現在 Oracle AQ
をサポートしていません。
JNDI プロパティ
アプリケーションに jndi.properties ファイルを含める場合、このファイルは Web アプ
リケーションではなく Java クラスにのみ使用されます。
Web アプリケーションでは、
hashtable
内でプロパティを設定し、javax.naming.InitialContext に渡すことができます。ク
ライアントがコンテナ外部から OC4J JNDI にアクセスする場合は、これら 2 つの方法のいず
れかでプロパティを定義する必要があります。
78
Oracle9iAS Containers for J2EEスタート・ガイド