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