| Oracle® Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング 11gリリース1(10.3.6) B61624-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング 11gリリース1(10.3.6) B61624-04 |
|
前 |
次 |
次の項では、WebLogic Server Enterprise JavaBeans (EJB)の設計オプション、設計の過程で考慮すべきBeanの動作、および推奨の設計パターンについて説明します。
この章は、Javaのプログラミング、EJB 2.x、および「WebLogic ServerのEJBの付加価値機能」で説明されている機能に精通している読者を対象としています。
Beanの設計を終えたら、第4章「Enterprise JavaBeansの実装」のプログラミングや他の実装に関するトピックを参照してください。
処理タスクのBeanタイプを選択するときには、様々なBeanの異なる性質や機能を考慮してください。
Beanのタイプは、クライアントとのBeanの関係によって異なります。一部のBeanタイプは一連のプロセスを通じてクライアントに固定され、ある種の総合請負業者のように機能し、クライアントに対するサービスを取得して調整します。下請け業者のように機能するBeanタイプもあり、それらのBeanは複数のクライアント指向の総合請負業者Beanに同じ1つの機能を提供します。クライアント指向のbeanは、クライアント・セッションを通じてクライアントの対話やクライアント・プロセスと関連する他の情報を追跡します(「状態の保持」と呼ばれる機能)。複数のクライアント指向Beanにコモディティ・サービスを提供するBeanは、状態を保持しません。
以降の節では、各Beanタイプのクライアントとの対話や状態管理の特性を説明します。
セッション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のインスタンスはすべて同じ機能であり、EJBコンテナはインスタンスをどのクライアント・リクエストにでも割り当てることができます。ホーム・インタフェースでステートレスBeanが作成されると、Beanがデプロイされたどのサーバーにでも呼出しを転送できるレプリカ対応スタブが返されます。ステートレスBeanでは状態が保持されないので、スタブではBeanのホストであるどのサーバーにでも呼出しを転送できます。
ステートレス・セッションBeanは2次ストレージに書き込まれないので、ステートフル・セッションBeanよりもパフォーマンスが良くなります。
多数のクライアントが必要なアプリケーションの場合、ステートレス・セッションBeanはステートフル・セッションBeanよりも優れたスケーラビリティを実現します。
インスタンスを作成するシステムのオーバーヘッドは、ステートフル・セッションBeanよりもステートレス・セッションBeanの方が小さくなります。
ステートレス・セッションBeanのインスタンスは、フリー・プールから取得することができます。
ステートフル・セッションBeanのインスタンスはクライアントのリクエストでインスタンス化され、セッション・コンテキストを設定する必要があり、セッションの最後にガベージ・コレクションされる必要があります。
ステートフル・セッションBeanよりもステートレス・セッションBeanの方が、通常はより多くのクライアントをサポートできます。ステートレス・セッションBeanのインスタンスは1つのクライアント・リクエストの間だけ確保されますが、ステートフル・セッションBeanはセッションが終わるまで確保されます。
必要なステートレス・セッションBeanインスタンスの数は通常はサーバーの実行キューのスレッド数とだいたい同じですが(数百)、必要なステートフル・セッションBeanインスタンスの数はアプリケーションのクライアント数により密接に対応します(一部のアプリケーションでは数十万になります)。
エンティティBeanは、永続ストレージ・メカニズムのビジネス・オブジェクトを表します。ビジネス・オブジェクトの例としては、顧客、注文、製品などがあります。Java SE JDKでは、永続ストレージ・メカニズムはリレーショナル・データベースです。通常、各エンティティBeanはリレーショナル・データベースに基底の表を持ち、Beanの各インスタンスはその表の行に対応します。
エンティティBeanの主な特長は以下のとおりです。
永続性 - エンティティBeanの永続性は、EJBコンテナまたはそのBean自体で管理できます。Beanでコンテナ管理による永続性が使用される場合、EJBコンテナは自動的に必要なデータベース・アクセス呼出しを生成します。エンティティBeanに記述したコードには、それらの呼出しは含まれません。Bean管理による永続性の場合は、データベース・アクセス・コードを記述してそれをBeanに含める必要があります。
共有アクセス: そのライフサイクルを通じて、エンティティBeanのインスタンスでは複数のクライアントをサポートできます(ただし同時ではありません)。複数のクライアントが同じデータを変更する場合があるので、エンティティBeanがトランザクション内で機能することが重要です。通常、EJBコンテナはトランザクション管理を提供します。この場合は、トランザクションの管理方法を決めるトランザクション属性をBeanのejb-jar.xmlファイルで指定します。Beanでトランザクションの境界をコード化する必要はありません。コンテナが境界を設定します。トランザクション管理については、「トランザクションの設計と管理のオプション」を参照してください。
主キー - 各エンティティBeanには、一意のオブジェクト識別子があります。たとえば顧客エンティティBeanは、顧客番号で識別される場合があります。一意の識別子(主キー)により、クライアントは特定のエンティティBeanを見つけることができます。詳細については、「コンテナ管理による関係(CMR)の使用」を参照してください。
関係 - リレーショナル・データベースの表のように、エンティティBeanは他のエンティティBeanと関連することがあります。Bean管理による永続性を使用するエンティティBeanとコンテナ管理による永続性を使用するエンティティBeanでは、関係の実装方法が異なります。Bean管理による永続性の場合は、記述するコードで関係を実装します。コンテナ管理による永続性の場合は、EJBコンテナが関係を処理します。このため、コンテナ管理による永続性を使用するエンティティBeanの関係はコンテナ管理による関係と呼ばれることもあります。詳細については、「CMRのエンティティのカスケード削除の使用」を参照してください。
WebLogic Serverは、読み書き対応と読取り専用の2種類のエンティティBeanをサポートしています。
読取り専用Beanは、データベースからデータが読み込まれる回数が減るので読み書き対応Beanよりもパフォーマンスが優れています。
一部のアプリケーションでは、読み書き対応エンティティBeanの使用が必須です。どちらを使用するかは、更新の頻度とデータ一貫性の要件によって決まります。表3-1に、主なガイドラインを示します。
表3-1 読み書き対応エンティティBeanと読取り専用エンティティ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)とは、Java EEアプリケーションが非同期でメッセージを処理できるようにするエンタープライズBeanのことです。MDBは、JMSまたはJCAメッセージ・リスナー(イベントのかわりにメッセージを受信することを除いてイベント・リスナーと同様)として機能します。メッセージは、Java EEコンポーネント(アプリケーション・クライアント、別のエンタープライズBeanまたはWebコンポーネント)、あるいはJava EE以外のアプリケーションから送信されます。
『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』を参照してください。
永続性管理の方式は、エンティティ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を使用します。付録G「EJB問合せ言語(EJB-QL)とWebLogic Server」を参照してください。
コンテナ管理による永続性のメリットは以下のとおりです。
プログラミングの労力の削減 - CMP Beanのためにデータベース・アクセスを実行するメソッドを記述する必要がありません。EJBコンテナが自動的にそのためのメソッドを生成します。
移植性の向上 - CMPは、以下の点でBeanの移植性を向上させます。
物理データベースの細部をビジネス・ロジックから切り離すことで、Beanが論理的に関連データベースから独立します。修正したデータベース設計を実装するか、別のデータベース・サーバーに変更する場合でも、Beanコードを修正する必要がありません。
Beanのコードを修正したり再コンパイルすることなく、Beanを別のJava EEアプリケーション・サーバーに再デプロイできます。
|
注意: ターゲット・アプリケーション・サーバーでサポートされていない機能を使用するBeanを再デプロイする場合は、Beanのコードを修正することが必要な場合もあります。 |
CMPエンティティでサポートされる機能の詳細は、「エンティティEJB」を参照してください。
それ自身の永続性を管理するBeanには、データ・アクセスを実行するメソッドが必要です。
BMPは推奨されていません。CMPは、「生産性と移植性が必要な場合はコンテナ管理による永続性(CMP)を使用する」で説明されているようにBean管理による永続性より多くのメリットを提供します。
ただし、一部のアプリケーションの要件はCMP Beanでは満たすことができません。たとえば、以下の場合はBMPを使用する必要があります。
アプリケーションでSQLストアド・プロシージャの既存のライブラリを使用する必要があります。
ターゲット・データベースでJDBCがサポートされていません。
Beanとデータベース表の間のマッピングが複雑です。たとえば、Beanは主キーを共有しない複数の表にマッピングされます。
トランザクションとは、ディスク上、メモリー内、またはデータベース内にあるアプリケーションの状態を変更する作業の1単位であり、一度開始されると最後まで完了するか、あるいは一切何も行われません。
トランザクションは、EJBコンテナ、Beanのコード、またはクライアント・コードによって境界設定(開始およびコミットまたはロールバックでの終了)できます。
トランザクションは、コストのかかるアプリケーション・リソースです(特にデータベース・トランザクション)。その理由は、トランザクションが終わるまでネットワーク接続が確保されるからです。データベース層、アプリケーション・サーバー層、およびWeb層のある多層アーキテクチャでは、ネットワーク・トラフィックの「往復」を減らしてパフォーマンスを最適化します。最適なアプローチは、EJBコンテナでアプリケーション・サーバー・レベルでトランザクションを開始および停止することです。
コンテナ管理によるトランザクション(CMT)は、セッション、エンティティ、およびメッセージドリブンのすべてのBeanタイプでサポートされています。ンテナ管理によるトランザクションは優れたパフォーマンスを実現し、開発を容易にします。その理由は、エンタープライズBeanのコードにトランザクションを開始および終了する文が含まれないからです。
CMT Beanの各メソッドは、1つのトランザクションと関連付けることができますが、必ずしもその必要はありません。コンテナ管理によるトランザクションでは、EJBコンテナが開始、停止、コミット、およびロールバックを含めてトランザクションを管理します。通常、コンテナはBeanのメソッドが開始される直前にトランザクションを開始し、メソッドが終了する直前にトランザクションをコミットします。
ejb-jar.xmlおよびweblogic-ejb-jar.xmlのトランザクション管理に関連する要素については、「コンテナ管理によるトランザクション要素」を参照してください。
トランザクションの途中で例外がスローされた場合、コンテナは自動的にトランザクションをロールバックします。トランザクションがシステム例外に基づくエラーの結果ロールバックされた場合を除いて、ロールバックされたコンテナ管理のトランザクションを自動的に再試行するように、EJBコンテナを構成できます。ロールバックは、Beanで明示的にプログラミングすることもできます。詳細は、第4章「Enterprise JavaBeansの実装」を参照してください。
メソッド呼出しを別の呼出しシナリオのエンタープライズ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管理によるトランザクションを使用せざるを得ない要件の例を以下に示します。
1つのメソッド呼出しで複数のトランザクションを定義する必要があります。コンテナ管理によるトランザクションの場合、メソッドは1つのトランザクションとしか関連付けることができません。Bean管理によるトランザクションを使用すると、1つのメソッドで複数のトランザクションを定義できます。ただし、そのメソッドを複数のメソッドに分割し、それぞれが専用のコンテナ管理によるトランザクションを使用するようにして、Bean管理によるトランザクションが必要にならないようにしてください。
複数のEJBメソッド呼出しにまたがる1つのトランザクションを定義する必要があります。たとえば、あるメソッドを使用してトランザクションを開始し、別のメソッドでトランザクションをコミットまたはロールバックするステートフル・セッションEJBの場合です。
EJBオブジェクトの機能についての詳しい情報が必要になるため、このような動作は避けてください。ただし、どうしても必要な場合は、Bean管理によるトランザクションの調整を利用し、個々のメソッドに対するクライアントの呼出しを調整する必要があります。
開発を簡略化し、信頼性を向上させるために、Bean管理によるトランザクションは適度に短くしてください。
Bean管理によるトランザクションの実装については、「Bean管理のトランザクションのプログラミング」を参照してください。
クライアント・アプリケーションでは、中断や予期せぬ終了が起こることがあります。クライアント・レベルでトランザクションを開始および停止する場合は、以下のリスクがあります。
ユーザーのアクションを待つ間、中断の間、クライアント・アクティビティが再開されるまで、またはタイムアウトになるまでのネットワーク・リソースの消費
トランザクションのタイムアウトまたは終了後にトランザクションをロールバックするための処理リソースとネットワーク・リソースの消費
決定的な理由がない限りは、クライアント・アプリケーションでトランザクションを管理しないでください。
トランザクションの分離レベルとは、更新されたがコミットはされていないデータを他のトランザクションに公開する度合いのことです。コミットされていないデータへのアクセスを許可すると、パフォーマンスは向上しますが、不適切なデータが他のトランザクションに提供されるリスクが増します。
Bean管理によるトランザクションの分離レベルは、BeanのJavaコードで設定します。手順については、「Bean管理のトランザクションのプログラミング」を参照してください。
コンテナ管理によるトランザクションの分離レベルは、weblogic-ejb-jar.xmlのtransaction-isolation要素のisolation-level下位要素で設定します。WebLogic Serverは、この値を基底のデータベースに渡します。トランザクションの動作は、EJBの分離レベル設定と、基底となる永続ストレージの同時実行性制御に依存します。
コンテナ管理トランザクションの分離レベルの設定については、『Oracle WebLogic Server JTAのプログラミング』を参照してください。
WebLogic Serverは、アプリケーションの要件を満たすために構成できる、エンタープライズBeanの様々な付加価値機能を提供します。それらの機能の詳細は、「WebLogic ServerのEJBの付加価値機能」を参照してください。
表3-2に、アプリケーションの要件と、それらを満たすために使用できる設計方式およびWebLogic Serverの機能を示します。
