Productionサンプル・アプリケーション

このトピックには次の項が含まれます:

•	Productionサンプル・アプリケーションのしくみ

•	Productionサンプル・アプリケーションの開発プロセス

•	Productionサンプル・アプリケーションのビルド

•	Productionサンプル・アプリケーションのコンパイル

•	Productionサンプル・アプリケーションの実行

•	Productionサンプル・アプリケーションをさらにスケーリングする方法

注意:	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サンプル・アプリケーションのしくみ

Productionサンプル・アプリケーションには、Wrapperサンプル・アプリケーションと同じエンド・ユーザー向けの機能が用意されています。Productionサンプル・アプリケーションでは、Oracle TuxedoソフトウェアのCORBA機能を利用して、CORBAアプリケーションをスケーリングする方法を示します。Productionサンプル・アプリケーションでは、次の処理を行います。

•	UBBCONFIGファイルに定義されているORA_GRPおよびAPP_GRPサーバー・グループ内で、Universityサーバー・アプリケーション、Billingサーバー・アプリケーション、およびATMI Tellerアプリケーションをレプリケートします。

•	追加のサーバー・マシン(Productionマシン2)上で、ORA_GRP1およびAPP_GRP1サーバー・グループをORA_GRP2およびAPP_GRP2としてレプリケートし、データベースを分割します。

•	サーバー・アプリケーションが同時に管理できるクライアント・アプリケーションからのリクエスト数を増やすために、ステートレス・オブジェクト・モデルを実装します。

•	次のオブジェクトにユニークなオブジェクトID (OID)を割り当てて、対応するサーバー・グループでそれらのオブジェクトを同時に複数回インスタンス化できるようにします。これにより、次のオブジェクトをプロセス単位ではなく、クライアント・アプリケーション単位で利用できるようになります。

•

Registrar

•	RegistrarFactory

•

Teller

•	TellerFactory

•	ファクトリ・ベース・ルーティングを実装して、クライアント・アプリケーションからのリクエストを(一部の学生からのリクエストはあるサーバー・マシンへ、他の学生からのリクエストは別のサーバー・マシンへと)転送します。

注意:	Productionサンプル・アプリケーションは簡単に使用できるように、Oracle Tuxedoソフトウェア・キットでは、1台のマシン上で1つのデータベースを使用して実行するように構成されています。ただし、Productionサンプル・アプリケーションは、複数のマシンで複数のデータベースを使用して実行するための構成もできるように設定されています。複数のマシンおよびデータベースに構成を変更するには、UBBCONFIGファイルを変更し、データベースを分割するだけでできます。

次の項では、Productionサンプル・アプリケーションで、レプリケートされたサーバー・アプリケーション、レプリケートされたサーバー・グループ、オブジェクト状態管理およびファクトリ・ベース・ルーティングを使用して、Productionサンプル・アプリケーションをスケーリングする方法について説明します。

サーバー・アプリケーションのレプリケート

サーバー・アプリケーションをレプリケートすると、次の処理が可能になります。

•	クライアント・アプリケーションからそのサーバー・アプリケーションに着信するリクエストの負荷のバランシングを行う方法が得られます。リクエストがサーバー・グループのTuxedoドメインで受信されると、Oracle Tuxedoシステムは、グループ内で負荷が最も低いサーバー・アプリケーションにリクエストをルーティングします。

•	サーバー・マシン上で実行する任意のサーバー・アプリケーション・プロセスのコピー数を指定できます。コピー数によって、クライアント・アプリケーションからのリクエストをTuxedoドメインが並列処理できるレベルが決まります。

•	サーバー・アプリケーションの1つが処理を停止した場合でも、有効なフェイルオーバー保護機能が用意されます。

Productionサンプル・アプリケーションでは、サーバー・アプリケーションは次の方法でレプリケートされます。

•	Universityサーバー・アプリケーション、ATMI Tellerアプリケーション、およびUniversityデータベースのサーバー・アプリケーションは、ORA_GRPグループ内でレプリケートされます。

•	Billingサーバー・アプリケーションは、APP_GRPグループ内でレプリケートされます。

図7-1に、レプリケートされたORA_GRPおよびAPP_GRPグループを示します。

図7-1 Productionサンプル・アプリケーションのレプリケートされたサーバー・グループ

図7-1では、次の点に注意してください。

•	RegistrarFactory、Registrar、TellerFactory、またはTellerオブジェクトのインスタンスは、1つのサーバー・アプリケーション・プロセス内に1つしか存在できません。

•	CourseSynopsisEnumeratorオブジェクトは、1つのサーバー・アプリケーション・プロセス内に任意の数だけ存在できます。

サーバー・グループのレプリケート

サーバー・グループは、既存のCORBAアプリケーションにサーバー・マシンを追加できる、Oracle Tuxedoソフトウェアの機能です。サーバー・グループをレプリケートすると、次の処理が可能になります。

•	CORBAアプリケーションの処理にかかる負荷を複数のサーバー・マシンに分散できます。

•	ファクトリ・ベース・ルーティングを使用して、クライアント・アプリケーションからのリクエストを特定のサーバー・マシンに送信できます。

サーバー・グループの構成およびレプリケート方法は、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アクティブ化ポリシーによって、オブジェクトの振る舞いは次のように変化します。

•	オブジェクトが呼び出されると、常に適切なサーバー・グループでTuxedoドメインによってインスタンス化されます。

•	呼出しが完了すると、オブジェクトはTuxedoドメインによって非アクティブ化されます。

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サーバー・アプリケーションの作成』を参照してください

Productionサンプル・アプリケーションの開発プロセス

ここでは、CORBAアプリケーションのスケーリングに必要な開発プロセスについて説明します。次の手順は、第3章「Basicサンプル・アプリケーション」で概説した開発手順の追加手順です。

注意:	この項に記載されている手順はすでに完了しており、Productionサンプル・アプリケーションに組み込まれています。

OMG IDL

開発プロセスでは、ファクトリ・ベース・ルーティングをサポートするために、Object Management Group (OMG)インタフェース定義言語(IDL)の次のオペレーションの定義を変更します。

•	学生IDを要求する、RegistrarFactoryオブジェクトのfind_registrar()オペレーション

•	口座番号を要求する、TellerFactoryオブジェクトのfind_teller()オペレーション

ファクトリ・ベース・ルーティングの実装の詳細は、『CORBAサーバー・アプリケーションの作成』を参照してください

クライアント・アプリケーション

開発プロセスでは、Registrarオブジェクトの作成時にSTU_ID値を指定します。STU_ID値には、クライアント・アプリケーションからのリクエストのルーティング先となるサーバー・グループを定義します。

Productionサンプル・アプリケーションでは、クライアント・アプリケーションの場合と同じ方法で、Universityサーバー・アプリケーションでTellerオブジェクトが作成されます。そのため、Tellerオブジェクトの作成時にACT_NUM値を指定する必要があります。

サーバー・アプリケーション

開発プロセスでは、RegistrarFactoryおよびTellerFactoryオブジェクトのTP::create_object_reference()オペレーションの呼出しを変更して、ルーティング基準を指定するNVlistを組み込む必要があります。TP::create_object_reference()オペレーションのcriteriaパラメータには、ファクトリ・ベース・ルーティングで使用する名前付き値のリストを次のように指定します。

•	Productionサンプル・アプリケーションのRegistrarFactoryオブジェクトは、criteriaの値をSTU_IDとして指定します。

•	Productionサンプル・アプリケーションのTellerFactoryオブジェクトは、criteriaの値をACT_NUMとして指定します。

criteriaパラメータの値は、UBBCONFIGファイルのROUTINGセクションで指定したルーティング基準名、フィールド、およびフィールド型と正確に一致しなければなりません。

ファクトリでのファクトリ・ベース・ルーティングの実装の詳細は、『CORBAサーバー・アプリケーションの作成』を参照してください

UBBCONFIGファイル

CORBAアプリケーションにおけるスケーラビリティの向上には、UBBCONFIGファイルが重要な役割を果たします。ここでは、Productionサンプル・アプリケーションのUBBCONFIGファイルを変更して次の処理を行う方法について説明します。

•	サーバー・アプリケーション・プロセスおよびサーバー・グループのレプリケート

•	ファクトリ・ベース・ルーティングの実装

サーバー・アプリケーション・プロセスおよびサーバー・グループのレプリケート

開発プロセスでは、次の方法でUBBCONFIGファイルを変更して、サーバー・アプリケーション・プロセスおよびサーバー・グループのレプリケートを構成します。

1.	UBBCONFIGファイルのGROUPSセクションに、構成するグループの名前を指定します。Productionサンプル・アプリケーションには、APP_GRP1、APP_GRP2、ORA_GRP1およびORA_GRP2の4つのサーバー・グループがあります。

2.	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ファイルを次のように変更します。

1.	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

2.	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でインスタンス化されることを示しています。

3.	UBBCONFIGファイルのROUTINGセクションでRANGES識別子によって指定されたグループを、識別して構成する必要があります。たとえば、Productionサンプル・アプリケーションでは、ORA_GRP1、ORA_GRP2、APP_GRP1およびAPP_GRP2の4つのグループが指定されています。これらのグループを構成し、グループが実行されるマシンを識別する必要があります。

注意:	GROUPSセクションのサーバー・グループの名前とROUTINGセクションで指定したグループの名前は、厳密に一致している必要があります。

ICFファイル

開発プロセスでは、Registrar、RegistrarFactory、Teller、およびTellerFactoryオブジェクトのアクティブ化ポリシーをprocessからmethodに変更する必要があります。CORBAオブジェクトのアクティブ化ポリシーとトランザクション・ポリシーの定義については、『CORBAサーバー・アプリケーションの作成』を参照してください。

Productionサンプル・アプリケーションのビルド

Productionサンプル・アプリケーションをビルドするには、次の手順に従います。

1.	Productionサンプル・アプリケーションのファイルを作業ディレクトリにコピーします。

2.	Productionサンプル・アプリケーションのファイルの保護を変更します。

3.	環境変数を設定します。

4.	Universityデータベースを初期化します。

5.	UBBCONFIGファイルをロードします。

6.	トランザクション・ログを作成します。

7.	クライアントおよびサーバー・サンプル・アプリケーションをビルドします。

次の項では、前述の各手順について説明します。

注意:	Productionサンプル・アプリケーションをビルドまたは実行する前に、第2章「環境設定」の手順を実行しておく必要があります。

Productionサンプル・アプリケーションのファイルを作業ディレクトリにコピーする

Productionサンプル・アプリケーションの各ファイルは、次のディレクトリにあります。

Windows

drive:\TUXDIR\samples\corba\university\production

UNIX

/usr/TUXDIR/samples/corba/university/production

また、utilsディレクトリを作業ディレクトリにコピーする必要があります。utilsディレクトリには、Universityデータベースのログ、トレースおよびアクセスを設定するファイルが格納されています。

Productionサンプル・アプリケーションを作成するには、表7-1のファイルを使用します。

 

表7-1 Productionサンプル・アプリケーションに含まれるファイル

ファイル	説明
billp.idl	TellerおよびTellerFactoryインタフェースを宣言するOMG IDL。
univp.idl	CourseSynopsisEnumerator、Registrar、およびRegistrarFactoryインタフェースを宣言するOMG IDL。
billps.cpp	Productionサンプル・アプリケーションのBillingサーバー・アプリケーション用C++ソース・コード。
univps.cpp	Productionサンプル・アプリケーションのUniversityサーバー・アプリケーション用C++ソース・コード。
billp__i.h billp_i.cpp	TellerおよびTellerFactoryインタフェースのメソッド実装用C++ソース・コード。
univp_i.h univp_i.cpp	CourseSynopsisEnumerator、Registrar、およびRegistrarFactoryインタフェースのメソッド実装用C++ソース・コード。
univpc.cpp	Productionサンプル・アプリケーションのCORBA C++クライアント・アプリケーション用C++ソース・コード。
univp_utils.h univp_utils.cpp	CORBA C++クライアント・アプリケーションのデータベース・アクセス関数を定義するファイル。
univp.icf	Productionサンプル・アプリケーションのUniversityサーバー・アプリケーション用実装構成ファイル(ICF)。
billp.icf	Productionサンプル・アプリケーションのBillingサーバー・アプリケーション用ICFファイル。
tellw_flds、tellw_u.c、tellw_c.h、tellws.ec	ATMIアプリケーションTellerのファイル。
setenvp.sh	Productionサンプル・アプリケーションのビルドおよび実行に必要な環境変数を設定するUNIXスクリプト。
setenvp.cmd	Productionサンプル・アプリケーションのビルドおよび実行に必要な環境変数を設定するMS-DOSコマンド。
ubb_p.mk	UNIXオペレーティング・システム用のUBBCONFIGファイル。
ubb_p.nt	Windowsオペレーティング・システム用のUBBCONFIGファイル。
makefilep.mk	UNIXオペレーティング・システムでのProductionサンプル・アプリケーション用のmakefile。
makefilep.nt	Windowsオペレーティング・システムでのProductionサンプル・アプリケーション用のmakefile。
log.cpp、log.h、log_client.cpp、log_server.cpp	サンプル・アプリケーションにログ機能とトレース機能を提供するクライアント・アプリケーションとサーバー・アプリケーションのファイル。これらのファイルは、\utilsディレクトリにあります。
oradbconn.cppおよびoranoconn.cpp	Oracle SQLデータベース・インスタンスへのアクセスを提供するファイル。これらのファイルは、\utilsディレクトリにあります。
samplesdb.cppおよびsamplesdb.h	サンプル・アプリケーションでのデータベース例外に出力関数を提供するファイル。これらのファイルは、\utilsディレクトリにあります。
unique_id.cpp、unique_id.h	サンプル・アプリケーションのC++ Unique IDクラスのルーチン。これらのファイルは、\utilsディレクトリにあります。
samplesdbsql.hおよびsamplesdbsql.pc	SQLデータベースへのアクセスを実装するC++クラスのメソッド。これらのファイルは、\utilsディレクトリにあります。
university.sql	Universityデータベース用のSQL。このファイルは、\utilsディレクトリにあります。

Productionサンプル・アプリケーションのファイル保護の属性を変更する

Oracle Tuxedoソフトウェアのインストール時には、サンプル・アプリケーションは読取り専用に設定されています。Productionサンプル・アプリケーションのファイルを編集または作成するには、次のように作業ディレクトリにコピーしたファイル保護の属性を変更する必要があります。

Windows

prompt>attrib -r drive:\workdirectory\*.*

UNIX

prompt>chmod u+rw /workdirectory/*.*

環境変数を設定する

次のコマンドを使用して、Productionサンプル・アプリケーションのクライアント・アプリケーションとサーバー・アプリケーションのビルドに使用する環境変数を設定します。

Windows

prompt>setenvp

UNIX

prompt>/bin/ksh

prompt>. ./setenvp.sh

Universityデータベースを初期化する

次のコマンドを使用して、Productionサンプル・アプリケーションで使用するUniversityデータベースを初期化します。

Windows

prompt>nmake -f makefilep.nt initdb

UNIX

prompt>make -f makefilep.mk initdb

UBBCONFIGファイルをロードする

次のコマンドを使用して、UBBCONFIGファイルをロードします。

Windows

prompt>tmloadcf -y ubb_p.nt

UNIX

prompt>tmloadcf -y ubb_p.mk

UBBCONFIGファイルの作成プロセスでは、アプリケーション・パスワードの入力が求められます。このパスワードは、クライアント・アプリケーションへのログオンに使用されます。パスワードを入力してEnterキーを押します。その際、パスワードを再入力してパスワードの確認を求めるメッセージが表示されます。

トランザクション・ログを作成する

トランザクション・ログには、CORBAアプリケーションでのトランザクション処理が記録されます。開発プロセスでは、UBBCONFIGファイルのTLOGDEVICEパラメータで指定したトランザクション・ログの場所を定義する必要があります。Productionサンプル・アプリケーションの場合、トランザクション・ログは作業ディレクトリに格納されています。

Productionサンプル・アプリケーションのトランザクション・ログを開くには、次の手順に従います。

1.	次のコマンドを入力して、会話型の管理インタフェースを起動します。

tmadmin

2.	次のコマンドを入力して、トランザクション・ログを作成します。

crdl -b blocks -z directorypath
crlog -m SITE1

説明

blocksにトランザクション・ログに割り当てるブロック数を指定し、directorypathにトランザクション・ログの場所を指定します。directorypathオプションは、UBBCONFIGファイルのTLOGDEVICEパラメータで指定した場所と一致する必要があります。Windowsでのコマンドの例を次に示します。

crdl -b 500 -z c:\mysamples\university\production\TLOG

3.	「q」を入力して、会話型の管理インタフェースを終了します。

Productionサンプル・アプリケーションのコンパイル

開発プロセスでは、buildobjclientおよびbuildobjserverコマンドを使用して、クライアント・アプリケーションとサーバー・アプリケーションをビルドします。ただし、Productionサンプル・アプリケーションの場合は、この手順は不要です。Productionサンプル・アプリケーションのディレクトリには、makefileが格納されており、これによりクライアントおよびサーバー・サンプル・アプリケーションがビルドされます。

Productionサンプル・アプリケーションのCORBA C++クライアント・アプリケーションとサーバー・アプリケーションをビルドするには、次のコマンドを使用します。

Windows

prompt>nmake -f makefilep.nt

UNIX

Productionサンプル・アプリケーションの実行

Productionサンプル・アプリケーションを実行するには、次の手順に従います。

1.	サーバー・アプリケーションを起動します。

2.	1つまたは複数のクライアント・アプリケーションを起動します。

次の項では、前述の各手順の詳細を説明します。

サーバー・アプリケーションの起動

Productionサンプル・アプリケーションでシステムおよびサンプル・アプリケーションのサーバー・アプリケーションを起動するには、次のコマンドを入力します。

prompt>tmboot -y

このコマンドを入力すると、次のサーバー・プロセスが開始されます。

•

TMSYSEVT

Oracle TuxedoシステムのEventBroker。

•

TMFFNAME

NameManagerサービスやFactoryFinderサービスなどのトランザクション管理サービス。

•

TMIFSRVR

インタフェース・リポジトリ・サーバー・プロセス。

Universityサーバー・アプリケーションの4つのプロセス。

•	tellp_server

ATMIアプリケーションTellerの4つのプロセス。

•	billp_server

Billingサーバー・アプリケーションの4つのプロセス。

•

ISL

IIOPリスナー/ハンドラ・プロセス。

ほかのサンプル・アプリケーションを使用するには、次のコマンドを入力して、システムおよびサンプル・アプリケーションのサーバー・プロセスを停止します。

prompt>tmshutdown

CORBA C++クライアント・アプリケーションの起動

Productionサンプル・アプリケーションのCORBA C++クライアント・アプリケーションを起動するには、次の手順に従います。

1.	MS-DOSプロンプトで次のコマンドを入力します。

prompt>univp_client

2.	画面に「Enter student id:」と表示されたら、100001 - 100010の任意の数値を入力します。

3.	[Enter]を押します。

4.	画面に「Enter domain password:」と表示されたら、UBBCONFIGファイルをロードしたときに定義したパスワードを入力します。

5.	[Enter]を押します。

注意:	Productionサンプル・アプリケーションのCORBA C++クライアント・アプリケーションは型ライブラリと同じように動作します。デフォルトでは、型ライブラリは\TUXDIR\TypeLibrariesに格納されています。

Productionサンプル・アプリケーションをさらにスケーリングする方法

Productionサンプル・アプリケーションをさらにスケーリングするには、次の方法に従います。

•	Productionサンプル・アプリケーションのサーバー・グループを複数のマシンにレプリケートします。

新しいサーバー・グループ、そのサーバー・グループで実行するサーバー・アプリケーション・プロセス、およびサーバー・グループを実行するサーバー・マシンを指定するには、UBBCONFIGファイルを変更する必要があります。

•	ファクトリ・ベース・ルーティングの表を修正します。

たとえば、Productionサンプル・アプリケーションの既存の2つのサーバー・グループにルーティングするかわりに、UBBCONFIGファイルのルーティング規則を修正すると、アプリケーションを追加されたサーバー・グループの間でさらに分割できます。ルーティング表を修正する場合は、UBBCONFIGファイルの情報と一致させる必要があります。

注意:	データベースを使用する既存のCORBAアプリケーションの能力を高める場合は、データベースがどのように設定されているかを考慮する必要があり、ファクトリ・ベース・ルーティングを使用している場合は、特に注意が必要です。たとえば、Productionサンプル・アプリケーションが6台のマシンに分散している場合は、UBBCONFIGファイルのルーティング表に基づいて、適切に各マシンのデータベースを設定する必要があります。