![]() ![]() ![]() ![]() ![]() ![]() ![]() |
このトピックではProductionサンプル・アプリケーションを例として使用し、CORBA C++アプリケーションをスケーリングして処理能力を高める方法を示します。事前に、必ず次の個所をお読みください。
Productionサンプル・アプリケーションには、Wrapperサンプル・アプリケーションと同じエンド・ユーザー向けの機能が用意されています。Productionサンプル・アプリケーションでは、Oracle Tuxedoソフトウェアの機能を使用して既存のOracle Tuxedoアプリケーションをスケーリングする方法が示されます。
Productionサンプル・アプリケーションの設計上の主な目標は、次の処理により、対応できるクライアント・アプリケーションの数を大幅に増やすことです。
これらの設計上の目標に対応するため、Productionサンプル・アプリケーションは次のようにしてスケーリングされています。
UBBCONFIG
ファイルで定義されているORA_GRP
サーバー・グループおよびAPP_GRP
サーバー・グループです。ORA_GRP
サーバー・グループおよびAPP_GRP
サーバー・グループを追加のサーバー・マシンであるProductionマシン2上で複製し、データベースの分割も行います。注意: | Productionサンプル・アプリケーションの使用を簡単にするには、1つのデータベースを使い、1つのマシン上で実行されるように、アプリケーションをOracle Tuxedoソフトウェア・キット上で構成します。ただし、この章で示した例では、アプリケーションは2つのデータベースを使って2つのマシン上で動作しています。 |
注意: | Productionサンプル・アプリケーションは、数台のマシン上で動作し、複数のデータベースを使用すべく構成できるよう設計されています。構成を複数のマシンとデータベース用に変更するには、UBBCONFIG ファイルを修正して、データベースをパーティション化する必要があります。この手順は、「アプリケーションをさらにスケーリングする方法」で説明しています。 |
以下の項では、Productionサンプル・アプリケーションが複製されたサーバー・プロセスとサーバー・グループ、オブジェクト状態管理、およびファクトリ・ベース・ルーティングをどのように使用して、スケーラビリティの目標を達成するかを説明します。
Productionサンプル・アプリケーションでのOMG IDLの変更は、RegistrarFactory
オブジェクトのfind_registrar()
オペレーション、およびTellerFactory
オブジェクトのfind_teller()
オペレーションに限定されています。2つのオペレーションは、それぞれ学生IDと口座番号を要求するように修正する必要があります。これらは、ファクトリ・ベース・ルーティングの実装に必要なものです。Productionサンプル・アプリケーションでのファクトリ・ベース・ルーティングの実装と使用については、「ファクトリ・ベース・ルーティングによるスケーリング」を参照してください。
ここでは、Productionサンプル・アプリケーションにおいて、スケーラビリティを増大させるために、オブジェクト状態管理をどのようにRegistrar
オブジェクトおよびTeller
オブジェクトで使用するかを説明します。オブジェクト状態管理の概要は、「オブジェクト状態管理の使用」を参照してください。
スケーラビリティを増大させるには、Productionサーバー・アプリケーションで、Registrar
およびTeller
オブジェクトにmethod
アクティブ化ポリシーを構成します。これら2つのオブジェクトにmethod
アクティブ化ポリシーを割り当てた結果、動作に次の変化がみられます。
BasicからWrapperまでの各種サンプル・アプリケーションでは、Registrar
オブジェクトはプロセス・バウンド・オブジェクト(process
アクティブ化ポリシー)となっていました。Registrar
オブジェクトに対するクライアント・リクエストはすべて、常にサーバー・マシンのメモリー内の同じオブジェクト・インスタンスに送られました。Basicサンプル・アプリケーションの設計は、小規模なデプロイメントに適しています。しかし、クライアント・アプリケーションのリクエストが増すにつれて、Registrar
オブジェクト上のクライアント・リクエストはキューに入れられるようになるため、レスポンス時間が遅くなります。
ただし、Registrar
およびTeller
オブジェクトがステートレス・オブジェクト(method
アクティブ化ポリシー)であり、これらのオブジェクトを管理するサーバー・プロセスがレプリケートされている場合、Registrar
およびTeller
の各オブジェクトは並行して複数のクライアント・リクエストを処理できます。これらのオブジェクトで処理できる同時のクライアント・リクエストの数で制約があるのは、Registrar
およびTeller
のオブジェクトをインスタンス化できる、利用可能なサーバー・プロセスの数のみです。したがって、これらのステートレス・オブジェクトはマシン・リソースのより効率的な使用と、クライアント・レスポンス時間の短縮を実現します。
最も重要なのは、Oracle Tuxedo CORBAで、Registrar
およびTeller
オブジェクトのコピーを各複製サーバー・プロセス内でインスタンス化できるように、オブジェクトの各コピーがユニークでなければならないことです。これらのオブジェクトの各インスタンスをユニークにするために、オブジェクトのファクトリではユニークなオブジェクトIDをオブジェクトに割り当てる必要があります。
Oracle Tuxedoアプリケーションが複製サーバー・アプリケーション・プロセスのそれぞれでRegistrar
およびTeller
オブジェクトのコピーをインスタンス化するには、オブジェクトの各コピーが一意のオブジェクトID (OID)を備えていなければなりません。ユニークなOIDは、これらのオブジェクトを作成するファクトリで割り当てられます。ユニークなオブジェクトIDの生成についての詳細は、『CORBAサーバー・アプリケーションの作成』を参照してください。その他の設計上の考慮事項については、「設計上の追加考慮事項」を参照してください。
このトピックでは、サーバー・プロセスおよびサーバー・グループを複製することによる、Productionサンプル・アプリケーションのスケーリング方法を説明します。概要については、「サーバー・プロセスおよびサーバー・グループの複製」を参照してください。
この項では、Productionサンプル・アプリケーションによるサーバー・アプリケーションの複製方法を説明します。この機能の概要については、「サーバー・プロセスの複製」を参照してください。
図2-1では、単一のマシン上で実行される、複製されたORA_GRP
およびAPP_GRP
グループを示します。
これらのグループの1つにリクエストが到達したとき、Oracle Tuxedoドメインにはこのリクエストを処理できるサーバー・プロセスがいくつかあります。Oracle Tuxedoドメインは、最も負荷の軽いサーバー・プロセスを選択することができます。
図2-1では、次の点に留意してください。
この項では、Productionサンプル・アプリケーションによるサーバー・グループの複製方法を説明します。この機能の概要については、「サーバー・グループの複製」を参照してください。
図2-2は、別のマシンにレプリケートされたProductionサンプル・アプリケーションのグループを示しており、このアプリケーションのUBBCONFIG
ファイルに指定されているとおり、ORA_GRP2
とAPP_GRP2
があります。
図2-2では、Productionマシン1と2のグループの内容で異なるのはデータベースのみです。
注意: | 双方のデータベースのコース情報表は同じものです。 |
所定のデータベース内の学生情報は、同じデータベース内の口座情報とはまったく関係がない場合があります。
Productionサンプル・アプリケーションがファクトリ・ベース・ルーティングを使用して、複数のマシン間にアプリケーションの処理負荷を分散する方法の詳細は、「ファクトリ・ベース・ルーティングによるスケーリング」を参照してください。
リスト2-1は、Productionサンプル・アプリケーションのUBBCONFIG
ファイルのGROUPS
セクションおよびSERVERS
セクションからの抜粋です。
*GROUPS
APP_GRP1
LMID = SITE1
GRPNO = 2
TMSNAME = TMS
APP_GRP2
LMID = SITE1
GRPNO = 3
TMSNAME = TMS
ORA_GRP1
LMID = SITE1
GRPNO = 4
OPENINFO = "ORACLE_XA:Oracle_XA+Acc=P/scott/..."
CLOSEINFO = ""
TMSNAME = "TMS_ORA"
ORA_GRP2
LMID = SITE1
GRPNO = 5
OPENINFO = "ORACLE_XA:Oracle_XA+Acc=P/scott/..."
CLOSEINFO = ""
TMSNAME = "TMS_ORA"
*SERVERS
# By default, activate 2 instances of each server
# and allow the administrator to activate up to 5
# instances of each server
DEFAULT:
MIN = 2
MAX = 5
tellp_server
SRVGRP = ORA_GRP1
SRVID = 10
RESTART = N
tellp_server
SRVGRP = ORA_GRP2
SRVID = 10
RESTART = N
billp_server
SRVGRP = APP_GRP1
SRVID = 10
RESTART = N
billp_server
SRVGRP = APP_GRP2
SRVID = 10
RESTART = N
univp_server
SRVGRP = ORA_GRP1
SRVID = 20
RESTART = N
univp_server
SRVGRP = ORA_GRP2
SRVID = 20
RESTART = N
このトピックでは、ファクトリ・ベース・ルーティングを使用してProductionサンプル・アプリケーションをスケーリングする方法について説明します。ファクトリ・ベース・ルーティングの概要については、「ファクトリ・ベース・ルーティングの使用(CORBAサーバーのみ)」を参照してください。
この項では、Productionサンプル・アプリケーションがどのようにファクトリ・ベース・ルーティングを使用するかを説明します。この機能の概要については、「ファクトリ・ベース・ルーティングの使用(CORBAサーバーのみ)」を参照してください。
ファクトリ・ベース・ルーティングを使用すると、Oracle Tuxedo CORBAのロード・バランシング機能およびスケーラビリティ機能を拡張できます。Productionサンプル・アプリケーションでは、ファクトリ・ベース・ルーティングを使用して、1つのマシンに1つの学生のサブセットを登録するリクエストを、別のマシンに別の学生のサブセットを登録するリクエストを送信できます。アプリケーションの処理機能を向上させると、アプリケーション内でのファクトリ・ベース・ルーティングを簡単に変更して、マシンをさらに追加できます。
Productionサンプル・アプリケーションでのファクトリ・ベース・ルーティングの実装に関する設計上の主な考慮事項は、ルーティングの基準となる値の選択です。Productionサンプル・アプリケーションは、次のようにファクトリ・ベース・ルーティングを使用します。
Registrar
オブジェクトへのリクエストは、学生IDに基づいてルーティングされます。IDが100001
- 100005
の学生からのリクエストは、Productionマシン1にルーティングされます。IDが100006
- 100010
の学生からのリクエストは、Productionマシン2にルーティングされます。Registrar
オブジェクトからTeller
オブジェクトへのリクエストは、口座番号に基づいてルーティングされます。200010
から200014
までの口座番号への支払いリクエストは、Productionマシン1にルーティングされます。200015
から200019
までの口座番号への支払いリクエストは、Productionマシン2にルーティングされます。 University Productionサンプル・アプリケーションでは、ファクトリ・ベース・ルーティングの実装方法が例示されます。ubb_b.nt
構成ファイルからのINTERFACES、ROUTING
、およびGROUPS
セクションでは、Oracle Tuxedo CORBAアプリケーションでファクトリ・ベース・ルーティングを実装する方法が示されます。このサンプルのubb_p.nt
またはubb_p.mk
UBBCONFIG
ファイルは、Oracle Tuxedoソフトウェアをインストールしたディレクトリで見つけることができます(\samples\corba\university\production
サブディレクトリを参照)。
UBBCONFIG
ファイルでは、グループおよびマシンの識別方法に加えて、INTERFACES
およびROUTING
セクションにおいて、以下のデータを指定する必要があります。
INTERFACES
セクションには、ファクトリ・ベース・ルーティングを有効にするインタフェースの名前がリストされています。各インタフェースについて、このセクションではインタフェースがルーティングを行う基準の種類を指定します。このセクションでは、リスト2-2
に示すように、FACTORYROUTINGという識別子を使用してルーティング基準を指定します。INTERFACES
"IDL:beasys.com/UniversityP/Registrar:1.0"
FACTORYROUTING = STU_ID
"IDL:beasys.com/BillingP/Teller:1.0"
FACTORYROUTING = ACT_NUM
リスト2-2は、ファクトリ・ベース・ルーティングが使用されているProductionサンプルの2つのインタフェースの完全修飾インタフェース名を示します。また、FACTORYROUTING
識別子によって、ルーティング値の名前がそれぞれSTU_ID
とACT_NUM
に指定されています。
ROUTING
セクションは、各ルーティング値について、表2-1に記載のパラメータを指定します。 リスト2-3は、Productionサンプル・アプリケーションで使用されるUBBCONFIG
ファイルのROUTING
セクションを示しています。
ROUTING
STU_ID
FIELD = "student_id"
TYPE = FACTORY
FIELDTYPE = LONG
RANGES = "100001-100005:ORA_GRP1,100006-100010:ORA_GRP2"
ACT_NUM
FIELD = "account_number"
TYPE = FACTORY
FIELDTYPE = LONG
RANGES = "200010-200014:APP_GRP1,200015-200019:APP_GRP2"
リスト2-3は、ある1つの範囲のIDを持つ学生に対するRegistrar
オブジェクト参照が、ある1つのサーバー・グループにルーティングされ、別の範囲のIDを持つ学生に対するRegistrar
オブジェクト参照が、別のグループにルーティングされることを示します。同様に、ある1つの範囲の口座に対するTeller
オブジェクト参照は、ある1つのサーバー・グループにルーティングされ、別の範囲の口座に対するTeller
オブジェクト参照は、別のグループにルーティングされます。
UBBCONFIG
ファイルのROUTING
セクションでRANGES
識別子によって指定されたグループを、識別して構成する必要があります。たとえば、ProductionサンプルはAPP_GRP1
、APP_GRP2
、ORA_GRP1
、およびORA_GRP2
という4つのグループを指定します。これらのグループを構成し、グループが実行されるマシンを識別する必要があります。 リスト2-4は、ProductionサンプルのUBBCONFIG
ファイルにおける、GROUPS
セクションを示し、ここでORA_GRP1
およびORA_GRP2
の各グループが構成されます。GROUPS
セクション内の名前と、ROUTING
セクションのRANGES
パラメータで指定されたグループ名がどのように一致しているかに注目してください。これは、ファクトリ・ベース・ルーティングが正しく機能するために重要です。また、アプリケーションでグループを構成する際にグループ名を変更した場合は、ROUTING
セクションにも反映する必要があります。(Oracle TuxedoソフトウェアとともにパッケージされているProductionサンプルは1台のマシンでのみ実行できるように構成されている点に注意してください。ただし、このアプリケーションを複数のマシンで実行できるように構成することは簡単です。)
*GROUPS
APP_GRP1
LMID = SITE1
GRPNO = 2
TMSNAME = TMS
APP_GRP2
LMID = SITE1
GRPNO = 3
TMSNAME = TMS
ORA_GRP1
LMID = SITE1
GRPNO = 4
OPENINFO = "ORACLE_XA:Oracle_XA+Acc=P/scott/tiger+SesTm=100+LogDir=.+MaxCur=5"
CLOSEINFO = ""
TMSNAME = "TMS_ORA"
ORA_GRP2
LMID = SITE1
GRPNO = 5
OPENINFO = "ORACLE_XA:Oracle_XA+Acc=P/scott/tiger+SesTm=100+LogDir=.+MaxCur=5"
CLOSEINFO = ""
TMSNAME = "TMS_ORA"
ファクトリでは、TP::create_object_reference()
オペレーションに対する呼出しの実装と同様の方式でファクトリ・ベース・ルーティングが行われます。このオペレーションには、リスト2-5のC++バインディングがあります。
CORBA::Object_ptr TP::create_object_reference (
const char* interfaceName,
const PortableServer::oid &stroid,
CORBA::NVlist_ptr criteria);
この操作に対する3番目のパラメータであるcriteria
は、ファクトリ・ベース・ルーティングに使用される、名前の付いた値を指定します。ファクトリ内でファクトリ・ベース・ルーティングを実装するには、NVlist
をビルドする必要があります。ファクトリ・ベース・ルーティングの使用はオプションであり、この引数に依存します。ファクトリ・ベース・ルーティングを使用するかわりに、この引数に0
(ゼロ)の値を渡すこともできます。
前述のように、Productionサンプル・アプリケーションのRegistrarFactory
オブジェクトは、値STU_ID
を指定します。この値は、UBBCONFIG
ファイルの次の項目と正確に一致する必要があります。
RegistrarFactory
オブジェクトは、リスト2-6
に記載のコードを使用して、学生IDをNVlistに挿入します。
// put the student id (which is the routing criteria)
// into a CORBA NVList:
CORBA::NVList_var v_criteria;
TP::orb()->create_list(1, v_criteria.out());
CORBA::Any any;
any <<= (CORBA::Long)student;
v_criteria->add_value("student_id", any, 0);
RegistrarFactory
オブジェクトには、リスト2-7
に示すTP::create_object_reference()オペレーションに対する呼出しが含まれます。これにより、リスト2-6
で作成されたNVlistが渡されます。
// create the registrar object reference using
// the routing criteria :
CORBA::Object_var v_reg_oref =
TP::create_object_reference(
UniversityP::_tc_Registrar->id(),
object_id,
v_criteria.in()
);
Productionサンプル・アプリケーションはまた、TellerFactory
オブジェクトでもファクトリ・ベース・ルーティングを使用し、口座番号に基づいてTeller
オブジェクトがインスタンス化されるべきグループを決定します。
ファクトリでファクトリ・ベース・ルーティングを実装するとき、Oracle Tuxedo CORBAによってオブジェクト参照が生成されます。次の例は、ファクトリ・ベース・ルーティングが実装されているときにクライアント・アプリケーションがRegistrar
オブジェクトへのオブジェクト参照を取得する方法を示します。
RegistrarFactory
オブジェクトを呼び出し、Registrar
オブジェクトへのリファレンスをリクエストします。リクエストには、学生IDが含まれています。RegistrarFactory
は、NVlist
に学生IDを挿入します。これは、ルーティング基準として使用されます。RegistrarFactory
は、TP::create_object_reference()
オペレーションを呼び出し、Registrar
インタフェース名、ユニークなOID、およびNVlist
を渡します。NVlist
の値と比較して、グループIDを判別します。クライアント・アプリケーションがその後、オブジェクト参照を使用してオブジェクトを呼び出すと、Oracle Tuxedo CORBAはオブジェクト参照で指定されたグループにリクエストをルーティングします。
注意: | Process-Entityデザイン・パターンを使用する場合は、ファクトリ・ベース・ルーティングの実装は慎重に行う必要があります。オブジェクトが処理できるのは、グループのデータベースに格納されているエンティティのみです。 |
Registrar
オブジェクトおよびTeller
オブジェクトを設計する際には、次のことを確認してください。
Registrar
オブジェクトおよびTeller
オブジェクトが、Productionデプロイメント環境、つまり、複数の複製サーバー・プロセスおよび複数のグループにわたって、適正に機能していること。UniversityおよびBillingの各サーバー・プロセスが複製されている場合の設計では、これら2つのオブジェクトをどのようにインスタンス化するかを考慮する必要があります。 オブジェクトはユニークなオブジェクトID (OID)を持ち、メソッド・バウンドである必要があります。つまり、これらのオブジェクトには、method
アクティブ化ポリシーが割り当てられている必要があります。
Productionサンプル・アプリケーションほど高度でないUniversityサーバー・アプリケーションでは、Registrar
オブジェクトとTeller
オブジェクトの実行時の振る舞いは、より単純でした。
しかし今では、UniversityおよびBillingサーバー・プロセスはレプリケートされているため、Oracle Tuxedo CORBAはRegistrar
オブジェクトとTeller
オブジェクトの複数インスタンスを区別できる必要があります。たとえば、グループ内で2つのUniversityサーバー・プロセスが実行されている場合、Oracle Tuxedo CORBAには、1つ目のUniversityサーバー・プロセスで実行されているRegistrar
オブジェクトと、2つ目のUniversityサーバー・プロセスで実行されているRegistrar
オブジェクトを区別する手段が必要です。これらのオブジェクトの複数のインスタンスを区別するには、各オブジェクト・インスタンスが一意であることが必要です。
各Registrar
およびTeller
オブジェクトをユニークなものにするには、これらのオブジェクトのファクトリで、これらに対するオブジェクト参照を作成する方法を変更しなければなりません。たとえばBasicサンプル・オブジェクトでは、RegistrarFactory
オブジェクトがRegistrar
オブジェクトへのオブジェクト参照を作成すると、TP::create_object_reference()
オペレーションが、文字列registrar
のみからなるOIDを指定していました。しかし、Productionサンプル・アプリケーションでは、同じTP::create_object_reference()
オペレーションが、生成されたユニークなOIDを使用します。
各Registrar
およびTeller
オブジェクトにユニークなOIDを付与した結果、Oracle Tuxedoドメインではこれらのオブジェクトの複数のインスタンスが、同時に実行可能です。この特性は、ステートレス・オブジェクト・モデルでは一般的なものであり、Oracle Tuxedoドメインが、高い性能を提供しつつ、高度にスケーラブルであり得ることの一例です。
最後に、一意のRegistrar
およびTeller
オブジェクトは、それらに対するクライアント・リクエストがあるたびにメモリーにロードする必要があるため、呼出しが完了したときにはこれらのオブジェクトを非アクティブ化し、関連するオブジェクト状態がアイドル状態のままメモリーに残存しないようにすることが重要です。Productionサーバー・アプリケーションは、実装構成ファイル(ICF)内のこれら2つのオブジェクトに、method
アクティブ化ポリシーを割り当てることによって、この問題に対処します。
複製サーバー・グループを使用する、主なスケーラビリティ上の利点は、複数台のマシンに処理を分散できることです。しかし、Universityサンプル・アプリケーションの場合のように、アプリケーションがデータベースと対話する場合は、これら複数のサーバー・グループがデータベースとの対話に与える影響を考慮することが重要です。
多くの場合、デプロイされているマシンに、データベースは1つずつ関連付けられています。サーバー・アプリケーションが複数台のマシンに分散されている場合は、データベースをどのようにセットアップするかを検討する必要があります。
この章で説明しているように、Productionサンプル・アプリケーションでは、2つのデータベースを使用します。しかし、このアプリケーションは、簡単にそれ以上のデータベースに対応できるよう構成できます。使用するデータベースの数は、システム管理者が決定できます。
Productionサンプル・アプリケーションでは、学生および口座の情報は、2つのデータベース間に分割されますが、コース情報は同一です。コース情報は、コース登録用途では読取り専用となっているため、両方のデータベースのコース情報が同一であることは問題にはなりません。一方で、学生情報および口座情報については読書きが行われます。複数のデータベースが学生および口座についても同一のデータを格納するとしたら(つまり、データベースが分割されていない場合)、アプリケーションでは、学生情報または口座情報が変更されるたびにデータベース全体にわたって学生および口座の情報の更新を同期する処理のオーバーヘッドに対処する必要が生じるでしょう。
Productionサンプル・アプリケーションは、ファクトリ・ベース・ルーティングによって、1台のマシンにリクエストの1セットを、別のマシンにリクエストの別の1セットを送信します。RegistrarFactory
オブジェクトでファクトリ・ベース・ルーティングがどのように実装されるかは、Registrar
オブジェクトへの参照がどのように作成されるかによって変わります。
たとえば、クライアント・アプリケーションがRegistrarFactory
オブジェクトにリクエストを送信して、Registrar
オブジェクトのオブジェクト参照を取得した場合、クライアント・アプリケーションはそのリクエストに学生IDを含めます。ファクトリによって返されたオブジェクト参照はグループ固有のものであるため、クライアント・アプリケーションは、RegistrarFactory
オブジェクトが返すオブジェクト参照を使用して、その後のRegistrar
オブジェクトへのすべての呼出しを、特定の学生のために行う必要があります。したがって、たとえばクライアント・アプリケーションがその後、Registrar
オブジェクトに対してget_student_details()
操作を呼び出すと、クライアント・アプリケーションでは、Registrar
オブジェクトが、その学生のデータを格納しているデータベースと関連付けられたサーバー・グループにおいて、確実にアクティブ化されます。
この機能を示すために、Productionサンプル・アプリケーションに実装されている以下の実行シナリオを検討してみます。
RegistrarFactory
オブジェクトのfind_registrar()
操作を呼び出します。この呼出しには学生ID 1000003
が含まれます。RegistrarFactory
オブジェクトにルーティングします。RegistrarFactory
オブジェクトは、学生IDを使用し、UBBCONFIG
ファイルのルーティング情報に基づいて、ORA_GRP1
内のRegistrar
オブジェクトへのオブジェクト参照を作成し、そのオブジェクト参照をクライアント・アプリケーションに返します。Registrar
オブジェクトのregister_for_courses()
オペレーションを呼び出します。ORA_GRP1
内のUniversityサーバー・プロセスに送られます。Registrar
オブジェクトをインスタンス化し、それにクライアント呼出しを送信します。 前述の説明のRegistrarFactory
オブジェクトは、クライアント・アプリケーションに、Productionマシン1上で実行され、100001
から100005
までのIDを持つ学生の学生データを格納したデータベースが含まれる、ORA_GRP1
内でのみインスタンス化が可能なRegistrar
オブジェクトへの一意の参照を返します。したがって、クライアント・アプリケーションが所定の学生のために、その後のリクエストをこのRegistrar
オブジェクトに送信すると、Registrar
オブジェクトは適正なデータベースと対話を行います。
Registrar
オブジェクトはTeller
オブジェクトが必要になると、Universityサーバー・オブジェクトにキャッシュされていた
TellerFactory
オブジェクト参照を使用して、TellerFactory
オブジェクトを呼び出します。
ただし、TellerFactory
オブジェクトではファクトリ・ベース・ルーティングが使用されているため、Registrar
オブジェクトがTeller
オブジェクトへの参照をリクエストするとき、Registrar
オブジェクトは学生の口座番号を渡します。このようにしてTellerFactory
オブジェクトは、正しいデータベースを備えたグループ内のTeller
オブジェクトへの参照を作成します。
注意: | Productionサンプル・アプリケーションが適正に動作するためには、システム管理者がサーバー・グループとデータベースの構成を正しく行うことが不可欠です。具体的には、システム管理者はルーティング表で指定されたルーティング基準と、これらの基準を使用したリクエストのルーティング先となるデータベースを、確実に一致させる必要があります。Productionサンプルを例にすると、指定されたグループにあるデータベースは、そのグループにルーティングされたリクエストに正しく対応する学生情報および口座情報を含んでいる必要があります。 |
将来的には、Productionサンプル・アプリケーションのシステム管理者がOracle Tuxedoドメインの容量を増やす必要を感じる場合もあります。たとえば、今後大学の学生数が著しく増えたり、いくつかのキャンパスを包含する、州全体の大学システムのコース登録プロセスに対応するようにProductionアプリケーションが拡張されたりすることが考えられます。これを行うのに、アプリケーションを修正したり再ビルドしたりする必要はありません。
システム管理者は、以下の処理によって、容量を追加し続けることができます。
システム管理者は、UBBCONFIG
ファイルを修正し、追加のサーバー・グループ、これらのグループで実行されるサーバー・プロセス、およびサーバー・グループが動作するマシンを指定する必要があります。
たとえば、Productionサンプル・アプリケーションの既存の2つのグループへルーティングするかわりに、システム管理者はUBBCONFIG
ファイルのルーティング・ルールを変更して、Oracle Tuxedoドメインに追加されたサーバー・グループにわたるよう、アプリケーションをさらにパーティション化することができます。ルーティング表への変更はすべて、UBBCONFIG
ファイル内の構成済のサーバー・グループおよびマシンの情報と一致している必要があります。
注意: | データベースを使用する既存のOracle Tuxedo CORBAアプリケーションに容量を追加する場合、特にファクトリ・ベース・ルーティングを使用しているときは、データベースのセットアップに対する影響も考慮する必要があります。たとえば、Productionサンプル・アプリケーションが6台のマシンに分散されている場合、各マシン上のデータベースを適切かつUBBCONFIG ファイルのルーティング表に従って設定する必要があります。 |
![]() ![]() ![]() |