| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > Tuxedo CORBA サーバ・アプリケーションの開発方法 > CORBA サーバ・アプリケーションの概念 |
|
Tuxedo CORBA サーバ・アプリケーションの開発方法
|
CORBA サーバ・アプリケーションの概念
ここでは、以下の内容について説明します。
このマニュアルの各章では、さまざまな BEA Tuxedo ソフトウェア機能を活用する CORBA サーバ・アプリケーションをビルドする手順および例について説明します。BEA Tuxedo CORBA サーバ・アプリケーションとその機能に関する基本情報については、『BEA Tuxedo CORBA アプリケーション入門』を参照してください。
CORBA サーバ・アプリケーションをビルドするために作成するエンティティ
CORBA サーバ・アプリケーションをビルドするには、次の 2 つのエンティティを作成します。
また、IDL コンパイラによって生成され、CORBA サーバ・アプリケーションに組み込む複数のファイルも使用します。これらのファイルのリストと説明については、「BEA Tuxedo CORBA サーバ・アプリケーションの作成手順」を参照してください。
以降の節では、これらのエンティティの基礎知識について説明します。これらのエンティティの生成の詳細については、「BEA Tuxedo CORBA サーバ・アプリケーションの作成手順」を参照してください。
サーバ・アプリケーション用の CORBA オブジェクトのインプリメンテーション
CORBA オブジェクトとは何か、およびそれらをどのように定義、インプリメント、インスタンス化、管理するかについて明確に理解しておくことは、CORBA サーバ・アプリケーションの設計者および作成者にとって不可欠です。
Object Management Group インターフェイス定義言語 (OMG IDL) で定義したインターフェイスの CORBA オブジェクトには、CORBA サーバ・アプリケーションのビジネス・ロジックとデータが含まれます。すべてのクライアント・アプリケーション要求では、CORBA オブジェクトのオペレーションが呼び出されます。インターフェイス用に定義されたオペレーションをインプリメントするコードを、オブジェクト・インプリメンテーションと言います。たとえば、C++ では、オブジェクト・インプリメンテーションは C++ クラスです。
ここでは、以下の内容について説明します。
OMG IDL インターフェイス定義で CORBA オブジェクトのオペレーションを確立する方法
CORBA オブジェクトのインターフェイスは、そのオブジェクトで実行可能なオペレーションを識別します。CORBA オブジェクトに固有の特性は、オブジェクトのインターフェイス定義がそのインプリメンテーションから独立していることです。インターフェイス定義により、インターフェイスのオペレーションをインプリメントする方法が確立されます。これには、オペレーションに受け渡し、オペレーションから返される有効なパラメータなどが含まれます。
インターフェイス定義は OMG IDL で表現され、アプリケーションのクライアント/サーバ間の取り決めを確立します。つまり、特定のインターフェイスについて、サーバ・アプリケーションは次のことを行います。
サーバ・アプリケーションがどのようにオペレーションをインプリメントするかは、時間と共に変わる場合があります。この振る舞いは、サーバ・アプリケーションが定義されたインターフェイスをインプリメントし、定義されたパラメータを使用するという要件を満たす限り許容されます。このため、クライアント・スタブは常にサーバ・マシン上のオブジェクト・インプリメンテーションの信頼できるプロキシであり続けます。これは、CORBA アーキテクチャの主要なメリットの 1 つです。つまり、サーバ・アプリケーションがオブジェクトをインプリメントする方法を変更するときに、クライアント・アプリケーションを修正する必要がなく、クライアント・アプリケーションがその変更を認識する必要もないということです。
また、インターフェイス定義は、クライアント・スタブと、サーバ・アプリケーションのスケルトンの両方の内容を決定します。これらの 2 つのエンティティに ORB とポータブル・オブジェクト・アダプタ (POA) を組み合わせることにより、オブジェクトのオペレーションに対するクライアント要求を、その要求を満たすことができるサーバ・アプリケーションのコードにルーティングできます。
システム設計者がアプリケーションのビジネス・オブジェクトのインターフェイスを指定したら、プログラマはそのインターフェイスをインプリメントします。このマニュアルでは、その方法について説明します。
OMG IDL の詳細については、『BEA Tuxedo CORBA クライアント・アプリケーションの開発方法』を参照してください。
CORBA オブジェクトのオペレーションをインプリメントする方法
前述のとおり、インターフェイスで定義されたオペレーションをインプリメントするコードを、オブジェクト・インプリメンテーションと言います。C++ の場合、このコードはメソッドのセットで構成され、アプリケーションの OMG IDL ファイル内のインターフェイスで定義されたオペレーションごとに 1 つ存在します。アプリケーションのオブジェクト・インプリメンテーションのセットが記述されたファイルを、インプリメンテーション・ファイルと言います。BEA Tuxedo システムには、IDL コンパイラが用意されています。IDL コンパイラは、次の図に示すように、アプリケーションの OMG IDL ファイルをコンパイルして、インプリメンテーション・ファイルを含むいくつかのファイルを生成します。
生成されたインプリメンテーション・ファイルには、メソッド・テンプレート、メソッド宣言、オブジェクトのコンストラクタとデストラクタ、およびその他のデータが含まれています。これらを出発点として、アプリケーションのオブジェクト・インプリメンテーションを記述できます。たとえば C++ では、生成されたインプリメンテーション・ファイルには各インターフェイスのメソッドのシグニチャが含まれています。このファイルに各メソッドのビジネス・ロジックを入力し、そのファイルをサーバ・アプリケーションの実行可能ファイルをビルドするコマンドへの入力として提供します。 クライアント・アプリケーションがサーバ・アプリケーションの CORBA オブジェクトをアクセスおよび操作する方法 クライアント・アプリケーションは、サーバ・アプリケーションによって管理される CORBA オブジェクトのオブジェクト・リファレンスを介して、それらのオブジェクトをアクセスおよび操作します。クライアント・アプリケーションは、オブジェクト・リファレンス上のオペレーション (つまり要求) を呼び出します。これらの要求はメッセージとしてサーバ・アプリケーションに送信されます。サーバ・アプリケーションは、CORBA オブジェクトの適切なオペレーションを呼び出します。これらの要求がサーバ・アプリケーションに送信され、そのサーバ・アプリケーションで呼び出されるという事実は、クライアントからは完全に見えません。クライアント・アプリケーションは、単にクライアント・スタブで呼び出しを行っているように見えます。 クライアント・アプリケーションは、オブジェクト・リファレンスによってのみ CORBA オブジェクトを操作できます。設計上の主要な考慮事項の 1 つは、アプリケーションに適した方法でどのようにオブジェクト・リファレンスを作成し、それらを必要としているクライアント・アプリケーションにそれらを返すかです。 一般に、CORBA オブジェクトへのオブジェクト・リファレンスはファクトリによって BEA Tuxedo システムで作成されます。ファクトリは、別の CORBA オブジェクトへのオブジェクト・リファレンスをそのオペレーションの 1 つとして返す任意の CORBA オブジェクトです。アプリケーションのファクトリは、アプリケーション用に定義したほかの CORBA オブジェクトと同じようにインプリメントします。ファクトリを FactoryFinder に登録することによって、ファクトリを BEA Tuxedo ドメイン、およびその BEA Tuxedo ドメインに接続されているクライアントに認識させることができます。ファクトリの登録は、通常 Server オブジェクトによって実行されるオペレーションです。詳細については、「第 1 章の 10 ページ「Server オブジェクト」」を参照してください。ファクトリの設計の詳細については、「第 1 章の 11 ページ「オブジェクト・リファレンスの生成」」を参照してください。 オブジェクト・リファレンスの内容 クライアント・アプリケーションからは、オブジェクト・リファレンスはオペーク、つまりブラック・ボックスのように見えます。クライアント・アプリケーションは、その内容を知らなくてもオブジェクト・リファレンスを使用できます。ただし、オブジェクト・リファレンスには、BEA Tuxedo システムが特定のオブジェクト・インスタンス、およびそのオブジェクトに関連付けられている状態データを検索するために必要なすべての情報が格納されています。 オブジェクト・リファレンスには、以下の情報が格納されます。
これは、オブジェクトの OMG IDL インターフェイスのインターフェイス・リポジトリ ID です。
OID は、リファレンスを適用するオブジェクトのインスタンスを一意に識別します。オブジェクトが外部ストレージ内にデータを持っている場合、OID には通常サーバ・マシンがそのオブジェクトのデータを検索するために使用できるキーも含まれます。
グループ ID は、クライアント・アプリケーションがオブジェクト・リファレンスを使用して要求を行ったときに、そのオブジェクト・リファレンスのルーティング先となるサーバ・グループを識別します。デフォルト以外のグループ ID の生成は、ファクトリ・ベース・ルーティングという BEA Tuxedo の主要機能の 1 つです。詳細については、「第 8 章の 14 ページ「ファクトリ・ベース・ルーティング」」で説明します。
注記 上のリストの 3 つの情報を組み合わせることにより、CORBA オブジェクトが一意に識別されます。指定されたインターフェイスおよび OID を持つ 1 つのオブジェクトが 2 つの異なるグループで同時に活性化されることも、それら 2 つのグループに同じオブジェクト・インプリメンテーションがある場合には起こりえます。指定されたインターフェイス名および OID の 1 つのオブジェクトがドメイン内で一度に 1 つだけ利用可能であることを保証する必要がある場合は、次のいずれかを行います。ファクトリ・ベース・ルーティングを使用して、特定の OID のオブジェクトが常に同じグループにルーティングされるようにするか、指定されるオブジェクト・インプリメンテーションが 1 つのグループのみに存在するようにドメインをコンフィグレーションする。そうすれば、指定されたインターフェイス名および OID を持つ 1 つのオブジェクトに複数のクライアントがオブジェクト・リファレンスをした場合でも、そのリファレンスは常に同じオブジェクト・インスタンスへルーティングされることになります。
ファクトリ・ベース・ルーティングの詳細については、「第 8 章の 14 ページ「ファクトリ・ベース・ルーティング」」を参照してください。
オブジェクト・リファレンスの存続期間
BEA Tuxedo ドメインで動作するサーバ・アプリケーションによって作成されるオブジェクト・リファレンスには、通常それを作成したサーバ・プロセスの存続期間より長い寿命が設定されます。BEA Tuxedo オブジェクト・リファレンスは、最初にそれらを作成したサーバ・プロセスが実行されているかどうかに関係なく、クライアント・アプリケーションで使用できます。このように、オブジェクト・リファレンスは特定のサーバ・プロセスに関連付けられてはいません。
TP::create_active_object_reference() オペレーションで作成されたオブジェクト・リファレンスは、それを作成したサーバ・プロセスが存続する間だけ有効です。詳細については、第 3 章の 20 ページ「状態を持つオブジェクトの事前活性化」を参照してください。
オブジェクト・インスタンスの受け渡し
ORB は、オブジェクト・インスタンスをオブジェクト・リファレンスとしてマーシャリングできません。たとえば、次のコードでファクトリ・リファレンスを受け渡すと、BEA Tuxedo システムで CORBA マーシャリング例外が発生します。
connection::setFactory(this);
オブジェクト・インスタンスを受け渡すには、次の例のように、プロキシ・オブジェクト・リファレンスを作成して、そのプロキシを代わりに受け渡します。
CORBA::Object myRef = TP::get_object_reference();
ResultSetFactory factoryRef = ResultSetFactoryHelper::_narrow(myRef);
connection::setFactoryRef(factoryRef);
CORBA オブジェクトの実行時のインスタンス化
サーバ・アプリケーションが、サーバ・マシンのメモリにマップされていないオブジェクト (活性化されていないオブジェクト) の要求を受信した場合、TP フレームワークは Server::create_servant() オペレーションを呼び出します。Server::create_servant() オペレーションは、作成する CORBA サーバ・アプリケーションのコンポーネントである Server オブジェクト (「第 1 章の 2 ページ「サーバ・アプリケーション用の CORBA オブジェクトのインプリメンテーション」」を参照) でインプリメントされます。
Server::create_servant() オペレーションにより、CORBA オブジェクト・インプリメンテーションのインスタンスがサーバ・マシンのメモリにマップされます。このオブジェクト・インプリメンテーションのインスタンスを、オブジェクトのサーバントと呼びます。正式には、サーバントとはアプリケーションの OMG IDL ファイルに定義されるインターフェイスをインプリメントする C++ クラスのインスタンスです。サーバントは、Server::create_servant() オペレーションに記述する C++ new 文によって生成されます。
オブジェクトのサーバントが作成されたら、TP フレームワークはそのサーバントの Tobj_ServantBase::activate_object() オペレーションを呼び出します。Tobj_ServantBase::activate_object() オペレーションは、すべてのオブジェクト・インプリメンテーション・クラスが継承する Tobj_ServantBase 基本クラスで定義される仮想オペレーションです。TP フレームワークは、Tobj_ServantBase::activate_object() オペレーションを呼び出してサーバントをオブジェクト ID (OID) に関連付けます。反対に、TP フレームワークが Tobj_ServantBase::deactivate_object() オペレーションを呼び出すと、サーバントと OID との関連付けが解除されます。
オブジェクトのデータがディスク上に存在し、CORBA オブジェクトを活性化するときにそのデータをメモリに読み取る場合、そのオブジェクトの Tobj_ServantBase::activate_object() オペレーションを定義およびインプリメントすることによってそのデータを読み取ることができます。Tobj_ServantBase::activate_object() オペレーションには、オブジェクトの永続的な状態をメモリに読み取るために必要な特定の読み取りオペレーションを格納できます。代わりに、インプリメンテーション・ファイルにコーディングしたオブジェクトの 1 つまたは複数のオペレーションによってオブジェクトのディスク・データをメモリに読み取ることもできます。詳細については、第 1 章の 19 ページ「オブジェクトのデータの読み取りと書き込み」を参照してください。Tobj_ServantBase::activate_object() オペレーションの呼び出しが完了したら、オブジェクトは活性化されていると見なされます。
こうしたオブジェクトのインプリメンテーションとデータの集合から、CORBA オブジェクトの実行時のアクティブ・インスタンスが構成されます。
サーバント・プール
サーバント・プールを使用すると、CORBA サーバ・アプリケーションはサーバントと特定の OID との関連付けが解除された後でも、サーバントをメモリに格納し続けることができます。プールされたサーバントで処理できるクライアント要求が到着すると、TP フレームワークは TP::create_servant オペレーションをバイパスし、プールされたサーバントとクライアント要求で提供された OID の間にリンクを作成します。
このため、サーバント・プールを使用すると、CORBA サーバ・アプリケーションは、サーバントによって処理できるオブジェクト要求が到着するたびにそのサーバントを再インスタンス化するコストを最小限に抑えることができます。サーバント・プールとその使い方の詳細については、「第 2 章の 33 ページ「サーバント・プール」」を参照してください。
注記 サーバント・プールは、WebLogic Enterprise リリース 4.2 で初めて導入されました。
Server オブジェクト
Server オブジェクトは、CORBA サーバ・アプリケーション用に作成するもう 1 つのプログラミング・コード・エンティティです。Server オブジェクトは、次のタスクを実行するオペレーションをインプリメントします。
Server オブジェクトは、一般のテキスト・エディタを使用してゼロから作成します。作成した Server オブジェクトは、サーバ・アプリケーションのビルド・コマンド、buildobjserver への入力として提供します。Server オブジェクトの作成については、「BEA Tuxedo CORBA サーバ・アプリケーションの作成手順」を参照してください。
CORBA サーバ・アプリケーションの開発プロセス
この節では、次のトピックに関する背景情報を提供します。この情報は、CORBA サーバ・アプリケーションの設計およびインプリメンテーション方法に大きな影響を与えます。
次の章に進む前にこれらのトピックに目を通しておくことは必須ではありません。ただし、ここでこれらのトピックを提供するのは、すべての CORBA サーバ・アプリケーションの基本的な設計とインプリメンテーションの問題に広く適用されるからです。
オブジェクト・リファレンスの生成
CORBA サーバ・アプリケーションの最も基本的な機能の 1 つは、クライアント・アプリケーションに対して、そのビジネス・ロジックを実行するために必要なオブジェクトのオブジェクト・リファレンスを提供することです。通常、CORBA クライアント・アプリケーションは、自身が使用する初期 CORBA オブジェクトのオブジェクト・リファレンスを次の 2 つのソースから取得します。
クライアント・アプリケーションは、Bootstrap オブジェクトを使用して BEA Tuxedo ドメイン内の特定のオブジェクト・セット (FactoryFinder オブジェクトや SecurityCurrent オブジェクトなど) の初期リファレンスを解決します。Bootstrap オブジェクトについては、『BEA Tuxedo CORBA アプリケーション入門』と『BEA Tuxedo CORBA クライアント・アプリケーションの開発方法』を参照してください。
ただし、ファクトリはユーザが設計、インプリメント、および登録します。ファクトリを使用すると、クライアント・アプリケーションは CORBA サーバ・アプリケーションのオブジェクト (特に初期サーバ・アプリケーション・オブジェクト) のリファレンスを取得できます。単純に言えば、ファクトリは別の CORBA オブジェクトのオブジェクト・リファレンスを返す任意の CORBA オブジェクトです。通常、クライアント・アプリケーションは、ファクトリのオペレーションを呼び出して特定のタイプの CORBA オブジェクトのオブジェクト・リファレンスを取得します。CORBA サーバ・アプリケーションを開発する際には、ファクトリの計画とインプリメンテーションを注意深く行うことが重要です。
クライアント・アプリケーションがサーバ・アプリケーションのファクトリを見つけるしくみ
クライアント・アプリケーションは、サーバ・アプリケーションによって管理されるファクトリを FactoryFinder を介して検索できます。通常、Server オブジェクトを開発する場合、サーバ・アプリケーションによって管理されるファクトリを FactoryFinder に登録するコードを組み込みます。この登録オペレーションを通じて、FactoryFinder はサーバ・アプリケーションのファクトリを追跡し、ファクトリを要求するクライアント・アプリケーションにそれらのオブジェクト・リファレンスを提供できます。オブジェクト・リファレンスを取得するときには、ファクトリを使用してそれらを FactoryFinder に登録することをお勧めします。この方法を使用すると、クライアント・アプリケーションは CORBA サーバ・アプリケーションのオブジェクトを簡単に見つけることができます。
アクティブ・オブジェクト・リファレンスの作成
アクティブ・オブジェクト・リファレンスは、サーバ・アプリケーションがオブジェクト・リファレンスを生成するための代わりの手段を提供する機能です。アクティブ・オブジェクト・リファレンスは、一般に前節で説明したファクトリによっては作成されません。アクティブ・オブジェクト・リファレンスは、状態を持つオブジェクトを事前活性化するための手段です。オブジェクトの状態については、次の節で詳しく説明します。.
既存のオブジェクト・リファレンスに関連付けられているオブジェクトは、クライアント・アプリケーションがそのオブジェクトに対して呼び出しを行うまでインスタンス化されません。ただし、アクティブ・オブジェクト・リファレンスに関連付けられているオブジェクトは、そのアクティブ・オブジェクト・リファレンスの作成時に作成され、活性化されます。アクティブ・オブジェクト・リファレンスは、イテレータ・オブジェクトなどの特定の目的に役立ちます。アクティブ・オブジェクト・リファレンスの詳細については、「第 3 章の 20 ページ「状態を持つオブジェクトの事前活性化」」を参照してください。
注記 アクティブ・オブジェクト・リファレンスの機能は、WebLogic Enterprise バージョン 4.2 で最初に導入されました。
オブジェクト状態の管理
オブジェクト状態の管理は、大規模クライアント/サーバ・システムの重要な課題です。このようなシステムでは、スループットと応答時間の最適化が不可欠だからです。BEA Tuxedo ドメインで実行されるアプリケーションなど、高スループット・アプリケーションの大部分は、状態を持たない傾向にあります。つまり、こうしたシステムは、サービスまたはオペレーションが達成された後にメモリから状態情報をフラッシュします。
状態の管理は、CORBA ベースのサーバ・アプリケーションを記述するのに不可欠の要素です。一般に、これらのサーバ・アプリケーションの状態を、スケーラビリティと高性能を実現するような方法で管理するのは困難です。BEA Tuxedo ソフトウェアは、状態を管理すると同時に、スケーラビリティと高性能を保証するための簡単な方法を提供します。
CORBA サーバ・アプリケーションにスケーラビリティを組み込むことにより、サーバ・アプリケーションは、数百または数千のクライアント・アプリケーション、複数のマシン、複製サーバ・プロセス、およびそれに比例した多数のオブジェクトとそれらに対する呼び出しで構成される環境においても正常に機能します。
オブジェクト状態について
BEA Tuxedo ドメインでは、オブジェクト状態は、特にオブジェクトに対する複数のクライアント呼び出しにわたるそのオブジェクトのプロセス状態を表します。BEA Tuxedo ソフトウェアでは、状態を持つオブジェクトと状態を持たないオブジェクトに関する以下の定義を使用します。
状態を持たないオブジェクトと状態を持つオブジェクトはどちらもデータを持ちますが、状態を持つオブジェクトは、それらのオペレーション呼び出しの間コンテキスト (状態) を保持するのに必要な非永続データをメモリ内に持つことができます。このため、こうした状態を持つオブジェクトの後続の呼び出しは、常に同じサーバントに送られます。反対に、状態を持たないオブジェクトの呼び出しは、BEA Tuxedo システムによって、そのオブジェクトを活性化できる任意の利用可能なサーバ・プロセスに送ることができます。 また、状態管理には、オブジェクトがアクティブであり続ける時間も含まれます。これは、サーバの性能とマシン・リソースの利用状態に重要な影響を与えます。活性化されたオブジェクトの存続期間は、オブジェクトのインターフェイスに割り当てるオブジェクトの活性化方針によって指定されます。オブジェクトの活性化方針については、次の節で説明します。 オブジェクトの状態は、クライアント・アプリケーションからは見えません。クライアント・アプリケーションは、分散オブジェクトとの既存の対話モデルをインプリメントします。クライアント・アプリケーションがオブジェクト・リファレンスを持っている限り、追加の要求に対してオブジェクトが常に利用可能であると見なされ、オブジェクトはクライアント・アプリケーションがそのオブジェクトと対話している間メモリ内に継続して保持されているように見えます。 アプリケーションの性能を最適化するには、作成するアプリケーションのオブジェクトがどのように状態を管理するのかについて注意深く計画する必要があります。オブジェクトは、非活性化される前に自身の状態を永続ストレージに保存する必要があります (該当する場合)。またオブジェクトは、活性化されるときに自身の状態を永続ストレージから復元する必要があります (該当する場合)。オブジェクト状態情報の読み取りと書き込みについては、「第 1 章の 19 ページ「オブジェクトのデータの読み取りと書き込み」」を参照してください。 注記 BEA Tuxedo リリース 8.0 では、性能の拡張として、パラレル・オブジェクトのサポートが提供されています。この機能を利用すると、特定アプリケーションのすべてのビジネス・オブジェクトを状態を持たないオブジェクトにすることができます。詳細については、『BEA Tuxedo CORBA プログラミング・リファレンス』の「第 3 章 TP フレームワーク」を参照してください。 オブジェクトの活性化方針 BEA Tuxedo ソフトウェアには、3 つのオブジェクトの活性化方針が用意されています。これらの方針をオブジェクトのインターフェイスに割り当てることで、オブジェクトがクライアント要求によって呼び出された後にメモリ内に保持される期間を指定できます。これらの方針によって、適用先のオブジェクトが一般に状態を持たないか、または状態を持つかが決定されます。 次の表に、3 つの方針とその説明を示します。
オブジェクトの活性化方針を割り当てることにより、オブジェクトを非活性化させるイベントを指定できます。オブジェクトの活性化方針をオブジェクトのインターフェイスに割り当てる方法については、「第 2 章の 17 ページ「ステップ 4: オブジェクトのメモリ内での振る舞い」」を参照してください。 アプリケーション制御の非活性化 BEA Tuxedo ソフトウェアには、アプリケーション制御の非活性化という機能も用意されています。この機能を使用すると、アプリケーションは実行時にオブジェクトを非活性化できます。BEA Tuxedo ソフトウェアは、プロセス・バウンド・オブジェクトが自身に対して呼び出すことができる TP::deactivateEnable() オペレーションを提供しています。TP::deactivateEnable() オペレーションが呼び出されると、そのオペレーションが存在するオブジェクトは自身に対する現在のクライアント呼び出しの完了時に非活性化されます。オブジェクトは、自身に対してだけこのオペレーションを呼び出すことができます。呼び出しが行われれているオブジェクト以外のオブジェクトでこのオペレーションを呼び出すことはできません。 アプリケーション制御の非活性化機能は、オブジェクトに対する一定数のクライアント呼び出しの間だけそのオブジェクトをメモリに保持し、クライアント・アプリケーションからオブジェクトにそのオブジェクトの処理が終了したことを通知できるようにする場合に特に役立ちます。その時点で、オブジェクトは自身をメモリから消去します。 したがって、アプリケーション制御の非活性化を使用すると、オブジェクトはプロセス・バウンド・オブジェクトと同じようにメモリに保持されます。つまり、オブジェクトは自身に対するクライアント呼び出しによって活性化され、その初期クライアント呼び出しの完了後もメモリに保持されます。このオブジェクトは、それが存在するサーバ・プロセスをシャットダウンせずに非活性化できます。 アプリケーション制御の非活性化の代わりの方法は、トランザクションをスコープしてクライアント・アプリケーションとオブジェクト間の会話を管理することです。ただし、トランザクションは本質的にコストが高く、一般にその期間が不定の状態では適していません。 一般に、アプリケーション制御の非活性化または会話のトランザクションを選択する場合、それらにディスク書き込みオペレーションが含まれているかどうかを調べます。会話に読み取り専用オペレーションが含まれているか、またはメモリ内のみの状態の管理が含まれている場合、アプリケーション制御の非活性化の方が適しています。会話中または会話の最後にデータをディスクに書き込む場合は、トランザクションの方が適しています。 注記 アプリケーション制御の非活性化を使用して、クライアント・アプリケーションとサーバ・アプリケーションによって管理されるオブジェクト間の会話モデルをインプリメントする場合、オブジェクトは最終的に TP::deactivateEnable() オペレーションを呼び出す必要があります。呼び出さない場合、オブジェクトはメモリ内で永久的にアイドル状態に置かれます。これは、TP::deactivateEnable() オペレーションの呼び出し前にクライアント・アプリケーションがクラッシュした場合に危険を招くおそれがあります。一方、トランザクションはタイムアウト・メカニズムをインプリメントして、オブジェクトが永久的にアイドル状態に置かれることを防ぎます。これは、2 つの会話モデルのいずれかを選択する際のもう 1 つの考慮事項です。 アプリケーション制御の非活性化は、次の手順を使用してオブジェクトにインプリメントします。
オブジェクトのデータの読み取りと書き込み
サーバ・アプリケーションによって管理される CORBA オブジェクトの多くは、外部ストレージにデータを持っています。こうした外部に格納されているデータは、オブジェクトの永続状態と見なされます。オブジェクト状態管理が適切に機能するには、オブジェクト・インプリメンテーションの適切なポイントで永続状態を処理する必要があります。
オブジェクトの永続状態の読み取りと書き込みに関するクライアント/サーバ・アプリケーションのさまざまな要件のために、TP フレームワークはディスク上の永続オブジェクト状態を自動的に処理できません。一般に、オブジェクトの永続状態が 1 つまたは複数のクライアント呼び出しによって修正される場合、そのオブジェクトが非活性化される前に永続状態を保存する必要があります。また、オブジェクトが活性化されている間にどのようにオブジェクトのデータを格納または初期化するかを注意深く計画する必要があります。
以降の節では、オブジェクトの永続状態を処理するためのメカニズムについて説明し、特定の環境でオブジェクト状態を読み書きする方法についての一般的なヒントを示します。具体的には、次のトピックについて説明します。
永続状態の読み書きの選択方法は、クライアント/サーバ・アプリケーションの要件、特にデータの構築方法によって異なります。一般に、最も重要なのは、特に XA リソース・マネージャが関与する場合に、ディスク・オペレーションの数を最小限に抑えることです。
オブジェクトの永続状態を読み書きするためのメカニズム
表 1-1 と 表 1-2 に、オブジェクトの永続状態を読み書きするためのメカニズムを示します。
表 1-1 オブジェクトの永続状態を読み取るためのメカニズム
表 1-2 オブジェクトの永続状態を読み取るためのメカニズム
注記 Tobj_ServantBase::deactivate_object() オペレーションを使用して永続状態をディスクに書き込む場合、ディスクへの書き込み中に発生するエラーはクライアント・アプリケーションにはレポートされません。このため、このオペレーションでデータをディスクに書き込むのは、オブジェクトがトランザクション・バウンドの場合 (transaction 活性化方針が割り当てられている場合) か、または TransactionCurrent オブジェクトを呼び出すことによってトランザクション内でディスク書き込みオペレーションをスコープする場合です。トランザクション内でディスクへの書き込み中に発生したエラーは、クライアント・アプリケーションにレポートできます。Tobj_ServantBase::deactivate_object() オペレーションを使用してオブジェクト状態をディスクに書き込む方法については、「第 2 章の 32 ページ「Tobj_ServantBase::deactivate_object() での状態処理に関する注意」」を参照してください。 オブジェクトの活性化時の状態の読み取り オブジェクトの Tobj_ServantBase::activate_object() オペレーションを使用した永続状態の読み取りは、次の条件のいずれかが存在するときに適しています。
Tobj_ServantBase::activate_object() オペレーションを使用した永続状態の読み取りには、次のメリットがあります。
オブジェクトの個々のオペレーションでの状態の読み取り
活性化方針に関係なく、どのオブジェクトを使用する場合も、そのデータを必要とする各オペレーションで永続データを読み取ることができます。つまり、永続状態の読み取りを Tobj_ServantBase::activate_object() オペレーションの外部で処理できます。この方法は、次の場合に適しています。
一例として、顧客の投資ポートフォリオを表すオブジェクトを考えてみましょう。このオブジェクトには、各投資に対応する複数の個別レコードが含まれているとします。特定のオペレーションがポートフォリオの 1 つの投資だけに影響を与える場合、そのオペレーションを使用して 1 つのレコードを読み取る方が、オブジェクトを呼び出すたびに投資ポートフォリオ全体を自動的に読み取る汎用の Tobj_ServantBase::activate_object() オペレーションを使用するより効率的です。
状態を持たないオブジェクトと永続状態
状態を持たないオブジェクト、つまり、method 活性化方針で定義されたオブジェクトの場合、次のことを保証する必要があります。
TP フレームワークは、活性化時にオブジェクトの Tobj_ServantBase::activate_object() オペレーションを呼び出します。オブジェクトが自身のディスク上の永続状態へのキーを含む OID を持っている場合、Tobj_ServantBase::activate_object() オペレーションはそのキーを OID から抽出するための唯一の機会をオブジェクトに提供します。
状態を持たないオブジェクトがトランザクションに参加できるようにする場合、一般に、そのオブジェクトの個々のメソッドの中でそのオブジェクトが永続状態をディスクに書き込むようにします。ただし、状態を持たないオブジェクトが常にトランザクションに関与する (このオブジェクトが呼び出されたときにトランザクションが常にスコープされる) 場合、Tobj_ServantBase::deactivate_object() オペレーションでデータベース書き込みオペレーションを処理することを選択できます。これは、データベース書き込みオペレーションを正確にコミットまたはロールバックするための信頼できるメカニズムが XA リソース・マネージャに用意されているからです。
注記 オブジェクトがメソッド・バウンドの場合でも、2 つのサーバ・プロセスが同じディスク・データに同時にアクセスする可能性を考慮に入れる必要があります。このような場合、並行性管理テクニックを使用できます。その最も簡単な方法は、トランザクションです。トランザクションとトランザクション・オブジェクトの詳細については、トランザクションの CORBA サーバ・アプリケーションへの統合を参照してください。
サーバント・プールと状態を持たないオブジェクト
サーバント・プールは、状態を持たないオブジェクトに対して特に便利な機能です。CORBA サーバ・アプリケーションがサーバントをプールすると、クライアントがオブジェクトを呼び出すたびにそのオブジェクトをインスタンス化するコストを大幅に低減できます。「第 1 章の 9 ページ「サーバント・プール」」の節で説明したとおり、プールされたサーバントはそのクライアント呼び出しの完了後もメモリに保持されます。アプリケーションで特定のオブジェクトを繰り返し呼び出す可能性がある場合、サーバントをプールすると、各クライアントに対してオブジェクトのメソッドではなくデータだけをメモリに読み取り、メモリから書き込むだけで済みます。オブジェクトのメソッドをメモリに読み取るコストが高い場合、サーバント・プールによってそのコストを低減できます。
サーバント・プールをインプリメントする方法については、「第 2 章の 33 ページ「サーバント・プール」」を参照してください。
状態を持つオブジェクトと永続状態
状態を持つオブジェクトの場合、必要な場合にのみ永続状態を読み書きする必要があります。この場合、次の最適化が必要になる場合があります。
一般に、トランザクション・バウンド・オブジェクトは、すべてのデータベース書き込みまたはロールバック・オペレーションを自動的に処理する XA リソース・マネージャに依存する必要があります。
注記 トランザクションに関与するオブジェクトの場合、XA リソース・マネージャによって管理されない外部ストレージへのオブジェクトのデータ書き込みはサポートされません。
オブジェクトとトランザクションの詳細については、トランザクションの CORBA サーバ・アプリケーションへの統合を参照してください。
サーバント・プールと状態を持つオブジェクト
サーバント・プールは、プロセス・バウンド・オブジェクトに対しては意味を持ちません。ただし、アプリケーション設計によっては、サーバント・プールによってトランザクション・バウンド・オブジェクトの性能が向上する場合があります。
オブジェクトの非活性化の責任
前節で説明したとおり、Tobj_ServantBase::deactivate_object() オペレーションは、オブジェクトの永続状態をディスクに書き込むための手段としてインプリメントします。また、このオペレーションは、保持されているオブジェクト・データをメモリからフラッシュして、オブジェクトのサーバントでそのオブジェクトの別のインスタンスを活性化できるようにするためにも使用されます。ただし、オブジェクトの Tobj_ServantBase::deactivate_object() オペレーションの呼び出しによってそのオブジェクトのデストラクタも呼び出されると見なしてはなりません。
不必要な I/O の回避
オブジェクトで不必要な I/O を行うことによってアプリケーションの効率を下げないよう注意する必要があります。注意が必要な状態は以下のとおりです。
一般的な最適化の方法は、活性化時に dirtyState フラグを初期化し、オブジェクトの活性化中にこのフラグが変更された場合にだけ Tobj_ServantBase::deactivate_object() オペレーションでデータを書き込むことです。ただし、これはオブジェクトが常に同じサーバント・プロセスで活性化されると保証できる場合にだけ使用できます。
活性化のサンプル
オブジェクトが活性化されるときに行われる一連のアクティビティの例については、『BEA Tuxedo CORBA アプリケーション入門』を参照してください。
デザイン・パターンの使い方
優れた設計に基づいてアプリケーションのビジネス・ロジックを構築することは重要です。BEA Tuxedo ソフトウェアには、このニーズを満たすデザイン・パターンのセットが用意されています。デザイン・パターンは、特定の設計問題に対する構造化されたソリューションです。デザイン・パターンの価値は、再利用およびほかのデザイン問題への適用が可能な形式で表現できることにあります。
BEA Tuxedo デザイン・パターンは、エンタープライズ・クラスのアプリケーション設計の問題に対する構造化されたソリューションです。これらを使用すると、大規模クライアント/サーバ・アプリケーションを適切に設計できます。
ここで説明するデザイン・パターンは、CORBA クライアント・アプリケーションおよびサーバ・アプリケーションで優れた設計手法を採用するためのガイドです。これらのデザイン・パターンは CORBA クライアント・アプリケーションおよびサーバ・アプリケーションの設計の重要な部分です。このマニュアルの各章には、これらのデザイン・パターンを使用して University サンプル・アプリケーションをインプリメントする方法が示されています。
Process-Entity デザイン・パターン
Process-Entity デザイン・パターンは、大規模なエンタープライズ・クラスのクライアント/サーバ・アプリケーションに適用されます。このデザイン・パターンは、『Object-Oriented Design Patterns』(Gamma ほか著) では Flyweight パターンと呼ばれ、ほかの出版物ではモデル/ビュー/コントローラと呼ばれています。
このパターンでは、クライアント・アプリケーションは存続期間の長いプロセス・オブジェクトを作成し、このオブジェクトと対話して要求を行います。たとえば、University サンプル・アプリケーションでは、このオブジェクトはクライアント・アプリケーションに代わってコース参照オペレーションを処理する登録係です。コース自体はデータベース・エンティティで、クライアント・アプリケーションからは見えません。
Process-Entity デザイン・パターンのメリットは次のとおりです。
Process-Entity デザイン・パターンの適用例については、「Basic CORBA サーバ・アプリケーションの設計とインプリメント」を参照してください。Process-Entity デザイン・パターンの詳細については、『CORBA 技術情報』を参照してください。
List-Enumerator デザイン・パターン
List-Enumerator デザイン・パターンも、大規模なエンタープライズ・クラスのクライアント/サーバ・アプリケーションに適用されます。List-Enumerator デザイン・パターンは、BEA Tuxedo の主要機能であるアプリケーション制御のオブジェクト活性化を利用して、複数のクライアント呼び出しの間メモリ内で保持および追跡されるデータのキャッシュを処理し、不要になったときにそのデータをメモリからフラッシュします。
List-Enumerator デザイン・パターンの適用例については、「Basic CORBA サーバ・アプリケーションの設計とインプリメント」を参照してください。
List-Enumerator デザインをインプリメントするのに特に役立つツール、オブジェクトの事前活性化については、「第 3 章の 20 ページ「状態を持つオブジェクトの事前活性化」」を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
