JP2000515280A

JP2000515280A - オブジェクト指向型情報伝送方法および装置

Info

Publication number: JP2000515280A
Application number: JP10506107A
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: EP0912936A1; WO1998002813A1; US6173327B1

Abstract

(57)【要約】コンピュータネットワーク上における１つのコンポーネントから他のコンポーネントに情報を伝達するためのオブジェクト指向型伝送方法および装置は、アダプタおよび情報プロバイダ要素のための処理系ライブラリをメモリにロードし、これらのコンポーネントのためのファクトリオブジェクトを作成するステップを含む。前記ネットワークを介してリクエストが到着すると、前記ファクトリオブジェクトが呼び出され、このファクトリオブジェクトによって、ストリームオブジェクトが作成される。その後、前記ストリームオブジェクトを使用して、情報プロバイダソースからオリジナルリクエスタに対して、データがストリーム伝送される。

Description

【発明の詳細な説明】オブジェクト指向型情報伝送方法および装置発明の背景１．発明の分野この発明は、１つのコンピュータ内またはコンピュータネットワーク内において情報を伝送するためのオブジェクト指向型情報伝送方法および装置に関する。特に、この発明は、ファクトリ／ストリームモデルを使用して、コンピュータまたはネットワーク内の１つのコンポーネントから他のコンポーネントにデータおよび関連コンテキストを伝送する分散型オブジェクトシステムに関する。２．背景分散型コンピューティングは、相互に情報を共有する２つまたは３つ以上のソフトウエアで構成される。これら２つのソフトウエアは、同一のコンピュータ、または、共通のネットワークに接続された複数の異なるコンピュータ上で実行される。ほとんどの分散型コンピューティング方式は、クライアント／サーバモデルに基づいている。このようなクライアント／サーバモデルでは、大別して２種類のソフトウエア、すなわち、情報またはサービスを要求するクライアントソフトウエアと、情報またはサービスを提供するサーバソフトウエアが使用される。通常、情報またはサービスは、Information Delivery System（情報伝送システム）ソフトウエアアプリケーションによって、サーバからクライアントに伝送される。この種のアプリケーションは、しばしば、クライアントからの情報リクエストを待つモジュールで構成される、モノリシックでプロトコルごとに固有の、UNIXに基づいたサーバアプリケーションである。前記リクエストが到着すると、前記モジュールは自分自身をコピー（“複写”）し、該モジュールのコピーが前記リクエストを処理することになる。例えば、ＳＱＬデータベースからの情報またはローカルディスクファイルに含まれる情報を提供することによって、前記リクエストは前記コピーによって処理される。一方、オリジナルのモジュールは、入って来るリクエストをモニタし続ける。しかしながら、前記情報伝送システムのアーキテクチャは、通常、プロトコルごとに固有のものである。換言すれば、前記伝送システムアーキテクチャは、ＨＴＴＰ、ＴＣＰ／ＩＰまたはＳＰＸのような特定のプロトコルのみをサポートするものである。このため、サポートされていないプロトコルを介して到着するリクエストは、処理されることができない。このようなシステムは、本来、柔軟性がなく拡張性もない。モノリシックなアプリケーションによる多数のプロトコルをサポートする試みは、さらに、それらの非拡張性を露呈することになる。しかし、一般的に、いつくかのプロトコルについてのサポートを追加するためには、アプリケーションにおいて付加的なコードを追加することを必要とする。多くのプロトコルが生成されるのに対応して、アプリケーションはより大きなものになる。アプリケーションが１つの処理を実行する場合、前記アプリケーションはエラー無しに実行され得る。しかし、前記アプリケーションが多数の処理を実行する場合、あまりにも多くの資源が使用され、前記アプリケーションが破損することになる。さらに、これらシステムの多くにおける耐故障性（フォールトトレランス）およびエラー処理の欠如により、エラー訂正はほとんど不可能となる。システム資源が使い果たされ、アプリケーションが終了した場合、しばしば、どのクライアントのリクエストがその故障の原因となったのかを判定するのが困難になる。例えば、前記システムは、ＳＱＬ問合せまたはWorld Wide Webページリクエストがそのエラーを招いたのかを判定するための組込み（ビルトイン）型メカニズムを備えていない。従って、前記アプリケーションは、容易にデバッグされたり、訂正されたりできない。考えられる１つの解決策は、分散型オブジェクトシステムの使用である。分散型オブジェクトコンピューティングは、分散型コンピューティング（上述）の概念とオブジェクト指向型コンピューティングの概念とを組合わせたものである。前記オブジェクト指向型コンピューティングはオブジェクトモデルに基づくものであり、該オブジェクトモデルにおいては、（しばしば、現実世界における現実の対象から抽出される）“オブジェクト”と呼ばれるコードが、属性を有し、メソッド（または“オペレーション”もしくは“メンバ関数”）によってサービスを提供する。典型的には、前記メソッドは、前記オブジェクトが有するプライベート属性（データ）に作用する。同様なオブジェクトの集合は、インターフェイス（または、Ｃ＋＋言語では“クラス”）を構成する。各オブジェクトは、オブジェクト参照と呼ばれるユニークな識別子によって識別される。分散型オブジェクトシステムにおいて、クライアントは、サーバが実行すべきオペレーションの指示、前記オブジェクト参照、および、リクエストの成功または失敗についての“例外情報”を戻すためのメカニズムを含む、リクエストを送る（または“オブジェクト呼出し”を実行する）。さらに、前記クライアントに関する“コンテキスト”情報（例えば、プラットフォームまたはマシーン）が、前記リクエストに含まれることもある。前記サーバは、前記リクエストを受け取り、そして、もし可能ならば、前記特定のオブジェクトについてのリクエストを実行し、前記オペレーションの成功または失敗についての情報（“例外情報”）を戻す。クライアントおよびサーバは、共に、利用可能なオブジェクト、および、実行可能なオペレーションについての情報を有さなければならない。従って、これら両者は、オブジェクト管理グループ（“ＯＭＧ”：Object Management Gr oup）によって定義されているインターフェイス定義言語（ＩＤＬ）のような共通の言語に対してアクセス可能でなければならない。インターフェイス定義は、通常、ＩＤＬで書かれ、コンパイレされ、クライアントアプリケーションおよびサーバアプリケーションにリンクされる。分散型オブジェクトコンピューティングは、従来のモノリシックアプリケーションの問題点のうちのいくつかを解決するものである。分散オブジェクトの場合、大きなアプリケーションは、より小さな“コンポーネント”に分解されることができ、当該システムをより管理しやすく、且つ、故障しにくくする。さらに、前記システムは、様々なコンポーネントがプラグ・アンド・プレイし、ネットワーク間で共同作業し、様々のプラットフォームにおいて実行され、オブジェクトラッパーを介してレガシアプリケーションと共存し、ネットワーク上を徘徊し、自己およびこれらが制御する資源を管理することを可能にする。さらに、例外処理を使用してエラーを捕捉することができる。しかし、残念ながら、現在の標準的な分散型システムのアーキテクチャは、いかにして多数のプロトコルにより多数の情報プロバイダからクライアントに対して情報が提供され得るか、について具体的に対処していない。前記ＯＭＧによって提案されたCommon Object Request Broker Architecture（ＣＯＲＢＡ）は、オブジェクトリクエストブローカ（ＯＲＢ）を使用して、クライアントとサーバとの間のオブジェクト呼出しを処理する。しかし、該ＣＯＲＢＡ基準は、依然として、特定のプロトコルを使用しなければならないという制限に束縛されている。OpenDocやＯＬＥなどの他の基準も、同様に、特定のプロトコルを使用しなければならない。さらに、従来の分散型オブジェクトシステムにあっては、古典的なオブジェクト呼出しは、リクエスト／応答メカニズムに基づいている。従って、ある一定量の情報のみが、特定のオブジェクト呼出しにおいて送信され得る。従来の情報伝送システムは、大量のデータ（例えば、４ＧＢのビデオデータ）の伝送をサポートするためのメカニズムを提供するものではない。従って、多数のプロトコルをサポートする情報伝送方法が必要となっている。さらに、分散オブジェクト技術を使用して個々のコンポーネントの使用を促進する情報伝送方法が必要となっている。さらに、ネットワーク内で大量のデータを伝送するための方法が必要となっている。発明の要旨この発明は、多数のプロトコルに対するサポートを有するオブジェクト指向型情報伝送方法およびシステムに関するものである。さらに、この発明の情報伝送システムは、ネットワーク内のクライアントアプリケーションに対する大量の情報伝送を可能にする。好ましい実施の形態において、前記オブジェクト指向型情報伝送方法は、次のようなステップを含む。先ず、情報をリクエストするアダプタコンポーネント、情報プロバイダコンポーネントおよびナビゲータコンポーネントが、１つまたは多数のコンピュータのメモリにロードされる。そして、ナビゲータオブジェクト、アダプタファクトリオブジェクトおよび情報プロバイダファクトリオブジェクトが生成される。ネットワーク上においてリクエスタからのリクエストが到着すると、ストリームオブジェクトを生成するために、前記ファクトリが呼び出される。情報ソースから前記リクエスタに情報を流す（ストリーム）するために、前記ストリームオブジェクトが呼び出される。ストリームインターフェイスは、情報ソースに対してデータを書いたり読み出したりするためのオペレーションを含む。このモデルを利用することにより、前記情報ソースから前記リクエスタに対してデータが個別的にストリームされ得る。他の実施の形態において、オブジェクト指向型情報伝送システムは、サーバまたはゲートウエイを介して他のサーバに情報を提供する少なくとも１つの情報プロバイダコンポーネントと、前記情報プロバイダコンポーネントに情報をリクエストする少なくとも１つのアダプタコンポーネントとを含む。各コンポーネントは、処理系ライブラリとして実現される。利用可能な様々なプロトコルに応じた多くのアダプタコンポーネントを、前記システムに使用することができる。各アダプタコンポーネントは、他のサブコンポーネントに前記リクエストを送るディスパッチャコンポーネントと前記リクエストを満足させるために使用すべき情報プロバイダを決定するナビゲータコンポーネントとを含む多数のサブコンポーネントを備えている。最後に、前記システムは、前記情報プロバイダコンポーネントから前記アダプタコンポーネントに個別的にパケットを送るためのオブジェクト指向型技術を利用する。特に、前記システムは、各アダプタコンポーネントおよび情報プロバイダコンポーネントが、ストリームオブジェクトの生成を可能にするファクトリインターフェイスと、大量の情報ユニットの取り出しまたは格納を可能にするストリームインターフェイスとを実施するファクトリ／ストリームモデルを使用する。さらに、前記情報伝送システムは、前記アダプタコンポーネントと前記情報プロバイダコンポーネントとの間の仲介者として機能するトレーダを使用することもできる。このようなトレーダが使用される場合、前記ナビゲータサブコンポーネントは前記トレーダを選択し、該トレーダは正しい情報プロバイダを選択する。前記トレーダコンポーネントはコピーされることができ、その場合、前記ナビゲータサブコンポーネントは適当なトレーダを選択する。この発明の情報伝送方法および装置は、多数の情報伝送に適用できる伸縮可能なコンポーネントの生成を容易にする。より重要なことは、この発明のオブジェクト指向性により、様々なコンポーネントが、異なるプラットフォーム間で、プロトコルから独立した形態で、情報を伝送することができる、ということである。この発明に係る情報伝送システムェクトは、添付図面を参照して以下に述べるこの発明の詳細な説明によって、より完全に理解されるであろう。図面の簡単な説明図１は、この発明の方法を実施するネットワークを示すブロック図、図２は、共通実行環境（ＣＥＥ）カプセルを示す図、図３は、ＩＤＬソースファイルのコンパイルおよびリンクを示すブロック図、図４は、この発明の方法に使用されるコンテキストデータ構造体を示す図、図５は、情報マトリックスのアーキテクチャ概観図、図６は、ＨＴＴＰアダプタの一例を示す図、図７は、Gopherゲートウエイの一例を示す図、図８は、トレードを伴わないコンポーネント間インタラクションを示す図、図９は、トレードを伴うコンポーネント間インタラクションを示す図、図１０ａは、アダプタコンポーネント間インタラクションのためのスタートアップ局面およびセットアップ局面を示す図、図１０ｂは、アダプタコンポーネント間インタラクションのためのストリーム局面およびクリーンアップ局面を示す図、図１１は、トレーダインタラクションを示す図、図１２は、情報プロバイダコンポーネント間インタラクションを示す図、図１３は、トランスフォーマコンポーネント間インタラクションを示す図、図１４ａおよび図１４ｂは、ＩＤＬ定義によるデータ構造体、生成されたＣＩＮ記述およびop_tag構造体の生成されたアレイを示す図、図１５は、この発明の方法におけるクライアント側の第１の好ましい実施の形態を示すフローチャート、図１６は、この発明の方法におけるサーバ側の第１の好ましい実施の形態を示すフローチャート、図１７は、基本データ型および混成データ型用のＣＩＮ記述の生成を示すフローチャート、図１８は、オペレーション用のＣＩＮ記述の生成を示すフローチャート、図１９は、インターフェイス用のＣＩＮ記述の生成を示すフローチャート、図２０は、ＰＩＦデータ構造体を示す図、図２１は、エントリデータ構造体を示す図、図２２は、オペレーションデータ構造体を示す図、図２３は、共用体データ構造体を示す図、好適な実施の形態の詳細な説明Ｉ．ハードウエアの概要図１はネットワーク３５の一例を示すものである。該ネットワーク３５は、クライアントコンピュータ４０と、この発明の情報伝送方法および装置を使用した情報マトリックス（“ＩＭ”）コンピュータ６０と、遠隔ファイルサーバコンピュータ８０と含む。前記クライアントコンピュータ４０、ＩＭコンピュータ６０およびファイルサーバコンピュータ８０は、インターネット接続部のようなネットワーク接続部５１，５３によって接続されている。前記クライアントコンピュータ４０は、バスまたはＩ／Ｏチャンネル４２を介してディスク記憶サブシステム４３と通信し、また、Ｉ／Ｏチャンネル４８を介してキーボードのような入力装置４１、ビデオ表示端末（“ＶＤＴ”）のような表示装置４８およびマウス４７と通信する。前記クライアントコンピュータ４０は、ＣＰＵ４５と、プログラムの実行についての現在の状態情報を格納するためのメモリ４４とを具備している。前記メモリ４４の一部は、クライアントコンピュータ４０上で現在実行されているプログラムの各関数に関連した状態および変数を格納するために専用される。前記クライアントコンピュータメモリ４４は、Netscape Communication Cor p.の商標Netscape Navigatorの下で販売されているブラウザのようなWorld Wide Web（“ＷＷＷ”）ブラウザ４９を格納している。前記ファイルサーバコンピュータ８０は、バスまたはＩ／Ｏチャンネル８２を介して対応するディスク記憶サブシステム８３と通信する。該サーバシステム８０は、ＣＰＵ８５とメモリ８４を備えている。該ファイルサーバメモリ８４には、ファイルトランスポート（移送）プロトコル（“ＦＴＰ”）サーバ８９がロードされている。前記ＦＴＰサーバ８９は、（前記ＩＭコンピュータ６０およびクライアントコンピュータ４０のような）他のコンピュータに対して、前記ディスク記憶サブシステム８３からのファイル、または、前記ファイルサーバコンピュータ８０と通信する他の遠隔のコンピュータからのファイルを提供する。前記ＩＭコンピュータ６０は、バスまたはＩ／Ｏチャンネル６２を介して対応するディスク記憶サブシステム６３と通信する。該ＩＭコンピュータ６０は、ＣＰＵ６５とメモリ６４を備えている。該メモリ６４は、１つまたは複数の処理系ライブラリ６８と、実行環境（“ＣＥＥ”）６１（後述）とを備えている。図１に示すネットワーク３５は、単に、典型的なネットワークを例示するものである。この発明の方法および装置は、１つまたは複数のコンピュータにおいて分散した分散ソフトウエアを使用する。前記処理系ライブラリ６８と実行環境６１とは、前記クライアントコンピュータメモリ４４またはファイルサーバメモリ８４に格納されてよい。さらに、前記World Wide Webブラウザ４９、ＦＴＰサーバ８９および実行環境６１は、１つのコンピュータにロードされてよい。 II．分散型コンピューティング環境この発明の方法および装置は、任意の分散型コンピューティング環境内で利用可能である。好ましい実施の形態において、Tandem Message Switching Facilit y（“ＭＳＦ”）Architectureの一コンポーネントである共通実行環境（“ＣＥＥ”）６１が使用される。前記ＣＥＥは、オブジェクトを起動したり停止したりするものであり、ＣＥＥカプセルにロードされた処理系ライブラリ間でメッセージのやり取りするために使用される。該ＣＥＥは、図１のように、１つのマシーンのメモリに格納されてよい。しかし、多くの場合、前記ＣＥＥおよび処理系ライブラリのコピーが、ネットワーク上の多数のマシーンにロードされることになる。前記ＣＥＥは、“カプセル”下部構造を使用する。該カプセルは、メモリスペースおよび１つまたは複数の実行ストリームを封入するものである。カプセルは、異なるシステムでは、当該システムによって使用されるオペレーティングシステムに応じて、異なる態様で実現されてよい。例えば、あるシステムでは、前記カプセルはプロセスとして実現されてよい。また、他のシステムでは、前記カプセルはスレッド（thread）として実現されてよい。図２は、例えば、ＩＭコンピュータ６０に格納されたＣＥＥカプセル７０を示すものであり、該ＣＥＥカプセル７０は、ＣＥＥ６１、ならびに、コアＣＥＥコンポーネントおよび処理系ライブラリ６８内に含まれるオブジェクトの処理系のうちのいくつかを含むものである。前記処理系ライブラリ６８は、後述のように、クライアントアプリケーションまたはサーバアプリケーション７９等の手書きコード、および、オブジェクトインターフェイスのＩＤＬ仕様書から生成されたクライアントスタブ７７を含んでいる。前記処理系ライブラリ６８およびＣＥＥ６１は、該ＣＥＥ６１によって供給される動的アクセス可能なルーチンのダウンコーリングおよび前記処理系ライブラリに含まれるルーチンのアップコーリングによって、相互作用（インタラクト）する。また、前記ＣＥＥ６１は、同じマシーン内の他のカプセルからのオブジェクトコール８２、および、他のＣＥＥからのリクエスト８４を受け取ることができる。ＣＥＥカプセルで実現されるオブジェクトは、構成設定オブジェクトまたは動的オブジェクトであってよい。構成設定オブジェクトの処理系の詳細は、（MSF Warehouse85のような）格納部または初期化スクリプトに格納されている。特定のオブジェクト参照に対するリクエストがあった場合、前記クライアント側ＣＥＥ６１では、この構成設定データに基づいて適切なカプセルを始動する。前記カプセルは、この構成設定データを使用して、ロードすべき処理系ライブラリおよび呼び出すべきオブジェクト初期化ルーチンを決定する。そして、前記オブジェクト初期化ルーチンがそのオブジェクトを生成する。動的オブジェクトは、同一のカプセル内において、動的に生成され、破棄される。該動的オブジェクトには、格納部に格納されたまたはスクリプト化された構成設定情報が無い。以下のパラグラフでは、前記処理系ライブラリ６８がどのようにＣＥＥ６１とインタラクトするのかについてシステムレベルで概説する。前記ＣＥＥ６１は、カプセル内でオブジェクトを起動したり停止したりするためのリクエストを実行する。さらに、上述の如く、前記ＣＥＥは、カプセル間オブジェクトコール７２および他のＣＥＥ７４からのリクエストを容易にする。オブジェクト起動リクエストは、クライアントアプリケーションまたはサーバアプリケーションからのオブジェクトコールが満足させられなければならない場合に発生する。オブジェクトを起動するためには、前記ＣＥＥ６１は、それが未だロードされていない場合、前記オブジェクトのオペレーションを含む適切な処理系ライブラリをロードし、その後、以下に説明するように、前記処理系ライブラリに含まれる構成設定オブジェクト初期化ルーチンを呼び出す。該初期化ルーチンは、前記処理系ライブラリがサポートするインターフェイスを指定し、その後前記ＣＥＥ６１によって呼び出すべき前記オブジェクトのオペレーションのエントリポイントを登録する。前記処理系ライブラリ６８はスタートアップ時にロードされる。スタートアップ時において、前記ＣＥＥ６１は、自己の初期化ルーチンを実行する。この初期化ルーチンは、前記ＣＥＥ６１に対して、様々な前記処理系ライブラリの位置を指示する。前記ＣＥＥ６１による位置検出がなされると、前記ＣＥＥ６１は、前記処理系ライブラリ６８における初期化ルーチンを呼び出す。前記処理系ライブラリに含まれる初期化ルーチンは、先ず、必要とされるアプリケーション別の初期化（例えば、ファイルを開くことなど）を実行しなければならない。次に、両前記初期化ルーチンは、前記オブジェクトのインターフェイスを指定するために、GEE_INTERFACE_CREATEと称される（上述の如く動的ライブラリに含まれる）ＣＥＥ関数をダウンコールする生成済のスタブ関数を呼び出す。インターフェイスは、各オブジェクトごとに指定されることができる。後述のように、インターフェイスの記述は、通常、インターフェイスのＩＤＬ記述から生成される。GEE_IN TERFACE_CREATEは、インターフェイスを生成し、この新たに生成されたインターフェイスに“インターフェイスハンドル”を戻す。前記ハンドルは、前記インターフェイスを指示するユニークな識別子である。そして、前記初期化ルーチンは、前記インターフェイスハンドルを使用して、GEE_IMPLEMENTATION_CREATEをダウンコールする。該GEE_IMPLEMENTATION_CREATEは、１つまたは複数のオブジェクトで使用可能な実行記述を生成する。該GEE_IMPLEMENTATION_CREATEは、前記インターフェイスにおいて各オペレーションごとの処理系を指示するユニークな識別子である“処理系ハンドル”を戻す。最後に、前記初期化ルーチンは、前記処理系ハンドルを使用して、CEE_SET_METHODをダウンコールするスタブ関数を呼び出す。該CEE_SET_METHODは、前記処理ライブラリ６８に含まれる処理系の特定のメソッドルーチンの実際のアドレスを指示する。 III．ＩＤＬソースファイルのコンパイルおよびリンク図３は、インターフェイス定義言語（“ＩＤＬ”）ソースファイルが、この発明の方法および装置に使用される処理系ライブラリにコンパイルされる手順を示すものである。先ず、ＩＤＬインターフェイス定義を含むＩＤＬソースファイル１０１が生成される。ＩＤＬコンパイラ１０３は、前記ＩＤＬソースファイル１０１をコンパイルする。前記ＩＤＬコンパイラ１０３は、オリジナルソースファイルを格納するために、コード１０１を分析して中間的なPickled IDLファイル（“ＰＩＦ”）１０５を生成する。コードジェネレータ１１１はＰＩＦファイルを分析する。ＰＩＦの生成については、セクションＸＸＸにおいて後述する。代案として、コードを生成するために、前記ＩＤＬコンパイラとコードジェネレータとが組み合わされてもよい。前記クライアントアプリケーションとサーバアプリケーションとが異なる言語によるものである場合、異なるコードジェネレータ１１１が使用される。代案として、前記コードジェネレータ１１１およびＩＤＬコンパイラ１０３は、１つのアプリケーションにおいて、言語別コードを生成するために組み合わされてもよい。前記コードジェネレータ１１１は、クライアントスタブ関数を含むクライアントスタブファイル７７と、オブジェクト実行についての定義を含むサーバスタブファイル８７とを生成する。コンパイルされたクライアントスタブオブジェクトコードおよびコンパイルされたサーバスタブオブジェクトコードを生成するために、前記クライアントスタブファイル７７およびサーバスタブファイル８７は、プログラミング言語別のコンパイラ１２１，１２３によってコンパイルされる。同様に、コンパイルされたクライアントアプリケーションオブジェクトコードおよびコンパイルされたサーバアプリケーションオジェクトコードを生成するために、クライアントアプリケーション７９およびサーバアプリケーション８９は、プログラミング言語別のコンパイラによってコンパイルされる。前記クライアントアプリケーション７９およびサーバアプリケーション８９は、さらに、前記コードジェネレータ１１１によって生成されるヘッダファイル１１９を含む。該ヘッダファイル１１９は共通の定義および宣言を含む。最後に、前記言語コンパイラ１２１は、前記クライアントアプリケーションオブジェクトコードとクライアントスタブオブジェクトコードとをリンクすることにより、処理系ライブラリ７１を生成する。同様に、第２のコンパイラ１２３は、前記サーバアプリケーションオブジェクトコードとサーバスタブオブジェクトコードとをリンクすることにより、他の処理系ライブラリ８１を生成する。 IV．ファクトリインターフェイスおよびストリームインターフェイスこの発明の方法および装置は、ネットワーク内で分散可能な１つまたは複数のソフトウエアコンポーネントで構成される情報伝送システム（“情報マトリックス”）において利用可能である。各コンポーネントは様々な形態で実現可能である。この発明の方法および装置により、開発者は、特定の情報伝送タスクに適するよう各コンポーネントを実現することができる。しかしながら、各コンポーネントの好ましい処理系は、前記ＣＥＥ６１にロードされここで実行される処理系ライブラリ６８の一部分として格納されている。各処理系ライブラリ６８は、ＩＤＬにより定義されたインターフェイスを処理することによって、これらのインターフェイスのオブジェクトを生成する。上述のように、インターフェイス定義は、ＩＤＬで書かれ、ＩＤＬコンパイラによってコンパイルされ、コードジェネレータによって前記コンポーネントのコードにリンクされる。こうして、前記コンポーネントは、そのインターフェイスのオブジェクトを生成する。各オブジェクトインターフェイスは、オブジェクト呼出しを介して他のオブジェクトとインタラクトする。図５に示すように、情報マトリックス６９のコンポーネントは、４つの主要な抽象コンポーネント（抽象体）、すなわち、（１）アダプタ（Adaptor）、（２）サーバ（Server）、（３）ゲートウエイ（Gateway）および（４）トレーダ（T rader）、に分割されることができる。各抽象体は、１つまたは複数の実際のソフトウエアコンポーネント（処理系ライブラリ）を含む。ここに説明する例において、すべての抽象体およびこれらに含まれるコンポーネントは、１つのＩＭコンピュータにロードされる。しかし、あるコンポーネントがクライアントコンピュータにロードされ、また、あるコンポーネントがサーバコンピュータにロードされていもよい。前記アダプタ抽象体（Adaptor Abstraction）は、リクエスタが前記情報マトリックス６９から情報を取り出すための方法を提供する。図１においては、クライアントマシーンメモリにロードされたWorld Wide Webブラウザ４９がリクエスタとなる。リクエストは、ＩＭコンピュータメモリ６４にロードされたアダプタ抽象体のコンポーネントのうちの１つに到達することになる。図５は、Hypertext Transport Protocol（“HTTP”）アダプタ１３１、Gopher（インターネットサーバ）プロトコルアダプタ１３３およびNetwork News Transportアダプタ１３５を含むアダプタ抽象体の一例を示している。他の種類の情報取出しリクエストのために、付加的なアダプタ抽象体が追加されてよい。前記ゲートウエイ抽象体（Gateway Abstraction）は、外部情報ソースを前記情報システムに接続する。例えば、図５は、HTTPゲートウエイ１３７、Gopherゲートウエイ１３９およびFile Transport Protocol（“FTP”）ゲートウエイ１４１を示している。前記サーバ１４３は、前記情報伝送システム内部に存在し、ディスクファイル１４５のようなローカルソースからの情報を提供する。前記ゲートウエイおよびサーバは、共にアダプタに対して情報を提供するので、“情報プロバイダ”と呼ばれる（前記ゲートウエイは外部ソースからの情報を提供し、前記サーバは内部ソースからの情報を提供する）。トレーダ（Trader）１５０は、情報プロバイダのロードをバランスさせるための方法に基づいて、必要とされるタイプのゲートウエイまたはサーバを選択する。しかしながら、トレーダ１５０を使用することなく、リクエスタに対して情報の提供がなされてもよい。この発明の各コンポーネントは、多数のＩＤＬインターフェイスを実現することができる。しかし、この発明は、あるコンポーネントについて、２つのインターフェイス、すなわち、ファクトリインターフェイスおよびストリームインターフエイスである２つのインターフェイスが実現される、ことを必要とする。前記ファクトリインターフェイスおよびストリームインターフェイスを実現するあるコンポーネントに関して、該インターフェイスはまさに以下に説明するように実現される。しかし、他のコンポーネントは前記ファクトリインターフェイスおよびストリームインターフェイスのオペレーションを“引き継ぐ”。すなわち、これらのコンポーネントは前記インターフェイスに対してオペレーションを付加する。前記ファクトリインターフェイスおよびストリームインターフェイスは、１つのコンポーネントから他のコンポーネントに大量のデータを送るために、あるコンポーネントによって利用される。前記ファトリインターフェイスはストリームオブジェクトを生成するために（いずれかのコンポーネントの）オブジェクトによって呼び出され、該ストリームオブジェクトは、コンポーネント間で大量のデータを送るために使用される。前記ファクトリインターフェイスは、生成（Create）オペレーションのみを含み、ただ１つの例外（予期されない出来事）を発生する。前記生成（Create）オペレーションはＩＤＬにより次のように定義される。１番目のパラメータpathは、情報のストリームの生成が必要な資源の名前である。２番目のパラメータは、ファクトリオペレーションが資源を見つけ、該資源のためのストリームを生成することを必要とする、ことを示す値を含むfactorType パラメータである。前記contextBufferパラメータは、リクエストされた前記ストリームのための“コンテキスト”を含み、前記ファクトリを異なる形態で動作させるデータを含むことができる。例えば、前記コンテキストは、特定のタイプ（.JPEGや.GIFなど）のデータに対するリクエストを含むことができる。（コンテキストの伝播のためのコンフィギュレーション（構成設定）については後述する）。前記Createオペレーションは３つの出力パラメータを有する。前記stream Typeパラメータは、戻されるストリームオブジェクトのストリーム方向を示す。前記streamTypeパラメータは、前記ストリームが“Get”オペレーションのみのためか、“Put”オペレーションのみのためか、あるいは、両前記オペレーションが実行され得るか、を示す３つの値を有することができる。前記streamObject パラメータは、前記リクエストされたストリームオブジェクトについてのオブジェクト参照を含む。その後のすべてのストリームオペレーションは、このオブジェクトに対して行われなければならない。前記streamHandleパラメータは、前記ストリームオブジェクト内において情報ストリームを指示する。前記streamHand leは、前記ストリームオブジェクトから情報を得るために該オブジェクトに与えられる。前記ファクトリインターフェイスは、１つのエラーが発生した時にただ１つの例外を発生する。好ましい実施の形態において、（１）ストリームテーブルが満杯、（２）安全上の理由により、そのプロセスが必要な情報にアクセスできない、（３）リクエストされた資源が存在しない、（４）前記リクエストされた資源が（ロックされたファイル、故障した遠隔ホストなどの理由により）利用できない、（５）前記リクエストされた資源がリクエストされたフォーマットで利用できない（そのファイルが.JPEGファイルであり、コーラは.GIFファイルのみを受け入れると明示した場合など）、および、（６）そのオペレーションは成功したが、データは存在しない、などの理由のうちの１つ又は複数のための例外が発生される。前記ストリームインターフェースは、１つのコンポーネントから他のコンポーネントに対する情報のストリーム伝送（ストリーミング）をサポートする。オブジェクト呼出しは、使用される基本的なメカニズムおよび特定のシステムにおけるその実行に応じて、一定のサイズに制限される。後述するように、前記ストリームインターフェースは、オブジェクトの“Get”オペレーションに対する多数の呼出しを通して、通常より相当大きな情報の取出しを容易にする。個別の情報ユニットを得るために、他のオブジェクトによってストリームオブジェクトが呼び出される。前記ストリームオブジェクトは、Getオペレーション、Putオペレーション、DestroyオペレーションおよびCancelオペレーションである４つのオペレーションを含む。前記GetオペレーションはＩＤＬにより次のように定義される。前記Getオペレーションは、“ハンドル”によって指示されたストリームオブジェクト（“ストリーム”または“データストリーム”）からデータを読み出すためにコンポーネントによって使用される。データは順次またはランダムに読み出されてよい。該Getオペレーションは、handle、length、buffer、end of stream 、operation識別子およびoffsetパラメータをとる。前記handleパラメータは、リクエストされた情報ストリームを指示する。データストリームのためのハンドルが、ファクトリオブジェクトについてのCreateオペレーションに対する呼出しから戻される。lengthパラメータは、呼出し（コーラ）側のコンポーネントが受け入れする用意のあるデータ量を指示する。該lengthについて許可される最大値は、前記オブジェクト呼出しのために使用されるトランスポート（移送）メカニズムによって定義される。戻される実際のデータ量は、処理系に応じて、より少ない場合がある。前記bufferパラメータは、前記オペレーションからの成功した戻り時に、リクエストされたデータを含むものである。前記end of streamパラメータ（通常はブール論理）は、リクエストされたシステムにそれ以上のデータが存在するか否かを示す。前記offsetパラメータは、読み出されるべきデータブロックのスタートを記述する。このoffsetは、（特定の処理系がランダムデータアクセスをサポートする場合）バイト位置であり、または、前記ストリームから読み出された前のデータブロックの直後にそのデータブロックがスタートすることを示す値である。前記operation識別子は、単に、読み出されたオペレーションを指示するものである。前記Putオペレーションは、前記ハンドルによって指示されたストリームに対してデータを書き込むために使用される。データの書込みは、順次、または、処理系が許す場合にはランダムな順序で行われてよい。該putメソッドは次のように定義される。上記定義に示すように、前記Putオペレーションは４つのパラメータをとる。これらのパラメータは、これらがwriteオペレーションに対応するという点を除き、前記Getメソッドのコンポーネントに類似している。前記Destroyオペレーションは、前記ストリームハンドルによって指示されるストリームがもはや必要でないときに、呼び出される。該メソッドは次のように定義される。前記Destroyオペレーションは、わずか３つのパラメータ、すなわち、operation 識別子、ストリームhandle、および、そのストリームがいかに処理されるべきかを示すdisposeパラメータ、をとる。好ましい実施の形態において、前記dispose パラメータは、ストリーミングが成功状態に完了したこと、ストリーミングが不成功状態に完了したこと、または、例外発生によりストリーミングが成功状態に完了しなかったこと、を示す３つの値をとる。前記Cancelメソッドは、未完了のストリームオペレーションをキャンセルするために使用される。該メソッドは次のように定義される。前記Cancelメソッドは、わずか２つのパラメータ、すなわち、そのストリームに対するhandleおよびoperation識別子、をとる。例外は、ストリーミングオペレーションに関する情報を戻す。好ましい実施の形態において、例外情報は、次の理由、すなわち、（１）前記オブジェクト呼出しを受け取ったオブジェクトが、リクエストされたハンドルを持つストリームを有さない、（２）閉じられた接続、ファクトリ削除またはこれと同様なイベントにより、前記ストリームが、ストリーミング中のデータに対するアクセスを失った、（３）特定のオフセットが制限外（ファイルサイズより大きい）、（４）特定のオフセットがストリーム処理系（Getメソッド）の及ばない所にある、（５）書かれるべきストリームオブジェクトについて“Get”メソッドが行われた、または、取り出されるべくストリームオブジェクトについて“Put”メソッドが試みられた、（６）オペレーションの代りにＩ／Ｏオペレーションが行われている間に発生したタイムアウトにより、ストリームオペレーションが失敗した、および、（７）ストリーム処理系が提供できる以上のデータをリクエストまたは供給するGetオペレーションまたはP utオペレーションが実行された、という理由のうちの１つまたは複数について戻される。Ｖ．コンテキスト上述の如く、この発明によって使用されるコンポーネントは、様々異なる時にロードされ得る処理系ライブラリとして構成設定されている。この構成設定は、新たなコンポーネントの生成を容易にし、各コンポーネントのデフォルト機能を容易に変更可能にする。しかし、各コンポーネントがその機能を実行する上で、各コンポーネントは、そのタスクを実行するための特殊な情報を必要とすることがある。この発明は、コンポーネント間で予め定義された情報（“コンテキスト ”）の実行時（ランタイム）伝送を可能にするコンテキスト構造体を使用する。好ましい実施の形態において、コンテキストは、図４に示すようなテキスト構造体を使用して、１つのコンポーネントから他のコンポーネントに送られる。該構造体は名前／値の対で構成されるオクテット文字列であり、前記名前は英数字列であり、その値１９７はＩＤＬで定義された任意のタイプでよいものである。さらに、前記文字列は、コンテキスト要素の長さ１９１と、全文字列の長さ１９３と、前記名前の長さ１９５とを含む。前記値１９７は、ＩＤＬで定義された“ 任意”のタイプであり、Presentation Convention Utilities（“ＰＣＵ”）を使用してエンコードされている。ＰＣＵエンコード方式は、ＩＤＬ定義されたデータ構造体の、表示形式から独立したエンコード方式である。前記Presentation Convention Utilitiesについては、後のセクションIXで説明する。この発明において、コンテキストは、可変量のデータを含む抽象データ型としい実現される。１つのコンポーネントは、コンテキストを生成し、該コンポーネントについての特定の情報などの情報をコンテキスト構造体に入れる。前記情報はファクトリの一部として提供される。そして、前記ファクトリは、コンテキストにより完成され、ナビゲータに発送される。該ナビゲータの決定は、コンテキスト情報のみに基づく。前記情報のプロバイダは、前記コンテキストに提供された情報を使用しても、しなくてもよい。トレーディングが必要な場合、そのトレーダは前記情報を使用する。前記コンテキストを操作し、拡張するために、一連のＣＥＥルーチンが提供される。これらのルーチンは、該コンテキストを利用するアプリケーションに影響することなく、前記コンテキスト構造体の変更を可能にする。これらのルーチンのうちの多くのものは、コンテキストバッファを指示するポインタをとる。前記 Put関数は、名前およびコンパクトなＩＤＬ表記（“ＣＩＮ”）で書かれたデータ構造体の記述子をとる。コンテキスト構造体は関数IM_Context_Initializeを使用するコンポーネントによって初期化される。該関数IM_Context_Initializeのプロトタイプは次のようである。前記contextパラメータは、上述のように割り当てられたコンテキスト構造体である。前記sizeパラメータは、前記コンテキスト構造体において利用可能なバッファスペースである。この関数は、前記コンテキスト構造体を初期化し、他の関数による使用のための準備をする。コンテキスト構造体に要素を格納するために、前記コンポーネントは関数IM_C ontext_ElememtPutを呼び出すことができ、該IM_Context_ElememtPutは値IM_Con text_RSXXXを戻す。前記contextパラメータは、初期化されたコンテキスト構造体である。該コンテキスト構造体のサイズは、contextSizeに指示されている。格納すべき要素の名前は、前記nameパラメータによって指示される。前記cinパラメータは、前記要素の値のデータ型を記述する文字列である。前記bufferは、前記関数からの成功した戻り時に格納されことになる前記要素の値を含む。このバッファは、“任意の型”というＩＤＬ構造体を有する。さらに、前記関数は、前記オペレーションの成功または失敗に関する情報を戻す。前記IM_Context_RSXXX値は、前記オペレーションが成功したか否かを示す。前記オペレーションが成功しなかった場合、その戻り値は、（１）供給された名前をもつ要素が前記コンテキストにおいて見つからなかったこと、（２）供給されたコンテキストが有効なコンテキスト構造体を含まなかったこと、または、（３）供給されたコンテキストに前記要素を格納する余裕がなかったこと、を示す。これらの関数IM_Context_StringPutおよびIM_Context_LongPutは、それぞれ、文字列またはlongをコンテキスト構造体に格納するために使用される。これらの関数は次のように定義される。これらの関数において、前記Contextパラメータは初期化されたコンテキスト構造体である。該構造体のサイズは、contextSizeに指示されている。格納すべき文字列またはlongの名前は前記nameパラメータによって指示され、前記関数からの成功した戻り時に格納されるべき前記文字列またはlongの値は、stringValu eまたはlongValueによって指示される。前記関数は、前記オペレーションが成功または失敗を示すためにIM_Context_RSXXXを戻す。該戻し値IM_Context_RSXXX、 IM_Context_ElementPutについての戻し値と同一である。前記コンテキスト構造体から要素を取り出すために、前記アプリケーションまたはコンポーネントは、次のように定義されるIM_Context_ElementGet、IM_Cont ext_StringGetまたはIM_Context_LongGetを呼び出すことができる。前記パラメータはそれらのGet版に類似している。前記nameパラメータは、前記コンテキスト構造体から取り出すべき文字列またはlongまたは要素の名前である。次のように定義されるIM_Context_ElementDeleteを介して、前記コンテキスト構造体からの要素の削除も可能である。この関数において、contextは初期化されたコンテキスト構造体であり、nameは削除すべき要素の名前である。これらのオペレーションの各々についての戻し値 IM_Context_RSXXXは、前のコンテキスト関数と同一である。 VI．抽象体Ａ．アダプタ各抽象体、すなわち、アダプタ、ゲートウエイ、サーバまたはトレーダは、１つまたは複数の実際のコンポーネントで構成されている。アダプタ抽象体（Adap tor Abstraction）は、リクエスタから入って来るリクエスト（例えば、クライアントコンピュータのウエブブラウザ49からのリクエスト）を待つ。前記アダプタコンポーネントは、前記情報伝送システムにおける情報を前記リクエスタに接続する。図６の例に示すように、アダプタは、最高６つのまでのコンポーネント、すなわち、（１）トランスポータコンポーネント、（２）オーセンティケータ（認証）コンポーネント、（３）ディスパッチャコンポーネント、（４）アダプタコンポーネント（前記Adaptor Abstractionと混同しないよう）、（５）ナビゲータコンポーネントおよび（６）トランスフォーマコンポーネント、を含む。前記トランスポータコンポーネントは、リクエスタに対して、異なるプラットフォームの様々なプロトコルへのインターフェイスを与える。該トランスポータコンポーネントは、前記ファクトリインターフェイスおよびストリームインターフェイスから引き継ぐTranportFactoryおよびTranportStreamをそれぞれ実行する。該TranportFactoryはTranportStreamオブジェクトを生成する。該TranportS treamオブジェクトは、前記トランスポータコンポーネントに到着するリクエストのための接続を確立するために必要な資源を示す。前記TranportStreamインターフェイスは、前記GetオペレーションおよびPutオペレーションをサポートする。前記Getオペレーションおよびputオペレーションは、データの読書きまたはデータの送受に対応するものでよい。前記TranportStreamインターフェイスは、３つの付加的なオペレーション、すなわち、（１）接続（Connect）、（２）受取り（Accept）、および、（３）切断（Disconnect）を追加する。前記Connectオペレーションは、TranportStreamオブジェクトを遠隔のホストに接続するために１つのコンポーネントによって呼び出されるものであり、次のように定義される。前記handleは、前記TranportStreamオブジェクトに対するハンドルである。前記 pathパラメータは、（ＴＣＰトランスポータのための“remote.host.com:80”またはLanマネージャのための“//remote_host/pipe/named_pipe”などの）なすべき接続を記述する文字列である。前記Acceptオペレーションにより、前記ストリームは新たな接続を待つ。接続が確立されると、前記呼出しが完了する。該Acceptオペレーションは次のように定義される。前記handleは、前記TranportFactory生成呼出しによって戻される特定のTranpor tStreamオブジェクトのためのハンドルである。前記pathパラメータは、確立された接続を記述する文字列である。前記切断メソッドにより、前記TranportStreamオブジェクトは、それが接続された遠隔のホストから断続される。該切断メソッドは次のように定義される。前記オーセンティケータコンポーネントは、アダプタ抽象体に到着する情報リクエストを認証する。該リクエストがユーザ情報およびパスワード情報を含む場合、前記オーセンティケータは、その組合せが有効だということを保証するために、提供された情報をオペレーティングシステムに対してチエックする。前記アダプタ抽象体のディスパッチャコンポーネントは、適当な前記アダプタコンポーネントに対して適当な順序でリクエストを送り出すことによって、該リクエストの処理を管理する処理系ライブラリである。好ましい実施の形態において、前記ディスパッチャはマルチスレッド式のステートマシーンである。該ディスパッチャは、様々なアダプタコンポーネントのファクトリインターフェイスについていくつかのCreateオペレーションを呼び出す。該ディスパッチャは、リクエストについて使用すべき情報プロバイダファクトリを決定するために、ナビゲータコンポーネントを呼び出す。該ディスパッチャは、前記情報プロバイダファクトリを呼び出す。その後、前記ディスパッチャは、前記情報プロバイダから前記トランスポートストリーム中にデータを送り込み、前記情報プロバイダが利用可能なデータがそれ以上無いということを示すまでこれを続ける。前記アダプタ抽象体はアダプタコンポーネントを含み、該アダプタコンポーネントは、リクエストを受入れ、該リクエストを他のコンポーネントによって使用されるような標準形態に変換するための論理を提供する。さらに、このコンポーネントは、前記リクエスタに対して応答を返すための論理を提供する。前記アダプタコンポーネントは、トランスレータライブラリを使用して、特定のプロトコルとコンテキストとの間のリクエストおよび応答を変換する。前記トランスレータライブラリは、リクエストおよび応答を解析し生成するための関数を含む。前記アダプタコンポーネントは、前記トランスレータライブラリに対して解析リクエストをする。該解析リクエストは、到着するリクエストを取得し、これを解析し、前記コンテキストに関連値を格納する（上述）。同様に、前記コンテキストを取得し、プロトコルに固有の応答を生成する。前記ナビゲータコンポーネントは、（前記アダプタコンポーネントによって提供される）標準形態のリクエストを取得し、そのリクエストを履行するために使用すべき情報プロバイダおよびトレーダを決定する。前記ナビゲータコンポーネントは、次のように定義される１つのNavigateオペレーションを有するNavigato rインターフェイスを実行する。前記ナビゲータは、パラメータとしてのサブジェクトおよびコンテキストをとるインターフェイスのナビゲーションを提供する。そして、該ナビゲーションは、コンテキストに設定されるナビゲーション規則に基づいて、該コンテキストを修正する。前記ナビゲータによって使用される規則は、複数のサブジェクトに細分される。サブジェクトは、規則ツリーにおける１つの規則として使用される。前記ナビゲータの構成は多くのサブジェクトを含むことができる。１つのサブジェクトに基づくナビゲーションは、その特定のサブジェクトに関連するコンテキストに付加的な値を加える。ナビゲーションは規則に基づくものである。前記規則は、条件を含まなければならず、割当て規則および他の規則を任意に含むことができる。前記条件はアトム条件で構成される。該アトム条件は次の形態のうちのいずれかをとる。すなわち、contextelementname‐'regular expression'：前記contextele mentnameによって示されるコンテキスト要素の値が文字列型であり、'regular e xpression'によって与えられる正規表現と一致する場合、このアトム条件は“真 ”となる。 contextelment operator‐'String constant'：前記contextelementname によって示されるコンテキスト要素の値が文字列（string）型であり、'string constant'によって与えられる文字列と同様である場合、このアトム条件は“真 ”となる。オペレータ（演算子）は、“＝”、“＞”、“＜”、“＞＝”または “＜＝”である。 contextelment operator numeric constant:前記contextelementnameによって示されるコンテキスト要素の値が数字型であり、numeric constantによって与えられる値と同様である場合、このアトム条件は“真”となる。オペレータ（演算子）は、“＝”、“＞”、“＜”、“＞＝”または“＜＝”である。さらに、演算子“not”、“and”および“or”を使用することによってアトム条件を組み合わせて、より複雑な条件を作ってもよい。前記トランスフォーマコンポーネントは、１つのフォーマットから他のフォーマットにデータを変換する。該トランスフォーマは、ディスパッチャコンポーネントと情報プロバイダとの間に位置する。該トランスフォーマは、前記ディスパッチャコンポーネントには情報プロバイダに見え、前記情報プロバイダにはディスパッチャに見える。こうして、変換は、様々なコンポーネントにとって、透明（不可視）状態で行われる。トランスフォーマは、前記Stream（ストリーム）インターフェイスおよびFact ory（ファクトリ）インターフェイスを利用する。前記トランスフォーマファクトリオブジェクトは、情報ストリームを生成するために、情報プロバイダファクトリオブジェクトを呼び出す。こうして、該トランスフォーマファクトリは、トランスフォーマストリームオブジェクトを生成し、前記情報ストリームおよびトランスフォーマ関数を付加する。前記ファクトリは、前記トランスフォーマストリームオブジェクトの参照およびハンドルを戻す。当該オペレーションの成功または失敗を示す例外を戻すことができる。図６は、ＨＴＴＰアダプタの一例のコンポーネントを示す図。該ＨＴＴＰアダプタは、共通のインターフェースをすべてのプラットフォームのＴＣＰに供給するＴＣＰトランスポータコンポーネント１５５を含む。該ＴＣＰトランスポータファクトリは、ソケットを生成し、任意に、該ソケットをポートに結び付ける。前記ＴＣＰトランスポータStreamは、前記Acceptオペレーションを使用して、前記ポートにおけるソケット呼出しを聞きこれを受け取る。リクエストが到着すると、前記Accept呼出しが完了する。前記Connectオペレーションは、ソケット呼出し接続を実行するために使用される。前記Putオペレーションは、前記ソケットでの送出しを実行する。オーセンティケータコンポーネント１６１は、アプリケーションから前記アダプタに到着する情報リクエストを認証する。該オーセンティケータコンポーネントは、パスワードおよび他のユーザに固有の情報をチェックするために利用されることができる。この情報はオペレーティングシステムに対してチェックされる。前記ディスパッチャは、前記アダプタにおける残りのコンポーネントに前記リクエストを送る。トランスフォーマコンポーネント１５７は、様々異なるテキスト情報からHypertext Markup Language（“ＨＴＭＬ”）を生成する。前記アダプタコンポーネント１５３は、前記ＴＣＰトランスポートを使用してＨＴＴＰリクエストを受け入れ、ネットワークを介して応答を返す。前記アダプタは、関数を有する変換ライブラリを使用してＨＴＴＰリクエストおよび応答を生成する。該アダプタは、前記ＨＴＴＰリクエストヘッダを取得しこれをコンテキスト要素に中に格納する解析リクエストを行う。ナビゲータコンポーネント１５９は、一定の構成設定情報に基づいて、前記リクエストを履行するために使用すべき情報プロバイダおよびトレーダを決定する。以下、これらのコンポーネントの各々の機能について、各コンポーネントによって実行されるインターフェースの説明に続いて詳述する。Ｂ．トレーダ前記トレーダ１５０は、Trader FactoryインターフェースおよびTrader Regis trationインターフェースを実行するトレーダコンポーネントと称されるだだ１つのコンポーネントを有する。前記アダプタのディスパッチャコンポーネントは、前記トレーダのファクトリオブジェクトを呼び出す。前記トレーダコンポーネントは、ロードバランス用のアルゴリズムを使用して、多くの情報プロバイダのうちの１つの情報プロバイダを選択する。前記トレーダは、情報プロバイダのための有効なストリームオブジェクト参照およびハンドルを戻す。スターアップ時において、情報プロバイダは、前記トレーダに登録され、該トレーダに対してそれらの情報伝送能力を通知する。前記Createオペレーションがトレーダファクトリにいて前記ディスパッチャによって呼び出されると、前記トレーダは情報プロバイダファクトリオブジェクトを選択する。該トレーダは、前記情報プロバイダのためにファクトリオブジェクトを呼び出し、前記ストリームオブジェクト参照およびストリームハンドルを前記ディスパッチャに戻す。リクエストされたタイプの情報プロバイダファクトリオブジェクトが前記トレーダに登録されていない場合、または、すべての利用可能な情報プロバイダファクトリオブジェクトがビジーである場合、前記トレーダは例外を戻すことができる。トレーダ登録インターフェイスは、情報プロバイダがトレーダに登録されるのを可能にする。前記トレーダは、前記アダプタのディスパッチャコンポーネントによって該トレーダに提供された情報に基づいて、情報プロバイダを選択することができる。前記トレーダ登録インターフェイスは、Register New Information Providerオペレーション、Un-register Information Providerオペレーション、Change Registration Informationオペレーションを含む。前記Register New Information Provider呼出しは、情報プロバイダによりトレード用に自分自身を登録するために使用される。各情報プロバイダは、その名前（例えば、“File” Server、“Gopher Gateway”など）、そのオブジェクト参照、そのファクトリが生成するよう設定された最大ストリーム数、および、トレーダがロードバランス用のアルゴリズムを実行するのを補助する他の情報を提供する。前記情報プロバイダは、該情報プロバイダが動作停止しまたはトレード用に利用不能になる旨示すために、前記Un-register Information Providerを呼び出す。該Un-register Information Provider呼出しは、登録された情報プロバイダが生成可能なストリームの数、または、トレードに影響する他のプロパティを変更するために使用される。前記トレーダコンポーネントが情報プロバイダファクトリオブジェクト呼出し時に例外を受け取った場合、前記トレーダは故障中のファクトリから回復する可能性を有する。１つ以上の情報プロバイダファクトリオブジェクトが利用可能であり、該ファクトリオブジェクトのうちの１つについて例外が戻された場合、他のファクトリオブジェクトが使用されてよい。ただ１つの情報プロバイダファクトリオブジェクトが利用可能であり、例外が該ファクトリが一時的なものであることを示す場合、前記トレーダは、所定量の時間だけ待ち、該ファクトリオブジェクトの呼出しを再び試みるよう構成可能である。Ｃ．情報プロバイダ１．ゲートウエイゲートウエイ抽象体（Gateway Abstraction）は、外部情報を前記情報マトリックスに接続するために使用される。該Gatewayは、トランスポータコンポーネントとゲートウエイコンポーネントとを含む。前記トランスポータコンポーネントは、前記アダプタ抽象体に使用されるトランスポータコンポーネントと同じ関数を実行する。こうして、前記トランスポータコンポーネントは、様々なトランスポートプロトコル、および、様々異なるプラットフォームのプロトコルに対する様々なインターフェイスのための抽象体を提供する。前記ゲートウエイコンポーネントは、スタートアップ時に前記トレーダに登録される。前記ゲートウエイコンポーネントは、（アダプタコンポーネントによって生成されるような）標準形態のリクエストを取得し、該リクエストを前記トランスポートコンポーネントを使用してネットワークを介して送出可能な外部リクエストに変換するための論理を提供する。また、該ゲートウエイコンポーネントは、遠隔のホストから応答を受け取るための論理を提供する。前記ゲートウエイコンポーネントは、ファクトリインターフェイスおよびストリームインターフェイスを実行する。呼び出されると、ゲートウエイファクトリオブジェクトは、ストリームオブジェクトとストリームコンテキストとを生成する。その処理系に応じて、該ストリームコンテキストは、ファイルハンドル、ＳＱＬカーソル、付加的なオブジェクト参照等を含むことができる。前記ストリームインターフェイスは、Getオペレーション、PutオペレーションおよびDestroyオペレーションを使用する。前記Getオペレーションは、ストリームから一定範囲のバイトをリクエストするために使用される。前記Putオペレーションは、一定範囲のバイトをストリームに格納する。前記Destroyオペレーションは、ストリームオブジェクトに対して、該オブジェクトがもはや使用されない旨知らせる。前記ストリームオブジェクトはその資源を解放し、該オブジェクトは削除されることができる。好ましい実施の形態において、ストリームは、ストリームオブジェクト参照およびストリーム識別子によって指示される。該ストリーム識別子は、ゲートウエイストリームファクトリに対して呼出しがなされるときに、該ファクトリによって割り当てられる。ストリーム識別子は、ストリームテーブルにおけるエントリのハンドルである。前記ストリームテーブルは、提供されるべきデータを決定するためのルックアップテーブルとして使用される。前記ストリームテーブルは、ゲートウエイの各実行ごとに異なることができるストリームコンテキストを含む。従って、前記ストリームコンテキストは、ファイルハンドル、ソケット番号、オブジェクト参照、ＳＱＬカーソル、または、ストリームオブジェクトに対する異なる呼出し間で維持されなければならない他のコンテキストを含むことができる。図７は、gopherゲートウエイ１３９の一例を示す。該ゲートウエイ１３９は、ゲートウエイコンテキスト１６９およびＴＣＰトランスポータコンポーネント１７１を含む。該gopherゲートウエイ１３９は、ＨＴＴＰアダプタに使用されているものと同じＴＣＰトランスポータ１７１を使用する。前記gopherゲートウエイコンテキスト１６９は、前記ＴＣＰトランスポータコンポーネント１７１を使用して、gopherリクエストを送り、前記ネットワークを介して応答を受け取る。２．サーバサーバ抽象体はサーバコンポーネントのみを含む。前記サーバコンポーネントは、（前記アダプタコンポーネントによって生成される）標準形式のリクエストを受け取り、ローカル情報にアクセスすることによって該リクエストを分解する。前記サーバは、ファクトリインターフェイスおよびストリームインターフェイスを実行する。サーバファクトリオブジェクトについてのCreateオペレーションは、リクエストされたファイルを開くよう試みる。前記ファイルを開くことが成功した場合、前記ファクトリは、ストリームオブジェクトを生成し、前記ストリームテーブルにおけるエントリを初期化する。前記ストリームテーブルは、ファイル名、ファイルハンドル、ファイルサイズ、ならびに、各オペレーション後に書き込まれ読み出されるバイト数を含むものである。前記ストリームオブについてのGetオペレーションは、開かれた前記ファイルについて読出しを実行する。前記putオペレーションは該開かれたファイルに書き込む。前記Destroyオペレーションは、前記ファイルを閉じ、前記ストリームテーブルにおけるエントリを削除する。 VII．コンポーネント間におけるシステムレベルでのインタラクションＡ．トレーダ無しインタラクション図８において、上記インターフェイスを使用する様々なコンポーネント間インタラクションの巨視図である。各コンポーネントの実行については後で詳述する。前記コンポーネント間のすべてのインタラクションは、オブジェクト呼出しに基づく。該オブジェクト呼出しは、同一のカプセル内のオブジェクト間、異なるカプセル内のオブジェクト間、および、異なるマシーン上のオブジェクト間では、透明（不可視）的に機能する。図８〜図１３の各々は、ある期間におけるオブジェクト生成およびインタラクション（上から下への処理）を示す。特に、スタートアップ局面、セットアップ局面、ストリーム局面、クリーンアップ局面が示されている。各コンポーネント（すなわち“処理系ライブラリ”または’“ＩＬ”）は、インターフェイスを示す１つまたは複数の付加的なボックスを含むボックスとして示されている。オブジェクトの生成および破棄は、中空の円によって示されている。前記オブジェクトの寿命は、該オブジェクトから延びる縦線によって示されている。中空の先端部を有する矢印は、オブジェクトインタラクションを示す。黒塗りの先端部を有する矢印は、コンテキスト構造体の移送を含む。アダプタ１３１，１３３，１３５および情報プロバイダ１３７，１３９，１４１，１４３は、トレーダ１５０を巻き込んで、または、トレーダ１５０を巻き込むことなく対話する。ほとんどの場合、トレーダ１５０が巻き込まれる。しかし、前記情報伝送システムが１つの目的を提供する１つのサーバを含む場合、前記トレーダは不要である。先ず、図８、図９および図１０を参照して、前記トレーダ１５０を巻き込むことなくインタラクションする場合について説明する。ここで、図６に示すように前記ＷＷＷブラウザ４９からのリクエストがＨＴＴＰアダプタ１３１に到着し、図７に示すように前記gopherゲートウエイが情報プロバイダとして使用される、と仮定する。しかし、例えばgopherアダプタまたはＮＮＴＰアダプタのような他のアダプタにリクエストが到着してもよい。さらに、goph erゲートウエイまたはＦＴＰゲートウエイまたはローカルファイルサーバが情報プロバイダとして使用されてもよい。図８は、スタートアップ、セットアップ、ストリームおよびクリーンアップ局面時におけるコンポーネント間のデータストリーミングを示す。上述のように、各抽象体のコンポーネントは個別のカプセルにロードされるのが好ましい。この図８において、アダプタコンポーネント１５３、ディスパッチャコンポーネントおよびナビゲータコンポーネント１５９を含むアダプタコンポーネントは、アダプタカプセルにロードされている。情報プロバイダコンポーネント１３９は、情報プロバイダカプセルにロードされている。前記スタートアップ局面において、様々なコンポーネントが初期化され、ロードされる。ステップ８０３では、前記処理系ライブラリがロードされ、それらの初期化ルーチンが呼び出される。アダプタコンポーネントおよび情報プロバイダのための初期化ルーチンは、ファクトリオブジェクト１５３０，１３９０を生成させる。前記ナビゲータコンポーネント１５９はナビゲーションオブジェクト１５９０を生成させる。ステップ８０５において、前記ディスパッチャコンポーネント１５１は、コンテキスト構造体を生成し、該コンテキスト構造体をパラメータとしてアダプタファクトリオブジェクトについてのCreateオペレーションを呼び出す。クライアントコンピュータ４０またはその他におけるＷＷＷブラウザ４９から前記アダプタ１３１にリクエストが到着すると、前記Createオペレーションが完了し、アダプタストリームオブジェクトが生成される。この初期的なスタートアップ局面に続いて、セットアップ局面が開始する。前記ＩＭコンピュータ６０は、前記アダプタ１３１に到着するリクエストを処理する。ステップ８０７において、前記クライアントコンピュータ４０にロードされたＷＷＷブラウザ４９からのリクエストが前記アダプタ１３１に到着する。ステップ８０９において、前記アダプタ１５３のファクトリは、前記リクエストのためにアダプタストリームオブジェクト１５３１を生成する。該ストリームオブジェクト１５３１は、前記ウェブブラウザ４９に対するインターフェイスである。次に、ステップ８１１において、前記アダプタ１５３はステップ８０５からのCr eate呼出しに応答する。該Create呼出しに対する応答は、新たに生成されたストリームオブジェクト１５３１に対する参照およびストリームハンドルを含み、前記リクエストのすべての詳細は前記コンテキストバッファに格納される。ステップ８１３では、前記ディスパッチャコンポーネント１５１は、前記ステップ８０５からのCreate呼出しによって生成されたリクエストコンテキストにより、前記ナビゲータコンポーネント１５９を呼び出す。該ナビゲータコンポーネント１５９は、前記リクエストコンテキストを使用して、前記外部リクエストを満足させるストリームオブジェクトを生成可能な情報プロバイダファクトリオブジェクトを選択する。ステップ８１５では、前記ナビゲータ１５９は、選択された前記情報プロバイダファクトリオブジェクト１３９０に関して、前記ディスパッチャ１５１に応答する。そして、前記ディスパッチャ１５１は、前記リクエストされた情報についてのストリームオブジェクトを得るために前記情報プロバイダファクトリオブジェクト１３９０を呼び出す。ステップ８１９において、前記情報プロバイダファクトリオブジェクト１３９０は、前記リクエストされた情報にアクセスする。次に、ステップ８２１において、前記情報プロバイダファクトリは、前記情報のためのストリームオブジェクト１３９１を生成する。最後に、ステップ８２３において、前記情報プロバイダファクトリオブジェクト１３９０は、生成された前記情報プロバイダストリームオブジェクト１３９１に対する参照を前記ディスパッチャ１５１に戻す。前記ストリーム局面において、オブジェクトおよびコンテキストは、相互にデータをストリームし合う。この情報プロバイダとリクエスタとの間において、ストリームは双方向に行うことができる。図８に示したストリーム局面は、情報プロバイダからリクエスタへの情報取出しについて説明するものである。情報プロバイダにおけるデータの格納は、データが逆方向に流れることを除き、データの取出しと同様である。ステップ８２５において、前記ディスパッチャ１５１は、前記Getオペレーションを使用して前記ストリームからデータブロックを得ることによって、前記情報プロバイダストリームオブジェクト１３９１を呼び出す。ステップ８２７では、前記情報プロバイダ１３９は、リクエストされたサイズのデータ片を得るために外部情報ソース（サーバの場合にはローカル情報ソース）にアクセスする。次に、ステップ８２９において、前記情報プロバイダストリームオブジェクト１３９１は、前記データ片、および、前記ストリームから利用可能なデータがそれ以上あるか否かを示す値（通常、ブール論理）を戻す。前記ディスパッチャ１５１は、前記情報プロバイダストリームによって戻されたデータを供給する前記Putオペレーションを使用して、前記アダプタストリームオブジェクト１５３１を呼び出す。ステップ８３３において、前記アダプタは、前記リクエストされた情報を前記外部リクエスタ（ＷＷＷブラウザ４９）に戻す。ステップ８３５において、前記アダプタはステップ８３１においてなされたPut呼出しを戻す。完了済みGetオペレーションから戻る前記情報プロバイダストリームによって示されるようにストリーミングが完了すると、前記ストリームは破棄される。ステップ８３７において、前記ディスパッチャ１５１は、前記情報プロバイダストリームオブジェクト１３９１の前記Destroyオペレーションを呼び出す。ステップ８３９において、前記情報プロバイダは前記呼出しを戻す。次に、ステップ８４１において、前記情報プロバイダストリームオブジェクト１３９１は、前記ストリームのために確保したすべての資源を閉じて解放した後、自分自身を破棄状態にする。ステップ８４３では、前記ディスパッチャ１５１は、前記アダプタストリームオブジェクト１５３１のDestroyオペレーションを呼び出す。ステップ８４５において、前記アダプタストリームオブジェクト１５３１は前記呼出しを戻す。最後に、ステップ８４７において、前記アダプタストリームオブジェクト１５３１は、前記ストリームオブジェクトのために確保したすべての資源を閉じて解放した後、自分自身を破棄状態にする。Ｂ．トレーダを伴うインタラクションここで、図９を参照して、前記トレーダコンポーネント１５０を伴うコンポーネント間インタラクションについて説明する。前記情報プロバイダファクトリオブジェクト１３９０がスタートアップ時にトレーダオブジェクト１５００に登録される点を除き、ここでのスタートアップ局面は前記トレーダを伴わないコンテキストにおけるスタートアップ局面と同様である。ステップ９０７において、前記ＷＷＷブラウザ４９からのリクエストがＨＴＴＰアダプタ１３１に到着する。ステップ９０９では、前記アダプタ１５３は、前記ブラウザ４９に対するインタラクションとして機能する前記リクエストのためのストリームオブジェクト１５３１を生成する。ステップ９１１において、前記アダプタ１５３は、前記スタートアップ局面からのファクトリ呼出しに応答することによって、そのファクトリオペレーションを完了させる。前記応答は、生成されたストリームオブジェクト１５３１に対する参照を含むと共に、リクエストコンテキストにおけるリクエストについての詳細を含むものである。ステップ９１３において、前記ディスパッチャ１５１は、前記スタートアップ局面に生成されたリクエストコンテキストによって前記ナビゲータ１５９を呼び出す。上述の規則に基づき、前記ナビゲータ１５９は、前記コンテキストを使用して、前記外部リクエストを満足させるストリームを生成可能なトレーダオブジェクト１５００を選択する。（１つのトレーダ１５０が使用される場合、前記ナビゲータ１５９は該１つのトレーダ１５０を選択する。）ステップ９１５において、前記ナビゲータ１５９は、前記選択されたトレーダオブジェクト１５０に対するオブジェクト参照を返す。前記ディスパッチャ１５１は、リクエストされた情報についての情報プロバイダストリームオブジェクトを得るために、前記トレーダオブジェクト１５００を呼び出す。そして、ステップ９１９では、前記トレーダオブジェクト１５００は、情報プロバイダファクトリオブジェクト１３９０を選択し、該オブジェクトを呼び出す。前記ファクトリオブジェクト１３９０は、ロードバランス用アルゴリズムに基づいて選択される。該ファクトリオブジェクト１３９０は、ステップ９２１で前記リクエストされた情報にアクセスは、ステップ９２３で前記リクエストされた情報についてのストリームオブジェクト１３９１を生成する。次に、前記情報プロバイダファクトリオブジェクト１３９０は、この生成されたストリームオブジェクト１３９１に対する参照と共に前記呼出しを返す。ステップ９２７では、前記トレーダオブジェクト１５００は、前記ストリームオブジェクト１３９１の参照を前記ディスパッチャに戻す。データのストリーミングおよびクリーンアップは、前記トレーダ無しの場合と同様である。前記トレーダ１５０は、ナビゲータではないコンテキストにとっては透明で見えない。 VIII．コンテキスト間の抽象体レベルでのインタラクション上述のように、各抽象体は、特定の開発者のニーズに応じて上記オペレーションを実行することができる。例えば、アダプタ抽象体はオーセンティケータを含んでいても、含んでいなくてもよい。従って、各抽象体は異なる内部構造を有していてよい。ここで、図１０〜図１３を参照して、１つの抽象体内のコンテキスト間における好ましいインタラクションについて説明する。Ａ．アダプタ図１０ａ〜図１０ｂは、アダプタコンポーネント間のインタラクションを示す。ステップ１００３において、前記オーセンティケータ１６１およびナビゲータ１５９の初期化ルーチンは、リクエストを満足させるためにオブジェクト１６１０および１５９０を生成する。前記トランスポータ１５５およびアダプタ５３は、ファクトリオブジェクト１５５０，１５３０を生成する。ステップ１００５において、前記ディスパッチャ１５１は、前記アダプタ１５３によって生成されたファクトリオブジェクト１５３０を呼び出す。（前記ディスパッチャは、該ディスパッチャが満足させる用意のあるリクエストの数に応じて、多数回、前記ファクトリオブジェクト１５３０を呼び出すことができる。）ステップ１００７において、前記ファクトリオブジェクトに対する呼出しを受け取ると、前記アダプタは前記トランスポータファクトリオブジェクト１５５０を生成する。ステップ１００９において、該トランスポータファクトリオブジェクト１５５０は、トランスポータストリームオブジェクト１５５１を生成する。該トランスポータストリームオブジェクト１５５１は、ステップ１０１１において、トランスポータストリームオブジェクト参照および前記アダプタ１５３に対するハンドルを戻す。ステップ１０１３では、前記アダプタ１５１は前記トランスポータストリームオブジェクトのAcceptオペレーションを呼び出す。上述のように、該Acceptオペレーションは、前記トランスポータストリームオブジェクト１５５１が入って来るリクエストを待つようにする。スタートアップ局面はステップ１０１５において開始する。ステップ１０１５において、前記ネットワークを介して、前記ＷＷＷブラウザ４９からの接続リクエストが前記アダプタに到着する。詳しくは、該リクエストは、前記トランスポータコンポーネント１５５に到着し、該トランスポータコンポーネント１５５は、ステップ１０１７において、前記トランスポータストリームオブジェクト１５５１が未完了のAccept呼出しを戻すようにする。ステップ１０１９では、前記アダプタファクトリオブジェクト１５３０は、ステップ１０２１において入って来るリクエストを読むために、前記トランスポータストリームオブジェクト１５５１を呼び出す。ステップ１０２３では、前記トランスポータストリームオブジェクト１５５１は、前記アダプタファクトリオブジェクト１５３０に前記データを戻す。ステップ１０２５において、前記アダプタファクトリオブジェクト１５３０は前記リクエストを解析する。前記リクエストがユーザ情報を含むものである場合、該ユーザ情報は、ステップ１０２７において前記オーセンティケータによって確認される。ステップ１０２９では、前記アダプタファクトリオブジェクト１５３０はアダプタストリームオブジェクト１５３１を生成する。該アダプタストリームオブジェクト１５３１は、前記トランスポータストリームオブジェクト参照およびハンドルを含むコンテキストコンポーネントを有する。ステップ１０３１において、前記アダプタファクトリオブジェクト１５３０は、前記アダプタストリームオブジェクト参照およびハンドルを前記ディスパッチャ１５１に戻すことによって、ステップ１００５から前記Create呼出しを戻す。ステップ１０３３において、前記ディスパッチャ１５１は、前記ナビゲータ１５９を呼び出し、前記リクエストのための情報プロバイダを見つける。トレーダが使用されていない場合、前記ナビゲータ１５９は、ステップ１０３５において、情報プロバイダの参照を戻す。トレーダが使用されている場合、前記ナビゲータ１５９はトレーダオブジェクト参照を戻す。前記ナビゲータは、さらに、トランスフォーマオブジェクト参照を戻してもよい。ステップ１０３７では、前記ディスパッチャ１５１は、情報プロバイダファクトリオブジェクト（図示せず）を呼び出し、ストリームオブジェクトを生成する。ステップ１０３９において、前記情報プロバイダは、ストリームオブジェクトおよびハンドルを戻す。図１０ｂは、アダプタ抽象体についてのストリーム局面およびクリーンアップ局面を示すものである。ステップ１０４１において、前記ディスパッチャ１５１は、前記情報プロバイダストリームオブジェクトについてのGetオペレーションを呼び出し、データブロックを得る。ステップ１０４３において、前記情報プロバイダストリームオブジェクトは前記データブロックを戻す。ステップ１０４５では、前記ディスパッチャ１５１は、前記Putオペレーションを使用して、取り出したデータを前記アダプタストリームオブジェクト１５３１に書き込む。ステップ１０４７において、前記アダプタストリームオブジェクト１５３１は、前記 Putオペレーションを使用して、前記データを前記トランスポータストリームオブジェクト１５５１に書き込む。該トランスポータストリームオブジェクト１５５１は、ステップ１０４９において、前記ネットワークを介して、前記データを前記ウェブブラウザ４９に書き込む。ステップ１０４９および１０５１において、前記トランスポータストリームオブジェクト１５５１およびアダプタストリームオブジェクト１５３１は、各々のPutオペレーションを戻す。前記情報プロバイダストリームオブジェクトについてのGetオペレーション、ならびに、前記アダプタストリームオブジェクトおよびトランスポータストリームオブジェクトについてのPutオペレーションを連続的に呼び出す処理は、前記情報プロバイダストリームオブジェクトが前記ディスパッチャ１５１にストリームエンド指示を戻すまで続く。ステップ１０５３において、前記ディスパッチャ１５１は、前記Destroyオペレーションを使用して、前記情報プロバイダストリームオブジェクトを呼び出す。ステップ１０５５において、前記情報プロバイダストリームオブジェクトは、その呼出しを戻し、これを破棄する。ステップ１０５７では、前記ディスパッチャ５１は、前記Destroyオペレーションを使用して、前記アダプタストリームオブジエクトを呼び出す。そして、前記アダプタストリームオブジェクト１５３１は、ステップ１０５９において、トランスポータストリームオブジェクトのDest royメソッドを呼び出す。ステップ１０６１において、前記トランスポータストリームオブジェクト１５５１は、前記ネットワーク接続を閉じることによって前記リクエストを終了させる。前記トランスポータストリームオブジェクト１５５１は、ステップ１０６３において、前記トランスポータストリームオブジェクト１５５１は、ステップ１０５９からの呼出しを完了し、ステップ１０６５において自分自身を破棄する。ステップ１０６７では、前記アダプタストリームオブジェクト１５３１は、ステップ１０５７からの呼出しを完了し、ステップ１０６９においてこれを破棄する。前記ディスパッチャは、次に入って来るリクエストを得るために、ステップ１０７１において前記アダプタファクトリオブジェクト１５３０を再呼出しする。ステップ１０７３において、前記アダプタ１５３は前記トランスポータファクトリオブジェクトを呼び出す。該トランスポータファクトリオブジェクトは、ステップ１０７５においてトランスポータストリームオブジェクト１５５２を生成する。ステップ１０７７では、前記トランスポータストリームオブジェクトは、生成された前記ストリームオブジェクトの参照およびハンドルを前記アダプタ５３に戻す。ステップ１０７９において、前記アダプタ１５３は前記トランスポータストリームオブジェクトのAcceptオペレーションを呼び出す。こうして、前記トランスポータ５５は他のリクエストを受け取ることができる状態になる。新たなリクエストが到着すると、前記アダプタは再び前記セットアップ局面に入る。Ｂ．トレーダ上述のように、Trader（トレーダ）は、トレーダファクトリインターフェイスおよびトレーダ登録インターフェイスを実行するトレーダコンポーネントのみを有する。該トレーダコンポーネントは、図１１に示すようにこれらのインターフェイスを実行する。セットアップ局面において、ファクトリリクエストが前記トレーダ１５０に到着し、該トレーダは、前記リクエストを満足させることができる特定のクラスの情報プロバイダを選択する。そして、ステップ１１０５において、前記トレーダは、前記情報プロバイダストリームオブジェクトを生成するために、前記情報プロバイダファクトリを呼び出す。前記情報プロバイダは、ステップ１１０７において、ストリームオブジェクト１３９１を生成する。次に、ステップ１１０９では、前記情報プロバイダは、前記情報プロバイダストリームオブジェクトの参照およびストリーム識別子を前記トレーダに戻す。ステップ１１１１では、前記トレーダは、前記コーラすなわちディスパッチャに対して前記情報プロバイダストリームを戻す。前記ストリーム局面において、前記ディスパッチャは、前記トレーダの仲介に気付くことなく、前記情報プロバイダストリームからストリームし続ける。前記情報プロバイダがストリーミングし終ると、該情報プロバイダはストリームエンド指示を送る。クリーンアップ局面において、前記ディスパッチャは生成された前記ストリームを破棄する。このクリーンアップは、トレーダ１５０を使用することなく行われる。Ｃ．情報プロバイダ図１２は、メモリ４０に格納されたストリームテーブルおよびオブジェクトテーブルを使用したファクトリインターフェイスおよびストリームインターフェイスの情報プロバイダ処理系を説明するものである。スタートアップ局面において、ステップ１２０３では、前記処理系ライブラリの初期化ルーチンが呼び出される。このルーチンは、情報プロバイダファクトリオブジェクト１３９０を生成する。前記トレーダが使用されている場合、前記Register New Information Provi derオペレーションを使用してトレーダオブジェクトを呼び出すことによって、前記情報プロバイダが前記トレーダに登録される。ステップ１２０５において、前記情報プロバイダは、前記ディスパッチャまたはトレーダからのファクトリ呼出しを受け取る。前記情報プロバイダファクトリの実行において、前記呼出しにおける情報は、情報ソースを選択し、その情報ソースが前記情報にアクセス可能であることを証明するために使用される。ステップ１２０８において、前記ファクトリの実行は、新たなストリームについてのストリームテーブルエントリを選択する。前記実行は、前記ストリームのための新たなユニークなハンドルを生成し、該ストリームコンテキストを前記テーブルエントリに書き込む。次に、ステップ１２０９において、前記ファクトリの処理系は、アドレス可能なストリームオブジェクト１３９１を生成し、これを選択する。このストリームオブジェクトの参照およびハンドルは、ステップ１２１１において、前記コーラに戻される。ストリーム局面において、ストリーミングは、前記GetオペレーションおよびP utオペレーションを使用して、２方向に行われることができる。ステップ１２１３において、ストリーム呼出しは、Get呼出しまたPut呼出しを介して前記ストリームオブジェクトに到着する。前記呼出しはストリームハンドルを含む。前記ストリームオブジェクト１３９１は、ステップ１２１４において、前記ストリームハンドルを確認し、該ハンドルを使用して前記ストリームテーブルのエントリにアクセスする。ステップ１２１５において、前記呼出しを完了させるのに必要なデータをアクセスするために、前記ストリームテーブルが使用される。ステップ１２１７では、前記ストリームオブジェクト１３９１が前記呼出しを戻す。クリーンアップ局面において、前記ストリームハンドルを含むDestroy呼出しが、前記ストリームオブジェクト１３９１に到着する。ステップ１２２０において、前記ストリームハンドルが、確認され、前記ストリームテーブルのエントリを見つけるために使用される。ステップ１２２３では、前記Destroy呼出しが完了し、こうして、ステップ１２２５において前記ストリームオブジェクト１３９１を破棄し、前記ストリームテーブルを解放する。Ｄ．トランスフォーマトランスフォーマは、アダプタおよびゲートウエイと共に使用されてよい。従って、トランスフォーマコンテキストが使用される場合、データのストリームは異なる形態で行われる。図１３は、トランスフォーマコンポーネントへのおよび該トランスフォーマコンポーネントからのインタラクションを示す。最初に、ステップ１３０３において、トランスフォーマファクトリオブジェクト１５７０および情報プロバイダファクトリオブジェクトが生成される。次に、ステップ１３０５において、前記アダプタコンポーネント１５３から前記トランスフォーマファクトリオブジェクト１５７０に、ファクトリ呼出しが到着する。前記トランスフォーマファクトリオブジェクト１５７０は、ステップ１３０７において、情報プロバイダファクトリオブジェクト１３９０を呼び出す。該情報プロバイダファクトリオブジェクト１３９０は、ステップ１３０９において、情報プロバイダストリームオブジェクト１３９１を生成する。ステップ１３１１において、前記情報プロバイダファクトリオブジェクト１３９０は、前記トランスフォーマファクトリオブジェクト１５７０に対して、新たに生成されたストリームオブジェクト参照を戻す。ステップ１３１３では、前記トランスフォーマファクトリオブジェクト１５７０は、トランスフォーマストリームオブジェクト１５７１を生成し、前記トランスフォーマストリームオブジェクトのコンテキストの一部として前記情報プロバイダストリームオブジェクト参照を維持する。そして、前記トランスフォーマファクトリオブジェクト１５７０は、前記トランスフォーマストリームオブジェクトの参照およびハンドルをそのコーラに戻す。ステップ１３１７において、Get呼出しが前記トランスフォーマストリームフォブジェクト１５７１に到着する。ステップ１３１９において、前記トランスフオーマは、データを得るためのGet呼出しを使用して、前記情報プロバイダストリームオブジェクト１３９１を呼び出す。ステップ１３２１では、前記情報プロバイダストリームオブジェクト１３９１はデータを戻す。該トランスフォーマは、変換関数を使用して、このデータを変換する。前記変換関数は、変換すべきデータ用の取出しバッファを調べる。変換すべき十分なデータが前記バッファに含まれる場合、そのデータは、前記バッファから取り出され、変換され、応答バッファに格納される。前記応答バッファおよび取出しバッファが満杯状態ではなく、前記情報プロバイダのストリームオブジェクトが“これ以上データ無し（no mor e data）”を示していない場合、前記情報プロバイダに対するGet呼出しが再び行われる。前記トランスフォーマストリームオブジェクトのGetメソッドは、前記応答バッファからデータを戻す。前記情報プロバイダのストリームオブジェクト上に“これ以上データ無し（no ore data）”指示が無く、前記取出しバッファが空状態であって、前記応答バッファの残りの部分が戻れされた場合、前記ストリームオブジェクト１５７１は“これ以上利用可能なデータ無し”を指示することになる。ステップ１３２３において、前記データが前記ディスパッチャに戻される。データが格納中である場合、ステップ１３１７では、Put呼出しが前記トランスフォーマに到着することになる。前記Put呼出しは、情報の流れが逆方向である点を除いて、前記Get呼出しと同様に作用する。クリーンアップ局面において、前記Destroyメソッドは、ステップ１３２５で、前記トランスフォーマストリームオブジェクト１５７１に到着する。前記トランスフォーマ１５７は、ステップ１３２７において、前記情報プロバイダストリームオブジェクト１３９１についてDestroy呼出しを実行する。ステップ１３２９において、前記情報プロバイダストリームオブジェクトは前記呼出しを戻す。該情報プロバイダは、ステップ１３３１において、前記情報プロバイダストリームオブジェクト１３９１を破棄する。ステップ１３３３において、前記トランスフォーマストリームオブジェクト１５７１は、前記呼出しを戻す。ステップ１３３５では、前記トランスフォーマは前記ストリームオブジェクト１５７１を破棄する。 IX．表示変換ユーティリティ図１４ａはＩＤＬで書かれたデータ構造体の一例５０１を示すものである。ＩＤＬで書かれた構造体“MyStruct”は、３つのコンポーネント、即ち、charデー型コンポーネントと、long（長）データ型コンポーネントと、boolean（ブール）データ型コンポーネントを含む。この型定義は、インターフェイス定義と共に、例えばIDLソースファイル１０１に含まれる。コードジェネレータは、IDLソースファイルを解析し、CIN記述１４０２を含むへッダファイルを生成する。CIN記述子は、（構造体名などの）識別子を使わずに構造体を簡潔に記述する一連のASCII文字を含む。この例においてｂ3文字は、データ構造体を、３つの要素を含むIDL struct型として識別する。Cは、IDL cha r型を示す。F文字は、IDL long型を識別し、B文字は、ブールデータ型を識別する。関数PCU_PREPAREは、一定のデータ型のCIN記述を、CIN記述よりもランタイムに使いやすい“準備CIN”形式に変換する。ルーチンPCU_PACKおよびPCU_UNPACK の使用に先立って、コードジェネレータ１１１によって生成された、へッダファイル１１９に含まれる各データ構造体のCIN記述が“準備”されなければならない。PCU_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データ構造体を最初に作成することにより、それらのop_ tagを作成する。ctx構造体を使用することは、個々のパラメータを各種の内部関数に送ることより望ましい。ctx構造体はＣ言語で次のように定義される。前記ctx構造体のフィールドは次のとおりである。上記opポインタは、準備CIN内の現在のオペレーションを指す。このポインタは、PCU_PREPAREが各CINアイテム（後述）を解析するときにインクリメントされる。前記op_endポインタは、準備 CIN＋１における最後のオペレーションを指す。Cinptrポインタは、準備中の全C IN文字列から読み込まれる次のバイトを指示する。cinendポインタは、準備中の CIN文字列の最終バイト＋１を指示する。このctx構造体のoffset、alignおよびs izeフィールドは、CIN記述データ構造体における処理済フィールドのオフセット、必要なアラインメント（境界整列）およびサイズを指定するprocess_cin_item （後述）の出力パラメータである。処理済みCIN文字列において遭遇する無限シーケンス（unbounded sequences）および文宇列（string）の個数のランニングカウントはnr_unboundedに含まれている。IDL“any”データ型を使用するフィールドのランニングカウントは、nr_anysフィールドに含まれている。フィールドp rev_branchは、前に処理された共用体ブランチ（union branch）オペレーションを指示する。このフィールドのリストは、そのヘッドが主共用体オペレーションに含まれるブランチオペレーションのリストの構築に使用される。共用体オペレーションはmain_unionによって指示される。 ctx構造体が作成されると、PCU_PREPAREは、CIN文字列中の各文字ごとにPROCE SS_CIN_ITEM、CIN文字列の各符号付きlong整数に対するTAKE_LONGおよびCIN文字列の各無符号long整数に対するTAKE_ULONGを呼び出す。PROCESS_CIN_ITEMは、CI N文字列の単一のアイテムを処理する。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データ構造体を変更する。先ず、PROCE SS_CIN_ITEMがopポインタをインクリメントして上記構造体の他のフィールドを適正CINアイテムに対応させる。さらに、ctx構造体のsize、alignおよびoffset フィールドが変更される。各データ型のためのアラインメントは、以下のアラインメント規則に基づいて決定される。基本データ型がそのサイズに合わされる。従って、sortデータ型は２バイトのアラインメントを有し、long型は４バイトアラインメントを有し、等々である。struct型および共用体型は、最高アラインメント要求付きの包含フィールドと同じアラインメントを有する。ともかく、stru ct型および共用体型は、好ましくは、少なくとも２バイトのアラインメント要求を有する。最後に、struct型および共用体型は、好ましくは、多数のアラインメント要求に埋め込まれる。 PROCESS_CIN_ITEMへの呼出しが戻るたびに、PCU_PREPAREは変更されたctx構造体に基づいてop_tagデータ構造体を作成する。次いで、これらのop_tag構造体のアレイが、PCU_PREPAREの呼出し後に、準備CINバッファであるprepbufに格納される。このop_tag構造体は、他の関数によって簡単に操作できる線形構造体である。構造体op_tagは、以下のように定義される。前記type（型）パラメータは、上記データ構造体のIDLデータ型を表す。type_de f型定義は、考えられる全データ型を列挙するものである。パラメータoffsetは、そのデータ構造体がある構造体または共用体の一部である場合、包含する構造体または共用体の始端からの該コンポーネントデータ型のオフセットである。データ型（１、２、３、４または８バイト）が要求するアラインメントは、alignパラメータによって指定される。sizeパラメータは、丸めを含むバイトでデータ構造体のサイズを示す。nr_elementsパラメータは、様々異なる目的に使用される。アレイについて、このパラメータは、全次元の要素の総数を示す。シーケンスについて、上記パラメータは、最大出現回数を示す。文字列について、上記パラメータは、ゼロ終了を除く最大サイズを指定する。構造体について、上記パラメータは、その構造体中の主フィールドの数を示す。共用体については、上記パラメータは、共用体中のフィールド数を示す。パラメータbranch_labelおよびis_d efault_branchは、共用体ブランチのみのためのものである。branch_labelパラメータは、上記共用体のIDL仕様において指定されたcaseラベル値を含み、is_de fault_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コンポーネント、無限列／文字列および“any （任意）”型を支援する。 PCU_PACKは、指定されたフォーマットに基づいて構造化データ型のコンポーネントを出力バッファに格納する。PCU_PACKは、Ｃ言語で次のように定義される。最初の３つのパラメータは、出力バッファへのデータの詰め込み方を指定する。これらのパラメータは、コーラ（呼出し側）によって提供された変換を実行するためのコーラ定義関数でよい。第１のパラメータdst_integer_fmtは、出力バッファにおいてshort型、long型およびlongデータ型に使用するフォーマットを指定する。このフォーマットに関して可能な値の例は、バイト重要度がアドレスの増加につれて減少する場合の整数表現を指定するPCU_INTEGER_BIGENDIAN、又は、バイト重要度がアドレスの増加につれて増加する場合の整数表現を指定するPCU_ INTEGER_LITTLEENDIANである。パラメータdst_real_fmtは、出力バッファでフロートおよび倍データ型に使用するフォーマットを指定する。このパラメータのサプル値は、例えばTandem T16フォーマットを使用する浮動小数点数表現を指定するPCU_REAL_T16などの、標準IEEEフォーマットまたはベンダ指定値を使用する浮動小数点数表現を指定するPCU_REAL_IEEEである。第３のパラメータdst_char_fm tは、出力バッファでchar型および文字列型に使用するフォーマットを指定する。このパラメータの１つの可能値は、ISOラテン−1フォーマット（Latin-1 form at）、ASCIIのスーパーセットを使用する文字表現である。もう１つの可能な値はIBMホストと互換性のあるEBCDICである。上述の^＊prepbufパラメータは、PCU_PREPAREによって戻された準備CIN記述を含むアドレスを指示するポインタである。^＊inbufパラメータは、出力バッファに格納される構造化データのアドレスを指示するポインタである。*outbufパラメータは、実際のパックされたデータを受け取る出力バッファのアドレスを指示するポインタである。outbufに収容可能なバイトの最大数はoutbuf_max_lenパラメータに含まれている。実際にoutbufに書き込まれるバイト数は、outbuf_lenパラメータによって戻される。バイト数が必要でない場合、NULLの値は、このパラメータとして渡せばよい。PCU_SHORTOUTBUFが上記関数によって戻された場合、o utbuf_lenパラメータは必要なoutbufサイズを取得する。従って、出力バッファにメモリを動的に割り当てるため、クライアントアプリケーションは、PCU_PACKを２回呼び出すことができる。最初の呼出しで、outbuf _max_lenがゼロに設定される。次いでPCU_PACKがPCU_SHORTBUFを戻し、outbuf_l enが必要な出力バッファサイズを含むこととなる。ここで出力バッファの正しいメモリ量をPCU_PACKの２回目の呼出しに先立って割り当てることができる。 PCU_PACKは最初にctx構造体を生成する。このctx構造体は、PROCESS_CIN_ITEM によって使用されるコンテキスト構造体と同様の関数を提供する。上記構造体は、大量のコンテキストがPCU_PACKと、PCU_PACK_ENGINEによって呼び出される低水準ルーチンとの間で共用されることを可能にする。上記ctx構造体は、PCU_PAC Kに対する下位関数によって使用され、次のように定義される。 PCU_PACKへの呼出しに指定されたリクエストされたあて先フォーマットはctx構造体に渡される。これら３つのフィールドはIDL“任意”型を処理するためPCU_P ACKを巡回的に呼び出さなければならない場合に必要になる。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において指定されている。このパラメータは、浮動小数点数字を表すフォーマットを指定する。浮動型と倍（do uble）型のアラインメントは、dst_real_fmtパラメータによって指定される。このパラメータは、整数を表現するフォーマットに対応する。charsの表現はdst_c har_fmtパラメータによって指定される。このdst_char_fmtパラメータは、文字を表現するフォーマットを指定する。ブール論理およびオクテット（octets）は再アラインされない。上記“任意”型は、（そのアラインメントがdst_integer_ fmtパラメータに基づいている）CIN記述の長さを指定する符号なしlong、型を記述するCIN文宇列（未変換ASCII文宇列）および（この変換規則に基づいて格納された）データ自体として格納される。アレイ、共用体などの混成型も再アラインされる。アレイは要素間のパディングなしで格納される。シーケンスは、上記出現回数の前の出現回数を示す符号なしlong整数として格納される。出現間のパディングは除去される。long整数のフォーマットは、上述のdst_integer_fmtパラメータによる。文字列は、charsとして格納された特定数の文字前の文字列長を示す符号なしlongとして格納される。前記charsのフォーマットは、dst_char_fmtパラメータによって決定される。構造体はパディングなしでフィールド毎に格納される。共用体は活性共用体ブランチが続くlong型として格納される。受け取り側において、サーバアプリケーションは、PCU_PACKを使用してパックされたバッファから未構造化データ型およびその付属物を抽出しなければならない。次いでPCU_UNPACKが、その未構造化データを、任意のデータ構造体の準備CI Nに基づいてそのデータ構造体に格納する。PCU_UNPACKは次のように定義される。最初の３つのパラメータは、PCU_UNPACKの最初の３つのパラメータに対応する。これらのパラメータは、入力バッファに格納されたデータ型のフォーマットを指定する。これらのパラメータは、好ましくは、そのPCU PACK版と同一である。上記*prepbufパラメータは、PCU_PREPAREによって戻された準備CIN記述を含むアドレスを示すポインタである。入力バッファのアドレスは*inbufが指示する。in bu fの長さは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_PACK によって提供された出力バッファ）からデータを抽出し、そのデータを出力バッファに配置するためのコーラ供給関数へのポインタを受け取る。準備CINバッファもパラメータとして提供される。PCU_NPACK_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を呼び出す。PC U_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 前記アレイのための文字の生成は、ステップ１７１３，１７１５，１７１７に示されている。このアレイ表現において、上記文字ａは（チャートＢに示すように）前記アレイのスタートを示している。文字nr_dimensionsは、該アレイにおける次元の数を示す数字である。また、文字size_1，size_2，size_nは、それぞれ、前記アレイの一次元、二次元およびｎ次元におけるサイズを示す。base-type は、前記アレイの各アレイ要素ごとの記述子である。様々な基本型の表現は、チャートＡに示されたオリジナルの基本型テーブルから導出される。ＩＤＬは、ユーザによって定義された構造体型を定義する。各構造体は、基本データ型または混成データ型の１つまたは複数のフィールドで構成される。構造体はＣＩＮにより次のように表現される。ｂnr_fields field_1[field＿2...field_n] １つの構造体を記述する文字の生成は、ステップ１７１９およびステップ１７２１に示されている。チャートＢに示すように、上記文字ｂは前記構造体（struct ）のスタートを示している。数字nr_fieldsは、前記構造体におけるフィールドの数を示す。前記構造体におけるフィールドは、fielｄ_1，field_2,field_nによって記述される。各フィールドは基本型または混成型である。前記構造体の基本型フィールドは、チャートＡに示されているように記述される。混成型はここに示されているように記述される（すなわち、アレイは、次元の数および各次元のサイズ、スタート文字ａ等で記述される）。ＩＤＬは、データ型のシーケンスを定義する。１つのシーケンスは、２つの特性、すなわち、（コンパイル時に決定される）最大サイズと（実行時に決定される）長さとを有する１次元のアレイである。シーケンスは次のように表現される。ｃnr-occurrences base_type 前記シーケンスのための文字の生成は、ステップ１７２３，１７２５に示されている。この表現において、上記文宇ｃは、チャートＢに示すように、前記シーケンスのスタートを示している。文字nr_occurrencesは、該シーケンスにデータ型の出現回数を示す。該出現回数の後には、前記シーケンスにおけるデータ型出現ごとの実際の記述予base_typeが続く。データ型が基本型である場合、チャートＡの適当な記述子が使用される。前記シーケンスが混成型である場合、記述子はここに説明されているように作成される。シーケンスのシーケンスも可能である。ＩＤＬは、空（nulｌ)文字を除くすべての８ビットの量（quantitｙ)で構成される文字列型を定義する。１つの文字列は、charのシーケンスに類似している。文字列はＣＩＮにより次のように表現される。ｄsize 文字列のスタートは文字ｄで示される。該文字列のサイズは、ステップ１７２７で生成される文字sizeによって示される。ＩＤＬにおいて、共用体（union）は、Ｃプログラミング言語の“共用体”とＣ“switch”文との間の交配体である。換言すれば、共用体シンタクスは、共用体ブランチを示す“case”ラベルと共に“switch”文を含むものである。ＩＤＬ共用体は区別されなければならない。すなわち、共用体のヘッダは、現在の呼出しインスタンスにどの共用体要素を使用すべきかを決定する型別タグフィールドを指定しなければならない。共用体および共用体ブランチは、ＣＩＮにより次のように表現される。ｅnr_fields flabel_1 field_1［flabel_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（Ｋ）である。２番目のフィールドは符号無しのlo ng（Ｋ）である。オペレーションをＣＩＮで記述する場合、前記方法はステップ１８５１に進む。図１８は、オペレーションのための記述子を生成するためのステップを示すフローチャートである。オペレーション記述子は、ＣＩＮにより次のように生成される。ステップ１８５１において、前記コードジェネレータは、前記オペレーションの記述子の残部を構成する文字列から導出されるユニークな整数operation_synops isを生成する。該整数は、前記ＣＩＮ記述子における残りの文字について例えば巡回冗長検査を実行することによって導出される。次に、前記コードジェネレータは、前記オペレーションの本来のＩＤＬ名から導出されるユニークな文字列op eration_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で生成される。次のものは元々ＩＤＬで記述された２つのサンプルオペレーションである。この発明の方法を使用することによって、上記AddオペレーションはＣＩＮにより次のように表現される。 126861413+3+ADDA3+DFAFAF0+0+ 前記オペレーションのＣＩＮ記述子は次のように説明される。最初の数字（12 6861413）は、文字列“3+ADDA3+DFAFAF0+0+”について巡回冗長検査を実行することによって、前記ＣＩＮの残部から導出される。オペレーションｉｄは３つの文字（３＋）を含む。これらの３つの文字は、オペレーションｉｄとしての文字列“ADD”である。すべてのＩＤＬ識別子は、固有のものであり、caseとは独立でなければならない。従って、オペレーションｉｄは大文字とされる。前記オペレーションは、一方向性属性（Ａ）を含まず、３つの“パラメーダ”（3＋）を含む。前記関数が結果を返すので、実際上、最初の“パラメータ”が関数結果（Ｄ）である。前記関数結果は符号付きのlong（Ｆ）である。次のパラメータ（実際上、最初のパラメータ）はｉｎパラメータ（Ａ）である。該パラメータは、型分類された符号付きのlong（Ｆ）のパラメータである。３番目のパラメータは、型分類された符号付きのlong（Ｆ）のinパラメータである。例外およびコンテキストは存在しない（０＋）。同様に、上記SubtractオペレーションはＣＩＮ記述子により次のように表現される。 453399302-9+SUBTRACTA3+DFAF0+0+ インターフェイスも、この発明の方法を使用することによって同様に記述される。図１０はインターフェイス記述子の生成を示す。インターフェイスは次のように定義される。整数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オペレーションのオペレーション記述子は、オペレーションの数を示す文字の次にくる。上述の如く、ＣＩＮ記述子は、クライアントアプリケーションおよびサーバアプリケーションの両方にリンクされるヘッダファイルに含まれる。こうして、クライアントおよびサーバの両方は、各々が適当と考える記述子を利用することができる。前記ＣＩＮは様々な形態で使用可能である。例えばデータ型のＣＩＮ記述子は、構造化されたデータ型をパックしたりアンパックしたりするための汎用関数を作成するのに有用であろう。さらに、ＣＩＮ記述子は、迅速にインターフェイスを比較するためにも使用可能である。例えば、サーバアプリケーションは、ＣＩＮで記述された２つのインターフェイスを含むヘッダファイルを有してもよい。この場合、該サーバアプリケーションは、既知の文字列比較関数を使用してＡＳＣＩＩ文字列記述子を比較することができる。ＣＩＮ記述が同一である（または類似している）場合、サーバは、サーバアプリケーションにおいて共通の方法を使用して両インターフェイスのオペレーションを実行することができる。こうして、上記ＣＩＮを使用して、異なる（しかし類似している）インターフェイスのための多数の時間コード化方法をセーブする。ＸＩ．ピクルドＩＤＬフォーマットデータ構造体の作成ピクルド（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_unlon）である場合、これは解析ツリーエントリにおいて図２３に示すようなに表現される。前記データ構造体２１１７は、識別子２３０３を示す符号なしの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データ構造体を使用して前記ＩＤＬソースが記述されると、前記データ構造体は任意の既知の方法を使用してファイルまたはデータベースに移送される。以上、オブジェクト指向型の情報伝送方法および装置について説明してきたが、この発明は様々な変更がなされてよい。例えば、１つのトレーダを使用する例について説明したが、この発明は多数のトレーダを使用する場合にも同様に適用可能である。実際上、多数のプロトコルおよび構成設定をサポートするために、各コンテキストをコピーしてもよい。

───────────────────────────────────────────────────── フロントページの続き (72)発明者エルレンケッター，アンスガードイツ国Ｄ―61267 ノイアンスパッハ, アウフデルハイデ 44 (72)発明者スコフィールド，アンドリュー，チャールズスイス連邦共和国ＣＨ―6330 シャム, リンデンブール 27 (72)発明者カエザー，レト，リチャードスイス連邦共和国ＣＨ―8968 ムットシェレン，スタインフガイシュトラーセ 40

Claims

【特許請求の範囲】１．第１のコンピュータのメモリに格納されたリクエストされた情報を第２のコンピュータのメモリに格納されたリクエスタに伝送するためのオブジェクト指向型方法であって、前記第１のコンピュータに、前記リクエストされた情報にアクセスするための情報プロバイダコンポーネントをロードするステップと、前記情報プロバイダコンポーネントから、情報プロバイダファクトリオブジェクトを生成するステップと、前記第１のコンピュータに、前記情報プロバイダコンポーネントを選択するためのナビゲータコンポーネントをロードするステップと、前記ナビゲータコンポーネントからナビゲータオブジェクトを生成するステップと、前記第２のメモリに、前記リクエスタからの前記リクエストされた情報についてのリクエストを受け取るためのアダプタコンポーネントをロードするステップと、前記アダプタコンポーネントから、アダプタストリームオブジェクトを生成するためのアダプタファクトリオブジェクトを生成するステップと、前記アダプタファクトリオブジェクトから、前記リクエストについてのアダプタストリームオブジェクトを生成するステップと、前記情報プロバイダコンポーネントから、情報プロバイダファクトリオブジェクトを生成するステップと、前記ナビゲータオブジェクトを使用して、前記情報プロバイダファクトリオブジェクトを選択するステップと、前記情報プロバイダファクトリオブジェクトを使用して、前記リクエストされた情報にアクセスするステップと、前記情報プロバイダファクトリオブジェクトから、情報プロバイダストリームオブジェクトを生成するステップと、前記アダプタストリームオブジェクトおよび情報プロバイダストリームオブジエクトを使用して、前記情報プロバイダコンポーネントから前記アダプタコンポーネントに前記リクエストされた情報を伝送するステップとを具備する方法。２．前記第２のコンピュータのメモリに、前記リクエストを前記アダプタコンポーネントおよび情報プロバイダコンポーネントに送るディスパッチャコンポーネントをロードするステップと、前記リクエストに関する情報を含むリクエストコンテキストにより、前記ディスパッチャコンポーネントから前記ナビゲータオブジェクトを呼び出すステップとをさらに具備する請求の範囲第１項に記載の方法。３．前記ナビゲータオブジェクトが、前記リクエストコンテキストを使用して前記情報プロバイダファクトリオブジェクトを選択する請求の範囲第２項に記載の方法。４．前記リクエストコンテキストが、コンテキスト名およびコンテキスト値を含むオクテット構造体である請求の範囲第３項に記載の方法。５．前記情報プロバイダコンポーネントから前記アダプタコンポーネントに前記情報をストリームするステップが、前記リクエストされた情報の個別部分を得るために、前記情報プロバイダストリームオブジェクトを呼び出すステップと、前記情報プロバイダストリームオブジェクトにより、前記リクエストされた情報の個別部分にアクセスするステップと、前記リクエストされた情報の個別部分を戻すステップと、前記アダプタストリームオブジェクトを呼び出し、該アダプタストリームオブジェクトに前記リクエストされた情報の個別部分を書き込むステップと、前記リクエストされた情報の個別部分を前記リクエスタに戻すステップとをさらに具備する請求の範囲第１項に記載の方法。６．前記情報プロバイダストリームオブジェクトから前記リクエストされた情報の他の個別部分が利用可能か否かを示すステップをさらに具備する請求の範囲第５項に記載の方法。７．前記情報プロバイダストリームオブジェクトを破棄するステップと、前記アダプタストリームオブジェクトを破棄するステップとをさらに具備する請求の範囲第６項に記載の方法。８．前記情報プロバイダファクトリオブジェクトから情報プロバイダストリームオブジェクトを生成するステップが、前記情報プロバイダファクトリオブジェクトに対する呼出しに含まれる情報を使用して、情報ソースを選択するステップと、メモリに格納されたストリームテーブルから新たなストリームのためのエントリを選択するステップと、前記ストリームのためのハンドルを生成するステップと、前記ストリームに関するストリームコンテキスト情報を前記ストリームテーブルエントリに書き込むステップと、前記情報プロバイダストリームオブジェクトを生成するステップと、前記情報プロバイダファクトリオブジェクトのコーラに対して、情報ストリームオブジェクト参照および前記ハンドルを戻すステップとをさらに具備する請求の範囲第５項に記載の方法。９．前記情報プロバイダストリームオブジェクトに対する呼出しに含まれるストリームハンドルを確認するステップと、確認された前記ストリームハンドルに基づいて前記ストリームテーブルにアクセスするステップとをさらに具備し、前記リクエストされた情報の個別部分にアクセスするステップが、アクセスされた前記ストリームテーブルエントリにおける情報を使用して実行される請求の範囲第８項に記載の方法。１０．前記情報ソースを閉じるステップと、前記情報プロバイダストリームオブジェクトを破棄するステップとをさらに具備する請求の範囲第８項に記載の方法。１１．特定のトランスポートプロトコルにインターフェースを提供するための少なくとも１つのトランスポータコンテキスト、および、情報のためのリクエストを認証するための少なくとも１つのオーセンティケータコンテキストを初期化し、メモリにロードするステップと、トランスポータファクトリオブジェクトを生成するステップと、前記トランスポータファクトリオブジェクトを呼び出すステップと、トランスポータストリームオブジェクトを生成するステップと、前記情報のためのリクエストに応じて前記トランスポータストリームオブジェクトを呼び出すステップと、前記情報のためのリクエストを読み出すステップと、前記情報のためのリクエストに関するデータを前記アダプタファクトリオブジェクトに戻すステップとをさらに具備する請求の範囲第４項に記載の方法。１２．前記リクエストされた情報の個別部分を前記リクエスタに戻すステップが、前記リクエストされた情報の個別部分を前記トランスポータオブジェクトに書き込むステップと、前記データを前記リクエスタに書き込むステップと、前記情報プロバイダストリームオブジェクトを破棄するステップと、前記アダプタストリームオブジェクトを破棄するステップと、前記トランスポータストリームオブジェクトを破棄するステップとを含む請求の範囲第１０項に記載の方法。１３．前記リクエストされた情報の個別部分を所望のフォーマットに変換するための少なくとも１つのトランスフォーマコンポーネントを初期化し、メモリにロードするステップと、トランスフォーマファクトリオブジェクトを生成するステップと、前記トランスフォーマファクトリオブジェクトを呼び出すステップと、トランスフォーマストリームオブジェクトを生成するステップと、前記リクエストされた情報の個別部分を、前記情報プロバイダストリームオブジェクトから前記トランスフォーマストリームオブジェクトにストリームするステップと、前記リクエストされた情報の個別部分を所望のフォーマットに変換するステップとをさらに具備する請求の範囲第４項に記載の方法。１４．コンピュータのメモリに格納されたコンポーネントから前記と同一のコンピュータまたは他のコンピュータに格納された他のコンポーネントに対して、情報を伝送するためのオブジェクト指向型方法であって、リクエスタからの情報リクエストを受け取るための少なくとも１つのアダプタコンポーネント、リクエストされた前記情報を提供するための少なくとも１つの情報プロバイダコンポーネント、前記少なくとも１つの情報コンポーネントのうちの１つを選択するための少なくとも１つのトレーダコンポーネント、および、前記少なくとも１つのトレーダコンポーネントのうちの１つを選択するための少なくとも１つのナビゲータコンポーネントを初期化し、これらをメモリにロードするステップと、前記少なくとも１つの情報プロバイダコンポーネントを前記トレーダコンポーネントに登録するステップと、前記少なくとも１つのトレーダコンポーネントのためのトレーダオブジェクトを生成するステップと、前記少なくとも１つのアダプタコンポーネントのためのファクトリオブジェクトを生成するステップと、前記アダプタファクトリオブジェクトを呼び出すステップと、前記アダプタファクトリオブジェクトから、前記リクエストのためのアダプタストリームを生成するステップと、前記少なくとも１つの情報コンポーネントごとのファクトリオブジェクトを生成するステップと、前記トレーダオブジェクトにおいて、ロードバランス用のアルゴリズムを使用して情報プロバイダファクトリオブジェクトを選択するステップと、選択された前記情報プロバイダファクトリオブジェクトを呼び出すステップと、前記選択された情報プロバイダファクトリオブジェクトから、情報プロバイダストリームオブジェクトを生成するステップと、前記アダプタストリームおよび前記選択された情報プロバイダストリームオブジェクトを使用して、前記情報プロバイダコンポーネントから前記アダプタコンポーネントへの前記トレーダコンポーネントに、前記リクエストされた情報をストリームするステップとを具備する方法。１５．前記情報プロバイダコンポーネントから前記アダプタコンポーネントに情報をストリームするステップが、前記リクエストされた情報の個別部分を得るために、前記情報プロバイダストリームオブジェクトを呼び出すステップと、前記情報プロバイダストリームオブジェクトにより、前記リクエストされた情報の個別部分にアクセスするステップと、前記リクエストされた情報の個別部分を戻すステップと、前記アダプタストリームオブジェクトを呼び出し、該アダプタストリームオブジェクトに前記リクエストされた情報の個別部分を書き込むステップと、前記リクエストされた情報の個別部分を前記リクエスタに戻すステップとをさらに具備する請求の範囲第１３項に記載の方法。１６．前記情報プロバイダストリームオブジェクトから前記リクエストされた情報の他の個別部分が利用可能か否かを示すステップをさらに具備する請求の範囲第１４項に記載の方法。１７．前記情報プロバイダファクトリオブジェクトから情報プロバイダストリームオブジェクトを生成するステップが、前記情報プロバイダファクトリオブジェクトに対する呼出しに含まれる情報を使用して、情報ソースを選択するステップと、メモリに格納されたストリームテーブルから新たなストリームのためのエントリを選択するステップと、前記ストリームのためのハンドルを生成するステップと、前記ストリームに関するストリームコンテキスト情報を前記ストリームテーブルエントリに書き込むステップと、前記情報プロバイダストリームオブジェクトを生成するステップと、前記情報プロバイダファクトリオブジェクトのコーラに対して、情報ストリームオブジェクト参照および前記ハンドルを戻すステップとをさらに具備する請求の範囲第１５項に記載の方法。１８．１つのコンピュータまたは複数のコンピュータのメモリ内の１つのコンポーネントから他のコンポーネントに対して、リクエストされた情報を伝送するためのコンピュータソフトウエア情報伝送システムであって、少なくとも１つの情報プロバイダコンポーネントと、リクエストによって、前記少なくとも１つの情報プロバイダコンポーネントに対して情報をリクエストする少なくとも１つのアダプタコンポーネントと、前記情報プロバイダコンポーネントから前記アダプタコンポーネントに対して、前記リクエストされた情報を個別的に送るためのオブジェクト指向型手段とを具備した情報伝送システム。１９．前記オブジェクト指向型手段が、前記少なくとも１つの情報プロバイダコンポーネントおよび前記少なくとも１つのアダプタコンポーネントによって実行されるファクトリインターフェイスと、前記少なくとも１つの情報プロバイダコンポーネントおよび前記少なくとも１つのアダプタコンポーネントによって実行されるストリームオブジェクトインターフェイスとを含み、ファクトリオブジェクトに対する呼出しがストリームオブジェクトを生成し、ストリームオブジェクトに対する呼出しが前記リクエストされた情報の個別部分を送り、または、取り出す請求の範囲第１７項に記載の情報伝送システム。２０．前記少なくとも１つの情報プロバイダが、複数のローカルファイルのために機能するファイルサーバを含む請求の範囲第１８項に記載の情報伝送システム。２１．前記少なくとも１つの情報プロバイダが、遠隔のホストから前記リクエストされた情報を取り出すための手段を含む請求の範囲第１８項に記載の情報伝送システム。２２．構成設定情報に基づいて、前記少なくとも１つの情報プロバイダのうちの１つを選択するための少なくとも１つのナビゲータコンポーネントを含む請求の範囲第１７項に記載の情報伝送システム。２３．ロードバランス用のアルゴリズムに基づいて、前記少なくとも１つの情報プロバイダのうちの１つを選択するための少なくとも１つのトレーダコンポーネントと、構成設定情報に基づいて、前記トレーダコンポーネントのうちの少なくとも１つを選択するための少なくとも１つのナビゲータコンポーネントとをさらに具備した請求の範囲第１７項に記載の情報伝送システム。