アプリケーションの実行

ドキュメントのダウンロード

サイトマップ

用語集

検索

e-docs > Tuxedo > TxRPC を使用した Tuxedo アプリケーションのプログラミング > アプリケーションの実行

TxRPC を使用した Tuxedo アプリケーションのプログラミング

アプリケーションの実行

ここでは、次の内容について説明します。

予備知識

RPC サーバを追加するための構成の変更を行う BEA Tuxedo システムの管理者は、ASCII コンフィギュレーション・ファイル (形式については UBBCONFIG(5) を参照) の作成方法と、tmloadcf(1) を用いたバイナリ・コンフィギュレーション・ファイルの読み込みについての知識を持っている必要があります。これらの作業については、『BEA Tuxedo アプリケーション実行時の管理』で説明されています。

アプリケーションの構成方法

RPC サーバの構成は、要求/応答サーバの場合と同様に行います。RPC サーバや RPC サーバのグループごとに、SERVERS ページ内にエントリが 1 つ必要です (MAX を 1 よりも大きな値にセットすると、1 つのエントリで複数の RPC サーバが設定できます)。必要に応じて RQADDR を指定すると、RPC サーバの複数のインスタンスが同一の要求キューを共有します (複数サーバ、単一キュー設定)。CONV パラメータは指定しないか、あるいは N に設定 (例: CONV=N) する必要があります。アプリケーション例のコンフィギュレーション・ファイル例を参照してください。

サーバがトランザクションの一部になる場合には、TLOGDEVICE をもつマシン上のグループに存在する必要があります。GROUPS エントリは、関連するリソース・マネージャへのアクセスに用いる TMSNAME と OPENINFO 文字列を使用して構成される必要があります。

SERVICES エントリの指定はオプションです。これを指定した場合、サービス名は前章で説明したとおり、インターフェイス名とバージョン番号に基づく必要があります。SERVICES エントリが必要になるのは、デフォルトの値とは異なる特別な負荷、優先順位、トランザクション時間を指定する場合です。また、このエントリは、AUTOTRAN 機能をオンにするためにも使用されます。この機能をオンにすると、入力要求がトランザクション・モードではない場合に、サービスに対してトランザクションが自動的に起動されるようにします。処理されるバッファの種類は CARRAY だけなので、SERVICES エントリを使用してバッファの種類 BUFTYPE を指定しないでください。また、ルーティングは RPC 要求に対してはサポートされていないので、ROUTING も指定しないでください。

アプリケーションを起動する前に、tmloadcf(1) コマンドを用いて ASCII コンフィギュレーション・ファイルをバイナリ TUXCONFIG ファイルにロードします。

tmconfig コマンドを使用すると、起動したアプリケーションに RPC サーバ用エントリを追加できることに注意してください。追加方法については、『BEA Tuxedo コマンド・リファレンス』の tmconfig、wtmconfig(1) を参照してください。

アプリケーションの起動とシャットダウン

構成を変更したときには、tmboot(1) を用いてアプリケーションを起動してください。tmshutdown(1) を用いて、アプリケーションをシャットダウンします。アプリケーション例の例を参照してください。

RPC サーバの起動とシャットダウン方法は、要求/応答サーバのものと同じです。RPC サーバの起動やシャットダウンは、全体構成の一部として行うときには -y オプション、グループの一部として行うときには -g オプション、論理マシンの一部として行うときには -l オプション、サーバ名で行うときには -s オプションを使用します。

アプリケーションの管理

管理インターフェイス内では、RPC サーバは要求/応答サーバとして表現されます。前に説明したとおり、tmconfig を使用すれば RPC サーバとサービスの動的再コンフィギュレーションが可能です。詳細については、『BEA Tuxedo コマンド・リファレンス』の tmconfig、wtmconfig(1) を参照してください。tmadmin(1) コマンドにより RPC サーバを監視できます。tmadmin printserver コマンドを用いて、RPC サーバ名および関連するランタイム情報 (たとえば、サービスやオペレーションの実行、ロード等) を出力できます。また printservice コマンドを使用して、利用可能な RPC サービス (インターフェイス) を出力できます。出力例については、アプリケーション例を参照してください。

動的サービス宣言の使用

RPC サービスは、要求/応答サービスの制御と同じ方法で動的に制御可能です。既に説明したとおり、サービス名はオペレーションの名前ではなく、インターフェイス名とバージョン番号でした。一般的に、サービス名は、-s オプションを使用して、buildserver(1) が実行されるときに指定され、サーバが -A オプションを使用して起動されるときに自動的に宣言されます。サービス (インターフェイス) 名を動的に宣言する方法としては、adv コマンドを用いて tmadmin から宣言するか、あるいはサーバ内から関数 tpadvertise(3c) を用いて宣言します。サービス (インターフェイス) 名の宣言を動的に解除する方法としては、unadv コマンドを用いて tmadmin から解除するか、サーバ内から関数 tpunadvertise(3c) を用いて解除します。サービス名は、tmadmin(1) から一時的に使用停止したり、停止解除 (再開) したりできます。サービス名の宣言解除、または使用停止を行うと、関連のあるインターフェイス内で定義されたオペレーションはすべて利用できなくなることに注意してください。