![]() ![]() ![]() ![]() ![]() ![]() ![]() |
注意: | 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
directorypath
crlog -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 ファイルのルーティング表に基づいて、適切に各マシンのデータベースを設定する必要があります。 |
![]() ![]() ![]() |