| Oracle® Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発 12c (12.1.2) E48053-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発 12c (12.1.2) E48053-02 |
|
前 |
次 |
この章では、Enterprise 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のインスタンスを作成し、メッセージのトラフィックに基づいて作動時にインスタンスを追加および削除します。
詳細は、『Oracle WebLogic Serverメッセージドリブン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 - 標準Java EEデプロイメント記述子。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 WebLogic Server Enterprise JavaBeansバージョン2.1の開発』の「weblogic-ejb-jar.xmlデプロイメント記述子のリファレンス」を参照してください。
weblogic-cmp-jar.xml - エンティティBeanのコンテナ管理による永続性に関連する要素を格納するWebLogic Server固有のデプロイメント記述子。コンテナ管理による永続性を使用するエンティティBeanは、weblogic-cmp-jar.xmlファイルに指定する必要があります。この『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』の「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のセキュリティ機能のプログラミングについては、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のEnterprise 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 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に定義された実際のメッセージ宛先にマップできます。『Oracle WebLogic ServerメッセージドリブンBeanの開発』の論理メッセージ宛先を使用する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インスタンスが不要になると、コンテナはそれを再利用できるようにプールに返します。詳細については、以下を参照してください。
『Oracle WebLogic ServerメッセージドリブンBeanの開発』のメッセージドリブンEJBのライフサイクルおよびフリー・プールに関する項
このリリースのWebLogic Serverでは、管理者は管理コンソールを使用してEJBプールを必要に応じて初期化できます。初期化されたEJBプールは、EJBがデプロイされた直後の状態にリセットされます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのEJBのアイドル状態のBeanのキャッシュおよびプールの初期化に関する項を参照してください。
WebLogic Serverは、ステートフル・セッションBeanとエンティティBeanのキャッシングをサポートしています。
キャッシュされている非アクティブなBeanインスタンスはパッシブ化でき(キャッシュから削除されてディスクに書き込まれる)、必要に応じて後でメモリーに復元できます。Beanインスタンスをパッシブ化すると、システム・リソースの使用が最適化されます。
キャッシュのサイズ、およびキャッシュからBeanを削除するルールなどの関連動作を構成することができます。コンテナ管理の永続性とBean管理の永続性のどちらを使用するかに関係なく、エンティティEJBではキャッシングがサポートされています。
また、このリリースのWebLogic Serverでは、管理者は管理コンソールを使用してEJBキャッシュを必要に応じて初期化できます。初期化されたEJBキャッシュは、EJBがデプロイされた直後の状態にリセットされます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのEJBのアイドル状態のBeanのキャッシュおよびプールの初期化に関する項を参照してください。
詳細は、次を参照してください:
コンテナ管理の永続性を使用するEJB用の、追加的なキャッシング機能も用意されています。詳細については、次の節を参照してください。
WebLogic Serverは、コンテナ管理による永続性を使用するエンティティBean向けに以下のキャッシング機能を提供します。
リレーションシップ・キャッシング - リレーションシップ・キャッシングでは、関係する複数Beanをキャッシュにロードし、それらに結合問合せを発行して問合せの発行回数を削減することによって、エンティティBeanのパフォーマンスが高められます。詳細については、「リレーションシップ・キャッシング」を参照してください。
アプリケーション・レベルのキャッシング - アプリケーション・レベルのキャッシング(「組合せキャッシング」とも呼ばれます)では、同じJava EEアプリケーションに属する複数のエンティティ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 WebLogic Serverクラスタの管理』のクラスタでのロード・バランシングに関する項を参照してください。
すべてのBeanタイプが、ホーム・レベルのロード・バランシングをサポートしています。メソッド・レベルのロード・バランシングは、読み書き対応エンティティBeanを除くすべてのBeanタイプでサポートされています。
|
注意: WebLogic Serverでは、オブジェクトのメソッド呼出しに対して常にロード・バランシングが実行されるわけではありません。ほとんどの場合は、リモート・サーバーにあるレプリカを使用するよりも、スタブ自体と連結しているレプリカを使用する方が効率的です。 |
EJBのフェイルオーバーは、EJBHomeスタブまたはサポートされている場合はEJBObjectスタブを使用して実現します。クライアントがスタブを通じて障害が発生したサービスに対して呼出しを行うと、スタブはその障害を検出し、別のレプリカに対してその呼出しを再試行します。
EJBのフェイルオーバーでは、Beanのメソッドが多重呼出し不変で、weblogic-ejb-jar.xmlでそのように構成されている必要があります。詳細は、『Oracle WebLogic Serverクラスタの管理』のEJBおよびRMIオブジェクトのレプリケーションとフェイルオーバーに関する項を参照してください。
表2-3に、クラスタ化されたEJBのフェイルオーバーおよびロード・バランシング機能をまとめます。
表2-3 クラスタ化されたEJBのフェイルオーバーとロード・バランシング
| EJBタイプ | ホーム・レベルのフェイルオーバー | メソッド・レベルのフェイルオーバー | 注意 |
|---|---|---|---|
|
ステートレス・セッション |
サポート |
サポート |
ステートレス・セッションEJBのクラスタ化動作は、 |
|
ステートフル・セッション |
サポート |
サポート |
ステートフル・セッションEJBのクラスタ化動作は、 |
|
読み書き対応エンティティ |
サポート |
サポートされていない |
フェイルオーバーはメソッドの実行中にはサポートされず、メソッドの完了後またはメソッドがサーバー・インスタンスへの接続に失敗したときにのみサポートされます。 読み書き対応BeanのホームはBeanのローカル・インスタンスを取得し、ローカル・サーバー・インスタンスに固定されたスタブを返します。 エンティティのクラスタ化動作は、 |
|
読取り専用エンティティ |
サポート |
サポート |
エンティティのクラスタ化動作は、 |
|
メッセージドリブン |
なし |
なし |
WebLogic Java Messaging Service (JMS)は、JMSサーバーのクラスタリングをサポートしています。詳細は、『Oracle WebLogic Serverクラスタの管理』のJMSとクラスタリングに関する項を参照してください。 |
詳細は、『Oracle WebLogic Serverクラスタの管理』のEJBおよびRMIのレプリケーションとフェイルオーバーに関する項およびEJBとRMIオブジェクトのロード・バランシングに関する項を参照してください。
WebLogic Serverのセキュリティ機能を使用すると、EJBへのアクセス(認可)と他のアプリケーション・コンポーネントや他のEJBと対話するときのEJBのIDの検証(認証)の両方を管理できます。
WebLogic Serverを使用すると、アプリケーション開発者はJava EEおよびWebLogic Serverデプロイメント記述子を使用してセキュリティをEJBアプリケーションに組み込むことができ、システム管理者はWebLogic Server管理コンソールからEJBアプリケーションのセキュリティを管理できます。後者に関しては、開発者はセキュリティをコード化する手間を省くことができ、管理者には、エンタープライズ・アプリケーション(EAR)全体、複数のEJBの含まれるEJB JAR、そのJAR内の特定のEJB、またはそのEJB内の1つのメソッドに対するセキュリティ・ポリシーを定義する一元的なツールが提供されます。
セキュリティとEJBの詳細については、以下を参照してください。
認証、認可など、セキュリティ関連の基礎的な情報については、『Oracle WebLogic Serverセキュリティの理解』のセキュリティの基礎に関する項を参照してください。
EJBの認証と認可を構成する手順については、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のEnterprise JavaBean (EJB)の保護に関する項を参照してください。
管理コンソールを使用してEJBの認証と認可を構成する手順については、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。
