CORBAサーバー・アプリケーションのスケーリング
このトピックではProductionサンプル・アプリケーションを例として使用し、CORBA C++アプリケーションをスケーリングして処理能力を高める方法を示します。事前に、必ず次の個所をお読みください。
|
•
|
Oracle Tuxedoオンライン・ドキュメントの「Productionサンプル・アプリケーション」
|
Productionサンプル・アプリケーションのスケーリングについて
Productionサンプル・アプリケーションには、Wrapperサンプル・アプリケーションと同じエンド・ユーザー向けの機能が用意されています。Productionサンプル・アプリケーションでは、Oracle Tuxedoソフトウェアの機能を使用して既存のOracle Tuxedoアプリケーションをスケーリングする方法が示されます。
Productionサンプル・アプリケーションの設計上の主な目標は、次の処理により、対応できるクライアント・アプリケーションの数を大幅に増やすことです。
|
•
|
並列的に、および1つのマシン上で、同じインタフェースを実装する複数のオブジェクトに対するクライアント・リクエストを処理します。 |
|
•
|
1つのマシンへある特定の学生ために、および別のマシンへ別の学生のために、リクエストを転送します。 |
これらの設計上の目標に対応するため、Productionサンプル・アプリケーションは次のようにしてスケーリングされています。
|
•
|
ステートレス・オブジェクト・モデルを実装して、サーバー・プロセスが同時に管理できるクライアント・リクエストの数を増やします。 |
|
•
|
University、BillingおよびOracle Tuxedo Tellerアプリケーションのサーバー・プロセスを、それらの構成が行われているグループ内でレプリケートします。該当するグループは、 UBBCONFIGファイルで定義されている ORA_GRPサーバー・グループおよび APP_GRPサーバー・グループです。 |
|
•
|
ORA_GRPサーバー・グループおよび APP_GRPサーバー・グループを追加のサーバー・マシンであるProductionマシン2上でレプリケートし、データベースの分割も行います。
|
|
•
|
次のオブジェクトにユニークなオブジェクトID (OID)を割り当て、それらがそれぞれのグループにおいて同時に複数回インスタンス化されるようにします。 |
これにより、これらのオブジェクトはプロセスではなくクライアント・アプリケーションごとに利用可能となるので、並列処理機能に対応できるようになります。
|
•
|
ファクトリ・ベース・ルーティングを実装して、1つのマシンへは一部の学生のために、別のマシンへはほかの学生のために、クライアント・リクエストを転送します。 |
|
注意:
|
Productionサンプル・アプリケーションの使用を簡単にするには、1つのデータベースを使い、1つのマシン上で実行されるように、アプリケーションをOracle Tuxedoソフトウェア・キット上で構成します。ただし、この章で示した例では、アプリケーションは2つのデータベースを使って2つのマシン上で動作しています。 |
Productionサンプル・アプリケーションは、数台のマシン上で動作し、複数のデータベースを使用すべく構成できるよう設計されています。構成を複数のマシンとデータベース用に変更するには、
UBBCONFIGファイルを修正して、データベースをパーティション化する必要があります。この手順は、
2-21ページの「アプリケーションをさらにスケーリングする方法」で説明しています。
次の項では、Productionサンプル・アプリケーションがレプリケートされたサーバー・プロセスとサーバー・グループ、オブジェクト状態管理、およびファクトリ・ベース・ルーティングをどのように使用して、スケーラビリティの目標を達成するかを説明します。
Productionサンプル・アプリケーションでのOMG IDLの変更は、
RegistrarFactoryオブジェクトの
find_registrar()オペレーション、および
TellerFactoryオブジェクトの
find_teller()オペレーションに限定されています。2つのオペレーションは、それぞれ学生IDと口座番号を要求するように修正する必要があります。これらは、ファクトリ・ベース・ルーティングの実装に必要なものです。Productionサンプル・アプリケーションでのファクトリ・ベース・ルーティングの実装と使用については、
2-10ページの「ファクトリ・ベース・ルーティングによるスケーリング」を参照してください。
ここでは、Productionサンプル・アプリケーションにおいて、スケーラビリティを増大させるために、オブジェクト状態管理をどのように
Registrarオブジェクトおよび
Tellerオブジェクトで使用するかを説明します。オブジェクト状態管理の概要は、
1-3ページの「オブジェクト状態管理の使用」を参照してください。
スケーラビリティを増大させるには、Productionサーバー・アプリケーションで、
Registrarおよび
Tellerオブジェクトに
methodアクティブ化ポリシーを構成します。これら2つのオブジェクトに
methodアクティブ化ポリシーを割り当てた結果、動作に次の変化がみられます。
|
•
|
これらのオブジェクトが呼び出されるときは常に、適切なサーバー・グループ内のOracle Tuxedoドメインによってインスタンス化されます。 |
|
•
|
呼出しが完了すると、Oracle Tuxedoドメインによりこれらのオブジェクトは非アクティブ化されます。 |
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サーバー・アプリケーションの作成』を参照してください。その他の設計上の考慮事項については、
2-16ページの「設計上の追加考慮事項」を参照してください。
サーバー・プロセスおよびサーバー・グループのレプリケートによるスケーリング
Productionアプリケーションでのサーバー・プロセスのレプリケート
図2-1では、単一のマシン上で実行される、レプリケートされた
ORA_GRPおよび
APP_GRPグループを示します。
|
•
|
Universityサーバー・アプリケーション、Oracle Tuxedo Tellerアプリケーション、およびOracle7 TMSサーバー・プロセスは、 ORA_GRPグループ内でレプリケートされます。 |
|
•
|
Billingサーバー・プロセスは、 APP_GRPグループ内でレプリケートされます。 |
これらのグループの1つにリクエストが到達したとき、Oracle Tuxedoドメインにはこのリクエストを処理できるサーバー・プロセスがいくつかあります。Oracle Tuxedoドメインは、最も負荷の軽いサーバー・プロセスを選択することができます。
|
•
|
常に、特定のサーバー・プロセス内で、 RegistrarFactory、 Registrar、 TellerFactory、または Tellerオブジェクトのインスタンスが複数存在することはできません。 |
|
•
|
CourseSynopsisEnumeratorオブジェクトは、どのUniversityサーバー・プロセスでも、任意の数だけ存在することができます。
|
Productionアプリケーションでのサーバー・グループのレプリケート
図2-2は、別のマシンにレプリケートされたProductionサンプル・アプリケーションのグループを示しており、このアプリケーションの
UBBCONFIGファイルに指定されているとおり、
ORA_GRP2と
APP_GRP2があります。
図2-2では、Productionマシン1と2のグループの内容で異なるのはデータベースのみです。
|
•
|
Productionマシン1のデータベースには、 100001から 100005までの間のIDを持つ学生の、学生情報および口座情報が格納されています。 |
|
•
|
Productionマシン2のデータベースには、 100006から 100010までの間のIDを持つ学生の、学生情報および口座情報が格納されています。 |
所定のデータベース内の学生情報は、同じデータベース内の口座情報とはまったく関係がない場合があります。
Productionアプリケーションのレプリケートサーバー・プロセスおよびグループの構成
リスト2-1は、Productionサンプル・アプリケーションの
UBBCONFIGファイルの
GROUPSセクションおよび
SERVERSセクションからの抜粋です。
リスト2-1
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アプリケーションでのファクトリ・ベース・ルーティングについて
ファクトリ・ベース・ルーティングを使用すると、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にルーティングされます。
|
UBBCONFIGファイルでのファクトリ・ベース・ルーティングの構成
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セクションにおいて、次のデータを指定する必要があります。
|
1.
|
INTERFACESセクションには、ファクトリ・ベース・ルーティングを有効にするインタフェースの名前がリストされています。各インタフェースについて、このセクションではインタフェースがルーティングを行う基準の種類を指定します。このセクションでは、 リスト2-2に示すように、 FACTORYROUTINGという識別子を使用してルーティング基準を指定します。
|
リスト2-2
UBBCONFIGファイルのINTERFACESセクション
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に指定されています。
|
2.
|
ROUTINGセクションは、各ルーティング値について、 表2-1に記載のパラメータを指定します。
|
表2-1
ROUTINGセクションで指定されるパラメータ
|
|
|
|
|
ルーティングのタイプを指定します。Productionサンプルでは、ルーティングのタイプはファクトリ・ベース・ルーティングです。したがって、このパラメータは FACTORYと定義されます。 |
|
|
ファクトリがルーティング値に挿入する変数名を指定します。Productionサンプルでは、このフィールド・パラメータがそれぞれ student_idと account_numberに設定されています。 |
|
|
ルーティング値のデータ型を指定します。Productionサンプルでは、 student_idおよび account_numberのフィールド型は longです。 |
|
|
|
リスト2-3に、Productionサンプル・アプリケーションで使用される
UBBCONFIGファイルの
ROUTINGセクションを示します。
リスト2-3
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オブジェクト参照は、別のグループにルーティングされます。
|
3.
|
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台のマシンでのみ実行できるように構成されている点に注意してください。ただし、このアプリケーションを複数のマシンで実行できるように構成することは簡単です。)
リスト2-4
UBBCONFIGファイルのGROUPSセクション
*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++バインドがあります。
リスト2-5
create_object_referenceの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ファイルの次の項目と正確に一致する必要があります。
|
•
|
INTERFACESセクションの FACTORYROUTING識別子で指定される、ルーティング名、タイプ、および使用できる値
|
|
•
|
ROUTINGセクションで指定される、ルーティング基準名、フィールド、およびフィールド型
|
RegistrarFactoryオブジェクトは、
リスト2-6に記載のコードを使用して、学生IDを
NVlistに挿入します。
リスト2-6
RegistrarFactoryオブジェクトの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が渡されます。
リスト2-7
RegistrarFactoryオブジェクトでのcreate_object_referenceの呼出し
// 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オブジェクトへのオブジェクト参照を取得する方法を示します。
|
1.
|
クライアント・アプリケーションが、 RegistrarFactoryオブジェクトを呼び出し、 Registrarオブジェクトへのリファレンスをリクエストします。リクエストには、学生IDが含まれています。 |
|
2.
|
RegistrarFactoryは、 NVlistに学生IDを挿入します。これは、ルーティング基準として使用されます。
|
|
3.
|
RegistrarFactoryは、 TP::create_object_reference()オペレーションを呼び出し、 Registrarインタフェース名、ユニークなOID、および NVlistを渡します。
|
|
4.
|
Oracle Tuxedo CORBAは、ルーティング表の内容を NVlistの値と比較して、グループIDを判別します。 |
|
5.
|
Oracle Tuxedo CORBAは、グループに関する情報を、オブジェクト参照に挿入します。 |
クライアント・アプリケーションがその後、オブジェクト参照を使用してオブジェクトを呼び出すと、Oracle Tuxedo CORBAはオブジェクト参照で指定されたグループにリクエストをルーティングします。
|
注意:
|
Process-Entityデザイン・パターンを使用する場合は、ファクトリ・ベース・ルーティングの実装は慎重に行う必要があります。オブジェクトが処理できるのは、グループのデータベースに格納されているエンティティのみです。 |
Registrarオブジェクトおよび
Tellerオブジェクトを設計する際には、次のことを確認してください。
|
•
|
Registrarオブジェクトおよび Tellerオブジェクトが、Productionデプロイメント環境、つまり、複数のレプリケートサーバー・プロセスおよび複数のグループにわたって、適正に機能していること。UniversityおよびBillingの各サーバー・プロセスがレプリケートされている場合の設計では、これら2つのオブジェクトをどのようにインスタンス化するかを考慮する必要があります。
|
|
•
|
Production Oracle Tuxedoドメインの2つのサーバー・グループが各々、別のデータベースを扱う場合には、所定の学生への登録および課金のオペレーションに対するクライアント・リクエストが、正しいサーバー・グループに送られること。 |
オブジェクトはユニークなオブジェクトID (OID)を持ち、メソッド・バウンドである必要があります。つまり、これらのオブジェクトには、
methodアクティブ化ポリシーが割り当てられている必要があります。
RegistrarオブジェクトおよびTellerオブジェクトのインスタンス化
Productionサンプル・アプリケーションほど高度でないUniversityサーバー・アプリケーションでは、
Registrarオブジェクトと
Tellerオブジェクトの実行時の振る舞いは、より単純でした。
|
•
|
各オブジェクトは、プロセス・バウンドでした。つまり、最初に呼び出されたときにアクティブ化され、そのオブジェクトが実行されているサーバー・プロセスが停止されるまで、メモリー内に残っていました。 |
|
•
|
Oracle Tuxedoドメインで実行されるサーバー・グループは1つしかなく、グループ内ではUniversityおよびBillingのサーバー・プロセスは1つしかなかったため、すべてのクライアント・リクエストは、同じオブジェクトに転送されました。複数のクライアント・リクエストがOracle Tuxedoドメインに到達する一方で、これらの各オブジェクトが処理するクライアントは一度に1つずつでした。 |
|
•
|
各オブジェクトのインスタンスは、それらが実行されているサーバー・プロセスに1つしかなかったため、どちらのオブジェクトにもユニークなOIDは不要でした。各オブジェクトのOIDが指定するのは、インタフェース・リポジトリIDのみでした。 |
しかし今では、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サンプル・アプリケーションに実装されている次の実行シナリオを検討してみます。
|
1.
|
クライアント・アプリケーションは、 RegistrarFactoryオブジェクトの find_registrar()操作を呼び出します。この呼出しには学生ID 1000003が含まれます。 |
|
2.
|
Oracle Tuxedo CORBAは、クライアント・リクエストを任意の RegistrarFactoryオブジェクトにルーティングします。 |
|
3.
|
RegistrarFactoryオブジェクトは、学生IDを使用し、 UBBCONFIGファイルのルーティング情報に基づいて、 ORA_GRP1内の Registrarオブジェクトへのオブジェクト参照を作成し、そのオブジェクト参照をクライアント・アプリケーションに返します。
|
|
4.
|
クライアント・アプリケーションは、 Registrarオブジェクトの register_for_courses()オペレーションを呼び出します。 |
|
5.
|
Oracle Tuxedo CORBAはクライアント・リクエストを受け取り、それをオブジェクト参照で指定されたサーバー・グループにルーティングします。この場合、クライアント・リクエストは、Productionマシン1の ORA_GRP1内のUniversityサーバー・プロセスに送られます。 |
|
6.
|
Universityサーバー・プロセスは、 Registrarオブジェクトをインスタンス化し、それにクライアント呼出しを送信します。 |
前述の説明の
RegistrarFactoryオブジェクトは、クライアント・アプリケーションに、Productionマシン1上で実行され、
100001から
100005までのIDを持つ学生の学生データを格納したデータベースが含まれる、
ORA_GRP1内でのみインスタンス化が可能な
Registrarオブジェクトへの一意の参照を返します。したがって、クライアント・アプリケーションが所定の学生のために、その後のリクエストをこの
Registrarオブジェクトに送信すると、
Registrarオブジェクトは適正なデータベースと対話を行います。
Tellerオブジェクトが適切なサーバー・グループでインスタンス化されるようにする方法
Registrarオブジェクトは
Tellerオブジェクトが必要になると、
Universityサーバー・オブジェクトにキャッシュされていた
TellerFactoryオブジェクト参照を使用して、
TellerFactoryオブジェクトを呼び出します。
ただし、
TellerFactoryオブジェクトではファクトリ・ベース・ルーティングが使用されているため、
Registrarオブジェクトが
Tellerオブジェクトへの参照をリクエストするとき、
Registrarオブジェクトは学生の口座番号を渡します。このようにして
TellerFactoryオブジェクトは、正しいデータベースを備えたグループ内の
Tellerオブジェクトへの参照を作成します。
|
注意:
|
Productionサンプル・アプリケーションが適正に動作するためには、システム管理者がサーバー・グループとデータベースの構成を正しく行うことが不可欠です。具体的には、システム管理者はルーティング表で指定されたルーティング基準と、これらの基準を使用したリクエストのルーティング先となるデータベースを、確実に一致させる必要があります。Productionサンプルを例にすると、指定されたグループにあるデータベースは、そのグループにルーティングされたリクエストに正しく対応する学生情報および口座情報を含んでいる必要があります。 |
将来的には、Productionサンプル・アプリケーションのシステム管理者がOracle Tuxedoドメインの容量を増やす必要を感じる場合もあります。たとえば、今後大学の学生数が著しく増えたり、いくつかのキャンパスを包含する、州全体の大学システムのコース登録プロセスに対応するようにProductionアプリケーションが拡張されたりすることが考えられます。これを行うのに、アプリケーションを修正したり再ビルドしたりする必要はありません。
システム管理者は、次の処理によって、容量を追加し続けることができます。
|
•
|
Productionサンプル・アプリケーションのサーバー・グループを複数のマシンにレプリケートします。 |
システム管理者は、
UBBCONFIGファイルを修正し、追加のサーバー・グループ、これらのグループで実行されるサーバー・プロセス、およびサーバー・グループが動作するマシンを指定する必要があります。
たとえば、Productionサンプル・アプリケーションの既存の2つのグループへルーティングするかわりに、システム管理者は
UBBCONFIGファイルのルーティング・ルールを変更して、Oracle Tuxedoドメインに追加されたサーバー・グループにわたるよう、アプリケーションをさらにパーティション化することができます。ルーティング表への変更はすべて、
UBBCONFIGファイル内の構成済のサーバー・グループおよびマシンの情報と一致している必要があります。
|
注意:
|
データベースを使用する既存のOracle Tuxedo CORBAアプリケーションに容量を追加する場合、特にファクトリ・ベース・ルーティングを使用しているときは、データベースのセットアップに対する影響も考慮する必要があります。たとえば、Productionサンプル・アプリケーションが6台のマシンに分散されている場合、各マシン上のデータベースを適切かつ UBBCONFIGファイルのルーティング表に従って設定する必要があります。 |
