JP2001502823A - インターフェイス定義言語によって定義されたデータ構造体を異種システム間で移送するための方法および装置 - Google Patents

Abstract

(57)【要約】 ＩＤＬ定義されたデータ構造体を２つのコンピュータ間での移送に便利な書式に、また、この書式から移行する方法および装置を開示する。このデータ構造体は最初は文字列で記述されている。この文字記述は該データ構造体のアラインメントおよびサイズに関する追加情報を含む異なる書式に変換される。送り側コンピュータのアプリケーションは、上記データ構造体からアラインメント書式を除去し、該データ構造体をバッファに格納する。上記データ構造体は、その型に準拠する所定の書式で出力バッファに格納される。次いでこのバッファが受け取り側コンピュータのメモリまたはデータファイルに送られる。受け取り側コンピュータは、上記所定書式に基づいて上記バッファから上記データ構造体を抽出する。このデータ構造体は再整列され、第２コンピュータのメモリに格納される。

Description

【発明の詳細な説明】 インターフェイス定義言語によって定義されたデータ構造体 を異種システム間で移送するための方法および装置 発明の背景 １．発明の分野 この発明は、オブジェクト管理グループのインターフェイス定義言語によっ て定義されたデータ構造体を異種プラットフォーム間で移送するための方法およ び装置に関する。特に、本発明は、データ構造体からアラインメントを除去し、 そのデータ構造体を所定の書式でファイルに又は異種プラットフォーム間で移送 する関数を利用するものである。 ２．背景 分散型オブジェクトコンピューティング方式は、分散型コンピューティング とおよびオブジェクト指向型コンピューティングの概念を組み合わせたものであ る。分散型コンピューティング方式は、情報を相互に共有する２つ又はそれ以上 のソフトウエアで構成される。これら２つのソフトウエアは、同一のコンピュー タ、または、共通のネットワークに接続された複数の異なるコンピュータ上で実 行される。ほとのどの分散型コンピューティング方式は、クライアント／サーバ モデルに基づいている。このようなクライアント／サーバモデルでは、２種類の ソフトウエア、即ち、情報またはサービスを要求するクライアントソフトウエア と、情報またはサービスを提供するサーバソフトウエアが使用される。 オブジェクト指向コンピューティングは、（しばしば、現実世界における実 オブジェクトから抽象化した）“オブジェクト”と称するコードが、（オブジェ クト指向プログラミング言語では“属性”と呼ばれる）データを所有するととも に、メソッド（“オペレーション”若しくは“メンバ関数”とも呼ばれる）を介 してサービスを提供するオブジェクトモデルに基づくものである。オブジェクト に含まれる上記データおよびメソッドは、“公開（パブリック）”または“非公 開（プライベート）”のものである。公開データは、他のオブジェクトによって 変更可能である。しかし、ほとんどのデータは、非公開であり、オブジェクトが 所有するメソッドにしかアクセスできない。典型的に、メソッドは、オブジェク トに含まれる非公開データ上で動作する。 類似オブジェクトの集まりがインターフェイス（またはＣ＋＋言語における “クラス”）を構成する。インターフェイスは、その全てのオブジェクトに含ま れるデータ型およびメソッドを指定する。そして、オブジェクトがそのインター フェイスに基づいて作成（“例示”）される。各オブジェクトは、それに固有の データを含む。各特定のオブジェクトは、分散型オブジェクトシステムにおいて 、オブジェクト参照と呼ばれる識別子によって識別される。 分散型オブジェクトシステムにおいて、クライアントは、リクエスト（又は “オブジェクト呼出し”）をサーバに送る。このリクエストは、サーバが実行す べきオペレーション、オブジェクト参照およびそのリクエストの成功又は失敗に 関する“例外情報”（予期せぬ出来事）を返すためのメカニズムを含んでいる。 サーバは、上記リクエストを受信し、もしかのうであるならそのリクエストを実 行し、適当な例外情報を戻す。オブジェクトリクエストブローカ（“ＯＲＢ”： Object Request Broker）は、該システムの全オブジェクトのためにサーバにリ クエストを送り、クライアントに回答を送る通信ハブを提供する。 クライアント側のORBは、メソッドの呼び出しおよびこれに関連するサーバ とメソッドの選択を要求するリクエストを取り扱う。アプリケーションが、ある オブジェクトについて実行すべきメソッドを要求するリクエストを上記ORBに送 ると、このORBは、該リクエストに含まれる引数をそのオブジェクトのインター フェイスに対して検査し、該リクエストをサーバに送り、必要な場合それを開始 する。サーバ側のORBは、上記リクエストを受け取り、引数の配列を解除し、必 要とされるコンテキスト状態をセットアップし、メソッドディスパッチャを呼び 出し、出力引数を配列し、その結果をクライアントに戻し、これにより、オブジ ェクト呼出しを終了する。 クライアントとサーバの両方が、実行可能な使用可能オブジェクトおよびメ ソッドに関する情報を有する必要がある。非公開データの隠蔽（オブジェクト指 向言語では“カプセル化”）により、クライアントは、リクエストがサーバによ ってどのように実行されるかを知る必要がない。ともかく、クライアントとサー バの両方が、両者間の通信を可能とする共通のインターフェイス定義にアクセス できなければならない。現在のところ、分散型オブジェクトコンピューティング 用の標準言語は、オブジェクト管理グループ（“ＯＭＧ”）のインターフェイス 定義言語（“ＩＤＬ”）である。 分散型オブジェクトシステムの開発者は、システムの使用可能インターフェ イスをIDLで定義する。インターフェイスは、該インターフェイスのオブジェク トについて実行できる１つ又はそれ以上のオペレーションを含む。各オペレーシ ョンは、１つ又はそれ以上のパラメータを受け取る。各パラメータは、特定のID Lデータ型である。 IDLは、いくつかのデータ型を含む。整数は、longおよびshortの、有符号お よび無符号整数データ型で表される。OMG IDL浮動小数点（floating point）型 には、float（浮動）型とdouble（倍）型がある。float型はIEEE単精度浮動小数 点数を表し、double型はIEEE倍精度浮動小数点数を表わす。OMD IDLは、８ビッ ト量で構成されるcharデータ型を定義する。ブール論理（boolean）データ型は 、真／偽の値を表示するのに使用する。“any（任意）”型は、任意のOMG IDL型 を表現できる値の指定を可能にする。構造体、共用体、テンプレートなどの混成 型を表わすのにも使われる。 IDLは、分散型オブジェクトシステムに使用されてOMGの共通オブジェクトリ クエストアーキテクチャ（ＣＯＲＢＡ：Common 0bject Request Broker Archite cture）を実行処理するよう設計されている。典型的なCORBAシステムにおいて、 インターフェイス定義は、IDL定義されたソースファイル（“翻訳ユニット”と も呼ばれる）に書き込まれている。ソースファイルは、これを特定の言語にマッ プするIDLコンパイラによってコンパイル（翻訳）される。IDLコンパイラは、ク ライアントスタブファイル、ヘッダファイルおよびサーバスケルトンファイルを 含むプログラミング言語別のファイルを生成する。次いでクライアントスタブフ ァイルがコンパイルされ、クライアントアプリケーションにリンクされてリクエ ストの作成に使用される。ヘッダファイルは、クライアントアプリケーションお よびサーバアプリケーションにリンクされ、データ型の定義に使用される。サー バスケルトンファイルは、サーバアプリケーションにリンクされ、オブジェクト （リクエスト）に関するクライアントオペレーションをサーバ処理系のメソッド にマップするのに使用される。 オブジェクト呼出しがあると、データ構造体は一方のコンピュータから他方 のコンピュータへ（クライアントからサーバへ、また、サーバからクライアント へ）移送される。このようなオブジェクト呼出しは、同一システム間でも起こる が、異なるオペレーティングシステム（OS）、プログラミング言語およびコンパ イラを使用する異種プラットフォーム間で発生しやすい。IDLソースファイルが コンパイルされて特定のプログラミング言語にマップされると、個々のコンパイ ラベンダがデータ構造体を特定の方法でスタックに整列（アライン）させる。従 って、クライアントとサーバの両システムがデータ構造体を異なる態様に整列さ せる場合がある。さらに、クライアントとサーバの両システムがパラメータを構 造体内で異なる態様に整列させる場合がある。クライアントアプリケーションと サーバアプリケーションが相手方の整列メソッドを理解しない場合、移送された データ構造体の混同が生じ、エラーが発生することになる。 さらに、クライアントとサーバとが使用するハードウエアが異なる場合があ る。例えば、一方のコンピュータが、最上位バイトが最初に列挙される“BIGend ian”と称する整数表現を必要とするCPUを含み、他方のコンピュータが、最下位 バイトが最初に列挙される“LITTLEendian”を必要とするCPUを含む場合がある 。これらの２つの装置間では、相互を知ることなしには、データ構造体を有効に やり取りすることはできない。 その上、クライアントとサーバが相互の詳しい知識を有している必要がある 場合、オブジェクト指向型コンピューティングの第一目標であるカプセル化が失 われてしまう。クライアントアプリケーションとサーバアプリケーションの両方 に詳細なアライメント関数を書き込んでオブジェクト呼出し時の互換性を確立し なければならない。この余分なコーディングワークが分散型オブジェクトコンピ ューティングを非効率的なものとしてしまう。 従って、IDL定義されたデータ構造体をプラットフォームから独立した書式 に変換し、変換されたデータ型が異種システム間で効果的に移送されるようにす る方法が望まれている。 更に、クライアントおよびサーバアプリケーションがオブジェクト呼出しを 処理するのに必要とされる実行時間およびコード量を減らす方法も望まれている 。 発明の要旨 本発明は、IDL定義されたデータ構造体をプラットフォームから独立した書 式に変換し、変換されたデータ型が異種システム間で効果的に移送されるように する方法に関するものである。クライアントおよびサーバアプリケーションがオ ブジェクト呼出しを処理するのに必要とされる実行時間およびコード量を減らす 要望も満足させられる。具体的には、両システムは、コンパクトIDL表記法（Ｃ ＩＮ：Compact IDL Notation）と称するASCII文字列書式で定義されたデータ構 造体の記述を有する。このCINは、データ構造体のオフセットとサイズに関する 追加情報を含む“準備CIN”書式に変換される。準備CINは、データ構造体を抽出 し、そのデータ構造体のサイズおよびオフセットに基づいてデータを出力バッフ ァに格納するために使用される。データは、アライメントパディングフィールド なしで出力バッファに高密にパックされる。前記出力バッファは、第２のシステ ムの入力バッファに移送される。該第２のコンピュータは、その入力バッファか らデータを抽出する。データは、次いで、前記データは、前記第２のコンピュー タの書式に変換され、前記準備CINに基づいてデータ構造体に並べ替えられる。 上記方法は、クライアントおよびサーバのシステムによる、処理系ライブラ リに対する呼出しを使用して実行される。処理系ライブラリは、実行時間ライブ ラリに位置する汎用関数を含む。汎用関数を呼び出すことにより、クライアント アプリケーションおよびサーバのアプリケーションは、相互の具体的知識無しで 、また、追加コードを必要とせずに、容易にオブジェクト呼出しをすることがで きる。 以下の好適実施例の詳細な説明を考察することにより、本技術分野に通じた 者は上記変換方法およびこれによって実現される追加の利点並びに目的を完全に 理解することができる。先ず簡単に説明する添付図面を参照する。 図面の簡単な説明 図１は、本発明の方法または装置を用いた分散型コンピューティング環境を 示す図である。 図２は、共通実行環境（CEE）の基本構造を示す図である。 図３は、従来のIDLソースファイルのコンパイルおよびリンクを示す図であ る。 図４は、本発明の方法を用いたIDLソースファイルのコンパイルおよびリン クを示す図である。 図５(a)および５(b)は、IDL定義されたデータ構造体、生成されたCIN記述お よび生成されたop_tag構造体アレイを示す図である。 図６は、本発明の方法に係るクライアント側の第１の好適実施例を説明する フローチャートである。 図７は、本発明の方法に係るサーバ側の第１の好適実施例を説明するフロー チャートである。 図８は、基本データ型および混成データ型のためのCIN記述子の生成を説明 するフローチャートである。 図９は、オペレーションのためのCIN記述子の生成を説明するフローチャー トである。 図１０は、インターフェイスのためのCIN記述子の生成を説明するフローチ ャートである。 図１１は、PIFデータ構造体を示す図である。 図１２は、エントリデータ構造体を示す図である。 図１３は、オペレーションデータ構造体を示す図である。 図１４は、共用体データ構造体を示す図である。 好適な実施の形態の詳細な説明I. ハードウエアの概要 以下、添付図面の図示例を参照して、本発明の好適な実施の形態を詳細に説 明する。添付図面において、同一または類似した構成要素には同一の参照番号を 付す。 図１に示すように、本発明の方法は、分散型（クライアント／サーバ）コン ピューティング環境１０に使用する設計になっている。当該クライアント／サー バシステムは、インターネット接続部またはローカルエリアネットワーク接続部 のようなネットワーク接続部１２によって接続されている。サーバコンピュータ １１は、バスまたはI／Oチャンネル２０を介して関連する格納サブシステム１３ と通信する。サーバシステム１１は、CPU１５と、プログラムの実行についての 現在状態情報を格納するためのメモリ１７とを具備している。メモリ１７の一部 は、クライアントコンピュータ上で現在実行されているプログラムの各関数に関 連した状態および変数の格納に専用される。同様に、クライアントコンピュータ ２１は、CPU２７と、これに関連するメモリ２３と、キーボードやマウスなどの 入力装置２９と、ビデオ表示端末（VDT）などの表示装置３３とを具備している 。該クライアントのCPUは、バスまたはI／Oチャンネル４０を介してディスク格 納サブシステム３３と通信し、また、I／Oチャンネル４１を介してキーボード２ ９、VDT３３およびマウス３１と通信する。上記の両コンピュータは、フロッピ ーディスクやCD-ROMを含む各種の記録媒体を読み取り可能である。 図１に示されるクライアント／サーバモデルは、典型的なクライアント／サ ーバシステムを単に例示するものである。本発明において、“クライアント”は 、サービスを要求するアプリケーションであり、“サーバ”は、その要求を実行 するアプリケーションである。実際上、上記クライアントアプリケーションおよ びサーバアプリケーションは、後述のように、同一のコンピュータおよび共通カ プセルに常駐してよい。上記クライアントアプリケーションおよびサーバアプリ ケーションは、異なるオペレーティングシステムを使用する異なるコンピュータ に常駐してもよい。 II. 分散型コンピューティング環境 本発明の方法および装置は、任意の分散型コンピューティング環境内で利用 可能である。好ましい実施の形態において、Tandem Message Switching Facilit y（MSF）アーキテクチャの一要素である共通実行環境（CEE）が使用される。こ のCEEは、オブジェクトを起動し、停止し、CEEカプセルにロードされたクライア ントアプリケーションとサーバアプリケーションとの間でメッセージをやり取り するのに使用される。該CEEは、単一マシンのメモリに格納してもよい。しかし 、該CEE、クライアントアプリケーションおよびサーバアプリケーションは、図 １に示すように、ネットワーク上の多数のマシンにロードしてもよい。クライア ント側のCEE７５は、クライアントメモリ２７に格納されている。また、サーバ 側のCEE８５は、サーバメモリ１７に格納されている。 上記CEEは、“カプセル”基本構造を使用する。カプセルは、メモリスペー スおよび実行ストリームをカプセル化する。カプセルは、オペレーティングシス テムに応じて、異なるシステム上で異なる態様で処理される。例えば、あるシス テム上で、カプセルはプロセスとして実行される。また、他のシステム上では、 カプセルはスレッド（thread）として実行される。さらに、クライアントアプリ ケーションおよびサーバアプリケーションは、図１に示すように異なるマシンに 含まれる異なるカプセル内に構築してもよい。代案として、異なるカプセルを図 ２のように構成してもよい。図２Aは、単一のカプセル８１にロードされたクラ イアントアプリケーション７７を示しており、サーバアプリケーション８７は別 のカプセル８５に格納すればよい。しかし、これら２つのアプリケーションは、 同一のマシン２１に格納されている。また、図２Bに示すように、上記クライア ントアプリケーションおよびサーバアプリケーションは、共に、同一のマシン２ １上の単一のカプセル８１にロードしてもよい。前述したように、本発明の方法 は、多数のカプセル、多数のマシンを使用する例に関連して説明する。従って、 クライアントマシン１２およびサーバマシン１１は、それぞれのメモリにロード されたクライアント側CEE７５およびサーバ側CEE８５を備えている。 図３は、例えば、CEE７５と、コアCEE構成要素のあるものを含むクライアン トコンピュータメモリ２７（ここでは図示せず）に含まれるCEEカプセル７０、 および、処理系ライブラリ７１内に含まれるオブジェクト処理系を示す。上記処 理系ライブラリ７１は、後述のように、クライアントアプリケーション７９（サ ーバカプセルの場合、サーバアプリケーション）およびオブジェクトのインター フェイスのIDL仕様書から生成されたクライアントスタブ７７（またはサーバス タブ）を含んでいる。上記処理系ライブラリ７１およびCEE７５は、該CEEによっ て供給される動的アクセス可能なルーチンのダウンコーリングおよび上記処理系 ライブラリに含まれるルーチンのアップコーリングによって、相互作用（インタ ラクト）する。また、CEE７５は、同じマシン内の他のカプセルからのオブジェ クト呼出し８２および他のCEEからのリクエスト８４を受け取ることができる。 クライアント側CEE７５およびサーバ側CEE８５は、任意の既知のネットワークプ ロトコルを使用して通信する。クライアントおよびサーバCEEは、クライアント およびサーバアプリケーションからダウンコール可能な数々のルーチンライブラ リを含む。表示変換ユーティリティ（ＰＣＵ：Presentation Conversion Utilit ies）８９は、この発明の方法に使用されるルーチンのライブラリである。 CEEカプセルにおいて実行されたオブジェクトは、構成設定されたものまた は動的なものとすれことができる。構成設定されたオブジェクトの処理系の詳細 は、（MSF Warehouse85のような）格納部または初期化スクリプトに格納されて いる。特定のオブジェクト参照に対するリクエストがあった場合、クライアント 側CEE７５は、この構成設定されたデータに基づいて適切なカプセルを始動する 。上記カプセルは、その構成設定されたデータを使用して、ロードすべき処理系 ライブラリおよび呼び出すべきオブジェクト初期化ルーチンを決定する。次いで 、上記オブジェクト初期化ルーチンがそのオブジェクトを作成する。動的オブジ ェクトは、同じカプセル内において動的に作成され、破棄される。該動的オブジ ェクトには、格納部に格納された、または、スクリプト化された構成設定情報が 無い。 次に、処理系ライブラリがCEE７５とどのように相互作用するか、システム レベルで説明する。CEE７５は、リクエストを実行してカプセル内のオブジェク トを起動し、停止する。さらに、上記CEEは、前述したように、カプセル間オブ ジェクト呼出し８２および他のCEE８４からのリクエストを用意にする。クライ アントアプリケーションまたはサーバのアプリケーションからのオブジェクト呼 出しを満足させなければならないとき、オブジェクト起動リクエストが発生する 。オブジェクトを起動するため、CEE７５は、そのオブジェクトのメソッドを包 含する適当な処理系ライブラリを（まだロードしていない場合）ロードし、次い で、構成設定されたオブジェクト初期化ルーチンを呼出しする。この初期化ルー チン は、処理系ライブラリがどのインターフェイスを支援するか指定し、後でCEEに 呼び出されるオブジェクトのメソッドのエントリ（入口点）を記憶する。 クライアントおよびサーバのシステムが始動すると、クライアント側とサー バ側の両CEEがそれぞれ自己の初期化を実行する。この初期化は、各種の処理系 ライブラリをどこで捜索すべきかをクライアントおよびサーバのCEEに伝える。C EEによって見つけられると、クライアントおよびサーバのアプリケーションの初 期化ルーチンが呼び出される。クライアントアプリケーションおよびサーバアプ リケーションに含まれるこの初期化ルーチンは、必要とされるアプリケーション に固有の初期化を先ず実行しなければならない。次に、クライアントおよびサー バの両初期化ルーチンがスタブ関数を呼出し、このスタブ関数が、CEE_INTERFAC E-CREATEと呼ばれる（上述のような動的ライブラリに含まれる）CEE関数をダウ ンコールして当該オブジェクトのインターフェイスを指定する。インターフェイ スはオブジェクト毎に指定すればよい。インターフェイス記述は、以下で説明す るように、通常はそのインターフェイスのIDL記述から生成される。CEE_INTERFA CE_CREATEは、インターフェイスを作成し、新規に作成されたインターフェイス に“インターフェイスハンドル”を返す。このハンドルは、該インターフェイス を指定する固有識別子である。次いで、サーバアプリケーション初期化ルーチン がインターフェイスハンドルを用いてCEE_IMPLEMENTATION_CREATEをダウンコー ルする。CEE_IMPLEMENTATION_CREATEは、１つまたはそれ以上のオブジェクトが 使用できる処理系記述を作成する。CEE_IMPLEMENTATION_CREATEは、インターフ ェイスの各オペレーションの処理系を指定する固有識別子である”処理系ハンド ル”を返す。最後に、サーバアプリケーション初期化ルーチンが処理系ハンドル を使用して、CEE_SET_METHODをダウンコールするスタブ関数を呼び出す。CEE_SE T_METHODは、サーバアプリケーションに含まれる処理系の特定のメソッドルーチ ンの実アドレスを指定する。これでCEEは、クライアントアプリケーションのオ ブジェクト呼出しをサーバアプリケーションの特定メソッドに接続するのに十分 な情報を有する。 III. IDL ソースファイルのコンパイルおよびリンク 図４は、IDLソースファイルが、コンパイルされ、本発明の方法および装置 を使用するクライアントアプリケーションおおびサーバアプリケーションにリン クされる手順を示す。先ず、IDLインターフェイス定義を含むIDLソースファイル １０１が作成される。IDLコンパイラ１０３は、IDLソースファイル１０１をコン パイルする。IDLコンパイラ１０３は、コード１０１を解析して中間のPickled I DL file（PIF）ファイル１０５を生成し、オリジナルソースファイルを格納する 。次にコードジェネレータ１１１がPIFファイルを解析する。PIFファイルの生成 は以下のセクションVIで説明する。好ましくは、IDLコンパイラとコードジェネ レータ１１１は、コードを生成するため組み合わされる。コードジェネレータ１ １１は、クライアントアプリケーションおよびサーバアプリケーションの言語で フアイルを生成する。クライアントアプリケーションとサーバアプリケーション の言語が異なる場合、異なるコードジェネレータが使用される。代案として、コ ードジェネレータ１１１およびIDLコンパイラ１０３を単一アプリケーションに 合体させて言語に固有のコードを生成するようにしてもよい。コードジェネレー タ１１１は、クライアントスタブ関数を含むクライアントスタブファイル７７と 、オブジェクト処理系についての定義を含むサーバスタブファイル８７を生成す る。クライアントスタブファイル７７およびサーバスタブファイル８７は、プロ グラミング言語に固有のコンパイラ１２１、１２３でコンパイルされて、コンパ イルされたクライアントスタブオブジェクトコードおよびコンパイルされたサー バスタブオブジェクトコードを生成する。同様に、クライアントアプリケーショ ン７９およびサーバアプリケーション８９は、プログラミング言語に固有のコン パイラでコンパイルされて、コンパイルされたクライアントアプリケーションオ ブジェクトコードおよびコンパイルされたサーバアプリケーションオブジェクト コードを生成する。クライアントアプリケーション７９およびサーバアプリケー ション８９は、コードジェネレータ１１１によって生成されたヘッダファイル１ １９をさらに含む。このヘッダファイル１１９は、共通の定義および宣言を含む 。最後に、言語コンパイラ１２１が、上記クライアントアプリケーションオブジ ェクトコードとクライアントスタブオブジェクトコードをリンクすることにより 、処理系ライブラリ７１を生成する。同様に、第２のコンパイラが、上記サーバ アプ リケーションオブジェクトコードとサーバスタブオブジェクトコードとをリンク することにより、処理系ライブラリ８１を生成する。 さらに、ヘッダファイル１１９，クライアントスタブファイル１１５および サーバスタブファイル１１７は、コンパクトIDL表記法（“ＣＩＮ”）と称する 各IDL定義データ構造体のコンパクト版を含む。CINは、特別な表記法を使用する IDLデータ構造体のASCII（または他の文字に基づく）表現である。CIN記述子は 、クライアントアプリケーション１２３とサーバアプリケーション１２３の両方 に含まれるヘッダファイル１１９に含まれている。この記述子はクライアントと サーバのスタブファイルにも含まれている。クライアントアプリケーションおよ びサーバアプリケーション１２１，１２３がCINにアクセスできるので、PCUライ ブラリ１３０によって提供された汎用関数を異種通信者間で使用することができ る。コードジェネレータによるCINの作成については以下のセクションＶで説明 する。 IV.データ構造体の移送 ここで本発明の方法を説明する。本発明の方法および装置は、ランタイムに クライアントアプリケーションおよびサーバアプリケーションが利用可能な汎用 関数またはルーチン群１３０を用いて実行される。これらのルーチンは、IDLに 初めから記述されているデータ構造体と共に使用することを意図したものである 。主ルーチンは、PCU_PREPARE、PCU_PACKおよびPCU_UNPACKである。 IDLソースファイルは、各種のデータ構造体のための数々の型定義を含んで いてよい。ソースファイルがコンパイルされてクライアントアプリケーションお よびサーバアプリケーションにリンクされると、クライアントアプリケーション およびサーバアプリケーションがデータ構造体を使用してオブジェクト呼出しを 実行する。クライアントアプリケーションは、特定のデータ構造体に含まれたデ ータを使って任意のオブジェクトについてオペレーションを実行することをリク エストしてよい。このデータ構造体に含まれるデータは、オブジェクト呼出し時 にサーバアプリケーションに移送される。サーバアプリケーションは、オブジェ クトについてのオペレーションを効果的に実行するためデータ構造体中のデータ を適切に整列させなければならない。 本発明の方法は、異種システム間でのIDL定義されたデータ構造体の移送を 容易にする。図５ａは、IDLで書かれたデータ構造体５０１の一例を示す。IDLで 書かれた構造体“MyStruct”は、３つの構成要素、即ち、charデータ型構成要素 と、long（長）データ型構成要素と、boolean（ブール）データ型構成要素を含 む。この型定義は、インターフェイス定義と共に、例えばIDLソースファイル１ ０１に含まれる。 コードジェネレータは、IDLソースファイルを解析し、CIN記述５０２を含む ヘッダファイルを生成する。CIN記述子は、（構造体名などの）識別子を使わず に構造体を簡潔に記述する一連のASCII文字を含む。ｂ3文字は、データ構造体を 、３つの要素を含むIDL struct型として識別する。Cは、IDL char型を示す。F文 字は、IDL long型を識別し、B文字は、ブールデータ型を識別する。 PCU_PREPAREは、一定のデータ型のCIN記述を、CIN記述よりもランタイムに 使いやすい“準備CIN”形式に変換する。ルーチンPCU_PACKおよびPCU_UNPACKの 使用に先立って、コードジェネレータ１１１によって生成された、ヘッダファイ ル１１９に含まれる各データ構造体のCIN記述を“準備”しなければならない。P CU_PREPAREがクライアントとサーバの双方から呼び出される。この呼び出しには 費用が比較的かかるので、初期化時のPCU_PREPAREに対する一回の呼び出しによ り、貴重なシステム資源をセーブすることができる。上記呼び出しは、好ましく は、クライアントアプリケーションおよびサーバアプリケーションの初期化ルー チン時に行われる。PCU_PREPAREは、Ｃ言語において次のように定義される。この関数において、cinbufは、上記データ構造体のCIN記述を含むバッファに対 するポインタである。パラメータcinlenは、CINのサイズである。PCU_PREPAREは 、 prepbufが指すアドレスに格納された”準備CIN”を戻す。prepbufの最大長を指 定するため、prepbufmaxlenを特定の値に設定する。また、この関数は、prepbuf に含まれる準備CINのサイズを指定するprepbuf_lenを戻す。NULL値は、この値が 必要とされない場合、上記パラメータとして送られる。cinbufから読み出された 実際のバイト数はパラメータ^*cin_usedにて戻される。^*cin_usedが必要とされな い場合は、NULLもこのパラメータとして使用してもよい。 PCU_PREPAREを使用して、CIN記述データ構造体のアラインメント、サイズ、 オフセット、データ型を記述するop_tagデータ構造体のテーブルである準備CIN を作成する。PCU_PREPAREは、PCU_PREPAREでその各内部関数に対してコンテキス トを送るのに使用するctxデータ構造体を最初に作成することにより、それらのo p_tagを作成する。ctx構造体を使用することは、個々のパラメータを各種の内部 関数に送ることより望ましい。ctx構造体はC言語で次のように定義される。前記ctx構造体のフィールドは次のとおりである。上記opポインタは、準備CIN内 の現在のオペレーションを指す。このポインタは、PCU_PREPAREが各CINアイテム （後述）を解析するときに増分される。前記op_endポインタは、準備CIN＋１に おける最後のオペレーションを指す。cinptrポインタは、準備中の全CIN文字列 から読み込まれる次のバイトを指示する。cinendポインタは、準備中のCIN文字 列の最終バイト＋１を指示する。このctx構造体のoffset、alignおよびsizeフィ ールドは、CIN記述データ構造体における処理済フィールドのオフセット、必要 なアラインメント（境界整列）およびサイズを指定するprocess_cin_item（後述 ）の出力パラメータである。処理済みCIN文字列において遭遇する無限シーケン ス（unbounded sequences）および文字列（string）の個数のランニングカウン トはnr_unboundedに含まれている。IDL“any”データ型を使用するフィールドの ランニングカウントは、nr_anysフィールドに含まれている。フィールドprev_br anchは、前に処理された共用体ブランチ（union branch）オペレーションを指示 する。このフィールドのリストは、ヘッドが主共用体オペレーションに含まれる ブランチオペレーションのリストの構築に使用される。共用体オペレーションは main_unionによって指示される。 ctx構造体が作成されると、PCU_PREPAREは、CIN文字列中の各文字ごとにPRO CESS_CIN_ITEM、CIN文字列の各符号付きlong整数に対するTAKE_LONGおよびCIN文 字列の各無符号long整数に対するTAKE_ULONGを呼び出す。PROCESS_CIN_ITEMは、 CIN文字列の単一のアイテムを処理する。ctx構造体はPROCESS_CIN_ITEMに渡され る。PROCESS_CIN_ITEMは多くの形態で実行可能である。好ましくは、当該関数は 、CIN文字列の各文字ごとに“case”を含むＣ言語“switch”文を使用する。さ らに、case文を使用して自分自身を巡回的に呼び出し、struct型のシーケンスま たは複数の共用体からなる共用体などの複雑な構造体を処理してもよい。 TAKE_LONGおよびTAKE_ULONGは、数字（アレイの次元数等）が後続する特定 のデータ型と共に使用される。TAKE_LONGは、CINバッファから１つの符号付きlo ng整数を抜き出し、その値をPCU_PREPAREに戻す。TAKE_ULONGは、CINバッファか ら１つの符号無しlong整数を抜き出し、その値をPCU_PREPAREに戻す。これらの 値は、PCU_PREPAREがop_tagデータ構造体のテーブルを作成するのに使用される 。 各呼出し毎に、PROCESS_CIN_ITEMはctxデータ構造体を変更する。先ず、PRO CESS_CIN_ITEMがopポインタを増分して上記構造体の他のフィールドを適正CINア イテムに対応させる。さらに、ctx構造体のsize、alignおよびoffsetフィールド が変更される。各データ型のためのアラインメントは、以下のアラインメント規 則に基づいて決定される。基本データ型がそのサイズに合わされる。従って、so rtデータ型は２バイトのアラインメントを有し、long型は４バイトアラインメン トを有し、等々である。struct型および共用体型は、最高アラインメント要求付 きの包含フィールドと同じアラインメントを有する。ともかく、struct型および 共用体型は、好ましくは、少なくとも２バイトのアラインメント要求を有する。 最後に、struct型および共用体型は、好ましくは、多数のアラインメント要求に 埋め込まれる。 PROCESS_CIN_ITEMへの呼出しが戻るたびに、PCU_PREPAREは変更されたctx構 造体に基づいてop_tagデータ構造体を作成する。次いで、これらのop_tag構造体 のアレイが、PCU_PREPAREの呼出し後に、準備CINバッファであるprepbufに格納 される。このop_tag構造体は、他の関数によって簡単に操作できる線形構造体で ある。構造体op_tagは、以下のように定義される。 type（型）パラメータは、上記データ構造体のIDLデータ型を表す。type_def 型定義は、考えられる全データ型を列挙するものである。パラメータoffsetは、 そのデータ構造体がある構造体または共用体の一部である場合、包含する構造体 または共用体の始端からの該構成要素データ型のオフセットである。データ型（ １、２、３、４または８バイト）が要求するアラインメントは、alignパラメー タによって指定される。sizeパラメータは、丸めを含むバイトでデータ構造体の サイズを示す。nr_elementsパラメータは、様々異なる目的に使用される。アレ イについて、このパラメータは、全次元の要素の総数を示す。シーケンスについ て、上記パラメータは、最大出現回数を示す。文字列について、上記パラメータ は、ゼロ終了を除く最大サイズを指定する。構造体について、上記パラメータは 、その構造体中の主フィールドの数を示す。共用体については、上記パラメータ は、共用体中のフィールド数を示す。パラメータbranch_labelおよびis_default _branchは、共用体ブランチのみのためのものである。branch_labelパラメータ は、上記共用体のIDL仕様において指定されたcaseラベル値を含み、is_default_ branchパラメータは、エントリが既定共用体ブランチを記述する場合、真（true ）である。is_slmpleパラメータは、データ構造体がIDL基本データ型の場合は真 で、該データ構造体が混成型の場合は偽（false）のブール論理である。^*next_b ranchパラメータは、共用体および共用体ブランチに使用され、該共用体に属す る次のブランチエントリのアドレスを指示する。共用体エントリの場合、上記パ ラメータは、第１のブランチを指す。最後のブランチの場合、上記パラメータは 値NULLを含む。^*union_endパラメータは、最後のブランチの結論に続く次のエン トリのアドレスを指示する。^*sequence_endパラメータは、シーケンスにのみ使 用され、シーケンス型（sequnced type）に続く次エントリのアドレスを指し示 す。^*default_branchパラメータは、デフォルトのブランチエントリのアドレス を指示する。これは、ブランチリストのどのブランチも共用体識別子と一致しな い場合に使用される。デフォルトがない場合、default_branchの値はNULLである 。パラメータreserve_XXXは、準備CINのサイズを誤推定する既存プログラムにお いてエラーを起こすことなくop_tag構造体にフィールドを追加することを可能に する。 図５ｂは、CIN文字列５０２のための生成op_tag構造体アレイを示す。第１ の構造体５２０は、MyStruct構造体の型、オフセット、サイズ、アラインメント およびメンバの個数を指定する。次の３つのop_tag構造体５３０、５４０、５５ ０は、上記MyStruct構造体の各フィールドごとの型、オフセット、サイズおよび アラインメントを含む。この構造体アレイは、構造化データをファイルまたはネ ットワークに送るのにPCU_PACKおよびPCU_UNPACKが使用するバッファprepbufに 格納されている。 上記データ構造体が“準備”され、op_tag構造体アレイがprepbufに格納さ れると、そのデータ構造体に格納された各種のメッセージをバッファに詰め込み 、PCU_PACKを用いて移送することができる。PCU_PACKは、構造化データ型をファ イルまたはネットワークに移送する間に出力バッファにコピーするのに使用され る。PCU_PACKは、共用体を含む全IDL構成要素、無限シーケンス／文字列および “任意”型を支援する。 PCU_PACKは、指定された書式に基づいて構造化データ型の構成要素を出力バ ッファに格納する。PCU_PACKは、Ｃ言語で次のように定義される。 最初の３つのパラメータは、出力バッファへのデータの詰め込み方を指定する。 これらのパラメータは、コーラ（呼出し側）によって提供された変換を実行する ための呼出側定義関数でよい。第１のパラメータdst_integer_fmtは、出力バッ ファにおいてshort型、long型およびlongデータ型に使用する書式を指定する。 この書式に関して可能な値の例は、バイト重要度がアドレスの増加につれて減少 する場合の整数表現を指定するPCU_INTEGER_BIGENDIAN、又は、バイト重要度が アドレスの増加につれて増加する場合の整数表現を指定するPCU_INTEGER_LITTLE ENDIANである。パラメータdst_real_fmtは、出力バッファでフロートおよび倍デ ータ型に使用する書式を指定する。このパラメータのサンプル値は、例えばTand em T16書式を使用する浮動小数点数表現を指定するPCU_REAL_T16などの、標準IE EE書式またはベンダ指定値を使用する浮動小数点数表現を指定するPCU_REAL_IEE Eである。第３のパラメータdst_char_fmtは、出力バッファでchar型および文字 列型に使用する書式を指定する。このパラメータの１つの可能値は、ISOラテン −1書式（Latin-1 format）、ASCIIのスーパーセットを使用する文字表現である 。もう１つの可能な値はIBMホストと互換性のあるEBCDICである。 上述の^*prepbufパラメータは、PCU_PREPAREによって戻された準備CIN記述を 含むアドレスを指示するポインタである。^*inbufパラメータは、出力バッファに 格納される構造化データのアドレスを指示するポインタである。^*outbufパラメ ータは、実際のパックされたデータを受け取る出力バッファのアドレスを指示す るポインタである。outbufに収容可能なバイトの最大数はoutbuf_max_lenパラメ ータに含まれている。実際にoutbufに書き込まれるバイト数は、outbuf_lenパラ メータによって戻される。バイト数が必要でない場合、NULLの値は、このパラメ ータとして渡せばよい。PCU_SHORTOUTBUFが上記関数によって戻された場合、out buf_lenパラメータは必要なoutbufサイズを取得する。 従って、出力バッファにメモリを動的に割り当てるため、クライアントアプ リケーションは、PCU_PACKを２回呼び出すことができる。最初の呼出しで、outb uf_max_lenが設定される。次いでPCU_PACKがPCU_SHORTBUFを戻し、outbuf_lenが 必要な出力バッファサイズを含むこととなる。ここで出力バッファの正しいメモ リ量をPCU_PACKの２回目の呼出に先立って割り当てることができる。 PCU_PACKは最初にctx構造体を生成する。このctx構造体は、PROCESS_CIN_IT EMによって使用されるコンテキスト構造体と同様の関数を提供する。上記構造体 は、大量のコンテキストがPCU_PACKと、PCU_PACK_ENGINEによって呼び出される 低水準ルーチンとの間で共用されることを可能にする。上記ctx構造体は、PCU_P ACKに対する下位関数によって使用され、次のように定義される。 PCU_PACKへの呼出しに指定されたリクエストされたあて先書式はctx構造体に渡 される。これら３つのフィールドはIDL“任意”型を処理するためPCU_PACKを巡 回的に呼び出さなければならない場合に必要になる。outptrポインタは、出力バ ッファに書き込まれる次のバイトを指示する。出力バッファが満杯であってもこ のポインタは継続して更新される。これにより、オーバーフローの場合に正しい サイズをコーラに戻すことが可能となる。かくしてコーラは出力バッファのサイ ズを調整可能となる。ポインタoutbuf_endは、出力バッファの最終バイト＋１を 指し示す。 PCU_PACKは、内部関数PCU_PACK_ENGINEを呼び出す。PCU_PACK_ENGINEは、出 力バッファへのデータの実際の詰め込みを実行する低水準関数を指示するポイン タを受け取る。PCU_PACKは、さらに、prepbufを指示するポインタと、パックさ れるデータ（inbufに含まれる）を指示するポインタと、PCU_PACKによって生成 されたctxを示すポインタを受け取る。PCU_PACK_ENGINEは、prepbufバッファ内 を要素単位で進み、（op_tag構造体に含まれる型によって指定されるような）当 該要素のtypeに基づき、また、PCU_PACKを指示するdst_XXX_fmtパラメータに基 づき、その要素の適当な低水準関数を呼び出す。PCU_PACK_ENGINEは、構造化デ ータ、（CIN文字による）データ型、ctx構造体アドレスおよび（op_tag構造体の sizeフィールドによって指定されるような）出力バッファに詰め込む入力バッフ ァのデータのサイズを含む入力バッファにアドレスを提供する。 PCU_PACK_ENGINEは、op_tagデータ構造体に含まれるデータ型およびPCU_PAC Kへの呼出し時に指定された変換に基づいて適正な低水準関数を呼び出す。この 低水準関数はデータを透明的（不可視的）にパックするか、指定された変換を実 行する公知の低水準関数である（例えば、LITTLEendianに対するBIGendian）。 各コーラ供給関数は、入力バッファからデータを取り出し、このデータを出力バ ッファ内に格納する。入力バッファから取り出されるバイトの数は、PCU_PACK_E NGINEから上記関数に提供されたサイズパラメータによって指定される。上記デ ータが出力バッファに配置されると、上記低水準関数がctx構造体のoutptrを変 更し、出力バッファに書き込まれた最後バイトの次のバイトを指示する。 PCU_PACK_ENGINEは、上記の各種の低水準関数を用いてデータを出力バッフ ァに次のように格納する。入力バッファ中の構造化データ型は、最初にIDLで定 義されたのと同じ順序で出力バッファに密に（バイト調整して）格納される。正 しいアラインメントを実現するためコードジェネレータによって挿入された任意 のパディングフィールドの内容は捨てられる。同様に、上記関数はデフォルト値 を上記フィールドに配置しない。 基本型データ構造体は、PCU_PACKへの呼出し時にdst_XXX_fmtパラメータに よって指定された表現で出力バッファに格納される。典型的に、これらのパラメ ータは、無変換でパッカー（packer）の固有書式に設定される。従って、サーバ アプリケーション（アンパッカー）が現実の変換を行うことになる。しかし、本 発明で使用するルーチンは、データ構造体の変換の実行をも許容する。 short、符号なしshort、long、符号なしlong、long longsおよび符号なしlo ng longsの表現は、PCU_PACKに対するdst_real_fmtにおいて指定されている。こ のパラメータは、浮動小数点数字を表す書式を指定する。浮動型と倍（double） 型のアラインメントは、dst_real_fmtパラメータによって指定される。このパラ メータは、整数を表現する書式に対応する。charsの表現はdst_char_fmtパラメ ータによって指定される。このdst_char_fmtパラメータは、文字を表現する書式 を指定する。ブール論理およびオクテット（octets）は再アラインしない。上記 “任意”型は、（アラインメントがdst_integer_fmtパラメータに基づいている ）CIN記述の長さを指定する符号なしlong、型を記述するCIN文字列（未変換ASCI I文字列）および（この変換規則に基づいて格納された）データ自体として格納 される。 アレイ、共用体などの混成型も再アラインされる。アレイは要素間にパディ ングなしで格納される。シーケンスは、上記出現回数の前の出現回数を示す符号 なしlong整数として格納される。出現間のパディングは除去される。long整数の 書式は、上述のdst_lnteger_fmtパラメータによる。文字列は、charsとして格納 された特定数の文字前の文字列長を示す符号なしlongとして格納される。charの 書式は、dst_char_fmtパラメータによって決定される。構造体はパディングなし でフィールド毎に格納される。共用体は活性共用体ブランチが続くlong型として 格納される。 受け取り側において、サーバアプリケーションは、PC_UPACKを使用してパッ クされたバッファから未構造化データ型およびその付属物を抽出しなければなら ない。次いでPCU_UNPACKが、その未構造化データを、任意のデータ構造体の準備 CINに基づいてそのデータ構造体に格納する。PCU_UNPACKは次のように定義され る。 最初の３つのパラメータは、PCU_UNPACKの最初の３つのパラメータに対応す る。これらのパラメータは、入力バッファに格納されたデータ型の書式を指定す る。これらのパラメータは、好ましくは、そのPCU_PACK版と同一である。上記^*p repbufパラメータは、PCU_PREPAREによって戻された準備CIN記述を含むアドレス を示すポインタである。入力バッファのアドレスは^*inbufが指示する。inbufの 長さはinbu_lenによって指定される。出力バッファのアドレスは^*outbufによっ て指示される。outbufによって収容されるバイト最大数はoutbuf_max_lenによっ て指定される。パラメータ^*outbuf_lenは、outbufに実際に書き込まれたバイト 数を取得する。入力バッファから読み出されたバイト数は^*inbuf_usedによって 指定される。書き込みバイト数または読み出しバイト数が必要でない場合、これ らのパラメータの値としてNULLを渡せばよい。 PCU_UNPACKは、PCU_PACKの内部関数にコンテキストを渡すのに使用するctx 構造体を生成する。このctx構造体は、PCU_UNPACKの下位関数によって使用され 、次のように定義される。 最初の３つのパラメータは、PCU_UNPACKに渡された書式である。これらのパラメ ータは、IDL“任意”型を処理するためPCU_PACKが巡回的に呼び出される場合に 内部関数によって必要とされる。上記inptrは、入力バッファから読み出される 次のバイトを指す。上記inbuf_endポインタは、入力バッファにおける最終バイ ト＋１を指す。 コンテキスト構造体の生成後、PCU_UNPACKは、PCU_UNPACKに機能性を提供す るPCU_UNPACK_ENGINEを呼び出す。PCU_UNPACK_ENGINEは、入力バッファ（PCU_PA CKによって提供された出力バッファ）からデータを抽出し、そのデータを出力バ ッファに配置するためのコーラ供給関数へのポインタを受け取る。準備CINバッ ファもパラメータとして提供される。PCU_UNPACK_ENGINEは、準備CIN内を要素毎 に進行して、op_tag構造体offsetおよびsizeフィールドによって指定された一定 のデータ構造体中に当該データを格納する。 準備CINバッファの各要素に対し、PCU_UNPACK_ENGINEはアンパックおよび変 換を実行するため適当な低水準のユーザ定義関数を呼び出す。PCU_PACK_ENGINE は、入力バッファから読み出されるデータのデータ型およびサイズを、該データ を書くための出力バッファのアドレスと共に送る。また、PCU_UNPACK_ENGINEは 上記関数の各々にctxデータ構造体を渡す。各コーラ定義関数が次いで入力バッ ファからデータを抽出してそのデータを別のデータ構造体に格納する。入力バッ ファから出力バッファに書き込まれるバイト数は、サイズパラメータによって決 定される。混成型については、PCU_UNPACK_ENGINEは、コーラ供給関数に追加の パラメータを供給する。データ構造体がアレイである場合、そのアレイの要素数 が提供される。データ構造体がシーケンスである場合、PCU_UNPACK_ENGINEは要 素の実際の数とともにそのシーケンスの要素最大数を提供する。データ構造体が 文字列である場合、その文字列の最大サイズおよび実サイズがコーラ供給関数に 提供される。混成型がstructデータ型である場合、その構造体のメンバ数が提供 される。 次に図６および図７を参照して本発明の方法を説明する。図６は本発明の方 法のクライアント側のフローチャートである。本発明の方法の実行に先立って、 データ構造体のコンパクト記述がコードジェネレータ１１１によって生成され、 クライアントスタブおよびサーバスタブに含められる。この記述は、アプリケー ションXXXに記述されたメソッドを使用して生成することができる。クライアン トスタブおよびサーバスタブはコンパイルされてクライアントアプリケーション およびサーバアプリケーションにリンクされる。第１のステップ６０１において 、クライアントスタブがクライアントアプリケーションにリンクされると、クラ イアントアプリケーションは関数PCU_PREPAREを呼び出すことにより準備CIN記述 を生成する。PCU_PREPAREは、データ構造体のCIN記述を取り出し、ステップ６０ ３において、そのCIN記述の各要素のためのPROCESS_CIN_ITEMを呼び出すことに よってCINをop_tagデータ構造体のアレイに変換する。各構造体は、CIN記述デー タ構造体の型、オフセット、アラインメントおよびサイズに関する情報を含有す る。次いでこれらの構造体のテーブルが、ステップ６０５においてprepbufと呼 ばれるメモリバッファに記憶される。 ステップ６０７において、クライアントアプリケーションは、各op_tagのサ イズフィールドによって指定されたサイズに基づいて当該データを出力バッファ にコピーすることによってデータ構造体をパックするPCU_PACKを呼び出す。PCU_ PACKは、データ構造体からアラインメントパディングフィールドを除去し、ステ ップ６０９においてそのデータ構造体を出力バッファに送り込む。データ構造体 が出力バッファに詰め込まれると、当該データがステップ６１１で移送される。 上記データ構造体はワイヤを通してサーバアプリケーションまたはディスクファ イルなどのファイルに移送すればよい。同じデータ構造体を伴う別のリクエスト がなされた場合、このリクエストはパックされ、クライアントアプリケーション がその新規リクエストのためステップ６０５〜６１１を繰返す。上記データ構造 体のCIN記述は再度“準備”する必要はない。 図７は本発明の方法のサーバ側を示す。ステップ７０１において、サーバア プリケーションは、CINの準備記述を取得するためPCU_PREPAREを呼び出す。この “準備”ステップは、上述のステップ６０１に類似する。次にサーバが、ステッ プ７０３において、PCU_PACKを使用してパックされたバッファから構造化データ 型およびその付属物を抽出するためPCU_UNPACKを呼び出す。ステップ７０５にお いて、上記構造体は上記関数に渡されたパラメータ（PCU_PACK関数に渡されたパ ラメータと同じ）に基づいてアンパックされる。データ構造体の抽出時に、上記 構造体はステップ７０７でサーバの入力バッファで指定された書式からサーバの 固有のアラインメントに再調整される。別のリクエストがサーバに到着すれば、 サーバはデータ構造体を準備することなくそのリクエストをアンパックするため PCU-UNPACKを呼び出すことができる。 Ｖ． コンパクトIDL表記法 図８は、ＩＤＬソースファイルに含まれるＩＤＬデータ型、オペレーションお よびインターフェースからのＣＩＮ記述子生成を示すフローチャートである。な お、図８〜図１０のステップは、メモリに格納されたコンピュータ命令を実行す るデータ処理システムのＣＰＵによって実行されるものである。ステップ８０１ において、コードジェネレータは、前記ＩＤＬソースファイルの最初の行から開 始し、該ＩＤＬソースファイルに記述されたデータ構造体、インターフェースま たはオペレーションを確認する。前記記述されたデータ構造体がインターフェー スである場合、前記コードジェネレータは、図１０に示された方向に従って処理 する。前記記述されたデータ構造体がインターフェース内のオペレーションであ る場合、前記コードジェネレータは、図９に示された方向に従って処理する。前 記記述されたデータ構造体がデータ型（または、後述するようなオペレーション のためのパラメータ）である場合、前記ジェネレータは、定義テーブルに基づい て１つの文字を生成する。なお、ここに含まれるチャートに示したもの以外の文 字が使用されてもよい。各チャートは、好ましいＡＳＣＩＩ文字のみを含んでい る。チャートＡは、様々なＩＤＬ基本型を示すために使用される文字列を含む好 ましい定義テーブルを示すものである。 チャートＡ このチャートＡに示すように、ＣＩＮ記述子における基本型を表現するために簡 単な文字列が使用される。 データ型がアレイまたは構造体（struct型）のような混成型である場合、一連 の異なるステップが行われる。ステップ８１１では、前記混成型のスタートを示 す文字が生成される。チャートＢは、様々なＩＤＬ混成型のスタートを示すため に使用される文字列を含むサンプルテーブルを示す。 チャートＢ 各混成型の具体的な表現は、その型に応じて異なる方法で取り扱われる。 ＩＤＬは、各基本型ごとに多次元で固定サイズのアレイを定義する。前記アレ イのサイズは、コンパイル時に決定される。アレイはＣＩＮにより次のように表 現される。 前記アレイのための文字の生成は、ステップ８１３，８１５，８１７に示されて いる。このアレイ表現において、上記文字ａは（チャートＢに示すように）前記 アレイのスタートを示している。文字nr_dimensionsは、該アレイにおける次元 の数を示す数字である。また、文字size_1，size_2，size_nは、それぞれ、前記 アレイの一次元、二次元およびｎ次元におけるサイズを示す。base_typeは、前 記アレイの各アレイ要素ごとの記述子である。様々な基本型の表現は、チャート Ａに示されたオリジナルの基本型テーブルから導出される。 ＩＤＬは、ユーザによって定義された構造体型を定義する。各構造体は、基本 データ型または混成データ型の１つまたは複数のフィールドで構成される。構造 体はＣＩＮにより次のように表現される。 １つの構造体を記述する文字の生成は、ステップ８１９およびステップ８２１に 示されている。チャートＢに示すように、上記文字ｂは前記構造体（struct）の スタートを示している。数字nr_fieldsは、前記構造体におけるフィールドの数 を示す。前記構造体におけるフィールドは、field_1，field＿2,field_nによっ て記述される。各フィールドは基本型または混成型である。前記構造体の基本型 フィールドは、チャートＡに示されているように記述される。混成型はここに示 されているように記述される（すなわち、アレイは、次元の数および各次元のサ イズ、スタート文字ａ等で記述される）。 ＩＤＬは、データ型のシーケンスを定義する。１つのシーケンスは、２つの特 性、すなわち、（コンパイル時に決定される）最大サイズと（実行時に決定され る）長さとを有する１次元のアレイである。シーケンスは次のように表現される 。 前記シーケンスのための文字の生成は、ステップ８２３，８２５に示されている 。この表現において、上記文字ｃは、チャートＢに示すように、前記シーケンス のスタートを示している。文字nr_occurrencesは、該シーケンスにデータ型の出 現回数を示す。該出現回数の後には、前記シーケンスにおけるデータ型出現ごと の実際の記述子base_typeが続く。データ型が基本型である場合、チャートＡの 適当な記述子が使用される。前記シーケンスが混成型である場合、記述子はここ に説明されているように作成される。シーケンスのシーケンスも可能である。 ＩＤＬは、空（null）文字を除くすべての８ビットの量（quantity）で構成さ れる文字列型を定義する。１つの文字列は、charのシーケンスに類似している。 文字列はＣＩＮにより次のように表現される。 文字列のスタートは文字ｄで示される。該文字列のサイズは、ステップ８２７で 生成される文字sizeによって示される。 ＩＤＬにおいて、共用体（union）は、Ｃプログラミング言語の“共用体”と Ｃ“switch”文との間の交配体である。換言すれば、共用体シンタクスは、共用 体ブランチを示す“case”ラベルと共に“switch”文を含むものである。ＩＤＬ 共用体は区別されなければならない。すなわち、共用体のヘッダは、現在の呼出 しインスタンスにどの共用体要素を使用すべきかを決定する型別タグフィールド を指定しなければならない。共用体および共用体ブランチは、ＣＩＮにより次の ように表現される。 共用体および共用体ブランチを示す文字の生成は、ステップ８２９，８３１，８ ３３，８３５に示されている。この表現において、ｅは共用体のスタートを示し 、ｆは該共用体内の共用体ブランチのスタートを示す。該共用体におけるフィー ルドの数は、文字nr_fieldsによって明示される。各フィールドのcaseラベル値 は、文字label_1によって示される。フィールドがデフォルトである場合、前記 ラベルは省略される。次に、各フィールドごとの記述子field_1がくる。前記共 用体のフィールドは、基本型または混成型のいずれであってもよい。従って、基 本型のフィールド記述子は、チャートＡに基づいて生成されてよい。混成型はこ こに説明されているように生成される。 基本型および混成型の記述から分かるように、ＣＩＮ記述は前記オリジナルの ＩＤＬソースファイルに含まれる識別子を含まず、汎用関数が生成される。従っ て、最も複雑なデータ構造であっても、文字列フォーマットで容易に表現され得 る。下記のものは元々ＩＤＬで記述されたサンプル構造体である。 この発明の方法を使用することにより、上記のデータ構造はＣＩＮにより次の ように表現される。 好ましい実施の形態において、正の数字の後には正符号（“＋”）が付けられて おり、負の数字の後には負符号（“−”）が付けられている。負の数は頻繁には 現れないが、負の数の使用は、例えば共用体のcaseラベルのようなデータ型に必 要となる（すなわち、case識別子は負の数であることがある）。上に示したＣＩ Ｎ記述子について以下に説明する。データ構造は最大の１００固の要素（１００ ＋）を有する１つのシーケンス（ｃ）で構成され、各前記要素は２個のフィール ド（２＋）を有する１つの共用体（ｅ）で構成されている。識別子がゼロ（偽） （ｆ０＋）である場合、１つの変形体は２個のフィールド（２）を含む構造体（ ｂ）である。１番目のフィールドは符号付きのlong（Ｆ）である。２番目のフィ ールドは符号付きのlong（Ｆ）である。識別子が１（真）（ｆ１＋）である場合 、第２の変形体は２個のフィールド（２＋）を含む構造体（ｂ）である。１番目 のフィールドは符号無しのlong（Ｋ）である。２番目のフィールドは符号無しの long（Ｋ）である。 オペレーションをＣＩＮで記述する場合、前記方法はステップ９５１に進む。 図９は、オペレーションのための記述子を生成するためのステップを示すフロー チャートである。オペレーション記述子は、ＣＩＮにより次のように生成される 。 ステップ９５１において、前記コードジェネレータは、前記オペレーションの記 述子の残部を構成する文字列から導出されるユニークな整数operation_synopsis を生成する。該整数は、前記ＣＩＮ記述子における残りの文字について例えば巡 回冗長検査を実行することによって導出される。次に、前記コードジェネレータ は、前記オペレーションの本来のＩＤＬ名から導出されるユニークな文字列oper ation_idを生成する。次に、ステップ９５５において、前記コードジェネレータ は、前記オペレーションの属性（無しまたは“一方向”）を示す文字であるoper ation_attributeを生成する。例えば、前記オペレーションが一方向属性を有さ ない場合、文宇Ａが生成される。しかし、前記オペレーションが一方向である場 合、前記コードジェネレータは文字Ｂを生成する。文字nr_paramsは、前記オペ レーション中にいくつのパラメータが含まれるかを示す整数である。前記オペレ ーションが非空き（non-void）リターン型を有する場合、１番目のパラメータが その結果である。param_1記述子は、その後に実際のパラメータデータ型が続く ことになる前記パラメータの方向（in、out、inoutまたは関数結果）を示す文字 を含む。例えば、前記コードジェネレータは、in、out、inoutおよび関数結果の 方向について、それぞれ、文字Ａ，Ｂ，ＣおよびＤを生成する。これら特定のパ ラメータについて、図８のステップ８０７にリターンする。各パラメータのデー タ型が記述されたとき、例外の数が整数nr_exceptionsによって示される。そし て、ステップ１１９にリターンすることによって、各例外の構造記述がなされる 。整数nr_contextsは、前記オペレーションによって保持されるコンテキスト名 の数を示す。これらのコンテキスト名は、文字列context_1，context_2，contex t_nで生成される。 次のものは元々ＩＤＬで記述された２つのサンプルオペレーションである。 この発明の方法を使用することによって、上記AddオペレーションはＣＩＮに より次のように表現される。 前記オペレーションのＣＩＮ記述子は次のように説明される。最初の数字（12 6861413）は、文字列“3+ADDA3+DFAFAF0+0+”について巡回冗長検査を実行する ことによって、前記ＣＩＮの残部から導出される。オペレーションｉｄは３つの 文字（３＋）を含む。これらの３つの文字は、オペレーションｉｄとしての文字 列“ADD”である。すべてのＩＤＬ識別子は、固有のものであり、caseとは独立 でなければならない。従って、オペレーションｉｄは大文字とされる。前記オペ レーションは、一方向性属性（Ａ）を含まず、３つの“パラメーダ”（３＋）を 含む。前記関数が結果を返すので、実際上、最初の“パラメータ”が関数結果（ Ｄ）である。前記関数結果は符号付きのlong（Ｆ）である。次のパラメータ（実 際上、最初のパラメータ）はｉｎパラメータ（Ａ）である。該パラメータは、型 分類された符号付きのlong（Ｆ）のパラメータである。３番目のパラメータは、 型分類された符号付きのlong（Ｆ）のinパラメータである。例外およびコンテキ ストは存在しない（０＋）。 同様に、上記SubtractオペレーションはＣＩＮ記述子により次のように表現さ れる。 インターフェイスも、この発明の方法を使用することによって同様に記述され る。図10はインターフェイス記述子の生成を示す。インターフェイスは次のよう に定義される。 整数nr_operationsは、該インターフェイスに含まれるオペレーションの数を示 す。各オペレーションは、オペレーション記述子を生成するための上記方法に従 つて、operation_spec_1，operation_spec_2，operation_spec_nで記述される。 こうして、前記コードジェネレータ１１２は、図９のステップ９５１に進み、各 オペレーションを記述する。 この発明の方法を使用することによって、上記AddオペレーションはＣＩＮに より次のように表現される。 前記インターフェイスは２つのオペレーション（２＋）を含む。上記Addオペ レーションおよびSubtractオペレーションのオペレーション記述子は、オペレー ションの数を示す文字の次にくる。 上述の如く、ＣＩＮ記述子は、クライアントアプリケーションおよびサーバア プリケーションの両方にリンクされるヘッダファイルに含まれる。こうして、ク ライアントおよびサーバの両方は、各々が適当と考える記述子を利用することが できる。前記ＣＩＮは様々な形態で使用可能である。例えばデータ型のＣＩＮ記 述子は、構造化されたデータ型をパックしたりアンパックしたりするための汎用 関数を作成するのに有用であろう。 さらに、ＣＩＮ記述子は、迅速にインターフェイスを比較するためにも使用可 能である。例えば、サーバアプリケーションは、ＣＩＮで記述された２つのイン ターフェイスを含むヘッダファイルを有してもよい。この場合、該サーバアプリ ケーションは、既知の文字列比較関数を使用してＡＳＣＩＩ文字列記述子を比較 することができる。ＣＩＮ記述が同一である（または類似している）場合、サー バは、サーバアプリケーションにおいて共通の方法を使用して両インターフェイ スのオペレーションを実行することができる。こうして、上記ＣＩＮを使用して 、異なる（しかし類似している）インターフェイスのための多数の時間コード化 方法をセーブする。 VI．ピクルドＩＤＬフォーマットデータ構造体の作成 ピクルド（pickled）ＩＤＬフォーマット（“ＰＩＦ”）データ構造体は、ク ライアントメモリ２３およびサーバメモリ１７にロードされたＩＤＬコンパイラ およびコードジェネレータと共に使用されるよう設計されている。該データ構造 体は、メモリ２３またはメモリ１７に格納されたＩＤＬソースファイルに基づい ている。該ソースファイルも、ディスクのようなコンピュータによって読取り可 能な媒体に格納されることができる。このデータ構造体は、ＩＤＬソースファイ ルを示す解析ツリーを含んでいる。該データ構造体は、メモリ２３またはメモリ １７あるいはディスクのようなコンピュータによって読取り可能な媒体に格納可 能である。前記ソースファイルを示す前記データ構造体は、ピクルドＩＤＬフォ ーマット（“ＰＩＦ”）と呼ばれている。該ＰＩＦファイルは、前記ソースファ イルに定義されたインターフェイスを使用するクライアントおよびサーバにより 実行時にアクセス可能である。該ＰＩＦファイルに含まれる解析ツリーは、ポイ ンタの代りにアレイインデックスを使用するアレイである。このアレイインデッ クスの使用により、その結果としての解析ツリーは言語とは独立したものとする ことができる。前記アレイの最初の構成要素は使用されない。前記アレイの２番 目の構成要素（インデックス１）は、前記解析ツリーの残りの部分へのエントリ ポイントとして機能するルート部である。 図１１にはデータ構造体tu１１０１が示されており、これは次のようにＩＤＬ によって定義される。 前記データ構造体１１０１は、その各々がentry_defタイプ（後で定義）である 解析ツリーノード１１０５のシーケンス（可変サイズアレイ）およびソースファ イルライン１１０７のシーケンスを含む。前記ソースファイルライン１１０７の シーケンスは、前記ＩＤＬソースファイルからの実際のソースコードラインを含 む文字列シーケンスである。 各解析ツリーノード（または“エントリ”）１１０５は、該ノードの名前およ びその特性を含む固定部、ならびに、前記ノードのタイプによって決まる可変部 で構成される。前記解析ツリーノードは図１２に示されており、これは次のよう にＩＤＬによって定義される。 前記解析ツリーノードの固定部はentry_index１２０５を含み、これは前記解 析ツリーにおけるこの特定のエントリのインデックスである符号なしlongである 。前記エントリの非修飾名は、nameフィールド１２０７に含まれる。オリジナル のＩＤＬソースファイルの名前は、file_nameフィールド１２１１に含まれる。l ine_nrフィールド１２１３は、この解析ツリーノードを作成させる前記ＩＤＬソ ースファイルにおけるライン番号を含む。ブールin_main_file１２１５は、コマ ンドライン上に指定されたＩＤＬソースファイルにおいてエントリがなされたか 否か、または、前記エントリが“include”ファイルの一部か否かを示す。この ファイルに続いて、前記解析ツリーは、可変部、すなわち、識別子entry_type_d efを有する共用体１２１７を含む。前記共用体識別子entry_type_defは、ノード のタイプおよびentry_def内のどの変数がアクティブなのかを指示する。entry_t ype_defは次のように定義される列挙である。 entry_type_defは、各種の解析ツリーエントリのリストを含む。各解析ツリー エントリは、entry_defに含まれるswitch文に使用される一定の定数を示す。各 エントリごとに、共用体u_tagは異なるタイプの構造体を含むことになる。列挙 された最初の値entry_unusedは、ゼロの値に対応し、前記共用体のタイプを決定 するのに使用されない。 前記解析ツリーエントリが（値entry_moduleによって指示された）モジュール である場合、前記解析ツリーの可変部は、モジュール定義シーケンスを含むデー タ構造である。各モジュール定義は、前記解析ツリーエントリにおけるインデッ クスとして機能する符号なしlongである。 前記解析ツリーエントリが（値entry_interfaceによって指示された）インタ ーフェイスである場合、前記解析ツリーの可変部は、ローカル定義シーケンス、 および、このインターフェイスが継承する基本インターフェイスのシーケンスを 含むデータ構造体である。前記解析ツリーエントリがインターフェイスの前向き 宣言（entry_interface_fwd）である場合、前記共用体はフル定義のインデック スを含む符号なしのlongである。 定数（entry_const）は、解析ツリーノードにおいて該定数の値を含む構造体 として表現される。好ましくは、前記ソースファイルに含まれる各種の基本タイ プ定数（ブール定数、char定数、double定数等）を識別するために、共用体およ びswitch/case文が使用される。 例外（entry_except）は、解析ツリーノードにおいてフィールドのシーケンス を含む構造体として表現される。属性（entry_attr）は、該属性が読出し専用で あるか否かを示すブール値、および、そのデータ型を示す符号なしのlongを含む データ構造として表現される。 前記解析ツリーエントリがオペレーション（op_def）である場合、前記エント リデータ構造体１１０５の可変部１２１７は図１３に示されるようなデータ構造 体である。前記データ構造体１２１７は、前記オペレーションが一方向属性を有 するものか否かを示すブール論理１３０５、戻りタイプを示す符号なしのlong１ ３０７、前記オペレーションに対する引数１３１１のシーケンス、前記オペレー ションに対する例外１３１１のシーケンス、および、前記オペレーションに含ま れるコンテキストを指示する文字列１３１３のシーケンスを含む。前記解析ツリ ーエントリが特定のオペレーションに対する引数（entry_argument）である場合 、該解析ツリーエントリの可変部は、該引数の方向およびデータ型を示す符号な しのlongを含む。 前記解析ツリーエントリが共用体（entry_union）である場合、これは解析ツ リーエントリにおいて図１４に示すようなに表現される。前記データ構造体１２ １７は、識別子１４０３を示す符号なしのlong、および、その型１４０５を示す 符号なしのlongを含む。その型は、基本型の列挙リストを使用して指示されるの が好ましい。該データ構造体１２１７は、共用体フィールド１４０７のシーケン スをさらに含む。前記解析ツリーエントリが共用体ブランチ（entry_branch）で ある場合、前記解析ツリーエントリの可変部は、前記ブランチの基本型を示す符 号なしのlong、前記ブランチがcaseラベルを含むか否かを示すブール数、および 、識別子の値を含む構造体である。前記値は特定のデータ型であるので、好まし くは、各種基本型の列挙リストを使用して、該共用体ブランチを表現するために 使用される構造体内の値を示す。 データ構造体（entry_struct）の場合、前記解析ツリーエントリの可変部は、 指定された構造体フィールドのシーケンスを含む構造体を含む。列挙された値（ entry_enum）は、列挙された値のシーケンスを含む構造体によって表現される。 列挙されたタイプの列挙（entry_enum_val）は、前記解析ツリーエントリにおい て、列挙の数値を保持する符号なしのlongを含む構造体によって表現される。 前記解析ツリーエントリが文字列（entry_string）である場合、前記解析ツリ ーエントリの可変部は、該文字列の最大サイズを含む構造体である。最大サイズ がゼロである場合、これは制限なしの文字列を示す。アレイ（entry_array）は 、 前記解析ツリーエントリにおいて、前記アレイの基本型を保持する符号なしのIo ng、および、前記アレイのサイズを保持するlongのシーケンス含む構造体によっ て表現される。シーケンス（entry_sequence）は、前記シーケンスの基本型およ び最大サイズを保持する符号なしのlongを含む構造体によって表現される。 タイプ定義（entry_typedef）の場合、前記解析ツリーエントリは、前記タイ プ定義の基本型を示す符号なしのlongの値を含む構造体によって表現される。予 め定義されたタイプ（entry_pre_defined）は、データ型を含む構造体によって 表現される。前記タイプを指示するために、前記各種基本型の列挙が使用される のが好ましい。 前記tuデータ構造体を使用して前記ＩＤＬソースが記述されると、前記データ 構造体は任意の既知の方法を使用してファイルまたはデータベースに移送される 。 以上のように移送に便利な書式におよび該書式から、ＩＤＬ定義されたデータ 構造体を変換するための本発明方法および装置の好ましい実施の形態について説 明してきたが、この発明の範囲および精神の範囲内で様々な変更が可能である。 例えば、ＩＤＬ定義されたデータ構造体について説明したが、データ構造体が前 記コードジェネレータと同一のアライメント定義に従うものである場合、上述し た発明の概念は、手書きのデータ構造体にも同様に適用可能である。

Claims (1)

1. 【特許請求の範囲】 １．少なくとも１つのフィールドを有する第１のデータ構造体に格納されたデー タを、第１のコンピュータメモリから、データファイルおよび第２のコンピュー タメモリの少なくとも一方に移送する方法であって、 前記第１のデータ構造体の文字列記述を生成するステップと、 前記第１データ構造体の前記文字列記述を前記第１コンピュータメモリおよび 前記第２コンピュータメモリに格納するステップと、 前記少なくとも１つのフィールドのサイズ、アラインメントおよび型を含む第 ２のデータ構造体を生成するステップと、 前記第２データ構造体を前記第１コンピュータメモリおよび前記第２コンピュ ータメモリに格納するステップと、 前記第１データ構造体の前記文字列記述に基づいて前記第１コンピュータメモ リのバッファに前記データを格納するステップと、 前記データファイルと前記第２コンピュータメモリの少なくとも一方に前記バ ッファを移送するステップと、 前記バッファから前記データを抜き出すステップと、 前記データ構造体の前記文字列記述に基づいて前記データを第３のデータ構造 体に格納するステップと を具備する方法。 ２．前記データをバッファに格納する前記ステップは、 前記構造体の浮動小数点型および倍型の構成要素を、浮動小数点数を表現する 書式で格納するステップと、 前記データ構造体のlong型、long long型、符号なしlong型、符号なしlong lo ng型、short型および符号なしshort型の構成要素を、整数を表現する書式で格納 するステップと、 前記データ構造体の文字型の構成要素を、文字を表現する書式で格納するステ ップと をさらに具備する請求の範囲第１項に記載の方法。 ３．前記データ構造体格納ステップは、 前記データ構造体の“any”型の構成要素を、前記文字列の長さ、前記文字列 および“任意”の前記データ構造体の構成要素を指定する符号なしlong型に変換 するステップと、 前記符号なしlong型を前記整数を表現する書式で格納するステップと、 前記文字列を、複数の文字の前に位置する前記文字列の長さを示す符号なしlo ng型として格納するステップと、 前記複数の文字の各々を前記文字を表現する書式で格納するステップと、 前記“任意”のデータ構造体の各構成要素を所定の書式に従って格納するステ ップと をさらに具備する請求の範囲第２項に記載の方法。 ４．所定書式に基づいて前記少なくとも１つのデータ構造体を格納する前記ステ ップは、 前記データ構造体のアレイ構成要素の要素を未詰込み書式で格納するステップ と、 前記データ構造体のシーケンス構成要素を、前記整数を表現する書式で格納す るステップと、 前記データ構造体の文字列構成要素を、前記文字列の長さを示し、複数の文字 の前に位置する符号なしlong型に変換するステップと、 前記データ構造体の前記文字列構成要素を表現する前記符号なしlong型を前記 整数を表現する書式で格納するステップと、 前記複数の文字の各々を前記文字を表現する書式で格納するステップと をさらに具備する請求の範囲第２項に記載の方法。 ５．前記浮動小数点数を表現する書式は、ＩＥＥＥ書式であることを特徴とする 請求の範囲第２項に記載の方法。 ６．前記浮動小数点数表現書式は、ＴＡＮＤＥＭ Ｔ１６書式であることを特徴 とする請求の範囲第２項に記載の方法。 ７．前記整数を表現する書式は、整数のバイト重要度がアドレス増加にともなっ て減少することを指定することを特徴とする請求の範囲第２項に記載の方法。 ８．前記整数を表現する書式は、整数のバイト重要度がアドレス増加にともなっ て増加することを指定することを特徴とする請求の範囲第２項に記載の方法。 ９．前記文字を表現する書式は、ＩＳＯ Ｌａｔｉｎ−１であることを特徴とす る請求の範囲第２項に記載の方法。 １０．前記少なくとも１つの構造体に関する情報を取得するステップと、 前記第１コンピュータの前記出力バッファにメモリを割り当てるステップと を更に含む請求の範囲第１項に記載の方法。 １１．インターフェイス定義言語で定義された整列データ構造体を、文字列書式 による前記データ構造体の記述を有する第１のコンピュータメモリから、前記デ ータ構造体の前記文字列記述を有する第２のコンピュータメモリおよびデータフ ァイルの少なくとも一方に移送する方法であって、 前記文字列記述を、前記データ構造体のアラインメントおよびサイズに関する 情報を含む書式に変換するステップと、 前記データ構造体から少なくとも１個のアラインメントフィールドを除去する ステップと、 浮動小数点数を表現する書式で、前記データ構造体の浮動小数点および倍型構 成要素を前記第１コンピュータのバッファに格納するステップと、 整数を表現する書式で、前記データ構造体のlong型、long long型、符号無しl ong型、符号無しlong long型、short型および符号無しshort型の構成要素を前記 第１コンピュータの前記バッファに格納するステップと、 文字を表現する書式で、前記データ構造体の文字型構成要素を前記第１コンピ ュータの前記バッファに格納するステップと、 前記第２コンピュータメモリとデータファイルの前記少なくとも一方に前記バ ッファを移送するステップと、 前記データ構造体の各構成要素を格納するための前記書式に基づいて前記バッ ファから前記データ構造体を抽出するステップと を具備する方法。 １２．前記小数点数を表現する書式は、ＩＥＥＥ書式であることを特徴とする請 求の範囲第１１項に記載の方法。 １３．前記小数点数を表現する書式は、Ｔａｎｄｅｍ Ｔ１６書式であることを 特徴とする請求の範囲第１１項に記載の方法。 １４．前記整数を表現する書式は、整数のバイト重要度がアドレス増加にともな って減少することを指定することを特徴とする請求の範囲第１１項に記載の方法 。 １５．前記整数を表現する書式は、整数のバイト重要度がアドレス増加にともな って増加することを指定することを特徴とする請求の範囲第１１項に記載の方法 。 １６．前記文字を表現する書式は、ＩＳＯ Ｌａｔｉｎ−１であることを特徴と する請求の範囲第１１項に記載の方法。 １７．インターフェイス定義言語で定義された整列データ構造体の文字列書式の 記述を有する少なくとも１つのマシンによって読み取り可能であり、前記少なく とも１つのマシンのメモリから前記データ構造体のＡＳＣＩＩ記述を有する第２ のマシンおよびデータファイルの少なくとも一方に前記データ構造体を移送する 方法を前記少なくとも１つのマシンに実行させる命令を含む媒体であって、前記 方法が、 前記文字列記述を前記データ構造体のアラインメントおよびサイズに関する情 報を含む書式に変換するステップと、 前記データ構造体から少なくとも１つのアラインメントフィールドを除去する ステップと、 前記データ構造体を前記第１マシンの前記メモリのバッファに格納するステッ プであり、少なくとも１つのデータ構造体を所定の書式で前記文字列記述に基づ いて格納するものと、 前記バッファを前記第１マシンの前記メモリからデータファイルおよび第２マ シンの前記少なくとも一方に移送するステップと、 前記データ構造体を前記バッファから前記所定書式に従って抽出するステップ と、 前記少なくとも１つのデータ構造体を整列させるステップと を具備することを特徴とする媒体。 １８．前記少なくとも１つのデータ構造体を所定の書式に基づいて格納する前記 ステップは、 前記データ構造体の浮動小数点および倍型構成要素を、浮動小数点数を表現す る書式で格納するステップと、 前記データ構造体のlong型、long long型、符号無しlong型、符号無しlong lo ng型、short型および符号無しshort型の構成要素を、整数を表現する書式で格納 するステップと、 前記データ構造体の文字型構成要素を、文字を表現する書式で格納するステッ プと をさらに具備する請求の範囲第１７項に記載の媒体。 １９．前記少なくとも１つのデータ構造体を所定書式に基づいて格納する前記ス テップは、 前記データ構造体の“any”型構成要素を、オリジナルＡＳＣＩＩ文字列、Ａ ＳＣＩＩ文字列および“任意”の前記データ構造体内のデータ構造体の長さを指 定する符号無しlong型に変換するステップと、 前記符号無しlong型を前記整数を表現する書式で格納するステップと、 前記ＡＳＣＩＩ文字列を、複数の文字の前に位置する前記文字列の長さを示す 符号無しlong型として格納するステップと、 前記複数の文字の各々を前記文字を表現する書式で格納するステップと、 前記“任意”データ構造体中の各データ構造体を所定の書式で格納するステッ プと をさらに具備する請求の範囲第１７項に記載の媒体。 ２０．前記少なくとも１つのデータ構造体を所定の書式で格納する前記ステップ は、 前記データ構造体のアレイ構成要素の要素を非詰め込み書式で格納するステッ プと、 前記データ構造体の列構成要素を前記整数を表現する書式で格納するステップ と、 前記データ構造体の文字列構成要素を、複数の文字の前に位置する前記文字列 の長さを示す符号無しlong型として表現するステップと、 文字列を表現する前記符号無しlong型を前記整数を表現する書式で格納するス テップと、 前記複数文字の各々を前記文字を表現する書式で格納するステップと をさらに具備する請求の範囲第１７項に記載の媒体。