JP2000515281A

JP2000515281A - インターフェイス定義言語によって定義されたインターフェイス、オペレーションおよびデータ型を記述するための方法および装置

Info

Publication number: JP2000515281A
Application number: JP10506110A
Authority: JP
Inventors: スコフィールド，アンドリュー
Original assignee: Compaq Computer Corp
Current assignee: Compaq Computer Corp
Priority date: 1996-07-11
Filing date: 1997-07-10
Publication date: 2000-11-14
Also published as: WO1998002808A1; EP0912933A1; US6263485B1; DE69727933D1; DE69727933T2; EP0912933B1

Abstract

(57)【要約】インターフェイス定義言語によって定義されたデータ型、オペレーションまたはインターフェイスを定義するための方法が説明されている。特に、前記データ型、オペレーションまたはインターフェイスを特定するＡＳＣＩＩ文字列識別子が発生される。データ型の基本型を識別するために文字が使用され、混成型およびこれら混成型の特徴を特定するために文字と数字との組合わせが使用される。オペレーションの場合、該オペレーションに含まれるパラメータの数および種類、例外の数、コンテキストの数を特定するために、文字および数字が使用される。インターフェイスは、該インターフェイスに含まれるオペレーションの数を示す数字を使用して記述される。オリジナルのＩＤＬ記述をＡＳＣＩＩ文字列識別子に変換することにより、異種システム間でオブジェクト呼出しを移送するための汎用関数が作成可能である。

Description

【発明の詳細な説明】インターフェイス定義言語によって定義されたインターフェイス、オペレーションおよびデータ型を記述するための方法および装置発明の背景１．発明の分野この発明は、インターフェイス定義言語によって定義されたインターフェイス、オペレーションおよびデータ型を記述するための方法および装置に関し、特に、一連のＡＳＣＩＩ文字を使用してデータ型を記述するものに関する。２．背景分散型オブジェクトコンピューティング方式は、分散型コンピューティングおよびオブジェクト指向型コンピューティングの概念を組合わせたものである。分散型コンピューティング方式は、相互に情報を共有する２つまたは３つ以上のソフトウエアで構成される。これら２つのソフトウエアは、同一のコンピュータ、または、共通のネットワークに接続された複数の異なるコンピュータ上で実行される。ほとんどの分散型コンピューティング方式は、クライアント／サーバモデルに基づいている。このようなクライアント／サーバモデルでは、大別して２種類のソフトウエア、すなわち、情報またはサービスを要求するクライアントソフトウエアと、情報またはサービスを提供または実行するサーバソフトウエアが使用される。前記オブジェクト指向型コンピューティングは、“オブジェクト”と呼ばれるコード（しばしば、現実世界における現実の対象から抽出される）がデータを含み、これらオブジェクトについて実行される行為（“オペレーション”とも呼ばれる）を含むことがあるオブジェクトモデルに基づくものである。各オブジェクトは、そのインターフェイス（または、Ｃ＋＋言語では“クラス”）によって定義される。前記インターフェイスは、該インターフェイスのオブジェクトについて実行されるオペレーション、および、該オペレーションのためのパラメータを含む、オブジェクトの特徴および作用を定義する。ある特定のオブジェクトは、分散型オブジェクトシステムにおいて、オブジェクト参照と呼ばれるユニークな識別子によって識別される。分散型オブジェクトシステムにおいて、クライアントアプリケーションは、サーバアプリケーションに対してリクエスト（または“呼びかけ”もしくは“オブジェクトコール”）を送る。このリクエストは、特定のオブジェクトについて実行すべきオペレーション、このオペレーションのためのパラメータ、前記オブジェクトのオブジェクト参照、および、リクエストの成功または失敗についてのエラー情報（または“例外情報”）を返すためのメカニズムを含んでいる。サーバアプリケーションは、前記リクエストを受け取り、サーバ“処理系”を介して前記リクエストを実行する。前記処理系は、特定のオブジェクトについてのオペレーションを要求するクライアントのリクエストに答える。前記処理系は、サーバアプリケーションにおいてその実行に関して要求された作業を実際に行うコード部分である１つまたは複数のメソッドを含む。前記処理系による実行が成功した場合、前記サーバアプリケーションは、必要に応じて、クライアントに対して回答を送る。前記サーバアプリケーションは、例外情報を返すこともある。分散型オブジェクトシステムを標準化するために、コンピュータソフトウエア会社の協会であるオブジェクト管理グループ（“ＯＭＧ”：Object Management Group）は、“ＣＯＲＢＡ”（Common Object Request Broker Architecture）を提案した。ＣＯＲＢＡ基準の下では、オブジェクトリクエストブローカ（“ＯＲＢ”）は、そのシステムにおけるすべてのオブジェクトのために、サーバに対してリクエストを送り、クライアントに回答を送る通信ハブを提供する。市販のＯＲＢは従来より知られており、一般的なタイプとしては、ＩＢＭのSystem Objec tModel（“ＳＯＭ”）がある。クライアント側のＯＲＢは、メソッドの呼出し（コール）、ならびに、これに関連したサーバおよびメソッドの選択を要求するリクエストを取り扱う。アプリケーションが、前記ＯＲＢに対して、１つのオブジェクトについて実行すべきメソッドを要求するリクエストを送ると、前記ＯＲＢでは、該リクエストに含まれる引数をそのオブジェクトのインターフェイスに対して検査し、該リクエストをサーバに送り、必要な場合それを開始する。サーバ側のＯＲＢは、前記リクエスト中の情報を使用して、該リクエストを満足させる最良の処理系を決定する。前記リクエスト中の情報には、前記クライアントが要求しているオペレーション、該オペレーションがどのオブジェクトについて実行されるかについての情報、さらに、前記リクエストについて格納されている付加情報が含まれる。さらに、前記サーバ側のＯＲＢは、各リクエストおよびその引数を検査する。さらに、該ＯＲＢは、前記クライアントに回答を送る機能も果たす。クライアントアプリケーションおよびサーバアプリケーションは、共に、オブジェクトおよびこれらのオブジェクトについて実行可能なオペレーションを含む利用可能なインターフェイスについての情報を有する必要がある。インターフェイス定義の共用化を容易にするために、前記ＯＭＧは、インターフェイス定義言語（“ＩＤＬ”）を提案した。該ＩＤＬは、オブジェクトのインターフェイス、すなわち、該オブジェクトについて実行可能なオペレーションを含む該オブジェクトの特徴および作用を記述するために使用される定義言語である（プログラミング言語ではない）。ＩＤＬインターフェイスは、クライアントがオブジェクトについて呼出し可能な１組のオペレーションを定義する。インターフェイスは、ＩＤＬオペレーションの実行が成功しなかったことを示す１つまたは複数の例外を宣言することができる。オペレーションは、パラメータを受け取り、返却値を返すことができる。オペレーションのための各パラメータは、その値がクライアントからサーバに送られるものか（すなわち、“イン（in）”なのか）、サーバからクライアントに送られるものか（すなわち、“アウト（out）”なのか）、また、これら両方向（“インアウト（inout）”）なのかを示す“方向”を有することができる。さらに、前記パラメータは、該パラメータが取り得る値を制限するデータ型を有する。さらに、前記オペレーションは、特定のオペレーションの呼出しのためにどの呼出し意味構造（semantics）が通信サービスによって提供されなければならないかを明示する“一方向”属性を任意に有していてよい。クライアントが一方向属性を有するオペレーションを呼び出す場合、前記呼出し意味構造は、前記オペレーションがサーバによってわずかに１回だけ実行されることを示す“最良努力”である。前記オペレーションを実行する試みが失敗した場合、前記サーバは、前記オペレーションの実行を再び試みない。一方向属性を有するオペレーションは、空（ボイド）返却の種類を明示しなければならず、出力パラメータを含んでいてはならない。ＩＤＬオペレーションパラメータの受入れ値、例外および返却値を記述するために、データ型が使用される。ＩＤＬは、２種類のデータ型、すなわち、基本型および混成型をサポートする。前記基本型は、short整数型、long整数型、longl ong整数型、符号なしのlong整数型、符号なしのshort整数型、浮動小数点（floa ting point）型、double型、文字（character）型、論理（boolean）型およびオクテット（octet）型を含む。また、前記混成型は、列挙（enum）型、文字列（s tring）型、構造体（struct）型、アレイ型、共用体（union）型、シーケンス型および“任意（any）”型を含む。前記構造体（struct）型は、Ｃ構造に類似しており、インターフェイス設計者が１つまたは複数の型定義を使用して混成データ型を作成することを可能にする。前記シーケンス型は、インターフェイス設計者が可変サイズのオブジェクトアレイを送ることを可能にする。前記“任意（an y）”型は、基本型であるかまたは混成型であるかを問わず、考えられる任意のデータ型を表すことができる。ＩＤＬは、ＯＭＧ（“ＣＯＲＢＡ”）のRevision２．０仕様を実行する分散型オブジェクトシステムに使用されるよう設計されている。前記ＣＯＲＢＡ仕様を実行する典型的なシステムにおいて、インターフェイス定義は、ＩＤＬ定義ソースファイル（“翻訳単位”としても知られている）に書かれている。前記ソースファイルは、クライアントスタブファイル、サーバスタブファイルおよびヘッダファイルを含むプログラミング言語別ファイルを生成するＩＤＬコンパイラによってコンパイルされる。前記クライアントスタブファイルは、ある１つのオブジェクトタイプに関するＩＤＬオペレーション定義の手続きルーチンへの、各言語別の対応づけ（マッピング）であり、各オペレーション毎に１つ設けられる。ある言語に固有のコンパイラによってコンパイルされ、クライアントアプリケーションにリンクされる場合、スタブルーチンは、リクエストを呼び出すために、前記クライアントアプリケーションによって呼び出されることができる。同様に、前記サーバスタブファイルは、ある１つのオブジェクトタイプに関するＩＤＬオペレーション定義（インターフェイスによる定義）の手続きルーチンへの、各言語別の対応づけである。コンパイルされ、サーバアプリケーションにリンクされる場合、前記サーバアプリケーションは、対応するリクエストが到着した時にこれらのルーチンを呼び出すことができる。前記ヘッダファイルは、コンパイルされ、クライアントアプリケーションおよびサーバアプリケーションにリンクされ、共通のデータ型を定義するために使用される。ある１つのアプリケーション内における厳密なＬＤＬ定義されたオペレーションを使用する上での問題点は、これらのオペレーションを汎用関数に使用できないことである。前記汎用関数とは、異種のプラットフォーム間にわたって使用可能な関数であり、従って、これらの異種のプラットフォーム間にわたるコードの再使用を促進できるものである。しかし、従来にあっては、特定のインターフェイスに含まれるオペレーションにアクセスするために、各アプリケーションは、特定のクライアントスタブ関数を呼び出さなければならない。インターフェイスには追加的なオペレーションが付加されるので、新たなスタブ関数が発生されなければならない。このため、アプリケーションは時間経過に伴ってますます複雑になる可能性がある。ＬＤＬ定義されたオペレーションを使用する上での他の問題点は、互換性を判定するためにインターフェイスの比較をすることができないことである。サーバがインターフェイスおよびそれに関連するオペレーションを用意できないという理由で、リクエストされたサービスを提供できないことがある。しかし、前記サーバは、同様なオペレーションを提供する互換性のあるインターフェイスを有することがある。現在のところ、インターフェイスおよび／またはオペレーションの互換性を判定するための方法は存在しない。従って、ＬＤＬ定義されたインターフェイス、オペレーションおよびパラメータを汎用関数に使用する必要がある。さらに、ＬＤＬ定義されたインターフェイス、オペレーションおよびデータ型の比較を容易にする必要がある。発明の要旨この発明は、ＬＤＬ定義されたインターフェイス、オペレーションおよびデータ型を汎用関数に使用する要求を満足させることのできる方法、システムおよびコンピュータプログラム製品を提供するものである。さらに、この発明の方法は、ＬＤＬ定義されたインターフェイス、オペレーションおよびパラメータの比較を容易にする要求を満足させる。この方法は、前記インターフェイス、オペレーションまたはパラメータを示す新たなＡＳＣＩＩ文字列記述子を生成するステップを含む。より詳しくは、パラメータの基本型を示すために文字が使用され、混成型パラメータおよびこれらの混成型パラメータの特性を示すために文字と数字との組合わせが使用される。オペレーションの場合、該オペレーションに含まれるパラメータの数および種類、例外の数およびコンテキストの数を示すために、文字と数字とが使用される。インターフェースは、該インターフェースに含まれるオペレーションの数を示す数字を使用して記述される。オリジナルのＩＤＬ記述をＡＳＣＩＩ文字列に変換することによって、オブジェクト呼出しを異種のシステム間で移送するための汎用関数を作成することができる。さらに、コードジェネレータは、複雑なデータ構造体のリンクの代りに、単に、インターフェースを詳しく記述する文字列を発生することができる。さらに、この発明の方法を用いて、個々のオペレーションおよびデータ型を容易に記述することができる。この発明に係るデータ型、オペレーションおよびインターフェースを記述するための方法、ならびに、その利点および目的は、添付図面を参照して以下に述べるこの発明の詳細な説明によって、より完全に理解されるであろう。図面の簡単な説明図１は、この発明の方法を使用したクライアント／サーバシステムを示す図、図２Ａおよび図２Ｂは、共通実行環境（ＣＥＥ）カプセルの異なる構成を示す図、図３は、ＣＥＥカプセルおよびそのコア要素を示す図、図４は、ＩＤＬソースファイルのコンパイル処理を示す図、図５は、基本データ型および混成データ型のためのＣＩＮ記述子の生成を記述するフローチャート、図６は、オペレーションのためのＣＩＮ記述子の生成を記述するフローチャート、図７は、インターフェイスのためのＣＩＮ記述子の生成を記述するフローチャート。好適な実施の形態の詳細な説明以下、添付図面に示した例を参照して、この発明の好適な実施の形態を詳細に説明する。添付図面において、同一または類似した構成要素には同一の参照番号が付されている。Ｉ．システムの概要図１に示すように、この発明の方法は、分散型（クライアント／サーバ）コンピューティング環境１０に使用されるよう設計されている。該クライアント／サーバシステムは、インターネット接続部またはローカルエリアネットワーク接続部のようなネットワーク接続部１２によって接続されている。サーバコンピュータ１１は、バスまたはＩ／Ｏチャンネル２０を介して、ディスク記憧サブシステム１３と通信する。サーバシステム１１は、ＣＰＵ１５と、プログラムの実行についての現在の状態情報を格納するためのメモリ１７とを具備している。該メモリ１７の一部は、クライアントコンピュータ上で現在実行されているプログラムの各関数に関連した状態および変数を格納するために専用される。同様に、クライアントコンピュータ２１は、ＣＰＵ２７とこれに関連するメモリ２３と、キーボード２９またはマウス３１のような入力装置２９と、ビデオ表示端末（“ＶＤＴ”）のような表示装置３３とを具備している。該クライアントのＣＰＵは、バスまたはＩ／Ｏチャンネル４０を介してディスク記憶サブシステム３３と通信し、また、Ｉ／Ｏチャンネル４１を介してキーボード２９、ＶＤＴ３３およびマウス３１と通信する。両前記コンピュータは、フロッピーディスクやＣＤ−ＲＯＭを含む各種の記録媒体を読取り可能である。前記クライアントメモリ２７には、クライアントアプリケーション７７およびクライアントスタブ７９がロードされている。同様に、前記サーバメモリ１７には、サーバアプリケーション８７およびサーバスタブ８９がロードされている。さらに、前記クライアントメモリおよびサーバメモリは、共に、実行環境（“ＣＥＥ”）７５，８５を含んでいる（後述）。図１に示すクライアント／サーバモデルは、単に、典型的なクライアント／サーバシステムを例示するものである。この発明によると、前記クライアントは、あるオブジェクトについてオペレーションが実行されるべきことをリクエストするアプリケーションであり、前記サーバは、前記オブジェクトについて前記オペレーションを実行するアプリケーションである。実際上、前記クライアントアプリケーションおよびサーバアプリケーションは、後述のように、同一のコンピュータおよび共通のカプセル内に備えられていてよい。しかし、ほとんどの場合、前記クライアントアプリケーションおよびサーバアプリケーションは、異なるオペレーティングシステムを使用する異なるコンピュータに備えられることになる。以下、この発明の方法を、異なるマシーン上で動作する２つのカプセルについて説明する。 II．分散型コンピューティング環境この発明の方法および装置は、任意の分散型コンピューティング環境内で利用可能である。好ましい実施の形態において、タンデム・メッセージ・スイッチング・ファシリティ（Tandem Message Switching FaCility）（“ＭＳＦ”）・アーキテクチャ（Architecture）の一要素である共通実行環境（“ＣＥＥ”）７５，８５が使用される。前記ＣＥＥは、オブジェクトを起動したり可動停止したりするものであり、ＣＥＥカプセルにロードされたクライアントアプリケーションとサーバアプリケーションとの間でメッセージのやり取りするために使用される。該ＣＥＥは、１つのマシーンのメモリに格納されてよい。しかし、該ＣＥＥ、クライアントアプリケーションおよびサーバアプリケーションは、図１に示すように、ネットワーク上の多数のマシーンにロードされてもよい。クライアント側のＣＥＥ７５は、クライアントメモリ２３に格納されている。また、サーバ側のＣＥＥ８５は、サーバメモリ１７に格納されている。前記共通実行環境（“ＣＥＥ”）は、“カプセル”下部構造を使用する。該カプセルは、メモリスペースおよび１つまたは複数の実行ストリームを封入するものである。カプセルは、異なるシステムでは、当該システムによって使用されるオペレーティングシステムに応じて、異なる態様で実現されてよい。例えば、あるシステムでは、前記カプセルはプロセスとして実現される。また、他のシステムでは、前記カプセルはスレッド（thread）として実現される。さらに、クライアントアプリケーションおよびサーバアプリケーションは、図１に示すように異なるマシーンに含まれる異なるカプセル内に構成されてもよい。代案として、異なるカプセルが図２のように構成されてもよい。図２Ａは１つのカプセル８１にロードされたクライアントアプリケーション７７を示し、この場合、サーバアプリケーション８７は別のカプセル８５にされてよい。しかし、これら２つのアプリケーションは、同一のマシーン２１に格納されている。また、図２Ｂに示すように、前記クライアントアプリケーションおよびサーバアプリケーションは、共に、同一のマシーン２１上の１つのカプセル８１内にロードされてもよい。上述のように、ここでは、多数のカプセル、多数のマシーンを使用する例についてこの発明の方法を説明する。従って、クライアントマシーン１２およびサーバマシーン１１は、それぞれのメモリにロードされたクライアント側ＣＥＥ７５およびサーバ側ＣＥＥ８５を備えている。図３は、例えば、クライアントコンピュータメモリ２７（ここでは図示せず）に格納されたＣＥＥカプセル７０を示すものであり、該ＣＥＥカプセル７０は、ＣＥＥ７５、ならびに、コアＣＥＥ要素および処理系ライブラリ７１内に含まれるオブジェクトの処理系のうちのいくつかを含むものである。前記処理系ライブラリ７１は、後述のように、オブジェクトインターフェイスのＩＤＬ仕様書から生成されたクライアントアプリケーション７９（サーバカプセルの場合、サーバアプリケーション）およびクライアントスタブ７７（またはサーバスタブ）を含んでいる。前記処理系ライブラリ７１およびＣＥＥ７５は、該ＣＥＥによって供給される動的アクセス可能なルーチンのダウンコーリングおよび前記処理系ライブラリに含まれるルーチンのアップコーリングによって、相互作用する。また、前記ＣＥＥ７５は、同じマシーン内の他のカプセルからのオブジェクト呼出し８２、および、他のＣＥＥからのリクエスト８４を受け取ることができる。前記クライアント側ＣＥＥ７５およびサーバ側ＣＥＥ８５は、任意の既知のネットワークプロトコルを使用して通信することができる。ＣＥＥカプセルで実現されるオブジェクトは、構成オブジェクトまたは動的オブジェクトであってよい。構成オブジェクトの処理系の詳細は、（MSF Warehous e85のような）格納部または初期化スクリプトに格納されている。特定のオブジェクト参照に対するリクエストがあった場合、前記クライアント側ＣＥＥ７５では、この構成データに基づいて適切なカプセルを始動する。前記カプセルは、この構成データを使用して、ロードすべき処理系ライブラリおよび呼び出すべきオブジェクト初期化ルーチンを決定する。そして、前記オブジェクト初期化ルーチンがそのオブジェクトを作成する。動的オブジェクトは、同一のカプセル内において、動的に作成され、破棄される。該動的オブジェクトには、格納部に格納されたまたはスクリプト化された構成情報が無い。 III．ＩＤＬソースファイルのコンパイルおよびリンク図４は、ＩＤＬソースファイルが、コンパイルされ、この発明の方法および装置を使用するクライアントアプリケーションおよびサーバアプリケーションにリンクされる手順を示すものである。先ず、ＩＤＬインターフェイス定義を含むＩＤＬソースファイル１０１が作成される。ＩＤＬコンパイラ１０３は、前記ＩＤＬソースファイル１０１をコンパイルする。前記ＩＤＬコンパイラ１０３は、コード１０１を分析して中間ファイル１０５を生成し、コンパイル済みソースファイルを格納する。コードジェネレータ１１２はＰＩＦファイルを分析する。前記コードジェネレータ１１２は、前記クライアントアプリケーションおよびサーバアプリケーションの言語のファイルを生成する。前記クライアントアプリケーションとサーバアプリケーションとが異なる言語によるものである場合、異なるコードジェネレータ１１２が使用される。好ましくは、前記コードジェネレータ１１２およびＩＤＬコンパイラ１０３は、１つのアプリケーションにおいて、言語別コードを生成するために組み合わされる。前記コードジェネレータ１１２は、クライアントスタブ関数を含むクライアントスタブファイル７７と、オブジェクト処理系についての定義を含むサーバスタブファイル８７とを生成する。前記クライアントスタブ関数は、前記ＣＥＥ７５に対する同期呼出しおよび非同期呼出しを含むものである。コンパイルされたクライアントスタブオブジェクトコードおよびコンパイルされたサーバスタブオブジェクトコードを生成するために、前記クライアントスタブファイル７７およびサーバスタブファイル８７は、プログラミング言語別のコンパイラ１２２，１２４によってコンパイルされる。同様に、コンパイルされたクライアントアプリケーションオブジェクトコードおよびコンパイルされたサーバアプリケーションオジェクトコードを生成するために、クライアントアプリケーション７９およびサーバアプリケーション８９は、プログラミング言語別のコンパイラによってコンパイルされる。前記クライアントアプリケーション７９およびサーバアプリケーション８９は、さらに、前記コードジェネレータ１１２によって生成される共通の定義、宣言を含むヘッダファイル１１９を含む。最後に、コンパイラ１２１は、前記クライアントアプリケーションオブジェクトコードとクライアントスタブオブジェクトコードとをリンクすることにより、処理系ライブラリ７１を生成する。同様に、第２のコンパイラは、前記サーバアプリケーションオブジェクトコードとサーバスタブオブジェクトコードとをリンクすることにより、他の処理系ライブラリ８１を生成する。前記コードジェネレータ１１２は、Compact IDL Notation（“ＣＩＮ”）を生成し、前記ヘッダファイル１１９に入れる。詳しくは、前記コードジェネレータ１１２は、コンパイルされたインターフェイス、オペレーションおよびオペレーションパラメータのすべてを調べ、（通常、前記インターフェイスの名前である）識別子および（例えばＣ＋＋の#defineマクロを使用して）前記ヘッダファイルの識別子の代りとなる文字シーケンスを定義する。コードジェネレータ１１２がソースファイルを各行ごとに解析するのに伴い、該コードジェネレータ１１２は、前記文字シーケンスを、該コードジェネレータ１１２を含むコンピュータのメモリに格納する。前記ソースファイルの全部が解析されると、前記コードジェネレータ１１２は、前記クライアントアプリケーションおよびサーバアプリケーションに含むべき前記ヘッダファイルのＡＳＣＩＩ記述子を生成する。後述のように、前記ＡＳＣＩＩ記述子の文字シーケンスは、前記コードジェネレータに知られた所定の定義に基づいて生成される。１つのＩＤＬソースファイルは、１つまたは複数のインターフェース定義およびデータ型定義（“typedefs”）を含む。前記インターフェースの本体は、いくつかの宣言を含む。タイプ宣言は、前記インターフェースが移出する型定義を明示する。例外宣言は、前記インターフェースによって移出される例外構造を明示する。属性宣言は、前記インターフェースによって移出される関連属性を明示する。オペレーション宣言は、前記インターフェースが移出するオペレーション、ならびに、各オペレーションの名前、リターンデータ型、パラメータの種類および例外を含むフォーマットを明示する。好ましい実施の形態において、この発明の方法は、ソースファイルに含まれるインターフェース定義、オペレーション定義および個々のデータ型定義を記述するために利用される。しかし、この発明の方法は、一定の定義、例外定義およびモジュール定義（インターフェース集合の定義）を記述するために利用される。 IV．Compact IDL Notationの生成図５は、ＩＤＬソースファイルに含まれるＩＤＬデータ型、オペレーションおよびインターフェースからのＣＩＮ記述子生成を示すフローチャートである。なお、図５〜図７のステップは、メモリに格納されたコンピュータ命令を実行するデータ処理システムのＣＰＵによって実行されるものである。ステップ１０１において、前記コードジェネレータ１１２は、前記ＩＤＬソースファイルの最初の行から開始し、該ＩＤＬソースファイルに記述されたデータ構造体、インターフェースまたはオペレーションを確認する。前記記述されたデータ構造体がインターフェースである場合、前記コードジェネレータ１１２は、図７に示された方向に従って処理する。前記記述されたデータ構造体がインターフェース内のオペレーションである場合、前記コードジェネレータ１１２は、図６に示された方向に従って処理する。前記記述されたデータ構造体がデータ型（または、後述するようなオペレーションのためのパラメータ）である場合、前記ジェネレータは、定義テーブルに基づいて１つの文字を生成する。なお、ここに含まれるチャートに示したもの以外の文字が使用されてもよい。各チャートは、好ましいＡＳＣＩＩ文字のみを含んでいる。チャートＡは、様々なＩＤＬ基本型を示すために使用される文字列を含む好ましい定義テーブルを示すものである。チャートＡこのチャートＡに示すように、ＣＩＮ記述子における基本型を表現するために簡単な文字列が使用される。データ型がアレイまたは構造体（構造体型）のような混成型である場合、一連の異なるステップが行われる。ステップ１１１では、前記混成型のスタートを示す文字が生成される。チャートＢは、様々なＩＤＬ混成型のスタートを示すために使用される文字列を含むサンプルテーブルを示す。チャートＢ各混成型の具体的な表現は、その型に応じて異なる方法で取り扱われる。ＩＤＬは、各基本型ごとに多次元で固定サイズのアレイを定義する。前記アレイのサイズは、コンパイル時に決定される。アレイはＣＩＮにより次のように表現される。ａ nr_dimensions Size_1.[Size_2，...size_n]base type 前記アレイのための文字の生成は、ステップ１１３，１１５，１１７に示されている。このアレイ表現において、上記文字ａは（チャートＢに示すように）前記アレイのスタートを示している。文字nr_dimensionsは、該アレイにおける次元の数を示す数字である。また、文字size_1，Size_2，size_nは、それぞれ、前記アレイの一次元、二次元およびｎ次元におけるサイズを示す。base-typeは、前記アレイの各アレイ要素ごとの記述子である。様々な基本型の表現は、チャートＡに示されたオリジナルの基本型テーブルから導出される。ＩＤＬは、ユーザによって定義された構造体型を定義する。各構造体は、基本データ型または混成データ型の１つまたは複数のフィールドで構成される。構造体はＣＩＮにより次のように表現される。ｂ nr_fields field_1[field_2...field_n] １つの構造体を記述する文字の生成は、ステップ１１９およびステップ１２１に示されている。チャートＢに示すように、上記文字ｂは前記構造体のスタートを示している。数字nr_fieldsは、前記構造体におけるフィールドの数を示す。前記構造体におけるフィールドは、field_1，field_2，field_nによって記述される。各フィールドは基本型または混成型である。前記構造体の基本型フィールドは、チャートＡに示されているように記述される。混成型はここに示されているように記述される（すなわち、アレイは、次元の数および各次元のサイズ、スタート文字等で記述される）。ＩＤＬは、データ型のシーケンスを定義する。１つのシーケンスは、２つの特性、すなわち、（コンパイル時に決定される）最大サイズと（実行時に決定される）長さとを有する１次元のアレイである。シーケンスは次のように表現される。ｃ nr-occurrences base_type 前記シーケンスのための文字の生成は、ステップ１２３，１２５に示されている。この表現において、上記文字ｃは、チャートＢに示すように、前記シーケンスのスタートを示している。文字nr_occurrencesは、該シーケンスにデータ型の出現回数を示す。該出現回数の後には、前記シーケンスにおけるデータ型出現ごとの実際の記述子base_typeが続く。データ型が基本型である場合、チャートＡの適当な記述子が使用される。前記シーケンスが混成型である場合、記述子はここに説明されているように作成される。シーケンスのシーケンスも可能である。ＩＤＬは、空（null）文字を除くすべての８ビットの量（quantity）で構成される文字列型を定義する。１つの文字列は、charのシーケンスに類似している。文字列はＣＩＮにより次のように表現される。ｄ size 文字列のスタートは文字ｄで示される。該文字列のサイズは、ステップ１２７で生成される文字sizeによって示される。ＩＤＬにおいて、共用体（union）は、Ｃプログラミング言語の“共用体”とＣ“switch”文との間の交配体である。換言すれば、共用体シンタクスは、共用体ブランチを示す“case”ラベル（ケース・ラベル）と共に“switch”文を含むものである。ＩＤＬ共用体は区別されなければならない。すなわち、共用体のヘッダは、現在の呼出しインスタンスにどの共用体要素を使用すべきかを決定する型別タグフィールドを指定しなければならない。共用体および共用体ブランチは、ＣＩＮにより次のように表現される。ｅ nr_fields ｆlabel_1 field_1[ｆ label_2 field_2...label_n field_n] 共用体および共用体ブランチを示す文字の生成は、ステップ１２９，１３１，１３３，１３５に示されている。この表現において、ｅは共用体のスタートを示し、ｆは該共用体内の共用体ブランチのスタートを示す。該共用体におけるフィールドの数は、文字nr_fieldsによって明示される。各フィールドのcaseラベル値は、文字label_1によって示される。フィールドがデフォルトである場合、前記ラベルは省略される。次に、各フィールドごとの記述子field_1がくる。前記共用体のフィールドは、基本型または混成型のいずれであってもよい。従って、基本型のフィールド記述子は、チャートＡに基づいて生成されてよい。混成型はここに説明されているように生成される。基本型および混成型の記述から分かるように、ＣＩＮ記述は前記オリジナルのＩＤＬソースファイルに含まれる識別子を含まず、汎用関数が生成される。従って、最も複雑なデータ構造であっても、文字列フォーマットで容易に表現され得る。下記のものは元々ＩＤＬで記述されたサンプル構造体である。この発明の方法を使用することにより、上記のデータ構造はＣＩＮにより次のように表現される。 “c100+e2+f0+b2+FFf1+b2+KK” 好ましい実施の形態において、正の数字の後には正符号（“＋”）が付けられており、負の数字の後には負符号（“−”）が付けられている。負の数は頻繁には現れないが、負の数の使用は、例えば共用体の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， context_nで生成される。次のものは元々ＩＤＬで記述された２つのサンプルオペレーションである。この発明の方法を使用することによって、上記AddオペレーションはＣＩＮにより次のように表現される。 126861413+3+ADDA3+DFAFAF0+0+ 前記オペレーションのＣＩＮ記述子は次のように説明される。最初の数字（12 6861413）は、文字列“3+ADDA3+DFAFAF0＋0+”について巡回冗長検査を実行することによって、前記ＣＩＮの残部から導出される。オペレーションｉｄは３つの文字（３＋）を含む。これらの３つの文字は、オペレーションｉｄとしての文字列“ADD”である。すべてのＩＤＬ識別子は、固有のものであり、caseとは独立でなければならない。従って、オペレーションｉｄは大文字とされる。前記オペレーションは、一方向性属性（Ａ）を含まず、３つの“パラメータ”（３＋）を含む。前記関数が結果を返すので、実際上、最初の“パラメータ”が関数結果（Ｄ）である。前記関数結果は符号付きのlong（Ｆ）である。次のパラメータ（実際上、最初のパラメータ）はinパラメータ（Ａ）である。該パラメータは、型分類された符号付きの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オペレーションのオペレーション記述子は、オペレーションの数を示す文字の次にくる。上述の如く、ＣＩＮ記述子は、クライアントアプリケーションおよびサーバアプリケーションの両方にリンクされるヘッダファイルに含まれる。こうして、クライアントおよびサーバの両方は、各々が適当と考える記述子を利用することができる。前記ＣＩＮは様々な形態で使用可能である。例えばデータ型のＣＩＮ記述子は、構造化されたデータ型をパックしたりアンパックしたりするための汎用関数を作成するのに有用であろう。さらに、ＣＩＮ記述子は、迅速にインターフェイスを比較するためにも使用可能である。例えば、サーバアプリケーションは、ＣＩＮで記述された２つのインターフェイスを含むヘッダファイルを有してもよい。この場合、該サーバアプリケーションは、既知の文字列比較関数を使用してＡＳＣＩＩ文字列記述子を比較することができる。ＣＩＮ記述が同一である（または類似している）場合、サーバは、サーバアプリケーションにおいて共通の方法を使用して両インターフェイスのオペレーションを実行することができる。こうして、上記ＣＩＮを使用して、異なる（しかし類似している）インターフェイスのための多数の時間コード化方法をセーブすることができる。以上、インターフェース定義言語で定義されたデータ型、オペレーションおよびインターフェイスを記述するための方法の好ましい実施の形態を説明してきたが、この発明の範囲および精神を逸脱することなく、様々な変更がなされてもよい。

Claims

【特許請求の範囲】１．ソースファイルに含まれるインターフェース定義言語で定義されたデータ型を記述するための方法であって、メモリを有するデータ処理システムによって実行されるものであり、前記ソースファイルを読み出すステップと、前記データ型を示す文字列記述子を前記メモリ内に生成するステップとを具備した方法。２．前記データ型が基本型である場合、前記文字列記述子を前記メモリ内に生成するステップが前記基本型を示す文字を生成するステップを含む請求の範囲第１項に記載のインターフェース定義言語で定義されたデータ型を記述するための方法。３．前記データ型がその各々が基本型要素を含むｎ次元のアレイである場合、前記文字列記述子を前記メモリ内に生成するステップが、前記アレイのスタートを示す文字を生成するステップと、前記アレイにおける次元の数を示す数字を生成するステップと、前記アレイの各前記次元におけるサイズを示す数字と、前記アレイにおける各要素ごとの基本型を示す文字を生成するステップとを具備する請求の範囲第１項に記載のインターフェース定義言語で定義されたデータ型を記述するための方法。４．前記データ型がｒ個のフィールドを有する構造体である場合、前記データ型を示す文字列記述子を生成するステップが、前記構造体のスタートを示す文字を生成するステップと、前記構造体におけるフィールドの数を示す数字を生成するステップと、前記構造体の各前記フィールドのデータ型を示すｒ個の記述子を生成するステップとを具備する請求の範囲第１項に記載のインターフェース定義言語で定義されたデータ型を記述するための方法。５．前記データ型がｙ個のフィールドを有する共用体である場合、前記データ型を示す文字列記述子を生成するステップが、前記共用体のスタートを示す文字を生成するステップと、前記共用体のブランチのスタートを示す文字を生成するステップと、前記共用体におけるフィールドの数を示す数字を生成するステップと、各前記フィールドのケース・ラベル値を示すｙ個の数字を生成するステップと、各前記フィールドのデータ型を示すｙ個の記述子を生成するステップとを具備する請求の範囲第１項に記載のインターフェース定義言語で定義されたデータ型を記述するための方法。６．前記データ型がシーケンスである場合、前記データ型を示す文字列記述子を生成するステップが、前記シーケンスのスタートを示す文字を生成するステップと、前記シーケンスにおけるデータ型の出現回数を示す数字を生成するステップと、前記シーケンスにおける各前記出現ごとの記述子を生成するステップとを具備する請求の範囲第１項に記載のインターフェース定義言語で定義されたデータ型を記述するための方法。７．前記データ型が文字列である場合、前記データ型を示す文字列記述子を生成するステップが、前記文字列を示す文字を生成するステップと、前記文字列における文字の数を示す数字を生成するステップとを具備する請求の範囲第１項に記載のインターフェース定義言語で定義されたデータ型を記述するための方法。８．ソースファイルに含まれるインターフェース定義言語で定義されたオペレーションを記述するための方法であって、メモリを有するデータ処理システムによって実行されるものであり、前記ソースファイルを読み出すステップと、前記オペレーションを示す文字列記述子を前記メモリ内に生成するステップとを具備した方法。９．インターフェース定義言語で定義されたオペレーションを記述するための方法であって、オペレーションを示す文字列記述子を生成するステップが、前記オペレーションをユニークな形態で識別する文字を生成するステップと、前記オペレーションの名前から派生する文字列を生成するステップと、前記オペレーションの属性を示す文字を生成するステップと、前記オペレーションにおけるパラメータの数を示す数字を生成するステップと、前記オペレーションにおける各パラメータの方向を文字を生成するステップと、前記オペレーションのための各パラメータのデータ型を示すパラメータ記述子を生成するステップと、前記オペレーションによって発生され得る例外の数を示す整数を生成するステップと、前記オペレーションによって発生され得る各例外の構造を示す記述子を生成するステップと、前記オペレーションに含まれるコンテキスト名の数を示す数字を生成するステップと、前記オペレーションに含まれる各コンテキスト名を示す記述子を生成するステップとを具備する方法。１０．前記オペレーションのためのパラメータのデータ型がインターフェース定義言語基本型である場合、前記パラメータ記述子を生成するステップが前記基本型を示す文字を生成するステップを具備する請求の範囲第９項に記載のインターフェース定義言語で定義されたオペレーションを記述するための方法。１１．前記オペレーションにおけるパラメータのデータ型がその各々が基本型の要素を含むｎ次元のアレイである場合、前記パラメータ記述子を生成するステップが、前記アレイのスタートを示す文字を生成するステップと、前記アレイにおける次元の数を示す数字を生成するステップと、前記アレイの各前記次元におけるサイズを示すｎ個の数字を生成するステップと、前記アレイにおける各要素ごとの基本型を示す文字を生成するステップとを具備する請求の範囲第９項に記載のインターフェース定義言語で定義されたオペレーションを記述するための方法。１２．前記オペレーションにおけるパラメータのデータ型がｒ個のフィールドを有する構造体である場合、前記パラメータ記述子を生成するステップが、前記構造体のスタートを示す文字を生成するステップと、前記構造体におけるフィールドの数を示す数字を生成するステップと、前記構造体の各前記フィールドのデータ型を示すｒ個のデータ型記述子を生成するステップとを具備する請求の範囲第９項に記載のインターフェース定義言語で定義されたデータ型を記述するための方法。１３．前記オペレーションにおけるパラメータのデータ型がｙ個のフィールドを有する共用体である場合、前記パラメータのデータ型を示すパラメータ記述子を生成するステップが、前記共用体のスタートを示す文字を生成するステップと、前記共用体のブランチのスタートを示す文字を生成するステップと、前記共用体におけるフィールドの数を示す数字を生成するステップと、各前記フィールドのcaseラベル値を示すｙ個の数字を生成するステップと、各前記フィールドのデータ型を示すｙ個のデータ型記述子を生成するステップとを具備する請求の範囲第９項に記載のインターフェース定義言語で定義されたデータ型を記述するための方法。１４．前記オペレーションにおけるパラメータのデータ型がシーケンスである場合、前記パラメータ記述子を生成するステップが、前記シーケンスのスタートを示す文字を生成するステップと、前記シーケンスにおけるデータ型の出現回数を示す数字を生成するステップと、前記シーケンスにおける各前記出現ごとの出現記述子を生成するステップとを具備する請求の範囲第９項に記載のインターフェース定義言語で定義されたデータ型を記述するための方法。１５．前記オペレーションにおけるパラメータのデータ型が文字列である場合、前記パラメータ記述子を生成するステップが、前記文字列を示す文字を生成するステップと、前記文字列における文字の数を示す数字を生成するステップとを具備する請求の範囲第９項に記載のインターフェース定義言語で定義されたデータ型を記述するための方法。１６．インターフェース定義言語記述に基づいてコンピュータのメモリに格納されたインターフェースを記述するための方法であって、前記インターフェースを示すインターフェース記述子を生成するステップと、前記インターフェース記述子から識別子の名前を除去するステップとを具備した方法。１７．前記インターフェース記述子を生成するステップが、前記インターフェース内に含まれるオペレーションの数を示す数字を生成するステップと、各前記オペレーションを示すオペレーション記述子を生成するステップとを具備する請求の範囲第１６項に記載のインターフェース定義言語で定義されたインターフェースを記述するための方法。１８．前記オペレーション記述を生成するステップが、前記オペレーションをユニークな形態で識別する文字を生成するステップと、前記オペレーションの名前から派生する文字列を生成するステップと、前記オペレーションの属性を示す文字を生成するステップと、前記オペレーションにおけるパラメータの数を示す数字を生成するステップと、前記オペレーションにおける各パラメータの方向を文字を生成するステップと、前記オペレーションのための各パラメータのデータ型を示すパラメータ記述子を生成するステップと、前記オペレーションによって発生され得る例外の数を示す整数を生成するステップと、前記オペレーションによって発生され得る各例外の構造を示す記述子を生成するステップと、前記オペレーションに含まれるコンテキスト名の数を示す数字を生成するステップと、前記オペレーションに含まれる各コンテキスト名を示す記述子を生成するステップとを具備する請求の範囲第１７項に記載のインターフェース定義言語で定義されたインターフェースを記述するための方法。１９．ソースファイルに含まれるインターフェース定義言語で定義されたデータ型を記述する方法をマシーンに実行させるためのマシーンにより読み取り可能な媒体であって、前記方法が、前記ソースファイルを読み出すステップと、前記データ型を示す文字列記述子を前記メモリ内に生成するステップとを具備した媒体。