Oracle

CORBAサーバー・アプリケーションの概念

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

•	CORBAサーバー・アプリケーションをビルドするために作成するエンティティ:

•	サーバー・アプリケーション用のCORBAオブジェクトの実装

•	サーバー・オブジェクト

•	CORBAサーバー・アプリケーションの開発プロセス:

•	オブジェクト参照の生成

•	オブジェクト状態の管理

•	オブジェクトのデータの読取りと書込み

•	デザイン・パターンの使い方

このマニュアルの各章では、様々なOracle Tuxedoソフトウェア機能を活用するCORBAサーバー・アプリケーションをビルドする手順および例について説明します。Oracle Tuxedo CORBAサーバー・アプリケーションとその動作のバックグラウンド情報は、『Oracle Tuxedo CORBAアプリケーション・スタート・ガイド』を参照してください。

CORBAサーバー・アプリケーションをビルドするために作成するエンティティ

CORBAサーバー・アプリケーションをビルドするには、次の2つのエンティティを作成します。

•	サーバー・アプリケーションのビジネス・ロジックを実行するCORBAオブジェクトの実装

•	サーバー・アプリケーションを初期化およびリリースし、クライアント・リクエストを満たすために必要なCORBAオブジェクトをインスタンス化する操作を実装するServerオブジェクト

また、IDLコンパイラによって生成され、CORBAサーバー・アプリケーションに組み込む複数のファイルも使用します。これらのファイルとその説明は、第2章「Oracle Tuxedo CORBAサーバー・アプリケーションの作成手順」を参照してください。

以降の項では、これらのエンティティの概要を説明します。これらのコンポーネントの生成方法の詳細は、第2章「Oracle Tuxedo CORBAサーバー・アプリケーションの作成手順」を参照してください。

サーバー・アプリケーション用のCORBAオブジェクトの実装

CORBAオブジェクトとは何か、およびそれらをどのように定義、実装、インスタンス化、管理するかについて明確に理解しておくことは、CORBAサーバー・アプリケーションの設計者および作成者にとって不可欠です。

Object Management Groupインタフェース定義言語(OMG IDL)で定義したインタフェースのCORBAオブジェクトには、CORBAサーバー・アプリケーションのビジネス・ロジックとデータが含まれます。すべてのクライアント・アプリケーション・リクエストでは、CORBAオブジェクトの操作が呼び出されます。インタフェースに定義された操作を実装するコードを記述する場合、これはオブジェクト実装と呼ばれます。たとえば、C++のオブジェクト実装はC++クラスです。

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

•	OMG IDLインタフェース定義でCORBAオブジェクトの呼出し可能な操作を確立する方法

•	CORBAオブジェクトの操作を実装する方法

•	クライアント・アプリケーションがサーバー・アプリケーションのCORBAオブジェクトをアクセスおよび操作する方法

•	クライアント・リクエストへの応答としてコードとデータを持つCORBAオブジェクトを実行時にインスタンス化する方法

インタフェース定義でCORBAオブジェクトの操作を確立する方法

CORBAオブジェクトのインタフェースでは、実行できる操作が識別されます。CORBAオブジェクトに固有の特性は、オブジェクトのインタフェース定義がその実装から独立していることです。インタフェースの定義により、操作に渡したり、操作から返される有効なパラメータなど、インタフェースでの操作の実装方法が確立されます。

インタフェース定義はOMG IDLで表現され、アプリケーションのクライアント/サーバー間の取決めを確立します。つまり、特定のインタフェースに対して、サーバー・アプリケーションが次のことを行う必要があります。

•	そのインタフェースで定義された操作を実装します。

•	常に各操作で定義されたパラメータを使用します。

サーバー・アプリケーションによる操作の実装方法は、時間の経過とともに変化する場合があります。これは、サーバー・アプリケーションが定義済インタフェースの実装および定義済パラメータの使用の要件を引き続き満たす場合は受け入れられる動作です。このため、クライアント・スタブは常にサーバー・マシン上のオブジェクト実装の信頼できるプロキシであり続けます。これはCORBAのアーキテクチャの主要な利点の1つです。つまり、サーバー・アプリケーションによるオブジェクトの実装方法を時間の経過とともに変更した場合でも、クライアント・アプリケーションを変更したり、オブジェクト実装が変更されたことを認識させる必要がありません。

また、インタフェース定義は、クライアント・スタブと、サーバー・アプリケーションのスケルトンの両方の内容を決定します。これらの2つのエンティティにORBとポータブル・オブジェクト・アダプタ(POA)を組み合せることにより、オブジェクトの操作に対するクライアント・リクエストを、そのリクエストを満たすことができるサーバー・アプリケーションのコードにルーティングできます。

システム設計者がアプリケーションのビジネス・オブジェクトのインタフェースを指定したら、プログラマはそのインタフェースを実装します。このマニュアルでは、その方法を説明します。

OMG IDLの詳細は、『CORBAクライアント・アプリケーションの作成』を参照してください。

CORBAオブジェクトの操作を実装する方法

前述のとおり、CORBAオブジェクトのインタフェースに定義された操作を実装するコードはオブジェクト実装と呼ばれます。C++の場合、このコードは一連のメソッドで構成され、それぞれがアプリケーションのOMG IDLファイルでインタフェースに定義されている各操作に対応しています。アプリケーションの一連のオブジェクト実装を含むファイルは、実装ファイルと呼ばれます。Oracle TuxedoシステムにはIDLコンパイラが用意されています。IDLコンパイラは、次の図に示すように、アプリケーションのOMG IDLファイルをコンパイルして、実装ファイルを含むいくつかのファイルを生成します。

生成された実装ファイルには、メソッド・テンプレート、メソッド宣言、オブジェクトのコンストラクタとデストラクタ、およびその他のデータが含まれています。これらを出発点として、アプリケーションのオブジェクト実装を記述できます。たとえば、C++では、生成された実装ファイルには、各インタフェースのメソッドのシグネチャが格納されます。このファイルに各メソッドのビジネス・ロジックを入力し、サーバー・アプリケーションの実行可能ファイルをビルドするコマンドに入力としてこのファイルを指定します。

クライアント・アプリケーションがサーバー・アプリケーションのCORBAオブジェクトをアクセスおよび操作する方法

クライアント・アプリケーションは、サーバー・アプリケーションによって管理されるCORBAオブジェクトのオブジェクト参照を介して、それらのオブジェクトをアクセスおよび操作します。クライアント・アプリケーションは、オブジェクト参照上の操作(つまりリクエスト)を呼び出します。これらのリクエストはメッセージとしてサーバー・アプリケーションに送信されます。サーバー・アプリケーションは、CORBAオブジェクトの適切な操作を呼び出します。これらのリクエストがサーバー・アプリケーションに送信され、そのサーバー・アプリケーションで呼び出されるという事実は、クライアントからは完全に見えません。クライアント・アプリケーションは、単にクライアント・スタブで呼出しを行っているように見えます。

クライアント・アプリケーションは、オブジェクト参照によってのみCORBAオブジェクトを操作できます。設計上の主要な考慮事項の1つは、アプリケーションに適した方法でどのようにオブジェクト参照を作成し、それらを必要としているクライアント・アプリケーションにそれらを返すかです。

一般に、CORBAオブジェクトへのオブジェクト参照はファクトリによってOracle Tuxedoシステムで作成されます。ファクトリは、別のCORBAオブジェクトへの参照をその操作の1つとして戻す任意のCORBAオブジェクトです。アプリケーションのファクトリは、アプリケーション用に定義した他のCORBAオブジェクトと同じように実装します。ファクトリをFactoryFinderに登録することによって、ファクトリをOracle Tuxedoドメイン、およびそのOracle Tuxedoドメインに接続されているクライアントに認識させることができます。ファクトリの登録は、通常、1-7ページの「サーバー・オブジェクト」という項で説明されているサーバー・オブジェクトによって実行される操作です。ファクトリの設計の詳細は、1-8ページの「オブジェクト参照の生成」という項を参照してください。

オブジェクト参照の内容

クライアント・アプリケーションの観点では、オブジェクト参照は非透過的であり、クライアント・アプリケーションはこれを使用する際に内容を認識する必要がないため、ブラック・ボックスのようなものです。ただし、オブジェクト参照には、Oracle Tuxedoシステムが特定のオブジェクト・インスタンス、およびそのオブジェクトに関連付けられている状態データを検索するために必要なすべての情報が格納されています。

オブジェクト参照には、以下の情報が格納されます。

•

インタフェース名

これは、オブジェクトのOMG IDLインタフェースのインタフェース・リポジトリIDです。

•	オブジェクトID (OID)

OIDは、参照が適用されるオブジェクトのインスタンスを一意に識別します。オブジェクトが外部ストレージ内にデータを持っている場合、OIDには通常サーバー・マシンがそのオブジェクトのデータを検索するために使用できるキーも含まれます。

•

グループID

グループIDは、クライアント・アプリケーションがオブジェクト参照を使用してリクエストを行ったときに、そのオブジェクト参照のルーティング先となるサーバー・グループを識別します。デフォルト以外のグループIDの生成は、8-11ページの「ファクトリ・ベース・ルーティング」という項で説明されているファクトリ・ベース・ルーティングというOracle Tuxedoの主要機能の1つです。

注意:

前述のリストの3つの項目を組み合せてCORBAオブジェクトを一意に識別します。2つの異なるグループに同じオブジェクト実装が含まれている場合は、これらのグループで、指定されたインタフェースとOIDのオブジェクトを同時にアクティブにできます。指定されたインタフェース名およびOIDの1つのオブジェクト・インスタンスがドメイン内で一度に1つのみ使用可能であることを保証する必要がある場合は、次のいずれかを実行します。つまり、ファクトリ・ベース・ルーティングを使用して、特定のOIDのオブジェクトが常に同じグループにルーティングされるようにするか、指定されるオブジェクト実装が1つのグループのみに存在するようにドメインを構成するかです。これにより、複数のクライアントに指定されたインタフェース名とOIDを含む1つのオブジェクト参照がある場合に、この参照が常に同じオブジェクト・インスタンスにルーティングされることが保証されます。

ファクトリ・ベース・ルーティングの詳細は、-11ページの「ファクトリ・ベース・ルーティング」という項を参照してください。

オブジェクト参照の存続期間

Oracle Tuxedoドメインで動作するサーバー・アプリケーションによって作成されるオブジェクト参照には、通常それを作成したサーバー・プロセスの有効期間より長い寿命が設定されます。最初にOracle Tuxedoオブジェクト参照を作成したサーバー・プロセスがまだ実行中であるかどうかにかかわらず、クライアント・アプリケーションはOracle Tuxedoオブジェクト参照を使用できます。つまり、オブジェクト参照は特定のサーバー・プロセスに関連付けられません。

TP::create_active_object_reference()操作で作成されたオブジェクト参照は、それを作成したサーバー・プロセスの存続期間のみ有効です。詳細は、3-15ページの「状態を持つオブジェクトの事前アクティブ化」という項を参照してください。

オブジェクト・インスタンスの受け渡し

ORBはオブジェクト・インスタンスをオブジェクト参照としてマーシャリングできません。たとえば、次のコードでファクトリ参照を受け渡すと、Oracle 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サーバー・アプリケーションのコンポーネントであるサーバー・オブジェクト(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-14ページの「オブジェクトのデータの読取りと書込み」という項を参照してください。)Tobj_ServantBase::activate_object()操作の呼出しが完了したら、オブジェクトはアクティブ化されていると見なされます。

こうしたオブジェクトの実装とデータの集合から、CORBAオブジェクトの実行時のアクティブ・インスタンスが構成されます。

サーバント・プール

サーバント・プールを使用すると、CORBAサーバー・アプリケーションはサーバントと特定のOIDとの関連付けが解除された後でも、サーバントをメモリーに格納し続けることができます。プールされたサーバントで処理できるクライアント・リクエストが到着すると、TPフレームワークはTP::create_servant操作をバイパスし、プールされたサーバントとクライアント・リクエストで提供されたOIDの間にリンクを作成します。

このため、サーバント・プールを使用すると、CORBAサーバー・アプリケーションは、サーバントによって処理できるオブジェクト・リクエストが到着するたびにそのサーバントを再インスタンス化するコストを最小限に抑えることができます。サーバント・プールおよびその使用方法の詳細は、2-25ページの「サーバント・プール」という項を参照してください。

注意:	サーバント・プールは、WebLogic Enterpriseリリース4.2で初めて導入されました。

Serverオブジェクト

サーバー・オブジェクトは、CORBAサーバー・アプリケーション用に作成するもう1つのプログラミング・コード・エンティティです。サーバー・オブジェクトは、次のタスクを実行する操作を実装します。

•	基本的なサーバー・アプリケーション初期化操作の実行(これには、サーバー・アプリケーションによって管理されるファクトリの登録や、サーバー・アプリケーションで必要なリソースの割当てが含まれます)。サーバー・アプリケーションがトランザクションに関与する場合、ServerオブジェクトはXAリソース・マネージャをオープンするコードを実装します。

•	クライアント・リクエストを満たすために必要なCORBAオブジェクトのインスタンス化。

•	サーバー・アプリケーションでのリクエストの処理が終了した際のサーバー・プロセスの停止およびクリーンアップの手順の実行。たとえば、サーバー・アプリケーションがトランザクションに関与する場合、サーバー・オブジェクトはXAリソース・マネージャをクローズするコードを実装します。

一般的なテキスト・エディタを使用してサーバー・オブジェクトを最初から作成します。作成したサーバー・オブジェクトは、サーバー・アプリケーションのビルド・コマンド、buildobjserverへの入力として提供します。サーバー・オブジェクトの作成の詳細は、第2章「Oracle Tuxedo CORBAサーバー・アプリケーションの作成手順」を参照してください。

CORBAサーバー・アプリケーションの開発プロセス

この項では、次のトピックに関する背景情報を提供します。この情報は、CORBAサーバー・アプリケーションの設計および実装方法に大きな影響を与えます。

•	オブジェクト参照の生成

•	オブジェクト状態の管理

•	オブジェクトのデータの読取りと書込み

•	デザイン・パターンの使い方

次の章に進む前にこれらのトピックに目を通しておくことは必須ではありません。ただし、ここでこれらのトピックを提供するのは、すべてのCORBAサーバー・アプリケーションの基本的な設計と実装の問題に広く適用されるからです。

オブジェクト参照の生成

CORBAサーバー・アプリケーションの最も基本的な機能の1つは、クライアント・アプリケーションに対して、そのビジネス・ロジックを実行するために必要なオブジェクトのオブジェクト参照を提供することです。CORBAクライアント・アプリケーションは、通常、使用する初期CORBAオブジェクトへのオブジェクト参照を次の2つのソースから取得します。

•	Bootstrapオブジェクト

•	Oracle Tuxedoドメインで管理されるファクトリ

クライアント・アプリケーションは、Bootstrapオブジェクトを使用してOracle Tuxedoドメイン内の特定のオブジェクト・セット(FactoryFinderオブジェクトやSecurityCurrentオブジェクトなど)の初期参照を解決します。Bootstrapオブジェクトの詳細は、『Oracle Tuxedo CORBAアプリケーション・スタート・ガイド』および『CORBAクライアント・アプリケーションの作成』を参照してください。

ただし、ファクトリはユーザーが設計、実装、および登録します。ファクトリを使用すると、クライアント・アプリケーションはCORBAサーバー・アプリケーションのオブジェクト(特に初期サーバー・アプリケーション・オブジェクト)の参照を取得できます。単純に言えば、ファクトリは別のCORBAオブジェクトのオブジェクト参照を返す任意のCORBAオブジェクトです。通常、クライアント・アプリケーションは、ファクトリの操作を呼び出して特定のタイプのCORBAオブジェクトのオブジェクト参照を取得します。CORBAサーバー・アプリケーションの開発時には、ファクトリを慎重に計画および実装することが重要です。

クライアント・アプリケーションがサーバー・アプリケーションのファクトリを見つけるしくみ

クライアント・アプリケーションは、サーバー・アプリケーションによって管理されるファクトリをFactoryFinderを介して検索できます。通常、サーバー・オブジェクトを開発する場合、サーバー・アプリケーションによって管理されるファクトリをFactoryFinderに登録するコードを組み込みます。この登録操作を通じて、FactoryFinderはサーバー・アプリケーションのファクトリを追跡し、ファクトリを要求するクライアント・アプリケーションにそれらのオブジェクト参照を提供できます。ファクトリを使用してそれらをFactoryFinderに登録することをお薦めします。この方法を使用すると、クライアント・アプリケーションはCORBAサーバー・アプリケーションのオブジェクトを簡単に見つけることができます。

アクティブ・オブジェクト参照の作成

アクティブ・オブジェクト参照は、サーバー・アプリケーションがオブジェクト参照を生成できる代替手段を提供する機能です。アクティブ・オブジェクト参照は、前の項で説明したとおり、通常ファクトリによって作成されません。また、アクティブ・オブジェクト参照は状態を持つオブジェクトの事前アクティブ化を目的としています。次の項で、オブジェクト状態について詳細に説明します。

従来のオブジェクト参照に関連付けられているオブジェクトは、クライアント・アプリケーションがそのオブジェクトに対して呼出しを行うまでインスタンス化されませんが、アクティブ・オブジェクト参照に関連付けられているオブジェクトは、そのアクティブ・オブジェクト参照の作成時に作成され、アクティブ化されます。アクティブ・オブジェクト参照は、イテレータ・オブジェクトなど、特定の目的の場合に特に便利です。アクティブ・オブジェクト参照の詳細は、3-15ページの「状態を持つオブジェクトの事前アクティブ化」という項を参照してください。

注意:	アクティブ・オブジェクト参照の機能は、WebLogic Enterpriseバージョン4.2で最初に導入されました。

オブジェクト状態の管理

オブジェクト状態管理は、大規模クライアント/サーバー・システムの重要な課題です。このようなシステムでは、スループットと応答時間の最適化が不可欠だからです。Oracle Tuxedoドメインで実行されるアプリケーションなど、高スループット・アプリケーションの大部分は、ステートレスな傾向にあります。つまり、こうしたシステムは、サービスまたは操作が達成された後にメモリーから状態情報をフラッシュします。

状態の管理は、CORBAベースのサーバー・アプリケーションの記述の主要な構成部分です。通常、これらのサーバー・アプリケーションでの状態の管理を、スケーラビリティとパフォーマンスが高い方法で行うことは困難です。Oracle Tuxedoソフトウェアでは、状態を管理し、同時にスケーラビリティと高いパフォーマンスを保証する簡単な方法が提供されます。

CORBAサーバー・アプリケーションにスケーラビリティを組み込むことにより、サーバー・アプリケーションは、数百または数千のクライアント・アプリケーション、複数のマシン、レプリケートサーバー・プロセス、およびそれに比例した多数のオブジェクトとそれらに対する呼出しで構成される環境においても正常に機能します。

オブジェクト状態について

Oracle Tuxedoドメインでは、オブジェクト状態は、オブジェクトに対する複数のクライアント呼出しにわたる、そのオブジェクトのプロセス状態を表します。Oracle Tuxedoソフトウェアでは、表1-1に示すステートフル・オブジェクトとステートレス・オブジェクトの定義を使用します。

 

表1-1 オブジェクト状態について

オブジェクト	動作の特性
ステートレス	このオブジェクトは、自身の操作の1つの呼出しの間だけメモリーにマップされ、その呼出しが完了すると、非アクティブ化されてそのプロセス状態がメモリーからフラッシュされます。つまり、このオブジェクトの状態は、呼出しの完了後はメモリーに保持されません。
ステートフル	このオブジェクトは、その呼出しと呼出しの間もアクティブ化され、その状態はそれらの呼出しを通して保持されます。状態は、次のような特定のイベントが発生するまでメモリーにとどまります。 • オブジェクトが存在するサーバー・プロセスの中断または停止 • オブジェクトが参加しているトランザクションのコミットまたはロールバック • オブジェクトによる自身のTP::deactivateEnable()操作の呼出し。 これらのイベントについては、この項でそれぞれ詳しく説明します。

ステートレス・オブジェクトとステートフル・オブジェクトはどちらもデータを持ちますが、ステートフル・オブジェクトは、それらの操作呼出しの間コンテキスト(状態)を保持するために必要な非永続データをメモリー内に持つことができます。したがって、このようなステートフル・オブジェクトの以降の呼出しは、常に、同じサーバントに対して行われます。反対に、ステートレス・オブジェクトの呼出しはOracle Tuxedoシステムによって、オブジェクトをアクティブ化できる使用可能なサーバー・プロセスに転送されることがあります。

状態管理にはオブジェクトがアクティブである期間も含まれ、これは、サーバーのパフォーマンスおよびマシン・リソースの使用に重要な影響を与えます。アクティブ化されたオブジェクトの有効期間は、オブジェクトのインタフェースに割り当てるオブジェクトのアクティブ化ポリシーによって指定されます。オブジェクトのアクティブ化ポリシーについては、次の項で説明します。

オブジェクト状態はクライアント・アプリケーションに対して透過的です。クライアント・アプリケーションは分散オブジェクトとの対話の会話モデルを実装します。クライアント・アプリケーションがオブジェクト参照を持っているかぎり、追加のリクエストに対してオブジェクトが常に使用可能であるとみなされ、オブジェクトはクライアント・アプリケーションがそのオブジェクトと対話している間メモリー内に継続して保持されているように見えます。

最適なアプリケーション・パフォーマンスを実現するには、アプリケーションのオブジェクトで状態を管理する方法を慎重に計画する必要があります。オブジェクトは、永続ストレージ(該当する場合)に状態を保存してから、非アクティブ化する必要があります。また、オブジェクトは、アクティブ化する際に永続ストレージ(該当する場合)の状態を復元する必要があります。オブジェクト状態情報の読取りと書込みの詳細は、1-14ページの「オブジェクトのデータの読取りと書込み」という項を参照してください。

注意:	Oracle Tuxedoリリース8.0以降では、パフォーマンスの拡張を目的としてパラレル・オブジェクトがサポートされます。この機能を使用すると、特定のアプリケーション内のすべてのビジネス・オブジェクトをステートレス・オブジェクトとして指定できます。詳細は、『CORBAプログラミング・リファレンス』の第3章「TPフレームワーク」を参照してください。

オブジェクトのアクティブ化ポリシー

Oracle Tuxedoソフトウェアには、3つのオブジェクトのアクティブ化ポリシーが用意されています。これらのポリシーをオブジェクトのインタフェースに割り当てることで、オブジェクトがクライアント・リクエストによって呼び出された後にメモリー内に保持される期間を指定できます。これらのポリシーによって、適用先のオブジェクトが一般にステートレスであるか、ステートフルであるかが設定されます。

表1-2に、3つのポリシーとその説明を示します。

 

表1-2 オブジェクトのアクティブ化ポリシー

ポリシー	説明
Method	オブジェクトは、自身の操作の1つの呼出しの間に限定してアクティブ化されます。つまり、オブジェクトは呼出しの開始時にアクティブ化され、呼出しの終了時に非アクティブ化されます。このアクティブ化ポリシーが適用されるオブジェクトを、メソッド・バウンド・オブジェクトと呼びます。 methodアクティブ化ポリシーは、ステートレス・オブジェクトに関連付けられます。このアクティブ化ポリシーはデフォルト。
Transaction	操作が呼び出されたときにオブジェクトをアクティブ化します。オブジェクトがトランザクションのスコープ内でアクティブ化された場合、そのオブジェクトはトランザクションがコミットまたはロールバックされるまでは、アクティブ化されたままです。オブジェクトがトランザクションのスコープの外でアクティブ化された場合、その動作はメソッド・バウンド・オブジェクトと同じです。このアクティブ化ポリシーが適用されるオブジェクトを、トランザクション・バウンド・オブジェクトと呼びます。 トランザクションのスコープ内のオブジェクトの動作、およびこのポリシーを使用するための一般的なガイドラインについては、第6章「トランザクションのCORBAサーバー・アプリケーションへの統合」を参照してください。 transactionアクティブ化ポリシーは、期間が制限され、特定の環境に置かれているステートフル・オブジェクトに関連付けられます。
Process	オブジェクトは、自身の操作が呼び出されたときにアクティブ化され、次の環境下でのみ非アクティブ化されます。 • このオブジェクトを管理するサーバー・プロセスが停止されました。 • このオブジェクトの操作によってTP::deactivateEnable()操作が呼び出され、その結果このオブジェクトが非アクティブ化されました。(これは、アプリケーション制御の非アクティブ化と呼ばれるOracle Tuxedoの主要機能の一部。詳細は、-13ページの「アプリケーション制御の非アクティブ化」という項を参照。) このアクティブ化ポリシーが適用されるオブジェクトを、プロセス・バウンド・オブジェクトと呼びます。processアクティブ化ポリシーは、ステートフル・オブジェクトに関連付けられます。

オブジェクトのアクティブ化ポリシーを割り当てて、オブジェクトが非アクティブ化される原因となるイベントを決定します。オブジェクトのアクティブ化ポリシーをオブジェクトのインタフェースに割り当てる方法の詳細は、2-13ページの「ステップ4: メモリー内でのオブジェクトの振る舞いの定義」という項を参照してください。

アプリケーション制御の非アクティブ化

Oracle Tuxedoソフトウェアには、アプリケーション制御の非アクティブ化という機能も用意されています。この機能を使用すると、アプリケーションは実行時にオブジェクトを非アクティブ化できます。Oracle Tuxedoソフトウェアは、プロセス・バウンド・オブジェクトが自身に対して呼び出すことができるTP::deactivateEnable()操作を提供しています。TP::deactivateEnable()操作が呼び出されると、その操作が存在するオブジェクトは自身に対する現在のクライアント呼出しの完了時に非アクティブ化されます。オブジェクトは、自身に対してだけこの操作を呼び出すことができます。呼出しが行われれているオブジェクト以外のオブジェクトでこの操作を呼び出すことはできません。

アプリケーション制御の非アクティブ化機能は、オブジェクトに対する一定数のクライアント呼出しの間に限定してそのオブジェクトをメモリーに保持し、クライアント・アプリケーションからオブジェクトにそのオブジェクトの処理が終了したことを通知できるようにする場合に特に役立ちます。この時点で、オブジェクトはメモリーの外に移動します。

したがって、アプリケーション制御の非アクティブ化を使用すると、オブジェクトはプロセス・バウンド・オブジェクトと同じようにメモリーに保持されます。つまり、オブジェクトは自身に対するクライアント呼出しによってアクティブ化され、その初期クライアント呼出しの完了後もメモリーに保持されます。その後、オブジェクトが存在するサーバー・プロセスを停止せずにオブジェクトを非アクティブ化できます。

アプリケーション制御の非アクティブ化のかわりの方法は、トランザクションをスコープしてクライアント・アプリケーションとオブジェクト間の会話を管理することです。ただし、トランザクションは本質的にコストが高く、一般にその期間が不定の状態では適していません。

会話に対してアプリケーション制御の非アクティブ化またはトランザクションを選択する際の経験則は、関与するディスク書込み操作があるかどうかです。会話に読取り専用操作が関与するか、メモリーのみでの状態の保持が関与する場合は、アプリケーション制御の非アクティブ化が適切です。会話中または会話の最後にデータのディスクへの書込みが行われる場合は、トランザクションがより適切です。

注意:

アプリケーション制御の非アクティブ化を使用して、クライアント・アプリケーションとサーバー・アプリケーションによって管理されるオブジェクト間の会話モデルを実装する場合、オブジェクトは最終的にTP::deactivateEnable()操作を呼び出す必要があります。呼び出さない場合、オブジェクトはメモリー内で永久的にアイドル状態に置かれます。これは、TP::deactivateEnable()操作の呼出し前にクライアント・アプリケーションがクラッシュした場合に危険を招くおそれがあります。一方、トランザクションはタイムアウト・メカニズムを実装して、オブジェクトが永久的にアイドル状態に置かれることを防ぎます。これは、2つの会話モデルのいずれかを選択する際のもう1つの考慮事項です。

アプリケーション制御の非アクティブ化は、次の手順を使用してオブジェクトに実装します。

1.	実装ファイルで、アプリケーション制御の非アクティブ化を使用するインタフェースの操作内の適切な位置にTP::deactivateEnable()操作の呼出しを挿入します。

2.	実装構成ファイル(ICFファイル)で、プロセス・バウンド・アクティブ化ポリシーを、TP::deactivateEnable()操作を呼び出す操作が含まれるインタフェースに割り当てます。

3.	2-16ページの「ステップ5: サーバー・アプリケーションのコンパイルとリンク」と2-16ページの「ステップ6: サーバー・アプリケーションのデプロイ」という項で説明するとおり、アプリケーションをビルドおよびデプロイします。

オブジェクトのデータの読取りと書込み

サーバー・アプリケーションで管理されるCORBAオブジェクトの多くに、外部ストレージに格納されたデータがある場合があります。こうした外部に格納されているデータは、オブジェクトの恒久または永続状態とみなされます。オブジェクト状態管理が適切に機能するには、オブジェクト実装の適切なポイントで永続状態を処理する必要があります。

オブジェクトの永続状態の読取りと書込みに関するクライアント/サーバー・アプリケーションの様々な要件のために、TPフレームワークはディスク上の永続オブジェクト状態を自動的に処理できません。一般に、オブジェクトの永続状態が1つ以上のクライアント呼出しによって修正される場合、そのオブジェクトが非アクティブ化される前に永続状態を保存する必要があります。また、オブジェクトがアクティブ化されている間にどのようにオブジェクトのデータを格納または初期化するかを注意深く計画する必要があります。

以降の項では、オブジェクトの永続状態を処理するためのメカニズムについて説明し、特定の環境でオブジェクト状態を読み書きする方法についての一般的なヒントを示します。具体的なトピックは次のとおりです。

•	オブジェクトの永続状態を読み書きするためのメカニズム

•	オブジェクトのアクティブ化時の状態の読取り

•	オブジェクトの個々の操作での状態の読取り

•	ステートレス・オブジェクトと永続状態

•	ステートフル・オブジェクトと永続状態

•	オブジェクトの非アクティブ化の責任

•	不必要なI/Oの回避

永続状態の読取りおよび書込みの選択方法は、特にデータの構造化方法に関するクライアント/サーバー・アプリケーションの特定の要件によって、常に異なります。通常、特にXAリソース・マネージャによって制御されるデータベースが関与する場合、ディスク操作の数を最小限に抑えることを優先する必要があります。

オブジェクトの永続状態を読み書きするためのメカニズム

表1-3と表1-4に、オブジェクトの永続状態を読み書きするために使用可能なメカニズムを示します。

 

表1-3 オブジェクトの永続状態を読み取るためのメカニズム

メカニズム	説明
Tobj_ServantBase:: activate_object()	TPフレームワークは、オブジェクトのサーバントの作成後に、そのサーバントに対してTobj_ServantBase::activate_object()操作を呼び出します。1-6ページの「CORBAオブジェクトの実行時のインスタンス化」という項で説明したように、この操作はクライアント/サーバー・アプリケーション用に定義するすべてのCORBAオブジェクトが継承するTobj_ServantBaseベース・クラスで定義されます。 オブジェクトのTobj_ServantBase::activate_object()操作を定義および実装しないことを選択することもできます。この場合、TPフレームワークがオブジェクトをアクティブ化したときに特定のオブジェクト状態の処理に関しては何も発生しません。ただし、この操作を定義および実装する場合、オブジェクトの永続状態の一部または全部をメモリーに読み取るコードを操作に組み込むことができます。このため、Tobj_ServantBase::activate_object()操作を使用すると、サーバー・アプリケーションには、オブジェクトの永続状態をメモリーに読み取るための最初の機会が与えられます。 オブジェクトのOIDにデータベース・キーが含まれている場合、Tobj_ServantBase::activate_object()操作はそのキーをOIDから抽出するための唯一の手段を提供します。 Tobj_ServantBase::activate_object()操作の実装の詳細は、2-5ページの「ステップ2: 各インタフェースの操作を実装するメソッドの記述」を参照してください。Tobj_ServantBase::activate_object()操作の実装の例は、第3章「Basic CORBAサーバー・アプリケーションの設計と実装」を参照してください。
オブジェクトの操作	オブジェクトで定義する個々の操作の内部に、オブジェクトの永続状態を読み取るコードを組み込むことができます。

 

表1-4 オブジェクトの永続状態を書き込むためのメカニズム

メカニズム	説明
Tobj_ServantBase:: deactivate_object()	オブジェクトがTPフレームワークによって非アクティブ化される場合、TPフレームワークはオブジェクト非アクティブ化の最終ステップとしてこの操作を呼び出します。Tobj_ServantBase::activate_object()操作と同様、Tobj_ServantBase::deactivate_object()操作もTobj_ServantBaseクラスで定義されます。オブジェクトのdeactivate_object()操作は、メモリーからフラッシュするか、またはデータベースに書き込む特定のオブジェクト状態が存在する場合にオプションで実装します。 Tobj_ServantBase::deactivate_object()操作は、サーバー・アプリケーションに、オブジェクトの非アクティブ化前に永続状態をディスクに書き込む最後の機会を提供します。 オブジェクトがメモリー内のデータを保持するか、任意の目的のためにメモリーを割り当てる場合、Tobj_ServantBase::deactivate_object()操作を実装してオブジェクトが最後にメモリーからデータをフラッシュできるようにします。オブジェクトの非アクティブ化前にメモリーから状態をフラッシュすることは、メモリー・リークを回避するために不可欠です。
オブジェクトの操作	ディスクから永続状態を読み取る個々の操作をオブジェクト上で持つことができるように、永続状態をディスクに書き込む個々の操作を持つことができます。 一般に、メソッド・バウンド・オブジェクトとプロセス・バウンド・オブジェクトの場合、データベース書込み操作はこれらの操作の中で実行し、Tobj_ServantBase::deactivate_object()操作では実行しません。 ただし、トランザクション・バウンド・オブジェクトの場合、Tobj_ServantBase::deactivate_object()操作で永続状態を書き込むと、トランザクション・サーバー・アプリケーションにとって意味のあるオブジェクト管理上の効率化が実現されます。

注意:

Tobj_ServantBase::deactivate_object()操作を使用して永続状態をディスクに書き込む場合、ディスクへの書込み中に発生するエラーはクライアント・アプリケーションにはレポートされません。このため、この操作でデータをディスクに書き込む必要があるのは、オブジェクトがトランザクション・バウンドの場合(transactionアクティブ化ポリシーが割り当てられている場合)か、またはTransactionCurrentオブジェクトを呼び出すことによってトランザクション内でディスク書込み操作をスコープする場合です。トランザクション内でディスクへの書込み中に発生したエラーは、クライアント・アプリケーションにレポートできます。Tobj_ServantBase::deactivate_object()操作を使用してオブジェクト状態をディスクに書き込む方法の詳細は、2-25ページの「Tobj_ServantBase::deactivate_object()での状態処理に関する注意」という項を参照してください。

オブジェクトのアクティブ化時の状態の読取り

オブジェクトのTobj_ServantBase::activate_object()操作を使用した永続状態の読取りは、次の条件のいずれかが存在するときに適しています。

•	オブジェクトのすべての操作でオブジェクト・データが常に使用または更新されます。

•	オブジェクトのすべてのデータを1つの操作で読み取ることができます。

Tobj_ServantBase::activate_object()操作を使用した永続状態の読取りには、次のメリットがあります。

•	オブジェクト・データを使用する各操作でコードを複製するかわりに、データを読み取るコードを1度記述するだけで済みます。

•	オブジェクトのデータを使用する操作は、そのデータの読取りを実行する必要がありません。この意味で、状態の初期化に依存しない方法で操作を書き込むことができます。

オブジェクトの個々の操作での状態の読取り

アクティブ化ポリシーに関係なく、どのオブジェクトを使用する場合も、そのデータを必要とする各操作で永続データを読み取ることができます。つまり、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つのサーバー・プロセスが同じディスク・データに同時にアクセスする可能性を考慮する必要がある場合があります。この場合、同時実行性管理テクニックを検討する必要があり、その最も簡単なテクニックはトランザクションです。トランザクションおよびトランザクション・オブジェクトの詳細は、第6章「トランザクションのCORBAサーバー・アプリケーションへの統合」を参照してください。

サーバント・プールとステートレス・オブジェクト

サーバント・プールは、ステートレス・オブジェクトに特に役立つ機能です。CORBAサーバー・アプリケーションによってサーバントがプールされると、クライアントがオブジェクトを呼び出すたびにオブジェクトをインスタンス化するコストを大幅に削減できます。-7ページの「サーバント・プール」という項で説明したとおり、プールされたサーバントは、そのクライアント呼出しの完了後もメモリーに保持されます。アプリケーションで特定のオブジェクトを繰り返し呼び出す可能性がある場合、サーバントをプールすると、各クライアントに対してオブジェクトのメソッドではなくデータだけをメモリーに読み取り、メモリーから書き込むだけで済みます。オブジェクトのメソッドをメモリーに読み取るコストが高い場合、サーバント・プールによってそのコストを低減できます。

サーバント・プールを実装する方法の詳細は、2-25ページの「サーバント・プール」という項を参照してください。

ステートフル・オブジェクトと永続状態

ステートフル・オブジェクトの場合、必要な場合にのみ永続状態を読み書きする必要があります。これにより、次の最適化が実現できる場合があります。

•	プロセス・バウンド・オブジェクトの場合、オブジェクトが長期間にわたって大量のメモリーを割り当てる状態を回避します。

•	トランザクション・バウンド・オブジェクトの場合、トランザクションの結果がわかっているときには、Tobj_ServantBase::deactivate_object()操作が呼び出されるまで永続状態の書込みを延期できます。

一般に、トランザクション・バウンド・オブジェクトは、すべてのデータベース書き込みまたはロールバック操作を自動的に処理するXAリソース・マネージャに依存する必要があります。

注意:	トランザクションに関与するオブジェクトの場合、XAリソース・マネージャによって管理されない外部ストレージへのオブジェクトのデータ書込みはサポートされません。

オブジェクトとトランザクションの詳細は、第6章「トランザクションのCORBAサーバー・アプリケーションへの統合」を参照してください。

サーバント・プールとステートフル・オブジェクト

サーバント・プールは、プロセス・バウンド・オブジェクトに対しては意味を持ちません。ただし、アプリケーション設計によっては、サーバント・プールによってトランザクション・バウンド・オブジェクトのパフォーマンスが向上する場合があります。

オブジェクトの非アクティブ化の責任

前項で説明したとおり、Tobj_ServantBase::deactivate_object()操作は、オブジェクトの永続状態をディスクに書き込むための手段として実装します。また、この操作は、保持されているオブジェクト・データをメモリーからフラッシュして、オブジェクトのサーバントでそのオブジェクトの別のインスタンスをアクティブ化できるようにするためにも使用されます。ただし、オブジェクトのTobj_ServantBase::deactivate_object()操作の呼出しによってそのオブジェクトのデストラクタも呼び出されると見なしてはなりません。

不必要なI/Oの回避

オブジェクトで不必要なI/Oを行うことによってアプリケーションの効率を下げないよう注意する必要があります。次のような状況を認識する必要があります。

•	オブジェクトの多くの操作がオブジェクト状態を使用しないか、またはオブジェクト状態に影響を与えない場合、これらの操作が呼び出されるたびに状態を読み書きすることは非効率です。設計を修正して、これらのオブジェクトが状態を必要とする操作でのみ状態を処理するようにします。この場合、オブジェクトのアクティブ化でそのすべての永続状態が読み取られないようにすることができます。

•	オブジェクト状態が複数の操作で読み込まれるデータで構成されている場合、次のいずれかを行うことによって、オブジェクトの呼出し時に必要な操作だけを行うようにします。

•	すべての操作に共通の状態のみをTobj_ServantBase::activate_object()操作で読み取ります。それ以外の状態の読取りは、それらを必要とする操作のみで行うようにします。

•	変更された状態のみを書き込みます。そのためには、アクティブ化中に変更されたデータを示すフラグを管理するか、ビフォー・データ・イメージとアフター・データ・イメージを比較します。

一般的な最適化の方法は、アクティブ化時にdirtyStateフラグを初期化し、オブジェクトのアクティブ化中にこのフラグが変更された場合にのみTobj_ServantBase::deactivate_object()操作でデータを書き込むことです。(ただし、これはオブジェクトが常に同じサーバント・プロセスでアクティブ化されると保証できる場合にだけ使用できます。)

アクティブ化のサンプル

オブジェクトがアクティブ化されるときに行われる一連のアクティビティの例については、『Oracle Tuxedo CORBAアプリケーション・スタート・ガイド』を参照してください。

デザイン・パターンの使い方

アプリケーションのビジネス・ロジックを、形式の正しい設計に基づいて構造化することが重要です。Oracle Tuxedoソフトウェアには、このニーズに対処するための一連のデザイン・パターンが用意されています。デザイン・パターンは、単に、特定の設計上の問題に対する構造化されたソリューションです。デザイン・パターンの価値は、再利用して、別の設計上の問題に適用可能な形式で表すことができる点にあります。

Oracle Tuxedoデザイン・パターンは、エンタープライズ・クラスのアプリケーション設計の問題に対する構造化されたソリューションです。デザイン・パターンを使用して、正常な大規模クライアント/サーバー・システムを設計できます。

ここで説明するデザイン・パターンは、CORBAクライアント/サーバー・アプリケーションで適切な設計手法を使用するためのガイドです。これらのデザイン・パターンはCORBAクライアント・アプリケーションおよびサーバー・アプリケーションの設計の主要な構成部分です。このマニュアルの各章には、これらのデザイン・パターンを使用してUniversityサンプル・アプリケーションを実装する方法が示されています。

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

Process-Entityデザイン・パターンは、大規模なエンタープライズ・クラスのクライアント/サーバー・アプリケーションに適用されます。このデザイン・パターンは、『Object-Oriented Design Patterns』(Gamma他著)ではFlyweightパターンと呼ばれ、他の出版物ではモデル/ビュー/コントローラと呼ばれています。

このパターンでは、クライアント・アプリケーションは、存続期間が長いプロセス・オブジェクトを作成し、これと対話してリクエストを作成します。たとえば、Universityサンプル・アプリケーションでは、このオブジェクトは、クライアント・アプリケーションにかわってコース参照操作を処理する登録事務係である場合があります。コース自体はデータベース・エンティティであり、クライアント・アプリケーションからは見えません。

Process-Entityデザイン・パターンのメリットは次のとおりです。

•	細粒度オブジェクトを実装せずに細粒度オブジェクトのメリットを実現できます。かわりに、CORBAのstructデータ型を使用して、オブジェクトをシミュレートします。

•	メモリーにマッピングされるオブジェクトが1つのみであるため、マシン・リソースの使用が最適化されます。対照的に、大規模なデプロイメントでは、各データベース・エンティティが独立したオブジェクト・インスタンスとしてメモリーにアクティブ化される場合、処理する必要があるオブジェクトの数によってマシンのリソースが急激に消費されてしまいます。

•

データベース・エンティティがクライアント・アプリケーションに対して公開されていないため、データベース・エンティティをCORBAオブジェクトとして実装する必要がありません。かわりに、エンティティをサーバー・プロセスのローカル言語オブジェクトとして実装できます。これは3層設計の基本原則ですが、多くのビジネスの機能(たとえば、実際の大学の登録事務係)を正確にモデル化します。大学の登録事務係である個人は、複数の学生に関連して大規模なコース・データベースを処理できます。学生ごとに1人ずつの登録事務係は必要ありません。したがって、プロセス・オブジェクト状態は、エンティティ・オブジェクト状態とは異なります。

Process-Entityデザイン・パターンの適用例については、第3章「Basic CORBAサーバー・アプリケーションの設計と実装」を参照してください。Process-Entityデザイン・パターンの詳細は、『テクニカル・アーティクル』を参照してください。

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

List-Enumeratorデザイン・パターンも、大規模なエンタープライズ・クラスのクライアント/サーバー・アプリケーションに適用されます。List-Enumeratorデザイン・パターンは、Oracle Tuxedoの主要機能であるアプリケーション制御のオブジェクト・アクティブ化を利用して、複数のクライアント呼出しの間メモリー内で保持および追跡されるデータのキャッシュを処理し、不要になったときにそのデータをメモリーからフラッシュします。

List-Enumeratorデザイン・パターンの適用例については、第3章「Basic CORBAサーバー・アプリケーションの設計と実装」を参照してください。

List-Enumeratorデザインの実装に特に役立つツールであるオブジェクトの事前アクティブ化の詳細は、3-15ページの「状態を持つオブジェクトの事前アクティブ化」という項を参照してください。