|
|
CORBA サーバ・アプリケーションのスケーリング
ここでは、以下の内容について説明します。
このトピックでは Production サンプル・アプリケーションを例として使用し、CORBA C++ アプリケーションをスケーリングして処理能力を高める方法を示します。事前に、必ず次の個所をお読みください。
Production サンプル・アプリケーションのスケーリングについて
Production サンプル・アプリケーションは、Wrapper サンプル・アプリケーションと同じエンド・ユーザ機能を提供します。Production サンプル・アプリケーションでは、BEA Tuxedo ソフトウェアの機能を使用して既存の BEA Tuxedo アプリケーションをスケーリングする方法が示されます。
この節では、以下の内容について説明します。
設計上の目標
Production サンプル・アプリケーションの設計上の主な目標は、次の処理により、対応できるクライアント・アプリケーションの数を大幅に増やすことです。
アプリケーションのスケーリング方法
これらの設計上の目標に対応するため、Production サンプル・アプリケーションは次のようにしてスケーリングされています。
UBBCONFIG
ファイルで定義されている ORA_GRP
サーバ・グループおよび APP_GRP
サーバ・グループです。ORA_GRP
サーバ・グループおよび APP_GRP
サーバ・グループを追加のサーバ・マシンである Production マシン 2 上で複製し、データベースの分割も行います。RegistrarFactory
Registrar
TellerFactory
Teller
これにより、これらのオブジェクトはプロセスではなくクライアント・アプリケーションごとに利用可能となるので、並列処理機能に対応できるようになります。
注記 Production サンプル・アプリケーションの使用を簡単にするには、1 つのデータベースを使い、1 つのマシン上で実行されるように、アプリケーションを BEA Tuxedo ソフトウェア・キット上でコンフィギュレーションします。ただし、この章で示した例では、アプリケーションは 2 つのデータベースを使って 2 つのマシン上で動作しています。
Production サンプル・アプリケーションは、数台のマシン上で動作し、複数のデータベースを使用すべくコンフィギュレーションできるよう設計されています。コンフィギュレーションを複数のマシンとデータベース用に変更するには、UBBCONFIG
ファイルを修正して、データベースを分割することが必要です。この手順は、アプリケーションをさらにスケーリングする方法で説明しています。
以下の節では、Production サンプル・アプリケーションが複製されたサーバ・プロセスとサーバ・グループ、オブジェクト状態管理、およびファクトリ・ベース・ルーティングをどのように使用して、スケーラビリティの目標を達成するかを説明します。
OMG IDL の変更
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
のオブジェクトをインスタンス化できる、利用可能なサーバ・プロセスの数だけです。したがって、これらの状態を持たないオブジェクトはマシン・リソースのより効率的な使用と、クライアント応答時間の短縮を実現します。
最も重要なのは、BEA Tuxedo CORBA で、Registrar
および Teller
オブジェクトのコピーを各複製サーバ・プロセス内でインスタンス化できるように、オブジェクトの各コピーが一意でなければならないことです。これらのオブジェクトの各インスタンスを一意にするために、オブジェクトのファクトリでは一意のオブジェクト ID をオブジェクトに割り当てる必要があります。
BEA Tuxedo アプリケーションが複製サーバ・アプリケーション・プロセスのそれぞれで Registrar
および Teller
オブジェクトのコピーをインスタンス化するには、オブジェクトの各コピーが一意のオブジェクト ID (OID) を備えていなければなりません。これらのオブジェクトを作成するファクトリが、一意の OID を割り当てる役割を担います。一意のオブジェクト ID の生成については、『BEA Tuxedo CORBA サーバ・アプリケーションの開発方法』を参照してください。その他の設計上の考慮事項については、設計上の追加考慮事項を参照してください。
サーバ・プロセスおよびサーバ・グループの複製によるスケーリング
ここでは、次の内容について説明します。
このトピックでは、サーバ・プロセスおよびサーバ・グループを複製することによる、Production サンプル・アプリケーションのスケーリング方法を説明します。概要については、サーバ・プロセスおよびサーバ・グループの複製を参照してください。
Production アプリケーションでのサーバ・プロセスの複製
この節では、Production サンプル・アプリケーションによるサーバ・アプリケーションの複製方法を説明します。この機能の概要については、サーバ・プロセスの複製を参照してください。
図 2-1 では、単一のマシン上で実行される、複製された ORA_GRP
および APP_GRP
グループを示します。
ORA_GRP
グループ内で複製されます。APP_GRP
グループ内で複製されます。図2-1 Production サンプルの複製サーバ・グループ
これらのグループの 1 つに要求が到達したとき、BEA Tuxedo ドメインにはこの要求を処理できるサーバ・プロセスがいくつかあります。BEA Tuxedo ドメインは、最も負荷の軽いサーバ・プロセスを選択することができます。
図 2-1 では、次の点に留意してください。
RegistrarFactory
、Registrar
、TellerFactory
、または Teller
オブジェクトのインスタンスが複数存在することはできません。CourseSynopsisEnumerator
オブジェクトは、どの University サーバ・プロセスでも、任意の数だけ存在することができます。Production アプリケーションでのサーバ・グループの複製
この節では、Production サンプル・アプリケーションによるサーバ・グループの複製方法を説明します。この機能の概要については、サーバ・グループの複製を参照してください。
図 2-2 は、アプリケーションの UBBCONFIG
ファイルで ORA_GRP2
および APP_GRP2
として指定された、別のマシン上で複製される Production サンプル・アプリケーション・グループを示します。
図2-2 複数のマシンにわたるサーバ・グループの複製
図 2-2 では、Production マシン 1 および 2 のグループの内容の違いはデータベースのみです。
100001
から 100005
までの間の ID を持つ学生の、学生情報および口座情報が格納されています。100006
から 100010
までの間の ID を持つ学生の、学生情報および口座情報が格納されています。注記 双方のデータベースのコース情報テーブルは同じものです。
所定のデータベース内の学生情報は、同じデータベース内の口座情報とはまったく関係がない場合があります。
Production サンプル・アプリケーションがファクトリ・ベース・ルーティングを使用して、複数のマシン間にアプリケーションの処理負荷を分散する方法の詳細については、ファクトリ・ベース・ルーティングによるスケーリングを参照してください。
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
# デフォルトでは、各サーバのインスタンスを 2 個活性化
# して、管理者による活性化については各サーバの
# インスタンスを 5 個まで可能にする
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 アプリケーションでのファクトリ・ベース・ルーティングについて
この節では、Production サンプル・アプリケーションがどのようにファクトリ・ベース・ルーティングを使用するかを説明します。この機能の概要については、ファクトリ・ベース・ルーティングの使用 (CORBA サーバのみ)を参照してください。
ファクトリ・ベース・ルーティングを使用すると、BEA Tuxedo CORBA のロード・バランシング機能およびスケーラビリティ機能を拡張できます。Production サンプル・アプリケーションでは、ファクトリ・ベース・ルーティングを使用して、1 つのマシンに 1 つの学生のサブセットを登録する要求を、別のマシンに別の学生のサブセットを登録する要求を送信できます。アプリケーションの処理機能を向上させると、アプリケーション内でのファクトリ・ベース・ルーティングを簡単に変更して、マシンをさらに追加できます。
Production サンプル・アプリケーションでのファクトリ・ベース・ルーティングのインプリメンテーションに関する設計上の主な考慮事項は、ルーティングの基準となる値の選択です。Production サンプル・アプリケーションは、次のようにファクトリ・ベース・ルーティングを使用します。
Registrar
オブジェクトに対する要求は、学生 ID に基づいてルーティングされます。100001
から 100005
までの学生 ID からの要求は、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
セクションでは、BEA Tuxedo CORBA アプリケーションでファクトリ・ベース・ルーティングをインプリメントする方法が示されます。このサンプルの ubb_p.nt
または ubb_p.mk
UBBCONFIG
ファイルは、BEA Tuxedo ソフトウェアをインストールしたディレクトリで見つけることができます。\samples
\corba
\university
\production
サブディレクトリを参照してください。
UBBCONFIG
ファイルでは、グループおよびマシンの識別方法に加えて、INTERFACES
および ROUTING
セクションにおいて、以下のデータを指定する必要があります。
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
です。
ROUTING
セクションは、各ルーティング値について、表 2-1 に記載のパラ
メータを指定します。
リスト 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
オブジェクト・リファレンスは、別のグループにルーティングされます。
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
セクションに反映される必要があります。BEA 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
// 学生 ID (ルーティング基準) を
// 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 の呼び出し
// ルーティング基準を使用して、registrar オブジェクト・
// リファレンスを作成
CORBA::Object_var v_reg_oref =
TP::create_object_reference(
UniversityP::_tc_Registrar->id(),
object_id,
v_criteria.in()
);
Production サンプル・アプリケーションはまた、TellerFactory
オブジェクトでもファクトリ・ベース・ルーティングを使用し、口座番号に基づいて Teller
オブジェクトがインスタンス化されるべきグループを決定します。
実行時の処理
ファクトリでファクトリ・ベース・ルーティングをインプリメントするとき、BEA Tuxedo CORBA によってオブジェクト・リファレンスが生成されます。以下の例では、ファクトリ・ベース・ルーティングのインプリメント時に、クライアント・アプリケーションが Registrar
オブジェクトへのオブジェクト・リファレンスを取得する方法を示します。
RegistrarFactory
オブジェクトを呼
び出し、Registrar
オブジェクトへのリファレンスを要求します。要求に
は、学生 ID が含まれています。
RegistrarFactory
は、NVlist
に学生 ID を挿入します。これは、ルーティ
ング基準として使用されます。
RegistrarFactory
は、TP::create_object_reference()
オペレーション
を呼び出し、Registrar
インターフェイス名、一意の OID、および NVlist
を渡します。
NVlist
内の値と
比較し、グループ ID を決定します。
クライアント・アプリケーションがその後、オブジェクト・リファレンスを使用してオブジェクトを呼び出すと、BEA Tuxedo CORBA はオブジェクト・リファレンスで指定されたグループに要求をルーティングします。
注記 プロセス・エンティティの設計パターンを使用する場合は、ファクトリ・ベース・ルーティングのインプリメントは慎重に行う必要があります。オブジェクトは、グループのデータベースに格納されているエンティティしか処理できません。
設計上の追加考慮事項
ここでは、次の内容について説明します。
設計上の追加考慮事項について
Registrar
オブジェクトおよび Teller
オブジェクトを設計する際には、次のことを確認してください。
Registrar
オブジェクトおよび Teller
オブジェクトが、Production デプロイメント具体的には複数の複製サーバ・プロセスおよび複数のグループにわたって、適正に機能していること。University および Billing の各サーバ・プロセスが複製されている場合の設計では、これら 2 つのオブジェクトをどのようにインスタンス化するかを考慮する必要があります。オブジェクトは一意のオブジェクト ID (OID) を持ち、メソッド・バウンドである必要があります。つまり、これらのオブジェクトには、method
活性化方針が割り当てられている必要があります。
Registrar オブジェクトおよび Teller オブジェクトのインスタンス化
Production サンプル・アプリケーションほど高度でない University サーバ・アプリケーションでは、Registrar
オブジェクトと Teller
オブジェクトの実行時の振る舞いは、より単純でした。
しかし今では、University および Billing サーバ・プロセスは複製されているため、BEA Tuxedo CORBA は Registrar
オブジェクトと Teller
オブジェクトの複数インスタンスを区別できなくてはなりません。たとえば、グループ内で 2 つの University サーバ・プロセスが実行されている場合、BEA Tuxedo CORBA には、1 つ目の University サーバ・プロセスで実行されている Registrar
オブジェクトと、2 つ目のサーバ・プロセスで実行されている Registrar
オブジェクトを区別する手段が必要です。これらのオブジェクトの複数のインスタンスを区別するには、各オブジェクト・インスタンスが一意的である必要があります。
各 Registrar
および Teller
オブジェクトを一意のものにするには、これらのオブジェクトのファクトリで、これらに対するオブジェクト・リファレンスを作成する方法を変更しなければなりません。たとえば Basic サンプル・オブジェクトでは、RegistrarFactory
オブジェクトが Registrar
オブジェクトへのオブジェクト・リファレンスを作成すると、TP::create_object_reference()
オペレーションが、文字列 registrar
のみからなる OID を指定していました。しかし、Production サンプル・アプリケーションでは、同じ TP::create_object_reference()
オペレーションが、生成された一意の OID を使用します。
各 Registrar
および Teller
オブジェクトに一意の OID を付与した結果、BEA Tuxedo ドメインではこれらのオブジェクトの複数のインスタンスが、同時に実行可能です。この特性は、状態を持たないオブジェクト・モデルでは一般的なものであり、BEA 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
オブジェクトは、クライアント・アプリケーションに、ORA_GRP1
内でのみインスタンス化が可能な Registrar
オブジェクトへの一意のリファレンスを返します。このグループには Production マシン 1 上で実行され、100001
から 100005
までの ID を持つ学生の学生データを格納したデータベースがあります。したがって、クライアント・アプリケーションが所定の学生のために、その後の要求をこの Registrar
オブジェクトに送信すると、 Registrar
オブジェクトは適正なデータベースと対話を行います。
Teller オブジェクトが適切なサーバ・グループでインスタンス化されるようにする方法
Registrar
オブジェクトは Teller
オブジェクトが必要になると、University サーバ・オブジェクトにキャッシュされていた TellerFactory
オブジェクト・リファレンスを使用して、TellerFactory
オブジェクトを呼び出します。
しかし、TellerFactory
オブジェクトではファクトリ・ベース・ルーティングが使用されているため、Registrar
オブジェクトは Teller
オブジェクトへのリファレンス要求時に、学生の口座番号を渡します。このようにして TellerFactory
オブジェクトは、正しいデータベースを備えたグループ内の Teller
オブジェクトへのリファレンスを作成します。
注記 Production サンプル・アプリケーションが適正に動作するためには、システム管理者がサーバ・グループとデータベースのコンフィギュレーションを正しく行うことが不可欠です。具体的には、システム管理者はルーティング・テーブルで指定されたルーティング基準と、これらの基準を使用した要求のルーティング先となるデータベースを、確実に一致させる必要があります。Production サンプルを例にすると、指定されたグループにあるデータベースは、そのグループにルーティングされた要求に正しく対応する学生情報および口座情報を含んでいる必要があります。
アプリケーションをさらにスケーリングする方法
将来的には、Production サンプル・アプリケーションのシステム管理者が BEA Tuxedo ドメインの容量を増やす必要を感じる場合もあります。たとえば、今後大学の学生数が著しく増えたり、いくつかのキャンパスを包含する、州全体の大学システムのコース登録プロセスに対応するように Production アプリケーションが拡張されたりすることが考えられます。これを行うのに、アプリケーションを修正したり再ビルドしたりする必要はありません。
システム管理者は、以下の処理によって、容量を追加し続けることができます。
システム管理者は、UBBCONFIG
ファイルを修正し、追加のサーバ・グループ、これらのグループで実行されるサーバ・プロセス、およびサーバ・グループが動作するマシンを指定する必要があります。
たとえば、Production サンプル・アプリケーションの既存の 2 つのグループへルーティングする代わりに、システム管理者は UBBCONFIG
ファイルのルーティング規則を変更して、BEA Tuxedo ドメインに追加されたサーバ・グループにわたるよう、アプリケーションをさらに分割することができます。ルーティング・テーブルへの変更はすべて、UBBCONFIG
ファイル内のコンフィギュレーション済みのサーバ・グループおよびマシンの情報と一致している必要があります。
注記 データベースを使用する既存の BEA Tuxedo CORBA アプリケーションに容量を追加する場合、特にファクトリ・ベース・ルーティングを使用しているときは、データベースのセットアップに対する影響も考慮する必要があります。たとえば、Production サンプル・アプリケーションが 6 台のマシンに分散されている場合、各マシン上のデータベースを適切かつ UBBCONFIG
ファイルのルーティング・テーブルに従ってセットアップする必要があります。
|
Copyright © 2001, BEA Systems, Inc. All rights reserved.
|