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