![]() |
![]() |
|
|
BEA Tuxedo の CORBA サーバ・アプリケーションのスケーリング
この章では、BEA Tuxedo システムの主要なスケーラビリティ機能を利用して CORBA サーバ・アプリケーションのスケーラビリティを高める方法について、Production University サンプル・アプリケーションを例にして説明します。Production サンプル・アプリケーションは、これらのスケーラビリティ機能を利用して以下の目標を達成します。
ここでは、次の内容について説明します。
BEA Tuxedo システムで利用可能なスケーラビリティ機能の概要
高度にスケーラブルなアプリケーションのサポートは、BEA Tuxedo システムの長所の 1 つです。多くのアプリケーションは、1 〜 10 のサーバ・プロセス、および 10 〜 100 のクライアント・アプリケーションが動作している環境で良好に機能します。しかし、ビジネス環境では、アプリケーションは次のレベルの処理をサポートする必要があります。
このような要件を負ったアプリケーションをデプロイすると、リソースの不足および性能のボトルネックがすぐに表面化します。BEA Tuxedo システムではこうした大規模なデプロイメントが複数の方法でサポートされていて、この章ではそれらのうち次の 3 つについて説明します。
アプリケーションを高度にスケーラブルにするために BEA Tuxedo システムで提供されているほかの機能には、IIOP リスナ/ハンドラがあります。概要については『BEA Tuxedo CORBA アプリケーション入門』、詳細な説明については『BEA Tuxedo アプリケーションの設定』を参照してください。また、『BEA Tuxedo CORBA アプリケーションのスケーリング、分散、およびチューニング』も参照してください。
BEA Tuxedo サーバ・アプリケーションのスケーリング
ここでは、非常に大規模な処理機能を実現できるようにアプリケーションをスケーリングする方法について、Production サンプル・アプリケーションを例にして説明します。Production サンプル・アプリケーションの設計上の基本的な目標は、対応できるクライアント・アプリケーションの数を大幅に増やすために、次のように対処することです。
こうした設計目標に対応するために、Production サンプル・アプリケーションでは次の処理をします。
RegistrarFactory
Registrar
TellerFactory
Teller
注記 Production サンプル・アプリケーションを使いやすくするために、このアプリケーションは 1 台のマシン上で 1 つのデータベースを使用して実行できるように BEA Tuxedo ソフトウェア・キット上でコンフィギュレーションされています。しかし、この章で説明する例は、このアプリケーションを 2 台のマシン上で 2 つのデータベースを使用して実行する方法を示します。
Production サンプル・アプリケーションの設計では、複数台のマシン上で複数のデータベースを使用して実行するコンフィギュレーションが可能になるように設定されています。複数のマシンおよびデータベースを使用するようにコンフィギュレーションを変更する作業には、UBBCONFIG
ファイルの変更とデータベースの分離が関係し、これらの詳細は「Production サーバ・アプリケーションをさらにスケーリングする方法」で説明されています。
以後の各節では、Production サンプル・アプリケーションのスケーラビリティの目標を達成するために、複製されたサーバ・プロセスおよびサーバ・グループの使用、オブジェクト状態管理、およびファクトリ・ベース・ルーティングについて説明します。次の節では、Production サンプル・アプリケーションにインプリメントされている OMG IDL の変更について説明します。
Production サンプル・アプリケーションの OMG IDL の変更
Production サンプル・アプリケーションの OMG IDL への変更は、RegistrarFactory
オブジェクトの find_registrar()
オペレーション、および TellerFactory
オブジェクトの find_teller()
オペレーションに限定されます。これら 2 つのオペレーションはそれぞれ、ファクトリ・ベース・ルーティングのインプリメンテーションに必要な学生 ID と口座番号を要求するように変更されます。Production サンプル・アプリケーションでのファクトリ・ベース・ルーティングのインプリメンテーションおよび使用については、「ファクトリ・ベース・ルーティング」を参照してください。
サーバ・プロセスおよびサーバ・グループの複製
BEA Tuxedo システムでは、サーバ・アプリケーションのコンフィギュレーションに多様な選択肢が用意されています。たとえば、以下のコンフィギュレーションが可能です。
以上をまとめると、次のようになります。
次の節では、複製されたサーバ・プロセスおよびグループについて説明するほか、それらを BEA Tuxedo システムにコンフィギュレーションする方法についても説明します。
複製されたサーバ・プロセス
使用するアプリケーションでサーバ・プロセスを複製すると、以下の利点があります。
複製されたサーバ・プロセスの利点を完全に活用するには、使用するサーバ・アプリケーションによってインスタンス化される各オブジェクトのすべてが一意な ID を持つようにしてください。こうすれば、オブジェクト上でのクライアント呼び出しによって必要なオブジェクトがインスタンス化される処理が、利用可能な複数のサーバ・プロセスの境界内で実行されるので、既に活性化されているオブジェクトのためのキューに入れられずに済みます。
図 8-1 は、次のことを示します。
この図では、2 つのグループは 1 台のマシンで実行されているものとして示されます。
図8-1 Production サンプルの複製されたサーバ・グループ
これらのグループのいずれかに要求が着信したとき、BEA Tuxedo ドメインには要求を処理できる利用可能なサーバ・プロセスが複数あり、BEA Tuxedo ドメインは最も負荷の少ないサーバ・プロセスを選択することができます。
図 8-1 では、次の点に注意してください。
RegistrarFactory
、Registrar
、TellerFactory
、または Teller
オブジェクトのインスタンスは 1 つだけです。CourseSynopsisEnumerator
オブジェクトが存在できます。複製されたサーバ・グループ
サーバ・グループの概念は BEA Tuxedo システムに固有のもので、CORBA のインプリメンテーションに追加されます。サーバ・グループは、BEA Tuxedo システムのスケーラビリティ機能の重要な要素です。基本的に、デプロイメント・システムにマシンを追加する場合は、グループを追加する必要があります。
図 8-2 は、別のマシンに複製された Production サンプル・アプリケーションのグループを示します。このアプリケーションの UBBCONFIG
ファイルに指定されているとおり、ORA_GRP2 と APP_GRP2 があります。
図8-2 マシン間でのサーバ・グループの複製
図 8-2 では、Production マシン 1 と 2 のグループの内容で異なるのはデータベースのみです。Production マシン 1 用のデータベースには、学生のサブセットについて、学生情報および口座情報が含まれています。Production マシン 2 用のデータベースには、学生の別のサブセットについて、学生情報および口座情報が含まれています。両方のデータベースにあるコース情報のテーブルは同じ内容です。データベースにある学生情報が、同じデータベース内の口座情報とは完全に無関連であることに注意してください。
サーバ・グループのコンフィギュレーションの方法、実行場所、および複製の方法は、UBBCONFIG
ファイルに指定されています。サーバ・グループを複製するときは、次のことが可能です。
複数のサーバ・グループを持つと、次のような影響があります。
Production サンプル・アプリケーションがファクトリ・ベース・ルーティングを使用して複数台のマシンにアプリケーションの処理負荷を分散させる方法の詳細については、「ファクトリ・ベース・ルーティング」を参照してください。
複製されたサーバ・プロセスおよびグループのコンフィギュレーション
使用する BEA Tuxedo ドメインにある複製されたサーバ・プロセスおよびグループをコンフィギュレーションするには、以下の手順に従います。
UBBCONFIG
ファイルを、「ワードパッド」などのテキス
ト・エディタで開きます。
GROUPS
セクションに、コンフィギュレーションするグループの名前を指定
します。
SERVERS
セクションに、複製するサーバ・プロセスに関する次の情報を入力
します。
GROUP
パラメータ。サーバ・プロセスが属するグループの名前を指定します。複数のグループに関係するサーバ・プロセスを複製する場合は、各グループに 1 つずつサーバ・プロセスを指定します。SRVID
パラメータ。数値識別子を指定して、サーバ・プロセスに一意な ID を割り当てます。MIN
パラメータ。アプリケーションの起動時に開始されるサーバ・プロセスのインスタンスの数を指定します。MAX
パラメータ。同時に実行できるサーバ・プロセスの最大数を指定します。MIN
および MAX
パラメータは、指定されたオブジェクトへの要求をサーバ・アプリケーションでどの程度まで並行処理できるかを決定します。実行時には、必要に応じて、システム管理者がリソースのボトルネックを調べて追加のサーバ・プロセスを起動することができます。このアプリケーションは、システム管理者がスケーリングできるように設計されています。
次の例は、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
# デフォルトでは、各サーバのインスタンスを 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
オブジェクト状態管理によるアプリケーションのスケーリング
CORBA サーバ・アプリケーションの概念で説明したように、オブジェクト状態管理は大規模なクライアント/サーバ・システムでは根本的に重要な検討事項です。それは、こうしたシステムでは最適なスループットおよび応答時間を実現することが重要であるためです。この節では、BEA Tuxedo サーバ・アプリケーションによって管理されるオブジェクトのスケーラビリティを高めるためにオブジェクト状態管理を使用する方法を、Production サンプル・アプリケーションの Registrar
および Teller
オブジェクトを例にして説明します。
次のテーブルは、使用する BEA Tuxedo アプリケーションのスケーラビリティを大きく高めるために、BEA Tuxedo システムでサポートされているオブジェクト状態管理モデルを使用する方法をまとめたものです。
スケーラビリティによる性能向上を達成するには、Production サーバ・アプリケーションの Registrar
および Teller
オブジェクトを、method
活性化方針を持つようにコンフィギュレーションする必要があります。これら 2 つのオブジェクトに method
活性化方針を割り当てた結果、振る舞いに次の変化がみられます。
Basic サンプル・アプリケーションから Wrapper サンプル・アプリケーションを通じて、Registrar
オブジェクトはプロセス・バウンドです。このオブジェクトへのすべてのクライアント要求は、マシンのメモリにある同じオブジェクトのインスタンスへ送られます。Basic サンプル・アプリケーションの設計は、すべての小規模なデプロイメントに適しています。しかし、クライアント・アプリケーションの要求が増すにつれて、Registrar
オブジェクト上のクライアント要求はキューに入れられるようになり、このため応答時間が遅くなります。
しかし、Registrar
および Teller
オブジェクトが状態を持たず、これらのオブジェクトを管理するサーバ・プロセスが複製されていれば、これらのオブジェクトはクライアント要求の並行処理に利用可能になります。これらのオブジェクトで同時に処理できるクライアント要求の数に対する唯一の制限は、これらのオブジェクトをインスタンス化できる利用可能なサーバ・プロセスの数です。そのため、こうした状態を持たないオブジェクトを使用すれば、マシンのリソースを効率的に利用でき、クライアントへの応答時間も短縮されます。
最も重要なのは、BEA Tuxedo システムが Registrar
および Teller
オブジェクトのコピーを、両オブジェクトごとに複製されたサーバ・プロセス内でインスタンス化できるようにするためには、これらのオブジェクトのコピーが一意である必要があるということです。こうしたオブジェクトの各インスタンスを一意にするには、これらのオブジェクトに関係するファクトリで一意なオブジェクト ID を割り当てる必要があります。このことも含めて、これら 2 つのオブジェクトに関する設計上の検討事項については、「Registrar および Teller オブジェクトに関する設計上の追加考慮事項」を参照してください。
ファクトリ・ベース・ルーティング
ファクトリ・ベース・ルーティングは、特定のサーバ・グループへクライアント要求を送信する方法を提供する強力な機能です。ファクトリ・ベース・ルーティングを使用すれば、アプリケーションの処理負荷を複数のマシンに分散できます。これは、指定されたオブジェクトがインスタンス化されるグループ、すなわちマシンを決定できるからです。
ファクトリ・ベース・ルーティングを使用すれば、BEA Tuxedo システムのさまざまなロード・バランシング機能およびスケーラビリティ機能を拡張することができます。Production サンプル・アプリケーションの場合、ファクトリ・ベース・ルーティングを使用すれば、学生のサブセットの 1 つを登録する要求を 1 台のマシンへ送信し、別のサブセットに関する要求は別のマシンへ送信することができます。使用するアプリケーションの処理能力を増やすためにマシンを追加しても、BEA Tuxedo システムではアプリケーションのファクトリ・ベース・ルーティングを簡単に変更してマシンの追加に対応できます。
ファクトリ・ベース・ルーティングの第一の利点は、デプロイメント環境の拡大に対応して、アプリケーション、特にインターフェイスの呼び出し機能をスケール・アップするための簡単な方法が提供されることです。アプリケーションのデプロイメント範囲を追加マシンにも広げることは、厳密には管理用の機能であり、アプリケーションの再コーディングや再ビルドは不要です。
クライアント/サーバ・アプリケーションにファクトリ・ベース・ルーティングをインプリメントする際に設計上最も重要な検討事項は、ルーティングのベースとなる値の選択です。以下の節では、ファクトリ・ベース・ルーティングの機能について、Production サンプル・アプリケーションを使用して説明します。Production サンプル・アプリケーションは、ファクトリ・ベース・ルーティングを次のように使用します。
Registrar
オブジェクトへのクライアント・アプリケーション要求は、学生 ID に基づいてルーティングされます。つまり、学生のサブセットの 1 つに関する要求が 1 つのグループに送られ、別のサブセットに関する要求は別のグループに送られます。Teller
オブジェクトへの要求は、口座番号に基づいてルーティングされます。つまり、口座のサブセットの 1 つに関する要求が 1 つのグループに送られ、別のサブセットに関する要求は別のグループに送られます。ファクトリ・ベース・ルーティングのしくみ
ファクトリでファクトリ・ベース・ルーティングをインプリメントする際には、ファクトリがオブジェクト・リファレンスを作成する方法が変更されます。すべてのオブジェクト・リファレンスはグループ ID を含み、デフォルトのグループ ID はオブジェクト・リファレンスを作成するファクトリと同じになります。しかし、ファクトリ・ベース・ルーティングを使用する場合、ファクトリはグループ ID を決定するルーティング基準も含めてオブジェクト・リファレンスを作成します。その後、クライアント・アプリケーションがこうしたオブジェクト・リファレンスを使用して呼び出しを送信すると、BEA Tuxedo システムによって、要求はオブジェクト・リファレンスに指定されたグループ ID へルーティングされます。ここでは、オブジェクト・リファレンスに関するグループ ID がどのようにして生成されるかを説明します。
ファクトリ・ベース・ルーティングをインプリメントするには、次の項目を調整する必要があります。
UBBCONFIG
ファイルの INTERFACES
および ROUTING
セクションのデータ。UBBCONFIG
ファイルでコンフィギュレーションされているグループ、マシンおよびデータベース。調整が必要なデータについて説明するために、以降の 2 つの節では、UBBCONFIG
ファイルでのファクトリ・ベース・ルーティングのコンフィギュレーションと、ファクトリでのファクトリ・ベース・ルーティングのインプリメンテーションを説明します。
UBBCONFIG ファイルでのファクトリ・ベース・ルーティングのコンフィギュレーション
要求がルーティングされる各インターフェイスについて、UBBCONFIG
ファイルに次の情報を記述する必要があります。
ファクトリ・ベース・ルーティングをコンフィギュレーションするには、UBBCONFIG
ファイルの INTERFACES
および ROUTING
セクションで次のデータを指定するほか、グループおよびマシンを識別する方法を指定する必要があります。
INTERFACES
セクションには、ファクトリ・ベース・ルーティングを使用可
能にする必要があるインターフェイスの名前をリストします。各インター
フェイスについて、このセクションでインターフェースのルーティングの基
準の種類を指定します。このセクションでは、次の例のように、
FACTORYROUTING
という識別子でルーティング基準を指定します。
INTERFACES
"IDL:beasys.com/UniversityP/Registrar:1.0"
FACTORYROUTING = STU_ID
"IDL:beasys.com/BillingP/Teller:1.0"
FACTORYROUTING = ACT_NUM
上の例では、Production サンプルでファクトリ・ベース・ルーティングが使用される 2 つのインターフェイスの完全修飾されたインターフェイス名を示します。FACTORYROUTING
識別子は、ルーティング値の名前として STU_ID
および ACT_NUM
をそれぞれ指定します。
ROUTING
セクションでは、ルーティング値ごとに以下のデータを指定しま
す。
TYPE
パラメータ。ルーティングの種類を指定します。Production サンプルでは、ルーティングの種類はファクトリ・ベース・ルーティングです。このため、このパラメータは FACTORY
と定義されます。FIELD
パラメータ。ファクトリがルーティング値に挿入する名前を指定します。Production サンプルでは、フィールドのパラメータはそれぞれ student_id
および account_number
です。FIELDTYPE
パラメータ。ルーティング値のデータ型を指定します。Production サンプルでは、student_id
および account_number
のフィールド・タイプは long
です。RANGES
パラメータ。各グループにルーティングされる値を指定します。 次の例は、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"
上の例では、一方の範囲に入る ID を持った学生についての Registrar
オブジェクト・リファレンスは一方のサーバ・グループにルーティングされ、もう一方の範囲に入る ID を持った学生についての Registrar
オブジェクト・リファレンスは他方のグループにルーティングされるということが示されています。同様に、一方の範囲に入る口座についての Teller
オブジェクト・リファレンスは一方のサーバ・グループへルーティングされ、もう一方の範囲に入る口座についての Teller
オブジェクト・リファレンスは他方のグループにルーティングされています。
UBBCONFIG
ファイルの ROUTING
セクションにある RANGES
識別子で指定され
ているグループを識別およびコンフィギュレーションする必要があります。
たとえば、Production サンプルでは 4 つのグループが指定されています。
APP_GRP1、APP_GRP2、ORA_GRP1、および ORA_GRP2 です。これらの
グループをコンフィギュレーションして、グループが実行されるマシンを識
別する必要があります。
次の例は、Production サンプルの UBBCONFIG
ファイルの GROUPS
セクションを示します。このセクションで、ORA_GRP1 および ORA_GRP2 グループがコンフィギュレーションされています。GROUPS
セクションに列挙されている名前が、ROUTING
セクションに指定されているグループ名とどのように一致するかに注目してください。この点が、ファクトリ・ベース・ルーティングの正常な動作に不可欠です。さらに、アプリケーションでグループをコンフィギュレーションする方法に関する何らかの変更も、ROUTING
セクションに反映される必要があります。BEA 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/..."
CLOSEINFO = ""
TMSNAME = "TMS_ORA"
ORA_GRP2
LMID = SITE1
GRPNO = 5
OPENINFO = "ORACLE_XA:Oracle_XA+Acc=P/scott/..."
CLOSEINFO = ""
TMSNAME = "TMS_ORA"
ファクトリでのファクトリ・ベース・ルーティングのインプリメンテーション
ファクトリは、TP::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
をビルドすることにあります。
先に説明したように、Production サンプル・アプリケーションの RegistrarFactory
オブジェクトは STU_ID
という値を指定します。この値は、UBBCONFIG
ファイルの次の項目と正確に一致する必要があります。
INTERFACES
セクションの FACTORYROUTING
識別子によって指定されるルーティング名、型、および使用できる値。ROUTING
セクションに指定されるルーティング基準名、フィールド、およびフィールド型。RegistrarFactory
オブジェクトは、次のコードを使用して NVlist
に学生 ID を挿入します。
// 学生 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
オブジェクトは次のようにして TP::create_object_reference()
オペレーションを呼び出し、前のコード例で作成された NVlist
を渡します。
// registrar オブジェクト・リファレンスを、ルーティング基準を
// 使用して作成する
CORBA::Object_var v_reg_oref =
TP::create_object_reference(
UniversityP::_tc_Registrar->id(),
object_id,
v_criteria.in()
);
また、Production サンプル・アプリケーションは、TellerFactory
オブジェクトでのファクトリ・ベース・ルーティングも使用して、Teller
オブジェクトが口座番号に基づいてどのグループでインスタンス化されるべきであるかを判別します。
注記 指定されたインターフェイスおよび OID を持つ 1 つのオブジェクトが 2 つの異なるグループで同時に活性化されることも、それら 2 つのグループに同じオブジェクト・インプリメンテーションがある場合には起こりえます。しかし、使用するファクトリで一意な OID が生成されていれば、こうした状況はほぼありません。指定されたインターフェイス名および OID の 1 つのオブジェクトがドメイン内で一度に 1 つだけ利用可能であることを保証する必要がある場合は、次のいずれかを行います。ファクトリ・ベース・ルーティングを使用して、特定の OID のオブジェクトが常に同じグループにルーティングされるようにするか、指定されるオブジェクト・インプリメンテーションが 1 つのグループのみに存在するようにドメインをコンフィグレーションする。そうすれば、指定されたインターフェイス名および OID を持つ 1 つのオブジェクトに複数のクライアントがオブジェクト・リファレンスをした場合でも、そのリファレンスは常に同じオブジェクト・インスタンスへルーティングされることになります。
オブジェクトの OID によるルーティングを利用可能にするには、TP::create_object_reference()
オペレーションで OID をルーティング基準に指定してから、UBBCONFIG
ファイルをそれに合わせて設定します。
実行時の処理
ファクトリでファクトリ・ベース・ルーティングをインプリメントするとき、BEA Tuxedo システムによってオブジェクト・リファレンスが生成されます。次の例は、ファクトリ・ベース・ルーティングがインプリメントされているときにクライアント・アプリケーションが Registrar
オブジェクトへのオブジェクト・リファレンスを取得する方法を示します。
RegistrarFactory
オブジェクトを呼び
出して、Registrar
オブジェクトへのリファレンスを要求します。要求には
学生 ID が含まれます。
RegistrarFactory
は、学生 ID を NVlist
に挿入します。NVlist はルーティ
ング基準として使用されます。
RegistrarFarctory
は TP::create_object_reference()
オペレーション
を呼び出して、Registrar
インターフェイス名、一意な OID、および
NVlist
を渡します。
NVlist
の値と比
較して、グループ ID を判別します。
続いてクライアント・アプリケーションがオブジェクト・リファレンスを使用してオブジェクト呼び出しを実行した場合、BEA Tuxedo システムはその要求を、オブジェクト・リファレンスで指定されたグループへルーティングします。
注記 Process-Entity デザイン・パターンを使用する場合は、ファクトリ・ベース・ルーティングのインプリメンテーションに注意してください。オブジェクトは、グループのデータベースに含まれているエンティティだけを提供できます。
Registrar および Teller オブジェクトに関する設計上の追加考慮事項
Registrar
および Teller
オブジェクトの設計に影響する主な考慮事項には、以下のものがあります。
Registrar
および Teller
オブジェクトが Production のデプロイメント環境、つまり、複数の複製されたサーバ・プロセスおよび複数のグループで適切に機能するようにする方法。University および Billing サーバ・プロセスが複製されている場合は、設計時にこれら 2 つのオブジェクトをインスタンス化する方法を考慮する必要があります。これらの考慮事項の主要な意味は、これらのオブジェクトが次の項目を満たす必要があるということです。
method
活性化方針が割り当てられている。以降の節では、これらの検討事項およびその内容について詳しく説明します。
Registrar および Teller オブジェクトのインスタンス化
Production サンプル・アプリケーションの前に扱った University サーバ・アプリケーションでは、Registrar
および Teller
オブジェクトの実行時の振る舞いは簡単なものでした。
しかし、University および Billing サーバ・プロセスが複製されると、BEA Tuxedo ドメインには Registrar
および Teller
オブジェクトの複数のインスタンスを区別する方法が必要になります。つまり、1 つのグループで 2 つの University サーバ・プロセスが実行中である場合、BEA Tuxedo ドメインには、いわば、1 番目の University サーバ・プロセスで実行中の Registrar
オブジェクトと、2 番目の University サーバ・プロセスで実行中の Registrar
オブジェクトを区別するための方法が必要になります。
これらのオブジェクトの複数のインスタンスを区別する機能を BEA Tuxedo ドメインに与える方法は、オブジェクトの各インスタンスを一意にすることです。
各 Registrar
および Teller
オブジェクトを一意にするには、これらのオブジェクトへのオブジェクト・リファレンスをファクトリで作成する際の方法を変更する必要があります。たとえば、Basic サンプル・アプリケーションの RegistrarFactory
オブジェクトが Registrar
オブジェクトへのオブジェクト・リファレンスを作成するとき、TP::create_object_reference()
オペレーションが指定する OID には registrar
という文字列が含まれているだけでした。しかし、Production サンプル・アプリケーションの場合、同じ TP::create_object_reference()
オペレーションでは生成済みの一意な OID が使用されます。
Registrar
および Teller
オブジェクトのそれぞれに一意な OID を付与した結果、これらのオブジェクトの複数のインスタンスが、BEA Tuxedo ドメインの中で同時に実行できるようになりました。この特性は状態を持たないオブジェクト・モデルに典型的なもので、BEA Tuxedo ドメインのスケーラビリティを高めつつ、高い性能を提供する方法の例でもあります。
そして最後に、一意な Registrar
および Teller
オブジェクトはクライアント要求ごとにメモリに格納される必要があるため、これらのオブジェクトへの呼び出しが完了したときには、オブジェクトの状態がメモリ上でアイドル状態となって残らないように、オブジェクトを非活性化することが非常に重要になります。Production サーバ・アプリケーションでは、ICF ファイルでこれら 2 つのオブジェクトに method
活性化方針を割り当てることで、この問題を解決しています。
適切なサーバ・グループで学生の登録が発生するようにする方法
複製されたサーバ・グループを使用することでスケーラビリティについて得られる最大の利点は、複数のマシンに処理を分散できることです。しかし、University サンプル・アプリケーションのように、使用するアプリケーションがデータベースとやり取りを行う場合は、こうした複数のサーバ・グループがデータベースとのやり取りに与える悪影響を考慮することが不可欠です。
多くの場合、デプロイメント環境のマシン 1 台につき 1 つのデータベースが関連付けられています。使用するサーバ・アプリケーションが複数のマシンに分散されている場合は、データベースを設定する方法について検討する必要があります。
Production サンプル・アプリケーションでは、この章で説明したように、2 つのデータベースが使用されます。しかし、このアプリケーションでさらに多くのデータベースを使用するように、コンフィギュレーションを簡単に変更することができます。使用するデータベースの数は、システム管理者が決定してください。
Production サンプル・アプリケーションでは、学生情報と口座情報は 2 つのデータベースに分割されていますが、コース情報は同一です。2 つのデータベースで同一のコース情報を持つことは、問題になりません。なぜなら、コース登録の目的上、コース情報は読み取り専用であるからです。一方で、学生情報および口座情報については読み書きが行われます。複数のデータベースが学生および口座についても同一のデータを格納するとしたら (つまり、データベースが分割されていない場合)、アプリケーションでは、学生情報または口座情報が変更されるたびにデータベース全体にわたって学生および口座の情報の更新を同期する処理のオーバーヘッドに対処する必要が生じるでしょう。
Production サンプル・アプリケーションはファクトリ・ベース・ルーティングを使用して要求のセットの 1 つを 1 台のマシンに送信し、別のセットを別のマシンに送信します。先に説明したように、ファクトリ・ベース・ルーティングは、Registrar
オブジェクトへのリファレンスが作成されている方法によって RegistrarFactory
オブジェクトにインプリメントされています。
たとえば、Registrar
オブジェクトへのリファレンスを取得するためにクライアント・アプリケーションが RegistrarFactory
オブジェクトに要求を送信するとき、クライアント・アプリケーションは要求に学生 ID を含めます。以後、クライアント・アプリケーションは、特定の学生に関する Registrar
オブジェクトの呼び出しを実行する際には、RegistrarFactory
オブジェクトが返すオブジェクト・リファレンスを使用する必要があります。これは、ファクトリによって返されるオブジェクト・リファレンスがグループ固有のものであるからです。このため、たとえば、続けてクライアント・アプリケーションが Registrar
オブジェクトの get_student_details()
オペレーションを呼び出したときに、学生のデータがあるデータベースと関連付けられているサーバ・グループでは Registrar
オブジェクトが活性化されているということが、クライアント・アプリケーションに対して保証されるといったことも可能です。この機能を示すために、Production サンプル・アプリケーションにインプリメントされている次の実行シナリオを検討してみます。
RegistrarFactory
オブジェクトの
find_registrar()
オペレーションを呼び出します。この要求には学生 ID
1000003 が含まれます。
BEA Tuxedo
ドメインは、クライアント要求を任意の RegistrarFactory
オ
ブジェクトにルーティングします。
RegistrarFactory
オブジェクトは、UBBCONFIG
ファイルのルーティング情
報に基づいて、学生 ID を使用して ORA_GRP1 の Registrar
オブジェクト
へのオブジェクト・リファレンスを作成し、このオブジェクト・リファレン
スをクライアント・アプリケーションに返します。
register_for_courses()
オペレーションを呼び出します。
Registrar
オブジェクトをインスタンス化
してから、同オブジェクトにクライアント呼び出しを送信します。
以上のシナリオの RegistrarFactory
オブジェクトがクライアント・アプリケーションに返すのは、ORA_GRP1 でだけインスタンス化できる Registrar
オブジェクトへの一意なリファレンスです。ORA_GRP1 は Production マシン 1 で実行されていて、学生 ID が 100001 〜 100005 の範囲の学生に関するデータが格納されているデータベースを利用します。このため、続けてクライアント・アプリケーションが学生に関する Registrar
オブジェクトへの要求を送信したとき、Registrar
オブジェクトは適切なデータベースとやり取りができます。
Teller オブジェクトが適切なサーバ・グループでインスタンス化されるようにする方法
Registrar
オブジェクトで Teller
オブジェクトが必要になると、Registrar
オブジェクトは TellerFactory
オブジェクトを呼び出します。このとき、University Server オブジェクトでキャッシュされている TellerFactory
オブジェクト・リファレンスが使用されます。詳細については、「Teller オブジェクトへの要求の送信」を参照してください。
しかし、ファクトリ・ベース・ルーティングが TellerFactory
オブジェクトで使用されているので、Registrar
オブジェクトが学生の口座番号を渡すのは、Registrar
オブジェクトが Teller
オブジェクトへのリファレンスを要求するときになります。このようにして、TellerFactory
オブジェクトは、正しいデータベースがあるグループに Teller
オブジェクトへのリファレンスを作成します。
注記 Production サンプル・アプリケーションが正しく機能するには、システム管理者がサーバ・グループおよびデータベースのコンフィギュレーションを正しく行うことが必須です。特に、システム管理者は、ルーティング・テーブルで指定されているルーティング基準と、このルーティング基準を使用する要求のルーティング先となるデータベースとの間に、必ず一致が存在するようにしなければなりません。Production サンプルを例にすると、指定されたグループにあるデータベースは、そのグループにルーティングされた要求に正しく対応する学生情報および口座情報を含んでいる必要があります。
Production サーバ・アプリケーションをさらにスケーリングする方法
将来的には、Production サンプル・アプリケーションのシステム管理者が BEA Tuxedo ドメインの容量を増やす必要を感じる場合もあります。たとえば、University で学生数が大幅に増加した場合や、7 つのキャンパスがある大学の全体のコース登録処理を扱えるように Production アプリケーションをスケール・アップする場合などが考えられます。こうしたスケーリングを、アプリケーションの変更や再ビルドをせずに実現できます。
継続的に容量を追加するために、システム管理者には以下のツールが用意されています。
UBBCONFIG
ファイルを変更する必要があります。サーバ・プロセスが実行されるグループを追加し、グループでどのサーバ・プロセスを実行するか指定してから、どのマシンで実行するかを指定してください。
たとえば、この章で示したように 2 つのグループへルーティングする代わりに、システム管理者が UBBCONFIG
ファイルでルーティング・ルールを変更することで、BEA Tuxedo ドメインに追加された新しいグループの間でアプリケーションの処理をさらに分離することが可能です。ルーティング・テーブルへのすべての変更は、UBBCONFIG
ファイルでコンフィギュレーションされているサーバ・グループおよびマシンに対するすべての変更および追加と整合している必要があります。
注記 データベースを使用するアプリケーションの容量を増やす場合、特にファクトリ・ベース・ルーティングを使用しているときには、データベースの設定に与える影響を検討する必要があります。たとえば、Production サンプル・アプリケーションが 6 台のマシンに分散している場合、各マシン上のデータベースは、適切に設定されて、UBBCONFIG
ファイルのルーティング・テーブルに合致している必要があります。
状態を持たないオブジェクトまたは状態を持つオブジェクトの選択
一般に、状態を持たないオブジェクトをインプリメントする際のコストと、状態を持つオブジェクトをインプリメントする際のコストを比較する必要があります。
オブジェクトをその永続状態で初期化するコストが高い場合 (これは、たとえば、そのオブジェクトのデータが大きな領域を占めている場合や、永続状態の場所が、それを活性化するサーバントから大幅に離れたディスク上である場合ですが)、たとえオブジェクトが会話の間アイドル状態であるとしても、オブジェクトが状態を持たないようにしておく方が合理的です。オブジェクトを活性化しておくコストがマシンのリソース使用の面で高くつく場合は、そうしたオブジェクトが状態を持たないようにするのが合理的です。
オブジェクト状態の管理をアプリケーションにとって効率的かつ適切な方法で行うことで、多数のオブジェクトを利用するクライアント・アプリケーションを同時に多数サポートするアプリケーションの機能を最高にすることができます。一般には、こうした目的のために、オブジェクトに対して method
活性化方針を割り当てます。こうすることによって、アイドル状態のオブジェクト・インスタンスが非活性化され、マシンのリソースをほかのオブジェクト・インスタンスに割り当てられるようになります。ただし、使用するアプリケーション固有の特性および要件は、アプリケーションごとに異なります。
注記 BEA Tuxedo リリース 8.0 では、性能の拡張として、パラレル・オブジェクトのサポートが提供されています。この機能を利用すると、特定アプリケーションのすべてのビジネス・オブジェクトを状態を持たないオブジェクトにすることができます。詳細については、『BEA Tuxedo CORBA プログラミング・リファレンス』の「TP フレームワーク」を参照してください。
状態を持たないオブジェクトが必要な場合
一般に状態を持たないオブジェクトは良好な性能とサーバ・リソースの最適な使用を実現しますが、これはオブジェクトがアイドル状態のときにサーバ・リソースが決して使用されないためです。状態を持たないオブジェクトは、一般に、サーバ・アプリケーションのインプリメンテーションに適した手法です。状態を持たないオブジェクトは、特に以下の状況に適しています。
オブジェクトを状態を持たないようにすることで、サーバ・アプリケーションのリソースがクライアント・アプリケーションからの入力の待機のために不定期に長時間拘束されないようにできます。
状態を持たないオブジェクト・モデルを使用するアプリケーションでは、次の特性に注意してください。
状態を持つオブジェクトが必要な場合
状態を持つオブジェクトは、いったん活性化されると、特定のイベントが発生するまでメモリ内にとどまります。当該のイベントは、たとえば、オブジェクトが存在しているプロセスのシャットダウン、またはオブジェクトが活性化されているトランザクションの完了などです。
状態を持つオブジェクトは、一般に以下の状況に適しています。
注記 プロセス・オブジェクトをトランザクションにどのように関与させるかについては、注意深く検討してください。トランザクションに関与しているすべてのオブジェクトは、ほかのクライアント・アプリケーションまたはオブジェクトから呼び出せません。プロセス・オブジェクトは多数のクライアント・アプリケーションによって利用されるので、トランザクションに対して頻繁に、または長期間関与すると、問題の原因になる可能性があります。
状態を持つオブジェクトの以下の振る舞いに注意してください。
たとえば、1 つのオブジェクトがデータベースにロックを保持し、大量のデータをメモリにキャッシュしている場合、その状態を持つオブジェクトによって使用されているデータベースおよびメモリは、トランザクションが完了するまでほかのオブジェクトでは利用できません。
![]() |
![]() |
|
Copyright © 2001, BEA Systems, Inc. All rights reserved.
|