| TxRPC を使用した Oracle Tuxedo アプリケーションのプログラミング |
|
 戻る |
 次へ |
ここでは、次の内容について説明します。
Oracle Tuxedo TxRPC のプログラマは、C コンパイレーション システムと、Oracle Tuxedo ATMI でのクライアントとサーバの構築方法に知識があることを前提としています。Oracle Tuxedo ATMI でのクライアントおよびサーバの構築については、『C 言語を使用した Oracle Tuxedo アプリケーションのプログラミング』、『COBOL を使用した Oracle Tuxedo アプリケーションのプログラミング』、および『FML を使用した Oracle Tuxedo アプリケーションのプログラミング』を参照してください。ワークステーション クライアントの構築については、『Oracle Tuxedo Workstation コンポーネント』を参照してください。
RPC サーバは、ATMI 要求/応答サーバの場合とほぼ同じように構築されコンフィグレーションされます。実際、RPC と要求/応答サーバのサービス ネームスペースは同一です。しかし、RPC サービス用に宣言される名前は異なります。要求/応答サーバ用では、サービス名はプロシージャにマップされます。RPC サーバでは、サービス名は IDL インタフェース名にマップされます。宣言された RPC サービスは <interface>v<major>_<minor> となります。ここで、<interface> はインタフェース名、<major> と <minor> はそれぞれメジャー バージョン番号とマイナー バージョン番号です。バージョン番号は、インタフェース定義で指定されたものか、あるいはデフォルトでの設定値 0.0 のいずれかをとります。サービス名の長さ制限は 15 文字です。このため、インタフェース名の長さは、13 からメジャーとマイナーのバージョン番号の桁数を引いたものに制限されます。これは、Oracle Tuxedo システムで名前が処理される方法によるもので、メジャー バージョン番号とマイナー バージョン番号が正確に一致する必要があることを意味しています。宣言されるのはインタフェースであって、個別のオペレーションではないことに注意してください (DCE/RPC と同様)。インタフェース内の適切なオペレーションが呼び出されるようにサーバ スタブが自動的に調整を行います。
RPC サーバは、buildserver(1) コマンドを使って構築されます。コンパイル時には、-s オプションを用いてサービス (インタフェース) 名を指定することをお勧めします。その後、-A オプションを用いてサーバを起動すると、指定したサービスを自動的に宣言することができます。この方法は、「アプリケーション例」のアプリケーション例で用いられています。
buildserver(1) コマンドは、Oracle Tuxedo ライブラリを自動的にリンクしますが、RPC ランタイムは明示的にリンクする必要があります。このリンクは、buildserver 行のアプリケーション ファイルの後に、-f -ltrpc オプションを指定することで行われます。通常は、tidl(1) コマンドの出力はサーバ スタブ オブジェクト ファイルです。このファイルは buildserver コマンドに直接受け渡されます。サーバ スタブと、オペレーションを実装するアプリケーション ソース、オブジェクト、ライブラリ ファイルは、ランタイム ライブラリよりも前に、-f オプションを使用して指定する必要があることに注意してください。「アプリケーション例」の makefile 例 rpcsimp.mk を参照してください。
ネイティブ RPC クライアントは、buildclient(1) コマンドを使って構築されます。このコマンドは、Oracle Tuxedo ライブラリを自動的にリンクします。RPC ランタイムは明示的にリンクする必要があります。このリンクは、buildclient コマンドラインのアプリケーション ファイルの後に、-f -ltrpc オプションを指定することで行われます。通常は、tidl(1) コマンドの出力はクライアント スタブ オブジェクト ファイルです。このファイルは buildclient コマンドに直接受け渡されます。クライアント スタブとリモート プロシージャ コールを実行するアプリケーション ソース、オブジェクト、ライブラリ ファイルは、ランタイム ライブラリよりも前に、-f オプションを使用して指定する必要があることに注意してください。「アプリケーション例」の makefile 例 rpcsimp.mk を参照してください。
UNIX ワークステーション クライアントを構築するには、ネイティブ ライブラリの代わりに ワークステーション ライブラリをリンクするように単純に -w オプションを buildclient(1) コマンドラインに追加します。
Windows 用のクライアント スタブのコンパイルは -D_TM_WIN 定義がコンパイル オプションとして必要になります。このオプションにより、該当する TxRPC 用の関数プロトタイプと Oracle Tuxedo システムのランタイム関数が使用されます。DLL のテキスト セグメントとデータ セグメントが、DLL を呼び出しているコードとは異なるように、特別にコンパイルする必要があります。これは、クライアント スタブ ソースでは同じになります。ヘッダ ファイルやスタブの作成は C プリプロセッサの定義を用いて自動的に行われ、宣言が容易に変更できるよう配慮されています。_TMF ("far" 用) の定義は、ヘッダ ファイル内のすべてのポインタ定義の前で行われ、_TM_WIN が定義されていれば、_TMF は自動的に "_far" 型として定義されます。
ほとんどの場合、標準ライブラリを使えば buildclient(1) コマンドでクライアントをリンクできます。wtrpc.lib ライブラリを使用します。
付録 A に示した例は、クライアント スタブを使って動的リンク ライブラリ (DLL) を作成する方法を示したものです。この手法は、DLL (アプリケーション コードが静的にリンクされることが無い) を使用する必要のあるビジュアル アプリケーション ビルダを使用する場合には一般的です。Windows 関数は、_pascal 呼び出し規約に従って宣言されることが従来の方法でした。ヘッダ ファイルやスタブの作成は C プリプロセッサの定義を用いて自動的に行われ、宣言が容易に変更できるよう配慮されています。_TMX ("eXport" 用) は、宣言されたすべての関数の前に置かれます。デフォルトでは、この宣言は何も定義しません。DLL に含まれるスタブをコンパイルするときは、_TMX を _far _pascal として定義する必要があります。また、DLL にインクルードされるファイルは、ラージ メモリ モデルを用いてコンパイルする必要があります。_pascal を使用すると、関数名は自動的にライブラリ内で大文字に変換されます。このため、-port case オプションをオン状態にしておくと、2 つの名前の違いは大文字/小文字の区別だけなのかを調べる追加の検証を行え便利です。
Windows DLL を構築する例が、「アプリケーション例」に示してあります。
|
注意 : TxRPC クライアントがwindows.h をインクルードしている場合、uuid_t の定義が重複するためにコンパイル エラーが起きることがあります。windows.h は、すでにインクルードされているのでそれをインクルードしないようにするか、アプリケーションの別のファイルでそれをインクルードする必要があります。 |
クライアントとサーバは、C と C++ のいずれを用いても構築できます。ヘッダ ファイルと作成されたスタブ ソース ファイルは、すべてのスタブ サポート関数と作成したオペレーションが C++ と C 間で完全に相互運用できる方法で定義されています。これらの関数やオペレーションは C リンケージを使用して、つまり extern "C" として宣言されているので、名前のアングリングはオフになります。
スタブ オブジェクト ファイルを C++ を用いて作成するには、tidl(1) の -cc_cmd オプションに CC -c を指定します。CC コマンドを用いると、クライアントとサーバのプログラムのコンパイルとリンクができます。そのためには、buildclient(1) と buildserver(1) を実行する前に、CC 環境変数を設定してエクスポートします。次に例を示します。
tidl -cc_cmd "CC -c" -keep all t.idl CC=CC buildserver -o server -s tv1_0 -f "-I. t_sstub.o server.c -ltrpc"
Windows 環境では C++ によるコンパイルは通常、異なるコマンド名を用いるのではなく、コンパイル コマンドラインのフラグまたはコンフィグレーション オプションで行えます。C++ でコンパイルするための適切なオプションを使用してください。
Oracle Tuxedo の TxRPC コンパイラは OSF/DCE と同一の IDL インタフェースを使用しますが、生成されたスタブでは同一のプロトコルは使用されません。したがって、Oracle Tuxedo の TxRPC スタブは、DCE IDL コンパイラが生成するスタブとは直接通信できません。
ただし、DCE/RPC と Oracle Tuxedo TxRPC 間では以下の相互動作を行うことができます。
DCE と Oracle Tuxedo TxRPC からのクライアント サイド スタブは、両方とも同一プログラム (クライアントとサーバのいずれでも) から呼び出すことができます。
Oracle Tuxedo サーバ スタブは、Oracle Tuxedo TxRPC クライアント スタブと同様に DCE クライアント スタブを呼び出すアプリケーション コードを呼び出せます。
DCE サーバ (マネージャ) は、Oracle Tuxedo TxRPC クライアント スタブを呼び出すアプリケーション コードを呼び出すことができます。
以下のセクションでは、Oracle Tuxedo TxRPC と OSF/DCE との間で行うことのできる相互作用について説明します。ただし各セクションでは、要求の発行元に対して要求者という用語を使用します。「クライアント」という用語を使用しないのは、他のサービスの要求を行う DCE または Oracle Tuxedo サービスも、実際には要求の発行元となりうるからです。「クライアント」および「サーバ」という用語は、それぞれ、IDL コンパイラ (DCE idl(1) または Oracle Tuxedo tidl(1)) によって生成されるクライアントおよびサーバ スタブを表します。これは、DCE と TxRPC 間で用語を統一するためのものです。また、「アプリケーション サービス」という用語は、リモートに呼び出されているプロシージャを実装したアプリケーション コードを表します。呼び出しているサーバ スタブが、DCE に生成されたものか Oracle Tuxedo に生成されたものかは、通常透過的です。
図 4-1 Oracle Tuxedo ゲートウェイを使用した DCE サービスに対する Oracle Tuxedo 要求者
最初の方法では、Oracle Tuxedo クライアント スタブが TxRPC を使用して Oracle Tuxedo サーバ スタブを呼び出す「ゲートウェイ」を使用します。サーバ スタブは、(アプリケーション サービスの代わりに) リンクされた DCE クライアントを持ち、この DCE クライアントが DCE RPC を使用して DCE サービスを呼び出します。この方法の長所は、クライアント プラットフォームで DCE を必要としない点です実際に、すべてのゲートウェイを実行している 1 台のマシンを除いて Oracle Tuxedo を実行するマシンのセットおよび DCE を実行するマシンのセットを切り離すことができます。この結果、Oracle Tuxedo と DCE 間でサービスを移動する機能を使用して、移行パスを提供します。この方法を実施するアプリケーション例については「DCE ゲートウェイ アプリケーション」で説明します。
このコンフィグレーションでは、要求者は通常の Oracle Tuxedo クライアントまたはサーバとして構築されます。同様に、サーバも通常の DCE サーバとして構築されます。もう一つの手順は、TxRPC サーバ スタブを使う Oracle Tuxedo サーバおよび DCE/RPC クライアント スタブを使う DCE クライアントとして機能するゲートウェイ プロセスを構築することです。
2 つの IDL コンパイラを実行し、得られたファイルをリンクするプロセスは、リンクされている DCE を使って Oracle Tuxedo サーバを構築する blds_dce(1) のコマンドの利用によって簡素化されています。
blds_dce の使用法は次のとおりです。
blds_dce [-o output_file] [-i idl_options] [-f firstfiles] [-l lastfile] \ [idl_file . . . ]
このコマンドは入力として 1 つ以上の IDL ファイルを使用するので、ゲートウェイは 1 つ以上のインタフェースを処理できます。これらのファイルごとにサーバ スタブを生成する場合は tidl を実行し、クライアント スタブを生成する場合は idl を実行します。
このコマンドは各種の DCE 環境を認識し、コンパイルとリンクに必要なコンパイル フラグと DCE ライブラリを提供します。新たな環境で開発している場合は、コマンドを変更して現在の環境に合ったオプションとライブラリの追加が必要になります。
このコマンドは、常に rpc_ss_allocate(3c) と rpc_ss_free(3c) を使用してメモリ割り当てを行う方法 (-DTMDCEGW を定義した状態) でソース ファイルをコンパイルします。詳細については、『Oracle Tuxedo C リファレンス』を参照してください。これにより Oracle Tuxedo サーバから復帰する際には必ずメモリが解放されるようになります。-DTMDCEGW を使用する場合には、Oracle Tuxedo TxRPC ヘッダ ファイルの代わりに DCE ヘッダ ファイルが組み込まれます。
buildserver(1) を用いて Oracle Tuxedo サーバを作成するには、アプリケーション ファイルを指定して (-f と -l オプションを使用します)、IDL 出力オブジェクト ファイルをコンパイルします。実行可能なサーバ名は -o オプションで指定できます。
この構成を実行する場合、まず DCE サーバがバックグラウンドで開始され、次に DCE ゲートウェイを含む Oracle Tuxedo のコンフィグレーションが起動し、要求者が実行されます。DCE ゲートウェイはシングル スレッドで実行されるので、同時に実行したいサービスの数と同数のゲートウェイ サービスをコンフィグレーションして起動する必要があることに注意してください。
このゲートウェイを構築する際に考慮すべき選択事項がいくつかあります。
まず DCE クライアントでは通常、プロセスが DCE プリンシパルとして実行します。ログイン コンテキストを取得する方法は 2 つあります。1 つの方法としては DCE に「ログイン」します。ある種の環境では、単にオペレーティング システムにログインするだけでログイン コンテキストを取得できます。多くの環境では、dce_login の実行が必要です。ローカル マシンで Oracle Tuxedo サーバを起動すると、初めに dce_login の実行が、そして次に tmboot(1) の実行が可能となり、起動したサーバはログイン コンテキストを継承することになります。tlisten(1) を使用して間接的に実行されるリモート マシンでサーバを起動する場合は、tlisten を開始する前に dce_login を実行する必要があります。これらの各事例では、セッション内で起動したすべてのサーバは同一プリンシパルによって実行されます。この方法の欠点は、資格に有効期限がある点です。
ほかの方法としては、プロセスをセットアップしそのプロセスが独自のログイン コンテキストを管理するようにします。サーバに提供される tpsvrinit(3c) 関数は、ログイン コンテキストをセットアップし、そのコンテキストの有効期限が切れる前にコンテキストのリフレッシュを行うスレッドを起動できます。セットアップと起動を行うためのコード列が $TUXDIR/lib/dceserver.c に用意されています。このコードは、-DTPSVRINIT オプションでコンパイルし、tpsvrinit() 関数を作成します (次のセクションで説明するような DCE サーバ用の main() としても使用できます)。このコードの詳細は、「DCE ゲートウェイ アプリケーション」で説明しています。
Oracle Tuxedo TxRPC はバインド ハンドルをサポートしていません。要求者のクライアント スタブからゲートウェイ内のサーバ スタブに RPC を送信する場合、Oracle Tuxedo システムは名前解決のすべてとサーバの選択を処理し、利用可能なサーバ間のロード バランシングを行います。ただし、ゲートウェイから DCE サーバへの送信時には DCE バインドを使用できます。DCE バインドを行った場合は、同じディレクトリ内で IDL ファイルを 2 つ使用するか、あるいは要求者および、ゲートウェイとサーバを構築するために 2 つのディレクトリを使用することをお勧めします。2 つの異なるファイル名を用いる前者の方法が例で示されていますが、この場合の IDL ファイルは第 2 の名前にリンクされます。最初の IDL ファイルでは、バインド ハンドルまたはバイディング属性は指定されていません。第 2 の IDL ファイルはゲートウェイと DCE サーバの生成に使用されますが、このファイルには、バインド ハンドルがオペレーションの第 1 パラメータとして挿入されるよう [explicit_handle] を指定する関連付けられた ACF ファイルが存在しています。ゲートウェイではハンドルがサポートされていないので、Oracle Tuxedo サーバ スタブから NULL ハンドルが生成されます。つまり、ゲートウェイの Oracle Tuxedo サーバ スタブと DCE クライアント スタブのどこかの場所で、有効なバインド ハンドルを生成する必要があるということです。
バインド ハンドルの生成は、マネージャ エントリ ポイント ベクトルを使用することで可能になります。デフォルトでは IDL コンパイラは、インタフェース内のオペレーションごとに関数ポインタ プロトタイプをもつ構造体を定義します。さらに、オペレーション名を元にしたデフォルト関数名をもつ構造体変数を定義し、初期化します。この構造体は以下のように定義されます。
<INTERF>_v<major>_<minor>_epv_t<INTERF>_v<major>_<minor>_s_epv
ここで <INTERF> はインタフェース名で、<major>_<minor> はインタフェース バージョンです。この変数は、サーバ スタブ関数を呼び出すときに、逆参照されます。関数名とオペレーション名に衝突や相違がある場合に、アプリケーションからこの変数の定義と初期化が行えるように、IDL コンパイラ オプション、-no_mepv を使用してこの変数の定義と初期化を無効にできます。アプリケーションで自動バインドの代わりに明示的または暗黙的なバインドを行う場合には、-no_mepv オプションを指定できます。またアプリケーションは、オペレーションと同じで、異なる名前または静的な名前をパラメータとして使用する関数を指す構造体定義を指定できます。その後、この関数は、実際のオペレーション名を用いて明示的または暗示的に DCE/RPC クライアント スタブ関数に渡される有効なバインド ハンドルを生成できます。
これは、「DCE ゲートウェイ アプリケーション」の例に示されています。dcebind.c ファイルはバインド ハンドルを生成し、またエントリ ポイント ベクトルと関連する関数は dceepv.c に示されています。
blds_dce を使用する場合に -no_mepv オプションを指定するには、オプションが IDL コンパイラを経由して渡されるように "-i -no_mepv" オプションを指定する必要があることに注意してください。これは、「DCE ゲートウェイ アプリケーション」の makefile、rpcsimp.mk に示されています。
この時点でログイン コンテキストとハンドルが有効なので、認証済み RPC コールを使用できます。バインド ハンドルをセットアップする一部として、rpc_binding_set_auth_info() を呼び出すことによって認証のためにバインド ハンドルにアノテーションを付けることができます。詳細については、『Oracle Tuxedo C リファレンス』を参照してください。これは、「DCE ゲートウェイ アプリケーション」の dcebind.c でバインド ハンドルを生成する一部として示されています。これによりゲートウェイと DCE サーバ間に認証 (および潜在的な暗号化) をセットアップします。要求者が Oracle Tuxedo サーバであれば、要求者は Oracle Tuxedo 管理者として実行されることが保証されています。Oracle Tuxedo クライアントの認証の詳細については、『Oracle Tuxedo アプリケーション実行時の管理』を参照してください。
この図では、DCE 要求者は DCE クライアント スタブを使って DCE サービスを起動し、次いでこの DCE サービスがアプリケーション サービスの代わりに Oracle Tuxedo クライアント スタブを呼び出し、さらにこの Oracle Tuxedo クライアント スタブが TxRPC を使用して Oracle Tuxedo サービスを起動します。このコンフィグレーションでは、クライアントが DCE バインドと認証を完全に制御していることに注意してください。アプリケーション プログラマがミドル サーバを構築するということは、アプリケーションも Oracle Tuxedo サービスに対する DCE サーバのバインドを制御するということを意味します。この方法は、DCE 要求者を Oracle Tuxedo システムに直接リンクし、呼び出すことを希望しない場合に使用されます。
DCE サーバ用の main() は、$TUXDIR/lib/dceserver.c で提供されているコードを元にする必要があります。DCE サーバの main() 用のテンプレートがすでに用意されている場合、追加し、修正する項目がわずかですが必要になります。
まず、tpinit(3c) を呼び出して Oracle Tuxedo アプリケーションに参加する必要があります。アプリケーション セキュリティがコンフィグレーションされている場合は、TPINIT バッファにユーザ名やアプリケーション パスワードなど追加情報が必要になることもあります。終了する前に、tpterm(3c) を呼び出して Oracle Tuxedo アプリケーションへの参加を終了させる必要があります。-DTCLIENT でコンパイルしてみると、dceserver.c には tpinit と tpterm を呼び出すコードが含まれていることが分かるはずです。TPINIT バッファをセットアップするコードは、アプリケーションに応じた修正が必要です。管理に関するより多くの情報を提供するには、クライアントが DCE クライアントであることを、ユーザ名またはクライアント名で示すのが効果的です (例ではクライアント名を DCECLIENT に設定しています)。この情報は管理インタフェースからクライアント情報を出力すると表示されます。
次の手順としては、Oracle Tuxedo システム ソフトウェアはスレッドセーフではないので、rpc_server_listen に渡すスレッディング レベルは 1 に設定する必要があります。dceserver.c では、-DTCLIENT でコンパイルする場合にはスレッディング レベルは 1 に設定され、それ以外の場合スレッディング レベルはデフォルトの rpc_c_listen_max_calls_default に設定されます。詳細については、『Oracle Tuxedo C リファレンス』を参照してください。
このコンフィグレーションでは、要求者は通常の DCE クライアントまたは DCE サーバとして構築されます。同様に、サーバは通常の Oracle Tuxedo サーバとして構築されます。追加の作業として、TxRPC クライアント スタブを使用する Oracle Tuxedo クライアントとして機能し、さらに DCE/RPC サーバ スタブを使用する DCE サーバとしても機能するゲートウェイ プロセスを構築します。
2 つの IDL コンパイラを実行し、得られたファイルをリンクするプロセスは、DCE がリンクされた Oracle Tuxedo クライアントを構築する bldc_dce(1) コマンドを使用することによって簡略化できます。
bldc_dce の使用法は次のとおりです。
bldc_dce [-o output_file] [-w] [-i idl_options] [-f firstfiles] \ [-l lastfiles] [idl_file . . . ]
このコマンドは入力として 1 つ以上の IDL ファイルを使用するので、ゲートウェイは 1 つ以上のインタフェースを処理できます。これらのファイルごとに、クライアント スタブを生成する場合は tidl を実行し、サーバ スタブを生成する場合は idl を実行します。
このコマンドは各種の DCE 環境を認識し、コンパイルとリンクに必要なコンパイル フラグと DCE ライブラリを提供します。新たな環境で開発している場合は、コマンドを変更して現在の環境に合ったオプションとライブラリの追加が必要になります。『Oracle Tuxedo C リファレンス』で説明しているように、復帰時メモリを確実に解放するために、常に rpc_ss_allocate と rpc_ss_free をメモリ割り当てに使用することを定義する -DTMDCEGW を指定してソース ファイルがコンパイルされます。-DTMDCEGW を使用する場合には、Oracle Tuxedo TxRPC ヘッダ ファイルの代わりに DCE ヘッダ ファイルが組み込まれます。
buildclient(1) を用いて Oracle Tuxedo クライアントを作成するには、アプリケーション ファイルを指定して (-f と -l オプションを使用します)、IDL 出力オブジェクト ファイルをコンパイルします。-DTCLIENT オプションを指定してコンパイルされた dceserver.o と等価なファイルが 1 つ含まれる必要があることに注意してください。
実行可能なクライアントの名前は -o オプションで指定できます。
このコンフィグレーションを実行する場合、DCE サーバを開始する前に Oracle Tuxedo のコンフィグレーションを起動し、DCE 要求をリスンする前に Oracle Tuxedo のコンフィグレーションが Oracle Tuxedo アプリケーションに参加できるようにする必要があります。
この方法では、DCE 環境をクライアントが直接利用できるものとみなしています。コンフィグレーションによっては、これが制限または短所になる場合もあります。クライアント プログラムは、DCE バインドと認証を直接制御します。これは要求者が、DCE サービスを呼び出す Oracle Tuxedo サービスであるか、または Oracle Tuxedo サービスと DCE サービスの両方を呼び出す Oracle Tuxedo クライアント (またはサーバ) である複合環境になっている可能性があることに注意してください。
DCE コードと混在して使用する Oracle Tuxedo の TxRPC コードをコンパイルするときは、TxRPC ヘッダ ファイルの代わりに、DCE ヘッダ ファイルを使用してコードをコンパイルする必要があります。このことは、クライアントやサーバのスタブ ファイルとアプリケーション コードの両方に対してコンパイル時に -DTMDCE を定義することで行えます。tidl(1) からオブジェクト ファイルを生成している場合は、-cc_opt -DTMDCE オプションをコマンドラインに追加する必要があります。別の方法としては、次の例のように、IDL コンパイラから c_source を生成し、オブジェクト ファイルではないこの C ソースを bldc_dce または blds_dce に渡します。
tidl -keep c_source -server none t.idl idl -keep c_source -server none dce.idl bldc_dce -o output_file -f client.c -f t_cstub.c -f dce_cstub.c
または
blds_dce -o output_file -s service -f server.c -f t_cstub.c -f dce_cstub.c
この例では、ゲートウェイ プロセスを構築しているのではないので、build コマンドに .idl ファイルを指定することはできません。また、blds_dce コマンドはサーバに関連したサービス名を認識できないので、-s オプションを使ってサービス名を指定する必要があることに注意してください。
この最後の事例では、DCE 要求者が直接 Oracle Tuxedo クライアント スタブを呼び出します。
ここでも、クライアントおよびサーバのスタブ ファイルとアプリケーション コードの両方に対して、-DTMDCE をコンパイル時に使用する必要があります。この場合、要求者は Oracle Tuxedo クライアントである必要があります。
tidl -keep c_source -client none t.idl bldc_dce -o output_file -f -DTCLIENT -f dceserver.c -f t_cstub.c
前述のように、dceserver.c はアプリケーションを終了するために tpterm(3c) を、アプリケーションに参加するために tpinit(3c) を呼び出す必要があることに注意してください。
このセクションでは、bldc_dce(1) や blds_dce(1) コマンドを用いることなく複合クライアントまたはサーバをコンパイルする際に、順守すべき規則の要点を説明します。
生成したクライアントとサーバ スタブをコンパイルし、tidl(1) が生成したヘッダ ファイルをインクルードしているクライアントとサーバ アプリケーション ソフトウェアをコンパイルするときは、TMDCE を定義する必要があります (たとえば、-DTMDCE=1)。これにより、Oracle Tuxedo TxRPC ヘッダ ファイルの代わりに DCE ヘッダ ファイルが使用されます。また、DCE のバージョンに中には、DCE ヘッダ ファイル用に適切なディレクトリを追加し、ローカル環境用に適切な DCE 定義を確保する DCE コンパイル シェルが用意されているものもあります。直接 C コンパイラを実行する代わりに、このシェルを使用します。DCE/RPC コンパイラと TMDCE 定義は、tidl の -cc_cmd オプションを使って指定できます。次に例を示します。
tidl -cc_cmd "/opt/dce/bin/cc -c -DTMDCE=1" simp.idl
または
tidl -keep c_source simp.idl /opt/dce/bin/cc -DTMDCE=1 -c -I. -I$TUXDIR/include simp_cstub.c /opt/dce/bin/cc -DTMDCE=1 -c -I. -I$TUXDIR/include client.c
コンパイラ シェルをもたないシステムの場合は、次のようになります。
cc <DCE options> -DTMDCE=1 -c -I. -I$(TUXDIR)/include \ -I/usr/include/dce simp_cstub.c
環境については DCE/RPC ドキュメントを参照してください。
サーバが RPC コールを行う場合は、前記のとおり set_client_alloc_free() を呼び出して rpc_ss_allocate() および rpc_ss_free() を使用できるようにします。詳細については、『Oracle Tuxedo C リファレンス』を参照してください。
実行可能ファイルをリンクする場合は、-ltrpc の代わりに -ldrpc を使用して、DCE/RPC と互換性のある Oracle Tuxedo TxRPC ランタイムを取得します。次に例を示します。
buildclient -o client -f client.o -f simp_cstub.o -f dce_cstub.o \ -f-ldrpc -f-ldce -f-lpthreads -f-lc_r
または
CC=/opt/dce/bin/cc buildclient -d " " -f client.o -f simp_cstub.o \ -f dce_cstub.o -f -ldrpc -o client
simp_cstub.o は tidl(1) によって生成され、また dce_cstub.o は idl によって生成されたと仮定します。最初の例では、DCE コンパイラ シェルを使用しないクライアントの構築を示しています。この場合、DCE ライブラリ (-ldce)、スレッド ライブラリ (-lpthreads)、リエントラント C ライブラリ (-lc_r) は明示的に指定しなければなりません。2 番目の例では、必要なライブラリを透過的にインクルードする DCE コンパイラ シェルの使用方法を示します。一部の環境では、ネットワーキングと XDR 用の buildserver および buildclient によってインクルードされたライブラリは、DCE コンパイラ シェルによってインクルードされるライブラリと衝突する場合があります (これらのライブラリのリエントラント バージョンが存在することもあります)。この場合は、buildserver(1) と buildclient(1) ライブラリは -d オプションを使って変更できます。リンク上の問題が発生した場合は、上記の例で示すとおり、-d " " を使用してネットワーキングと XDR ライブラリを切り離してみてください。それでもリンクに問題がある場合は、-d オプションを指定しないで、-v オプションを指定してコマンドを実行し、デフォルトで使用されるライブラリを調べてみてください。その後で、ライブラリが複数存在していれば、-d オプションを使ってライブラリのサブセットを指定します。ネットワーキング、XDR、DCE ライブラリは環境に応じて異なるため、ライブラリの正しい組み合せは環境に依存します。
|
注意 : DCE スタブと Oracle Tuxedo TxRPC スタブの混在は、Windows では現在サポートされていません。 |
