WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド
|
 |
 |
|
以下の節では、WebLogic Server エンタープライズ JavaBean (EJB) の設計オプション、設計の過程で考慮すべき Bean の動作、および推奨の設計パターンについて説明します。
この章は、Java のプログラミング、EJB 2.x、および「WebLogic Server の EJB の付加価値機能」で説明されている機能に精通している読者を対象としています。
Bean の設計を終えたら、「エンタープライズ JavaBean の実装」のプログラミングや他の実装に関するトピックを参照してください。
処理タスクの Bean タイプを選択するときには、さまざまな Bean の異なる性質や機能を考慮してください。
Bean のタイプは、クライアントとの Bean の関係によって異なります。一部の Bean タイプは一連のプロセスを通じてクライアントに固定され、ある種の総合請負業者のように機能し、クライアントに対するサービスを取得して調整します。下請け業者のように機能する Bean タイプもあり、それらの Bean は複数のクライアント指向の総合請負業者 Bean に同じ 1 つの機能を提供します。クライアント指向の Bean は、クライアント セッションを通じてクライアントの対話やクライアント プロセスと関連する他の情報を追跡します (「状態の保持」と呼ばれる機能)。複数のクライアント指向 Bean にコモディティ サービスを提供する Bean は、状態を保持しません。クライアントの対話および状態の管理に関する詳しい説明については、『WebLogic Server クラスタ ユーザーズ ガイド』の「サービス タイプごとの J2EE と WebLogic のサポート」を参照してください。
以降の節では、各 Bean タイプのクライアントとの対話や状態管理の特性を説明します。
注意 : 各 Bean タイプが適しているビジネス プロセスの例を含む、各 Bean タイプの基本的な概要については、「アプリケーションによる EJB の使い方」を参照してください。
セッション Bean は、サーバ内の 1 つのクライアントを表します。サーバにデプロイされたアプリケーションにアクセスするために、クライアントはセッション Bean のメソッドを呼び出します。セッション Bean はクライアントの代わりに作業を実行し、サーバ内のタスクを実行してクライアントから複雑さを隠蔽します。
セッション Bean インスタンスにはクライアントが 1 つあります。セッション Bean は永続的ではありません。クライアントが終了すると、そのセッション Bean は終了したようになり、クライアントとの関連はなくなります。
セッション Bean は Web アプリケーションとエンティティ Bean の間で Facade として使用して、複雑な対話を格納し、RMI 呼び出しを削減することができます。クライアント アプリケーションが直接リモートのエンティティ Bean にアクセスする場合、各ゲッター メソッドはリモート呼び出しです。セッション Facade Bean はエンティティ Bean にローカルでアクセスし、データを構造体に収集して、それを値で返すことができます。以降の節では、2 種類のセッション Bean、状態を保持するセッション Bean と状態を保持しないセッション Bean が説明されています。
ステートフル セッション Bean は、密結合クライアントとの対話サービスをサポートしています。ステートフル セッション Bean は、特定のクライアントのタスクを実行します。この Bean は、クライアント セッションの間状態を保持します。セッションが完了した後は、状態は維持されません。
ステートフル セッション Bean はクライアント単位でインスタンス化され、急激に増加してリソースを消費する可能性があります。
ステートフル セッション Bean と同じように、ステートレス セッション Bean は特定のクライアントのタスクを実行します。ステートフル セッション Bean とは違って、ステートレス セッション Bean はクライアントの状態を保持しません。ステートレス セッション Bean は、メソッド呼び出しの間だけ状態を保持できます。メソッドが終了すると、状態は維持されなくなります。
メソッド呼び出しの間を除いて、ステートレス Bean のインスタンスはすべて同じ機能であり、EJB コンテナはインスタンスをどのクライアント リクエストにでも割り当てることができます。ホーム インタフェースでステートレス Bean が作成されると、Bean がデプロイされたどのサーバにでも呼び出しを転送できるレプリカ対応スタブが返されます。ステートレス Bean では状態が保持されないので、スタブでは Bean のホストであるどのサーバにでも呼び出しを転送できます。
ステートレス セッション Bean は 2 次ストレージに書き込まれないので、ステートフル セッション Bean よりもパフォーマンスが良くなります。
多数のクライアントが必要なアプリケーションの場合、ステートレス セッション Bean はステートフル セッション Bean よりも優れたスケーラビリティを実現します。
インスタンスを作成するシステムのオーバーヘッドが、ステートフル セッション Bean よりもステートレス セッション Bean の方が小さくなります。
ステートフル セッション Bean よりもステートレス セッション Bean の方が、通常はより多くのクライアントをサポートできます。ステートレス セッション Bean のインスタンスは 1 つのクライアント リクエストの間だけ確保されますが、ステートフル セッション Bean はセッションが終わるまで確保されます。
必要なステートレス セッション Bean インスタンスの数は通常はサーバの実行キューのスレッド数とだいたい同じですが (数百)、必要なステートフル セッション Bean インスタンスの数はアプリケーションのクライアント数により密接に対応します (一部のアプリケーションでは数十万になる)。
このリリースの WebLogic Server では、Web サービス エンドポイント インタフェースを使用してステートレス セッション Bean を Web サービスとして公開できます。詳細については、『WebLogic Web サービス プログラマーズ ガイド』を参照してください。
エンティティ Bean は、永続ストレージ メカニズムのビジネス オブジェクトを表します。ビジネス オブジェクトの例としては、顧客、注文、製品などがあります。J2EE SDK では、永続ストレージ メカニズムはリレーショナル データベースです。通常、各エンティティ Bean はリレーショナル データベースに基底のテーブルを持ち、Bean の各インスタンスはそのテーブルの行に対応します。
ejb-jar.xml ファイルで指定します。Bean でトランザクションの境界をコード化する必要はありません。コンテナが境界を設定します。トランザクション管理については、「機能と設計パターン」を参照してください。 WebLogic Server は、読み書き対応と読み込み専用の 2 種類のエンティティ Bean をサポートしています。
読み込み専用 Bean は、データベースからデータが読み込まれる回数が減るので読み書き対応 Bean よりもパフォーマンスが優れています。
一部のアプリケーションでは、読み書き対応エンティティ Bean の使用が必須です。どちらを使用するかは、更新の頻度とデータ一貫性の要件によって決まります。表 3-1 に、主なガイドラインを示します。
表 3-1 読み書き対応エンティティ Bean と読み込み専用エンティティ Bean の比較
|
|
以降の節では、パフォーマンスとデータ一貫性の要件に基づいてエンティティ Bean の実装を選択する手法について説明します。
古いデータで問題ない場合は、読み込み専用エンティティ Bean を使用することをお勧めします。読み込み専用エンティティ Bean は、製品カタログや多くのアプリケーションの内容の大部分に適しています。主キーに基づく読み込みは、タイマーに基づいて無効化されるローカル エンティティ キャッシュに対して実行されます。他のクエリは、データベースに対して行われます。読み込み専用エンティティ Bean のパフォーマンスは、トランザクション対応エンティティよりも 3 ～ 4 倍速くなります。
注意 : クライアントは読み込み専用エンティティ Bean でセッター メソッドを正常に呼び出すことができるが、データが永続ストアに移動することはあり得ない。
読み書き対応 Bean は、顧客口座の保守など、高度なデータ一貫性が要求されるアプリケーションに適しています。読み書きはすべてデータベースで実行されます。
注意 : Bean 管理による永続性を使用するエンティティ Bean、またはコンテナ管理による永続性を使用する EJB 1.1 エンティティ Bean の場合は、weblogic-ejb-jar.xml で isModified メソッドを指定することでデータベースへの書き込み回数を減らすことができます。
read-mostly アプリケーション (頻繁に読み込みが行われ、更新はまれであるカタログなど) では、読み込み専用 Bean と読み込み専用 Bean を拡張する読み書き対応 Bean の組み合わせが適しています。読み込み専用 Bean では高速で一貫性の乏しい読み込みが行われ、読み書き対応 Bean では一貫性の優れた書き込みが行われます。
リモート呼び出しによるオーバーヘッドを回避するには、クライアントまたはサーブレットのコードからリモート EJB エンティティ Bean にアクセスしないようにします。その代わりに、セッション Bean (「Facade」と呼ばれる) を使用して複雑な対話を内包し、Web アプリケーションから RMI オブジェクトへの呼び出しを削減します。クライアント アプリケーションが直接リモートのエンティティ Bean にアクセスする場合、各ゲッター メソッドはリモート呼び出しです。セッション Facade Bean はエンティティ Bean にローカルでアクセスし、データを構造体に収集して、それを値で返すことができます。
Web 層から直接ローカルのエンティティ Bean インスタンスにアクセスすることに不都合な点はありません。むしろそうする方が、Facade を使用するよりも適切です。
転送オブジェクト (値オプションやヘルパー オブジェクトとも呼ばれる) は使用しないでください。転送オブジェクトは関連する属性をグループ化する EJB 内のシリアライズ可能クラスで、リモート ビジネス メソッドの戻り値の型として使用される複合値を形成します。
パフォーマンスを最適化するためには、転送オブジェクトを使用するよりもローカル エンティティ インスタンスにアクセスする方が常に適切です。
メッセージ駆動型 Bean (MDB) とは、J2EE アプリケーションが非同期でメッセージを処理できるようにするエンタープライズ Bean のことです。MDB は、JMS または JCA メッセージ リスナ (イベントの代わりにメッセージを受信することを除いてイベント リスナと同様) として機能します。メッセージは、どの J2EE コンポーネント (アプリケーション クライアント、別のエンタープライズ Bean、または Web コンポーネント) または非 J2EE アプリケーションからでも送信できます。
メッセージが到着すると、コンテナはメッセージ駆動型 Bean の onMessage メソッドを呼び出してそのメッセージを処理します。onMessage メソッドは通常はメッセージを 5 つある JMS メッセージ タイプのいずれかにキャストし、アプリケーションのビジネス ロジックに従って処理します。onMessage メソッドはヘルパー メソッドを呼び出すか、セッション Bean またはエンティティ Bean を呼び出してメッセージ内の情報を処理するか、あるいはその情報をデータベースに格納します。
メッセージはトランザクション コンテキスト内のメッセージ駆動型 Bean に配信することもできます。そうすれば、onMessage メソッドのすべての処理が単一トランザクションに属することになります。メッセージの処理がロールバックされた場合、そのメッセージは再配信されます。
メッセージ駆動型 Bean を設計する上での選択肢については、「MDB とメッセージング モデル」を参照してください。
永続性管理の方式は、エンティティ Bean のデータベース アクセスがどのように実行されるのかを決めます。
エンティティ Bean の永続性管理方式 (コンテナ管理または Bean 管理) は ejb-jar.xml の persistence-type 要素でコンフィグレーションします。
注意 : weblogic-ejb-jar.xml の persistence-use 要素では、コンテナ管理による永続性を使用するエンティティ Bean のサードパーティ永続性サービスの使用を指定できます。
CMP Bean は、すべてのデータベース対話について EJB コンテナに依存します。Bean は、データベースにアクセスするコードを持ちません。その代わりに、EJB コンテナが、weblogic-cmp-jar.xml にあるエンティティ Bean の永続フィールドと関係についての情報に基づいてデータベース アクセス メソッドを生成します。詳細については、「weblogic-cmp-jar.xml デプロイメント記述子のリファレンス」を参照してください。
CMP Bean は、データベース アクセスに EJB QL を使用します。「EJB クエリ言語 (EJB-QL) と WebLogic Server」を参照してください。
注意 : 対象アプリケーション サーバでサポートされていない機能を使用する Bean を再デプロイする場合は、Bean のコードを修正することが必要な場合もあります。
CMP エンティティでサポートされる機能の詳細については、「エンティティ EJB」を参照してください。
それ自身の永続性を管理する Bean には、データ アクセスを実行するメソッドが必要です。
BMP は推奨されていません。CMP は、「生産性と移植性が必要な場合はコンテナ管理による永続性 (CMP) を使用する」で説明されているように Bean 管理による永続性より多くのメリットを提供します。
ただし、一部のアプリケーションの要件は CMP Bean では満たすことができません。たとえば、以下の場合は BMP を使用する必要があります。
トランザクションとは、ディスク上、メモリ内、またはデータベース内にあるアプリケーションの状態を変更する作業の 1 単位であり、一度開始されると最後まで完了するか、あるいは一切何も行われません。
トランザクションは、EJB コンテナ、Bean のコード、またはクライアント コードによって境界設定 (開始され、コミットまたはロールバックで終わる) できます。
トランザクションは、コストのかかるアプリケーション リソースです (特にデータベース トランザクション)。その理由は、トランザクションが終わるまでネットワーク接続が確保されるからです。データベース層、アプリケーション サーバ層、および Web 層のある多層アーキテクチャでは、ネットワーク トラフィックの「往復」を減らしてパフォーマンスを最適化します。最適なアプローチは、EJB コンテナでアプリケーション サーバ レベルでトランザクションを開始および停止することです。
コンテナ管理によるトランザクション (CMT) は、セッション、エンティティ、およびメッセージ駆動型のすべての Bean タイプでサポートされています。コンテナ管理によるトランザクションは優れたパフォーマンスを実現し、開発を容易にします。その理由は、エンタープライズ Bean のコードにトランザクションを開始および終了する文が含まれないからです。
CMT Bean の各メソッドは、1 つのトランザクションと関連付けることができますが、必ずしもその必要はありません。コンテナ管理によるトランザクションでは、EJB コンテナが開始、停止、コミット、およびロールバックを含めてトランザクションを管理します。通常、コンテナは Bean のメソッドが開始される直前にトランザクションを開始し、メソッドが終了する直前にトランザクションをコミットします。
ejb-jar.xml および weblogic-ejb-jar.xml のトランザクション管理に関連する要素については、「コンテナ管理によるトランザクション要素」を参照してください。
トランザクションの途中でシステム例外が送出された場合、コンテナは自動的にトランザクションをロールバックします。EJB コンテナをコンフィグレーションして、ロールバックされたコンテナ管理のトランザクションを自動的に再試行できます。ロールバックは、Bean で明示的にプログラミングすることもできます。詳細については、「エンタープライズ JavaBean の実装」を参照してください。
メソッド呼び出しを別の呼び出しシナリオのエンタープライズ Bean のビジネス メソッドに委託したときにトランザクションの境界を EJB コンテナがどのように管理するかは、ejb-jar.xml の trans-attribute 要素で管理します。
たとえば、トランザクションを呼び出すクライアントがそれ自体トランザクション内で動作している場合は、呼び出されたトランザクションの trans-attribute 要素によって、それが新しいトランザクションで動作するのか、呼び出し側トランザクション内で動作するのかが決まります。
1 つのデータベース トランザクションは、複数のサーバ インスタンス上にある複数の Bean にまたがることができます。複数の Bean が関わるトランザクションの実装については、「複数の EJB で分散されるトランザクションのプログラミング」を参照してください。
複数のデータストアを更新するトランザクションは、論理単位としてコミットまたはロールバックする必要があります。2 フェーズ コミット プロトコルを使用すると、複数のリソース マネージャにまたがる 1 つのトランザクションを調整して、すべての参加データベースで更新がコミットされるか、すべてのデータベースで完全にロールバックされるようにすることができます。
2 フェーズ コミットはリソースを大量に消費します。トランザクションは複数のデータベースに分散しないようにしてください。
Bean 管理によるトランザクションでは、EJB のコードが開始、停止、コミット、およびロールバックを含めてトランザクションを管理します。Bean 管理によるトランザクションは、すべてのセッション Bean およびメッセージ駆動型 Bean でサポートされています。エンティティ Bean では、Bean 管理によるトランザクションは使用できません。
注意 : Bean 管理によるトランザクションでは、コンテナ提供のトランザクション管理機能は使用できません。Bean 管理によるトランザクションとコンテナ管理によるトランザクションを同じ Bean で組み合わせないでください。
Bean 管理によるトランザクションを使用せざるを得ない要件の例を以下に示します。
開発を簡略化し、信頼性を向上させるために、Bean 管理によるトランザクションは適度に短くしてください。
Bean 管理によるトランザクションの実装については、「Bean 管理のトランザクションのプログラミング」を参照してください。
クライアント アプリケーションでは、中断や予期せぬ終了が起こることがあります。クライアント レベルでトランザクションを開始および停止する場合は、以下のリスクがあります。
決定的な理由がない限りは、クライアント アプリケーションでトランザクションを管理しないでください。
トランザクションのアイソレーション レベルとは、更新されたがコミットはされていないデータを他のトランザクションに公開する度合いのことです。コミットされていないデータへのアクセスを許可すると、パフォーマンスは向上しますが、不適切なデータが他のトランザクションに提供されるリスクが増します。
Bean 管理によるトランザクションのアイソレーション レベルは、Bean の Java コードで設定します。手順については、「Bean 管理のトランザクションのプログラミング」を参照してください。
コンテナ管理によるトランザクションのアイソレーション レベルは、weblogic-ejb-jar.xml の transaction-isolation 要素の isolation-level 下位要素で設定します。WebLogic Server は、この値を基底のデータベースに渡します。トランザクションの動作は、EJB のアイソレーション レベル設定と、基盤となる永続ストレージの同時実行性の制御に依存します。
コンテナ管理トランザクションのアイソレーション レベルの設定に関する詳細については、『WebLogic JTA プログラマーズ ガイド』を参照してください。
WebLogic Server は、アプリケーションの要件を満たすためにコンフィグレーションできる、エンタープライズ Bean のさまざまな付加価値機能を提供します。それらの機能の詳細については、「WebLogic Server の EJB の付加価値機能」を参照してください。
表 3-2 に、アプリケーションの要件と、それらを満たすために使用できる設計方式および WebLogic Server の機能を示します。
|
|
|