Oracle Tuxedo TxRPCは、
『DCE: REMOTE PROCEDURE CALL』(Doc Code: P312 ISBN 1-872630-95-2)の第3章「Interface Definition Language」で説明されているIDL文法と関連機能をサポートしています。この本は次から入手できます。
X/OPEN Company Ltd (Publications)
P O Box 109
Penn
High Wycombe
Bucks HP10 8NP
United Kingdom
電話: +44 (0) 494 813844
FAX: +44 (0) 494 814989
X/OPENドキュメントは、ATMI環境でOracle Tuxedo製品が準拠し、その言語および規則の原典とするものです。X/OPEN TxRPC IDL-onlyインタフェースがサポートされていることに注意してください。DCEバインドとランタイムに関するドキュメントの一部は適用されません。X/OPENドキュメントはOSF DCE AES/RPCドキュメントを基本としています。チュートリアル、プログラマーズ・ガイドとして入手可能な文献は多数ありますが、ほとんどのものには最新の機能は記載されていません。OSFから入手できるプログラマーズ・ガイドとして、Prentice-Hallの『OSF DCE Application Development Guide』(Englewood Cliffs, New Jersey, 07632)があります。
『X/OPEN Preliminary Specification for TxRPC Communication Application Programming Interface』もまたX/OPENから入手できます(上記を参照)。TxRPCは、RPC用のトランザクション・サポートをオリジナルのX/OPEN RPCインタフェースに追加しています。
汎用一意識別子(UUID)はインタフェースを一意に識別するために使用します。
uuidgenコマンドを実行してUUIDを生成します。出力は次のようになります。
$ uuidgen -i > simp.idl
$ cat simp.idl
[uuid(816A4780-A76B-110F-9B3F-930269220000)]
interface INTERFACE
{
}
次にこのテンプレートを使用して、型定義、定数、およびオペレーションを追加するアプリケーション用のIDL入力ファイルを作成します。
ATMIとDCEの両方の
uuidgen(1)コマンドを利用できる場合は、DCEコマンドでテンプレートを生成する必要があります。DCEバージョンでは通常、次で説明するとおり、ノード・アドレスを取得するためにマシン固有の手法を採用しています。
ATMIの
uuidgenコマンドは、
-sオプション(初期化されたC構造体としてUUID文字列を生成する)と、
-tオプション(以前の形式のUUID文字列を新規形式に変換する)をサポートしていない点を除いて、DCEコマンドと同じです。インタフェースの詳細は
uuidgen(1)のリファレンス・ページを参照してください。
uuidgenコマンドは、ISO/IEC 8802-3 (ANSI/IEEE 802.3)に記載されているように48ビット・ノード・アドレスを要求します。プラットフォームに依存せずにこの値を求める方法は存在しません。また一部のマシン(ワークステーションなど)ではまったく利用できないこともあります。ATMIの
uuidgenコマンドでは、次の手法が使用されています。
|
•
|
NADDR環境変数が num.num.num.num.num.numの形式の値で設定されている場合、インターネット・スタイルのアドレスが採用され、48ビットのノード・アドレスに変換されます。ここで numは0と255を含む、0から255までの値です。これにより8802-3ノード・アドレスの使用法に準拠できます。また、このアドレスにアクセスできないユーザーも、インターネット・アドレス(8802-3アドレスと同じではない)などの別の値を利用できるようになります。 インターネット・アドレスを使用している場合、インターネット・アドレスは32ビット・アドレスなので、最後の num.numは0.0とします。
|
|
•
|
NADDR環境変数が設定されておらず、 WSNADDR環境変数が 0xnnnnnnnnnnnnnnnn形式の値に設定されている場合、ワークステーションで使用されるような、16進数のネットワーク・アドレスが採用されることになります。これは8802-3アドレスではなく、また最後の16ビットはゼロとして処理されることに注意してください。
|
|
•
|
NADDR環境変数と WSNADDR環境変数のいずれも設定されていない場合には、(またWindowsでない場合)、そのマシンの unameを用いて /etc/hosts内のマシン・エントリと照合し、インターネット・スタイルのアドレスを取得します。
|
|
•
|
前述のいずれにも当てはまらない場合、警告が表示され、アドレス00.00.00.00.00.00が採用されます。これは、ユニークなUUIDを生成できる可能性が低くなるので望ましい方法ではありません。 |
IDLコンパイラはIDL文法を認識して、入力に基づいてスタブ関数を生成します。文法とそのセマンティクスは、本章前半に記載したX/OPENリファレンスとOSF/DCEリファレンスの両方に詳しく説明されています。次の項目で説明するいくつかの変更を加えることで文法はそのまま認識されます。
次にX/OPEN TxRPC仕様に定義されている基本X/OPEN RPC仕様に対する変更点を示します。
|
•
|
TxRPC仕様からの最も重要な拡張点は、IDLファイルのインタフェースとオペレーション属性に [transaction_optional]と [transaction_mandatory]属性を追加した点です。 [transaction_optional]は、トランザクション内でRPCを実行する場合、トランザクションの一部としてリモート・サービスが実行されることを示します。 [transaction_mandatory]属性ではトランザクション内でRPCが実行される必要があります。これらの属性の指定がなければ、リモート・サービスはクライアントのトランザクションの一部ではありません。 |
|
•
|
X/OPEN TxRPC IDL-onlyでは型と属性のバインドは必須ではありません。属性のバインドには、 [handle]、 [endpoint]、 [auto_handle]、 [implicit_handle]、および [explicit_handle]があります。これらの属性は tidl(1)によって認識されますがサポートされていません(無視されます)。 handle_t型に対しても特別な処理は行われません。ほかの定義済の型と同様に受け渡され、ハンドルとしては処理されません。 |
|
•
|
X/OPEN TxRPC IDL-onlyではパイプは必須ではありません。 tidlは [local]モードでしかパイプをサポートしません。つまり、パイプはヘッダー・ファイル用として指定できますが、スタブ生成用としては指定できません。 |
|
•
|
X/OPEN TxRPC IDL-onlyでは [idempotent]、 [maybe]、および [broadcast]属性は必須ではありません。 tidl(1)はこれらの属性を無視します。 |
次にX/OPEN RPC仕様に対する強化を示します。多くの場合、言語はC言語により密接に従うように拡張されており、ANSI CからIDLプロトタイプに変換することにより、既存インタフェースの移植を簡素化しています。
|
•
|
X/OPEN仕様では、文字定数と文字列は移植可能なセット、つまりスペース (0x20)からティルダ (0x7e)までに制限されています。OSF DCE RPCでは、文字セット(0x01から0xffまで)内のその他の文字の使用も認められています。 |
|
•
|
Cと同様、次の演算子は区切り文字として扱われます。 |
|| && ? | & _ == != = << >> <= >= < > + - % ! ~
つまり、これらのトークンの1つが先行するまたは後続する場合は、識別子または数字の前または後に空白を入れる必要はないということです。IDL仕様では
a=b+3は認められず、
a = b + 3のように空白を入れる必要があります。これはOSF DCE IDLコンパイラの動作によるものと思われます。
|
•
|
公開されているX/OPEN仕様では、フィールド名とパラメータ名に型名を使用できないという制約があります。この制約により、すべての名前を単一のネームスペースに置くことができます。この制約はC、C++またはOSF IDLコンパイラの仕様と整合性がないので、強制するものではありません。 |
|
•
|
X/OPEN仕様は、パラメータまたは関数の結果として匿名の列挙を認めておらず、またポインタのターゲットとして匿名構造体またはユニオンを認めていません。これらについてはOSF DCE IDLコンパイラでは認められています。これらの制約は強制されません。インタフェース名およびバージョンに基づく名前は、マーシャリング中に使用するために生成されます。 |
|
•
|
Cと同様に、列挙値(定数)は整数定数式で使用できます。これはDCE IDLコンパイラの動作によるものと思われます。 |
|
•
|
現時点のX/OPEN RPC仕様の定義では、次のようにオペレーション宣言子の前にポインタを置くことは文法上認められません。 |
また、構造体またはユニオンを返すことも認めていません。すべてを定義済の型に隠ぺいできるという点で正しいと考えられますが、DCE IDLコンパイラと、もちろんCコンパイラはより豊富なオペレーションを返すことを認めています。サポートされている文法は次のようになります。
[
operation_attributes] <
type_spec> <
declarator>
この場合の
<declarator>は、
<function_declarator>を含む必要があります。
<function_declarator>が存在しない場合、変数は宣言されますが、結果としてエラーになります。オペレーションの配列または配列を戻すオペレーションを宣言することはともにこの文法で認められていて、宣言としては認識されますが、エラーのフラグが設定されます。
|
•
|
IDL <type_declaration>が宣言子のリストを取るように、 <ACS_type_declaration>は <ACS_named_type>値を取ります。これはDCE IDLコンパイラの動作によるものと思われます。 |
|
•
|
Field Manipulation Language (FML)を使用して作成、操作されるフィールド化バッファは多くのOracle Tuxedo ATMIアプリケーションの不可欠の部分になっています。フィールド化バッファは、IDLでは新しい基本型としてサポートされます。フィールド化バッファは、16ビット・バッファについてはキーワード FBFRで、32ビット・バッファはキーワード FBFR32で示され、ポインタとして定義される必要があります(たとえば FBFR *または FBFR32 *)。フィールド化バッファは typedefで基本型として定義することはできません。フィールド化バッファは、構造体のフィールドで、さらにパラメータとして使用できます。これは、配列またはポインタ(完全ポインタまたは参照ポインタのいずれか)のベース・タイプとして使用できます。ただし、フィールド化バッファの整合配列と可変配列はサポートされません。 |
|
•
|
OSF IDLコンパイラでは、AES仕様またはX/OPEN RPC仕様にドキュメント化されていない制約がいくつか存在します。Oracle TuxedoのIDLコンパイラではこれらの制約が強制されます。 |
|
•
|
[ transmit_as()]で使用する転送型には[ represent_as]属性を設定できません。 |
|
•
|
ユニオン・アームを[ref]ポインタにしたり、ユニオン・アームに[ ref]ポインタを含めることはできません。 |
|
•
|
整合配列と可変配列の両方あるいはいずれか一方が構造体に存在する場合は、配列サイズの属性変数はポインタにはできません。つまりポインタではなく、構造体内の整数要素である必要があります。 |
X/OPEN RPC仕様に対してOracle Tuxedo ATMIの4つの拡張機能が追加されており、これらは仕様をよりC言語に近づける一方で、OSF DCE IDLコンパイラではサポートされないためにIDLファイルの移植性に制限を加えることになります。
|
•
|
ANSI Cと同様に、文字列連結がサポートされます。つまり、 |
const char *str = "abc" "def";
const char *str = "abcdef";
|
•
|
エスケープ文字を使用した改行を文字列定数内で用いることができます。つまり、 |
const char *str = "abc\
def";
const char *str = "abcdef";
|
•
|
列挙値はユニオン・ケースでも使用でき、整数として扱われます。Cと同様に自動的に変換されます。 |
|
•
|
各 <union_case_label>の型を <switch_type_spec>によって指定する必要があるという制約は設けていません。かわりに、C言語のswitch文のcase文で行われるような型の強制変換が行われます。 |
次の7つの機能は
tidlコンパイラではサポートされていません。
|
•
|
移行属性 [v1_struct]、 [v1_enum]、 [v1_string]、 [v1_array]は認識されますが、サポートされていません。これらの属性はOSF IDL仕様にはありますが、X/OPEN仕様にはありません。 |
|
•
|
OSF/DCEと同様に [local]モードでのみOSF/DCEドキュメントに定義された関数ポインタがサポートされます。 |
|
•
|
クライアントとサーバー間ではインタフェースのマイナー・バージョンまで完全に一致する必要があります。X/OPEN RPC仕様では、サーバーのマイナー・バージョンがクライアントのマイナー・バージョンよりも大きいか等しい場合も許可しています。 |
|
•
|
32ビット長のマシンでは、整数リテラル値は -2**31から2**31の範囲に制限されています。2**31+1から2**32-1の範囲のunsigned long整数値はサポートされません。これはDCE IDLコンパイラの動作によるものと思われます。 |
|
•
|
コンテキスト・ハンドルは [local]モードだけでサポートされます。状態をまたがるオペレーションを管理するためにコンテキスト・ハンドルを使用して、インタフェースを記述することはできません。 |
|
•
|
[out-of-line] ACS属性は無視されます。この機能は、たとえばOSF IDLコンパイラを使用する異なる実装間での相互運用をサポートするという点では定義されていません。
|
IDLコンパイラ用のインタフェースは、X/OPEN仕様では指定されていません。
DCEアプリケーションの移植性を考慮し、Oracle Tuxedo ATMI IDLコンパイラのインタフェースはDCE IDLコンパイラと同様ですが、次のような例外があります。
|
•
|
コマンド名は idlのかわりに tidlを用います。同じ環境に両方のコンパイラが存在する場合でも、コンパイラの識別がアプリケーションから容易に行えます。 |
|
•
|
-bugオプションは、旧バージョンのソフトウェアとの相互運用のために、誤動作を起こさせます。このオプションは無効です。 -no_bugオプションも無効です。
|
|
•
|
-space_optオプションは無視されます。このオプションは、コード領域の最適化を行います。領域は常に最適化されます。
|
|
•
|
新しいオプション -use_constがサポートされています。 -use_constは、定数定義用の #define文のかわりにANSI C const文を生成します。このオプションにより、IDLファイル内で定義された定数がCプリプロセッサ定義を使用するファイル内の別の定数名と競合するというやっかいな問題を回避できます。このオプションにより、Cの定数として定義されるときに、これらの定数は別のネームスペースに正しく配置されます。本機能を使うと、IDLファイルの移植性が制限されます。 |
|
•
|
デフォルトでは、 /lib/cpp、 /usr/ccs/lib/cpp、または /usr/lib/cppのいずれかのコマンドを使用して、入力IDLファイルと入力ACFファイルのプリプロセッサ処理を行います。3つのプリプロセッサのうち最初に見つかったものを使用します。 |
デフォルトでは、IDLコンパイラは入力IDLファイルを受け取り、クライアントとサーバー・スタブのオブジェクト・ファイルを生成します。
-keep c_sourceオプションはCソース・ファイルだけを生成し、
-keep allオプションはCソース・ファイルとオブジェクト・ファイルの両方を保持します。
付録「?$paratext[AppHead]>,?」にリストされているサンプルRPCアプリケーションでは、
-keep objectオプションを使用してオブジェクト・ファイルを生成します。
デフォルトでは、
tidlは最大50個までのエラーを表示します。エラー数が50個を超えている場合に、すべてのエラーを表示するときは、
-error allオプションを指定します。エラー出力は
stderrに送られます。
その他使用可能なオプションの詳細は、
『Oracle Tuxedoコマンド・リファレンス』を参照してください。
