bea ホーム | 製品 | dev2dev | support | askBEA |
|
e-docs > Tuxedo > Tuxedo CORBA University サンプル・アプリケーション > Production サンプル・アプリケーション |
Tuxedo CORBA University サンプル・アプリケーション |
Production サンプル・アプリケーション
ここでは、以下の内容について説明します。
注記 Production サンプル・アプリケーションのクライアント・アプリケーションは、Wrapper サンプル・アプリケーションのクライアント・アプリケーションと同じ方法で動作します。
トラブルシューティング情報については、¥production ディレクトリにある Readme.txt を参照してください。また、Production サンプル・アプリケーションの使用方法に関する最新の情報も参照してください。
Production サンプル・アプリケーションのしくみ
Production サンプル・アプリケーションには、Wrapper サンプル・アプリケーションと同じエンド・ユーザ向けの機能が用意されています。Production サンプル・アプリケーションでは、BEA Tuxedo ソフトウェアの CORBA 機能を利用して、CORBA アプリケーションをスケーリングする方法を示します。Production サンプル・アプリケーションでは、以下の処理を行います。
注記 Production サンプル・アプリケーションの使用を簡単にするために、BEA Tuxedo ソフトウェア・キットでは、1 台のマシン上で 1 つのデータベースを使用して実行できるようにコンフィギュレーションされています。ただし、Production サンプル・アプリケーションでは、複数のマシンで複数のデータベースを使用して実行できるようにコンフィギュレーションされています。複数のマシンおよびデータベースへのコンフィギュレーションを変更する場合、UBBCONFIG ファイルを変更し、データベースを分割するだけで変更できます。
以下の節では、Production サンプル・アプリケーションで、複製されたサーバ・アプリケーション、複製されたサーバ・グループ、オブジェクト状態管理およびファクトリ・ベース・ルーティングを使用して、Production サンプル・アプリケーションをスケーリングする方法について説明します。
サーバ・アプリケーションの複製
サーバ・アプリケーションを複製すると、以下の処理が可能になります。
Production サンプル・アプリケーションでは、サーバ・アプリケーションは次の方法で複製されます。
図7-1 では、複製された ORA_GRP および APP_GRP サーバ・グループを示しています。
図 7-1 Production サンプル・アプリケーションの複製されたサーバ・グループ
サーバ・グループの複製
サーバ・グループは、既存の CORBA アプリケーションにサーバ・マシンを追加できる、BEA Tuxedo ソフトウェアの機能です。サーバ・グループを複製すると、次の処理が可能になります。
サーバ・グループのコンフィギュレーションおよび複製方法は、UBBCONFIG ファイルで指定します。
図7-2 では、2 番目のサーバ・マシンで複製された Production サンプル・アプリケーションのサーバ・グループを示しています。Production サンプル・アプリケーションの UBBCONFIG ファイルでは、複製されたサーバ・グループは、ORA_GRP2 および APP_GRP2 として定義されています。
図 7-2 サーバ・マシン間でのサーバ・グループの複製
図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 の生成についての詳細は、『BEA Tuxedo CORBA サーバ・アプリケーションの開発方法』を参照してください。
ファクトリ・ベース・ルーティングの使用方法
ファクトリ・ベース・ルーティングは、クライアント・アプリケーションからの要求を特定のサーバ・グループに送信可能にする CORBA の機能です。ファクトリ・ベース・ルーティングを使用すると、CORBA アプリケーションの処理にかかる負荷を複数のサーバ・マシンに分散できます。Production サンプル・アプリケーションでは、ファクトリ・ベース・ルーティングを次のように使用します。
ファクトリ・ベース・ルーティングの設定についての詳細は、『BEA Tuxedo CORBA サーバ・アプリケーションの開発方法』を参照してください。
Production サンプル・アプリケーションの開発プロセス
ここでは、CORBA アプリケーションのスケーリングに必要な開発プロセスについて説明します。以下の手順は、Basic サンプル・アプリケーションで概説した開発手順の追加手順です。
注記 この節に記載されている手順はすでに完了しており、Production サンプル・アプリケーションに組み込まれています。
OMG IDL
開発プロセスでは、ファクトリ・ベース・ルーティングをサポートするために、Object Management Group (OMG) インターフェイス定義言語 (IDL) の次のオペレーションの定義を変更します。
ファクトリ・ベース・ルーティングのインプリメントについての詳細は、『BEA Tuxedo 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 セクションで指定したルーティング基準名、フィールド、およびフィールド型と正確に一致しなければなりません。
ファクトリでのファクトリ・ベース・ルーティングのインプリメントについての詳細は、『BEA Tuxedo CORBA サーバ・アプリケーションの開発方法』を参照してください。
UBBCONFIG ファイル
CORBA アプリケーションにおけるスケーラビリティの向上には、UBBCONFIG ファイルが重要な役割を果たします。ここでは、Production サンプル・アプリケーションの UBBCONFIG ファイルを変更して次の処理を行う方法について説明します。
サーバ・アプリケーション・プロセスおよびサーバ・グループの複製
開発プロセスでは、以下の方法で UBBCONFIG ファイルを変更して、サーバ・アプリケーション・プロセスおよびサーバ・グループの複製をコンフィギュレーションします。
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
# デフォルトでは、各サーバのインスタンスを 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
ファクトリ・ベース・ルーティングのインプリメント
ファクトリ・ベース・ルーティングを使用できるようにするには、各インターフェイスについて、UBBCONFIG ファイルに次の情報を定義する必要があります。
開発プロセスでは、UBBCONFIG ファイルを以下のように変更します。
*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 でインスタンス化されることを示しています。
注記 GROUPS セクションのサーバ・グループの名前と ROUTING セクションで指定したグループの名前は、正しく一致している必要があります。
ICF ファイル
開発プロセスでは、Registrar、RegistrarFactory、Teller、および TellerFactory オブジェクトの活性化方針を process から method に変更する必要があります。CORBA オブジェクトの活性化方針およびトランザクション方針の定義についての詳細は、『BEA Tuxedo CORBA サーバ・アプリケーションの開発方法』を参照してください。
Production サンプル・アプリケーションのビルド
Production サンプル・アプリケーションをビルドするには、次の手順に従います。
以降の節では、上記の各手順について説明します。
注記 Production サンプル・アプリケーションをビルドまたは実行する前に、環境設定の手順を実行しておく必要があります。
Production サンプル・アプリケーションのファイルを作業ディレクトリにコピーする
Production サンプル・アプリケーションの各ファイルは、次のディレクトリにあります。
Windows 2000
drive:¥TUXDIR¥samples¥corba¥university¥production
UNIX
/usr/TUXDIR/samples/corba/university/production
また、utils ディレクトリも作業ディレクトリにコピーする必要があります。utils ディレクトリには、ログ、トレース、および University データベースへのアクセスを設定するファイルが格納されています。
Production サンプル・アプリケーションを作成するには、表 7-1 のファイルを使用します。
Production サンプル・アプリケーションのファイル保護の属性を変更する BEA Tuxedo ソフトウェアのインストール時には、サンプル・アプリケーションは読み取り専用に設定されています。Production サンプル・アプリケーションのファイルを編集または作成するには、次のように作業ディレクトリにコピーしたファイル保護の属性を変更する必要があります。 Windows 2000 prompt>attrib -r drive:¥workdirectory¥*.* UNIX prompt>chmod u+rw /workdirectory/*.* 環境変数を設定する 次のコマンドを使用して、Production サンプル・アプリケーションのクライアント・アプリケーションとサーバ・アプリケーションのビルドに使用する環境変数を設定します。 Windows 2000 prompt>setenvp UNIX prompt>/bin/ksh prompt>. ./setenvp.sh University データベースを初期化する 次のコマンドを使用して、Production サンプル・アプリケーションで使用する University データベースを初期化します。 Windows 2000 prompt>nmake -f makefilep.nt initdb UNIX prompt>make -f makefilep.mk initdb UBBCONFIG ファイルをロードする 次のコマンドを使用して、UBBCONFIG ファイルをロードします。 Windows 2000 prompt>tmloadcf -y ubb_p.nt UNIX prompt>tmloadcf -y ubb_p.mk UBBCONFIG ファイルの作成プロセスでは、アプリケーション・パスワードの入力が求められます。このパスワードは、クライアント・アプリケーションへのログオンに使用されます。パスワードを入力して Enter キーを押します。その際、パスワードを再入力してパスワードの確認を求めるメッセージが表示されます。 トランザクション・ログを作成する トランザクション・ログには、CORBA アプリケーションでのトランザクション処理が記録されます。開発プロセスでは、UBBCONFIG ファイルの TLOGDEVICE パラメータでトランザクション・ログの場所を定義する必要があります。Production サンプル・アプリケーションの場合、トランザクション・ログは作業ディレクトリに格納されています。 Production サンプル・アプリケーションのトランザクション・ログを開くには、次の手順に従います。
Production サンプル・アプリケーションのコンパイル
開発プロセスでは、buildobjclient および buildobjserver コマンドを使用して、クライアント・アプリケーションとサーバ・アプリケーションをビルドします。ただし、Production サンプル・アプリケーションの場合は、この手順は不要です。Production サンプル・アプリケーションのディレクトリには、makefile が格納されています。この makefile により、クライアントとサーバ・サンプル・アプリケーションがビルドされます。
Production サンプル・アプリケーションの CORBA C++ クライアント・アプリケーションとサーバ・アプリケーションをビルドするには、次のコマンドを使用します。
Windows 2000
prompt>nmake -f makefilep.nt
UNIX
prompt>make -f makefilep.mk
CORBA Java クライアント・アプリケーションをビルドするには、次のコマンドを使用します。
Windows 2000
prompt>nmake -f makefilep.nt javaclient
UNIX
prompt>make -f makefilep.mk javaclient
ActiveX クライアント・アプリケーションの起動については、ActiveX クライアント・アプリケーションの起動を参照してください。
buildobjclient および buildobjserver コマンドの詳細については、『BEA Tuxedo コマンド・リファレンス』を参照してください。
Production サンプル・アプリケーションの実行
Production サンプル・アプリケーションを実行するには、次の手順に従います。
以降の節では、上記の各手順の詳細について説明します。
サーバ・アプリケーションの起動
Production サンプル・アプリケーションでシステムおよびサンプル・アプリケーションのサーバ・アプリケーションを起動するには、次のコマンドを入力します。
prompt>tmboot -y
このコマンドを入力すると、次のサーバ・プロセスが開始されます。
ほかのサンプル・アプリケーションを使用するには、次のコマンドを入力して、システムおよびサンプル・アプリケーションのサーバ・プロセスを停止します。
prompt>tmshutdown
CORBA C++ クライアント・アプリケーションの起動
Production サンプル・アプリケーションの CORBA C++ クライアント・アプリケーションを起動するには、次の手順に従います。
注記 Production サンプル・アプリケーションでは、Production サンプル・アプリケーションと Wrapper サンプル・アプリケーションの各 CORBA C++ クライアント・アプリケーションは同じ方法で動作します。
CORBA Java クライアント・アプリケーションの起動
Production サンプル・アプリケーションの CORBA Java クライアント・アプリケーションを実行するには、以下の手順に従います。
注記 Microsoft Windows 2000 システムの場合、ノード名はすべて大文字にする必要があります。たとえば、UBBCONFIG ファイルおよび UnivPApplet.html ファイルでノードを SERVER に指定した場合、ブラウザは http://SERVER/UnivPApplet.html に設定します。
注記 Production サンプル・アプリケーションでは、Production サンプル・アプリケーションと Wrapper サンプル・アプリケーションの各 CORBA Java クライアント・アプリケーションは同じ方法で動作します。
ActiveX クライアント・アプリケーションの起動
注記 University サンプル・アプリケーションでは、インターフェイス・リポジトリに CORBA インターフェイスの OMG IDL をロードする作業は makefile によって自動化されています。
ActiveX クライアント・アプリケーションを起動するには、Application Builder を使用して CORBA インターフェイスの ActiveX バインディングを作成する必要があります。
CORBA インターフェイスの ActiveX バインディングを作成するには、次の手順に従います。
ActiveX クライアント・アプリケーションを実行するには、以下の手順に従います。
注記 Production サンプル・アプリケーションでは、Production サンプル・アプリケーションと Wrapper サンプル・アプリケーションの各 ActiveX クライアント・アプリケーションは同じ方法で動作します。
Production サンプル・アプリケーションをさらにスケーリングする方法
Production サンプル・アプリケーションをさらにスケーリングするには、次の方法に従います。
注記 データベースを使用する既存の CORBA アプリケーションに機能を追加する場合は、データベースがどのように設定されているかを考慮する必要があります。ファクトリ・ベース・ルーティングを使用している場合は、特に注意が必要です。たとえば、Production サンプル・アプリケーションが 6 台のマシン間に分散している場合は、UBBCONFIG ファイルのルーティング・テーブルに基づいて、適切に各マシンのデータベースを設定する必要があります。