|
| 注意: | Productionサンプル・アプリケーションのクライアント・アプリケーションは、Wrapperサンプル・アプリケーションのクライアント・アプリケーションと同じ方法で動作します。 |
| 注意: | Oracle Tuxedo CORBA JavaクライアントとOracle Tuxedo CORBA JavaクライアントORBはTuxedo 8.1で非推奨になり、サポートされなくなりました。すべてのOracle Tuxedo CORBA JavaクライアントおよびOracle Tuxedo CORBA JavaクライアントORBのテキスト・リファレンスとコード・サンプルは、サード・パーティ製のJava ORBライブラリを実装または実行する際の参考や、プログラマの参照用としてのみ使用してください。 |
| 注意: | サード・パーティのCORBA Java ORBのテクニカル・サポートは、各ベンダーによって提供されます。Oracle Tuxedoでは、サード・パーティのCORBA Java ORBに関する技術的なサポートやドキュメントは提供していません。 |
Productionサンプル・アプリケーションには、Wrapperサンプル・アプリケーションと同じエンド・ユーザー向けの機能が用意されています。Productionサンプル・アプリケーションでは、Oracle TuxedoソフトウェアのCORBA機能を利用して、CORBAアプリケーションをスケーリングする方法を示します。Productionサンプル・アプリケーションでは、次の処理を行います。
UBBCONFIGファイルに定義されているORA_GRPおよびAPP_GRPサーバー・グループ内で、Universityサーバー・アプリケーション、Billingサーバー・アプリケーション、およびATMI Tellerアプリケーションを複製します。ORA_GRP1およびAPP_GRP1サーバー・グループをORA_GRP2およびAPP_GRP2として複製し、データベースを分割します。| 注意: | Productionサンプル・アプリケーションは簡単に使用できるように、Oracle Tuxedoソフトウェア・キットでは、1台のマシン上で1つのデータベースを使用して実行するように構成されています。ただし、Productionサンプル・アプリケーションは、複数のマシンで複数のデータベースを使用して実行するための構成もできるように設定されています。複数のマシンおよびデータベースに構成を変更するには、UBBCONFIGファイルを変更し、データベースを分割するだけでできます。 |
次の項では、Productionサンプル・アプリケーションで、複製されたサーバー・アプリケーション、複製されたサーバー・グループ、オブジェクト状態管理およびファクトリ・ベース・ルーティングを使用して、Productionサンプル・アプリケーションをスケーリングする方法について説明します。
サーバー・アプリケーションを複製すると、次の処理が可能になります。
Productionサンプル・アプリケーションでは、サーバー・アプリケーションは次の方法で複製されます。
図7-1に、複製されたORA_GRPおよびAPP_GRPグループを示します。

図7-1では、次の点に注意してください。
サーバー・グループは、既存のCORBAアプリケーションにサーバー・マシンを追加できる、Oracle Tuxedoソフトウェアの機能です。サーバー・グループを複製すると、次の処理が可能になります。
サーバー・グループの構成および複製方法は、UBBCONFIGファイルで指定します。
図7-2に、2番目のサーバー・マシンで複製されたProductionサンプル・アプリケーションのサーバー・グループを示します。Productionサンプル・アプリケーションのUBBCONFIGファイルでは、複製されたサーバー・グループは、ORA_GRP2およびAPP_GRP2として定義されています。

図7-2では、Productionマシン1および2のサーバー・グループの内容で異なるのはデータベースのみです。Universityデータベースは、2つのデータベースに分割されています。Productionマシン1のデータベースには、IDが100001 - 100005の学生の学生情報および口座情報が格納されています。Productionマシン2のデータベースには、IDが100006 - 100010の学生の学生情報および口座情報が格納されています。
スケーラビリティを向上させるには、Productionサンプル・アプリケーションで、RegistrarおよびTellerオブジェクトがmethodアクティブ化ポリシーを持つように構成します。methodアクティブ化ポリシーによって、オブジェクトの振る舞いは次のように変化します。
BasicからProductionまでのサンプル・アプリケーションのRegistrarオブジェクトには、processというアクティブ化ポリシーがありました。Registrarオブジェクトのクライアント・アプリケーションからのリクエストはすべて、サーバー・マシンのメモリーにある同じオブジェクトのインスタンスに送られました。この設計は小規模なデプロイメントには適しています。ただし、クライアント・アプリケーションのリクエストが増加するにしたがい、Registrarのクライアント・アプリケーションからのリクエストはキューに登録されるようになり、レスポンス時間が遅くなります。
これに対し、RegistrarおよびTellerオブジェクトにmethodのアクティブ化ポリシーがあり、これらのオブジェクトを管理するサーバー・アプリケーションを複製すると、RegistrarおよびTellerオブジェクトはクライアント・アプリケーションからの複数のリクエストを並列処理できるようになります。唯一の制限は、RegistrarおよびTellerオブジェクトのインスタンス化に利用可能なサーバー・アプリケーション・プロセスの数です。
CORBAアプリケーションでは、複製済の各サーバー・アプリケーション・プロセスでRegistrarおよびTellerオブジェクトのコピーをインスタンス化するために、RegistrarおよびTellerオブジェクトには、ユニークなオブジェクトID (OID)が割り当てられています。ユニークなOIDは、これらのオブジェクトを作成するファクトリで割り当てられます。ユニークなオブジェクトIDの生成の詳細は、『CORBAサーバー・アプリケーションの作成』を参照してください。
ファクトリ・ベース・ルーティングは、クライアント・アプリケーションからのリクエストを特定のサーバー・グループに送信可能にするCORBAの機能です。ファクトリ・ベース・ルーティングを使用すると、CORBAアプリケーションの処理にかかる負荷を複数のサーバー・マシンに分散できます。Productionサンプル・アプリケーションでは、ファクトリ・ベース・ルーティングを次のように使用します。
Registrarオブジェクトへのリクエストは、学生IDに基づいてルーティングされます。IDが100001 - 100005の学生からのリクエストは、Productionマシン1にルーティングされます。IDが100006 - 100010の学生からのリクエストは、Productionマシン2にルーティングされます。 RegistrarオブジェクトからTellerオブジェクトへのリクエストは、口座番号に基づいてルーティングされます。200010から200014までの口座番号への支払いリクエストは、Productionマシン1にルーティングされます。200015から200019までの口座番号への支払いリクエストは、Productionマシン2にルーティングされます。ファクトリ・ベース・ルーティングの設定の詳細は、『CORBAサーバー・アプリケーションの作成』を参照してください。
ここでは、CORBAアプリケーションのスケーリングに必要な開発プロセスについて説明します。次の手順は、「Basicサンプル・アプリケーション」で概説した開発手順の追加手順です。
| 注意: | この項に記載されている手順はすでに完了しており、Productionサンプル・アプリケーションに組み込まれています。 |
開発プロセスでは、ファクトリ・ベース・ルーティングをサポートするために、Object Management Group (OMG)インタフェース定義言語(IDL)の次のオペレーションの定義を変更します。
ファクトリ・ベース・ルーティングの実装の詳細は、『CORBAサーバー・アプリケーションの作成』を参照してください。
開発プロセスでは、Registrarオブジェクトの作成時にSTU_ID値を指定します。STU_ID値には、クライアント・アプリケーションからのリクエストのルーティング先となるサーバー・グループを定義します。
Productionサンプル・アプリケーションでは、クライアント・アプリケーションの場合と同じ方法で、Universityサーバー・アプリケーションでTellerオブジェクトが作成されます。そのため、Tellerオブジェクトの作成時にACT_NUM値を指定する必要があります。
開発プロセスでは、RegistrarFactoryおよびTellerFactoryオブジェクトのTP::create_object_reference()オペレーションの呼出しを変更して、ルーティング基準を指定するNVlistを組み込む必要があります。TP::create_object_reference()オペレーションのcriteriaパラメータには、ファクトリ・ベース・ルーティングで使用する名前付き値のリストを次のように指定します。
criteriaパラメータの値は、UBBCONFIGファイルのROUTINGセクションで指定したルーティング基準名、フィールド、およびフィールド型と正確に一致しなければなりません。
ファクトリでのファクトリ・ベース・ルーティングの実装の詳細は、『CORBAサーバー・アプリケーションの作成』を参照してください。
CORBAアプリケーションにおけるスケーラビリティの向上には、UBBCONFIGファイルが重要な役割を果たします。ここでは、Productionサンプル・アプリケーションのUBBCONFIGファイルを変更して次の処理を行う方法について説明します。
開発プロセスでは、次の方法でUBBCONFIGファイルを変更して、サーバー・アプリケーション・プロセスおよびサーバー・グループの複製を構成します。
UBBCONFIGファイルのGROUPSセクションに、構成するグループの名前を指定します。Productionサンプル・アプリケーションには、APP_GRP1、APP_GRP2、ORA_GRP1およびORA_GRP2の4つのサーバー・グループがあります。UBBCONFIGファイルのSERVERSセクションに、複製するサーバー・アプリケーション・プロセスに関する次の情報を入力します。GROUPパラメータ。サーバー・アプリケーション・プロセスが属するサーバー・グループの名前を指定します。複数のグループに関係するサーバー・プロセスを複製する場合は、各グループに1つずつサーバー・プロセスを指定します。SRVIDパラメータ。サーバー・マシンのユニークな管理IDを指定します。MINパラメータ。CORBAアプリケーションの起動時に開始する、サーバー・アプリケーション・プロセスのインスタンス数を指定します。開始するサーバー・アプリケーション・プロセスは最低2つ必要です。MAXパラメータ。同時に実行できるサーバー・アプリケーション・プロセスの最大数を指定します。指定可能なサーバー・アプリケーション・プロセスの数は最大5つです。 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/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"
*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
ファクトリ・ベース・ルーティングを使用できるようにするには、各インタフェースについて、UBBCONFIGファイルに次の情報を定義する必要があります。
開発プロセスでは、UBBCONFIGファイルを次のように変更します。
INTERFACESセクションには、ファクトリ・ベース・ルーティングを有効にするインタフェースの名前のリストが示されます。このセクションで、各インタフェースのルーティング値を指定します。ルーティング値は、FACTORYROUTING識別子で指定します。 次に、Productionサンプル・アプリケーションのRegistrarおよびTellerオブジェクトのFACTORYROUTING識別子の例を示します。
INTERFACES
"IDL:beasys.com/UniversityP/Registrar:1.0"
FACTORYROUTING = STU_ID
"IDL:beasys.com/BillingP/Teller:1.0"
FACTORYROUTING = ACT_NUM
ROUTINGセクションでは、ルーティング値ごとに次のデータを指定します。TYPEパラメータでは、ルーティングのタイプを指定します。Productionサンプル・アプリケーションでは、ルーティングの種類はファクトリ・ベース・ルーティングです。したがって、このパラメータは、FACTORYと定義します。FIELDパラメータは、ファクトリがルーティング値に挿入する名前を指定します。Productionサンプル・アプリケーションでは、フィールドのパラメータはstudent_idおよびaccount_numberです。FIELDTYPEパラメータは、ルーティング値のデータ型を指定します。Productionサンプル・アプリケーションでは、STU_IDおよびACT_NUMのフィールド型は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が100001 - 100005の学生のRegistrarオブジェクトはORA_GRP1でインスタンス化され、IDが100006 - 100010の学生のオブジェクトはORA_GRP2でインスタンス化されることを示しています。同様に、200010 - 200014の口座番号のTellerオブジェクトはAPP_GRP1でインスタンス化され、200015 - 200019の口座番号のオブジェクトはAPP_GRP2でインスタンス化されることを示しています。
UBBCONFIGファイルのROUTINGセクションにあるRANGES識別子で指定されたグループを識別および構成する必要があります。たとえば、Productionサンプル・アプリケーションでは、ORA_GRP1、ORA_GRP2、APP_GRP1およびAPP_GRP2の4つのグループが指定されています。これらのグループを構成し、グループが実行されるマシンを識別する必要があります。 | 注意: | GROUPSセクションのサーバー・グループの名前とROUTINGセクションで指定したグループの名前は、正しく一致している必要があります。 |
開発プロセスでは、Registrar、RegistrarFactory、Teller、およびTellerFactoryオブジェクトのアクティブ化ポリシーをprocessからmethodに変更する必要があります。CORBAオブジェクトのアクティブ化ポリシーとトランザクション・ポリシーの定義については、『CORBAサーバー・アプリケーションの作成』を参照してください。
Productionサンプル・アプリケーションをビルドするには、次の手順に従います。
| 注意: | Productionサンプル・アプリケーションをビルドまたは実行する前に、「環境設定」の手順を実行しておく必要があります。 |
Productionサンプル・アプリケーションの各ファイルは、次のディレクトリにあります。
drive:\TUXDIR\samples\corba\university\production
/usr/TUXDIR/samples/corba/university/production
また、utilsディレクトリを作業ディレクトリにコピーする必要があります。utilsディレクトリには、Universityデータベースのログ、トレースおよびアクセスを設定するファイルが格納されています。
Productionサンプル・アプリケーションを作成するには、表7-1のファイルを使用します。
Oracle Tuxedoソフトウェアのインストール時には、サンプル・アプリケーションは読取り専用に設定されています。Productionサンプル・アプリケーションのファイルを編集または作成するには、次のように作業ディレクトリにコピーしたファイル保護の属性を変更する必要があります。
prompt>attrib -r drive:\workdirectory\*.*
prompt>chmod u+rw /workdirectory/*.*
次のコマンドを使用して、Productionサンプル・アプリケーションのクライアント・アプリケーションとサーバー・アプリケーションのビルドに使用する環境変数を設定します。
次のコマンドを使用して、Productionサンプル・アプリケーションで使用するUniversityデータベースを初期化します。
prompt>nmake -f makefilep.nt initdb
prompt>make -f makefilep.mk initdb
次のコマンドを使用して、UBBCONFIGファイルをロードします。
UBBCONFIGファイルの作成プロセスでは、アプリケーション・パスワードの入力が求められます。このパスワードは、クライアント・アプリケーションへのログオンに使用されます。パスワードを入力してEnterキーを押します。その際、パスワードを再入力してパスワードの確認を求めるメッセージが表示されます。
トランザクション・ログには、CORBAアプリケーションでのトランザクション処理が記録されます。開発プロセスでは、UBBCONFIGファイルのTLOGDEVICEパラメータで指定したトランザクション・ログの場所を定義する必要があります。Productionサンプル・アプリケーションの場合、トランザクション・ログは作業ディレクトリに格納されています。
Productionサンプル・アプリケーションのトランザクション・ログを開くには、次の手順に従います。
crdl -b blocks -z directorypathcrlog -m SITE1
blocksにトランザクション・ログに割り当てるブロック数を指定し、directorypathにトランザクション・ログの場所を指定します。directorypathオプションは、UBBCONFIGファイルのTLOGDEVICEパラメータで指定した場所と一致する必要があります。Windowsでのコマンドの例を次に示します。
crdl -b 500 -z c:\mysamples\university\production\TLOG
「q」を入力して、会話型の管理インタフェースを終了します。
開発プロセスでは、buildobjclientおよびbuildobjserverコマンドを使用して、クライアント・アプリケーションとサーバー・アプリケーションをビルドします。ただし、Productionサンプル・アプリケーションの場合は、この手順は不要です。Productionサンプル・アプリケーションのディレクトリには、makefileが格納されており、これによりクライアントおよびサーバー・サンプル・アプリケーションがビルドされます。
Productionサンプル・アプリケーションのCORBA C++クライアント・アプリケーションとサーバー・アプリケーションをビルドするには、次のコマンドを使用します。
prompt>nmake -f makefilep.nt
Productionサンプル・アプリケーションを実行するには、次の手順に従います。
Productionサンプル・アプリケーションでシステムおよびサンプル・アプリケーションのサーバー・アプリケーションを起動するには、次のコマンドを入力します。
このコマンドを入力すると、次のサーバー・プロセスが開始されます。
ほかのサンプル・アプリケーションを使用するには、次のコマンドを入力して、システムおよびサンプル・アプリケーションのサーバー・プロセスを停止します。
Productionサンプル・アプリケーションのCORBA C++クライアント・アプリケーションを起動するには、次の手順に従います。
| 注意: | Productionサンプル・アプリケーションのCORBA C++クライアント・アプリケーションは型ライブラリと同じように動作します。デフォルトでは、型ライブラリは\TUXDIR\TypeLibrariesに格納されています。 |
Productionサンプル・アプリケーションをさらにスケーリングするには、次の方法に従います。
新しいサーバー・グループ、そのサーバー・グループで実行するサーバー・アプリケーション・プロセス、およびサーバー・グループを実行するサーバー・マシンを指定するには、UBBCONFIGファイルを変更する必要があります。
たとえば、Productionサンプル・アプリケーションの既存の2つのサーバー・グループにルーティングするかわりに、UBBCONFIGファイルのルーティング規則を修正すると、アプリケーションを追加されたサーバー・グループの間でさらに分割できます。ルーティング表を修正する場合は、UBBCONFIGファイルの情報と一致させる必要があります。
| 注意: | データベースを使用する既存のCORBAアプリケーションの能力を高める場合は、データベースがどのように設定されているかを考慮する必要があり、ファクトリ・ベース・ルーティングを使用している場合は、特に注意が必要です。たとえば、Productionサンプル・アプリケーションが6台のマシンに分散している場合は、UBBCONFIGファイルのルーティング表に基づいて、適切に各マシンのデータベースを設定する必要があります。 |
|