| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > Tuxedo CORBA サーバ・アプリケーションの開発方法 > Basic CORBA サーバ・アプリケーションの設計とインプリメント |
|
Tuxedo CORBA サーバ・アプリケーションの開発方法
|
Basic CORBA サーバ・アプリケーションの設計とインプリメント
この章では、Basic University サンプル・アプリケーションを例として使用して、CORBA サーバ・アプリケーションを設計およびインプリメントする方法について説明します。この章の内容は、インプリメントするアプリケーションの設計が完了し、OMG IDL に定義されていることを前提にしています。この章では、サーバ・アプリケーション向けの設計およびインプリメンテーションの選択肢に焦点を当てます。
ここでは、以下の内容について説明します。
Basic University サンプル・アプリケーションのしくみ
Basic University サンプル・アプリケーションを使用すると、学生は中央の University データベースからコース情報を参照できます。この Basic サンプル・アプリケーションでは、学生は次のことを行うことができます。
Basic University サンプル・アプリケーションの OMG IDL
Basic University サンプル・アプリケーションの OMG IDL ファイルには、次のインターフェイスが定義されます。
図3-1 に、Basic University サンプル・アプリケーションを示します。 図 3-1 Basic University サンプル・アプリケーション
Basic University サンプル・アプリケーションで何が発生するかを説明するために、次のイベント・グループについて説明します。
アプリケーションの起動
次に、Basic クライアント・アプリケーションおよびサーバ・アプリケーションが起動し、クライアント・アプリケーションが Registrar オブジェクトのオブジェクト・リファレンスを取得するときに行われる一般的な一連のイベントを示します。
コース概要の参照
次に、学生がコース概要のリストを参照するときに発生する一連のイベントを順番に示します。
コース詳細の参照
次に、クライアント・アプリケーションがコース詳細を参照するときに行われる一連のイベントを示します。
University サーバ・アプリケーションの設計上の考慮事項
Basic University サンプル・アプリケーションには、University サーバ・アプリケーションが含まれます。このサーバ・アプリケーションは、CORBA サーバ・アプリケーションの基本的な設計問題を処理します。この節では、以下のトピックについて説明します。
この節では、さらに次の 2 つのトピックについても説明します。
オブジェクト・リファレンスの生成に関する設計上の考慮事項
Basic クライアント・アプリケーションでは、University サーバ・アプリケーションによって管理される次のオブジェクトのリファレンスが必要です。
次の表に、これらのリファレンスがどのように生成されて返されるかを示します。
University サーバ・アプリケーションがオブジェクト・リファレンスを生成する方法について、以下のことに注意してください。
オブジェクト状態の管理に関する設計上の考慮事項
Basic サンプル・アプリケーションの 3 つのオブジェクトには、それぞれ独自の状態管理の要件が存在します。この節では、それぞれのオブジェクト状態管理の要件について説明します。
RegistrarFactory オブジェクト
RegistrarFactory オブジェクトは、特定のクライアント要求に一意なものである必要はありません。また、このオブジェクトをメモリに保持しておき、クライアント呼び出しごとにこのオブジェクトを活性化および非活性化する負担を回避することは合理的です。したがって、RegistrarFactory オブジェクトには process 活性化方針が割り当てられます。
Registrar オブジェクト
Basic サンプル・アプリケーションは、小規模な環境へのデプロイに適しています。Registrar オブジェクトは、RegistrarFactory オブジェクトに似た特性を備えています。つまり、このオブジェクトは特定のクライアント要求に一意なものである必要がありません。また、呼び出しごとにこのオブジェクトを活性化および非活性化する負担を回避することは合理的です。したがって、Basic サンプル・アプリケーションでは、Registrar オブジェクトには process 活性化方針が割り当てられます。
CourseSynopsisEnumerator オブジェクト
University サーバ・アプリケーションの基本的な設計上の問題は、大きすぎて 1 回の応答ではクライアント・アプリケーションに返すことができないコース概要リストをどのように処理するかです。したがって、この問題の解決策は、次のことが中心となります。
University サーバ・アプリケーションは、この解決策をインプリメントする CourseSynopsisEnumerator オブジェクトを備えています。このオブジェクトは最初に呼び出されたときに最初の概要リストを返しますが、その後もメモリ内コンテキストに保持されるので、クライアント・アプリケーションは後続の要求で概要の残りを取得できます。メモリ内コンテキストを保持するには、CourseSynopsisEnumerator オブジェクトは状態を持たなければなりません。つまり、このオブジェクトは複数のクライアント呼び出しにわたってメモリ内に常駐します。
クライアントが CourseSynopsisEnumerator オブジェクトとの会話を終了するときに、このオブジェクトにはメモリからフラッシュされるための手段が必要です。このため、CourseSynopsisEnumerator オブジェクトの適切な状態管理の方法は、process 活性化方針を割り当て、CORBA アプリケーション制御の非活性化機能をインプリメントすることです。
アプリケーション制御の非活性化は、そのオブジェクトの destroy() オペレーションによってインプリメントされます。
次のコード例に、CourseSynopsisEnumerator オブジェクトの destroy() オペレーションを示します。
void CourseSynopsisEnumerator_i::destroy()
{
// クライアントが列挙子の「破棄」を呼び出すと、
// このオブジェクトは「消滅」する必要がある。
// そのためには、TP フレームワークに
// このオブジェクトとの会話が完了したことを通知する
TP::deactivateEnable();
}
Basic University サンプル・アプリケーションの ICF ファイル
次のコード例に、Basic サンプル・アプリケーション用の ICF ファイルを示します。
module POA_UniversityB
{
implementation CourseSynopsisEnumerator_i
{
activation_policy ( process );
transaction_policy ( optional );
implements ( UniversityB::CourseSynopsisEnumerator );
};
implementation Registrar_i
{
activation_policy ( process );
transaction_policy ( optional );
implements ( UniversityB::Registrar );
};
implementation RegistrarFactory_i
{
activation_policy ( process );
transaction_policy ( optional );
implements ( UniversityB::RegistrarFactory );
};
};
永続状態情報の処理に関する設計上の考慮事項
永続状態情報の処理とは、オブジェクトの活性化中または活性化後のある時点でディスクから永続状態情報を読み取り、必要な場合、非活性化中または非活性化後のある時点でそれを書き込むことです。Basic サンプル・アプリケーションでは、次の 2 つのオブジェクトが永続状態情報を処理します。
以降の 2 つの節では、この 2 つのオブジェクトが永続状態情報を処理する方法に関する設計上の考慮事項を説明します。
Registrar オブジェクト
Registrar オブジェクトのオペレーションの 1 つによって、クライアント・アプリケーションにコース情報の詳細が返されます。一般的なシナリオでは、数多くのコース概要を参照した学生は、通常 2 つか 3 つのコースに関する詳細情報を一度に参照しようとします。
このシナリオを効率的にインプリメントするために、Registrar オブジェクトには get_course_details() オペレーションが定義されています。このオペレーションは、コース番号のリストを指定するパラメータを入力として受け付けます。次にこのオペレーションは、データベースからコースの詳細を検索し、その詳細をクライアント・アプリケーションに返します。このオペレーションがインプリメントされるオブジェクトはプロセス・バウンドなので、このオペレーションはその呼び出しの完了後に状態データをメモリに保持するのを避ける必要があります。
Registrar オブジェクトは、永続状態をメモリに保持しません。クライアント・アプリケーションが get_course_details() オペレーションを呼び出すと、このオブジェクトは関連するコース情報を University データベースからフェッチしてクライアントに送信します。このオブジェクトは、コース・データをメモリ内に保持しません。このオブジェクトの activate_object() オペレーションと deactivate_object() オペレーションでは永続状態は処理されません。
CourseSynopsisEnumerator オブジェクト
CourseSynopsisEnumerator オブジェクトは、自身が University データベースから検索するコース概要を処理します。状態処理に関する設計上の考慮事項は、ディスクから状態を読み取る方法です。このオブジェクトは、状態をディスクに書き込みません。
CourseSynopsisEnumerator オブジェクトの機能には、次の 3 つの重要な側面があります。これらの側面は、このオブジェクトがその永続状態を読み取る方法に影響を与えます。
この 3 つの側面を考えたとき、このオブジェクトでは次のことを行うのが合理的です。
したがって、CourseSynopsisEnumerator オブジェクトが活性化されるときに、そのオブジェクトの activate_object() オペレーションは次のことを行います。
注記 オブジェクトの Tobj_ServantBase::activate_object() オペレーションまたは Tobj_ServantBase::deactivate_object() オペレーションをインプリメントする場合は、インプリメンテーション・ヘッダ・ファイル (つまり、application_i.h ファイル) を編集し、これらのオペレーションの定義をそのオブジェクトのインターフェイスのクラス定義テンプレートに追加してください。
University データベースの使い方
University サンプル・アプリケーションが University データベースを使用する方法について、次のことに注意してください。
注記 Wrapper および Production サンプル・アプリケーションの BEA Tuxedo Teller アプリケーションは、University データベース内の口座情報に直接アクセスし、samplesdb.h ファイルを使用しません。
Basic サーバ・アプリケーションに組み込むファイルの詳細については、『BEA Tuxedo CORBA University サンプル・アプリケーション』を参照してください。
Basic サンプル・アプリケーションがデザイン・パターンを適用する方法
Basic サンプル・アプリケーションは、次のデザイン・パターンを使用します。
この節では、この 2 つのデザイン・パターンが Basic サンプル・アプリケーションに適している理由と、Basic サンプル・アプリケーションがこれらのパターンをインプリメントする方法について説明します。
Process-Entity デザイン・パターン
第 1 章の 30 ページ「Process-Entity デザイン・パターン」で説明したように、このデザイン・パターンは、クライアント・アプリケーションによって必要とされるデータ・エンティティを処理する 1 つのプロセス・オブジェクトが存在する場合に適しています。データ・エンティティは、クライアント・アプリケーションではなくこのプロセス・オブジェクトによって操作される CORBA struct としてカプセル化されます。
Process-Entity デザイン・パターンを Basic サンプル・アプリケーションに適用すると、Basic サンプル・アプリケーションは細粒度オブジェクトのインプリメントを回避できます。たとえば、Registrar オブジェクトは、同じような多数のコース・オブジェクト・セットの有効な代替となります。単一の粗粒度 Registrar オブジェクトを管理する負荷は、何百、何千もの細粒度のコース・オブジェクトを管理する負荷に比べれば、それほど大きくはありません。
Process-Entity デザイン・パターンの詳細については、『デザイン・パターンに関する技術情報』を参照してください。
List-Enumerator デザイン・パターン
このデザイン・パターンは、大きすぎて 1 つの応答でクライアント・アプリケーションに返すことができないデータの内部リストをオブジェクトが生成した場合に適しています。このため、オブジェクトは 1 回の応答で最初のデータ・リストをクライアント・アプリケーションに返し、後続の応答で残りのデータを返すことができなければなりません。
また、List-Enumerator オブジェクトは、既に返されたデータの量を同時に追跡して、後続のリストを正確に返すことができるようにする必要があります。List-Enumerator オブジェクトは常に状態を持ち (クライアント呼び出しにまたがって活性化され、メモリに常駐する)、サーバ・アプリケーションはそれらが不要になったときにそれらを非活性化できます。
List-Enumerator デザイン・パターンは、CourseSynopsisEnumerator オブジェクトに最適です。このデザイン・パターンをインプリメントすると、次のメリットが得られます。
このため、後続のすべての呼び出しは適切な CourseSynopsisEnumerator オブジェクトに対して行われます。これは、サーバ・プロセスに CourseSynopsisEnumerator クラスのアクティブ・インスタンスが複数存在する場合に重要です。
get_courses_synopsis() オペレーションは一意の CourseSynopsisEnumerator オブジェクト・リファレンスを返すので、クライアント要求どうしが衝突することはありません。つまり、クライアント要求が間違った CourseSynopsisEnumerator オブジェクトに誤って送られることはありません。
Registrar オブジェクトは get_courses_synopsis() オペレーションを備えていますが、データベース問い合わせと概要リストの知識はすべて CourseSynopsisEnumerator オブジェクトに埋め込まれます。この場合、Registrar オブジェクトは単にクライアントが次のデータを取得するための手段として機能します。
BEA Tuxedo システムに組み込まれた性能効率化
BEA Tuxedo システムは、同じサーバ・プロセス内の 2 つのオブジェクト間のデータ・マーシャリングを自動的に無効化することによって、性能の効率化を実現します。この効率化は、次の環境が存在するときに得られます。
この例には、Registrar オブジェクトが CourseSynopsisEnumerator オブジェクトのオブジェクト・リファレンスを作成し、それによってそのオブジェクトがインスタンス化された場合などがあります。この 2 つのオブジェクト間の要求と応答では、データ・マーシャリングは行われません。
状態を持つオブジェクトの事前活性化
状態を持つオブジェクトの事前活性化機能を使用すると、クライアント・アプリケーションがオブジェクトを呼び出す前にそのオブジェクトを活性化できます。この機能は、University サンプルの CourseSynopsisEnumerator オブジェクトなどのイテレータ・オブジェクトを作成するときに特に役立ちます。
状態を持つオブジェクトの事前活性化では、TP::create_active_object_reference() オペレーションを使用します。通常、クライアントがあるオブジェクトに対する呼び出しを発行するまで、CORBA サーバ・アプリケーションでそのオブジェクトは作成されません。ただし、オブジェクトを事前活性化し、TP::create_active_object_reference() オペレーションを使用してそのオブジェクトのリファレンスをクライアントに受け渡すことによって、クライアント・アプリケーションは既に活性化され、状態を持っているオブジェクトを呼び出すことができます。
注記 状態を持つオブジェクトの事前活性化の機能は、WebLogic Enterprise バージョン 4.2 で最初に導入されました。
状態を持つオブジェクトを事前活性化する方法
事前活性化の機能を使用するためのプロセスは、サーバ・アプリケーションに次のコードを記述することです。
このように、事前活性化オブジェクトは、TP フレームワークがそのオブジェクトの Server::create_servant() オペレーションと Tobj_ServantBase::activate_object() オペレーションを呼び出さずに作成されます。
事前活性化オブジェクトの使い方に関する注意
事前活性化機能を使用するときには、以下のことに注意してください。
ある一時オブジェクト・リファレンスが作成されたプロセスのシャットダウン後にクライアント・アプリケーションがそのオブジェクト・リファレンスを呼び出した場合、TP フレームワークは次の例外を返します。
CORBA::OBJECT_NOT_EXIST
サーバがクラッシュし、そのときに削除されたオブジェクトをクライアント・アプリケーションが呼び出そうとする状況を回避するには、事前活性化されるオブジェクトに対する Tobj_ServantBase::activate_object() オペレーションのインプリメンテーションに TobjS::ActivateObjectFailed 例外を追加します。クライアントがサーバ・クラッシュ後にこのようなオブジェクトを呼び出そうとし、TP フレームワークがそのオブジェクトの Tobj_ServantBase::activate_object() オペレーションを呼び出した場合、TP フレームワークはクライアント・アプリケーションに次の例外を返します。
CORBA::OBJECT_NOT_EXIST
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
