| Oracle® Fusion Middleware Oracle WebLogic Server エンタープライズ JavaBeans (EJB) プログラマーズ ガイド 11g リリース 1 (10.3.1) B55528-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server エンタープライズ JavaBeans (EJB) プログラマーズ ガイド 11g リリース 1 (10.3.1) B55528-01 |
|
戻る |
次へ |
以下の節では、エンタープライズ JavaBean (EJB) のさまざまなタイプと、それらがアプリケーションで果たす機能を概説し、それらが他のアプリケーション オブジェクトおよび WebLogic Server とどのように機能するのかについて説明します。
この章は、Java のプログラミングおよび EJB 2.x の概念と機能に精通している読者を対象としています。
以降の節では、各 Bean タイプの目的と機能について説明します。
セッション Bean は、ビジネス ロジックを実装します。セッション Bean インスタンスは、一度に 1 つのクライアントにサービスを提供します。セッション Bean には、2 つのタイプ (ステートフルとステートレス) があります。
ステートレス セッション Bean は、呼び出し間でセッションやクライアントの状態の情報を格納しません。唯一格納されることのある状態はクライアントに固有のものではなく、キャッシュされたデータベース接続や別の EJB の参照などです。ステートレス セッション Bean が状態を格納できるのは、長くてメソッド呼び出しの期間だけです。メソッドが完了すると、状態情報は維持されません。ステートレス セッション Bean のインスタンスはすべて、どのクライアントにもサービスを提供できます (どのインスタンスも機能は同じ)。ステートレス セッション Bean は、ステートフル セッション Bean よりもパフォーマンスが優れています。その理由は、各ステートレス セッション Bean が複数のクライアントをサポートできるからです (ただし一度に 1 つ)。
例 : 訪問者が「お問い合わせ」リンクをクリックして電子メール送信できるインターネット アプリケーションでは、ステートレス セッション Bean を使用して、JSP によってユーザから収集された送信先と送信元の情報に基づいて電子メールを生成できます。
ステートフル セッション Bean は、特定のクライアントとの対話を反映する状態情報をメソッドやトランザクションをまたがって維持します。ステートフル セッション Bean は、クライアントと他のエンタープライズ Bean の対話を管理するか、ワークフローを管理できます。
例 : 社員が個人のプロファイル情報を表示して更新できる、ある会社の Web サイトでは、ステートフル セッション Bean を使用してさまざまな他の Bean を呼び出し、ユーザがページ上で「データの表示」をクリックした後に以下のようなユーザが必要とするサービスを提供できます。
JSP からログイン データを受け付け、そのログイン データを検証する別の EJB を呼び出す
認可の確認を JSP に送信する
認可されたユーザのプロファイル情報にアクセスする Bean を呼び出す
エンティティ Bean は、永続データの集合 (通常はデータベースの行) を表し、そのデータを管理したり読み込んだりするためのメソッドを提供します。エンティティ Bean は主キーによってユニークに識別され、複数のクライアントに同時にサービスを提供できます。エンティティ Bean は、他のエンティティ Bean との関係に参加することができます。エンティティ Bean 間の関係は、エンティティ Bean がモデル化する実世界のエンティティによって決まります。エンティティ Bean のフィールドと他のエンティティ Bean との関係は、その Bean の ejb-jar.xml デプロイメント記述子で指定されたオブジェクト スキーマで定義します。
エンティティ Bean は、他の Bean タイプ (メッセージ駆動型 Bean やセッション Bean など) をクライアントとするか、Web コンポーネントから直にアクセスすることができます。クライアントは、エンティティ Bean を使用して永続ストアのデータにアクセスします。エンティティ Bean はデータベース アクセスの仕組みをカプセル化し、その複雑さをクライアントから分離し、物理データベースの細部をビジネス ロジックから切り離します。
例 : 会社のイントラネット上の個人プロファイル情報にアクセスする社員のサービスを調整する、上の例のステートフル セッション Bean では、社員のプロファイルを取得および更新するためにエンティティ Bean を使用できます。
メッセージ駆動型 Bean は、要求に対する応答が即時である必要のない疎結合 (非同期) のビジネス ロジックを実装します。メッセージ駆動型 Bean は、JMS キューまたトピックからメッセージを受信し、そのメッセージの内容に基づいてビジネス ロジックを実行します。それは、EJB と JMS の間の非同期インタフェースです。
MDB インスタンスはそのライフサイクルを通じて、同時にではありませんが複数のクライアントからのメッセージを処理できます。特定のクライアントの状態は維持されません。メッセージ駆動型 Bean のインスタンスはすべて同じ機能であり、EJB コンテナはどの MDB インスタンスにもメッセージを割り当てることができます。コンテナは、それらのインスタンスをプールしてメッセージのストリームの並行処理を可能にします。
EJB コンテナは、必要に応じて Bean のインスタンスを作成し、JMS メッセージをインスタンスに渡すことによってメッセージ駆動型 Bean と直接対話します。コンテナは、デプロイメント時に Bean のインスタンスを作成し、メッセージのトラフィックに基づいて作動時にインスタンスを追加および削除します。
例 : 顧客から注文を受けるプロセスがサプライヤへの発注プロセスを引き起こすオンライン ショッピング アプリケーションでは、サプライヤへの発注プロセスをメッセージ駆動型 Bean で実装できます。顧客の注文が必ずサプライヤへの発注につながる一方で、そのステップは疎結合になります。その理由は、顧客の注文を確定する前にサプライヤへの発注を生成する必要はないからです。関連するサプライヤへの注文が発行される前に顧客の注文が「蓄積」されるのは問題なく、有益なことです。
以下の節では、各 Bean タイプで必須のクラス、EJB 実行時環境、および Bean の実行時の動作を管理するデプロイメント記述子ファイルについて簡単に説明します。
Bean の構造は Bean タイプによって異なります。表 2-1 に、各タイプの EJB を構成するクラスと、そのクラス タイプの用途を示します。
表 2-1 EJB の構成要素
| EJB コンポーネント | 説明 | ステートレス セッション | ステートフル セッション | エンティティ | MDB |
|---|---|---|---|---|---|
|
リモート インタフェース |
リモート インタフェースはビジネス ロジックをリモート クライアント (EJB とは別のアプリケーションで動作するクライアント) にエクスポーズする。リモート クライアントから呼び出せるビジネス メソッドを定義する。 |
使用 |
使用 |
使用 |
不使用 |
|
ローカル インタフェース |
ローカル インタフェースは、ビジネス ロジックをローカル クライアント (EJB と同じアプリケーションで動作しているクライアント) にエクスポーズする。ローカル クライアントから呼び出せるビジネス メソッドを定義する。 注意 : 1.1 EJB では利用できない。 |
使用 |
使用 |
使用 |
不使用 |
|
ローカル ホーム インタフェース |
ローカル ホーム インタフェース (EJB ファクトリまたはライフサイクル インタフェースとも呼ばれる) は、ローカル クライアント (EJB と同じアプリケーションで動作するクライアント) から使用して、Bean のインスタンスを作成、削除、および (エンティティ Bean の場合は) 検索することができるメソッドを提供する。 ローカル ホーム インタフェースには、特定の Bean インスタンスに固有ではないビジネス ロジックである「ホーム メソッド」もある。 |
使用 |
使用 |
使用 |
不使用 |
|
リモート ホーム インタフェース |
リモート ホーム インタフェース (EJB ファクトリまたはライフサイクル インタフェースとも呼ばれる) は、リモート クライアント (EJB とは別のアプリケーションで動作するクライアント) から使用して、Bean のインスタンスを作成、削除、および検索することができるメソッドを提供する。 |
使用 |
使用 |
使用 |
不使用 |
|
Bean クラス |
Bean クラスはビジネス ロジックを実装する。 |
使用 |
使用 |
使用 |
使用 |
|
主キー クラス |
エンティティ Bean だけが主キー クラスを持つ。主キー クラスは、データベースの 1 つまたは複数のフィールドにマッピングされ、エンティティ Bean が対応している永続データを識別する。 |
不使用 |
不使用 |
使用 |
不使用 |
EJB コンテナとは、アプリケーション サーバにデプロイされた Bean の実行時コンテナです。このコンテナはアプリケーション サーバの起動時に自動的に作成され、Bean と以下のような実行時サービスの間のインタフェースとして機能します。
ライフサイクル管理
コード生成
永続性管理
セキュリティ
トランザクションの管理
ロックと同時実行性の制御
Bean の構造とその実行時の動作は、1 つまたは複数の XML デプロイメント記述子ファイルで定義します。プログラマはデプロイメント記述子を EJB のパッケージ化プロセスで作成し、その記述子は Bean のコンパイル時に EJB デプロイメントの一部になります。
WebLogic Server の EJB には、以下の 3 つのデプロイメント記述子があります。
ejb-jar.xml - 標準の J2EE デプロイメント記述子。Bean はすべて ejb-jar.xml で指定する必要があります。ejb-jar.xml では、一緒にデプロイされる複数の Bean を指定できます。
weblogic-ejb-jar.xml - クラスタ化、キャッシング、トランザクションといった WebLogic Server の機能と関連する要素を格納する WebLogic Server 固有のデプロイメント記述子。このファイルは、Bean が WebLogic Server 固有の機能を利用する場合は必須です。ejb-jar.xml と同じように、weblogic-ejb-jar.xml では一緒にデプロイされる複数の Bean を指定できます。『Oracle Fusion Middleware Oracle WebLogic Server エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」を参照してください。
weblogic-cmp-jar.xml - エンティティ Bean のコンテナ管理による永続性に関連する要素を格納する WebLogic Server 固有のデプロイメント記述子。コンテナ管理による永続性を使用するエンティティ Bean は、weblogic-cmp-jar.xml ファイルに指定する必要があります。『Oracle Fusion Middleware Oracle WebLogic Server エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「weblogic-cmp-jar.xml デプロイメント記述子のリファレンス」を参照してください。
「EJB デプロイメント記述子」で説明されているように、WebLogic Server EJB の実行時の動作は、3 つの異なるデプロイメント記述子ファイル ejb-jar.xml、weblogic-ejb-jar.xml、および weblogic-cmp-jar.xml の要素で制御できます。
表 2-2 に、各記述子ファイルで値が一致しなければならない要素のリストを示します。表中の要素は、「Bean とリソースのリファレンス」と「セキュリティ ロール」で定義されています。
表 2-2 記述子ファイル間の要素のマッピング
| この要素のマッピング | ejb-jar.xml のこの要素から | weblogic-ejb-jar.xml のこの要素の同じ要素へ | および、weblogic-cmp-jar.xml のこの要素へ |
|---|---|---|---|
|
|
|
|
なし |
|
|
|
|
|
|
|
|
または
|
なし |
|
|
|
|
なし |
各記述子ファイルは、Bean とその Bean が使用する実行時ファクトリ リソースを識別する要素を格納します。
ejb-name - 各デプロイメント記述子ファイルで Bean を識別するために使用する名前。Bean の参照にアプリケーション コードで使用する名前とは関係ありません。
ejb-ref-name - 別の .jar にある Bean が参照元 Bean のコードで表される名前。
res-ref-name - リソース ファクトリが参照元 Bean のコードで表される名前。
特定の Bean またはリソース ファクトリは、それを格納する各記述子ファイルで同じ値で識別されます。表 2-1 に、Bean とリソースの参照要素およびそれらの各記述子ファイルでの位置を示します。
たとえば、LineItem という名前のコンテナ管理による永続性エンティティ Bean の場合、次の行、
<ejb-name>LineItem</ejb-name>
は以下の位置にあります。
ejb-jar.xml の assembly-descriptor 要素
weblogic-ejb-jar.xml の enterprise-bean 要素
weblogic-cmp-jar.xml の weblogic-rdbms-bean 要素
セキュリティ ロールは、ejb-jar.xml および weblogic-ejb-jar.xml の role-name 要素で定義します。
以下を参照してください。
EJB のセキュリティ機能のプログラミングについては、『Oracle Fusion Middleware Oracle WebLogic Server Security プログラマーズ ガイド』の「エンタープライズ JavaBean (EJB) のセキュリティ対策」を参照
デプロイメント記述子ファイルの作成または生成については、「デプロイメント記述子を生成する」を参照
デプロイメント記述子ファイルの編集については、「デプロイメント記述子を編集する」を参照
ejb-jar.xml の要素については、http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd を参照
weblogic-ejb-jar.xml の要素については、「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」を参照
weblogic-cmp-jar.xml の要素については、「weblogic-cmp-jar.xml デプロイメント記述子のリファレンス」を参照
図 2-1 に、EJB と WebLogic Server アプリケーションの他のコンポーネント、および EJB とクライアントとの一般的な関係を示します。
EJB は、サーブレット、Java クライアント アプリケーション、他の EJB、アプレット、非 Java クライアントなどのサーバサイドまたはクライアントサイド オブジェクトからアクセスできます。
EJB のクライアントは、アプリケーションが同じか別かに関係なく同じ方法で EJB にアクセスします。WebLogic Server は、Bean にローカル インタフェースしかない場合を除いて、リモートで機能できる EJB のホーム インタフェースおよびビジネス インタフェースの実装を自動的に作成します。
EJB では、Java Naming and Directory Interface (JNDI) を使用して環境プロパティを指定する必要があります。さまざまなマシン、アプリケーション サーバ、コンテナなど、ネットワーク上のあらゆる場所にある EJB のホーム インタフェースが含まれるように EJB クライアントの JNDI ネームスペースをコンフィグレーションできます。
ほとんどの Bean では、グローバル JNDI 名 (weblogic-ejb-jar.xml の jndi-name 要素および local-jndi-name 要素で指定) は必要ありません。ほとんどの Bean は、「EJB リンクの使用」で説明されているように ejb-link を使用してお互いを参照します。
ネットワークのオーバーヘッドのため、Bean にはリモート クライアントからアクセスするよりも同じマシン上のクライアントからアクセスする方が効率的であり、クライアントが同じアプリケーションにあればさらに効率的です。
EJB へのクライアント アクセスのプログラミングについては、「クライアントによる EJB へのアクセスのプログラミング」を参照してください。
WebLogic Server EJB は、以下のプロトコルを使用します。
T3 - リモート オブジェクトとの通信に使用します。T3 は、Remote Method Invocation (RMI) プロトコルを実装する WebLogic 独自のリモート ネットワーク プロトコルです。
RMI - リモート オブジェクトとの通信に使用します。RMI を使用すると、アプリケーションはネットワークの他のどこかにあるオブジェクトの参照を取得し、同じ JVM でクライアントと共存しているかのようにそのオブジェクトのメソッドをクライアントの仮想マシンからローカルで呼び出すことができます。
リモート インタフェースのある EJB は RMI オブジェクトです。EJB のリモート インタフェースは、java.rmi.remote を拡張します。WebLogic RMI の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server RMI プログラマーズ ガイド』を参照してください。
HTTP - EJB は、java.net.URL リソース接続ファクトリを使用して WebLogic Server 環境外の Web サーバとの HTTP 接続を取得できます。詳細については、「URL に要求を送信するように EJB をコンフィグレーションする」を参照してください。
EJB が使用するネットワーク接続の属性は、EJB を WebLogic Server カスタム ネットワーク チャネルにバインドすることによって指定できます。詳細については、「EJB のネットワーク通信のコンフィグレーション」を参照してください。
このリリースの WebLogic Server では、論理メッセージ送り先を使用して、ejb-jar.xml に定義された論理メッセージ送り先を weblogic-ejb-jar.xml に定義された実際のメッセージ送り先にマップできます。「EJB のコンフィグレーションによる論理メッセージ送り先の使用」を参照してください。
メッセージ送り先の参照をデプロイメント中に解決できない場合、警告が発行されますが、デプロイメント自体は正常に完了します。使用できないメッセージ送り先にリンクされている MDB は、そのメッセージ送り先に定期的に接続しようとします。そのメッセージ送り先が使用可能にならない限り、ejb-jar.xml に宣言されている message-destination-references のルックアップは失敗し、javax.naming.NamingException が発生します。メッセージ送り先が使用可能になると、MDB はそのメッセージ送り先に接続し、そのメッセージを処理します。
この節では、EJB の開発プロセスを容易にしたり、EJB アプリケーションのパフォーマンス、信頼性、および可用性を拡張する主要な WebLogic Server の機能について説明します。
WebLogic Server は、EJB の応答時間とパフォーマンスを向上させるプールやキャッシングなどの機能をサポートしています。プロダクション環境では、それらの機能により、クライアントが EJB インスタンスを取得したり、永続データにアクセスしてそれを保持したりするのに要する時間を短縮できます。
Weblogic Server は、ステートレス セッション Bean、メッセージ駆動型 Bean、およびエンティティ Bean のすぐに使えるよう準備された EJB インスタンスのフリー プールを保持します。その EJB コンテナはコンフィグレーションされた数の Bean インスタンスを起動時に作成するので、要求ごとに新しいインスタンスを作成する必要はありません。クライアントで EJB インスタンスが不要になると、コンテナはそれを再利用できるようにプールに返します。詳細については、以下を参照してください。
このリリースの WebLogic Server では、管理者は Administration Console を使用して EJB プールを必要に応じて初期化できます。初期化された EJB プールは、EJB がデプロイされた直後の状態にリセットされます。詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「EJB のアイドル状態の Bean のキャッシュおよびプールの初期化」を参照してください。
WebLogic Server は、ステートフル セッション Bean とエンティティ Bean のキャッシングをサポートしています。
キャッシュされている非アクティブな Bean インスタンスはパッシベーションでき (キャッシュから削除されてディスクに書き込まれる)、必要に応じて後でメモリに復元できます。Bean インスタンスをパッシベーションすると、システム リソースの使用が最適化されます。
キャッシュのサイズ、およびキャッシュから Bean を削除するルールなどの関連動作をコンフィグレーションすることができます。コンテナ管理の永続性と Bean 管理の永続性のどちらを使用するかに関係なく、エンティティ EJB ではキャッシングがサポートされています。
また、このリリースの WebLogic Server では、管理者は Administration Console を使用して EJB キャッシュを必要に応じて初期化できます。初期化された EJB キャッシュは、EJB がデプロイされた直後の状態にリセットされます。詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「EJB のアイドル状態の Bean のキャッシュおよびプールの初期化」を参照してください。
詳細については、次を参照してください。
コンテナ管理の永続性を使用する EJB 用の、追加的なキャッシング機能も用意されています。詳細については、次の節を参照してください。
WebLogic Server は、コンテナ管理による永続性を使用するエンティティ Bean 向けに以下のキャッシング機能を提供します。
リレーションシップ キャッシング - リレーションシップ キャッシングでは、関係する複数 Bean をキャッシュにロードし、それらに結合クエリを発行してクエリの発行回数を削減することによって、エンティティ Bean のパフォーマンスが高められます。詳細については、「リレーションシップ キャッシング」を参照してください。
アプリケーションレベルのキャッシング - アプリケーションレベルのキャッシング (「組み合わせキャッシング」とも呼ばれる) では、同じ J2EE アプリケーションに属する複数のエンティティ Bean が 1 つの実行時キャッシュを共有できます。詳細については、「アプリケーションレベルのキャッシングのコンフィグレーション」を参照してください。
トランザクション間のキャッシング - トランザクション間のキャッシング、または、長期キャッシングを使用すると、EJB コンテナはエンティティ Bean の永続データをトランザクション間でキャッシュできるようになります。詳細については、「cache-between-transactions によるデータベース読み込みの制限 (長期キャッシング)」を参照してください。
グループは、エンティティ Bean の一連の永続属性を指定します。field-group は、Bean のコンテナ管理による永続性 (CMP) フィールドとコンテナ管理による関係 (CMR) フィールドのサブセットを表します。Bean 内の関連フィールドを、障害のあったグループにまとめて 1 つのユニットとしてメモリ内に入れることができます。グループをクエリまたは関係に関連付けることができます。それによって、クエリを実行するか、または関係に従った結果として Bean がロードされたときに、グループ内の指定フィールドのみがロードされます。詳細については、「フィールド グループの指定」を参照してください。
ejbLoad() メソッドと ejbStore() メソッドは、ejbStore() の不要な呼び出しを防止してパフォーマンスを上げるようにコンフィグレーションできます。必要に応じて、ejbStore() がトランザクションの終わりにではなく各メソッド呼び出しの後に WebLogic Server から呼び出されるようにすることができます。詳細については、「ejbLoad() と ejbStore() の動作について」を参照してください。
WebLogic Server では、1 回のデータベース アクセスで完了できるように複数のデータベース処理をバッチ処理および順序付けできます。この機能を利用すると、複数のエンティティ インスタンスが 1 つのトランザクションから影響を受ける場合に起こる可能性のあるボトルネックを避けることができます。詳細については、「処理の順序付けとバッチ処理」を参照してください。
このリリースの WebLogic Server の CMP 2.0 エンティティ Bean では、setXXX() メソッドを呼び出しても、変更されていないプリミティブ フィールドおよび不変フィールドの値はデータベースに書き込まれません。この最適化により、特にデータベースの更新が多いアプリケーションでパフォーマンスが向上します。
頻繁には更新されない EJB データの場合、read-only EJB と read-write EJB を組み合わせることによって「read-mostly パターン」を作成できます。read-mostly パターンを使用すると、マルチキャストの無効化を利用してデータの一貫性を維持できます (更新後にキャッシュされている読み込み専用データを無効化する効率的なメカニズム)。トランザクションの更新が完了した後に invalidate() メソッドを使用すると、ローカル キャッシュが無効化されるとともに、マルチキャスト メッセージがクラスタ内の他のサーバに送信されてそれらのキャッシュされているコピーが無効化されます。詳細については、「read-mostly パターンの使い方」を参照してください。
WebLogic Server は、コンテナ管理による永続性を使用するエンティティ Bean のさまざまな付加価値データベース アクセス機能を提供します。
WebLogic Server は、CMP エンティティ EJB の単純主キーを自動的に生成する複数の手法をサポートしています (WebLogic Server で自動的に生成できる Oracle SEQUENCE の使用を含む)。詳細については、「主キーの自動生成」を参照してください。
エンティティ Bean が変更されたときに EJB コンテナが自動的に基底のテーブル スキーマを変更するようにコンフィグレーションできます。そのようにコンフィグレーションすると、テーブルはオブジェクトの関係の最新のマッピングを常に反映するようになります。詳細については、「自動テーブル作成 (開発のみ)」を参照してください。
WebLogic Server を使用すると、各自のアプリケーション コードでプログラム的にクエリを作成したり実行できるようになります。このため、EJB を更新してデプロイせずに、新しいクエリを作成して実行することができます。また、EJB デプロイメント記述子のサイズが小さくなったり、複雑さが緩和されたりもします。詳細については、「同時方式の選択」を参照してください。
WebLogic Server EJB はクラスタにデプロイすることができ、EJB のリモート クライアントのためにロード バランシングとフェイルオーバがサポートされます。EJB は、クラスタ化されているすべてのサーバにデプロイする必要があります。
WebLogic Server クラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数の WebLogic Server サーバ インスタンスで構成されます。クラスタはクライアントからは単一の WebLogic Server インスタンスのように見えます。クラスタを構成する複数のサーバ インスタンスは同じマシン上で実行することも、複数のマシンに分散配置することもできます。
EJB のフェイルオーバとロード バランシングは、レプリカ対応スタブによって処理されます。このスタブは、クラスタ全体の中からオブジェクトのインスタンスを見つけ出すためのメカニズムです。レプリカ対応スタブは、オブジェクトのコンパイル処理の結果として EJB に対して作成されます。EJB は、2 つの異なるレプリカ対応スタブを持つことができます。1 つは EJBHome インタフェース用、もう 1 つは EJBObject インタフェース用です。このため、クライアントが EJBHome スタブを使用して EJB オブジェクトをルックアップするときにはホーム レベルで、クライアントが EJBObject スタブを使用して EJB に対するメソッド呼び出しを行うときにはメソッド レベルで、一部の Bean タイプはロード バランシングとフェイルオーバの機能を利用することができます。表 2-1 は、各 EJB タイプのロード バランシングとフェイルオーバのサポートをまとめたものです (メソッド レベルとホーム レベル)。
Bean スタブは、オブジェクトに対するメソッド呼び出しを負荷分散するためのロード バランシング アルゴリズム (呼び出しルーティング クラス) を備えています。呼び出しが行われるたびに、スタブではそのロード アルゴリズムを利用して呼び出すレプリカを選択できます。
WebLogic Server クラスタは、クラスタ化された EJB のロード バランシングを行う複数のアルゴリズムをサポートしています。デフォルトはラウンドロビン方式です。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「クラスタでのロード バランシング」を参照してください。
すべての Bean タイプが、ホーム レベルのロード バランシングをサポートしています。メソッド レベルのロード バランシングは、読み書き対応エンティティ Bean を除くすべての Bean タイプでサポートされています。
|
注意 : WebLogic Server では、オブジェクトのメソッド呼び出しに対して常にロード バランシングが実行されるわけではありません。ほとんどの場合は、リモート サーバにあるレプリカを使用するよりも、スタブ自体と連結しているレプリカを使用する方が効率的です。 |
EJB のフェイルオーバは、EJBHome スタブまたはサポートされている場合は EJBObject スタブを使用して実現します。クライアントがスタブを通じて障害が発生したサービスに対して呼び出しを行うと、スタブはその障害を検出し、別のレプリカに対してその呼び出しを再試行します。
EJB のフェイルオーバでは、Bean のメソッドが多重呼び出し不変で、weblogic-ejb-jar.xml でそのようにコンフィグレーションされている必要があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「EJB と RMI オブジェクトのロード バランシング」を参照してください。
表 2-3 に、クラスタ化された EJB のフェイルオーバおよびロード バランシング機能をまとめます。
表 2-3 クラスタ化された EJB のフェイルオーバとロード バランシング
| EJB タイプ | ホーム レベルのフェイルオーバ | メソッド レベルのフェイルオーバ | 注意 |
|---|---|---|---|
|
ステートレス セッション |
サポート |
サポート |
ステートレス セッション EJB のクラスタ化動作は、 |
|
ステートフル セッション |
サポート |
サポート |
ステートフル セッション EJB のクラスタ化動作は、 |
|
読み書き対応エンティティ |
サポート |
サポートされていない |
フェイルオーバはメソッドの実行中にはサポートされず、メソッドの完了後またはメソッドがサーバ インスタンスへの接続に失敗したときにのみサポートされる。 読み書き対応 Bean のホームは Bean のローカル インスタンスを取得し、ローカル サーバ インスタンスに固定されたスタブを返す。 エンティティのクラスタ化動作は、 |
|
読み込み専用エンティティ |
サポート |
サポート |
エンティティのクラスタ化動作は、 |
|
メッセージ駆動型 |
なし |
なし |
WebLogic Java Messaging Service (JMS) は、JMS サーバのクラスタ化をサポートしている。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「JMS とクラスタ化」を参照。 |
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「EJB と RMI のレプリケーションとフェイルオーバ」および「EJB と RMI オブジェクトのロード バランシング」を参照してください。
WebLogic Server のセキュリティ機能を使用すると、EJB へのアクセス (認可) と他のアプリケーション コンポーネントや他の EJB と対話するときの EJB の ID の検証 (認証) の両方を管理できます。
WebLogic Server を使用すると、アプリケーション開発者は J2EE および WebLogic Server デプロイメント記述子を使用してセキュリティを EJB アプリケーションに組み込むことができ、システム管理者は WebLogic Server Administration Console から EJB アプリケーションのセキュリティを管理できます。後者に関しては、開発者はセキュリティをコード化する手間を省くことができ、管理者には、エンタープライズ アプリケーション (EAR) 全体、複数の EJB の含まれる EJB JAR、その JAR 内の特定の EJB、またはその EJB 内の 1 つのメソッドに対するセキュリティ ポリシーを定義する一元的なツールが提供されます。
セキュリティと EJB の詳細については、以下を参照してください。
認証、認可など、セキュリティ関連の基礎的な情報については、『Oracle Fusion Middleware Oracle WebLogic Server Security について』の「セキュリティの基礎概念」を参照
EJB の認証と認可をコンフィグレーションする手順については、『Oracle Fusion Middleware Oracle WebLogic Server Security プログラマーズ ガイド』の「エンタープライズ JavaBean (EJB) のセキュリティ対策」を参照
Administration Console を使用して EJB の認証と認可をコンフィグレーションする手順については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』を参照
