(57)【要約】【課題】ＩＤＬ定義されたデータ構造体を２つのコンピュータ間での移送に便利な書式に、また、この書式から移行する方法および装置を提供する。【解決手段】移送すべきデータ構造体の文字列記述がホストコンピュータで生成される。この文字列記述は、該データ構造体のサイズ、アラインメントおよび型を記述するホスト記述に変換される。ホスト記述内の記述に基づき該ホストコンピュータの出力バッファ内に該データ構造体をパックし、この出力バッファをクライアントコンピュータの入力バッファに移送する。クライアントコンピュータでは、クライアントコンピュータ内で使用される際の前記データ構造体における各フィールドのサイズ、アラインメントおよび型を記述するクライアント記述を生成する。【選択図】  図４
2007234047.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのフィールドを有するデータ構造体を、ホストコンピュータからクライアントコンピュータに移送する方法であって、
前記ホストコンピュータによって、前記データ構造体の文字列記述を生成するステップと、
前記ホストコンピュータによって、前記文字列記述のホスト記述を生成するステップであって、前記ホスト記述とは、前記ホストコンピュータ内で使用される際の前記データ構造体における各フィールドのサイズ、アラインメントおよび型を記述するものである前記ステップと、
前記クライアントコンピュータによって、前記文字列記述のクライアント記述を生成するステップであって、前記クライアント記述とは、前記クライアントコンピュータ内で使用される際の前記データ構造体における各フィールドのサイズ、アラインメントおよび型を記述するものである前記ステップと、
前記ホストコンピュータによって、前記ホスト記述内の記述に基づき該ホストコンピュータの出力バッファ内に前記データ構造体をパックするステップと、
前記ホストコンピュータによって、前記出力バッファを前記クライアントコンピュータの入力バッファに移送するステップと
を具備する方法。
【請求項２】
前記クライアントコンピュータによって実行され、前記入力バッファと前記クライアント記述を使用して第２のデータ構造体を生成するステップを更に具備することを特徴とする請求項１に記載の方法。
【請求項３】
前記出力バッファに前記データ構造体をパックするステップは、前記ホストコンピュータによってそれぞれ実行される、
ＩＤＬ（インターフェイス定義言語）定義された前記データ構造体における float型およびdouble型のデータ構成要素を、浮動小数点数を表現するためのフォーマットで格納するステップと、
ＩＤＬ定義された前記データ構造体におけるlong型、long long型、符号なしlong型、符号なしlong long型、short型および符号なしshort型のデータ構成要素を、整数を表現するためのフォーマットで格納するステップと、
ＩＤＬ定義された前記データ構造体における文字キャラクタ型のデータ構成要素を、文字キャラクタを表現するためのフォーマットで格納するステップと
を具備することを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記出力バッファに前記データ構造体をパックする前記ステップは、前記ホストコンピュータによってそれぞれ実行される、
ＩＤＬ定義された前記データ構造体における整数又はテキストを含む文字列記述でなる“any”型のデータ構成要素を、その文字列記述の長さと、当該文字列記述と、“any”型のデータ構成要素であることとを特定する符号なしlong型に変換するステップと、
前記符号なしlong型を整数を表現するためのフォーマットで格納するステップと、
複数の文字キャラクタの前に、前記文字列記述の長さを示す文字列を符号なしlong型にて格納するステップと、
前記複数の文字キャラクタの各々を文字キャラクタを表現するためのフォーマットで格納するステップと、
前記“any” 型の各データ構成要素を所定のフォーマットに従って前記出力バッファに格納するステップと
を具備することを特徴とする請求項１乃至３のいずれかに記載の方法。
【請求項５】
前記出力バッファに前記データ構造体をパックする前記ステップは、前記ホストコンピュータによってそれぞれ実行される、
ＩＤＬ定義された前記データ構造体におけるデータ数の確定されたアレイ型のデータ構成要素を空の１又は複数バイトのパディングフィールドを設けることのないフォーマットで格納するステップと、
ＩＤＬ定義された前記データ構造体におけるデータ数の確定されないシーケンス型のデータ構成要素を、整数を表現するためのフォーマットで格納するステップと、
ＩＤＬ定義された前記データ構造体における文字列型のデータ構成要素を、前記文字列の長さを示し、複数の文字キャラクタの前に位置する符号なしlong型に変換するステップと、
前記変換された前記符号なしlong型を整数を表現するフォーマットで格納するステップと、
前記複数の文字キャラクタの各々を文字キャラクタを表現するためのフォーマットで格納するステップと
を具備することを特徴とする請求項１乃至４のいずれかに記載の方法。
【請求項６】
前記浮動小数点数を表現するためのフォーマットは、仮数部と指数部を用いる既存のＩＥＥＥ規格のフォーマットであることを特徴とする請求項３に記載の方法。
【請求項７】
前記浮動小数点数を表現するためのフォーマットは、仮数部と指数部を用いるフォーマットであることを特徴とする請求項３に記載の方法。
【請求項８】
前記整数を表現するためのフォーマットは、複数バイトからなる整数のバイトの重みがアドレス増加にともなって減少することを指定することを特徴とする請求項３に記載の方法。
【請求項９】
前記整数を表現するためのフォーマットは、複数バイトからなる整数のバイトの重みがアドレス増加にともなって増加することを指定することを特徴とする請求項３に記載の方法。
【請求項１０】
前記文字キャラクタを表現するためのフォーマットは、既存のＩＳＯ規格におけるいずれか１つの所定の欧米文字フォーマットに従うものであることを特徴とする請求項３に記載の方法。
【請求項１１】
コンピュータ読み取り可能な記憶媒体であって、少なくとも１つのフィールドを有するデータ構造体を、ホストコンピュータからクライアントコンピュータに移送するためのプログラムを記憶してなり、前記プログラムは、
前記ホストコンピュータに、
前記データ構造体の文字列記述を生成するステップと、
前記文字列記述のホスト記述を生成するステップであって、前記ホスト記述とは、前記ホストコンピュータ内で使用される際の前記データ構造体における各フィールドのサイズ、アラインメントおよび型を記述するものである前記ステップと、
前記ホスト記述内の記述に基づき該ホストコンピュータの出力バッファ内に前記データ構造体をパックするステップと、
前記出力バッファを前記クライアントコンピュータの入力バッファに移送するステップと
を実行させるプログラムと、
前記クライアントコンピュータに、
前記文字列記述のクライアント記述を生成するステップであって、前記クライアント記述とは、前記クライアントコンピュータ内で使用される際の前記データ構造体における各フィールドのサイズ、アラインメントおよび型を記述するものである前記ステップ、
を実行させるプログラムと、
で構成されることを特徴とするコンピュータ読み取り可能な記憶媒体。
【請求項１２】
前記クライアントコンピュータに、
前記入力バッファと前記クライアント記述を使用して第２のデータ構造体を生成するステップ
を更に実行させるプログラムを記憶してなることを特徴とする請求項１１に記載の記憶媒体。
【請求項１３】
前記出力バッファに前記データ構造体をパックするステップでは、前記ホストコンピュータに、
ＩＤＬ（インターフェイス定義言語）定義された前記データ構造体における float型およびdouble型のデータ構成要素を、浮動小数点数を表現するためのフォーマットで格納するステップと、
ＩＤＬ定義された前記データ構造体におけるlong型、long long型、符号なしlong型、符号なしlong long型、short型および符号なしshort型のデータ構成要素を、整数を表現するためのフォーマットで格納するステップと、
ＩＤＬ定義された前記データ構造体における文字キャラクタ型のデータ構成要素を、文字キャラクタを表現するためのフォーマットで格納するステップと
を実行させることを特徴とする請求項１１又は１２に記載の記憶媒体。
【請求項１４】
前記出力バッファに前記データ構造体をパックする前記ステップでは、前記ホストコンピュータに、
ＩＤＬ定義された前記データ構造体における整数又はテキストを含む文字列記述でなる“any”型のデータ構成要素を、その文字列記述の長さと、当該文字列記述と、“any”型のデータ構成要素であることとを特定する符号なしlong型に変換するステップと、
前記符号なしlong型を整数を表現するためのフォーマットで格納するステップと、
複数の文字キャラクタの前に、前記文字列記述の長さを示す文字列を符号なしlong型にて格納するステップと、
前記複数の文字キャラクタの各々を文字キャラクタを表現するためのフォーマットで格納するステップと、
前記“any” 型の各データ構成要素を所定のフォーマットに従って前記出力バッファに格納するステップと
を実行させることを特徴とする請求項１１乃至１３のいずれかに記載の記憶媒体。
【請求項１５】
前記出力バッファに前記データ構造体をパックする前記ステップでは、前記ホストコンピュータに、
ＩＤＬ定義された前記データ構造体におけるデータ数の確定されたアレイ型のデータ構成要素を空の１又は複数バイトのパディングフィールドを設けることのないフォーマットで格納するステップと、
ＩＤＬ定義された前記データ構造体におけるデータ数の確定されないシーケンス型のデータ構成要素を、整数を表現するためのフォーマットで格納するステップと、
ＩＤＬ定義された前記データ構造体における文字列型のデータ構成要素を、前記文字列の長さを示し、複数の文字キャラクタの前に位置する符号なしlong型に変換するステップと、
前記変換された前記符号なしlong型を整数を表現するフォーマットで格納するステップと、
前記複数の文字キャラクタの各々を文字キャラクタを表現するためのフォーマットで格納するステップと
を実行させることを特徴とする請求項１１乃至１４のいずれかに記載の記憶媒体。
【請求項１６】
前記浮動小数点数を表現するためのフォーマットは、仮数部と指数部を用いる既存のＩＥＥＥ規格のフォーマットであることを特徴とする請求項１３に記載の記憶媒体。
【請求項１７】
前記浮動小数点数を表現するためのフォーマットは、仮数部と指数部を用いるフォーマットであることを特徴とする請求項１３に記載の記憶媒体。
【請求項１８】
前記整数を表現するためのフォーマットは、複数バイトからなる整数のバイトの重みがアドレス増加にともなって減少することを指定することを特徴とする請求項１３に記載の記憶媒体。
【請求項１９】
前記整数を表現するためのフォーマットは、複数バイトからなる整数のバイトの重みがアドレス増加にともなって増加することを指定することを特徴とする請求項１３に記載の記憶媒体。
【請求項２０】
前記文字キャラクタを表現するためのフォーマットは、既存のＩＳＯ規格におけるいずれか１つの所定の欧米文字フォーマットに従うものであることを特徴とする請求項１３に記載の記憶媒体。
【請求項２１】
少なくとも１つのフィールドを有するデータ構造体を、ホストコンピュータからクライアントコンピュータに移送するシステムであって、
前記ホストコンピュータにおいて、前記データ構造体の文字列記述を生成する手段と、
前記ホストコンピュータにおいて、前記文字列記述のホスト記述を生成する手段であって、前記ホスト記述とは、前記ホストコンピュータ内で使用される際の前記データ構造体における各フィールドのサイズ、アラインメントおよび型を記述するものである前記手段と、
前記クライアントコンピュータにおいて、前記文字列記述のクライアント記述を生成する手段であって、前記クライアント記述とは、前記クライアントコンピュータ内で使用される際の前記データ構造体における各フィールドのサイズ、アラインメントおよび型を記述するものである前記手段と、
前記ホストコンピュータにおいて、前記ホスト記述内の記述に基づき該ホストコンピュータの出力バッファ内に前記データ構造体をパックする手段と、
前記ホストコンピュータにおいて、前記出力バッファを前記クライアントコンピュータの入力バッファに移送する手段と
を具備するシステム。
【請求項２２】
前記クライアントコンピュータにおいて、前記入力バッファと前記クライアント記述を使用して第２のデータ構造体を生成する手段を更に具備することを特徴とする請求項２１に記載のシステム。
【請求項２３】
前記出力バッファに前記データ構造体をパックする前記手段は、
ＩＤＬ（インターフェイス定義言語）定義された前記データ構造体における float型およびdouble型のデータ構成要素を、浮動小数点数を表現するためのフォーマットで格納する手段と、
ＩＤＬ定義された前記データ構造体におけるlong型、long long型、符号なしlong型、符号なしlong long型、short型および符号なしshort型のデータ構成要素を、整数を表現するためのフォーマットで格納する手段と、
ＩＤＬ定義された前記データ構造体における文字キャラクタ型のデータ構成要素を、文字キャラクタを表現するためのフォーマットで格納する手段と
を具備することを特徴とする請求項２１又は２２に記載のシステム。
【請求項２４】
前記出力バッファに前記データ構造体をパックする前記手段は、
ＩＤＬ定義された前記データ構造体における整数又はテキストを含む文字列記述でなる“any”型のデータ構成要素を、その文字列記述の長さと、当該文字列記述と、“any”型のデータ構成要素であることとを特定する符号なしlong型に変換する手段と、
前記符号なしlong型を整数を表現するためのフォーマットで格納する手段と、
複数の文字キャラクタの前に、前記文字列記述の長さを示す文字列を符号なしlong型にて格納する手段と、
前記複数の文字キャラクタの各々を文字キャラクタを表現するためのフォーマットで格納する手段と、
前記“any” 型の各データ構成要素を所定のフォーマットに従って前記出力バッファに格納する手段と
を具備することを特徴とする請求項２１乃至２３のいずれかに記載のシステム。
【請求項２５】
前記出力バッファに前記データ構造体をパックする前記手段は、
ＩＤＬ定義された前記データ構造体におけるデータ数の確定されたアレイ型のデータ構成要素を空の１又は複数バイトのパディングフィールドを設けることのないフォーマットで格納する手段と、
ＩＤＬ定義された前記データ構造体におけるデータ数の確定されないシーケンス型のデータ構成要素を、整数を表現するためのフォーマットで格納する手段と、
ＩＤＬ定義された前記データ構造体における文字列型のデータ構成要素を、前記文字列の長さを示し、複数の文字キャラクタの前に位置する符号なしlong型に変換する手段と、
前記変換された前記符号なしlong型を整数を表現するフォーマットで格納する手段と、
前記複数の文字キャラクタの各々を文字キャラクタを表現するためのフォーマットで格納する手段と
を具備することを特徴とする請求項２１乃至２４のいずれかに記載のシステム。
【請求項２６】
前記浮動小数点数を表現するためのフォーマットは、仮数部と指数部を用いる既存のＩＥＥＥ規格のフォーマットであることを特徴とする請求項２３に記載のシステム。
【請求項２７】
前記浮動小数点数を表現するためのフォーマットは、仮数部と指数部を用いるフォーマットであることを特徴とする請求項３に記載のシステム。
【請求項２８】
前記整数を表現するためのフォーマットは、複数バイトからなる整数のバイトの重みがアドレス増加にともなって減少することを指定することを特徴とする請求項２３に記載のシステム。
【請求項２９】
前記整数を表現するためのフォーマットは、複数バイトからなる整数のバイトの重みがアドレス増加にともなって増加することを指定することを特徴とする請求項２３に記載のシステム。
【請求項３０】
前記文字キャラクタを表現するためのフォーマットは、既存のＩＳＯ規格におけるいずれか１つの所定の欧米文字フォーマットに従うものであることを特徴とする請求項２３に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、オブジェクト管理グループのインターフェイス定義言語によって定義されたデータ構造体を異種プラットフォーム間で移送するための方法および装置に関する。特に、本発明は、データ構造体からアラインメントを除去し、そのデータ構造体を所定の書式でファイルに又は異種プラットフォーム間で移送する関数を利用するものである。
【背景技術】
【０００２】
分散型オブジェクトコンピューティング方式は、分散型コンピューティングとおよびオブジェクト指向型コンピューティングの概念を組み合わせたものである。分散型コンピューティング方式は、情報を相互に共有する２つ又はそれ以上のソフトウエアで構成される。これら２つのソフトウエアは、同一のコンピュータ、または、共通のネットワークに接続された複数の異なるコンピュータ上で実行される。ほとんどの分散型コンピューティング方式は、クライアント／サーバモデルに基づいている。このようなクライアント／サーバモデルでは、２種類のソフトウエア、即ち、情報またはサービスを要求するクライアントソフトウエアと、情報またはサービスを提供するサーバソフトウエアが使用される。
【０００３】
オブジェクト指向コンピューティングは、（しばしば、現実世界における実オブジェクトから抽象化した）“オブジェクト”と称するコードが、（オブジェクト指向プログラミング言語では“属性”と呼ばれる）データを所有するとともに、メソッド（“オペレーション”若しくは“メンバ関数”とも呼ばれる）を介してサービスを提供するオブジェクトモデルに基づくものである。オブジェクトに含まれる上記データおよびメソッドは、“公開（パブリック）”または“非公開（プライベート）”のものである。公開データは、他のオブジェクトによって変更可能である。しかし、ほとんどのデータは、非公開であり、オブジェクトが所有するメソッドにしかアクセスできない。典型的に、メソッドは、オブジェクトに含まれる非公開データ上で動作する。
【０００４】
類似オブジェクトの集まりがインターフェイス（またはＣ＋＋言語における“クラス”）を構成する。インターフェイスは、その全てのオブジェクトに含まれるデータ型およびメソッドを指定する。そして、オブジェクトがそのインターフェイスに基づいて作成（“例示”）される。各オブジェクトは、それに固有のデータを含む。各特定のオブジェクトは、分散型オブジェクトシステムにおいて、オブジェクト参照と呼ばれる識別子によって識別される。
【０００５】
分散型オブジェクトシステムにおいて、クライアントは、リクエスト（又は“オブジェクト呼出し”）をサーバに送る。このリクエストは、サーバが実行すべきオペレーション、オブジェクト参照およびそのリクエストの成功又は失敗に関する“例外情報”（予期せぬ出来事）を返すためのメカニズムを含んでいる。サーバは、上記リクエストを受信し、もし可能であるならそのリクエストを実行し、適当な例外情報を戻す。オブジェクトリクエストブローカ（“ＯＲＢ”：Object Request Broker）は、該システムの全オブジェクトのためにサーバにリクエストを送り、クライアントに回答を送る通信ハブを提供する。
【０００６】
クライアント側のORBは、メソッドの呼び出しおよびこれに関連するサーバとメソッドの選択を要求するリクエストを取り扱う。アプリケーションが、あるオブジェクトについて実行すべきメソッドを要求するリクエストを上記ORBに送ると、このORBは、該リクエストに含まれる引数をそのオブジェクトのインターフェイスに対して検査し、該リクエストをサーバに送り、必要な場合それを開始する。サーバ側のORBは、上記リクエストを受け取り、引数の配列を解除し、必要とされるコンテキスト状態をセットアップし、メソッドディスパッチャを呼び出し、出力引数を配列し、その結果をクライアントに戻し、これにより、オブジェクト呼出しを終了する。
【０００７】
クライアントとサーバの両方が、実行可能な使用可能オブジェクトおよびメソッドに関する情報を有する必要がある。非公開データの隠蔽（オブジェクト指向言語では“カプセル化”）により、クライアントは、リクエストがサーバによってどのように実行されるかを知る必要がない。ともかく、クライアントとサーバの両方が、両者間の通信を可能とする共通のインターフェイス定義にアクセスできなければならない。現在のところ、分散型オブジェクトコンピューティング用の標準言語は、オブジェクト管理グループ（“ＯＭＧ”）のインターフェイス定義言語（“ＩＤＬ”）である。
【０００８】
分散型オブジェクトシステムの開発者は、システムの使用可能インターフェイスをIDLで定義する。インターフェイスは、該インターフェイスのオブジェクトについて実行できる１つ又はそれ以上のオペレーションを含む。各オペレーションは、１つ又はそれ以上のパラメータを受け取る。各パラメータは、特定のIDLデータ型である。
【０００９】
IDLは、いくつかのデータ型を含む。整数は、longおよびshortの、有符号および無符号整数データ型で表される。OMG IDL浮動小数点（floating point）型には、float（浮動）型とdouble（倍）型がある。float型はIEEE単精度浮動小数点数を表し、double型はIEEE倍精度浮動小数点数を表わす。OMD IDLは、８ビット量で構成されるchar（文字キャラクタ）データ型を定義する。ブール論理（boolean）データ型は、真／偽の値を表示するのに使用する。“any（任意）”型は、任意のOMG IDL型を表現できる値の指定を可能にする。構造体、共用体、テンプレートなどの混成型を表わすのにも使われる。
【００１０】
IDLは、分散型オブジェクトシステムに使用されてOMGの共通オブジェクトリクエストアーキテクチャ（ＣＯＲＢＡ：Common Object Request Broker Architecture）を実行処理するよう設計されている。典型的なCORBAシステムにおいて、インターフェイス定義は、IDL定義されたソースファイル（“翻訳ユニット”とも呼ばれる）に書き込まれている。ソースファイルは、これを特定の言語にマップするIDLコンパイラによってコンパイル（翻訳）される。IDLコンパイラは、クライアントスタブファイル、ヘッダファイルおよびサーバスケルトンファイルを含むプログラミング言語別のファイルを生成する。次いでクライアントスタブファイルがコンパイルされ、クライアントアプリケーションにリンクされてリクエストの作成に使用される。ヘッダファイルは、クライアントアプリケーションおよびサーバアプリケーションにリンクされ、データ型の定義に使用される。サーバスケルトンファイルは、サーバアプリケーションにリンクされ、オブジェクト（リクエスト）に関するクライアントオペレーションをサーバ処理系のメソッドにマップするのに使用される。
【００１１】
オブジェクト呼出しがあると、データ構造体は一方のコンピュータから他方のコンピュータへ（クライアントからサーバへ、また、サーバからクライアントへ）移送される。このようなオブジェクト呼出しは、同一システム間でも起こるが、異なるオペレーティングシステム（OS）、プログラミング言語およびコンパイラを使用する異種プラットフォーム間で発生しやすい。IDLソースファイルがコンパイルされて特定のプログラミング言語にマップされると、個々のコンパイラベンダがデータ構造体を特定の方法でスタックに整列（アライン）させる。従って、クライアントとサーバの両システムがデータ構造体を異なる態様に整列させる場合がある。さらに、クライアントとサーバの両システムがパラメータを構造体内で異なる態様に整列させる場合がある。クライアントアプリケーションとサーバアプリケーションが相手方の整列メソッドを理解しない場合、移送されたデータ構造体の混同が生じ、エラーが発生することになる。
【００１２】
さらに、クライアントとサーバとが使用するハードウエアが異なる場合がある。例えば、一方のコンピュータが、最上位バイトが最初に列挙される“BIGendian”と称する整数表現を必要とするCPUを含み、他方のコンピュータが、最下位バイトが最初に列挙される“LITTLEendian”を必要とするCPUを含む場合がある。これらの２つの装置間では、相互を知ることなしには、データ構造体を有効にやり取りすることはできない。
【００１３】
その上、クライアントとサーバが相互の詳しい知識を有している必要がある場合、オブジェクト指向型コンピューティングの第一目標であるカプセル化が失われてしまう。クライアントアプリケーションとサーバアプリケーションの両方に詳細なアライメント関数を書き込んでオブジェクト呼出し時の互換性を確立しなければならない。この余分なコーディングワークが分散型オブジェクトコンピューティングを非効率的なものとしてしまう。
【００１４】
従って、IDL定義されたデータ構造体をプラットフォームから独立した書式に変換し、変換されたデータ型が異種システム間で効果的に移送されるようにする方法が望まれている。
【００１５】
更に、クライアントおよびサーバアプリケーションがオブジェクト呼出しを処理するのに必要とされる実行時間およびコード量を減らす方法も望まれている。
【発明の開示】
【００１６】
本発明は、IDL定義されたデータ構造体をプラットフォームから独立した書式に変換し、変換されたデータ型が異種システム間で効果的に移送されるようにする方法に関するものである。クライアントおよびサーバアプリケーションがオブジェクト呼出しを処理するのに必要とされる実行時間およびコード量を減らす要望も満足させられる。具体的には、両システムは、コンパクトIDL表記法（ＣＩＮ：Compact IDL Notation）と称するASCII文字列書式で定義されたデータ構造体の記述を有する。このCINは、データ構造体のオフセットとサイズに関する追加情報を含む“準備CIN”書式に変換される。準備CINは、データ構造体を抽出し、そのデータ構造体のサイズおよびオフセットに基づいてデータを出力バッファに格納するために使用される。データは、アライメントパディングフィールドなしで出力バッファに高密にパックされる。前記出力バッファは、第２のシステムの入力バッファに移送される。該第２のコンピュータは、その入力バッファからデータを抽出する。データは、次いで、前記データは、前記第２のコンピュータの書式に変換され、前記準備CINに基づいてデータ構造体に並べ替えられる。
【００１７】
上記方法は、クライアントおよびサーバのシステムによる、処理系ライブラリに対する呼出しを使用して実行される。処理系ライブラリは、実行時間ライブラリに位置する汎用関数を含む。汎用関数を呼び出すことにより、クライアントアプリケーションおよびサーバのアプリケーションは、相互の具体的知識無しで、また、追加コードを必要とせずに、容易にオブジェクト呼出しをすることができる。
【００１８】
以下の好適実施例の詳細な説明を考察することにより、本技術分野に通じた者は上記変換方法およびこれによって実現される追加の利点並びに目的を完全に理解することができる。
【発明を実施するための最良の形態】
【００１９】
Ｉ．ハードウエアの概要
以下、添付図面の図示例を参照して、本発明の好適な実施の形態を詳細に説明する。添付図面において、同一または類似した構成要素には同一の参照番号を付す。
【００２０】
図１に示すように、本発明の方法は、分散型（クライアント／サーバ）コンピューティング環境１０に使用する設計になっている。当該クライアント／サーバシステムは、インターネット接続部またはローカルエリアネットワーク接続部のようなネットワーク接続部１２によって接続されている。サーバコンピュータ１１は、バスまたはI／Oチャンネル２０を介して関連する格納サブシステム１３と通信する。サーバシステム１１は、CPU１５と、プログラムの実行についての現在状態情報を格納するためのメモリ１７とを具備している。メモリ１７の一部は、クライアントコンピュータ上で現在実行されているプログラムの各関数に関連した状態および変数の格納に専用される。同様に、クライアントコンピュータ２１は、CPU２７と、これに関連するメモリ２３と、キーボードやマウスなどの入力装置２９と、ビデオ表示端末（VDT）などの表示装置３３とを具備している。該クライアントのCPUは、バスまたはI／Oチャンネル４０を介してディスク格納サブシステム３３３と通信し、また、I／Oチャンネル４１を介してキーボード２９、VDT３３およびマウス３１と通信する。上記の両コンピュータは、フロッピーディスク（商標）やCD-ROMを含む各種の記録媒体を読み取り可能である。
【００２１】
図１に示されるクライアント／サーバモデルは、典型的なクライアント／サーバシステムを単に例示するものである。本発明において、“クライアント”は、サービスを要求するアプリケーションであり、“サーバ”は、その要求を実行するアプリケーションである。実際上、上記クライアントアプリケーションおよびサーバアプリケーションは、後述のように、同一のコンピュータおよび共通カプセルに常駐してよい。上記クライアントアプリケーションおよびサーバアプリケーションは、異なるオペレーティングシステムを使用する異なるコンピュータに常駐してもよい。
【００２２】
II．分散型コンピューティング環境
本発明の方法および装置は、任意の分散型コンピューティング環境内で利用可能である。好ましい実施の形態において、Tandem Message Switching Facility（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 Utilities）１３０は、この発明の方法に使用されるルーチンのライブラリである。
【００２５】
CEEカプセルにおいて実行されたオブジェクトは、構成設定されたものまたは動的なものとすれことができる。構成設定されたオブジェクトの処理系の詳細は、（MSF Warehouse ８６のような）格納部または初期化スクリプトに格納されている。特定のオブジェクト参照に対するリクエストがあった場合、クライアント側CEE７５は、この構成設定されたデータに基づいて適切なカプセルを始動する。上記カプセルは、その構成設定されたデータを使用して、ロードすべき処理系ライブラリおよび呼び出すべきオブジェクト初期化ルーチンを決定する。次いで、上記オブジェクト初期化ルーチンがそのオブジェクトを作成する。動的オブジェクトは、同じカプセル内において動的に作成され、破棄される。該動的オブジェクトには、格納部に格納された、または、スクリプト化された構成設定情報が無い。
【００２６】
次に、処理系ライブラリがCEE７５とどのように相互作用するか、システムレベルで説明する。CEE７５は、リクエストを実行してカプセル内のオブジェクトを起動し、停止する。さらに、上記CEEは、前述したように、カプセル間オブジェクト呼出し８２および他のCEE８４からのリクエストを用意にする。クライアントアプリケーションまたはサーバのアプリケーションからのオブジェクト呼出しを満足させなければならないとき、オブジェクト起動リクエストが発生する。オブジェクトを起動するため、CEE７５は、そのオブジェクトのメソッドを包含する適当な処理系ライブラリを（まだロードしていない場合）ロードし、次いで、構成設定されたオブジェクト初期化ルーチンを呼出しする。この初期化ルーチンは、処理系ライブラリがどのインターフェイスを支援するか指定し、後でCEEに呼び出されるオブジェクトのメソッドのエントリ（入口点）を記憶する。
【００２７】
クライアントおよびサーバのシステムが始動すると、クライアント側とサーバ側の両CEEがそれぞれ自己の初期化を実行する。この初期化は、各種の処理系ライブラリをどこで捜索すべきかをクライアントおよびサーバのCEEに伝える。CEEによって見つけられると、クライアントおよびサーバのアプリケーションの初期化ルーチンが呼び出される。クライアントアプリケーションおよびサーバアプリケーションに含まれるこの初期化ルーチンは、必要とされるアプリケーションに固有の初期化を先ず実行しなければならない。次に、クライアントおよびサーバの両初期化ルーチンがスタブ関数を呼出し、このスタブ関数が、CEE_INTERFACE_CREATEと呼ばれる（上述のような動的ライブラリに含まれる）CEE関数をダウンコールして当該オブジェクトのインターフェイスを指定する。インターフェイスはオブジェクト毎に指定すればよい。インターフェイス記述は、以下で説明するように、通常はそのインターフェイスのIDL記述から生成される。CEE_INTERFACE_CREATEは、インターフェイスを作成し、新規に作成されたインターフェイスに“インターフェイスハンドル”を返す。このハンドルは、該インターフェイスを指定する固有識別子である。次いで、サーバアプリケーション初期化ルーチンがインターフェイスハンドルを用いてCEE_IMPLEMENTATION_CREATEをダウンコールする。CEE_IMPLEMENTATION_CREATEは、１つまたはそれ以上のオブジェクトが使用できる処理系記述を作成する。CEE_IMPLEMENTATION_CREATEは、インターフェイスの各オペレーションの処理系を指定する固有識別子である“処理系ハンドル”を返す。最後に、サーバアプリケーション初期化ルーチンが処理系ハンドルを使用して、CEE_SET_METHODをダウンコールするスタブ関数を呼び出す。CEE_SET_METHODは、サーバアプリケーションに含まれる処理系の特定のメソッドルーチンの実アドレスを指定する。これでCEEは、クライアントアプリケーションのオブジェクト呼出しをサーバアプリケーションの特定メソッドに接続するのに十分な情報を有する。
【００２８】
III．IDLソースファイルのコンパイルおよびリンク
図４は、IDLソースファイルが、コンパイルされ、本発明の方法および装置を使用するクライアントアプリケーションおよびサーバアプリケーションにリンクされる手順を示す。先ず、IDLインターフェイス定義を含むIDLソースファイル１０１が作成される。IDLコンパイラ１０３は、IDLソースファイル１０１をコンパイルする。IDLコンパイラ１０３は、コード１０１を解析して中間のPickled IDL file（PIF）ファイル１０５を生成し、オリジナルソースファイルを格納する。次にコードジェネレータ１１１がPIFファイルを解析する。PIFファイルの生成は以下のセクションVIで説明する。好ましくは、IDLコンパイラとコードジェネレータ１１１は、コードを生成するため組み合わされる。コードジェネレータ１１１は、クライアントアプリケーションおよびサーバアプリケーションの言語でファイルを生成する。クライアントアプリケーションとサーバアプリケーションの言語が異なる場合、異なるコードジェネレータが使用される。代案として、コードジェネレータ１１１およびIDLコンパイラ１０３を単一アプリケーションに合体させて言語に固有のコードを生成するようにしてもよい。コードジェネレータ１１１は、クライアントスタブ関数を含むクライアントスタブファイル７９と、オブジェクト処理系についての定義を含むサーバスタブファイル８９を生成する。クライアントスタブファイル７９およびサーバスタブファイル８９は、プログラミング言語に固有のコンパイラ１２１、１２３でコンパイルされて、コンパイルされたクライアントスタブオブジェクトコードおよびコンパイルされたサーバスタブオブジェクトコードを生成する。同様に、クライアントアプリケーション７７およびサーバアプリケーション８７は、プログラミング言語に固有のコンパイラでコンパイルされて、コンパイルされたクライアントアプリケーションオブジェクトコードおよびコンパイルされたサーバアプリケーションオブジェクトコードを生成する。クライアントアプリケーション７７およびサーバアプリケーション８７は、コードジェネレータ１１１によって生成されたヘッダファイル１１９をさらに含む。このヘッダファイル１１９は、共通の定義および宣言を含む。最後に、言語コンパイラ１２１が、上記クライアントアプリケーションオブジェクトコードとクライアントスタブオブジェクトコードをリンクすることにより、処理系ライブラリ７１を生成する。同様に、第２のコンパイラが、上記サーバアプリケーションオブジェクトコードとサーバスタブオブジェクトコードとをリンクすることにより、処理系ライブラリ１２４を生成する。
【００２９】
さらに、ヘッダファイル１１９，クライアントスタブファイル１１５およびサーバスタブファイル１１７は、コンパクトIDL表記法（“ＣＩＮ”）と称する各IDL定義データ構造体のコンパクト版を含む。CINは、特別な表記法を使用するIDLデータ構造体のASCII（または他の文字に基づく）表現である。CIN記述子は、クライアントアプリケーション７７とサーバアプリケーション８７の両方に含まれるヘッダファイル１１９に含まれている。この記述子はクライアントとサーバのスタブファイルにも含まれている。クライアントアプリケーションおよびサーバアプリケーション７７，８７がCINにアクセスできるので、PCUライブラリ１３０によって提供された汎用関数を異種通信者間で使用することができる。コードジェネレータによるCINの作成については以下のセクションＶで説明する。
【００３０】
IV．データ構造体の移送
ここで本発明の方法を説明する。本発明の方法および装置は、ランタイムにクライアントアプリケーションおよびサーバアプリケーションが利用可能な汎用関数またはルーチン群（PCUライブラリ１３０）を用いて実行される。これらのルーチンは、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記述を“準備”しなければならない。PCU_PREPAREがクライアントとサーバの双方から呼び出される。この呼び出しには費用が比較的かかるので、初期化時のPCU_PREPAREに対する一回の呼び出しにより、貴重なシステム資源をセーブすることができる。上記呼び出しは、好ましくは、クライアントアプリケーションおよびサーバアプリケーションの初期化ルーチン時に行われる。PCU_PREPAREは、Ｃ言語において次のように定義される。
【００３５】
【数１】
2007234047.tif 000003
この関数において、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データ構造体を最初に作成することにより、それらのop_tagを作成する。ctx構造体を使用することは、個々のパラメータを各種の内部関数に送ることより望ましい。ctx構造体はC言語で次のように定義される。
【００３７】
【数２】
2007234047.tif 000004
前記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_branchは、前に処理された共用体ブランチ（union branch）オペレーションを指示する。このフィールドのリストは、ヘッドが主共用体オペレーションに含まれるブランチオペレーションのリストの構築に使用される。共用体オペレーションはmain_unionによって指示される。
【００３８】
ctx構造体が作成されると、PCU_PREPAREは、CIN文字列中の各文字ごとにPROCESS_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バッファから１つの符号付きlong整数を抜き出し、その値をPCU_PREPAREに戻す。TAKE_ULONGは、CINバッファから１つの符号無しlong整数を抜き出し、その値をPCU_PREPAREに戻す。これらの値は、PCU_PREPAREがop_tagデータ構造体のテーブルを作成するのに使用される。
【００４０】
各呼出し毎に、PROCESS_CIN_ITEMはctxデータ構造体を変更する。先ず、PROCESS_CIN_ITEMがopポインタを増分して上記構造体の他のフィールドを適正CINアイテムに対応させる。さらに、ctx構造体のsize、alignおよびoffsetフィールドが変更される。各データ型のためのアラインメントは、以下のアラインメント規則に基づいて決定される。基本データ型がそのサイズに合わされる。従って、sortデータ型は２バイトのアラインメントを有し、long型は４バイトアラインメントを有し、等々である。Struct型および共用体型は、最高アラインメント要求付きの包含フィールドと同じアラインメントを有する。ともかく、struct型および共用体型は、好ましくは、少なくとも２バイトのアラインメント要求を有する。最後に、struct型および共用体型は、好ましくは、多数のアラインメント要求に埋め込まれる。
【００４１】
PROCESS_CIN_ITEMへの呼出しが戻るたびに、PCU_PREPAREは変更されたctx構造体に基づいてop_tagデータ構造体を作成する。次いで、これらのop_tag構造体のアレイが、PCU_PREPAREの呼出し後に、準備CINバッファであるprepbufに格納される。このop_tag構造体は、他の関数によって簡単に操作できる線形構造体である。構造体op_tagは、以下のように定義される。
【００４２】
stuct op_tag {
type_def        type;
long            offset;
long            align;
long            size;
long            nr_elements;
long            branch_label;
char            is_default_branch;
char            is_simple;
char            reserve_XXX;
op_def     *sequence_end;
op_def     *next_branch;
op_def     *union_end;
op_def     *default_branch};
【００４３】
type（型）パラメータは、上記データ構造体のIDLデータ型を表す。type_def型定義は、考えられる全データ型を列挙するものである。パラメータoffsetは、そのデータ構造体がある構造体または共用体の一部である場合、包含する構造体または共用体の始端からの該構成要素データ型のオフセットである。データ型（１、２、３、４または８バイト）が要求するアラインメントは、alignパラメータによって指定される。sizeパラメータは、丸めを含むバイトでデータ構造体のサイズを示す。nr_elementsパラメータは、様々異なる目的に使用される。アレイについて、このパラメータは、全次元の要素の総数を示す。シーケンスについて、上記パラメータは、最大出現回数を示す。文字列について、上記パラメータは、ゼロ終了を除く最大サイズを指定する。構造体について、上記パラメータは、その構造体中の主フィールドの数を示す。共用体については、上記パラメータは、共用体中のフィールド数を示す。パラメータbranch_labelおよびis_default_branchは、共用体ブランチのみのためのものである。branch_labelパラメータは、上記共用体のIDL仕様において指定されたcaseラベル値を含み、is_default_branchパラメータは、エントリが既定共用体ブランチを記述する場合、真（true）である。is_simpleパラメータは、データ構造体がIDL基本データ型の場合は真で、該データ構造体が混成型の場合は偽（false）のブール論理である。*next_branchパラメータは、共用体および共用体ブランチに使用され、該共用体に属する次のブランチエントリのアドレスを指示する。共用体エントリの場合、上記パラメータは、第１のブランチを指す。最後のブランチの場合、上記パラメータは値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は、Ｃ言語で次のように定義される。
PCU_PACK (
char            dst_integer_fmt,
char            dst_real_fmt,
char            dst_char_fmt,
const void      *prepbuf,
const void      *inbuf,
long            outbuf_max_len,
void            *outbuf,
long            *outbuf_len);
【００４６】
最初の３つのパラメータは、出力バッファへのデータの詰め込み方を指定する。これらのパラメータは、コーラ（呼出し側）によって提供された変換を実行するための呼出側定義関数でよい。第１のパラメータdst_integer_fmtは、出力バッファにおいてshort型、long型およびlongデータ型に使用する書式を指定する。この書式に関して可能な値の例は、バイト重要度がアドレスの増加につれて減少する場合の整数表現を指定するPCU_INTEGER_BIGENDIAN、又は、バイト重要度がアドレスの増加につれて増加する場合の整数表現を指定するPCU_INTEGER_LITTLEENDIANである。パラメータdst_real_fmtは、出力バッファでフロート（float）および倍（double）データ型に使用する書式を指定する。このパラメータのサンプル値は、例えばTandem T16書式を使用する浮動小数点数表現を指定するPCU_REAL_T16などの、標準IEEE書式またはベンダ指定値を使用する浮動小数点数表現を指定するPCU_REAL_IEEEである。第３のパラメータ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が上記関数によって戻された場合、outbuf_lenパラメータは必要なoutbufサイズを取得する。
【００４８】
従って、出力バッファにメモリを動的に割り当てるため、クライアントアプリケーションは、PCU_PACKを２回呼び出すことができる。最初の呼出しで、outbuf_max_lenが設定される。次いでPCU_PACKがPCU_SHORTBUFを戻し、outbuf_lenが必要な出力バッファサイズを含むこととなる。ここで出力バッファの正しいメモリ量をPCU_PACKの２回目の呼出に先立って割り当てることができる。
【００４９】
PCU_PACKは最初にctx構造体を生成する。このctx構造体は、PROCESS_CIN_ITEMによって使用されるコンテキスト構造体と同様の関数を提供する。上記構造体は、大量のコンテキストがPCU_PACKと、PCU_PACK_ENGINEによって呼び出される低水準ルーチンとの間で共用されることを可能にする。上記ctx構造体は、PCU_PACKに対する下位関数によって使用され、次のように定義される。
【００５０】
struct pack_ctx_tag {
char    dst_integer_fmt,
char    dst_real_fmt,
char    dst_char_fmt,
char    *outptr,
char    *outbuf_end
}
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_PACKへの呼出し時に指定された変換に基づいて適正な低水準関数を呼び出す。この低水準関数はデータを透明的（不可視的）にパックするか、指定された変換を実行する公知の低水準関数である（例えば、LITTLEendianに対するBIGendian）。各コーラ供給関数は、入力バッファからデータを取り出し、このデータを出力バッファ内に格納する。入力バッファから取り出されるバイトの数は、PCU_PACK_ENGINEから上記関数に提供されたサイズパラメータによって指定される。上記データが出力バッファに配置されると、上記低水準関数がctx構造体のoutptrを変更し、出力バッファに書き込まれた最後バイトの次のバイトを指示する。
【００５３】
PCU_PACK_ENGINEは、上記の各種の低水準関数を用いてデータを出力バッファに次のように格納する。入力バッファ中の構造化データ型は、最初にIDLで定義されたのと同じ順序で出力バッファに密に（バイト調整して）格納される。正しいアラインメントを実現するためコードジェネレータによって挿入された任意のパディングフィールドの内容は捨てられる。同様に、上記関数はデフォルト値を上記フィールドに配置しない。
【００５４】
基本型データ構造体は、PCU_PACKへの呼出し時にdst_XXX_fmtパラメータによって指定された表現で出力バッファに格納される。典型的に、これらのパラメータは、無変換でパッカー（packer）の固有書式に設定される。従って、サーバアプリケーション（アンパッカー）が現実の変換を行うことになる。しかし、本発明で使用するルーチンは、データ構造体の変換の実行をも許容する。
【００５５】
short、符号なしshort、long、符号なしlong、long longsおよび符号なしlong longsの表現は、PCU_PACKに対するdst_real_fmtにおいて指定されている。このパラメータは、浮動小数点数字を表す書式を指定する。浮動型と倍（double）型のアラインメントは、dst_real_fmtパラメータによって指定される。このパラメータは、整数を表現する書式に対応する。charsの表現はdst_char_fmtパラメータによって指定される。このdst_char_fmtパラメータは、文字を表現する書式を指定する。ブール論理およびオクテット（octets）は再アラインしない。上記“任意”型は、（アラインメントがdst_integer_fmtパラメータに基づいている）CIN記述の長さを指定する符号なしlong、型を記述するCIN文字列（未変換ASCII文字列）および（この変換規則に基づいて格納された）データ自体として格納される。
【００５６】
アレイ、共用体などの混成型も再アラインされる。アレイは要素間にパディングなしで格納される。シーケンスは、上記出現回数の前の出現回数を示す符号なしlong整数として格納される。出現間のパディングは除去される。long整数の書式は、上述のdst_integer_fmtパラメータによる。文字列は、charsとして格納された特定数の文字前の文字列長を示す符号なしlongとして格納される。charの書式は、dst_char_fmtパラメータによって決定される。構造体はパディングなしでフィールド毎に格納される。共用体は活性共用体ブランチが続くlong型として格納される。
【００５７】
受け取り側において、サーバアプリケーションは、PCU_PACKを使用してパックされたバッファから未構造化データ型およびその付属物を抽出しなければならない。次いでPCU_UNPACKが、その未構造化データを、任意のデータ構造体の準備CINに基づいてそのデータ構造体に格納する。PCU_UNPACKは次のように定義される。
PCU_UNPACK (
char        src_integer_fmt,
char        src_real_fmt,
char        src_char_fmt,
const void         *prepbuf,
const void         *inbuf,
long        inbuf_len,
long        outbuf_max_len,
void        *outbuf,
long        *outbuf_len,
long        *inbuf_used);
【００５８】
最初の３つのパラメータは、PCU_UNPACKの最初の３つのパラメータに対応する。これらのパラメータは、入力バッファに格納されたデータ型の書式を指定する。これらのパラメータは、好ましくは、そのPCU_PACK版と同一である。上記*prepbufパラメータは、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の下位関数によって使用され、次のように定義される。
struct pack_ctx_tag {
char    src_integer_fmt,
char    src_real_fmt,
char    src_char_fmt,
char    *inptr,
char    *inbuf_end
}
【００６０】
最初の３つのパラメータは、PCU_UNPACKに渡された書式である。これらのパラメータは、IDL“任意”型を処理するためPCU_PACKが巡回的に呼び出される場合に内部関数によって必要とされる。上記inptrは、入力バッファから読み出される次のバイトを指す。上記inbuf_endポインタは、入力バッファにおける最終バイト＋１を指す。
【００６１】
コンテキスト構造体の生成後、PCU_UNPACKは、PCU_UNPACKに機能性を提供するPCU_UNPACK_ENGINEを呼び出す。PCU_UNPACK_ENGINEは、入力バッファ（PCU_PACKによって提供された出力バッファ）からデータを抽出し、そのデータを出力バッファに配置するためのコーラ供給関数へのポインタを受け取る。準備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表記法
図８は、ＩＤＬソースファイルに含まれるＩＤＬデータ型、オペレーションおよびインターフェースからのＣＩＮ記述子生成を示すフローチャートである。なお、図８〜図１０のステップは、メモリに格納されたコンピュータ命令を実行するデータ処理システムのＣＰＵによって実行されるものである。ステップ８０１において、コードジェネレータは、前記ＩＤＬソースファイルの最初の行から開始し、該ＩＤＬソースファイルに記述されたデータ構造体、インターフェースまたはオペレーションを確認する。前記記述されたデータ構造体がインターフェースである場合、前記コードジェネレータは、図１０に示された方向に従って処理する。前記記述されたデータ構造体がインターフェース内のオペレーションである場合、前記コードジェネレータは、図９に示された方向に従って処理する。前記記述されたデータ構造体がデータ型（または、後述するようなオペレーションのためのパラメータ）である場合、前記ジェネレータは、定義テーブルに基づいて１つの文字を生成する。なお、ここに含まれるチャートに示したもの以外の文字が使用されてもよい。各チャートは、好ましいＡＳＣＩＩ文字のみを含んでいる。チャートＡは、様々なＩＤＬ基本型を示すために使用される文字列を含む好ましい定義テーブルを示すものである。
【００６７】
【表１】
2007234047.tif 000005
このチャートＡに示すように、ＣＩＮ記述子における基本型を表現するために簡単な文字列が使用される。
【００６８】
データ型がアレイまたは構造体（struct型）のような混成型である場合、一連の異なるステップが行われる。ステップ８１１では、前記混成型のスタートを示す文字が生成される。チャートＢは、様々なＩＤＬ混成型のスタートを示すために使用される文字列を含むサンプルテーブルを示す。
【００６９】
【表２】
2007234047.tif 000006
各混成型の具体的な表現は、その型に応じて異なる方法で取り扱われる。
【００７０】
ＩＤＬは、各基本型ごとに多次元で固定サイズのアレイを定義する。前記アレイのサイズは、コンパイル時に決定される。アレイはＣＩＮにより次のように表現される。
ａnr_dimensions size_1.[size＿2,...size_n]base type
前記アレイのための文字の生成は、ステップ８１３，８１５，８１７に示されている。このアレイ表現において、上記文字ａは（チャートＢに示すように）前記アレイのスタートを示している。文字nr_dimensionsは、該アレイにおける次元の数を示す数字である。また、文字size_1，size_2，size_nは、それぞれ、前記アレイの一次元、二次元およびｎ次元におけるサイズを示す。base-typeは、前記アレイの各アレイ要素ごとの記述子である。様々な基本型の表現は、チャートＡに示されたオリジナルの基本型テーブルから導出される。
【００７１】
ＩＤＬは、ユーザによって定義された構造体型を定義する。各構造体は、基本データ型または混成データ型の１つまたは複数のフィールドで構成される。構造体はＣＩＮにより次のように表現される。
ｂnr_fields field_１[field＿2...field_n]
１つの構造体を記述する文字の生成は、ステップ８１９およびステップ８２１に示されている。チャートＢに示すように、上記文字ｂは前記構造体（struct）のスタートを示している。数字nr_fieldsは、前記構造体におけるフィールドの数を示す。前記構造体におけるフィールドは、field_１，field＿2,field_nによって記述される。各フィールドは基本型または混成型である。前記構造体の基本型フィールドは、チャートＡに示されているように記述される。混成型はここに示されているように記述される（すなわち、アレイは、次元の数および各次元のサイズ、スタート文字ａ等で記述される）。
【００７２】
ＩＤＬは、データ型のシーケンスを定義する。１つのシーケンスは、２つの特性、すなわち、（コンパイル時に決定される）最大サイズと（実行時に決定される）長さとを有する１次元のアレイである。シーケンスは次のように表現される。
ｃnr-occurrences base_type
前記シーケンスのための文字の生成は、ステップ８２３，８２５に示されている。この表現において、上記文字ｃは、チャートＢに示すように、前記シーケンスのスタートを示している。文字nr_occurrencesは、該シーケンスにデータ型の出現回数を示す。該出現回数の後には、前記シーケンスにおけるデータ型出現ごとの実際の記述子base_typeが続く。データ型が基本型である場合、チャートＡの適当な記述子が使用される。前記シーケンスが混成型である場合、記述子はここに説明されているように作成される。シーケンスのシーケンスも可能である。
【００７３】
ＩＤＬは、空（null）文字を除くすべての８ビットの量（quantity）で構成される文字列（String）型を定義する。１つの文字列は、charのシーケンスに類似している。文字列はＣＩＮにより次のように表現される。
ｄsize
文字列のスタートは文字ｄで示される。該文字列のサイズは、ステップ８２７で生成される文字sizeによって示される。
【００７４】
ＩＤＬにおいて、共用体（union）は、Ｃプログラミング言語の“共用体”とＣ“switch”文との間の交配体である。換言すれば、共用体シンタクスは、共用体ブランチを示す“case”ラベルと共に“switch”文を含むものである。ＩＤＬ共用体は区別されなければならない。すなわち、共用体のヘッダは、現在の呼出しインスタンスにどの共用体要素を使用すべきかを決定する型別タグフィールドを指定しなければならない。共用体および共用体ブランチは、ＣＩＮにより次のように表現される。
ｅnr_fields ｆlabel_1 field_１[ｆlabel_2 field_2 ...label_n field_n]
共用体および共用体ブランチを示す文字の生成は、ステップ８２９，８３１，８３３，８３５に示されている。この表現において、ｅは共用体のスタートを示し、ｆは該共用体内の共用体ブランチのスタートを示す。該共用体におけるフィールドの数は、文字nr_fields によって明示される。各フィールドのcaseラベル値は、文字label_1によって示される。フィールドがデフォルトである場合、前記ラベルは省略される。次に、各フィールドごとの記述子field_１がくる。前記共用体のフィールドは、基本型または混成型のいずれであってもよい。従って、基本型のフィールド記述子は、チャートＡに基づいて生成されてよい。混成型はここに説明されているように生成される。
【００７５】
基本型および混成型の記述から分かるように、ＣＩＮ記述は前記オリジナルのＩＤＬソースファイルに含まれる識別子を含まず、汎用関数が生成される。従って、最も複雑なデータ構造であっても、文字列フォーマットで容易に表現され得る。下記のものは元々ＩＤＬで記述されたサンプル構造体である。
【００７６】
【数３】
2007234047.tif 000007
【００７７】
この発明の方法を使用することにより、上記のデータ構造はＣＩＮにより次のように表現される。
“c100+e2+f0+b2+FFf1+b2+KK”
好ましい実施の形態において、正の数字の後には正符号（“＋”）が付けられており、負の数字の後には負符号（“−”）が付けられている。負の数は頻繁には現れないが、負の数の使用は、例えば共用体のcaseラベルのようなデータ型に必要となる（すなわち、case識別子は負の数であることがある）。上に示したＣＩＮ記述子について以下に説明する。データ構造は最大の１００固の要素（１００＋）を有する１つのシーケンス（ｃ）で構成され、各前記要素は２個のフィールド（２＋）を有する１つの共用体（ｅ）で構成されている。識別子がゼロ（偽）（ｆ０＋）である場合、１つの変形体は２個のフィールド（２）を含む構造体（ｂ）である。１番目のフィールドは符号付きのlong（Ｆ）である。２番目のフィールドは符号付きのlong（Ｆ）である。識別子が１（真）（ｆ１＋）である場合、第２の変形体は２個のフィールド（２＋）を含む構造体（ｂ）である。１番目のフィールドは符号無しのlong（Ｋ）である。２番目のフィールドは符号無しのlong（Ｋ）である。
【００７８】
オペレーションをＣＩＮで記述する場合、前記方法はステップ９５１に進む。図９は、オペレーションのための記述子を生成するためのステップを示すフローチャートである。オペレーション記述子は、ＣＩＮにより次のように生成される。
【数４】
2007234047.tif 000008
【００７９】
ステップ９５１において、前記コードジェネレータは、前記オペレーションの記述子の残部を構成する文字列から導出されるユニークな整数operation_synopsisを生成する。該整数は、前記ＣＩＮ記述子における残りの文字について例えば巡回冗長検査を実行することによって導出される。次に、前記コードジェネレータは、前記オペレーションの本来のＩＤＬ名から導出されるユニークな文字列operation_idを生成する。次に、ステップ９５５において、前記コードジェネレータは、前記オペレーションの属性（無しまたは“一方向”）を示す文字であるoperation_attributeを生成する。例えば、前記オペレーションが一方向属性を有さない場合、文字Ａが生成される。しかし、前記オペレーションが一方向である場合、前記コードジェネレータは文字Ｂを生成する。文字nr_paramsは、前記オペレーション中にいくつのパラメータが含まれるかを示す整数である。前記オペレーションが非空き（non-void）リターン型を有する場合、１番目のパラメータがその結果である。param_1記述子は、その後に実際のパラメータデータ型が続くことになる前記パラメータの方向（in、out、inoutまたは関数結果）を示す文字を含む。例えば、前記コードジェネレータは、in、out、inoutおよび関数結果の方向について、それぞれ、文字Ａ，Ｂ，ＣおよびＤを生成する。これら特定のパラメータについて、図８のステップ８０７にリターンする。各パラメータのデータ型が記述されたとき、例外の数が整数nr_exceptionsによって示される。そして、ステップ１１９にリターンすることによって、各例外の構造記述がなされる。整数nr_contextsは、前記オペレーションによって保持されるコンテキスト名の数を示す。これらのコンテキスト名は、文字列context_1，context_2，context_nで生成される。
【００８０】
次のものは元々ＩＤＬで記述された２つのサンプルオペレーションである。
interface Math{
long Add(in long x,in long y);
long Subtract(in long x,in long y);
};
【００８１】
この発明の方法を使用することによって、上記AddオペレーションはＣＩＮにより次のように表現される。
126861413+3+ADDA3+DFAFAF0+0+
【００８２】
前記オペレーションのＣＩＮ記述子は次のように説明される。最初の数字（126861413）は、文字列“3+ADDA3+DFAFAF0+0+”について巡回冗長検査を実行することによって、前記ＣＩＮの残部から導出される。オペレーションｉｄは３つの文字（３＋）を含む。これらの３つの文字は、オペレーションｉｄとしての文字列“ADD”である。すべてのＩＤＬ識別子は、固有のものであり、caseとは独立でなければならない。従って、オペレーションｉｄは大文字とされる。前記オペレーションは、一方向性属性（Ａ）を含まず、３つの“パラメータ”（３＋）を含む。前記関数が結果を返すので、実際上、最初の“パラメータ”が関数結果（Ｄ）である。前記関数結果は符号付きのlong（Ｆ）である。次のパラメータ（実際上、最初のパラメータ）はｉｎパラメータ（Ａ）である。該パラメータは、型分類された符号付きのlong（Ｆ）のパラメータである。３番目のパラメータは、型分類された符号付きのlong（Ｆ）のinパラメータである。例外およびコンテキストは存在しない（０＋）。
【００８３】
同様に、上記SubtractオペレーションはＣＩＮ記述子により次のように表現される。
453399302-9+SUBTRACTA3+DFAF0+0+
【００８４】
インターフェイスも、この発明の方法を使用することによって同様に記述される。図１０はインターフェイス記述子の生成を示す。インターフェイスは次のように定義される。
nr_operations
operation_spec_1
operation_spec_2
operation_spec_n
整数nr_operationsは、該インターフェイスに含まれるオペレーションの数を示す。各オペレーションは、オペレーション記述子を生成するための上記方法に従って、operation_spec_1，operation_spec_2，operation_spec_nで記述される。こうして、前記コードジェネレータ１１２は、図９のステップ９５１に進み、各オペレーションを記述する。
【００８５】
この発明の方法を使用することによって、上記AddオペレーションはＣＩＮにより次のように表現される。
2+126861413+3+ADDA3+DFAFAF0+0+453399302-9+SUBTRACTA3+DFAF0+0+
【００８６】
前記インターフェイスは２つのオペレーション（２＋）を含む。上記AddオペレーションおよびSubtractオペレーションのオペレーション記述子は、オペレーションの数を示す文字の次にくる。
【００８７】
上述の如く、ＣＩＮ記述子は、クライアントアプリケーションおよびサーバアプリケーションの両方にリンクされるヘッダファイルに含まれる。こうして、クライアントおよびサーバの両方は、各々が適当と考える記述子を利用することができる。前記ＣＩＮは様々な形態で使用可能である。例えばデータ型のＣＩＮ記述子は、構造化されたデータ型をパックしたりアンパックしたりするための汎用関数を作成するのに有用であろう。
【００８８】
さらに、ＣＩＮ記述子は、迅速にインターフェイスを比較するためにも使用可能である。例えば、サーバアプリケーションは、ＣＩＮで記述された２つのインターフェイスを含むヘッダファイルを有してもよい。この場合、該サーバアプリケーションは、既知の文字列比較関数を使用してＡＳＣＩＩ文字列記述子を比較することができる。ＣＩＮ記述が同一である（または類似している）場合、サーバは、サーバアプリケーションにおいて共通の方法を使用して両インターフェイスのオペレーションを実行することができる。こうして、上記ＣＩＮを使用して、異なる（しかし類似している）インターフェイスのための多数の時間コード化方法をセーブする。
【００８９】
VI．ピクルドＩＤＬフォーマットデータ構造体の作成
ピクルド（pickled）ＩＤＬフォーマット（“ＰＩＦ”）データ構造体は、クライアントメモリ２３およびサーバメモリ１７にロードされたＩＤＬコンパイラおよびコードジェネレータと共に使用されるよう設計されている。該データ構造体は、メモリ２３またはメモリ１７に格納されたＩＤＬソースファイルに基づいている。該ソースファイルも、ディスクのようなコンピュータによって読取り可能な媒体に格納されることができる。このデータ構造体は、ＩＤＬソースファイルを示す解析ツリーを含んでいる。該データ構造体は、メモリ２３またはメモリ１７あるいはディスクのようなコンピュータによって読取り可能な媒体に格納可能である。前記ソースファイルを示す前記データ構造体は、ピクルドＩＤＬフォーマット（“ＰＩＦ”）と呼ばれている。該ＰＩＦファイルは、前記ソースファイルに定義されたインターフェイスを使用するクライアントおよびサーバにより実行時にアクセス可能である。該ＰＩＦファイルに含まれる解析ツリーは、ポインタの代りにアレイインデックスを使用するアレイである。このアレイインデックスの使用により、その結果としての解析ツリーは言語とは独立したものとすることができる。前記アレイの最初の構成要素は使用されない。前記アレイの２番目の構成要素（インデックス１）は、前記解析ツリーの残りの部分へのエントリポイントとして機能するルート部である。
【００９０】
図１１にはデータ構造体tu１１０１が示されており、これは次のようにＩＤＬによって定義される。
strunct tu_def{
sequence<entry_def>      entry;
sequence<string>         source;
}
前記データ構造体１１０１は、その各々がentry_defタイプ（後で定義）である解析ツリーノード１１０５のシーケンス（可変サイズアレイ）およびソースファイルライン１１０７のシーケンスを含む。前記ソースファイルライン１１０７のシーケンスは、前記ＩＤＬソースファイルからの実際のソースコードラインを含む文字列シーケンスである。
【００９１】
各解析ツリーノード（または“エントリ”）１１０５は、該ノードの名前およびその特性を含む固定部、ならびに、前記ノードのタイプによって決まる可変部で構成される。前記解析ツリーノードは図１２に示されており、これは次のようにＩＤＬによって定義される。
【００９２】
【数５】
2007234047.tif 000009
【００９３】
前記解析ツリーノードの固定部はentry_index１２０５を含み、これは前記解析ツリーにおけるこの特定のエントリのインデックスである符号なしlongである。前記エントリの非修飾名は、nameフィールド１２０７に含まれる。オリジナルのＩＤＬソースファイルの名前は、file_nameフィールド１２１１に含まれる。line_nrフィールド１２１３は、この解析ツリーノードを作成させる前記ＩＤＬソースファイルにおけるライン番号を含む。ブールin_main_file１２１５は、コマンドライン上に指定されたＩＤＬソースファイルにおいてエントリがなされたか否か、または、前記エントリが“include”ファイルの一部か否かを示す。このファイルに続いて、前記解析ツリーは、可変部、すなわち、識別子entry_type_defを有する共用体１２１７を含む。前記共用体識別子entry_type_defは、ノードのタイプおよびentry_def内のどの変数がアクティブなのかを指示する。entry_type_defは次のように定義される列挙である。
【００９４】
【数６】
2007234047.tif 000010
【００９５】
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）は、前記解析ツリーエントリにおいて、前記アレイの基本型を保持する符号なしのlong、および、前記アレイのサイズを保持するlongのシーケンス含む構造体によって表現される。シーケンス（entry_sequence）は、前記シーケンスの基本型および最大サイズを保持する符号なしのlongを含む構造体によって表現される。
【０１０４】
タイプ定義（entry_typedef）の場合、前記解析ツリーエントリは、前記タイプ定義の基本型を示す符号なしのlongの値を含む構造体によって表現される。予め定義されたタイプ（entry_pre_defined）は、データ型を含む構造体によって表現される。前記タイプを指示するために、前記各種基本型の列挙が使用されるのが好ましい。
【０１０５】
前記tuデータ構造体を使用して前記ＩＤＬソースが記述されると、前記データ構造体は任意の既知の方法を使用してファイルまたはデータベースに移送される。
【０１０６】
以上のように移送に便利な書式におよび該書式から、ＩＤＬ定義されたデータ構造体を変換するための本発明方法および装置の好ましい実施の形態について説明してきたが、この発明の範囲および精神の範囲内で様々な変更が可能である。例えば、ＩＤＬ定義されたデータ構造体について説明したが、データ構造体が前記コードジェネレータと同一のアライメント定義に従うものである場合、上述した発明の概念は、手書きのデータ構造体にも同様に適用可能である。
【図面の簡単な説明】
【０１０７】
【図１】本発明の方法または装置を用いた分散型コンピューティング環境を示す図である。
【図２Ａ】共通実行環境（CEE）の基本構造を示す図である。
【図２Ｂ】共通実行環境（CEE）の基本構造を示す図である。
【図３】従来のIDLソースファイルのコンパイルおよびリンクを示す図である。
【図４】本発明の方法を用いたIDLソースファイルのコンパイルおよびリンクを示す図である。
【図５ａ】IDL定義されたデータ構造体、生成されたCIN記述および生成されたop_tag構造体アレイを示す図である。
【図５ｂ】IDL定義されたデータ構造体、生成されたCIN記述および生成されたop_tag構造体アレイを示す図である。
【図６】本発明の方法に係るクライアント側の第１の好適実施例を説明するフローチャートである。
【図７】本発明の方法に係るサーバ側の第１の好適実施例を説明するフローチャートである。
【図８】基本データ型および混成データ型のためのCIN記述子の生成を説明するフローチャートである。
【図９】オペレーションのためのCIN記述子の生成を説明するフローチャートである。
【図１０】インターフェイスのためのCIN記述子の生成を説明するフローチャートである。
【図１１】PIFデータ構造体を示す図である。
【図１２】エントリデータ構造体を示す図である。
【図１３】オペレーションデータ構造体を示す図である。
【図１４】共用体データ構造体を示す図である。
【符号の説明】
【０１０８】
１０  分散型（クライアント／サーバ）コンピューティング環境
１１  サーバコンピュータ
１２  ネットワーク接続部
１３  格納サブシステム
１５  ＣＰＵ
１７  メモリ
２０  バスまたはI／Oチャンネル
２１  クライアントコンピュータ
２３  メモリ
２７  ＣＰＵ
２９  入力装置
３３  表示装置
３３３  ディスク格納サブシステム
４０  バスまたはI／Oチャンネル
【図１】
2007234047.tif 000011
【図２Ａ】
2007234047.tif 000012
【図２Ｂ】
2007234047.tif 000013
【図３】
2007234047.tif 000014
【図４】
2007234047.tif 000015
【図５ａ】
2007234047.tif 000016
【図５ｂ】
2007234047.tif 000017
【図６】
2007234047.tif 000018
【図７】
2007234047.tif 000019
【図８】
2007234047.tif 000020
【図９】
2007234047.tif 000021
【図１０】
2007234047.tif 000022
【図１１】
2007234047.tif 000023
【図１２】
2007234047.tif 000024
【図１３】
2007234047.tif 000025
【図１４】
2007234047.tif 000026