TxRPC の概要

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

• TxRPC とは

 

---

TxRPC とは

TxRPC 機能により、プログラマはリモート・プロシージャ・コール (RPC) インターフェイスを使用できます。つまり、クライアント・プロセスは、ローカル関数呼び出しを使用しているほかのプロセス内で、リモート関数 (リモート・サービス) を呼び出すことができます。アプリケーションの作成者は、オペレーション (プロシージャ) と、インターフェイス定義言語 (IDL: Interface Definition Language) を使用してこれらのオペレーションに対してパラメータとして渡されるデータ型を指定する必要があります。オペレーション群は 1 つのインターフェイス内でグループにまとめられます。IDL コンパイラを使用して、スタブと呼ばれる代替プロシージャを生成します。このスタブを使用して、そのオペレーションをリモートに実行できます。まず理解する必要のある重要な概念は、2 つの基本的なネーミングのレベルがあることです。まず、インターフェイスが名前を持ち、1 つのインターフェイス内で 1 つ以上のオペレーションに名前がつけられます。インターフェイスは、実行時に利用可能になります。つまり、インターフェイス内のすべてのオペレーションが呼び出し可能になります。1 つのインターフェイス内の各オペレーションが利用可能になるわけではありません。個別のオペレーションを利用可能にする必要がある場合は、固有のインターフェイス内でオペレーションを定義します。

次の図は、RPC がローカル・プロシージャ・コールのように見える方法を示しています。

図 1-1 RPC の通信

 

クライアント・アプリケーション・コードは、IDL ファイル内で定義されたオペレーション (関数) 群の 1 つを呼び出します。サーバ側にある実際の関数を呼び出す代わりに、クライアント・スタブが呼び出されます。データ型とオペレーションを定義する IDL 入力ファイルに基づいて、IDL コンパイラがクライアント・スタブを作成します。入力パラメータ、戻り値の型、出力パラメータは、オペレーションごとに定義されます。クライアント・スタブは入力パラメータを受け取り、それらを単一のデータ・バッファに変換し、そのデータをサーバに送って応答を待ちます。その後サーバが戻り値および出力パラメータとして返したバッファ形式のデータをアンパックします。クライアント・プロセスとサーバ・プロセス間の通信は、マシン内、マシン間のいずれでも BEA Tuxedo システムのランタイムで処理されます。

サーバ側では、ランタイムがインターフェイスのサーバ・スタブを呼び出します。サーバ・スタブも IDL コンパイラが生成します。サーバ・スタブは入力パラメータを含むデータ・バッファをアンパックします。場合によってはサーバ・スタブは、オペレーションの出力パラメータに必要な領域を割り当て、オペレーションを呼び出して復帰を待ち、戻り値と出力パラメータを 1 つのバッファ内にパックしてクライアントに応答を返します。

アプリケーションからは、単純なローカル・プロシージャ・コールが行われているように見えます。スタブとランタイムは、ローカルなアドレス空間 (プロセス) 以外のリモート・プロシージャの呼び出しを隠ぺいします。

リモート・プロシージャ・コールを使用するアプリケーションを作成する手順は、これらのコールを用いない場合のアプリケーションの作成手順とほぼ同じです。大部分の時間はクライアントとサーバ用のアプリケーション、つまり実際にアプリケーションが行う作業のコーディングに費やされるでしょう。BEA Tuxedo システムのランタイムにより、アプリケーション・プログラマは、通信やクライアント・マシンで使用しているデータ形式からサーバ・マシンで使用しているデータ形式への変換などを配慮しなくて済みます。サーバ間の通信に TxRPC を使うこともできます。

単体型アプリケーションを作成する手順以外に、クライアントとサーバ間のインターフェイスを完全に定義する手順も必要になります。前述のように、インターフェイスにはリモート・プロシージャ・コールに用いるデータ型とオペレーションの定義が含まれます。通常、インターフェイスの定義を含むファイル名には拡張子 .idl をつけます。この規則に従えば、ファイルの種類がわかります。

すべてのインターフェイスはそれぞれ固有の識別子を持つ必要があります。この汎用一意識別子 (UUID:Universal Unique Identifier) は、128 ビットで構成され、すべてのインターフェイス間でそのインターフェイスを一意に識別します。アプリケーション・プログラマは、uuidgen プログラムを実行して UUID を生成します。uuidgen プログラムに -i オプションを指定して実行すると、新たな UUID を含むインターフェイス・テンプレートが作成されます。アプリケーション例に簡単な RPC アプリケーションのコードを含む開発例を示しています。この例では、最初の手順として uuidgen コマンドの実行方法とその出力結果を示しています。uuidgen コマンドのその他のオプションについては、uuidgen(1) のマニュアル・ページを参照してください。

実行時にこの UUID を使用して、クライアント・スタブが受信側のサーバ・スタブと一致することを確認します。つまり、UUID は、BEA Tuxedo システムのランタイムが検証するためにクライアントからサーバに送られるもので、アプリケーション・プログラマに対しては透過的です。

UUID の検証以外にも、各インターフェイスはインターフェイスに関連付けられたバージョン番号をも持っています。このバージョン番号はメジャー番号とマイナー番号から構成されます。バージョン番号がインターフェイス定義の一部として指定されない場合、デフォルトで 0.0 に設定されます。そのため、同じインターフェイスに対して利用できるバージョンが複数存在する可能性があります。クライアントは、特定のバージョンのインターフェイスから作成されたスタブ内の RPC を呼び出すことにより、特定のバージョンのインターフェイスを要求します。バージョンが異なっていることは、データ型、オペレーション・パラメータ、または戻り値が変更されているか、あるいはそのインターフェイスにオペレーションが追加、削除されたことを意味します。このため、RPC を正常に実行するには、クライアントとサーバの UUID およびバージョンが一致している必要があります。アプリケーション・プログラマは、同じバージョン番号を持つインターフェイスには、同じインターフェイスまたは互換性のあるインターフェイスを提供する必要があります。

uuidgen によってテンプレート IDL が作成された後、アプリケーション・プログラムは、そのインターフェイス内のすべてのデータ型およびオペレーションを定義する必要があります。IDL 言語は、プロシージャ・ステートメントを除く C や C++ の宣言部によく似ています。typedef ステートメントでデータ型を宣言し、関数プロトタイプでオペレーションを宣言します。さらに情報を追加する場合は IDL 属性を用います。IDL 言語では、属性指定は [in] のように角かっこで囲みます。属性を使用して、実行時にポインタを NULL にできるかどうかなどのポインタの形式に関する情報や、パラメータが入力、出力、またはその両方のいずれかなどのパラメータに関係する情報を提供できます。IDL 言語および関連するコンパイラについての詳細は、インターフェイス定義言語 (IDL) の使用で説明します。

IDL ファイルのほかに、インターフェイスの追加属性を指定するために、オプションの ACF (Attribute Configuration File) も用意されています。各 RPC オペレーションの状態を返すために、状態変数をオペレーション内で定義することが最も重要です。状態変数の使用法の詳細は、RPC クライアント/サーバ・プログラムの作成で説明します。ACF ファイル内の属性は、IDL ファイル内の属性とは異なり、クライアントとサーバ間の通信には影響を与えませんが、アプリケーション・コードと、生成されたスタブとの間のインターフェイスに影響を及ぼします。

BEA Tuxedo システムのランタイム使用時には、クライアントとサーバのバインディング (接続) の管理は透過的に行われます。クライアントやサーバのアプリケーション・コードからは、クライアントとサーバのバイディングを管理するための情報は得られません。対称的に、OSF DCE ランタイム使用時には、バインディング管理のためにプログラマにかかる負担は大変なものがあります。BEA Tuxedo ランタイムは OSF DCE ランタイム関数をサポートしていません。IDL や ACF ファイル内のバインディング属性は無視します。

IDL ファイルおよびオプションの ACF ファイルは、IDL コンパイラを使って「コンパイル」されます。IDL コンパイラはまずヘッダ・ファイルを 1 つ作成します。このヘッダ・ファイルには、IDL ファイル内で定義されたオペレーションの型定義と関数プロトタイプがすべて含まれています。インターフェイス内で定義された RPC を呼び出すアプリケーション内でヘッダ・ファイルをインクルードできます。入力ファイルが file.idl と file.acf であれば、デフォルトのヘッダ・ファイルの名前は file.h になります。コンパイラはクライアントとサーバの両方のスタブ・コードを作成します (例 : file_cstub.c と file_sstub.c)。これらのスタブ・ファイルは前述したように、データのパッケージ処理と RPC の通信処理を含みます。特に指定しない限り、IDL コンパイラは C コンパイラを起動し、クライアントとサーバのスタブ・オブジェクト・ファイル (例 :file_cstub.o および file_sstub.o) を作成します。その後、スタブ・ソース・ファイルは削除されます。IDL コンパイラには、さまざまなオプションがあります。制限付きの生成、ソースおよびオブジェクト・ファイルの保持、および出力ファイル名やディレクトリの変更を指定できます。詳細については、tidl(1) のリファレンス・ページを参照してください。

インターフェイスの定義が完了した後の大部分の作業はアプリケーション・コードを記述することです。クライアント・コードでは、インターフェイス内で定義されたオペレーションを呼び出します。サーバ・コードではそのオペレーションを実装する必要があります。サーバは、RPC を呼び出すことにより、クライアントとしても動作できる事に注意してください。アプリケーションを作成する上での注意事項については、インターフェイス定義言語 (IDL) の使用でより詳細に解説します。

アプリケーション・コードが完成すると、いよいよそのコードをコンパイルして BEA Tuxedo システムのランタイムとリンクします。このプロセスを簡略化するためのプログラムが 2 つ用意されています。それは、サーバ用の buildserver とクライアント用の buildclient です。これらのプログラムを使用して任意のソース・ファイルをコンパイルし、BEA Tuxedo システムのランタイムを使用して、コンパイルされたオブジェクトとライブラリ・ファイルをリンクして実行形式のファイルを作成します。これらのプログラムでは代替のコンパイラやコンパイラ・オプションを指定することもできます。詳細については buildserver(1) と buildclient(1) のリファレンス・ページを参照してください。

サーバとクライアントを作成するプロセス全体を図1-2 と図1-3 に示します。異なるプラットフォーム上でのクライアントとサーバ・プログラムの作成については、RPC クライアント/サーバ・プログラムの構築を参照してください。

図 1-2 RPC サーバの構築方法

 

図1-2 はサーバを作成するプロセスを示します。

1. uuidgen を実行し、UUID を持つスケルトンの IDL ファイル (simp.idl) を生成します。テンプレート IDL ファイルを編集し、インターフェイス定義言語を使用してクラインアトとサーバ間のインターフェイスを定義します。

2. simp.idl およびオプションの simp.acf を使って IDL コンパイラ (tidl) を実行し、インターフェイス・ヘッダ・ファイルとサーバ・スタブ・オブジェクト・ファイルを生成します。

3. サーバのアプリケーション・コード (server.c) を記述した後、buildserver を実行し、そのコードをコンパイルしてサーバ・スタブ、BEA Tuxedo システムのランタイム、および TxRPC ランタイムとリンクし実行可能なサーバを生成します。

   図 1-3 RPC クライアントの構築方法

   
    

   上の図はクライアントを作成するプロセスを示します。

4. 手順 1 で生成された IDL ファイルを用いて、IDL コンパイラ (tidl) を実行し、インターフェイス・ヘッダ・ファイルとクライアント・スタブ・オブジェクト・ファイルを生成します。

5. クライアントのアプリケーション・コード (client.c) を記述した後、buildclient を実行し、そのコードをコンパイルしてクライアント・スタブ、BEA Tuxedo システムのランタイム、および TxRPC ランタイムとリンクし実行可能なクライアントを生成します。

アプリケーション・クライアントおよびサーバが作成されると、アプリケーションを構成および起動することができ、クライアントの実行が可能になります。詳細については、アプリケーションの実行で説明しています。