Basic CORBAサーバー・アプリケーションの設計と実装

この章では、Basic Universityサンプル・アプリケーションを例として使用して、CORBAサーバー・アプリケーションの設計および実装方法について説明します。この章の内容は、実装するアプリケーションの設計が完了しており、OMG IDLで表現されていることが前提となっています。この章では、サーバー・アプリケーション向けの設計および実装の選択肢に焦点を当てています。

このトピックには次の項が含まれます:

•	Basic Universityサンプル・アプリケーションのしくみ。このトピックでは、設計と実装の考慮事項について説明します

•	Universityサーバー・アプリケーションの設計上の考慮事項。このトピックでは、次のトピックについて包括的に説明します。

•	オブジェクト参照の生成に関する設計上の考慮事項

•	オブジェクト状態の管理に関する設計上の考慮事項

•	永続状態情報の処理に関する設計上の考慮事項

•	Basicサンプル・アプリケーションがデザイン・パターンを適用する方法

•	Oracle Tuxedoシステムに組み込まれたパフォーマンス効率化

•	状態を持つオブジェクトの事前アクティブ化

Basic Universityサンプル・アプリケーションのしくみ

Basic Universityサンプル・アプリケーションを使用すると、学生は中央のUniversityデータベースからコース情報を参照できます。学生はBasicサンプル・アプリケーションを使用して、次の処理を行うことができます。

•	検索文字列を指定して、データベースからコース概要を参照します。サーバー・アプリケーションによって、タイトル、教授または説明に検索文字列が含まれるすべてのコースの概要が返されます。(クライアント・アプリケーションに返されるコース概要には、コース番号とタイトルのみが含まれます。)

•	特定のコースの詳細情報を表示します。指定したコースの詳細情報には、コース概要の他に次の情報が含まれます。

•

コスト

•

履修単位

•	クラス・スケジュール

•

座席数

•

登録学生数

•

教授

•

説明

Basic Universityサンプル・アプリケーションのOMG IDL

Basic Universityサンプル・アプリケーションのOMG IDLファイルには、次のインタフェースが定義されます。

 

インタフェース	説明	操作
RegistrarFactory	Registrarオブジェクトへのオブジェクト参照を作成します	find_registrar()
Registrar	データベースからコース情報を取得します。	get_courses_synopsis() get_courses_details()
CourseSynopsisEnumerator	検索基準に一致するコースの概要をデータベースからフェッチして、それらをメモリーに読み込みます。	get_next_n() destroy()

図3-1に、Basic Universityサンプル・アプリケーションを示します。

図3-1 Basic Universityサンプル・アプリケーション

Basic Universityサンプル・アプリケーションで何が発生するかを説明するために、次のイベント・グループについて説明します。

•	アプリケーションの起動 - サーバー・アプリケーションが起動し、クライアント・アプリケーションがRegistrarオブジェクトのオブジェクト参照を取得するとき

•	コース概要の参照 - クライアント・アプリケーションがリクエストを送信してコース概要を参照するとき。

•	コース詳細の参照 - クライアント・アプリケーションがリクエストを送信して特定のコース・リストの詳細を参照するとき。

アプリケーションの起動

次に、Basicクライアント・アプリケーションおよびサーバー・アプリケーションが起動し、クライアント・アプリケーションがRegistrarオブジェクトのオブジェクト参照を取得するときに行われる一般的な一連のイベントを示します。

1.	Basicクライアント・アプリケーションおよびサーバー・アプリケーションが起動し、クライアント・アプリケーションはFactoryFinderからRegistrarFactoryオブジェクトのオブジェクト参照を取得します。

2.	RegistrarFactoryオブジェクトの参照を使用して、クライアント・アプリケーションはRegistrarFactoryオブジェクトのfind_registrar()操作を呼び出します。

3.	RegistrarFactoryオブジェクトはメモリー内に存在しません(このオブジェクトに対するリクエストが以前にサーバー・プロセスに到着していないため)。このため、TPフレームワークはサーバー・オブジェクトのServer::create_servant()操作を呼び出してRegistrarFactoryオブジェクトをインスタンス化します。

4.	インスタンス化が済んだら、RegistrarFactoryオブジェクトのfind_registrar()操作が呼び出されます。RegistrarFactoryオブジェクトは、Registrarのオブジェクト参照を作成してクライアント・アプリケーションに戻します。

コース概要の参照

次に、学生がコース概要のリストを参照するときに発生する一連のイベントを順番に示します。

1.	Registrarオブジェクトのオブジェクト参照を使用して、クライアント・アプリケーションはget_courses_synopsis()操作を呼び出し、次のものを指定します。

•	データベースからコース概要を検索するための検索文字列

•	変数number_to_getで表され、返される概要リストのサイズを指定する整数。

2.	Registrarオブジェクトはメモリー内に存在しないため(このオブジェクトに対するリクエストが以前にサーバー・プロセスに到着していないため)、TPフレームワークはサーバー・オブジェクトに実装されているServer::create_servant()操作を呼び出します。これにより、Registrarオブジェクトがサーバー・マシンのメモリー内にインスタンス化されます。

3.	Registrarオブジェクトはクライアント・リクエストを受信し、CourseSynopsisEnumeratorオブジェクトのオブジェクト参照を作成します。CourseSynopsisEnumeratorオブジェクトは、データベースからコース概要をフェッチするためにRegistrarオブジェクトによって呼び出されます。

CourseSynopsisEnumeratorオブジェクトのオブジェクト参照を作成するために、Registrarオブジェクトは次の処理を実行します。

a.	CourseSynopsisEnumeratorオブジェクトの一意のIDを生成します。

b.	CourseSynopsisEnumeratorオブジェクトのオブジェクトIDを生成します。このIDは、前のステップで生成された一意のIDとクライアントによって指定された検索文字列を連結したものです。

c.	CourseSynopsisEnumeratorオブジェクトのインタフェース・リポジトリIDをそのインタフェース・タイプ・コードから取得します。

d.	TP::create_object_reference()操作を呼び出します。この操作により、最初のクライアント・リクエストに必要なCourseSynopsisEnumeratorオブジェクトのオブジェクト参照が作成されます。

4.	前のステップで作成したオブジェクト参照を使用して、RegistrarオブジェクトはCourseSynopsisEnumeratorオブジェクトに対するget_next_n()操作を呼び出して、リスト・サイズを渡します。ステップ1で説明したように、このリスト・サイズはパラメータnumber_to_getによって表されます。

5.	TPフレームワークは、サーバー・オブジェクトのServer::create_servant()操作を呼び出して、CourseSynopsisEnumeratorオブジェクトをインスタンス化します。

6.	TPフレームワークは、CourseSynopsisEnumeratorオブジェクトのactivate_object()操作を呼び出します。この操作は、次の2つのことを行います。

•	そのOIDから検索基準を抽出します。

•	その検索基準を使用して、一致するコース概要をデータベースからフェッチし、それらをサーバー・マシンのメモリーに読み込みます。

7.	CourseSynopsisEnumeratorオブジェクトは、Registrarオブジェクトに次の情報を返します。

•	戻り値のCourseSynopsisListに指定されるコース概要リスト。これは、最初のコース概要リストを含むsequenceです。

•	検索基準に一致するが、まだ返されていないコース概要の数。これは、number_remainingパラメータによって指定されます。

8.	Registrarオブジェクトは、クライアント・アプリケーションにCourseSynopsisEnumeratorオブジェクト参照を返します。また、そのオブジェクトから取得した次の情報も返します。

•	最初のコース概要リスト

•	number_remaining変数

(number_remaining変数が0の場合、RegistrarオブジェクトはCourseSynopsisEnumeratorオブジェクトのdestroy()操作を呼び出し、クライアント・アプリケーションにnil参照を返します。)

9.	クライアント・アプリケーションは、一致する次の概要リストを取得するためのリクエストを直接CourseSynopsisEnumeratorオブジェクトに送信します。

10.	CourseSynopsisEnumeratorオブジェクトはそのクライアント・リクエストを満たすとともに、更新したnumber_remaining変数を返します。

11.	クライアント・アプリケーションは、CourseSynopsisEnumeratorオブジェクトとのやり取りを終了すると、CourseSynopsisEnumeratorオブジェクトに対してdestroy()操作を呼び出します。この結果、CourseSynopsisEnumeratorオブジェクトはTP::deactivateEnable()操作を呼び出します。

12.	TPフレームワークは、CourseSynopsisEnumeratorオブジェクトのdeactivate_object()操作を呼び出します。この結果、CourseSynopsisEnumeratorオブジェクトが保持しているコース概要のリストがサーバー・コンピュータのメモリーから削除されるため、CourseSynopsisEnumeratorオブジェクトのサーバントを別のクライアント・リクエストのために再利用できるようになります。

コース詳細の参照

次に、クライアント・アプリケーションがコース詳細を参照するときに行われる一連のイベントを示します。

1.	学生は、詳細を参照したいコースのコース番号を入力します。

2.	クライアント・アプリケーションは、Registrarオブジェクトのget_course_details()操作を呼び出し、コース番号のリストを受け渡します。

3.	Registrarオブジェクトは、一致するコース番号をデータベースから検索し、指定された各コースの詳細を含んだリストを返します。このリストは、コース全体の詳細を含んだ一連のstructであるCourseDetailsList変数に格納されます。

Universityサーバー・アプリケーションの設計上の考慮事項

Basic Universityサンプル・アプリケーションには、Universityサーバー・アプリケーションが含まれます。このサーバー・アプリケーションは、CORBAサーバー・アプリケーションの基本的な設計問題を処理します。この項のトピックは次のとおりです。

•	オブジェクト参照の生成に関する設計上の考慮事項

•	オブジェクト状態の管理に関する設計上の考慮事項

•	永続状態情報の処理に関する設計上の考慮事項

•	Basicサンプル・アプリケーションがデザイン・パターンを適用する方法

この項では、さらに次の2つのトピックについても説明します。

•	Oracle Tuxedoシステムに組み込まれたパフォーマンス効率化

•	状態を持つオブジェクトの事前アクティブ化

オブジェクト参照の生成に関する設計上の考慮事項

Basicクライアント・アプリケーションでは、Universityサーバー・アプリケーションによって管理される次のオブジェクトの参照が必要です。

•	RegistrarFactoryオブジェクト

•	Registrarオブジェクト

•	CourseSynopsisEnumeratorオブジェクト

次の表に、これらの参照がどのように生成されて返されるかを示します。

 

オブジェクト	オブジェクト参照が 生成されて返されるしくみ
RegistrarFactory	RegistrarFactoryオブジェクトのオブジェクト参照は、RegistrarFactoryオブジェクトをFactoryFinderに登録するサーバー・オブジェクトで生成されます。クライアント・アプリケーションは、RegistrarFactoryオブジェクトへの参照をFactoryFinderから取得します。 Basic Universityサーバー・アプリケーション・プロセスには、RegistrarFactoryオブジェクトは1つしか存在しません。
Registrar	Registrarオブジェクトのオブジェクト参照は、RegistrarFactoryオブジェクトによって作成され、クライアント・アプリケーションがfind_registrar()操作を呼び出したときに返されます。Registrarオブジェクト用に作成されたオブジェクト参照は常に同一です。このオブジェクト参照には一意のOIDが含まれません。 Basic Universityサーバー・アプリケーション・プロセスには、Registrarオブジェクトは1つしか存在しません。
CourseSynopsisEnumerator	CourseSynopsisEnumeratorオブジェクトのオブジェクト参照は、クライアント・アプリケーションがget_courses_synopsis()操作を呼び出したときにRegistrarオブジェクトによって作成されます。つまり、RegistrarオブジェクトはCourseSynopsisEnumeratorオブジェクトのファクトリです。CourseSynopsisEnumeratorオブジェクトの設計と使い方については、この章で後述します。 Basic Universityサーバー・アプリケーション・プロセスには、任意の数のCourseSynopsisEnumeratorオブジェクトが存在できます。

Universityサーバー・アプリケーションがオブジェクト参照を生成する方法について、以下のことに注意してください。

•	サーバー・オブジェクトは、RegistrarFactoryオブジェクトをFactoryFinderに登録します。この方法により、クライアント・アプリケーションはサーバー・アプリケーション内の基本オブジェクトのオブジェクト参照を取得するために必要なファクトリを検索できます。

•	Registrarオブジェクトのオブジェクト参照は、RegistrarFactoryオブジェクトによって作成されます。これは、クライアント・アプリケーションにオブジェクト参照を返すためのきわめて一般的かつ基本的な方法を示します。つまり、クライアント・アプリケーションがビジネス・ロジックを実行するために必要な基本オブジェクトの参照を作成して返すための専用ファクトリが存在するということです。

•	CourseSynopsisEnumeratorオブジェクトへのオブジェクト参照は、登録されているファクトリの外部で作成されます。Universityサンプル・アプリケーションでは、CourseSynopsisEnumeratorオブジェクトが使用されるのに適しているため、ファクトリ外部での作成は優れた設計となります。つまり、その存在が特定のクライアント・アプリケーション操作に固有となります。CourseSynopsisEnumeratorオブジェクトは固有のリストと、その他の問合せからの結果とは関連性のない結果を返します。

•	Registrarオブジェクトは、操作の一環として別のオブジェクトへのオブジェクト参照を作成するため、Registrarオブジェクトはファクトリとなります。ただし、RegistrarオブジェクトはFactoryFinderを持つファクトリとして登録されません。そのため、クライアント・アプリケーションはRegistrarオブジェクトへの参照をFactoryFinderから取得できません。

オブジェクト状態の管理に関する設計上の考慮事項

Basicサンプル・アプリケーションの3つのオブジェクトには、それぞれ独自の状態管理の要件が存在します。この項では、それぞれのオブジェクト状態管理の要件について説明します。

RegistrarFactoryオブジェクト

RegistrarFactoryオブジェクトは、特定のクライアント・リクエストに対して一意である必要はありません。また、このオブジェクトをメモリーに保持しておき、クライアント呼出しごとにこのオブジェクトをアクティブ化および非アクティブ化する負担を回避することは合理的です。したがって、RegistrarFactoryオブジェクトにはprocessアクティブ化ポリシーが割り当てられます。

Registrarオブジェクト

Basicサンプル・アプリケーションは、小規模環境でのデプロイを目的としています。Registrarオブジェクトは、RegistrarFactoryオブジェクトに似た特性を多数備えています。つまり、このオブジェクトは特定のクライアント・リクエストに一意である必要はありません。また、呼出しのたびにオブジェクトのアクティブ化/非アクティブ化を継続して行う必要をなくすためにも合理的です。そのため、Basicサンプル・アプリケーションでは、Registrarオブジェクトはprocessアクティブ化ポリシーを持ちます。

CourseSynopsisEnumeratorオブジェクト

Universityサーバー・アプリケーションの基本的な設計上の問題は、大きすぎて1回のレスポンスではクライアント・アプリケーションに返すことができないコース概要リストをどのように処理するかです。このため、ソリューションは次のことが中心となります。

•	クライアント・アプリケーションとコース概要をUniversityデータベースからフェッチできるオブジェクト間の会話を開始します。

•	オブジェクトがクライアント・アプリケーションに最初の概要リストを返します。

•	コース概要の残りをメモリーに保持しておき、クライアント・アプリケーションが一度にそれらを取得できるようにします。

•	完了時にクライアント・アプリケーションが会話を終了することによって、マシンのリソースを解放します。

Universityサーバー・アプリケーションは、このソリューションを実装するCourseSynopsisEnumeratorオブジェクトを備えています。このオブジェクトは最初に呼び出されたときに最初の概要リストを返しますが、その後もインメモリー・コンテキストに保持されるので、クライアント・アプリケーションは後続のリクエストで概要の残りを取得できます。インメモリー・コンテキストを保持するには、CourseSynopsisEnumeratorオブジェクトはステートフルでなければなりません。つまり、このオブジェクトは複数のクライアント呼出しにわたってメモリー内に常駐します。

クライアントがCourseSynopsisEnumeratorオブジェクトとの会話を終了するときに、このオブジェクトにはメモリーからフラッシュされるための手段が必要です。このため、CourseSynopsisEnumeratorオブジェクトの適切な状態管理の方法は、processアクティブ化ポリシーを割り当て、CORBAアプリケーション制御の非アクティブ化機能を実装することです。

アプリケーション制御の非アクティブ化は、そのオブジェクトのdestroy()操作によって実装されます。

次のサンプル・コードに、CourseSynopsisEnumeratorオブジェクトのdestroy()操作を示します。

void CourseSynopsisEnumerator_i::destroy()
{
// When the client calls "destroy" on the enumerator,
// then this object needs to be "destructed".
// Do this by telling the TP framework that we're
// done with this object.

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つのオブジェクトが永続状態情報を処理します。

•	Registrarオブジェクト

•	CourseSynopsisEnumeratorオブジェクト

以降の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つの重要な側面があります。これらの側面は、このオブジェクトがその永続状態を読み取る方法に影響を与えます。

•	このオブジェクトのOIDには、概要に対する最初のクライアント・リクエストで指定された検索基準が含まれます。この検索基準は、データベースのキーとして機能します。つまり、このオブジェクトはOIDに格納されている検索基準に基づいてデータベースから情報を抽出します。

•	このオブジェクトのすべての操作は、そのオブジェクトがメモリーに読み込むコース概要を使用します。

•	このオブジェクトは、非アクティブ化されるときにコース概要をメモリーからフラッシュする必要があります。

この3つの側面を考えたとき、このオブジェクトでは次のことを行うのが合理的です。

•	アクティブ化時に、そのオブジェクトのactivate_object()操作を介してその永続状態情報を読み取ります。

•	非アクティブ化時に、deactivate_object()操作を介してメモリーからコース概要をフラッシュします。

したがって、CourseSynopsisEnumeratorオブジェクトがアクティブ化されるときに、そのオブジェクトのactivate_object()操作は次の処理を実行します。

1.	そのOIDから検索基準を抽出します。

2.	検索基準に一致するコース概要をデータベースから検索します。

注意:	オブジェクトに対するTobj_ServantBase::activate_object()操作またはTobj_ServantBase::deactivate_object()操作を実装する場合は、実装ヘッダー・ファイル(つまり、application_i.hファイル)を編集し、これらの操作の定義をそのオブジェクトのインタフェースのクラス定義テンプレートに追加してください。

Universityデータベースの使い方

Universityサンプル・アプリケーションがUniversityデータベースを使用する方法について、次のことに注意してください。

•

すべてのUniversityサンプル・アプリケーションは、Universityデータベースにアクセスしてコース情報と学生情報を操作します。通常、これが、実装ファイルで記述するコードの大部分を占めます。Universityサンプルの実装ファイルをより簡素化して、データベース・コードではなくCORBAの機能に集中できるようにするために、サンプルでは、データベースを読み書きするすべてのコードが一連のクラスにラッピングされています。utilsディレクトリのsamplesdb.hファイルには、これらのクラスの定義が含まれています。これらのクラスは、Universityデータベース内のコース・レコードと学生レコードを読み書きするために必要なすべてのSQL呼出しを行います。

注意:	WrapperおよびProductionサンプル・アプリケーションのOracle Tuxedo Tellerアプリケーションは、Universityデータベース内の口座情報に直接アクセスし、samplesdb.hファイルを使用しません。

Basicサーバー・アプリケーションに組み込むファイルの詳細は、『CORBA Universityサンプル・アプリケーション・ガイド』を参照してください。

•

CourseSynopsisEnumeratorオブジェクトは、データベース・カーソルを使用してUniversityデータベースから一致するコース概要を検索します。データベース・カーソルは複数のトランザクションにまたがることができないため、CourseSynopsisEnumeratorオブジェクトに対するactivate_object()操作は一致するすべてのコース概要をメモリーに読み込みます。カーソルはイテレータ・クラスによって管理されているため、CourseSynopsisEnumeratorオブジェクトからは見えないことに注意してください。Universityサンプル・アプリケーションがトランザクションを使用する方法の詳細は、第6章「トランザクションのCORBAサーバー・アプリケーションへの統合」を参照してください。

Basicサンプル・アプリケーションがデザイン・パターンを適用する方法

Basicサンプル・アプリケーションは、次のデザイン・パターンを使用します。

•	Process-Entity

•	List-Enumerator

この項では、この2つのデザイン・パターンがBasicサンプル・アプリケーションに適している理由と、Basicサンプル・アプリケーションがこれらのパターンを実装する方法について説明します。

Process-Entityデザイン・パターン

1-22ページの「Process-Entityデザイン・パターン」という項で説明したように、このデザイン・パターンは、クライアント・アプリケーションによって必要とされるデータ・エンティティを処理する1つのプロセス・オブジェクトが存在する場合に適しています。データ・エンティティは、クライアント・アプリケーションではなくこのプロセス・オブジェクトによって操作されるCORBA structとしてカプセル化されます。

Process-Entityデザイン・パターンをBasicサンプル・アプリケーションに適用すると、Basicサンプル・アプリケーションは細粒度オブジェクトの実装を回避できます。たとえば、Registrarオブジェクトは、同様に数の多い一連のコース・オブジェクトのかわりに使用できる効率的なオブジェクトです。単一の粗粒度Registrarオブジェクトを管理する負荷は、何百、何千もの細粒度のコース・オブジェクトを管理するオーバーヘッドに比べれば、それほど大きくはありません。

Process-Entityデザイン・パターンの詳細は、デザイン・パターンに関するテクニカル・アーティクルを参照してください。

List-Enumeratorデザイン・パターン

このデザイン・パターンは、大きすぎて1つのレスポンスでクライアント・アプリケーションに返すことができないデータの内部リストをオブジェクトが生成した場合に適しています。したがって、このオブジェクトはクライアント・アプリケーションに最初のデータを1つのレスポンスで返す必要があり、後続のレスポンスで残りのデータを返すことができる必要があります。

List-Enumeratorオブジェクトも、このオブジェクトが適切な後続データを返すことができるように、すでに返されたデータ量を同時に追跡する必要があります。List-Enumeratorオブジェクトは常にステートフルであり(クライアント呼出しにまたがってアクティブ化され、メモリーに常駐する)、サーバー・アプリケーションはそれらが不要になったときにそれらを非アクティブ化できます。

List-Enumeratorデザイン・パターンは、CourseSynopsisEnumeratorオブジェクトに最適です。このデザイン・パターンを実装すると、次のメリットが得られます。

•	Universityサーバー・アプリケーションは、大きいコース概要リストを、クライアント・アプリケーションが処理できる方法、つまり管理可能な分量で返すための方法を手に入れます。

•	各CourseSynopsisEnumeratorオブジェクトは一意で、その内容はこのオブジェクトが作成される原因となったリクエストによって決まります。(また、各CourseSynopsisEnumeratorのオブジェクトIDも一意です。)クライアントがRegistrarオブジェクトに対してget_courses_synopsis()操作を呼び出すと、Registrarオブジェクトは次のものを戻します。

•

最初の概要リスト

•	残りの概要を返すことができるCourseSynopsisEnumeratorオブジェクトのオブジェクト参照。

このため、後続のすべての呼出しは適切なCourseSynopsisEnumeratorオブジェクトに対して行われます。これは、サーバー・プロセスにCourseSynopsisEnumeratorクラスのアクティブ・インスタンスが複数存在する場合に重要です。

get_courses_synopsis()操作は一意のCourseSynopsisEnumeratorオブジェクト参照を返すので、クライアント・リクエストどうしが衝突することはありません。つまり、クライアント・リクエストが間違ったCourseSynopsisEnumeratorオブジェクトに誤って送られることはありません。

Registrarオブジェクトはget_courses_synopsis()操作を備えていますが、データベース問合せと概要リストの知識はすべてCourseSynopsisEnumeratorオブジェクトに埋め込まれます。この場合、Registrarオブジェクトは単にクライアントが次のデータを取得するための手段として機能します。

•

最初の概要リスト

•	残りの概要を返すことができるCourseSynopsisEnumeratorオブジェクトの参照。

Oracle Tuxedoシステムに組み込まれたパフォーマンス効率化

Oracle Tuxedoシステムでは、同じサーバー・プロセスの2つのオブジェクト間のデータ・マーシャリングが自動的に無効化されることによって、パフォーマンスが効率化されます。この効率化は次の状況が存在する場合に発生します。

•	オブジェクト参照が、自身が作成されたサーバー・プロセスを含んでいるグループに送られる場合

•	そのサーバー・プロセス内のあるオブジェクトがそのオブジェクト参照を使用して操作を呼び出し、それによって同じプロセスでオブジェクトがインスタンス化される場合

この例には、RegistrarオブジェクトがCourseSynopsisEnumeratorオブジェクトのオブジェクト参照を作成し、それによってそのオブジェクトがインスタンス化された場合などがあります。この2つのオブジェクト間のリクエストとレスポンスでは、データ・マーシャリングは行われません。

状態を持つオブジェクトの事前アクティブ化

状態を持つオブジェクトの事前アクティブ化機能を使用すると、クライアント・アプリケーションがオブジェクトを呼び出す前にそのオブジェクトをアクティブ化できます。この機能は、UniversityサンプルのCourseSynopsisEnumeratorオブジェクトなどのイテレータ・オブジェクトを作成するときに特に役立ちます。

状態を持つオブジェクトの事前アクティブ化では、TP::create_active_object_reference()操作を使用します。通常、クライアントがあるオブジェクトに対する呼出しを発行するまで、CORBAサーバー・アプリケーションでそのオブジェクトは作成されません。ただし、オブジェクトを事前アクティブ化し、TP::create_active_object_reference()操作を使用してそのオブジェクトへの参照をクライアントに渡すことによって、クライアント・アプリケーションは、すでにアクティブ化され、状態を持っているオブジェクトを呼び出すことができます。

注意:	状態を持つオブジェクトの事前アクティブ化の機能は、WebLogic Enterpriseバージョン4.2で最初に導入されました。

状態を持つオブジェクトを事前アクティブ化する方法

事前アクティブ化の機能を使用するためのプロセスは、サーバー・アプリケーションに次のコードを記述することです。

1.	オブジェクトを作成するためのC++ new文の呼出しを含めます。

2.	オブジェクトの状態を設定します。

3.	TP::create_active_object_reference()操作を呼び出して、新しく作成されたオブジェクトの参照を取得します。このオブジェクト参照は、クライアント・アプリケーションに返すことができます。

このように、事前アクティブ化オブジェクトは、TPフレームワークがそのオブジェクトのServer::create_servant()とTobj_ServantBase::activate_object()操作を呼び出さずに作成されます。

事前アクティブ化オブジェクトの使い方に関する注意

事前アクティブ化機能を使用するときには、以下のことに注意してください。

•	事前アクティブ化オブジェクトには、processアクティブ化ポリシーが割り当てられている必要があります。このため、これらのオブジェクトは、プロセスの終了時か、それらのオブジェクトに対するTP::deactivateEnable()操作の呼出しによってのみ非アクティブ化できます。

•	TP::create_active_object_reference()操作によって作成されるオブジェクト参照は一時的なものです。これは、事前アクティブ化オブジェクトは自身が作成されたプロセスの存続期間にわたって存在し、別のサーバー・プロセスで再びアクティブ化してはならないためです。

ある一時オブジェクト参照が作成されたプロセスの停止後にクライアント・アプリケーションがそのオブジェクト参照を呼び出した場合、TPフレームワークは次の例外を返します。

CORBA::OBJECT_NOT_EXIST

•	事前アクティブ化されたオブジェクトでは、通常、クラッシュが発生した場合に状態を回復できませんが、このようなオブジェクトは通常、特定の一連の操作のコンテキストで使用されてから削除されることが想定されているため許容できます。その状態は特定の一連の操作以外では意味を持ちません。

サーバーがクラッシュし、そのときに削除されたオブジェクトをクライアント・アプリケーションが呼び出そうとする状況を回避するには、事前アクティブ化されるオブジェクトに対するTobj_ServantBase::activate_object()操作の実装にTobjS::ActivateObjectFailed例外を追加します。クライアントがサーバー・クラッシュ後にこのようなオブジェクトを呼び出そうとし、TPフレームワークがそのオブジェクトに対してTobj_ServantBase::activate_object()操作を呼び出した場合、TPフレームワークはクライアント・アプリケーションに次の例外を戻します。

CORBA::OBJECT_NOT_EXIST

•	事前アクティブ化は慎重に使用してください。すべてのプロセス・バウンド・オブジェクトと同じように、事前アクティブ化によって少ないリソースが事前に割り当てられるためです。