WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド
|
 |
 |
|
以下の節では、エンタープライズ JavaBean (EJB) の異なるタイプ、それらのタイプがアプリケーションで提供する機能を概説し、それらが他のアプリケーション オブジェクトや WebLogic Server とどのように機能するのかについて説明します。
この章は、Java のプログラミングおよび EJB 2.0 の概念と機能に精通している読者を対象としています。
以降の節では、各 Bean タイプの目的と機能について説明します。
セッション Bean は、ビジネス ロジックを実装します。セッション Bean インスタンスは、一度に 1 つのクライアントにサービスを提供します。セッション Bean には、2 つのタイプ (ステートフルとステートレス) があります。
ステートレス セッション Bean は、呼び出し間でセッションやクライアントの状態の情報を格納しません。唯一格納されることのある状態はクライアントに固有のものではなく、キャッシュされたデータベース接続や別の EJB の参照などです。ステートレス セッション Bean が状態を格納できるのは、長くてメソッド呼び出しの期間だけです。メソッドが完了すると、状態情報は維持されません。ステートレス セッション Bean のインスタンスはすべて、どのクライアントにもサービスを提供できます (どのインスタンスも機能は同じ)。ステートレス セッション Bean は、ステートフル セッション Bean よりもパフォーマンスが優れています。その理由は、各ステートレス セッション Bean が複数のクライアントをサポートできるからです (ただし 1 度に 1 つ)。
例 : 訪問者が「お問い合わせ」リンクをクリックして電子メール送信できるインターネット アプリケーションでは、ステートレス セッション Bean を使用して、JSP によってユーザから収集された送信先と送信元の情報に基づいて電子メールを生成できます。
ステートフル セッション Bean は、特定のクライアントとの対話を反映する状態情報をメソッドやトランザクションをまたがって維持します。ステートフル セッション Bean は、クライアントと他のエンタープライズ Bean の対話を管理するか、ワークフローを管理できます。
例 : 社員が個人のプロファイル情報を表示して更新できる、ある会社の Web サイトでは、ステートフル セッション Bean を使用してさまざまな他の 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 は各タイプの 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 を指定できます。詳細については、「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」を参照してください。weblogic-cmp-jar.xml - エンティティ Bean のコンテナ管理による永続性に関連する要素を格納する WebLogic Server 固有のデプロイメント記述子。コンテナ管理による永続性を使用するエンティティ Bean は、weblogic-cmp-jar.xml ファイルで指定する必要があります。詳細については、「weblogic-cmp-jar.xml デプロイメント記述子のリファレンス」を参照してください。「EJB デプロイメント記述子」で説明されているように、WebLogic Server EJB の実行時の動作は、3 つの異なるデプロイメント記述子ファイル ejb-jar.xml、weblogic-ejb-jar.xml、および weblogic-cmp-jar.xml の要素で制御できます。
表 2-2 は、各記述子ファイルで値が一致しなければならない要素のリストです。表中の要素は、「Bean とリソースのリファレンス」と「セキュリティ ロール」で定義されています。
|
|
|||
各記述子ファイルは、Bean とその Bean が使用する実行時ファクトリ リソースを識別する要素を格納します。
ejb-name - 各デプロイメント記述子ファイルで Bean を識別するために使用する名前。Bean の参照にアプリケーション コードで使用する名前とは関係ありません。 ejb-ref-name - 別の .jar にある Bean が参照元 Bean のコードで表される名前。res-ref-name - リソース ファクトリが参照元 Bean のコードで表される名前。特定の Bean またはリソース ファクトリは、それを格納する各記述子ファイルで同じ値で識別されます。表 2-2 は、Bean とリソースの参照要素およびそれらの各記述子ファイルでの位置を示しています。
たとえば、LineItem という名前のコンテナ管理による永続性エンティティ Bean の場合、次の行、
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-jar.xml の要素については、http://www.java.sun.com/dtd/ejb-jar_2_0.dtd を参照 weblogic-ejb-jar.xml の要素については、「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」を参照 weblogic-cmp-jar.xml の要素については、「weblogic-cmp-jar.xml デプロイメント記述子のリファレンス」を参照
図 2-1 は、EJB が WebLogic Server アプリケーションの他のコンポーネントやクライアントと通常どのように関わるのかを示しています
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 は、以下のプロトコルを使用します。
リモート インタフェースのある EJB は RMI オブジェクトです。EJB のリモート インタフェースは、java.rmi.remote を拡張します。WebLogic RMI の詳細については、『WebLogic RMI プログラマーズ ガイド』を参照してください。
java.net.URL リソース接続ファクトリを使用して WebLogic Server 環境外の Web サーバとの HTTP 接続を取得できます。詳細については、「URL にリクエストを送信するように EJB をコンフィグレーションする」を参照してください。
この節では、EJB の開発プロセスを容易にしたり、EJB アプリケーションのパフォーマンス、信頼性、および可用性を拡張する主要な WebLogic Server の機能について説明します。
WebLogic Server は、EJB の応答時間とパフォーマンスを向上させるプールやキャッシングなどの機能をサポートしています。プロダクション環境では、それらの機能により、クライアントが EJB インスタンスを取得したり、永続データにアクセスしてそれを保持したりするのに要する時間を短縮できます。
Weblogic Server は、ステートレス セッション Bean、メッセージ駆動型 Bean、およびエンティティ Bean のすぐに使えるよう準備された EJB インスタンスのフリー プールを保持します。その EJB コンテナはコンフィグレーションされた数の Bean インスタンスを起動時に作成するので、リクエストごとに新しいインスタンスを作成する必要はありません。クライアントで EJB インスタンスが不要になると、コンテナはそれを再利用できるようにプールに返します。詳細については、以下を参照してください。
WebLogic Server は、ステートフル セッション Bean とエンティティ Bean のキャッシングをサポートしています。
キャッシュされている非アクティブな Bean インスタンスはパッシベーションでき (キャッシュから削除されてディスクに書き込まれる)、必要に応じて後でメモリに復元できます。Bean インスタンスをパッシベーションすると、システム リソースの使用が最適化されます。
キャッシュのサイズ、およびキャッシュから Bean を削除するルールなどの関連動作をコンフィグレーションすることができます。コンテナ管理の永続性と Bean 管理の永続性のどちらを使用するかに関係なく、エンティティ EJB ではキャッシングがサポートされています。
コンテナ管理の永続性を使用する EJB 用の、追加的なキャッシング機能も用意されています。詳細については、次の節を参照してください。
WebLogic Server は、コンテナ管理による永続性を使用するエンティティ Bean 向けに以下のキャッシング機能を提供します。
グループは、エンティティ Bean の一連の永続属性を指定します。field-group は、Bean のコンテナ管理による永続性 (CMP) フィールドとコンテナ管理による関係 (CMR) フィールドのサブセットを表します。Bean 内の関連フィールドを、障害のあったグループにまとめて 1 つのユニットとしてメモリ内に入れることができます。グループをクエリまたは関係に関連付けることができます。それによって、クエリを実行するか、または関係に従った結果として Bean がロードされたときに、グループ内の指定フィールドのみがロードされます。詳細については、「フィールド グループの指定」を参照してください。
ejbLoad() メソッドと ejbStore() メソッドは、ejbStore() の不要な呼び出しを防止してパフォーマンスを上げるようにコンフィグレーションできます。必要に応じて、ejbStore() がトランザクションの終わりにではなく各メソッド呼び出しの後に WebLogic Server から呼び出されるようにすることができます。詳細については、「ejbLoad() と ejbStore() の動作について」を参照してください。
WebLogic Server では、1 回のデータベース アクセスで完了できるように複数のデータベース処理をバッチ処理および順序付けできます。この機能を利用すると、複数のエンティティ インスタンスが 1 つのトランザクションから影響を受ける場合に起こる可能性のあるボトルネックを避けることができます。詳細については、「処理の順序付けとバッチ処理」を参照してください。
WebLogic Server 8.1 SP01 以降の 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-3 は、各 EJB タイプのロード バランシングとフェイルオーバのサポートをまとめたものです (メソッド レベルとホーム レベル)。
Bean スタブは、オブジェクトに対するメソッド呼び出しを負荷分散するためのロード バランシング アルゴリズム (呼び出しルーティング クラス) を備えています。呼び出しが行われるたびに、スタブではそのロード アルゴリズムを利用して呼び出すレプリカを選択できます。
WebLogic Server クラスタは、クラスタ化された EJB のロード バランシングを行う複数のアルゴリズムをサポートしています。デフォルトはラウンドロビン方式です。詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタでのロード バランシング」を参照してください。
すべての Bean タイプが、ホーム レベルのロード バランシングをサポートしています。メソッド レベルのロード バランシングは、読み書き対応エンティティ Bean を除くすべての Bean タイプでサポートされています。
注意 : WebLogic Server では、オブジェクトのメソッド呼び出しに対して常にロード バランシングが実行されるわけではありません。ほとんどの場合は、リモート サーバにあるレプリカを使用するよりも、スタブ自体と連結しているレプリカを使用する方が効率的です。
EJB のフェイルオーバは、EJBHome スタブまたはサポートされている場合は EJBObject スタブを使用して実現します。クライアントがスタブを通じて障害が発生したサービスに対して呼び出しを行うと、スタブはその障害を検出し、別のレプリカに対してその呼び出しを再試行します。
EJB のフェイルオーバでは、Bean のメソッドが多重呼び出し不変で、weblogic-ejb-jar.xml でそのようにコンフィグレーションされている必要があります。詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「EJB と RMI のレプリケーションとフェイルオーバ」を参照してください。
表 2-3 は、クラスタ化された EJB のフェイルオーバおよびロード バランシング機能の要約です。
表 2-3 クラスタ化された EJB のフェイルオーバとロード バランシング
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
詳細については、『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 の詳細については、以下を参照してください。
|
|
|