1. 『C言語を使用したOracle Tuxedo ATMIアプリケーションのプログラミング』
  2. 型付きバッファの管理
  3. 型付きバッファの概要

2.1 型付きバッファの概要

あるプロセスから別のプロセスにメッセージを送信する場合、メッセージ・データ用のバッファを割り当てておく必要があります。Oracle Tuxedo ATMIクライアントは、型付きバッファを使用してATMIサーバーにメッセージを送ります。型付きバッファとは、カテゴリ(タイプ)と、サブカテゴリ(サブタイプ)が定義されたメモリー領域です。型付きバッファは、Oracle Tuxedoシステムでサポートされる分散プログラミング環境の基本要素の1つです。

なぜ型付きを使用するのでしょうか。分散環境では、アプリケーションが異機種システムにインストールされ、異なるプロトコルを使用して複数のネットワーク間で通信が行われます。バッファ・タイプが異なると、初期化、メッセージの送受信、およびデータのエンコード/デコードにそれぞれ別のルーチンが必要になります。各バッファに特定のタイプが割り当てられていると、プログラマが介在しなくても、そのタイプに対応するルーチンを自動的に呼び出すことができます。

次の表は、Oracle Tuxedoシステムでサポートされる型付きバッファと、そのバッファが次の条件を満たしているかどうかを示しています:

  • 自己記述型であるかどうか。つまり、バッファのデータ型と長さが、タイプとサブタイプ、およびそのデータからわかるかどうか。
  • サブタイプが必要かどうか。
  • 型付きバッファのデータ依存型ルーティングがシステムでサポートされているかどうか。
  • 型付きバッファのエンコード/デコードがシステムでサポートされているかどうか。

ルーティング関数が必要な場合は、アプリケーション・プログラマが用意します。

表2-1 型付きバッファ

型付きバッファ 説明 自己記述型 サブタイプ データ依存型ルーティング エンコード/デコード
CARRAY 未定義の文字配列。NULL文字を含むことができます。Oracle Tuxedoシステムでは配列のセマンティクスは解釈されないので、この型付きバッファは曖昧なデータを処理する場合に使用します。CARRAYは自己記述型ではないので、転送時には長さを指定する必要があります。システムではバイトは解釈されないので、マシン間のメッセージ送信ではエンコード/デコードはサポートされません。 いいえ いいえ いいえ いいえ
FML (フィールド操作言語) Oracle Tuxedoシステム固有の自己記述型バッファ・タイプ。このバッファでは、各データ・フィールドに対応する識別子、オカレンス番号、場合によっては長さを示す値が格納されています。データ操作はすべて、ネイティブなC言語の文ではなくFML関数を使用して行われます。このため、処理に多少のオーバーヘッドが生じてでも、FMLバッファを通じて、データの独立性と動作の柔軟性が確保されるようになっています。

FMLバッファでは、フィールド識別子とフィールド長に16ビットが使用されます。

FMLバッファの詳細は、「FML型バッファ」を参照してください

 はい いいえ はい はい
FML32 FMLと同じ。ただし、フィールド識別子とフィールド長に32ビットが使用されます。より長いフィールドを多数使用できるので、バッファ全体が大きくなります。

FML32バッファの詳細は、「FML型バッファ」を参照してください

 はい いいえ はい はい
STRING 最後がNULL文字で終了する文字配列。STRINGバッファは、自己記述型です。そのため、異なる文字セットを使用するマシン間でデータを交換する場合は、Oracle Tuxedoシステムによってデータが自動的に変換されます。 はい いいえ いいえ いいえ
VIEW アプリケーションで定義されるC構造体。VIEW型には、個々のデータ構造体を示すサブタイプが必要です。VIEW記述ファイル(データ構造体のフィールドとタイプが定義されたファイル)は、VIEW型バッファに定義されたデータ構造体を使用するクライアント・プロセスとサーバー・プロセスがアクセスできなければなりません。異なるタイプのマシン間でバッファがやり取りされる場合は、エンコード/デコードが自動的に行われます。

VIEWは、mbstring型バッファをサポートしていません。

VIEWバッファの詳細は、「VIEW型バッファの使用」を参照してください

 いいえ はい はい はい
VIEW32 VIEWと同じ。ただし、長さとカウントのフィールド長に32ビットが使用されます。より長いフィールドを多数使用できるので、バッファ全体が大きくなります。

VIEW32は、mbstring型バッファをサポートしており、carrayと同じ方法でmbstringデータを処理します。

VIEWバッファの詳細は、「VIEW型バッファの使用」を参照してください

 いいえ はい はい はい
X_C_TYPE VIEWと同じです。 いいえ はい はい はい
X_COMMON VIEWと同じ。ただし、このバッファ型はCOBOLとCプログラム間の互換性を取るために使用されます。フィールド・タイプとして使用できるのは、short、long、およびstringだけです。 いいえ はい はい はい
XML XMLドキュメントは、次の要素から構成されます。
  • エンコードされた文字の並びで構成されるテキスト
  • ドキュメントの論理構造の記述と、その構造に関する情報
XML文書のルーティングは、要素の内容、または要素タイプと属性値に基づいて行われます。使用されている文字エンコードはXMLパーサーによって判別されます(Oracle Tuxedo 22.1では、XMLパーサーとしてApache Xerces C++バージョン3.2.3パーサーが使用可能)。エンコードがOracle Tuxedoの構成ファイル(UBBCONFIG(5)とDMCONFIG(5))で使用されているネイティブな文字セット(US-ASCIIまたはEBCDIC)と異なる場合、要素と属性名はUS-ASCIIまたはEBCDICに変換されます。

XMLバッファおよびXerces C++パーサーの詳細は、「XML型バッファとApache Xerces C++パーサーの使用」を参照してください

 いいえ いいえ はい いいえ
X_OCTET CARRAYと同じです。 いいえ いいえ いいえ いいえ
MBSTRING Oracle Tuxedo 8.1で使用可能になったマルチバイト文字の文字配列。MBSTRINGバッファの詳細は、「MBSTRING型バッファの使用」を参照してください いいえ いいえ いいえ いいえ
RECORD アプリケーションで定義されるCOBOLコピーブック・レコード。RECORD型には、レコード構造体を示すサブタイプが必要です。レコード構造体のフィールドと型が定義されたRECORD記述ファイルは、RECORD型バッファに記述されたレコード構造体を使用するクライアント・プロセスとサーバー・プロセスで使用できる必要があります。RECORDバッファの詳細は、「RECORD型バッファの使用」を参照してください。 いいえ はい いいえ はい

すべてのバッファ・タイプは、$TUXDIR/libディレクトリのtmtypesw.cファイルに定義されています。クライアント・プログラムとサーバー・プログラムで認識されるバッファ・タイプは、tmtypesw.cに定義されているものだけです。tmtypesw.cファイルを編集して、バッファ・タイプを追加したり削除できます。また、UBBCONFIGのBUFTYPEパラメータを使用して、特定のサービスで処理できるタイプとサブタイプを制限できます。

tmtypesw.cファイルは、共有オブジェクトや動的リンク・ライブラリのビルドに使用されます。このオブジェクトは、Oracle Tuxedo管理サーバー、およびアプリケーション・クライアントとアプリケーション・サーバーによって動的にロードされます。

関連項目:

親トピック: 型付きバッファの管理