| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > Tuxedo CORBA サーバ・アプリケーションの開発方法 > BEA Tuxedo CORBA サーバ・アプリケーションの作成手順 |
|
Tuxedo CORBA サーバ・アプリケーションの開発方法
|
BEA Tuxedo CORBA サーバ・アプリケーションの作成手順
この章では、CORBA サーバ・アプリケーションを作成するための手順について説明します。この章で説明する手順は、決定的なものではありません。サーバ・アプリケーションによっては、ほかの手順を行う必要があります。また、これらの手順のいくつかについては順番を変更することができます。ただし、これらの手順は、すべての CORBA サーバ・アプリケーションの開発プロセスに共通のものです。
ここでは、以下の内容について説明します。
この章では、最初に手順の要約と、このマニュアルで使用する開発ツールおよび開発コマンドのリストを示します。デプロイメント環境によっては、ほかのソフトウェア開発ツールも使用します。このため、この章で説明するツールとコマンドも決定的なものではありません。
この章では、BEA Tuxedo ソフトウェアに付属の Basic University サンプル・アプリケーションの中の例を使用します。Basic University サンプル・アプリケーションの詳細については、『BEA Tuxedo CORBA University サンプル・アプリケーション』を参照してください。このマニュアルで使用するツールとコマンドの詳細については、『BEA Tuxedo CORBA プログラミング・リファレンス』を参照してください。
マルチスレッドCORBA サーバ・アプリケーションの作成については、「第 4 章 マルチスレッド CORBA サーバ・アプリケーションの作成」を参照してください。
CORBA サーバ・アプリケーション開発プロセスの概要
サーバ・アプリケーションを作成するための基本的な手順は次のとおりです。
ステップ 1: サーバ・アプリケーション用の OMG IDL ファイルのコンパイル
ステップ 2: 各インターフェイスのオペレーションをインプリメントするメソッドの記述
ステップ 3: サーバ・オブジェクトの作成
ステップ 4: オブジェクトのメモリ内での振る舞い
ステップ 5: サーバ・アプリケーションのコンパイルとリンク
ステップ 6: サーバ・アプリケーションのデプロイ
BEA Tuxedo ソフトウェアには、次の開発ツールと開発コマンドが用意されています。
ステップ 1: サーバ・アプリケーション用の OMG IDL ファイルのコンパイル
BEA Tuxedo ドメインで実行されるアプリケーションのクライアントおよびサーバ部分の基本構造は、そのアプリケーションの OMG IDL ファイルに記述される文によって決定されます。アプリケーションの OMG IDL ファイルをコンパイルする場合、IDL コンパイラは、idl コマンドで指定するオプションに応じて、次の図に示すファイルの一部または全部を生成します。影付きのコンポーネントは、サーバ・アプリケーションを作成するために修正するファイルです。
表 に、IDL コンパイラによって生成されるファイルを示します。
IDL コンパイラの使い方
表 2-1 に示したファイルを生成するには、次のコマンドを入力します。
idl [options] idl-filename [icf-filename]
idl コマンド構文のパラメータは次のとおりです。
注記 WebLogic Enterprise 5.1 では、プラグマの C++ IDL コンパイラ・インプリメンテーションが変更され、CORBA 2.3 機能がサポートされるようになりました。これにより、IDL ファイルが影響を受ける場合があります。CORBA 2.3 機能は、プラグマ接頭辞定義が影響を及す可能性があるスコープを変更します。プラグマはインクルードされる IDL ファイルに含まれる定義には影響を及さず、またインクルードされる IDL ファイル内で行われるプラグマ接頭辞定義はそれらのファイルの外部のオブジェクトに影響を及しません。
C++ IDL コンパイラは、プラグマ接頭辞の処理を訂正するよう変更されました。この変更はオブジェクトのリポジトリ ID に影響を与えるため、_narrow などのオペレーションでエラーが発生する場合があります。
このようなエラーを防ぐには、次のことを行います。
IDL コンパイラと idl コマンドの詳細については、『BEA Tuxedo CORBA プログラミング・リファレンス』を参照してください。
スケルトンとインプリメンテーション・ファイルの生成
次のコマンド行は、OMG IDL ファイル univb.idl のクライアント・スタブ・ファイル、スケルトン・ファイル、初期インプリメンテーション・ファイル、スケルトン・ヘッダ・ファイル、およびインプリメンテーション・ヘッダ・ファイルを生成します。
idl -i univb.idl
idl コマンドの詳細については、『BEA Tuxedo CORBA プログラミング・リファレンス』を参照してください。BEA Tuxedo University サンプル・アプリケーション用のこれらのファイルを生成する方法については、『BEA Tuxedo CORBA University サンプル・アプリケーション』を参照してください。
注記 非デフォルトのオブジェクトの活性化方針またはトランザクション方針を指定する場合、または生成するスケルトン・ファイルとインプリメンテーション・ファイルのインターフェイスの数を制限する場合、インプリメンテーション・コンフィギュレーション・ファイル (ICF) を生成し、この ICF ファイルを IDL コンパイラに受け渡す必要があります。詳細については、ページ 2-14 の「ICF でオブジェクトの活性化方針とトランザクション方針を指定する方法」を参照してください。
tie クラスの生成
IDL コンパイラには、インターフェイスの tie クラス・テンプレートを生成するために使用できる -T コマンド行オプションも用意されています。CORBA アプリケーションの tie クラスのインプリメントについては、ページ 2-29 の「デレゲーション・ベースのインターフェイス・インプリメンテーション」を参照してください。
ステップ 2: 各インターフェイスのオペレーションをインプリメントするメソッドの記述
サーバ・アプリケーション・プログラマは、アプリケーションの OMG IDL ファイルで定義した各インターフェイスのオペレーションをインプリメントするメソッドを記述します。
インプリメンテーション・ファイルには以下のものが含まれます。
Tobj_ServantBase::activate_object() オペレーションと Tobj_ServantBase::deactivate_object() オペレーションの中で、オブジェクトの活性化または非活性化に関連する特定の手順を実行するコードを記述します。これには、オブジェクトの永続状態のディスクからの読み取りとディスクへの書き込みがそれぞれ含まれます。これらのオペレーションをオブジェクトにインプリメントする場合、インプリメンテーション・ヘッダ・ファイルを編集して、これらのオペレーションを使用する各インプリメンテーションにそれらの定義を追加する必要があります。
IDL コンパイラによって生成されるインプリメンテーション・ファイル
サーバ・アプリケーションのインプリメンテーション・ファイルはすべて手動で作成できますが、インプリメンテーション・ファイルを記述する出発点として、IDL コンパイラが生成するインプリメンテーション・ファイルを使用することもできます。IDL コンパイラによって生成されるインプリメンテーション・ファイルには、アプリケーションのインターフェイス用に定義された各オペレーションをインプリメントするメソッドのシグニチャが含まれます。
通常、このインプリメンテーション・ファイルは、IDL コンパイラを呼び出すコマンドで -i オプションを指定することによって 1 度だけ作成します。アプリケーションのインターフェイスを繰り返し修正し、これらのインターフェイスのオペレーション (オペレーション・シグニチャを含む) を変更した場合は、必要なすべての変更をインプリメンテーション・ファイルに追加してこれらの変更を反映させる必要があります。
ファクトリのインプリメント
ページ 1-4 の「クライアント・アプリケーションがサーバ・アプリケーションのCORBA オブジェクトをアクセスおよび操作する方法」で説明したように、クライアント・アプリケーションがサーバ・アプリケーションによって管理されるオブジェクトを簡単に検索できるようにするためには、ファクトリを作成する必要があります。ファクトリはインプリメントするほかの CORBA オブジェクトに似ていますが、FactoryFinder オブジェクトに登録する必要があります。ファクトリの登録については、ページ 2-10 の「ファクトリを作成および登録するコードの記述」を参照してください。
ファクトリの主要な機能は、オブジェクト・リファレンスを作成することです。ファクトリは、TP::create_object_reference() オペレーションを呼び出すことによってこれを実行します。TP::create_object_reference() オペレーションでは、次の入力パラメータが必要となります。
たとえば、Basic University サンプル・アプリケーションでは、RegistrarFactory インターフェイスは、次のように 1 つのオペレーションだけを指定します。
University::Registrar_ptr RegistrarFactory_i::find_registrar()
RegistrarFactory オブジェクトの find_registrar() オペレーションには、Registrar オブジェクトのリファレンスを作成するための TP::create_object_reference() オペレーションへの次の呼び出しが含まれています。
CORBA::Object_var v_reg_oref =
TP::create_object_reference(
University::_tc_Registrar->id(),
object_id,
CORBA::NVlist::_nil()
);
このコード・サンプルでは、次のことに留意してください。
University::_tc_Registrar->id()
CORBA::NVlist::_nil()
オブジェクト・リファレンスのルーティング先のグループに影響を与えるルーティング基準の指定については、「第 8 章 BEA Tuxedo のCORBA サーバ・アプリケーションのスケーリング」を参照してください。
ステップ 3: サーバ・オブジェクトの作成
Server オブジェクトのインプリメントは、ほかの言語オブジェクトのインプリメントとは異なります。Server オブジェクトのヘッダ・クラスは既に作成されており、Server オブジェクト・クラスは既にインスタンス化されています。Server オブジェクトを作成するには、パッケージ済みの Server オブジェクト・クラスの特定のメソッド・セットをインプリメントします。この節では、インプリメントするこれらのメソッドについて説明します。
Server オブジェクトを作成するには、一般のテキスト・エディタで新しいファイルを作成し、次のオペレーションをインプリメントします。
どのサーバ・アプリケーションにも、Server オブジェクトのインスタンスは 1 つしか存在しません。サーバ・アプリケーションが複数の CORBA オブジェクト・インプリメンテーションを管理する場合、記述する Server::initialize()、Server::create_servant()、および Server::release() オペレーションにはこれらのインプリメンテーションすべてに適用するコードを組み込む必要があります。 これらのタスクの大部分のコードには、TP フレームワークとの対話が含まれます。以降の節では、これらの Server オブジェクト・オペレーションのそれぞれに対して必要なコードについて説明し、Basic University サンプル・アプリケーションのサンプル・コードを示します。 サーバ・アプリケーションの初期化 Server オブジェクトに実装する最初のオペレーションは、サーバ・アプリケーションを初期化するオペレーションです。このオペレーションは、BEA Tuxedo システムがサーバ・アプリケーションを起動するときに呼び出されます。TP フレームワークは、サーバ・アプリケーションの起動シーケンス中に Server オブジェクトの次のオペレーションを呼び出します。 BEA Tuxedo ドメインの UBBCONFIG ファイルの SERVERS セクションに指定する特定のサーバ・アプリケーション用の CLOPT パラメータは、Server::initialize() オペレーションにargc および argv として受け渡されます。サーバ・アプリケーションへの引数の受け渡しについては、『BEA Tuxedo アプリケーション実行時の管理』を参照してください。サーバ・アプリケーションに引数を受け渡す例については、『BEA Tuxedo CORBA University サンプル・アプリケーション』を参照してください。 Server::initialize() オペレーションの中には、該当する場合、次のことを行うコードを組み込みます。
CORBA::Boolean Server::initialize(int argc, char** argv)
ファクトリを作成および登録するコードの記述
クライアント・アプリケーションがオブジェクトを簡単に検索できるようにするためのファクトリをサーバ・アプリケーションが管理する場合、そのファクトリを FactoryFinder オブジェクトに登録するコードを記述する必要があります。このコードは、通常サーバ・アプリケーション初期化プロセスの最後のステップとして呼び出されます。
サーバ・アプリケーションによって管理されるファクトリを登録するコードを記述するには、次のことを行います。
このステップでは、ページ 2-7 の「ファクトリのインプリメント」で説明したとおりオブジェクト・リファレンスを作成します。このステップでは、TP::create_object_reference() オペレーションの呼び出しを組み込み、OMG IDL インターフェイスのインターフェイス・リポジトリ ID を指定します。次の例では、RegistrarFactory ファクトリのオブジェクト・リファレンス (s_v_fact_ref 変数で表される) が作成されます。
University::RegistrarFactory s_v_fact_ref =
TP::create_object_reference(
University::_tc_RegistrarFactory->id(),
object_id,
CORBA::NVList::_nil()
);
このステップでは、サーバ・アプリケーションによって管理される各ファクトリに対して次のオペレーションを呼び出します。
TP::register_factory (CORBA::Object_ptr factory_or,
const char* factory_id);
TP::register_factory() オペレーションは、サーバ・アプリケーションのファクトリを FactoryFinder オブジェクトに登録します。このオペレーションでは、次の入力パラメータが必要です。
次の例では、RegistrarFactory ファクトリが BEA Tuxedo ドメインに登録されます。
TP::register_factory(s_v_fact_ref.in(),
University::_tc_RegistrarFactory->id());
University::_tc_RegistrarFactory->id() パラメータに注目してください。これは、TP::create_object_reference() オペレーションで指定したパラメータと同じです。このパラメータは、オブジェクトの OMG IDL インターフェイスのインターフェイス・リポジトリ ID をそのタイプ・コードから抽出します。
サーバントの作成
サーバ・アプリケーション初期化プロセスが完了したら、サーバ・アプリケーションはクライアント要求を処理できる状態になります。CORBA オブジェクトのオペレーションに対する要求が到着し、それを処理するサーバントがメモリ内に存在しない場合、TP フレームワークは Server オブジェクトの次のオペレーションを呼び出します。
Tobj_Servant Server::create_servant(const char* interfaceName)
Server::create_servant() オペレーションには、クライアント要求によって必要とされるオブジェクトのサーバントをインスタンス化するコードが含まれます。たとえば、C++ では、このコードにはオブジェクトのインターフェイス・クラスの new 文が組み込まれます。
Server::create_servant() オペレーションでは、サーバントは OID に関連付けられません。サーバントと OID の関連付けは、TP フレームワークがそのサーバントの Tobj_ServantBase::activate_object() オペレーション (オブジェクトのインスタンス化を完了させるオペレーション) を呼び出したときに行われます。オブジェクトのコンストラクタで OID をオブジェクトに関連付けることはできません。同様に、サーバントと OID の関連付けの解除は、TP フレームワークがそのサーバントの deactivate_object() オペレーションを呼び出したときに行われます。
BEA Tuxedo システムでのこうしたサーバントの振る舞いにより、TP フレームワークは、オブジェクトの非活性化後、別のオブジェクトのインスタンス化のためにサーバントを使用できます。したがって、オブジェクトの Tobj_ServantBase::deactivate_object() オペレーションの呼び出しによってそのオブジェクトのデストラクタも呼び出されるとは考えないでください。サーバ・アプリケーションでサーバント・プール機能を使用する場合、オブジェクトの Tobj_ServantBase::deactivate_object() オペレーションに TP::application_responsibility() オペレーションをインプリメントして、サーバントへのポインタを後で使用できるようにサーバント・プールに受け渡すことができます。サーバント・プールについては、ページ 2-28 の「サーバント・プール」を参照してください。
Server::create_servant() オペレーションでは、入力引数が 1 つ必要です。この引数は、サーバントを作成するためのオブジェクトの OMG IDL インターフェイスのインターフェイス リポジトリ ID を含む文字列を指定します。
このオペレーション用に記述するコードには、サーバ・アプリケーションによって管理されるオブジェクトの OMG IDL インターフェイスのインターフェイス・リポジトリ ID を指定します。実行時に、Server::create_servant() オペレーションは、要求によって指定されたオブジェクトに対して必要なサーバントを返します。
次のコードは、Basic University サンプル・アプリケーションの University サーバ・アプリケーションの Server::create_servant() オペレーションをインプリメントします。
Tobj_Servant Server::create_servant(const char* intf_repos_id)
{
if (!strcmp(intf_repos_id, University::_tc_RegistrarFactory->id())) {
return new RegistrarFactory_i();
}
if (!strcmp(intf_repos_id, University::_tc_Registrar->id())) {
return new Registrar_i();
}
if (!strcmp(intf_repos_id, University::_tc_CourseSynopsisEnumerator->id())) {
return new CourseSynopsisEnumerator_i();
}
return 0; // unknown interface
}
サーバ・アプリケーションのリリース
BEA Tuxedo システム管理者が tmshutdown コマンドを入力すると、TP フレームワークは、BEA Tuxedo ドメインで実行される各サーバ・アプリケーションの Server オブジェクトの次のオペレーションを呼び出します。
void Server::release()
Server::release() オペレーションでは、次のような、サーバ・アプリケーションに応じたアプリケーション固有のクリーンアップ・タスクを実行できます。
サーバ・アプリケーションがシャットダウン要求を受信すると、そのサーバ・アプリケーションはほかのリモート・オブジェクトから要求を受信することができなくなります。これは、管理者がサーバ・アプリケーションをシャットダウンする順番に影響を与えます。たとえば、あるサーバ・プロセスへの Server::release() オペレーションの呼び出しが別のサーバ・プロセスに含まれている場合、最初のサーバ・プロセスはシャットダウンしてはなりません。
サーバのシャットダウン中に、次の呼び出しを組み込んでサーバ・アプリケーションの各ファクトリの登録を削除できます。
TP::unregister_factory (CORBA::Object_ptr factory_or,
const char* factory_id)
TP::unregister_factory() オペレーションの呼び出しは、Server::release() インプリメンテーションの最初のアクションの 1 つである必要があります。TP::unregister_factory() オペレーションは、サーバ・アプリケーションのファクトリへの登録を削除します。このオペレーションでは、次の入力引数が必要です。
次の例では、Basic サンプル・アプリケーションで使用されている RegistrarFactory ファクトリへの登録が削除されます。
TP::unregister_factory(s_v_fact_ref.in(), UnivB::_tc_RegistrarFactory->id());
このコード例では、グローバル変数 s_v_fact_ref の使い方に注目してください。この変数は、RegistrarFactory オブジェクトを登録した Server::initialize() オペレーションで設定されたもので、ここで再び使用されます。
また、UnivB::_tc_RegistrarFactory->id() パラメータにも注目してください。これも、ファクトリの登録に使用されたインターフェイス名と同じです。
ステップ 4: オブジェクトのメモリ内での振る舞い
ページ 1-11 の「オブジェクト状態の管理」で説明したように、オブジェクトの活性化方針とトランザクション方針を割り当て、オプションでアプリケーション制御の非活性化機能を使用することによって、オブジェクトを非活性化するイベントを指定します。
オブジェクトの活性化方針とトランザクション方針は ICF ファイルに指定し、アプリケーション制御の非活性化は TP::deactivateEnable() オペレーションを介して使用します。この節では、Basic University サンプル・アプリケーションを例として使用して、これらのメカニズムをインプリメントする方法について説明します。
ここでは、次のことについて説明します。
ICF でオブジェクトの活性化方針とトランザクション方針を指定する方法
BEA Tuxedo ソフトウェアは、ページ 1-13 の「オブジェクトの活性化方針」で説明した次の活性化方針をサポートしています。
BEA Tuxedo ソフトウェアは、「第 6 章 トランザクションのCORBA サーバ・アプリケーションへの統合」で説明する次のトランザクション方針もサポートしています。
これらの方針をアプリケーションのオブジェクトに割り当てるには、次の手順に従います。
# genicf university.idl
module POA_UniversityB
{
implementation CourseSynopsisEnumerator_i
{
activation_policy ( method );
transaction_policy ( optional );
implements ( UniversityB::CourseSynopsisEnumerator );
};
};
module POA_UniversityB
{
implementation Registrar_i
{
activation_policy ( method );
transaction_policy ( optional );
implements ( UniversityB::Registrar );
};
};
module POA_UniversityB
{
implementation RegistrarFactory_i
{
activation_policy ( method );
transaction_policy ( optional );
implements ( UniversityB::RegistrarFactory );
};
};
implementation RegistrarFactory_i
{
activation_policy ( method );
transaction_policy ( optional );
implements ( UniversityB::RegistrarFactory );
};
ステップ 5: サーバ・アプリケーションのコンパイルとリンク
Server オブジェクトとオブジェクト・インプリメンテーションのコードの記述が済んだら、サーバ・アプリケーションをコンパイルおよびリンクします。
CORBA サーバ・アプリケーションをコンパイルおよびリンクするには、buildobjserver コマンドを使用します。buildobjserver コマンドの形式は次のとおりです。
buildobjserver [-o servername] [options]
buildobjserver コマンドの構文要素を次に説明します。
University サンプル・アプリケーションのコンパイルとリンクの詳細については、『BEA Tuxedo CORBA University サンプル・アプリケーション』を参照してください。buildobjserver コマンドの詳細については、『BEA Tuxedo コマンド・リファレンス』を参照してください。
マルチスレッド CORBA サーバ・アプリケーションの設計とビルドには、特別な考慮事項が存在します。詳細については、ページ 4-13 の「buildobjserver コマンドの使い方」を参照してください。
注記 IBM AIX 4.3.3 システム上で BEA Tuxedo ソフトウェアを実行する場合、-brtl コンパイラ・オプションを使用して CORBA アプリケーションを再コンパイルする必要があります。
ステップ 6: サーバ・アプリケーションのデプロイ
システム管理者は、この節で説明する手順を使用して CORBA サーバ・アプリケーションをデプロイします。University サンプル・アプリケーションのビルドとデプロイの詳細については、『BEA Tuxedo CORBA University サンプル・アプリケーション』を参照してください。
サーバ・アプリケーションをデプロイするには、以下の手順に従います。
tmloadcf -y application-ubbconfig-file
tmboot -y
University サンプル・アプリケーションの詳細については、『BEA Tuxedo CORBA University サンプル・アプリケーション』を参照してください。CORBA アプリケーション用の UBBCONFIG ファイルの作成の詳細については、『BEA Tuxedo アプリケーションの設定』を参照してください。
開発とデバッグのヒント
ここでは、以下の内容について説明します。
CORBA 例外とユーザ・ログの使い方
ここでは、以下の内容について説明します。
例外のクライアント・アプリケーション・ビュー
クライアント・アプリケーションが CORBA オブジェクトのオペレーションを呼び出した場合、その呼び出しの結果として例外が返される場合があります。クライアント・アプリケーションに返される有効な例外は次のとおりです。
BEA Tuxedo システムは、これらの CORBA 定義の制限に違反することがないよう動作します。詳細については、ページ 2-20 の「例外のサーバ・アプリケーション・ビュー」で説明します。
クライアント・アプリケーションが認識する例外セットは制限されているので、クライアント・アプリケーションは原因が不明な例外をキャッチする場合があります。BEA Tuxedo システムは、こうした例外を可能な限りユーザ・ログの説明メッセージで補足します。このメッセージは、エラー状態の検出とデバッグに役立ちます。これらのケースについては、次の節で説明します。
例外のサーバ・アプリケーション・ビュー
ここでは、以下の内容について説明します。
BEA Tuxedo システムによって生成され、アプリケーション・コードによってキャッチされる例外
BEA Tuxedo システムは、TP オブジェクトのオペレーションが呼び出された場合、次の例外をアプリケーションに返す場合があります。
interface TobjS {
exception AlreadyRegistered { };
exception ActivateObjectFailed { string reason; };
exception ApplicationProblem { };
exception CannotProceed { };
exception CreateServantFailed { string reason; };
exception DeactivateObjectFailed { string reason; };
exception IllegalInterface { };
exception IllegalOperation { };
exception InitializeFailed { string reason; };
exception InvalidDomain { };
exception InvalidInterface { };
exception InvalidName { };
exception InvalidObject { };
exception InvalidObjectId { };
exception InvalidServant { };
exception NilObject { string reason; };
exception NoSuchElement { };
exception NotFound { };
exception OrbProblem { };
exception OutOfMemory { };
exception OverFlow { };
exception RegistrarNotAvailable { };
exception ReleaseFailed { string reason; };
exception TpfProblem { };
exception UnknownInterface { };
}CORBA オブジェクトのオペレーションの呼び出し中にアプリケーション・コードによって生成された例外を BEA Tuxedo システムが処理する方法
サーバ・アプリケーションは、クライアント呼び出し中に次の場所で例外を生成する場合があります。
サーバ・アプリケーションは次のタイプの例外を生成する可能性があります。
interface TobjS {
exception ActivateObjectFailed { string reason; };
exception CreateServantFailed { string reason; };
exception DeactivateObjectFailed { string reason; };
exception InitializeFailed { string reason; };
exception ReleaseFailed { string reason; };
}サーバ・アプリケーション・コードによって生成され、サーバ・アプリケーションによってキャッチされないすべての例外は、BEA Tuxedo システムによってキャッチされます。これらの例外がキャッチされると、次のいずれかの処理が発生します。
以下の節では、CORBA オブジェクトに対するクライアント呼び出し中にサーバ・アプリケーションによって生成される例外を BEA Tuxedo システムがどのように処理するかについて説明します。
Server::create_servant() オペレーションで生成された例外
例外が Server::create_servant() オペレーションで生成された場合、次の処理が行われます。
Tobj_ServantBase::activate_object() オペレーションで生成された例外
例外が Tobj_ServantBase::activate_object() オペレーションで生成された場合、次の処理が行われます。
オペレーション・インプリメンテーションで生成された例外
BEA Tuxedo システムでは、オペレーション・インプリメンテーションは、CORBA システム例外、またはクライアント・アプリケーションによって認識され、OMG IDL に定義されるユーザ定義例外のいずれかをスローする必要があります。これらのタイプの例外がオペレーション・インプリメンテーションによってスローされた場合、BEA Tuxedo システムは次のいずれかの状態が存在しない限り、それらをクライアント・アプリケーションに返します。
"WARN: Application didn't catch TobjS exception. TP Framework throwing CORBA::BAD_OPERATION."
例外が TobjS::IllegalOperation の場合、次の補足メッセージが書き込まれ、アプリケーションにコーディング・エラーが存在する可能性があることを開発者に警告します。
"WARN: Application called TP::deactivateEnable() illegally and didn't catch TobjS exception."
これは、TP::deactivateEnable() オペレーションが、transaction 活性化方針が割り当てられているオブジェクトの内部で呼び出された場合に発生する可能性があります。アプリケーション制御の非活性化はトランザクション・バウンド・オブジェクトではサポートされません。
CORBA 仕様で定義されているとおり、クライアントに送り返される応答には、オペレーション・インプリメンテーションからの結果値か、オペレーション・インプリメンテーションでスローされた例外のいずれかが含まれ、両方が含まれることはありません。最初のケース、つまり、応答ステータス値が NO_EXCEPTION − の場合、応答にはオペレーションの戻り値と任意の inout または out 引数値が含まれます。それ以外のケース、つまり、応答ステータス値が USER_EXCEPTION または SYSTEM_EXCEPTION の場合、応答には例外の符号化が含まれます。
Tobj_ServantBase::deactivate_object() オペレーションで生成された例外
例外が Tobj_ServantBase::deactivate_object() オペレーションで生成された場合、次の処理が発生します。
オブジェクト・インスタンスの受け渡し時に生成された CORBA マーシャリング例外
ORB は、オブジェクト・インスタンスをオブジェクト・リファレンスとしてマーシャリングできません。たとえば、次のコードでファクトリ・リファレンスを受け渡すと、BEA Tuxedo システムで CORBA マーシャリング例外が発生します。
connection::setFactory(this);
オブジェクト・インスタンスを受け渡すには、次の例のように、プロキシ・オブジェクト・リファレンスを作成して、そのプロキシを代わりに受け渡します。
CORBA::Object myRef = TP::get_object_reference();
ResultSetFactory factoryRef = ResultSetFactoryHelper::_narrow(myRef);
connection::setFactoryRef(factoryRef);
Detecting Error Conditions in the Callback Methods
BEA Tuxedo システムには、メッセージ文字列を指定できる定義済みの例外セットが用意されています。TP フレームワークは、アプリケーション・コードが次のコールバック・メソッドでエラーを取得した場合、これらのメッセージ文字列をユーザ・ログに書き込みます。
これらの例外は、例外の発生原因に関する明確な情報を送信するための便利なデバッグ支援機能として使用できます。TP フレームワークは、これらのメッセージをユーザ・ログにのみ書き込みます。これらのメッセージは、クライアント・アプリケーションには返されません。
これらのメッセージは、次の例外で指定します。これらの例外では、オプションで reason 文字列を指定できます。
メッセージ文字列をユーザ・ログに送るには、次の例のように、その文字列を例外に指定します。 これらの例外をスローする場合、reason 文字列パラメータが指定されている必要があります。これらの例外の 1 つで reason 文字列を指定しない場合は、次の例のように、二重引用符を入力する必要があります。 OMG IDL インターフェイスのバージョンと修正に関する一般的な注意事項 Server オブジェクトの Server::create_servant() オペレーションのインプリメンテーションは、そのインターフェイス ID に基づいてオブジェクトをインスタンス化します。このインターフェイス ID は、ファクトリが TP::create_object_reference() オペレーションを呼び出したときにファクトリに指定されるインターフェイス ID と同じである必要があります。インターフェイス ID が一致しない場合、通常 Server::create_servant() オペレーションで例外が発生するか、または NULL サーバントが返されます。この場合、BEA Tuxedo システムは、CORBA::OBJECT_NOT_EXIST 例外をクライアント・アプリケーションに返します。BEA Tuxedo システムは、TP::create_object_reference() オペレーションでインターフェイス ID の検証を行いません。 このような状態は、開発の過程で、インターフェイスの異なるバージョンが開発されるか、IDL ファイルに対して多くの変更が行われる場合に発生する可能性があります。OMG IDL にインターフェイス ID の文字列定数を指定し、これらの定数をファクトリと Server::create_servant() オペレーションで使用する場合でも、オブジェクト・インプリメンテーションとファクトリが異なる実行可能ファイルに存在する場合は、不一致が発生する可能性があります。多くの場合、この問題の診断は困難です。 こうした問題を避けるには、開発中に次の予防的プログラミング手法を検討する必要があります。このコードは、アプリケーションのデバッグ・バージョンにのみ記述する必要があります。実働バージョンでは受け入れられない性能の低下が発生する可能性があるからです。
throw CreateServantFailed("Unknown interface");throw ActivateObjectFailed("");
Tobj_ServantBase::deactivate_object() での状態処理に関する注意
Tobj_ServantBase::deactivate_object() オペレーションは、オブジェクトの活性化境界に達したときに呼び出されます。このオペレーションのインプリメンテーションでは、オプションで永続状態をディスクに書き込むことができます。このオペレーションで生成された例外はクライアント・アプリケーションに返されないことを理解しておくことが重要です。クライアント・アプリケーションは、オブジェクトがトランザクションに参加していない限り、このオペレーションで生成されたエラー状態を認識しません。このため、このオペレーションで状態が正常に書き込まれたかどうかを知ることが重要である場合は、トランザクションを使用することをお勧めします。
Tobj_ServantBase::deactivate_object() オペレーションで状態を書き込むことを選択し、クライアント・アプリケーションがその書き込みオペレーションの結果を知る必要がある場合、次のことを行うことをお勧めします。
トランザクションを使用しない場合は、Tobj_ServantBase::deactivate_object() オペレーションを使用せずに、オブジェクトの個々のオペレーションのスコープの中でオブジェクト状態を書き込むことをお勧めします。エラーが発生した場合、オペレーションはクライアント・アプリケーションに返される例外を生成できます。
サーバント・プール
ページ 1-21 の「サーバント・プールと状態を持たないオブジェクト」で説明したように、サーバント・プールを使用すると、メソッド・バウンド・オブジェクトとトランザクション・バウンド・オブジェクトのオブジェクト・インスタンス化のコストを削減できます。
サーバント・プールの機能
通常、オブジェクトの非活性化中 (TP フレームワークが Tobj_ServantBase::deactivate_object() オペレーションを呼び出したとき) に、TP フレームワークはオブジェクトのサーバントを削除します。ただし、サーバント・プールを使用する場合、TP フレームワークはオブジェクトの非活性化時にサーバントを削除しません。代わりに、サーバ・アプリケーションはプール内のサーバントへのポインタを保持します。それ以降、そのプール内のサーバントによって処理可能な要求がクライアントから送られてくると、サーバ・アプリケーションはそのサーバントを再利用して新しいオブジェクト ID を割り当てます。サーバントがプールから再利用される場合、TP フレームワークは新しいサーバントを作成しません。
サーバント・プールのインプリメント方法
サーバント・プールは、以下の手順でインプリメントします。
注記 このリリースでは、TP::application_responsibility() オペレーションのサポートが変更されています。詳細については、『BEA Tuxedo CORBA プログラミング・リファレンス』を参照してください。
デレゲーション・ベースのインターフェイス・インプリメンテーション
BEA Tuxedo CORBA アプリケーションでオブジェクトをインプリメントする主要な方法は、継承とデレゲーションの 2 つです。オブジェクトが POA スケルトン・クラスから継承され、それによって CORBA オブジェクトとなった場合、そのオブジェクトは継承によってインプリメントされたと言われます。
ただし、POA スケルトン・クラスからの継承が困難または不可能な C++ オブジェクトを CORBA アプリケーションで使用したい場合もあります。たとえば、POA スケルトン・クラスから継承するために大幅な書き換えが必要な C++ オブジェクトなどです。こうした非 CORBA オブジェクトを CORBA アプリケーションで使用するには、そのオブジェクト用の tie クラスを作成します。tie クラスは、POA スケルトン・クラスから継承されます。また、tie クラスには 1 つまたは複数のオペレーションが含まれ、それらはインプリメンテーションのためにレガシー・クラスに委譲されます。これにより、レガシー・クラスはデレゲーションによって CORBA アプリケーションにインプリメントされます。
BEA Tuxedo システムの tie クラスについて
デレゲーション・ベースのインターフェイス・インプリメンテーションを作成するには、IDL コンパイラの -T コマンド行オプションを使用して、OMG IDL ファイルに定義されている各インターフェイスに対する tie クラス・テンプレートを生成します。
CORBA アプリケーションで tie クラスを使用する場合、Server オブジェクトに Server::create_servant() オペレーションをインプリメントする方法も変わります。以降の節では、BEA Tuxedo 製品で tie クラスを使用する方法についてさらに詳しく説明し、Server::create_servant() オペレーションをインプリメントしてこれらのクラスをインスタンス化する方法についても説明します。
BEA Tuxedo CORBA では、tie クラスはサーバントであり、したがって基本的にレガシー・クラスのラッパー・オブジェクトとして機能します。
次の図に、レガシー・オブジェクトのラッパーとして機能する、Account インターフェイスの継承の特性を示します。レガシー・オブジェクトには、オペレーション op1 のインプリメンテーションが含まれています。tie クラスは、op1 をレガシー・クラスに委譲します。
tie クラスを使用する条件
tie クラスは BEA Tuxedo CORBA に固有のものではなく、CORBA アプリケーションでデレゲーションをインプリメントするための唯一の方法でもありません。ただし、BEA Tuxedo CORBA の tie クラス用の便利な機能を使用すると、それらの tie クラスの基本的なコンストラクタ、デストラクタ、およびハウスキーピング・オペレーションに必要なコーディングの量を大幅に減らすことができます。
tie クラスは、次のいずれかの状況で使用することをお勧めします。
次の場合、tie クラスの使用はお勧めしません。
CORBA アプリケーションに tie クラスを作成する方法
BEA Tuxedo ドメインのアプリケーションに tie クラスを作成するには、次の手順に従います。
Account * Account_ptr = new LegacyAccount();
AccountFactoryServant = new POA_Account_tie<LegacyAccount> (Account_ptr)
注記 UNIX 用の Compaq C++ Tru64 コンパイラで tie クラスをコンパイルする場合、buildobjserver コマンドで使用される CFLAGS または CPPFLAGS 環境変数の定義に -noimplicit_include オプションを指定する必要があります。このオプションを指定すると、C++ コンパイラはサーバ・スケルトン・ファイル (_s.h) がインクルードされる場所にサーバ・スケルトン定義ファイル (_s.cpp) を自動的に組み込みません。これは、複数定義のシンボル・エラーを回避するために必要です。Tru64 C++ で tie クラスなどのクラス・テンプレートを使用する方法については、Compaq の出版物を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
