|
•
|
CourseSynopsisEnumeratorオブジェクトは、どのUniversityサーバー・プロセスでも、任意の数だけ存在することができます。
|
図8-2に、別のマシンにレプリケートされたProductionサンプル・アプリケーションのグループを示します。このアプリケーションの
UBBCONFIGファイルに指定されているとおり、ORA_GRP2とAPP_GRP2があります。
図8-2では、Productionマシン1と2のグループの内容で異なるのはデータベースのみです。Productionマシン1用のデータベースには、学生のサブセットについて、学生情報および口座情報が含まれています。Productionマシン2用のデータベースには、学生の別のサブセットについて、学生情報および口座情報が含まれています。(両方のデータベースにあるコース情報の表は同じ内容です。)データベースにある学生情報が、同じデータベース内の口座情報とは完全に無関連であることに注意してください。
|
1.
|
アプリケーションのUBBCONFIGファイルを、ワードパッドなどのテキスト・エディタで開きます。
|
|
2.
|
GROUPSセクションで、構成するグループの名前を指定します。
|
|
3.
|
SERVERSセクションに、レプリケートするサーバー・プロセスに関する次の情報を入力します。
|
|
•
|
GROUPパラメータ。サーバー・プロセスが属するグループの名前を指定します。複数のグループに関係するサーバー・プロセスをレプリケートする場合は、各グループに1つずつサーバー・プロセスを指定します。
|
|
•
|
SRVIDパラメータ。数値識別子を指定して、サーバー・プロセスに一意のIDを割り当てます。
|
|
•
|
MINパラメータ。アプリケーションの起動時に開始されるサーバー・プロセスのインスタンスの数を指定します。
|
|
•
|
MAXパラメータ。同時に実行できるサーバー・プロセスの最大数を指定します。
|
MINおよび
MAXパラメータは、指定されたオブジェクトへのリクエストをサーバー・アプリケーションでどの程度まで並行処理できるかを決定します。実行時には、必要に応じて、システム管理者がリソースのボトルネックを調べて、新しいサーバー・プロセスを起動することができます。このアプリケーションは、システム管理者がスケーリングできるように設計されています。
第1章「CORBAサーバー・アプリケーションの概念」で説明したように、オブジェクト状態管理は大規模なクライアント/サーバー・システムでは根本的に重要な検討事項です。それは、こうしたシステムでは最適なスループットおよび応答時間を実現することが重要であるためです。この節では、Oracle Tuxedoサーバー・アプリケーションによって管理されるオブジェクトのスケーラビリティを高めるためにオブジェクト状態管理を使用する方法を、Productionサンプル・アプリケーションの
Registrarおよび
Tellerオブジェクトを例にして説明します。
Basicサンプル・アプリケーションからWrapperサンプル・アプリケーションを通じて、Registrarオブジェクトはプロセス・バウンドです。このオブジェクトへのすべてのクライアント・リクエストは、マシンのメモリーにある同じオブジェクトのインスタンスへ送られます。Basicサンプル・アプリケーションの設計は、すべての小規模なデプロイメントに適しています。しかし、クライアント・アプリケーションのリクエストが増すにつれて、
Registrarオブジェクト上のクライアント・リクエストはキューに入れられるようになり、このためレスポンス時間が遅くなります。
しかし、Registrarおよび
Tellerオブジェクトがステートレスで、これらのオブジェクトを管理するサーバー・プロセスがレプリケートされていれば、これらのオブジェクトはクライアント・リクエストの並行処理に使用可能になります。これらのオブジェクトで同時に処理できるクライアント・リクエストの数に対する唯一の制限は、これらのオブジェクトをインスタンス化できる利用可能なサーバー・プロセスの数です。したがって、これらのステートレス・オブジェクトはマシン・リソースのより効率的な使用と、クライアントレスポンス時間の短縮を実現します。
ファクトリ・ベース・ルーティングは、特定のサーバー・グループへクライアント・リクエストを送信する方法を提供する強力な機能です。ファクトリ・ベース・ルーティングを使用すれば、アプリケーションの処理負荷を複数のマシンに分散できます。これは、指定されたオブジェクトがインスタンス化されるグループ、つまりマシンを決定できるからです。
|
•
|
Registrarオブジェクトへのクライアント・アプリケーション・リクエストは、学生IDに基づいてルーティングされます。つまり、学生のサブセットの1つに関するリクエストが1つのグループに送られ、別のサブセットに関するリクエストは別のグループに送られます。
|
|
•
|
Tellerオブジェクトへのリクエストは、口座番号に基づいてルーティングされます。つまり、口座のサブセットの1つに関するリクエストが1つのグループに送られ、別のサブセットに関するリクエストは別のグループに送られます。
|
|
•
|
UBBCONFIGファイルの INTERFACESおよび ROUTINGセクションのデータ。
|
|
•
|
UBBCONFIGファイルで構成されているグループ、マシンおよびデータベース。
|
|
1.
|
INTERFACESセクションには、ファクトリ・ベース・ルーティングを有効にするインタフェースの名前の一覧が示されます。各インタフェースについて、このセクションでインタフェースのルーティングの基準の種類を指定します。このセクションでは、次の例のように、 FACTORYROUTINGという識別子でルーティング基準を指定します。
|
|
2.
|
ROUTINGセクションでは、ルーティング値ごとに次のデータを指定します。
|
|
•
|
TYPEパラメータは、ルーティングのタイプを指定します。Productionサンプルでは、ルーティングのタイプはファクトリ・ベース・ルーティングです。したがって、このパラメータは、 FACTORYと定義します。
|
|
•
|
FIELDパラメータは、ファクトリがルーティング値に挿入する名前を指定します。Productionサンプルでは、フィールド・パラメータはそれぞれ、 student_idおよび account_numberです。
|
|
•
|
FIELDTYPEパラメータは、ルーティング値のデータ型を指定します。Productionサンプルでは、 student_idおよび account_numberのフィールド型は longです。
|
|
•
|
RANGESパラメータは、各グループにルーティングされる値を指定します。
|
前述の例では、一方の範囲に入るIDを持った学生についてのRegistrarオブジェクト参照は一方のサーバー・グループにルーティングされ、もう一方の範囲に入るIDを持った学生についての
Registrarオブジェクト参照は他方のグループにルーティングされるということが示されています。同様に、ある1つの範囲の口座に対する
Tellerオブジェクト参照は、ある1つのサーバー・グループにルーティングされ、別の範囲の口座に対する
Tellerオブジェクト参照は、別のグループにルーティングされます。
|
3.
|
UBBCONFIGファイルの ROUTINGセクションにある RANGES識別子で指定されたグループを識別および構成する必要があります。たとえば、ProductionサンプルはAPP_GRP1、APP_GRP2、ORA_GRP1、およびORA_GRP2という4つのグループを指定します。これらのグループを構成し、グループが実行されるマシンを識別する必要があります。
|
次の例は、ProductionサンプルのUBBCONFIGファイルの
GROUPSセクションを示します。このセクションで、ORA_GRP1およびORA_GRP2グループが構成されています。
GROUPSセクションに列挙されている名前が、
ROUTINGセクションに指定されているグループ名とどのように一致するかに注目してください。さらに、アプリケーションでグループを構成する方法に関する何らかの変更も、
ROUTINGセクションに反映させる必要があります。(Oracle Tuxedoソフトウェアに収録されているProductionサンプルは、1台のマシンで実行するように構成されていることに注意してください。しかし、このアプリケーションを複数のマシンで実行するように構成することも容易にできます。)
ファクトリは、TP::create_object_reference()操作への呼出しが実装されている方法によってファクトリ・ベース・ルーティングを実装します。この操作には、次のC++バインドがあります。
この操作に対する3番目のパラメータであるcriteriaは、ファクトリ・ベース・ルーティングに使用される名前の付いた値のリストを指定します。このため、ファクトリでファクトリ・ベース・ルーティングを実装する機能は、
NVlistをビルドすることにあります。
|
•
|
INTERFACESセクションの FACTORYROUTING識別子で指定される、ルーティング名、タイプおよび使用できる値。
|
|
•
|
ROUTINGセクションで指定される、ルーティング基準名、フィールドおよびフィールド型。
|
RegistrarFactoryオブジェクトは、次のコードを使用して
NVlistに学生IDを挿入します。
RegistrarFactoryオブジェクトは次のようにして
TP::create_object_reference()操作を呼び出し、前のサンプル・コードで作成された
NVlistを渡します。
|
1.
|
クライアント・アプリケーションが、RegistrarFactoryオブジェクトを呼び出し、 Registrarオブジェクトの参照をリクエストします。リクエストには学生IDが含まれます。
|
|
2.
|
RegistrarFactoryは、 NVlistに学生IDを挿入します。これは、ルーティング基準として使用されます。
|
|
3.
|
RegistrarFactoryは、 TP::create_object_reference()操作を呼び出し、 Registrarインタフェース名、一意のOIDおよび NVlistを渡します。
|
Registrarおよび
Tellerオブジェクトの設計に影響する主な考慮事項には、次のものがあります。
|
•
|
Registrarおよび TellerオブジェクトがProductionのデプロイメント環境、つまり、複数のレプリケートされたサーバー・プロセスおよび複数のグループで適切に機能するようにする方法。UniversityおよびBillingの各サーバー・プロセスがレプリケートされている場合の設計では、これら2つのオブジェクトをどのようにインスタンス化するかを考慮する必要があります。
|
各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アクティブ化ポリシーを割り当てることで、この問題を解決しています。
たとえば、クライアント・アプリケーションがRegistrarFactoryオブジェクトにリクエストを送信して、
Registrarオブジェクトのオブジェクト参照を取得した場合、クライアント・アプリケーションはそのリクエストに学生IDを含めます。ファクトリによって返されたオブジェクト参照はグループ固有のものであるため、クライアント・アプリケーションは、
RegistrarFactoryオブジェクトが返すオブジェクト参照を使用して、その後の
Registrarオブジェクトへのすべての呼出しを、特定の学生のために行う必要があります。したがって、たとえばクライアント・アプリケーションがその後、
Registrarオブジェクトに対して
get_student_details()操作を呼び出すと、クライアント・アプリケーションでは、
Registrarオブジェクトが、その学生のデータを格納しているデータベースと関連付けられたサーバー・グループにおいて、確実にアクティブ化されます。この機能を示すために、Productionサンプル・アプリケーションに実装されている以下の実行シナリオを検討してみます。
|
1.
|
クライアント・アプリケーションは、RegistrarFactoryオブジェクトの find_registrar()操作を呼び出します。この要求には学生ID 1000003が含まれます。
|
|
3.
|
RegistrarFactoryオブジェクトは、 UBBCONFIGファイルのルーティング情報に基づいて、学生IDを使用してORA_GRP1の Registrarオブジェクトへのオブジェクト参照を作成し、このオブジェクト参照をクライアント・アプリケーションに返します。
|
前述のシナリオのRegistrarFactoryオブジェクトがクライアント・アプリケーションに返すのは、ORA_GRP1でのみインスタンス化できる
Registrarオブジェクトへの一意の参照です。ORA_GRP1はProductionマシン1で実行されていて、学生IDが100001 - 100005の範囲の学生に関するデータが格納されているデータベースを利用します。このため、続けてクライアント・アプリケーションが学生に関する
Registrarオブジェクトへのリクエストを送信したとき、
Registrarオブジェクトは適切なデータベースとやり取りができます。
Registrarオブジェクトで
Tellerオブジェクトが必要になると、
Registrarオブジェクトは
TellerFactoryオブジェクトを呼び出します。このとき、University Serverオブジェクトでキャッシュされている
TellerFactoryオブジェクト参照が使用されます。詳細は、
-10ページの「Tellerオブジェクトへのリクエストの送信」を参照してください。
しかし、TellerFactoryオブジェクトではファクトリ・ベース・ルーティングが使用されているため、
Registrarオブジェクトは
Tellerオブジェクトの参照リクエスト時に、学生の口座番号を渡します。
このようにして
TellerFactoryオブジェクトは、正しいデータベースを備えたグループ内の
Tellerオブジェクトへの参照を作成します。
UBBCONFIGファイルを変更する必要があります。サーバー・プロセスが実行されるグループを追加し、グループでどのサーバー・プロセスを実行するか指定してから、どのマシンで実行するかを指定してください。
