JP3023225B2 - ソフトウエア間通信のためのデータ交換装置 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、同一または異なるコ
ンピュータにおいて動作している複数のソフトウエア間
における自由度の高い(decoupled)情報交換に関するも
のである。ここでは、各ソフトウエアにおいて、異なる
データ表現のフォーマットや異なる編成(organization)
を使用できるようにし、また、データ表現や編成が同じ
であるが、再プログラムをすることなく変更されるよう
なフォーマットや編成を使用できるようにしている。こ
の発明において、ソフトウエアは、次のような方法で、
「意味」(semantic)情報やフィールド名情報を使用す
る。すなわち、各ソフトウエアは、意味やフィールド名
の違いがあっても、外部の(foreign)ソフトウエアから
受け取ったデータを、理解し使用することができる。意
味情報は、データ表現やデータ編成情報から切り離され
ている。

【０００２】

【従来の技術および発明が解決しようとする課題】形式
の異なるコンピュータやソフトウエア・プログラムが氾
濫しているという事および、異なる形式のソフトウエア
が動作する異なる形式のコンピュータにおいては常にデ
ータ交換が必要であるという事から、上記のようなデー
タ交換を可能にするシステムが望まれてきた。一般的に
は、互いに外部にあるソフトウエアモジュール間におい
て交換されるデータは、テキスト、データ、グラフィッ
クスを含んでいる。また、デジタル化した音声やイメー
ジデータ、さらには、もっと特殊な形態の情報を交換し
なければならない場合もある。このようなデータの種々
の形式は、「プリミティブ(primitives)」と呼ばれてい
る。ソフトウエアプログラムは、理解し取扱うようにプ
ログラムされたプリミティブしか扱うことができないの
である。異なる形式のプリミティブがデータとしてプロ
グラムに与えられた場合には、エラーを生じてしまう。

【０００３】ここで、「外部(foreign)」という用語
は、データ交換に関係するソフトウエアモジュールもし
くはホストコンピュータが「異なる言語を話す」という
ことを意味するものである。例えば、パーソナルコンピ
ュータやワークステーションに広く用いられているモト
ローラやインテルのマイクロプロセッサでは、次のよう
に異なるデータ表現を用いている。すなわち、あるマイ
クロプロセッサ・ファミリにおいては、複数ワードの最
上位バイトが最初に位置しているのに対し、他のファミ
リにおいては、最上位バイトが最後に位置している。さ
らに、ＩＢＭ製のコンピュータにおいてはテキスト文字
がＥＢＣＤＩＣコードに変換されるのに対し、これ以外
のほとんどのコンピュータにおいては、テキスト文字は
アスキー(ASCII)コードに変換される。また、整数、不
動小数点等を有する数を表現するために、多くの方法が
存在している。加えて、外部のソフトウエアモジュール
は、異なる方法を用いてデータを編成するとともに、異
なる意味情報、すなわちデータレコード中の各フィール
ドの名称とそれが意味するもの、を用いている。

【０００４】データの表現、編成のため、上記のような
種々のフォーマットが用いられている。このため、有効
な通信を行うには、その前に、共通言語への翻訳をする
か、あるいは、あるコンピュータや処理で使用されてい
る言語を、他のコンピュータや処理に用いられている言
語に翻訳をする必要がある。さらに、ローカルエリア・
ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡ
Ｎ）、ゲートウエイ、衛生通信等によって接続され、物
理的には離れているコンピュータ間において、相互に通
信を行うソフトウエアも多く存在する。これら種々のネ
ットワークは、それぞれ独自の通信プロトコルを有して
いる。また、少なくとも経済サービスの世界において
は、ダウ・ジョーンズ・ニュース(Dow Jones News)やテ
レレート（商標）(Telerate^TM)等の生データソースが、
異なるデータフォーマット、通信プロトコルを使用して
いる。これらのソースのデータを受信するためには、そ
れぞれのデータフォーマット、通信プロトコルを理解し
て、それに従わなければならない。

【０００５】株式、債券、金融市況等に関する経済デー
タ等の複雑なデータ構造においては、データをネスティ
ング(nesting)構造にすることが有効な場合が多い。す
なわち、特定の主題に関するデータを、当該主題を種々
の角度から表わした多数の「フィールド」に分けたデー
タレコードに編成する場合が多い。フィールドにサブ・
フィールドを持たせ、このサブ・フィールドにさらにサ
ブ・フィールドを持たせるというように、必要に応じて
レベル化することも有効である。ここでは、このような
データ編成の形を、「ネスティング(nesting)」と呼
ぶ。フィールド名および主題との関連においてフィール
ド名が意味しているものを、「意味情報」と呼ぶ。フィ
ールドにおける浮動小数点、整数、英数字(alphanumeri
c)等の実際のデータ編成、およびどれだけのフィールド
によってデータレコードが構成されているかという意味
での編成を、「フォーマット」情報もしくは「型(Typ
e)」情報と呼ぶ。データのみを持つ（ネスティングされ
たサブ・フィールドを持たない）フィールドを「プリミ
ティブ・フィールド」と呼び、他のフィールドを持つフ
ィールドを「構造化フィールド」と呼ぶ。

【０００６】ソフトウエア間でのデータ交換において
は、基本的な２つのタイプがある。１つは、「フォーマ
ット・オペレーション」と呼ばれるものであり、データ
レコード（以後、データレコードのことを「フォーム」
と呼ぶ場合もある）のフォーマットを他のフォーマット
に変換するものである。このようなフォーマットオペレ
ーションとしては、例えば、浮動小数点やEBCDICフィー
ルドを有するデータレコードを、イーサネット（商標）
(ETHERNET^TM)のＬＡＮを介して伝送するために、パック
形式に変換する場合である。受信側における処理、ソフ
トウエアにおいては、イーサネット（商標）のパケット
フォーマットから、整数、ASCIIフィールドへの変換を
行うフォーマット・オペレーションを行わねばならない
場合も生じる。

【０００７】２つめのタイプのオペレーションを、「意
味依存オペレーション」と呼ぶ。なぜなら、あるフォー
ムを持つフィールド、例えば、今日のＩＢＭの株価や昨
日のＩＢＭ株価の安値を、ソフトウエアに与えるような
場合には、作業を行うフォームに関する型情報もしくは
フォーマット情報だけでなく、意味情報にアクセスする
ことが必要だからである。

【０００８】さらに今日では、データの型が異なる種々
のソース、あるいはデータの型が同じである種々のソー
スが存在しており、そのカバー範囲はオーバーラップし
ているにもかかわらず、異なるフォーマット、異なる通
信プロトコルを使用している（同じフォーマット、同じ
通信プロトコルにてオーバラップする場合もある）。情
報を供給するサービスのネットワーク・アドレスやその
情報ソースとの通信に必要な通信プロトコルの詳細をソ
フトウエアが知らなくとも、主題に関する情報を得るこ
とができれば、有用である（ソフトウエアのことを、以
後、「アプリケーション」と呼ぶことがある）。

【０００９】そこで、種々のソフトウエア、コンピュー
タを「切り離し(decoupling)」してデータ交換を有効に
かつ確実に行うため、種々のソフトウエア、プロセス、
コンピュータ間のインターフェイスを提供することので
きる通信システムの登場が望まれている。「切離す」と
いうのは、ソフトウェアモジュールプログラムが、他の
ソフトウエアと他のコンピュータがネットワーク内のど
こにあるのか、フォームとデータが外部ソフトウェアに
おいてとるフォーマットと、外部のソフトウェアモジュ
ール又は外部のコンピュータと通信するためにどの通信
プロトコルを必要とするか、又は発信元プロセスと宛先
プロセスの間の任意のネットワークを通すためにどの通
信プロトコルが用いられるかを知ることなしに、および
多数の生データソースのうちのどれが要求されているデ
ータを供給できるかを知ることなしに、ソフトウェアモ
ジュールのプログラマが他のコンピュータ又は他のソフ
トウェアプロセスから情報をアクセスできることを意味
する。更に、「切離し」は、ここで用いる用語として
は、データが一度に要求され、他に供給されうることを
意味する。また、プロセスが、外部フォーマットで作成
されたフォームの例から、希望のデータを得ることがで
きることを意味し、また、適切な意味オペレーションの
通信インターフェイスによる学習(exercise)を通じて、
取り出し処理が明らかな状態で外部フォームから要求さ
れたデータを取り出し、外部の意味データを得ることが
できることを意味する。

【００１０】種々の切離し度を持つ外部ソフトウェアモ
ジュールの間で情報の交換を行えるようにする各種のシ
ステムが従来技術に存在する。そのような種類のシステ
ムの１つが任意の電子メールソフトウェアである。この
ソフトウェアはCCITTのＸ．４０９規格を含めた電子文
書交換規格を実現するものである。電子メールソフトウ
ェアは、フォーマットデータまたは型データがデータレ
コードまたはフォームの各例に含まれていると言う意味
で、アプリケーションを切離すものである。しかし、意
味情報を記録または処理するための用意はされていな
い。したがって、外部データ構造中の希望のフィールド
の名称または意味を基にしてデータの取出しまたは翻訳
を行うというような意味オペレーションは不可能であ
る。意味に依存するオペレーションは、通信が成功した
とするならば、非常に重要である。更に、情報ソースの
アドレスを知ることなく、単に情報を要求するだけでよ
い、主題に基づくアドレッシングを実現できるようにす
る用意が電子メールソフトウェアには設けられていな
い。更に、電子メールソフトウェアは、通信プロトコル
が確立していないサービスまたはネットワークにアクセ
スすることができない。

【００１１】リレーショナルデータベースおよびデータ
辞書は、従来技術において、外部プロセスのデータ共有
を可能としている、ソフトウェアシステムの別の例であ
る。この種のソフトウェアの欠点は、これらのプログラ
ムが「平板的な」表、レコードおよびレコード内のフィ
ールドだけしか取り扱うことができず、レコード内にネ
スティングされたレコードを取り扱うことができないこ
とである。更に、電子メールソフトウェアにおいて述べ
た欠点は、リレーショナルデータベースソフトウェアに
も存在する。

【００１２】

【課題を解決するための手段】本発明の教示に従うこと
により、従来知られていなかった程度の切離しを行いつ
つ、外部プロセスとコンピュータをインターフェイスす
るための構造を提供する方法と装置を得ることができ
る。

【００１３】本発明の教示に基づくデータ通信インター
フェイス・ソフトウエア・システムは、２つの主コンポ
ーネント、通信コンポーネント、データ交換コンポーネ
ントに編成されたいくつかのプログラムライブラリを備
えている。本発明のこの明細書で用いるインターフェイ
スという用語は、外部プロセスと外部コンピュータの少
なくとも一方と通信を行うのに有用な作業を行うため
に、アプリケーションにより呼出すことができる機能の
集りを意味する。インターフェイスの呼出し機能は、本
発明による通信インターフェイス内の、アプリケーショ
ンからまたは他のコンポーネントからのサブルーチンコ
ールによるものとしてもよい。

【００１４】好ましい実施例においては、インターフェ
イスを有するサブルーチンライブラリ中の種々のサブル
ーチンによって、インターフェイスの機能が実行され
る。もちろん、サブルーチンの代りに別々のプログラム
またはモジュールを使用でき、この方が実際に好ましい
場合もあることは、当業者なら分かるであろう。

【００１５】データフォーマットの切り離しは、次のよ
うにして行われる。すなわち、第１のフォーマットのデ
ータレコード、データフォームを使用する第１のプロセ
スが第２のプロセスのフォーマットを知る必要なく、ま
たは使用する必要なく、異なる第２のフォーマットのデ
ータレコードを持つ第２のプロセスと通信することがで
きる。このような切離しは、通信インターフェイスソフ
トウェアシステムのデータの交換コンポーネントにより
実現される。

【００１６】本発明の通信インターフェイスのデータ交
換コンポーネントは、フォームマネージャーモジュール
とフォームクラスマネージャーモジュールを含む。フォ
ームマネージャーモジュールは、フォーム例の作成、記
憶、取消、破棄を取扱い、フォームクラスマネージャー
の各種機能を呼出すものである。フォームクラスマネー
ジャーは、フォームクラス記述子の作成、記憶、取消、
破棄および翻訳を取扱うものである。ここで、フォーム
クラス記述子とは、特定のフォームクラスに関係したフ
ォーマット情報、意味情報が記録されたデータレコード
をいう。フォームクラスマネージャーはアプリケーショ
ンからの要求、または通信インターフェイスの他ののコ
ンポーネントからの要求を受けて、フィールド名やフィ
ールドの意味によって認識された時にフォーム例の特定
フィールドを得ることもでき、適切なフォーム例を検索
することもでき、さらに特定フィールド中の要求された
データを取り出して、送ることもできる。また、フォー
ムクラスマネージャーは、フォームの未知のクラス定義
を探すことができる。これは、フォームマネージャー
が、すでに既知のクラス定義の情報を調べることによ
り、あるいは新たなフォームクラスを作成した外部プロ
セスとリンクしているフォームクラスマネージャーにク
ラス定義を要求することにより実現される。意味情報に
データ表現またはデータ編成に関する情報が含まれてい
ないという点で、フィールド名等の意味データは、デー
タ表現、データ編成から切り離される。本発明の通信イ
ンターフェイスは、意味的、データフォーマット的な観
点において、データの切り離しを行うものである。意味
的な観点における切り離しは、意味依存オペレーション
を実行する能力により実現される。この意味依存オペレ
ーションにより、この通信インターフェイスに接続され
たどのプロセスも、同じデータ編成を持つ他のプロセス
だけでなく異なったデータ編成を持つ他のプロセスとの
データ交換を行うことが可能となる。なお、上記の異な
ったデータ編成とは、同じ内容を示すデータに対し同じ
フィールド名を使用しているが、データの編成が異なる
ようなものをいう。他の実施例においては、意味依存オ
ペレーションにより、別名変換、同義語変換機能が実行
される。この機能により、受入れたデータフィールドが
異なった名称を持っているが一定の内容を示す場合に、
要求を出したプロセスが理解できるフィールド名に変え
られたり、あるいはフィールド名が変えられたものとし
て取扱われる。

【００１７】この発明によるインターフェイスは、３つ
のレイヤーに構造化プロセス構造を有する。

【００１８】構造的な切り離しは、情報レイヤーによっ
て達成される。要求を行うプロセスは、プロセスやサー
バのネットワークアドレスを知ることなしに、特定の主
題に関するデータの要求を行うことができる。この種の
切り離しは、インターフェイスの通信コンポーネントに
おける情報レイヤー内の主題に基づくアドレッシング(s
ubject-based-addressing)システムによって達成され
る。

【００１９】主題に基づくアドレッシングは、本発明の
通信インターフェイスの通信コンポーネントにより、主
題のマッピング(subject mapping)を行うことによって
実現される。通信コンポーネントは、データ要求の対象
となっている主題を記述したアプリケーションから「申
し込み(subscribe)」要求を受ける。情報レイヤー内の
主題マッパモジュール(subject-mapper module)がアプ
リケーションから「申し込み」要求を受け、その後、デ
ータベース、テーブル等の主題を検索する。データベー
スは、種々の主題についてのデータを供給する各種のサ
ーバープロセスを示す「サービスレコード」を記憶して
いる。適切なサーバプロセスを示すサービスレコードが
特定されて、主題マッパモジュールに返送される。ここ
で、適切なサービスレコードとは、要求された型のデー
タおよび特定されたサーバプロセスと通信を行う際に使
用する通信プロトコルを供給することのできるサービス
レコードをいう。

【００２０】主題マッパは、プロセス構造の第２レイヤ
ー（サービスレイヤーという）上の複数の通信ライブラ
リプログラムまたはサブルーチンにアクセスする。サー
ビスレイヤー上のルーチンは、「サービス統制(service
disciplines)」と呼ばれる。各サービス統制は、サー
バプロセスに特有の所定の通信プロトコルを有してい
る。主題マッパは、その後、サービスレコードにおいて
識別されている適切なサービス統制を呼出す。

【００２１】サービス統制には主題マッパによって主題
が与えられ、サービス統制は適切なサーバープロセスに
対する通信の設定を続ける。その後、主題に関するデー
タを含むフォーム例が、通信を設定したサービス統制を
介して、サーバプロセスにより、要求するプロセスへ送
られる。

【００２２】サービスプロトコルの切離しはサービスレ
イヤーにより行われる。

【００２３】テレレート（商標）等のページ指向サーバ
プロセスのサービス統制により、一時的な切り離しが実
現される。これは、どのページに申し込み(subscriptio
ns)がなされたかの最新情報を記憶しているリアルタイ
ムデータベースにアクセスすることによって実現され
る。

【００２４】通信コンポーネントの第３レイヤーは、通
信レイヤーと呼ばれ、組み立て(configuration)に関す
る切り離しを行う。このレイヤーは、プログラムのＤＣ
Ｃライブラリを有している。このライブラリは、特定サ
ーバとのデータリンクを確立する要求を受け、リンクの
ためのプロトコルがまだ確立していなければ、最適の通
信プロトコルを決定する。通信レイヤーは、一対一の(p
ointーtoーpoint)通信プロトコル、同時通信(broadcast)
プロトコル、信頼性の高い同時通信(reliablebroadcas
t)のプロトコル、インテリジェント・マルチキャスト
（商標）のプロトコル等の種々の通信プロトコルを有す
る通信プロトコルエンジンを備えている。通信レイヤー
の機能のうちのいくつかのものは、オペレーティング・
システムの標準的な転送プロトコルの機能を増やすもの
であり、付加価値サービスを提供するものである。

【００２５】これら付加価値サービスのうちの一つは、
信頼性の高い同時通信プロトコルである。このプロトコ
ルエンジンは、送信側のメッセージのパケットにシーケ
ンス番号を付加し、全てのパケットが受信側に受信され
たことを確認する。パケットは、再送信のために、送信
側において記憶される。受信側においては、全てのパケ
ットが受信されなかった場合や伝送エラーがあった場合
には、再送信の要求が出される。その後、エラーのあっ
たパケットや送られなかったパケットが再送信される。
全てのパケットが正しく受信された場合には、確認メッ
セージが送られる。これにより、送信側のプロトコルエ
ンジンは、再送信バッファから送信済のパケットを消去
し(flush)、次のメッセージのパケットを送るためのバ
ッファ容量を確保する。

【００２６】もう一つの付加価値サービスは、インテリ
ジェント・マルチキャスト・プロトコルである。このプ
ロトコルは、送られるべきメッセージの主題を調べ、こ
の主題に対する申し込みが幾つあったかを決定するサー
ビス統制を有している。申し込みの数が、一対一の送信
と同時送信とのコストによってセットされたしきい値よ
り小さい場合には、メッセージは一対一の送信によって
送られる。そうでない場合には、メッセージは、信頼性
の高い同時通信によって送られる。

【００２７】

【実施例】以下の記述は技術的にかなり高度であるか
ら、後に掲げる用語解説に定義したデジタルネットワー
ク通信技術において用いられている用語を理解すること
によって、より良い理解を得ることができる。この明細
書を読む者は、まず、用語解説を読むことをすすめる。

【００２８】まず、本発明の通信インターフェイスを組
み込むことができる典型的なシステムのブロック図が示
されている第１図を参照する。もっとも、本発明により
効果を得ることができるシステムアーキテクチャは、広
範囲にわたるものである。本発明に係る通信インターフ
ェイスを、以下に示す他の実施例において、ＴＩＢ（商
標）もしくはテクネクロン情報バスと呼ぶ場合がある。
ここで、本発明を説明するために用いた重要ないくつか
の用語についての基本的な理解を得るために、この明細
書に含まれている用語について説明することにする。本
発明の教示は、コンピュータプログラムのライブラリに
組込まれる。これらのプログラムは、一緒になって、通
信インターフェイスを提供する。この通信インターフェ
イスは、ネットワーク通信のプロトコルやサービス通信
のプロトコルにおけるクライエントアプリケーションの
開発や変更のモジュール化を容易にする多くの機能を有
する。これらの機能は、種々のクライエントアプリケー
ションを「切り離した」状態（この状態においては、発
明が、通信プロセス間の、仲介者、仲人であるかのよう
にふるまう）で結合することによって達成される。以
下、本発明の教示を通信インターフェイスと呼ぶことに
する。ここで用いる「切離す」という用語は、クライエ
ントアプリケーションのプログラマが、通信プロトコル
の詳細と、データ表現フォーマットの細部と、データ交
換を希望される他の全てのアプリケーションまたはサー
ビスのデータレコード編成の細部とを知る必要から解放
されることを意味する。更に、クライエントアプリケー
ションのプログラマは、特定の主題についてのデータを
得るために、それらの主題についてのデータを供給する
サービスまたはサーバの場所を知る必要はない。この通
信インターフェイスは、クライエントアプリケーショ
ン、データ消費者アプリケーション、データ供給者サー
ビスの間のデータ交換における全ての詳細事項について
自動的に注意を払う。第１図に示す装置は、ネットワー
クを介してまたは共有メモリによって、複数のホストコ
ンピュータが結合された典型的なネットワークである。
第１図には２つのクライエントアプリケーション１６、
１８が動作しているホストコンピュータ１０、１２が示
されている。他の実施例においては、これら２つのクラ
イエントアプリケーションは、同じコンピュータの上で
実行してもよい。これらのホストコンピュータは、ネッ
トワーク１４によって結合されている。ネットワークと
しては、イーサネット（商標）通信プロトコル、トーク
ンリング(token ring)プロトコル等を使用することがで
きる。データ交換のためのネットワークの説明は、本発
明の実施のためには必要でない。本発明の実施のために
は、従来技術で知られているデータ交換方法で十分だか
らである。したがって、ホストコンピュータ１０、１２
が等しくアクセスする共用メモリファイルまたは共用分
散型記憶装置も、本発明の教示が適用できる環境として
十分である。

【００２９】各ホストコンピュータ１０、１２は、ラン
ダムアクセスメモリおよび、ディスクドライブまたはテ
ープドライブ等の大容量記憶装置を有する。これらのメ
モリには、各種のオペレーティングシステムプログラ
ム、クライエントアプリケーションプログラム、一体と
なって通信インターフェイスを構成するライブラリのプ
ログラム等のプログラムが記憶される。これらのプログ
ラムは、ホストコンピュータに有用な仕事をさせるため
のものである。通信インターフェイス中のプログラムの
ライブラリは、特定の主題についてのデータを供給する
サービスの場所を見つけたり、適切な通信プロトコルを
用いてそのサービスと通信を行わせるというような動作
を行わせるために、クライエントアプリケーションによ
り呼出すことができる基本的なツールを提供する。

【００３０】各ホストコンピュータは端末装置、プリン
タ（図示せず）等のユーザーインターフェイスに結合す
ることもできる。

【００３１】第１図に示す例示的な装置において、ホス
トコンピュータ１０は、そのメモリにクライエントアプ
リケーションプログラム１６を格納している。このクラ
イエントアプリケーションプログラム１６が、有用な作
業を行うために、ホストコンピュータ１２を制御する他
のクライエントアプリケーションプログラムまたはサー
ビス１８とのデータの交換を求めていると仮定する。ま
た、ホストコンピュータ１０、１２はデータ表現のため
に異なるフォーマットを使用し、アプリケーションプロ
グラム１６、１８は、作成したデータレコードのデータ
表現、データ編成のフォーマットに異なったものを使用
すると仮定する。これらのデータレコードは、フォーム
と呼ばれる。また、ホストコンピュータ１０と１２の間
のデータ通信路１４は、イーサネット（商標）系列のＬ
ＡＮで構成されているものと仮定する。

【００３２】各ホストコンピュータ１０、１２は、それ
ぞれ、通信インターフェイス２０、２２を構成するプロ
グラムのライブラリによってもプログラムされている。
通信インターフェイスプログラムは、ランタイムコード
(run time code)を生成するために、リンカ(linker)に
よってクライエントアプリケーションのコンパイル後の
コードと結合されており、通信プログラムのソースコー
ドは、コンパイル前のクライエントアプリケーションプ
ログラムのソースコードに含まれている。いずれにして
も、通信ライブラリプログラムは、なんらかの形でクラ
イエントアプリケーションと結合される。したがって、
ホストコンピュータ１０が２つのクライエントアプリケ
ーションによって動作しているとすると、各クライエン
トアプリケーションは、モジュール２０等の通信インタ
ーフェイスモジュールに結合される。

【００３３】通信インターフェイスモジュール２０の目
的は、アプリケーション１８において用いられているフ
ォームのデータ編成、データフォーマットの詳細から、
アプリケーション１６を切り離すことである。また、ア
プリケーション１８のネットワークアドレスからアプリ
ケーション１６を切り離すことである。さらに、アプリ
ケーション１８によって用いられている通信プロトコル
の詳細からアプリケーション１６を切り離すことであ
る。同様に、ネットワーク１４を介して、データを送る
ために必要な通信プロトコル、データ編成、データフォ
ーマットの詳細からアプリケーション１６を切り離すこ
とである。通信インターフェイスモジュール２２は、ア
プリケーション１８に対して上記と同じ機能を発揮する
ものである。これにより、アプリケーション１６とネッ
トワーク１４についての詳細を知る必要から解放するも
のである。通信インターフェイスモジュールは、変更の
モジュール化を容易にするものである。これにより、ク
ライエントアプリケーション、データフォーマットまた
はデータ編成、ホストコンピュータあるいはネットワー
クの変更を行った場合に、この変更の影響をシステム全
体に波及させずに互換性を維持できるようにしている。

【００３４】これらの機能のいくつかを実現するため
に、通信インターフェイス２０と２２は、ネットワーク
１４を介して、主題テーブル２６とサービステーブル２
８を含むネットワークファイルシステム２４にアクセス
する。これらの表（テーブル）については、後で主題に
基づく（主題の主動的）アドレッシングの説明に関連し
て詳しく説明する。これらのテーブルには、各種の主題
についての情報を提供するサービスのネットワークアド
レスがリストアップされている。

【００３５】この通信インターフェイスを用いる典型的
なシステムモデルは、ユーザと、ユーザー群と、ネット
ワークと、サービスと、サービス例(service instance
s)（またはサーバ）と、主題とで構成される。人間であ
る末端ユーザは、ユーザーＩＤにより識別される。この
通信インターフェイスにおいて用いられるユーザーＩＤ
は、通常、基礎を成しているオペレーティングシステム
（図示せず）により用いられるログオンＩＤ、ユーザＩ
Ｄと同じである。しかし、そのようでなくともよい。各
ユーザーは、１つのグループの一構成員である。

【００３６】グループは、類似したサービスアクセスパ
ターンおよびアクセス権を有するユーザーで構成され
る。サービスまたはシステムに対するアクセス権は、ユ
ーザーのレベルおよびグループのレベルにより許可する
ことができる。システム管理者は、ユーザーをグループ
に割り振りする責任がある。

【００３７】ここで用いる「ネットワーク」という用語
は下側の「トランスポート層」（この用語はＩＳＯネッ
トワーク層モデルに用いられるから）と、ＩＳＯネット
ワークモデルにおけるトランスポート層より下層にある
全ての層を意味する。アプリケーションは、ホストコン
ピュータが接続されている任意のネットワークを介し
て、データを送信または受信できる。

【００３８】第１図においてブロック２０と２２として
一例を示した本発明の通信インターフェイスは、各クラ
イエントアプリケーションのために、通信コンポーネン
ト３０とデータ交換コンポーネント３２を含んでいる。
通信コンポーネント３０は、共通の通信機能セットであ
って、たとえば、主題に基づくアドレッシングとサービ
ス統制の切離しの少なくとも一方を実現する。通信コン
ポーネントは、各クライエントアプリケーションに結合
される。また、各通信コンポーネントは、結合されるネ
ットワークの標準的なトランスポート層プロトコル、例
えばＴＣＰ／ＩＰに結合される。各通信コンポーネント
は、多数のトランスポート層プロトコルに結合され、各
プロトコルを支持できる。ネットワークのトランスポー
ト層は次のことを実行する。それは、トランスポート層
アドレスをネットワークアドレスにマップし、トランス
ポート層接続をネットワーク接続へ多重化してスループ
ットを増大させ、誤り検出とサービス品質の監視を行
い、誤りを訂正し、セグメント化とブロック化を行い、
ネットワークへのトランスポート層とセッション層との
個々の接続の流れ制御と、迅速なデータ転送を行う。通
信コンポーネントは、クライエントアプリケーションの
ために確実な通信を行うとともに、クライエントアプリ
ケーションに対して場所の明瞭性とネットワークの独立
性を提供する。コンポーネント３２を典型とする通信イ
ンターフェイスのデータ交換コンポーネントは、データ
表現、データ転送の強力な方法を実現する。これは、フ
ォームと呼ばれる自己記述データオブジェクト内にデー
タを包含させることにより実現される。これらのフォー
ムは、対象とするデータばかりでなく、フォームの編成
やデータのために用いられる表現を記述する型情報やフ
ォーマット情報を含むという点において自己記述的であ
る。フォームはこのような型情報やフォーマット情報を
含んでいるので、あるフォーマットを有する特定のフォ
ームを別のフォーマットへ変換するためのフォーマット
オペレーションは、フォーム自身のデータを用いて行う
ことが可能である。この時、意味情報を与えるクラス記
述やクラス定義と呼ばれる他のデータにアクセスする必
要はない。クラス記述子における意味情報は、基本的
に、フォームのフィールド名を意味する。

【００３９】フォームそれ自体のデータだけでフォーマ
ットオペレーションを行う能力は、きわめて重要な能力
である。なぜなら、例えばクラス記述子のような他の場
所に設けられている他のデータオブジェクトにアクセス
しなければフォーマットオペレーションが行えないよう
な場合に生じる動作の遅延を防ぐことができるからであ
る。一般にクライエントアプリケーションのための処理
時間の２５〜５０％がフォーマットオペレーションに費
やされているので、自己記述オブジェクトを使用してこ
の処理時間を速くすることにより、処理が能率化され
る。

【００４０】データ交換コンポーネントにより管理され
る自己記述フォームは、データ取扱いおよびデータ表示
のための全般的なツールの実現も許す。それらのツール
は、フォームをマシンとは独立のフォーマットで、プロ
セスの間を送るための通信ツールを含んでいる。更に、
自己記述フォームを用いるクライエントアプリケーショ
ンに悪影響を及ぼすことなしに、自己記述フォームを拡
張できる、すなわち、それらのフォームの編成を変化し
たり、拡張したりできるので、それらのフォームはモジ
ュール化アプリケーションの開発を非常に容易にする。

【００４１】通信インターフェイスの最も下の層はＩＳ
Ｏモデルのトランスポート層に結合され、かつ、通信コ
ンポーネント３０は、多くのサービス統制を含み、多く
のネットワークを支持するために多くのトランスポート
層プロトコルを含んでいるので、ネットワーク不良の場
合には、あるネットワークから他のネットワークへ明示
的に切り換えるようなアプリケーション指向のプロトコ
ルを書くことができる。

【００４２】「サービス」とは、クライエントアプリケ
ーションによって使用するために、アプリケーションに
より送り出される機能の有意セットを表わすものであ
る。サービスの例えはダウ・ジョーンズ・ニュース(Dow
JonesNews)、クォートロン(Quotron)データ源、トレー
ド・チケット・ルーター(Trade Ticket ruoter)のよう
な歴史的ニュース検索サービスである。一般的には、ア
プリケーションはただ１つのサービスを送り出すが、多
くの異なるサービスの送り出しも可能である。

【００４３】「サービス例」は与えたれたサービスの供
給を可能とするアプリケーションまたはプロセスであ
る。ある与えられたサービスに対して、いくつかの
「例」は、サービスのスループットを改善するようにま
たは耐障害性を持たせるために、サービスを同時に行う
ことができる。

【００４４】ネットワーク、サービスおよびサーバーは
従来技術で知られている伝統的な構成要素であるが、従
来技術によるシステムは、ネスティングされたデータオ
ブジェクトによるデータの独立性や主題スペースの概念
に対する認識をもつに至っていなかった。主題スペース
は、主題に基づくアドレッシングと呼ばれる切離しの１
つの型を支持している。多数のレベルにおいてネスティ
ングできる自己記述データは新しいものである。ネット
ワークの他の部分において行われているように、クライ
エントアプリケーションを種々の通信プロトコルおよび
データフォーマットから切離すことも非常に有用であ
る。

【００４５】主題に基づくアドレッシングを実現するた
めに用いられる主題スペースは、主題カテゴリーの階層
的なセットで構成される。好適な実施例においては、４
レベル主題スペース階層を用いた。典型的な主題の例
は、「株、ｉｂｍ、コンポジット、トレード」である。
通信インターフェイスに結合されたクライエントアプリ
ケーションは、種々の主題カテゴリーの使用と解釈に関
する規約を確立する自由と責任を有する。

【００４６】各主題は、一般に、システムファイルに記
憶されたデータレコード中の主題についてのデータを供
給する１以上のサービスと関連付けられている。各サー
ビスには、通信インターフェイスの通信コンポーネント
において、サービス統制、すなわち、そのサービスと通
信するために必要な通信プロトコルや通信手順が組合わ
されているので、クライエントアプリケーションは、そ
の主題についてのデータを供給するサービス例がどこに
あるのかを知ることなく、特定の主題に関するデータを
要求することができる。また、その主題の情報を提供す
るサービスのネットワークアドレスを与えずに、主題の
みを与える申し込み要求を行うことによって、ネットワ
ーク上の主題の位置が分る。これらの申し込み要求は、
通信インターフェイスにより、その主題の情報を供給す
る１以上のサービス例との実際の通信接続に翻訳され
る。

【００４７】主題カテゴリーのセットは、主題領域(sub
ject domain)と呼ばれる。多数の主題領域が許される。
各領域は、領域特有の主題と、メッセージヘッダにおい
て主題を効率的に表わすコーディング機能とを定めるこ
とができる。

【００４８】

【データの独立性：データ交換コンポーネント】第１図
の通信インターフェイスのコンポーネント３２のような
データ交換コンポーネントの全体的な目的は、アプリケ
ーション１６のようなクライエントアプリケーションを
データ表現と、データ構成と、データの意味の細部から
切離すことである。

【００４９】図２において、フォーマット情報と意味情
報の双方を定義する構造化クラスのクラス定義の一例が
示されている。これは、このクラスの全てのフォーム例
に共通のものである。選択した特定の例においては、フ
ォーラムクラスはプレイヤー名と名づけられ、クラスＩ
Ｄ１０００を有する。このクラス１０００のフォームの
例は、名前と、年齢と、テニス競技者に対するＮＴＲＰ
評点とについてのデータを含んでいる。あらゆるクラス
定義には、クラスを独自に識別するクラスＩＤと呼ばれ
るクラス番号が組合される。

【００５０】クラス定義は、フィールドのリストを、フ
ィールド内容のデータ表現と名前により与える。各フィ
ールドはフォームを含み、各フォームは原始(primitiv
e)または構造化されたものとすることができる。原始ク
ラスフォームは実際のデータを記憶しているが、構造化
クラスフォームは、原始または構造化された他のフォー
ムを含むフィールドを有する。図２のクラス定義におい
ては、評点、年齢、姓、名と名づけられる４つのフィー
ルドがある。各フィールドは原始クラスフォームを含む
から、このクラスのフォームにおける各フィールドは実
際のデータを含む。例えば、フィールド評点はクラス１
１の原始フォームを常に含む。クラス１１は浮動小数点
と名づけられる原始クラスである。浮動小数点は、この
フィールドの内容が浮動小数点のデータ表現であること
を定めている。クラス浮動小数点、クラス１１のための
原始クラス定義が図５に見られる。原始クラス１１のク
ラス定義は、浮動小数点というクラス名を有している。
このクラス名は、クラス（この例では、クラス番号のク
ラス１１もクラスを独自に識別する）と、１つのデータ
値のデータ表現の詳細を独自に識別する。１つのデータ
値の詳細は、周知の予め定められたシステムのデータ型
を用いる。このデータ型は、ホストコンピュータと、こ
のクラスのフォームを取扱うアプリケーションの双方に
理解される。

【００５１】実際のデータ値のデータ表現に対する典型
的な詳細は整数、浮動小数点、ASCII文字列、またはEBC
DIC文字列等である。原始クラス１１の場合には、デー
タ値の詳細は、浮動小数点１／１である。これは、この
原始クラスのフォーム例に記憶されているデータが、合
計２桁の浮動小数点であって、そのうちの１桁が小数点
の右側になることを示す表記法である。

【００５２】次に、図２のプレイヤー名クラス定義につ
いての考察に戻ることにする。第２のフィールドは年齢
と名づけられる。このフィールドは、クラスナンバー１
２を持ち、図５において定義された整数と名づけられた
原始クラスのフォームを含む。それにはクラス番号が組
合され、第５図において定義されている。フォームの整
数クラス、クラス１２は、図５のクラス定義ごとに、整
数３の詳細を示すデータを有する。整数３は、３個の数
字を有する整数データをフィールドが含むことを意味す
る。第２図におけるクラス１０００の最後の２つのフィ
ールドは、姓と名である。これら両方のフィールドは、
ストリング ２０ ＡＳＣＩＩ クラス１０と名づけら
れているクラスの原始フォームを含む。クラス１０のク
ラス定義が第５図に与えられており、このクラスのフォ
ームの例が２０文字の長さであるASCII文字列を含むこ
とを指定している。

【００５３】第３図に、プレイヤー住所、クラス１００
１と名づけられた他の構造化クラス定義を示す。このク
ラスのフォームの各例は、ストリート、市および州と名
づけられた３つのフィールドを含む。これら３つの各フ
ィールドは、ストリング ２０ ＡＳＣＩＩ、クラス１
０、と名づけられているクラスの原始フォームを含む。
また、クラス１０に対するクラス定義が第５図に与えら
れ、２０文字のＡＳＣＩＩストリングのデータ表現を指
定する。

【００５４】構造化クラスフォームのネスティングの例
が、図４に示されている。図４は、トーナメントエント
リィ、クラス１００２、と名づけられているクラスにお
けるフォーム例についてのクラス定義である。このクラ
スにおけるフォームの各例は、トーナメント名、プレイ
ヤー、アドレスと名づけられた３つのフィールドを含
む。トーナメント名フィールドは、第５図に定義されて
いるストリング ２０ＡＳＣＩＩ、クラス１０、と名づ
けられている原始クラスのフォームを含む。プレイヤー
と名づけられているフィールドは、第２図に示されてい
るフォーマットと意味特徴を有するプレイヤー名、クラ
ス１０００、と名づけられているクラスの構造化フォー
ムの例を含む。アドレスと名づけられているフィールド
は、プレイヤーアドレス、クラス１００１、と名づけら
れている構造化クラスの構造化フォームの例を含む。プ
レイヤーアドレスは、第３図のクラス定義において与え
られているフォーマットと意味特徴を有する。

【００５５】図４のクラス定義は、フォームのネスティ
ングをどのようにして行うことができるかを示すもので
あって、フォームの各フィールドはフォーム自体であ
り、あらゆるフォームは、原始としてただ１つのフィー
ルドを有することも可能であり、構造化して複数のフィ
ールドを有することも可能である。言いかえると、フォ
ーム例は、必要な数のフィールドを有することができ、
各フィールドは必要な数のサブフィールドを有すること
ができる。更に、各サブフィールドは、必要な数のサブ
−サブフィールドを有することができる。このネスティ
ング構造は、任意の数のレベルにわたって進められる。
このようなデータの構造により、種々の複雑さを持つデ
ータを、容易に表現し、かつ取扱うことができるように
なる。

【００５６】次に、トーナメントエントリィ、クラス１
００２、として名づけられたフォームクラスのフォーム
例を、図６に示す。このフォーム例は、オブジェクトと
してメモリに記憶されている。データブロック３８は、
これがトーナメントエントリィと名づけられている構造
化クラスのフォームの例であることを示す構造化クラス
番号１００２を含む。データブロック４０は、このクラ
スのフォームが３つのフィールドを有することを示す。
これら３つのフィールドは、それらのフィールド内のフ
ォームのクラス番号を含んでいる、４２、４４、４６で
示されているデータブロックを有する。第１のフィール
ドが図５に示されているようなクラス１０のフォームを
含むことを、データブロック４２は示す。クラス１０フ
ォームは、図５においてクラス１０に対するクラス定義
で定義されているASCII文字の２０文字列を含んだ原始
フォームである。このフォームの例におけるASCII文字
の実際の列が４８で示され、これはＵ．Ｓ．オープンテ
ニストーナメントに対するトーナメントエントリィであ
ることを示している。データブロック４４は、第２のフ
ィールドが、クラス１０００の構造化フォームの例であ
るフォームを含んでいることを示している。このクラス
定義を参照することにより、このクラスがプレイヤー名
と名づけられていることが示される。データブロック５
０は、このクラスの構造化フォームが４つのサブフィー
ルドを含むことを示す。これらのフィールドは、データ
ブロック５２、５４、５６、５８に記録されているクラ
スのフォームを含む。これらのフィールドは、フィール
ド４４のサブフィールドである。第１のサブフィールド
は、データブロック５２を有しており、このサブフィー
ルドが原始クラス１１のフォームを含むことを示す。こ
のクラスのフォームは、図５において、１つの小数点を
有する浮動小数点の２桁の数を含んでいるものとして示
されている。このフォーム例に対する実際のデータが６
０で示され、このプレイヤーのエントリィ評点が３．５
であることが示されている。第２のサブフィールドはデ
ータブロック５４を有し、このサブフィールドは原始ク
ラス１２のフォームであることを示す。このクラスのク
ラス定義は、このクラスが整数と名付けられ、整数デー
タを含むことを示している。図２に示されるクラス１０
００のクラス定義は、ブロック６２で示されるこの整数
データがプレイヤーの年齢であることを示している。フ
ィールド名についてのクラス定義意味データは、フォー
ム例には格納されていないことに注目されたい。フォー
マット情報または型情報だけが、各フィールドのクラス
ＩＤのフォーム中のフォーム例に格納される。

【００５７】第３のサブフィールドは、データブロック
５６を有し、このサブフィールドがストリング ２０
ＡＳＣＩＩと名付けられた原始クラス１０のフォームを
含むことを示している。このサブフィールドは、図２に
示されている、クラスプレイヤー名、クラス１０００、
のフォームの姓フィールドに対応している。原始クラス
１０クラス定義は、この原始クラスの例が２０文字のAS
CIIストリングを含むことを指定する。このストリング
は、この例の場合には、プレイヤーの姓を定めている。
図６に示す例においては、プレイヤーの姓は６４に示す
ようにブラケット(Blacklet)である。

【００５８】最後のサブフィールドは、データブロック
５８を有し、２０文字のASCIIストリングである原始ク
ラス１０の原始フォームをこのフィールドが含んでいる
ことを示している。このサブフィールドは、プレイヤー
の名を含んでいるものとして、クラス１０００にクラス
定義される。このASCIIストリングが６６として示され
ている。

【００５９】クラス１００２のフォーム例における第３
のフィールドは、データブロック４６を有する。このデ
ータブロックは、このフィールドが構造化クラス１００
１の構造化フォームを含むことを示す。このクラスのク
ラス定義は第３図に与えられており、このクラスがプレ
イヤー アドレスと名付けられていることを示してい
る。データブロック６８は、このフィールドが、７０、
７２、７４で示されるクラス番号のフォームを含む３つ
のサブフィールドを有しすることを示している。これら
の各サブフィールドは、図５において定義されている原
始クラス１０のフォームを含む。したがって、これらの
各サブフィールドは、２０文字のASCIIストリングを含
む。これら３つのフィールドの内容は、クラス１００１
についてのクラス定義において定義され、それぞれ、フ
ィールド４４において名づけられたプレイヤーのアドレ
スに対するストリート、市および州である。これらの３
文字ストリングが、それぞれ７６、７６、８０で示され
ている。

【００６０】図７には、このクラスのフォーム例とクラ
ス定義との間における、意味情報、フォーマット情報、
実データの区分が示されている。フィールド名と、フォ
ーマット情報、型情報とは、ボックス８２に示されてい
るようにクラス定義中に格納される。フォーマット情報
や型情報（クラスＩＤのフォームにおいて）と、実際の
データまたはフィールド値は、ボックス８４に示すよう
に、フォーム例に格納される。たとえば、図６に示され
ているトーナメントエントリー、クラス１００２のフォ
ーム例において、第１フィールドの実データは、ブロッ
ク４８で示されるものであるにもかかわらず、第１フィ
ールドのフォーマットデータはブロック４２に記憶され
たデータとなっている。本質的には、クラス番号やクラ
スＩＤは、通信インターフェイスにより、その原始クラ
スのフォーム例におけるデータの種類に対する仕様に等
しくされる。したがって、通信インターフェイスは、ク
ラス定義をアクセスする必要なしに、フォーム自体の例
に格納されているフォーマットデータだけを用いて特定
のフォーム例に対してフォーマットオペレーションを実
行できる。これにより、処理速度の低下をもたらすディ
スクアクセス、ネットワークアクセスを含むクラス定義
へのアクセスの必要性が無くなり、フォーマットオペレ
ーションの速度が向上する。フォーマット型オペレーシ
ョンは、外部プロセス内のデータ交換における全ての動
作の集りを有するから、データ構造と、ここで定義され
ているデータ構造を取扱うためのプログラムのライブラ
リィとは、外部プロセスと外部コンピュータの間のデー
タ交換の効率を大幅に向上させる。

【００６１】たとえば、第６図に示されているフォーム
例がデジタル・イクイップメント・コーポレーション(D
igital Eguipment Corporration)（DEC)製のコンピュー
タで実行されるプロセスによって発生され、したがって
テキストがASCII文字で表わされるものと仮定する。ま
たこのフォームは、アイビーエム(IBM)コンピュータで
実行されているプロセスへ送るべきものであると仮定す
る。アイビーエムコンピュータでは、文字ストリングは
EBCDICコードで表わされる。更に、それら２台のコンピ
ュータがイーサネット通信プロトコルを用いてローカル
エリアネットワークにより結合されているものと仮定す
る。

【００６２】この転送を行うために、いくつかのフォー
マットオペレーションを行わねばならない。これらフォ
ーマットオペレーションは、ＤＥＣコンピュータが１０
で示されているホスト１で、アイビーエムコンピュータ
が１２で示されているホスト２であると仮定して、第１
図を参照することにより最もよく理解できる。

【００６３】第６図に示すフォーム例をアプリケーショ
ン１６からアプリケーション１８へ転送するための第１
のフォーマットオペレーションは、第６図に示されてい
るフォーマットから、ネットワーク１４を介する転送に
適当なパックされたフォーマットへの交換である。ネッ
トワークは、一般に、端と端を一緒にしてパックされた
複数のバイトと、それらのバイトに先行するヘッダ情報
の多数のバイトとを含むデータブロックで構成されたメ
ッセージに対して作動する。このヘッダ情報は、メッセ
ージの長さ、宛先アドレス、発信元アドレス等のような
ものと、メッセージの終りに附された誤り訂正コードと
を含む。実際のデータブロックの始りと終りをマークす
るためにデリミタが用いられる場合もある。

【００６４】この仮定した転送において実行せねばなら
ないであろう第２のフォーマット動作は、ネットワーク
１４を介して転送するために必要なパックされたフォー
マットから、アプリケーション１８とホストコンピュー
タ１２により用いられるフォーマットへの変換である。

【００６５】フォーマットオペレーションは通信インタ
ーフェイスのフォームマネージャーモジュールによって
行われる。例えば、仮定的な転送における最初のフォー
マットオペレーションは、第１図のフォームマネジャー
モジュール８６により行われ、一方、仮定的な転送にお
ける第２のフォーマットオペレーションはデータ交換コ
ンポーネント８８におけるフォームマネジャーモジュー
ルにより実行される。次に、フォーマットオペレーショ
ンの実行においてフォームマネージャーモジュールによ
り行われるオペレーションの流れ図が示されている図８
を参照する。通信インターフェイスのフォームマネジャ
ーモジュールにおけるルーチンの各種の機能についての
詳細が、ここに含まれている通信インターフェイスの各
種のライブラリィルーチンについての機能の仕様中に見
出される。図８のプロセスは、本発明の通信インターフ
ェイスの中のデータ交換コンポーネントのフォームマネ
ジャーモジュール中のソフトウェアプログラムにより実
現される。第１のステップはアプリケーションから、ま
たは通信インターフェイス中の別のモジュールからフォ
ーマット変換呼出しを受けることである。このプロセス
は、ブロック９０と図１の経路９２、９４とにより表現
されている。同じ種類の呼出しを、図１におけるホスト
コンピュータ１２に対してアプリケーション１８または
通信コンポーネント９６により、データ交換コンポーネ
ント８８中のフォームマネージャーモジュールに対して
行うことができる。その理由は、これは、本発明の通信
インターフェイスにより全てのクライエントアプリケー
ションへ提供される標準的な機能すなわち「ツール」だ
からである。あらゆるクライエントアプリケーション
は、図１のインターフェイス２０のような通信インター
フェイスに結合される。典型的には、図１のモジュール
３０、９６のような通信コンポーネントからフォームマ
ネージャモジュールへ与えられるフォーマット変換コー
ルは、フォーマット１のフォームを送るタスクを与えら
れたサービス統制モジュールからフォーマット２を使用
する外部アプリケーションへのコールである。通信イン
ターフェイスの中の別のモジュールからのフォーマット
変換コールについての別の同様なシナリオは、サービス
統制が、外部フォーマットであって、クライエントアプ
リケーションのフォーマットへ変換する必要がある別の
アプリケーションまたはサービスからフォームを受けた
時である。

【００６６】フォーマット変換コールには、パラメータ
が組合され、それらのパラメータはフォームマネジャー
へ与えられる。これらのパラメータは、「取出し」フォ
ーマットと「受入れ」すなわち「ターゲット」フォーマ
ットを指定する。

【００６７】ブロック９８は、指定された変換のための
適切なターゲトフォーマット特有のテーブルをアドレッ
シングするプロセスを表わす、すなわち、指定された
「取出し」フォーマットが、各原始「取出し」フォーマ
ットクラスに対する適切なターゲットフォーマットにつ
いての詳細を与えて、変換を完了させる専用のテーブル
を有する。好適な実施例においては、あらゆる変換オペ
レーション中に順次アドレスされる２つのテーブルがあ
る。別の実施例においては、それら２つのテーブルを組
合わせることができる。好適な実施例において用いられ
る２つのテーブルの例が、図９〜図１１に示されてい
る。図９は、ＤＥＣマシンからＸ．４０９フォーマット
へ変換するための特定のフォーマット変換テーブルを示
す。図１０は、Ｘ．４０９フォーマットからアイビーエ
ム・マシンのフォーマットへの変換のためのフォーマッ
ト特有変換テーブルを示す。図１１は、各「取出し」−
「受入れ」フォーマット対に対して特定の変換を行う通
信インターフェイスライブラリィ中の変換プログラムの
名称を識別する全体的な変換手順表を示す。

【００６８】図９と図１０のテーブルは、図１のアプリ
ケーション１６からアプリケーション１８へフォームを
送るために必要なテーブルの全てではないであろう。ア
プリケーション１６のフォーマットから、ＤＥＣマシン
フォーマットへ変換するため、あるいは、アイビーエム
・マシンフォーマットからアプリケーション１８のフォ
ーマットへの変換のために必要な別のフォーマット特有
のテーブルもある。しかし、通信インターフェイスのフ
ォームマネジャーモジュールにより実現されるフォーマ
ット変換プロセスの全体的な概念を、図９〜図１０を参
照にして説明できる。

【００６９】アプリケーション１６からアプリケーショ
ン１８へフォームを送るプロセスにおいて必要な第１の
変換は、ＤＥＣマシンフォーマットから、イーサネット
（商標）ネットワークを介して送るために適当なパック
されたフォーマットへの変換であると仮定するこの場合
には、ステップ９０で受けられたフォーマット変換コー
ルは、ブロック９８により表わされているプロセスを行
うフォームマネージャーモジュール内のソフトウェアに
よる呼び出し処理である。

【００７０】この仮定した例においては、このルーチン
によりアクセスするための適切なフォーマットに特有の
テーブルが、ブロック９０により受けられた元のフォー
マット変換コールにおける「取出し」フォーマットと
「受入れ」フォーマットの各パラメータにより決定され
る。これにより、図９に示されている表がアクセスされ
る。フォーマット変換コールは、変換すべきフォームの
アドレスの識別も行う。

【００７１】次のステップがブロック１００により示さ
れている。このステップは、元のフォーマット変換コー
ルにおいては識別されるフォームをアクセスすること
と、フォームの原始クラスを含んでいる第１のフィール
ドを見付けるためにフォームを探索することを含む。い
いかえると、サブフィールドを有する別の構造化フォー
ムとは異なって、フィールドが実際のデータを格納して
いることを見出されるまで、レコードが探索される。

【００７２】図６に示されているフォームの場合には、
フォームの原始クラスを格納する第１のフィールドはフ
ィールド４２である。図９の表の「取出し」列は、適切
なエントリィが見出されるまで、クラス番号１０を用い
て探索される。この場合には、１０の「取出し」クラス
に対するエントリィが、原始クラス２５に対するクラス
定義中で指定されているフォーマットは「受入れ」フォ
ーマットであること示す。「取出し」フォーマットを用
いて「受入れ」フォーマットを探索するこのプロセスが
図８のブロックで示されている。図９に示すテーブル
を、ブロック１０２で示されているステップを行うルー
チンのコードに「接続(hardwired)」できる。

【００７３】あるいは、図９のテーブルを、図１のネッ
トワークファイルシステム２４のどこかに格納されるデ
ータベースまたはその他のファイルとすることができ
る。その場合には、図８のステップ１０２を実行するル
ーチンは、図９のテーブルをアクセスするためにネット
ワークのアドレスとファイル名を知る。

【００７４】次に、図８のブロック１０４に示されてい
るプロセスは、図１１に示されている一般的な変換手順
をアクセスすることによって行われる。これは、フォー
ムの１つの原始クラスをフォームの別の原始プログラム
へ変換する実際の作業を実行するフォームマネジャー中
の変換プログラムを識別するテーブルである。この表は
あらゆる「取出し」−「受入れ」フォーマット対のため
の１つのエントリィで編成される。「取出し」−「受入
れ」対に対するテーブル中のエントリィは、変換の実際
の作業を行う変換ルーチンの名称を含む。ブロック１０
４に示されているプロセスは、ステップ１０２における
フォーマット特有の変換テーブルをアクセスすることか
ら決定される「取出し」−「受入れ」対をとり、「取出
し」−「受入れ」一致を有するエントリィが見出される
まで、一般的な変換手順テーブルのエントリィを検索す
る。この場合には、図１１のテーブルの一番上から３番
目のエントリィが、図９へのアクセスにおいて見出され
た「取出し」−「受入れ」フォーマット対に一致する。
このエントリィは読み出され、この変換を行うためのル
ーチンの名称が「ASCII ETHER」であると決定される。
（多くの実施例においては、名称ではなくて、ルーチン
のメモリアドレスがテーブルに格納される。）図８のブ
ロック１０６は、ブロック１０４で識別された変換プロ
グラムを呼出し、この変換ルーチンを行って、ステップ
１００で選択したフィールドの内容を、ステップ１０２
で識別された「受入れ」フォーマットすなわちターゲッ
トフォーマットへ変換することを行うプロセスを示す。
仮定した例においては、ルーチン「ASCII ETHER」が呼
出され、ステップ１０６により実行される。このルーチ
ンを呼出すと、ステップ１００のプロセスにおいて選択
されたフィールド、すなわち、図６に示すフォーム例の
フィールド４２に格納されている実際のデータを供給し
て、テキストストリング「Ｕ．Ｓ．オープン」がパック
されたイーサネットフォーマットへ変換される。

【００７５】次に、ブロック１０８のテストが行われ、
フォーム原始クラスが処理されたかどうかを判定する。
もし処理されたとするとフォームのフォーマット変換は
終了され、ブロック１１０により示されているようにフ
ォーマット変換ルーチンを出る。

【００７６】フォームの原始クラスを含んでいる処理す
べきフィールドが残っていれば、ブロック１１２で示さ
れているプロセスが実行される。このプロセスはフォー
ムの原始クラスを含んでいる次のフィールドを見つけ
る。

【００７７】その後、フォームの原始クラスを含んでい
る全てのフィールドが適切な「受入れ」フォーマットへ
変換されるまで、ブロック１０２、１０４、１０６、１
０８により示されている処理ステップが実行される。

【００７８】上記のように、フォームの原始クラスを含
んでいるフィールドを探索するステップは、変換すべき
フォームを通って直列に進む。次に出合うフィールドが
構造化クラスのフォームを含んでいるとすると、フォー
ムの原始クラスを内部に有する最初のフィールドが検索
されるまで、フォームのそのクラス自体が探索される。
全てのフィールドが処理され、フォームに格納されてい
る全てのデータが適切なフォーマットに変換されるま
で、その全てのフィールドに対するあらゆるネスティン
グレベルにわたってそのプロセスは続く。これがどのよ
うにして行われるのかの例として、図６のフォームにお
いては、第１のフィールド４２の処理の後で、図８のブ
ロック１１２により示されているプロセスがフィールド
４４に次に遭遇する（フィールドは、そのフィールドに
格納されているフォームに対するクラスＩＤと実際のデ
ータであり、またはそのフィールドに格納されているオ
ームのフィールドとサブフィールドである）。図６によ
り表わされているフォームの特定のクラスにおいては、
いくつかのサブフィールドで構成されている構造化フォ
ームを第２のフィールド４４が含むことに注目された
い。それから処理はクラス１０００の構造化フォームを
アクセスする。そのフォームは、第２のフィールドによ
り格納され、原始クラスのフォームを含んでいるそれの
第１フィールドを探すまで、その構造化フォームの中を
直列に進む。図６の仮定例においては、第１のフィール
ドは５２におけるクラス番号１１により示されるサブフ
ィールドである。それから、ブロック１０２により示さ
れているプロセスは、図９のテーブル中の「取出し」列
内のクラス１１を探索し、ターゲットフォーマットが原
始クラス１５のクラス定義により指定されることを決定
する。それから、この「取出し」−「受入れ」対１１〜
１５が、図１１のテーブルのエントリィと比較され、一
致するエントリィが見い出される。その後、図８のブロ
ック１０６のプロセスが、「Floatl ether」とよばれる
変換プログラムを実行し、図６の６０におけるデータの
ブロックを適切なイーサネット・パックされたフォーマ
ットへ変換する。それから、このプロセスは全てのネス
ティングレベルにわたって続行される。次に、典型的な
意味依存オペレーションについての流れ図が示されてい
る図１２を参照する。フィールド名が既知で、フォーム
例のアドレスが既知であるならば、外部アプリケーショ
ンにより発生されたフォームの例の特定のフィールド中
のデータを１つのアプリケーションが得ることができる
ようにすることにより、アプリケーションの切離しを許
す。本発明の通信インターフェイスは、好適な実施例に
おいては、フィールドを得る呼出し(getfield call)の
フォームでクライエントアプリケーションから意味依存
オペレーション要求を受ける。その好適な実施例におい
ては、全てのプロセスは、同じことを意味するデータフ
ィールドに対する同じフィールド名を用いる（フォーム
の編成、または外部プロセスにより発生されたフォーム
でのフィールドのデータ表現とは無関係に）。別の実施
例においては、俗称テーブル(aliasing table)または同
義語テーブル(synonym table)あるいはデータベースが
用いられる。そのような実施例においては、フィールド
を得る呼出しを用いてクラスマネジャー内の同義語テー
ブルをアクセスし、要求されたフィールド名の全ての同
義語を探す。求められているフィールド名と同義である
全てのフィールド名が戻される。それから、クラスマネ
ジャーは、求められているフィールド名または同義名の
いずれかとの一致のためのクラス定義を探し、一致フィ
ールドを有するフィールドを検索する。

【００７９】次に好適な実施例の説明へ戻って、このよ
うなフィールドを得る呼出しは、クライエントアプリケ
ーションにより、図１のモジュール１２２のようなフォ
ームクラスマネジャーモジュールに対して直接行うこと
ができ、またはそれらのモジュールを通信コンポーネン
トまたはフォームマネジャーモジュールにし、それらの
モジュールによりフォームクラスマネジャーへ転送させ
ることができる。フォームクラスマネジャーはフォーム
クラス定義を作成し、破棄し、取扱い、格納し、読み出
す。

【００８０】フィールドを得る呼出しは、含まれている
フォームのアドレスと、対とするフォーム中のフィール
ド名とをフォームクラスマネジャーへ供給する。その要
求を受けるプロセスが図１２のブロック１２０により示
されている。ブロック１２０は、プログラムにより、す
なわち、要求しているアプリケーションにより、または
対象とするフォームに対するクラス定義を含めたクラス
定義を見出すことができるデータベースの場所を告げら
れることによって、クラスマネージャーにクラス定義が
与えられるようにするプロセスも示すものである。図１
のネットワークファイルシステム２４にはいくつかのデ
ータベースすなわちファイルを設けることができ、それ
にクラス定義が格納される。対象とするフォームに対す
るクラス定義が格納される特定のファイルの場所をフォ
ームクラスマネジャーへ与えることが必要なだけであ
る。

【００８１】次に、ブロック１２２に示すように、クラ
スマネジャーモジュールは、元の呼出しにおいて識別さ
れたフォームクラスに対するクラス定義をアクセスす
る。

【００８２】それから、クラスマネジャーはクラス定義
フィールド名を検索して、元の呼出において与えられた
フィールドの名の一致を見出す。このプロセスがブロッ
ク１２４に示されている。

【００８３】対象とするフィールドをクラス定義中で探
した後で、クラスマネジャーは相対的なアドレスポイン
タを、このクラスのフォーム例中の対象とするフィール
ドへ戻す。このプロセスが図１２のブロック１２６に示
されている。クラスマネジャーにより戻されるこの相対
的なアドレスポインタは、図２、図４、図６を参照とす
ることによって最も良く理解される。フィールドを得る
呼び出しを行ったアプリケーションが、特定のプレイヤ
ーの年齢の決定に興味をもったと仮定する。フィールド
を得る要求は、図６に示すように、プレイヤーのブラケ
ット(Blacktt)に対するクラス１００２のフォーム例の
ためのアドレスを識別する。又、フィールドを得る要求
には対象とするフィールドの名称、すなわち、「年令」
も含まれる。それからクラスマネジャーは対象とするフ
ォームの例をアクセスし、フォームのこのクラスへ加え
られる特定のクラス識別子又はクラス定義を示すクラス
番号を読み出す。それから、クラスマネジャーは、図４
に示すように、クラス１００２のためのクラス記述子を
アクセスし、クラス定義を見つける。次に、クラスマネ
ジャーは、クラス定義１００２の各フィールドに対する
クラス定義をアクセスし、元のフィールドを得る要求中
のフィールド名を、クラス１００２に対するクラス定義
を構成する種々のクラス定義中のフィールド名と比較す
る。言換えると、クラスマネジャーは、クラス１０、１
０００及び１００１に対するクラス定義中のフィールド
名を対象とするフィールド名「年令」と比較する。図２
からわかるように、クラス１０００についてのクラス定
義において一致が見出される。図６に示されている特定
のレコードフォーマットに対して、「年令」フィールド
は、データブロック６２である。このデータブロック
は、レコードのスタートから１０番目のデータブロック
である。それからクラスマネジャーは図１２のブロック
１２６内の１０の相対的なアドレスポインタを戻す。こ
の相対的なアドレスポインタは、元のフィールドを得る
呼出を行ったクライエントアプリケーションへ戻され
る。それからクライエントアプリケーションは、データ
を得る呼び出しをフォームマネジャーモジュールへ発
し、対象とするフォームの特定の例内の希望のフィール
ドの相対的なアドレスをフォームマネジャーモジュール
へ供給する。フォームマネジャーモジュールは、元のフ
ィールドを得る呼出がフォームマネジャーモジュールを
通ってきて、フォームクラスマネジャーへ戻されるなら
ば、それが既に有するであろう対象とするフォーム例の
アドレスも知らなければならない。フォームマネジャー
モジュールが対象とするフォームの特定の例のアドレス
を有しないとすると、フォームマネジャーはクライエン
トアプリケーションからそれを要求する。データを得る
呼出を受け、相対的なアドレスと、対象とするフォーム
の例のアドレスとを得た後で、フォームマネジャーはフ
ォームのこの例をアクセスし、それをクライエントへ戻
す。このデータを得る呼び出しを受けるプロセスと適切
なデータの返送を行うプロセスは、図１２において、ブ
ロック１２８によって示されている。

【００８４】通常、クラスマネージャーモジュールは、
ホストマシンのＲＡＭ中で行う意味依存オペレーション
に必要なクラス定義を、クラス記述子として記憶する。
クラス定義は、意味の詳細とクラスを定義するフォーメ
ーション情報である。クラス記述子は、クラス定義の具
体的なメモリオブジェクトである。クラス記述子は、少
なくとも２つの方法で記憶される。ランダム・アクセス
・メモリ(RAM)において、クラス記述子は、機械に特有
のフォーマットおよびクラス定義を作成したクライエン
トアプリケーションに特有のフォーマットでフォームと
して記憶される。ディスクもしくはテープに記憶された
クラス記述子は、テキストのASCIIストリングとして記
憶される。

【００８５】クラスマネージャモジュールが意味依存オ
ペレーションを行うことを要求すると、ＲＡＭに記憶さ
れたクラス記述子を検索し、適当なクラス記述子が存在
するかどうかを決定する。もしあれば、そのクラス記述
子が、図１２の上記オペレーションの実行に使用され
る。適当なクラス記述子がなければ、クラスマネージャ
が入手する。これは、図１のシステムファイル２４に記
憶されたクラス記述子の既知のファイルを検索すること
により、あるいはクラス定義を作成した外部アプリケー
ションに対し、要求されたモジュールのクラス定義を送
るように要求することにより、行われる。クラス記述子
を記憶したファイルの位置は、クライエントアプリケー
ションに知られており、クラスマネージャモジュールも
このアドレスを記憶している。意味依存のオペレーショ
ンの要求には、適当なクラス記述子が見出されるであろ
うファイルのアドレスが含まれることがある。要求に上
記のようなアドレスが含まれていない場合には、クラス
マネージャクラス記述子の記憶内容を介して、さらにシ
ステム記述子ファイルの位置を確認するクラスマネージ
ャによって記憶されたレコードの中に確認されたファイ
ルを介して見つけ出す。

【００８６】クラスマネージャがクラス記述を作成した
外部のアプリケーションからクラス記述子を要求すれ
ば、外部アプリケーションは、クラスマネージャに対し
て、ネットワークから要求しているクラスマネージャも
しくは要求モジュールに対する適当なクラス記述子を送
るような要求を送る。クラス記述子は、他の形式で送ら
れ、要求された意味依存オペレーションを行うためのク
ラスマネージャを要求する。

【００８７】クラスマネージャはクラス記述子を得るた
めにファイルにアクセスしなければならない場合、クラ
ス記述が含まれておりパックされたASCII表現をＲＡＭ
に記憶する本来の型に変換しなければならない。これ
は、ASCIIテキストを種々のフィールド名、フィールド
内容の詳細、クラスマネージャに分けて細かに調べるこ
とによって行われる。

【００８８】図１３Ａ、図１３Ｂは、フォームとしてメ
モリに定義されたクラス記述子のクラス定義、構造、編
成を示している。図１３Ａに与えられたクラス定義は、
パーソンクラスと名付けられ、姓と名の２つのフィール
ドのみを有する。これら各フィールドには、２０文字の
ASCIIストリングが記憶される。

【００８９】図１３Ｂは、クラス番号１０２１を有する
構造化フォームデータブロック１４０を有している。第
１のフィールドは、この例では、パーソンクラスという
クラス名を示すASCIIストリングを含むと指定された原
始クラスを含んでいる（データブロック１４６）。第２
のフィールドは、番号２、データブロック１４８が付さ
れ、データブロック１５０と指定された原始クラスであ
る。第２フィールドは、クラス１０２１のクラス定義に
より定義され、このフォームクラスが、原始（真）であ
るか構造化されているか（偽）が決定されている。この
例においては、データブロック１５０は偽であり、クラ
ス１０２１が構造化クラスであることを示している。第
３フィールドは、データブロック１５２で示され、クラ
ス番号１１２が付与された構造化クラスである。クラス
１０２１のクラス定義は、第３フィールドが、フィール
ド名と詳細をクラス定義に与えることにより構造化クラ
スであることを定義している。データブロック１５４
は、クラス１１２に表われる２つのフィールドを示して
いる。クラス１１２の第１のフィールドは、それ自身ク
ラス番号１５０、データブロック１５６を与えられた構
造化クラスであり、２つのサブフィールド、データブロ
ック１５８を有している。

【００９０】第１サブフィールドは、原始クラス１５、
データブロック１６０であり、クラス１５０として指定
され、クラス１０２１の第１フィールド名を含むように
されている。データブロック１６２は、クラス１０２１
のファーストフィールド名を与える。

【００９１】第２サブフィールドは、原始クラス１５、
データブロック１６４であり、クラス１５０とクラス定
義されており（図示せず）、クラス１０２１の第１フィ
ールド中に記憶された実データ（データブロック１６
４）を指定するASCIIストリングが含まれている。クラ
ス１１２の第２フィールドは、クラス１１２で定義さ
れ、クラス１５０のフォーム、データブロック１６８と
データブロック１７０を有している。データブロック１
６８は、２つのフィールドを持ち、データブロック１７
０は、クラス１０２１の次のフィールドの名前を与える
とともに、第２フィールドに記憶された実データの表現
の型を指定する。

【００９２】

【主題に基づくアドレッシングによるデータ分配および
サービスプロトコルの切り離しおよびサービス統制プロ
トコル層の使用】次に、切り離しの２つの重要なフォー
ムを実現するために協同する各種のソフトウェアモジュ
ールと、ファイルと、ネットワークと、コンピュータと
のブロック図が示されている図１４を参照する。切り離
しのそれらのフォームはデータ分配切り離しおよびサー
ビスプロトコル切り離しである。データ分配切り離し手
段は、希望のサービスを行うサーバーに対するネットワ
ークアドレスを知る必要からクライエントアプリケーシ
ョンを自由にする。したがって、たとえば、ダウ・ジョ
ーンズ・ニュース・サービス(Dow Jones News Servise)
により供給される情報を特定のアプリケーションが知る
必要があるものとすると、クライエントアプリケーショ
ンは、そのサーバーおよびどの場所がダウ・ジョーンズ
・ニュース・サービスから生のデータを供給しているか
を知る必要がない。

【００９３】データ交換が望まれるサーバー、サービ
ス、その他のアプリケーションにより用いられる通信プ
ロトコルを、クライエントアプリケーションが知る必要
がないことをサービスプロトコル切り離しは意味する。

【００９４】データ分配の切り離しは、図１４における
通信モジュール３０により実現される。通信コンポーネ
ントは、主題マッパ１８０を実現するソフトウェアルー
チンのライブラリィと、主題に基づくアドレッシングを
実現するための複数のサービス統制とで構成される。サ
ービス統制１８２、１８４、１８６は、主題に基づくア
ドレッシングに含まれているサービス統制の例である。

【００９５】主題に基づくアドレッシングは、サービス
を修正すること、又は別のサービスで置き換えて、情報
の受手に衝撃を与えることなしに等しい情報を提供す
る。情報供給元から情報の受手を切り離すことにより、
従来のサービス向けモデルよりも高度のモジュール化
と、融通性を持たせることができる。

【００９６】主題に基づくアドレッシングは、ホストコ
ンピュータ１０で実行しているクライエントアプリケー
ション１６により、主題マッパ１８０に対する申込みコ
ール１８８で開始される。申込みコールは特定の主題に
関する情報に対する要求である。特定の主題が株、ＩＢ
Ｍ、ニュースであると仮定する。この申込みコールは、
２つのパラメータを主題マッパ１８０へ送る。それらの
パラメータの１つは主題、株、ＩＢＭ、ニュースであ
る。他のパラメータは、主題についてのデータを送らね
ばならないクライエントアプリケーション１６における
呼出しルーチンの名称である。主題マッパ１８に対する
申込み呼出しは、標準的な手順呼出しである。

【００９７】この主題マッパの目的は、サービスのため
のネットワークアドレスを決定すること、およびそれら
のサービスに対して通信を決定するために適切なサービ
ス統制ルーチンを呼出すことである。申込みコールにお
ける主題についての情報を提供するサービスの場所を見
つけるために、主題マッパ１８０は、線１９０により表
わされている要求をディレクトリサービスコンポーネン
ト１９２へ送る。ディレクトリサービスコンポーネント
は、ネットワークの結合されている別のコンピュータで
実行されている別のプロセスであって、実際に別のコン
ピュータ又はホストコンピュータ１０で実行させること
ができる。ディレクトリサービスルーチンは、その主題
についての情報をどのサービスが供給するのか、それら
のサービスがどこにあるのか、および通信のためにそれ
らのサービスにより用いられるサービス統制を示すデー
タベース、又はサービスレコードとよばれるレコードの
テーブルを維持する。ディレクトリサービスコンポーネ
ント１９２は、主題マッパ１８０から送られた要求を受
け、そのテーブルを通じて一致を探すためにその要求の
主題パラメータを用いる。即ち、ディレクトリサービス
コンポーネント１９２は、希望の主題についての情報を
提供する特定のサービスを示すサービスレコードを探
す。次にそのサービスレコードは、線１９４により示さ
れているように主題マッパへ送り帰される。ディレクト
リサービスコンポーネントは、多数のサービスが希望の
主題についての情報を供給するものとすれば、いくつか
の一致を見出すことができる。

【００９８】線１９４により示されている主題マッパへ
送り返されるサービスレコードは、多くのフィールドを
含む。サービスレコード内での求められる２つのレコー
ドは、希望の主題についての情報を提供するサービスの
名称と、そのサービスにより用いられるサービス統制の
名称である。供給できる他の選択できるフィールドは、
そのサービスを実施するサーバーの名称とそのサーバー
のネットワークにおける場所である。

【００９９】一般に、ディレクトリサービスコンポーネ
ントは、主題サービスが存在する全てのサービスレコー
ドを供給する。その理由は、全てのサービスにより主題
へ提供される情報中には完全な重なり合いが存在しない
ことがあるからである。更に、各サービスは別のサーバ
ーにより実行される。そのサーバーは、同じネットワー
クによりクライエントアプリケーションへ結合してもよ
く、又は結合しなくともよい。そのような多数のネット
ワーク経路とサービスが存在するものとすると、主題が
一致している全てのサービスレコードを主題マッパへ送
り返すことにより、ネットワーク、サーバー又はサービ
スのいずれかが故障した時に、それらを切り換える能力
を通信インターフェイスに持たせられる。

【０１００】上記のように、主題マッパ１８０は全ての
サービスと通信を行うように機能して、希望の主題につ
いての情報を提供する。多数のサービスレコードがディ
レクトリサービスモジュール１９２から返送されたとす
ると、主題マッパ１８０はそれらのサービスの全てと通
信を設定する。

【０１０１】サービスレコードを受けると、主題マッパ
は識別された各サービス統制を呼出して、主題と、その
サービス統制へ加えることができるサービスレコードを
それへ送る。図１４には、ただ３つのサービス統制１８
２、１８４、１８６が示されているが、実際のシステム
では３つよりも多くのものを設けることができる。ディ
レクトリサービスコンポーネント１９２が存在しない
か、一致を見出さないとすると、主題マッパ１８０へは
サービスレコードは戻されない。この場合には、主題マ
ッパは省略時サービス統制を呼出して、それと主題およ
び無効(null)レコードを送る。

【０１０２】各サービス統制は、ソフトウェアモジュー
ルであって、そのサービス統制に関連する特定のサービ
スと通信するために最適にされた特注のサービスを含
む。

【０１０３】主題マッパ１８０により呼出された各サー
ビス統制は、それへ送られたサービスレコードを調べ、
通信を行うべきサービスの場所を決定する。考察してい
る特定の仮定した例においては、ディレクトリサービス
モジュール１９２によりただ１つのサービスレコードが
戻されていること、そのサービスレコードがサーバー１
９６で行われているダウジョーンズニュースサービスを
識別すること、および１８２においてサービス統制Ａ
を、サーバー１９６におけるダウジョーンズニュースサ
ービスと通信するために適切なサービス統制として識別
する。それから、サービス統制Ａは、要求メッセージを
線１９８で示されているようにサーバー１９６へ送る。
この要求メッセージは、主題をサービスへ送り、サービ
スレコード全部又は一部を送ることができる。

【０１０４】サーバー１９６は要求メッセージを処理
し、実際に、希望の主題についての情報を供給できるか
どうかを判定する。それからそれは、線２００により示
されている応答メッセージを送り返す。

【０１０５】通信がそのようにして、ひとたび設定され
たとすると、要求されている主題に関連する情報の全て
の項目を、経路２０２で示されているように適切なサー
ビス統制へ連続して送る。ここで選択した例において
は、サーバー１９６で行われるサービスは、サービス統
制１８２へ送るためにアイビーエムに関連する新しい事
項だけを抽出する。他の実施例においては、サーバー
は、主題による選別を行うことなく全ての情報を通過さ
せるものであってもよい。通信コンポーネント３０は、
要求された主題だけを選び出し、要求したアプリケーシ
ョン１６に送る。これは、以下に説明するデーモン(dea
mon)によって行われる。また、以下に説明する情報層、
サービス層等のいずれかにて行ってもよい。

【０１０６】各サービス統制は、異なる挙動をとること
ができる。例えば、１８４におけるサービス統制Ｂは、
次の挙動をとることができる。サーバー１９６で行われ
るサービスは、ダウジョーンズニューサービスの全ての
ニュース事項をネットワーク１４で同時通信（放送）で
きる。サービス統制Ｂの全ての例は、ネットワークを監
視でき、希望の主題に関連するメッセージだけを抽出す
る。多くの異なる通信プロトコルを用いることが可能で
ある。

【０１０７】１８２におけるサービス統制Ａは、サービ
スにより送られたデータを受け、それをクライエントア
プリケーション１６中の名付けられている戻しルーチン
２０４へ送る。（サービス統制１８２は、線１８２で示
されているように主題マッパ１８０からの最初のメッセ
ージ中の呼戻しルーチンの名称を送った。）名称をつけ
られた呼戻しルーチンは、希望の主題についての情報
で、行うようにプログラムされているものは何でも行
う。

【０１０８】クライエントアプリケーション１６が取消
し指令を主題マッパ１８０へ明確に送るまでは、データ
は名称をつけられている呼戻しルーチン２０４へこのよ
うにして流れ続ける。主題マッパ１８０は、存在してい
る全ての申込みのレコードを保存して、有効である種々
の申込みと取消し指令を比較する。一致が見出されたと
すると、適切なサービス統制に取消し要求が知らされ、
それからこのサービス統制が取消しメッセージを適切な
サーバーへ送る。それからサービスは、その主題につい
てのそれ以上のデータを、取消し要求を送ったサービス
統制に送ることを止める。

【０１０９】サービス統制が自立しており、主題マッパ
へ結合されないことも可能である。この場合には、サー
ビス統制はアプリケーションへ直結され、申込みコール
はサービス統制に対して直接行われる。違いは、希望の
データを供給するサービスの名称と、サービスをアクセ
スするために用いられるサービス統制の名称をアプリケ
ーションが知らなければならないことである。次に、識
別されたサービスのネットワークアドレスを見つけるた
めにデータベースまたはディレクトリサービステーブル
がアクセスされ、上記のようにして通信が設定される。
このソフトウェアアーテキクチャは、データ分配の切り
離しを行わないが、サービスプロトコルの切り離しを行
い、それによって、データを交換すべきサービスとの通
信インターフェイスの詳細を知る必要からアプリケーシ
ョンを自由にする。

【０１１０】本発明の通信インターフェイスにより行わ
れる、主題に基づくアドレッシング申込みサービスにつ
いてのより多くの詳細は、下記の通信インターフェイス
仕様の４節に示されている。本発明の通信インターフェ
イスの好適な実施例がその仕様に従って構成される。

【０１１１】好適な実施例における実際の申込み機能
は、仕様の４節に述べられているＴＩＢ消費作成ライブ
ラリィルーチンを実行することにより行われる。ＴＩＢ
消費作成に対する呼出しは、それへ送られたパラメータ
の特性リストを含む。それの１つが、仕様の４節におけ
る私のメッセージハンドラー(my message handler)と指
定されている呼戻しルーチンである。

【０１１２】仕様においては、主題に基づくアドレッシ
ング申込みサービス機能がTIBINFOとして示されてい
る。このTIBINFO インターフェイスは、２つのライブラ
リィより成る。最初のライブラリィは、データの需要者
に対するTIBINFO CONSUMEと呼ばれる。第２のライブラ
リィはデータ供給者に対するTIBINFO PUBLISHと呼ばれ
る。あるアプリケーションは、それが消費需要者か、供
給者か、あるいは両方であるかに応じて、一方のライブ
ラリィを含む。アプリケーションは需要者と供給者を同
時に兼ねることができる。

【０１１３】次に、本発明のインターフェイスとアプリ
ケーション、およびそれらのアプリケーションを結合す
るネットワークの関係のブロック図が示されている図１
５を参照する。第１図におけるブロックの参照番号と同
じものがつけられているブロックは、第１図における対
応するブロックに類似の機能を有する。図１５のブロッ
ク図は、好適な実施例のプロセスアーテキクチャを示
す。図１５に与えられているプロセスアーテキクチャに
対応するソフトウェアアーテキクチャが、図１６にブロ
ックで示されている。

【０１１４】図１５において、図１の通信コンポーネン
ト３０は、図１５では２つの別々の機能ブロック３０
Ａ、３０Ｂとして示されている。すなわち、図１におけ
る通信コンポーネントの機能が、図１５のプロセスアー
テキクチャでは２つの機能ブロックに分割される。通信
ライブラリィ３０Ａは、各クライエントアプリケーショ
ン１６へ結合され、バックエンド通信デーモン３０Ｂが
ネットワーク１４と通信ライブラリィ３０Ａへ結合され
る。ホストプロセッサ当り１つの通信デーモンが存在す
ることが一般的である。このホストプロセッサは、図１
５には２３０で示されているが、図１６には全て示され
ていない。図１５においては、図１の状況とは異なっ
て、クライエントアプリケーション１６と１８は同じホ
ストコンピュータ２３０で実行されることに注目された
い。各クライエントアプリケーションは、通信ライブラ
リィ３０Ａと９６中の各種のライブラリィプログラムの
それ自信のコピーと、データ交換コンポーネント３２と
８８のフォームライブラリィのそれ自身のコピーとへ結
合される。プログラムのそれらの結合されたライブラリ
ィは共通の通信デーモン３０Ｂを共用する。

【０１１５】種々のホストプロセッサにおける通信デー
モンは、共同して、マシンの間で確実かつ効率的な通信
を行えるようにする。主題をアドレスされたデータに対
しては、デーモンは、主題によりメッセージを抽出する
ために低レベルのシステムサポートを行うことにより、
それの効率的な送信を助ける。通信デーモンは、エラー
対策、負荷の平均化、ネットワーク効率の改善のため、
種々の通信プロトコルを実行する。

【０１１６】通信ライブラリィ３０Ａは、各１組のアプ
リケーション向きの通信に関連する数多くの機能を行
う。例えば、通信ライブラリィは、ASCII主題値よりも
簡潔で、検査が容易である効率的なメッセージヘッダへ
主題を翻訳する。通信ライブラリィは、特定のサービス
例のための目標にされた要求にサービス要求をマップ
し、それらの状態を監視する。

【０１１７】本発明の通信インターフェイスのデータ交
換コンポーネントは、「フォームライブラリィ」とよば
れるライブラリィとして実現される。このライブラリィ
はクライエントアプリケーションへ結合され、データコ
ンポーネントの全ての中核機能を提供する。フォームラ
イブラリィは、通信ライブラリィとは独立に結合でき、
それの動作のために通信デーモン３０Ｂを要求すること
はない。

【０１１８】通信デーモンは、２つの役割を果す。サー
ビス例が主題と、この主題に関するデータを送るネット
ワークアドレスを知らされる、上記した主題に基づくア
ドレッシングモードにおいては、通信デーモン３０Ｂは
データを送るべきネットワークアドレスを所有する。こ
のデータは、デーモンによりクライエントアプリケーシ
ョンに結びつけられている通信ライブラリィへ送られ
る。そのクライエントアプリケーションは、データをク
ライエントアプリケーション中の適切な呼戻しルーチン
へ送る。他のモードにおいては、データを供給するサー
ビス例が同時通信モードにあって、多くの異なる主題に
ついてのデータをネットワークにおける全てのデーモン
へ呼出す時に、通信デーモンはネットワーク１４から来
るデータを主題により選別する。

【０１１９】図１５におけるブロック２３１、２３３、
２３５は、通信ライブラリィ３０Ａとフォームライブラ
リィ３２中のプログラムにより実現されるインターフェ
イス機能を表わす。TIBINFOインターフェイス２３３
は、申込みコールとして知られている通信パラダイム(p
aradigm)により、主題に基づくアドレッシングサービス
を行う。このパラダイムにおいては、データ需要者はサ
ービスまたは主題を申込み、需要者が申込みを明確に終
らせる（または障害が起こる）まで、サービスまたは主
題についてのデータの連続した流れを受ける。申込みパ
ラダイムは、株価のような動的に変化する値を監視する
リアルタイムアプリケーションに適する。これとは対称
的に、従来の要求／応答通信(request/reply communica
tion)は、データの需要者が変化を学ぶデータ提供者を
「選ぶ」ことを要するから、そのようなリアルタイムア
プリケーションにはあまり適さない。

【０１２０】インターフェイス２３５は、１組のプロト
コルと、図１６のマーケットデータ申込みサービス(MDS
S)サブコンポーネント２３４を含むサービスとに対する
プログラムインターフェイスを構成する。このサービス
統制については後で詳しく説明する。RMDPインターフェ
イス２３５は、サービスアドレスプロトコルであって、
データを交換するサービスの名称についてデータを知る
ことをクライエントアプリケーションに求める。

【０１２１】図１６に、システムのソフトウェアアーキ
テクチャを示す。分散型通信コンポーネント２３２は種
々のプロトコルエンジン２３７、２３９と２４１を含ん
でいる。プロトコルエンジンは、サービス統制プロトコ
ルをある特定のネットワークプロトコルにインタフェー
スする通信プロトコルをカプセル化する。各プロトコル
エンジンは、信頼性も効率も高い通信網を確立するのに
要するあらゆるロジックをカプセル化する。各プロトコ
ルエンジンは、特定のネットワーク特性と特定の利用分
野の特性に合うように調整される。プロトコルエンジン
２３７、２３９、２４１は、アプリケーション１６や１
８のようなユーザーアプリケーションのために汎用通信
インタフェースを提供する。このことにより、これらア
プリケーション（プログラマにより書かれる）が特定の
ネットワーク上で通信するために必要なそのネットワー
クの知識とトランスポート層プロトコルの知識が必要と
されなくなる。ネットワークプロトコルの内のいずれ
か、またはネットワーク構成が、例えば新規にローカル
エリアネットワークやゲートウェイが追加されたりして
変更されたり、またはトランスポート層プロトコルＤＥ
ＣＮＥＴからＴＣＰ／ＩＰへ変更されても、アプリケー
ションプログラムの変更は不要である。上記のような変
更はプロトコルエンジンを追加、削除、また修正するこ
とにより、プロトコルが上記変更を許容できるようにす
ることが可能である。これらプロトコルエンジンは共用
できるので、全アプリケーションソフトを替えるより全
プロトコルエンジンを替える方が容易である。

【０１２２】プロトコルエンジンによりアプリケーショ
ンにはプロトコル透明性と通信路透明性が与えられ、し
たがってアプリケーションにてこれら詳細を扱うコード
を不要とする。また、これらのプロトコルエンジンによ
りネットワークインタフェースの透明性が与えらる。

【０１２３】プロトコルエンジンにより信頼性のある通
信プロトコルが実現でき、実施例のいくつかでは付加価
値のあるサービスを提供できる。付加価値のあるサービ
スとは、例えば、高信頼性放送や高信頼性二点間通信
や、また効率を維持するために状況により必要となれば
通信を高信頼性放送より高信頼性二点間通信に切り替え
られるような多重放送通信がある。更に、二つ以上のア
プリケーションがある主題に関するデータを要求する場
合で、要求状態にある第一のアプリケーションに向けら
れているデータを受信し、それをその他の要求状態にあ
るアプリケーションに向けるようなとき、プロトコルエ
ンジンは放送の操作性を高める。従来の放送用ソフトウ
ェアはこの能力に欠ける。

【０１２４】プロトコルエンジンによりネットワーク上
で受信されたメッセージを主題ごとにフィルタにかける
ことにより効率の良い主題に基づいたアドレス指定を実
現できる。この方法により要求された主題に関するデー
タのみが要求状態にあるアプリケーションのコールバッ
クルーチンに乗せられる。好ましい実施例としては、プ
ロデューサのアプリケーションかまたはサービス事例に
接続されたプロトコルエンジンにより、データを主題に
よりフィルタにかけた後にネットワークに転送される
と、通信リンクの受信側ではネットワークのバンド幅や
入出力プロセッサのバンド幅やオーバヘッド処理が節約
できる。

【０１２５】分散型通信コンポーネント２３２（以後Ｄ
ＣＣと呼称）は図１６にていくつかの重要な目的にかな
うように構成されている。第一に、ＤＣＣは単純で安定
性があり、均質な通信モデルを提供する。これにより、
いくつかのメリットが得られる。プログラマは分散型環
境を始めとして、目的処理の探索、この目的処理との通
信の達成、予想しなかった何かが発生した場合の原因の
追求といった煩雑さから逃れられる。これらの全てはプ
ログラマによってではなく有能な通信インフラストラク
チャにより最適に達成できる。第二に、ＤＣＣによりプ
ログラマの生産性を増すことはもとより、新規特性の統
合を単純化により開発に要する時間を短縮できる。最後
に、ＤＣＣによれば他のコンポーネントのネットワーク
上での物流を知るために果たされるアプリケーションに
対する負担を取り除くことにより、構成の自由度が大き
く高められる。このことは特定の物理構成にコードでの
プログラマによる依存性を無くし、したがって後に予想
される再構成を複雑化することも無くなる。

【０１２６】もう一つの重要な目的は、重要なシステム
構造のカプセル化により移植性を得ることである。顧客
アプリケーションが、変更されているかも知れないトラ
ンスポートとアクセスプロトコルから隔てられているた
め、新規ハードウェアやソフトウェア環境に移行する場
合はこの移植性が重要となる。システム（ＤＣＣ）の小
部分に必要とされる変更を分離することにより、アプリ
ケーションは実質的に変更せずに移植でき、したがっ
て、このアプリケーションソフトウェアに対する投資は
守られる。

【０１２７】ＴＣＰ／ＩＰやＯＳＩといった標準プロト
コルスーツでよりコストのかからない“非結合”トラン
スポートプロトコルによりコード化されているので、Ｄ
ＣＣは効率化を促進する。ＤＣＣはプロトコルでの最も
コストを必要とする問題、即ち、データ“コピー”操作
の拡散を防ぐような構成となっている。

【０１２８】ＤＣＣは販売側により供給される基本サー
ビスの上にサービスの層を実現してこれらの目的を達成
する。ＤＣＣによれば、信頼性のあるデータ転送やフロ
ー制御メカニズムのような基本機能を作り直さなくて
も、どのオペレーティングシステムの特異性からもアプ
リケーションは逃れられる。その例として、ＭＳ−ＤＯ
Ｓ環境でのハードウェア指向のインタフェースやＵＮＩ
Ｘのファイル記述子のプロセス当たりの限度がある。多
数のハードウェアやソフトウェア環境に簡単に移植でき
る一つの統一した通話料を提供することにより、ＤＣＣ
は上記目的を可能としている。

【０１２９】ＤＣＣは、サービス統制プロトコルが必要
とする種々の相互作用パラダイムや耐故障性についての
要求事項や性能上の要求事項をサポートするためいくつ
かの異なった送信プロトコルを実行している。より興味
があるプロトコルの二つは、高信頼性放送とインテリジ
ェント多重放送プロトコルである。

【０１３０】標準の放送プロトコルは信頼性が低く、メ
ッセージ喪失を検出することができない。ＤＣＣ高信頼
性放送プロトコルによれば、全操作ホストが各放送メッ
セージを受信するか、またはメッセージの喪失を検出で
きることが保証される。多数のいわゆる高信頼性放送プ
ロトコルと異なり、喪失したメッセージは限られた一定
周期で再送信される。

【０１３１】インテリジェント多重放送プロトコルは多
数の目的地に対して信頼性のあるデータストリームを提
供する。このプロトコルの新規性はネットワークとプロ
セッサ負荷を最適化するために二点間通信より放送通信
にダイナミックに切替え可能ということにある。二点間
通信より放送（またはその反対）への切替えは高次レベ
ルのプロトコルまで透過的である。このトランスポート
プロトコルにより、二点間通信のみ、または放送のみを
使用する場合より、より多数のユーザーをサポートでき
る。このプロトコルはＤＣＣにより他のプロトコルの上
に構築できる。現在のところ、全ＤＣＣプロトコルは、
例えばメッセージ（これは他の多くのプロトコルと対照
的であるが）のようなデータのみを、離散的な単位で交
換している。ＤＣＣは単一のプロセスに基づくメッセー
ジをその転送順で受信する。

【０１３２】ＤＣＣはまたメッセージ喪失が発生した場
合再転送をサポートするような耐故障性メッセージ転送
プロトコルを含む。ＤＣＣソフトウェアはメッセージ伝
達につき“多くて一度”のセマンティックスを保証し、
また“ちょうど一度”のセマンティックスを追求してい
る。

【０１３３】ＤＣＣはアプリケーションのプログラマに
より使用される目的でインタフェースを表示はしない。

【０１３４】離散型コンポーネント２３２はサービス統
制２３４、２３６、２３８に接続される。サービス統制
２３４はマーケットデータ加入サービスと呼ばれる機能
を有する。このプロトコルによりデータの消費者は、個
々のデータのソースの故障に関して耐故障性のあるデー
タの一連の流れを受信することができる。このプロトコ
ルスーツは負荷バランスと権利付与方針を管理する。Ｍ
ＤＳＳサービス統制は、このサービス統制をＲＭＤＰイ
ンタフェースで要求するアプリケーションが要求された
データを提供するのはそのサービスであるということを
知らなければならないという意味ではサービス指向であ
るといえる。ＭＤＳＳサービス統制はしかしながら、あ
る主題に関してのデータストリームがＭＤＳＳサービス
統制により接続されたアプリケーションに伝達されると
いう意味では、主題アドレス加入サービス（ＳＡＳＳ）
サービス統制によって実行される加入通信パラダイムを
サポートしている。

【０１３５】ＭＤＳＳサービス統制によりデータ消費者
アプリケーションは各データのソースの故障に対して耐
故障性のある一連のデータストリームを受信できる。こ
のプロトコルスーツ２３４はまた、負荷バランスと権利
付与方針の管理の為のメカニズムを提供する。すなわ
ち、ユーザーあるいはアプリケーションのアクセス特権
がデータ消費者が特定のサービスからデータを得る権利
を有することを保証するようにチェックされる。

【０１３６】二つの特性により、ＭＤＳＳサービス統制
は代表的な顧客サーバプロトコルと異なっている。第一
に、加入ははっきりとサポートされていて、したがって
要求の値に対する変更は自動的に要求状態にあるアプリ
ケーションに伝達される。第二に、顧客アプリケーショ
ンはある特定のサービスを要求するか加入する（これは
ある特定のサーバと反対であり、またある特定の主題と
も反対である）。そしてＭＤＳＳサービス統制は顧客ア
プリケーションの要求を利用可能なサーバに転送する。
ＭＤＳＳサービス統制はまたサーバの連結状態を監視
し、もし連結が故障すれば必要なら他のサーバを利用し
て再連結を行う。

【０１３７】ＭＤＳＳサービス統制は次に述べる重要な
目的を実行する。

【０１３８】耐故障性は、二重または三重のネットワー
クをサポートしかつ、プロトコルエンジンで実行された
高信頼性放送のような耐故障送信プロトコルを使用する
ことにより冗長サービスの間を自動切替するようなプロ
グラムコードにより実現できる。サーバの故障後の復帰
は自動で行われる。

【０１３９】負荷バランスはある特定のサービスのため
に稼働している全てのサーバを通じてデータ要求の負荷
がバランス良く配分されるようにして実行される。

【０１４０】負荷はあるサーバが故障したりまた故障よ
り復帰したりした場合は自動的に再度バランス調整され
る。更に、 ＭＤＳＳは、外部通信ライン上でのバンド
幅やページキャシュにある“スロット”のような少ない
資源を有効に利用するサーバ配分方針をサポートしてい
る。

【０１４１】ネットワーク効率化は図１５に示されてい
るように、分散型通信デーモン３０Ｂによるインテリジ
ェント多重放送プロトコルにより実行される。インテリ
ジェント多重放送は、必要なときには二点間通信プロト
コルから放送通信プロトコルへ自動的かつダイナミック
な切替えをすることにより、ネットワークと入出力プロ
セッサのバンド幅の資源を有効に利用している。例え
ば、テレレートページ８データは初めの五つの加入者に
二点間分配による供給がなされ、そして第六の加入者が
出てきたとき全加入者を放送分配に切り替えられる。Ｍ
ＤＳＳサービス統制によれば、サーバの探索、通信の接
続、故障にたいする対応、故障よりの回復、負荷バラン
スを含む、分散システムをプログラムする上での煩雑さ
の大半を封じるような簡単で使用し易いアプリケーショ
ン開発インタフェースを提供する。ＭＤＳＳサービス統
制のコアとなる機能は取得、停止、駆動である。顧客ア
プリケーションより“取得”呼出は指定されたサーバへ
の耐故障性のある連結を行い、指定ページか指定データ
要素の現在値を取得する。連結は、指定ページに対する
更新が自動的に顧客アプリケーションに転送されるよう
に加入に基づいたものである。“停止”は加入を停止す
る。“駆動”は加入を変更することができるかも知れな
いサービスに変更子を送信する。

【０１４２】ＭＤＳＳサービス統制はページ指向のサー
ビスをサポートするように最適化されてはいるが、どの
ようなタイプのデータの分配をもサポート可能である。

【０１４３】ＭＳＡ２３６で示されているサービス統制
は異なった機能を有する。ＳＡＳＳ２３８で示されてい
るサービス統制は主題に基づいたアドレス加入サービス
をサポートする。

【０１４４】主題に基づいたアドレス指定とＳＡＳＳサ
ービス統制（以後ＳＡＳＳ）によりそれを実行する背後
にある基本思想は明快である。アプリケーションがデー
タを要求しているときはいつでも、特にダイナミックに
変動している値に関するデータの場合は、アプリケーシ
ョンは適切な主題を指定することによりそれに加入す
る。ＳＡＳＳはこの主題に関する情報を提供するような
一つ以上のサービス事例に対する要求をマップ化する。
ＳＡＳＳは、選択されたサービスを提供するサービサー
かまたはサーバとの通信に必要とされる適切な一つ以上
のプロトコルエンジンによって、全ての選択されたサー
ビスへの適切なる連結を可能とする。

【０１４５】主題に基づいたアドレス指定をすることに
より、情報の消費者は、情報を作成しているアプリケー
ションとは無関係にな方法で情報を要求できる。したが
って、情報を作成しているアプリケーションが改訂され
たりまたは新しいアプリケーションと取り替えられたり
しても、情報消費者に不都合を起こさないようにして同
じ情報を提供し得る。

【０１４６】主題に基づいたアドレス指定は分散型アプ
リケーションをプログラムする場合の煩雑さを次の三点
において大幅に軽減する。第一に、アプリケーションは
主題により情報を要求するが、これはサーバあるいはサ
ービスにより要求する方法と対照的である。この高次の
レベルで情報を指定すると、希望情報を提供するサービ
ス事例の現ネットワークアドレスを知る必要があるとい
うアプリケーションに果たされた負荷が取り除かれる。
更に、適切なサービスよりデータを抽出する為の通信プ
ロトコルの詳細を知る必要があるということと、ネット
ワークを横断して連絡するトランスポートプロトコルの
詳細を知る必要があるということによるアプリケーショ
ンにかかった負荷が軽減される。例えば、公平価格のた
め、ＩＤＮからＴｉｃｋｅｒ ３ へ変更するといっ
た、サービス提供者側における変更が生じたとき、顧客
アプリケーションがプログラム上の変更をする必要性が
なくなる。全データは顧客アプリケーションへ単一かつ
一様なインタフェースにより提供される。三つの異なっ
たサービスからの情報を必要とする顧客アプリケーショ
ンを作成するプログラマは従来の通信モデルにおけるよ
うに三様のサービス通信プロトコルを知る必要はない。
最後に、ＳＡＳＳは適切なサービス事例検索や正しい通
信連結といった困難かつ間違い易い手順の多くを自動化
する。

【０１４７】ＳＡＳＳサービス統制は、ユーザーインタ
フェースにより呼び出される三つの基本機能を提供す
る。

【０１４８】“加入”は一つ以上の主題につきリアルタ
イムで消費者が情報を要求したとき、呼び出される機能
である。ＳＡＳＳサービス統制は提示された主題に合致
する全データが消費者アプリケーションに確かに転送さ
れるように必要とあれば如何なる通信リンクをも組み立
てる。データが非同期式（割込み作動）か同期式かを消
費者は指定できる。

【０１４９】プロデューサ側のサービスへは、そのサー
ビスの登録手順が設定完了時点で、加入が連絡される。
登録手順はＳＡＳＳによりなされ、ユーザーには見えな
い。“取消”は“加入”の反対である。この機能が呼び
出されると、ＳＡＳＳは専用通信チャンネルを閉鎖し、
もし登録状態が存在すればプロデューサ側のサービスへ
取消を連絡する。

【０１５０】“受信”機能と“コールバック”機能は、
それにより加入者要望の情報に合致するメッセージをア
プリケーションが受信できるような機能に関連する。コ
ールバックは非同期式であり、イベント作動のプログラ
ム方式をサポートしている。この方式はリアルタイムで
のデータ交換を必要とするアプリケーションに適してい
る。受信機能はメッセージ受信用の従来の同期式インタ
フェースをサポートしている。

【０１５１】データ作成者用に補足機能が備わってい
る。また、アプリケーションはデータの作成者であり同
時にデータの消費者でも有り得る。

【０１５２】図１７では本発明の基づく考えが有益に取
り入れられている、代表的なコンピュータネットワーク
が示されている。このコンピュータネットワークはロー
カルエリアネットワーク（以後ＬＡＮ）３０２によりフ
ァイルサーバ３０４に接続されているヒューストンの第
一ホストＣＰＵ３００とゲートウェイネットワーク相互
接続回路３０６を含む。ゲートウェイ回路３０６はＬＡ
Ｎ３０２を広域ネットワーク（以後ＷＡＮ）３０８に接
続している。ＷＡＮ３０８はホスト３００を、ロンドン
からのＱｕｏｔｒｏｎサービスとパリからのＭａｒｋｅ
ｔｆｅｅｄ ２０００サービスをそれぞれ提供する二つ
のサーバ３１０と３１２に接続している。ＷＡＮはまた
ホスト３００をジュネーブにある第二のホストＣＰＵ３
１４に接続し、ジュネーブのサーバ３１６は第二のＬＡ
Ｎ３１８によりテレレートサービスを提供している。ダ
ムターミナル３２０もまたＬＡＮ３１８へ接続されてい
る。

【０１５３】一般にはホスト３００と３１４はマルチタ
スクのマシンであるが、またＤＯＳやＰＣ−ＤＯＳのオ
ペレーティングシステムを走らせることのできるコンピ
ュータのような単一処理ＣＰＵでもある。ＴＩＢ通信イ
ンタフェースソフトウェアはＵＮＩＸに準拠したマルチ
タスクマシン用にポートが構成されている。

【０１５４】本発明に基づく考えをＤＯＳかまたは他の
シングルタスク環境に適応させるためには、処理アーキ
テクチャのＴＩＢ通信デーモン３０Ｂは、オペレーティ
ングシステムからアプリケーションの一つが加入してい
る主題に関連するネットワーク上でメッセージが受信さ
れたという連絡を受信すると直ちに呼び出される、すな
わち、開始されるような割込み作動処理が可能なように
構成されていることを必要とする。

【０１５５】システムの残りの構成要素との間でデータ
を交換できるに十分な互換性を有する場合に限り、ＬＡ
Ｎ３０２、３１８、ＷＡＮ３０８，ゲートウェイ３０６
のおのおのはどの従来の構造とプロトコルを有していて
も良いし、将来開発される新たな構造とプロトコルを有
していてもよい。ネットワークに使用される構造とプロ
トコルの代表的な例としてはＴＣＰ／ＩＰ、ＤＥＣＮＥ
Ｔ、ＥＴＨＥＲＮＥＴ、トークンリング、ＡＲＰＡＮＥ
Ｔと他のディジタルパックまたはいずれか一方、または
ハードワイヤかマイク波か衛星送信メディアを使用した
高速プライベートラインのディジタルシステムかアナロ
グシステムがある。Ｘ．１、Ｘ．２、Ｘ．３、Ｘ．２
０、Ｘ．２１、Ｘ．２４、Ｘ．２８、Ｘ．２９、Ｘ．２
５、Ｘ．７５などの種々のＣＣＩＴＴの勧告はスピー
ド、ユーザーのオプション、種々のインタフェーススタ
ンダード、スタート／ストップモードターミナルハンド
リング、同期ターミナル用のマルチプレックスインタフ
ェース、インタフェース回路の定義、パッケットネット
ワークの相互接続を提案していて、これら全ては参考の
ためここに添付されている。コンピュータネットワーク
アーキテクチャとプロトコルの詳細な説明は特別号ＩＥ
ＥＥ通信に関するトランザクション、１９８０年４月Ｖ
ｏｌ．ＣＯＭ−２８にあり、参考のためにここに添付さ
れている。大半のディジタルデータ通信は一文字当たり
ビットの数とそのビットのシーケンスと表現される文字
によりなされ、０のシーケンスと１のシーケンスはコー
ドを定義している各文字に対応する。最も、一般的なコ
ードはＵ．Ｓ．ＡＳＣＩＩとして知られる国際アルファ
ベットＮｏ．５である。他のコードもまた使用可能であ
る。コードのタイプは本発明にとっては重要ではない。

【０１５６】コードの転送にて、受信点と送信点間の同
期を維持するために一般に使用されている二つの方法が
ある。スタート／ストップ転送にては文字と文字との間
隔は常に１の信号であり、信号０のビットの送信は受信
ターミナルへ文字がスタートしたことを合図することに
なる。データビットはスタートビットに続き、さらにそ
の後にストップビットが続く。ストップパルスは文字と
文字の間の信号と同じであり、ターミナルの仕様に基づ
く最短のパルス長となる。同期式ではタイミングを保持
するために、文字が転送されない間隔でも同期アイドル
パターンで一様のレートでビットは送り出される。同期
式は高速度送信に利用される。

【０１５７】ディジタルコンピュータネットワーク通信
でプロトコルという用語は通信を作動するための標準的
な手順を意味する。目的は装置と通信チャンネルの端末
でのインタフェースの処理を統合することにある。プロ
トコルはいくつかのレベルで適用できると思われる。国
際標準化機構（ＩＳＯ）は標準プロトコルの開発の指針
となる七つのレベルを有するオープンシステム相互接続
の参考モデルを開発した。この７レベルの標準は以後Ｉ
ＳＯモデルと呼称され、その機能を次に示す。 （１）アプリケーション： アプリケーション間
の通信ができなければならない。プロトコルはエンドユ
ーザーのニーズを満たすこと。

【０１５８】（２）プレゼンテーション： アプリ
ケーションプログラムにより使用できるように適切な形
に構成されたデータを提示できること。アプリケーショ
ン層が交換のデータの意味が解釈可能なように、アプリ
ケーション層により選択できる複数のサービスが提供さ
れること。

【０１５９】（３）セション： プレゼ
ンテーション項目と制御データ交換、すなわちダイアロ
グ制御の間の関係を確立し設定する。

【０１６０】（４）トランスポート： ネット
ワークより独立した透過性のあるデータ転送を提供す
る。信頼性があり費用有効性のあるデータ転送が達成さ
れるような細分化された方法へセション層が係わる必要
をなくする。

【０１６１】（５）ネットワーク： ネット
ワークより独立したルーチンとスイッチングサービスを
提供する。

【０１６２】（６）データリンク： ネット
ワーク間でデータリンクを構成したり、維持したり、解
除したりするための機能的かつ手順的な手段を提供する
ことによりリンク上にて故障なしのデータ転送を可能と
すること。

【０１６３】（７）物理的項目： データ
リンク間のデータ回路のような物理的な接続を構成した
り、維持したり、解除したりするための機械的、電気
的、機能的、手順的特性を示す。

【０１６４】従来より最も一般的なあるデータリンクプ
ロトコルはデータに交換をするために文字か文字の組合
せを使用する。また、ＡＮＳＩのＡｄｖａｎｃｅｄ Ｄ
ａｔａ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｏｎｔｒｏｌ
Ｐｒｏｃｅｄｕｒｅとその部分集合などの他のプロト
コルはリンク制御をするためにメッセージの予め決めら
れた位置にビットのシーケンスを用いている。

【０１６５】パケットネットワークは６０年代半ばの回
路スイッチやメッセージスイッチデータネットワークで
一般的であったよりももっと効率的なネットワーク装置
の使用を促すために開発された。回路スイッチネットワ
ークでは一つのチャンネルはコールの間はずっと割り当
てられた。メッセージスイッチネットワークではメッセ
ージかあるいはシリアルメッセージの一部分は、もし通
信路（ループかトランク）が利用可能なら、次のスイッ
チに送信された。もしそうでなければ、メッセージは通
信路が空くまで記憶された。メッセージスイッチ間のト
ランクの使用は時として非常に効率を向上させた。多数
の回路スイッチのアプリケーションではしかし、回路が
使用されている時間のほんの一部のみの期間しかデータ
は送信されなかった。装置の有効利用を目的とし、また
そのほかの理由にもより、パケットネットワークが出現
した。

【０１６６】パケットネットワークではホストやターミ
ナルから他のホストやターミナルへのメッセージはある
特定の長さ、普通１２８バイト、のパケットに分割され
る。これらパケットは発信点より目的地点に個別に送信
される。各パケットは、そのパケットを処理するのに必
要な情報をネットワークへ提供するヘッダを含む。一般
的には、パケットは少なくともソースと目的地のネット
ワークのアドレスを含み、パケット長といったその他の
データフィールドを含むこともある。一つのソースのア
イドル時間が他のソースに利用できるように、一ターミ
ナルから他のターミナルへ発信されたパケットは、他の
ユーザーにより彼らの目的地へ発信されたパケット間に
装置上にて交互配置される。種々のネットワークコンテ
ンション解決プロトコルが、同じ時、同じチャンネル上
でパケットを送信しようとする二つ以上の目的地を持つ
ネットワークの制御を仲裁するためにある。あるプロト
コルは物理的に多重チャンネルを時分割か周波数マルチ
プレックスにより使用している。

【０１６７】論理チャンネルの使用により同じ物理的な
インタフェース回路が二つ以上のターミナルまたはコン
ピュータとともに動作させられる。あるどの瞬間をでみ
ても、各論理チャンネルはある受信アドレスとの通信に
使用されている；各パケットはそのヘッダ内に論理チャ
ンネルの識別項を含み、物理的なインターフェース回路
上で種々の論理チャンネルの種々のパケットが交互配置
されている。

【０１６８】目的地ではメッセージは受信アドレス処理
にかけられる前に再構成されフォーマット化される。一
般に、ネットワークはその内部にデータの動きを制御す
るための内部プロトコルを有する。

【０１６９】ネットワークの内部スピードは一般に、ネ
ットワークに接続されているどのターミナルやノードの
スピードよりも早い。

【０１７０】メッセージを扱う一般によく使用されてい
る方法が三つある。“データグラム”は発信元から目的
地へ発信される片方向メッセージである。データグラム
は独立して転送され、必ずしも発信順には着信しない。
転送か非転送かの通知もされ得る。“バーチャルコー
ル”ではパケットはネットワークの二人のユーザーで交
換される；目的地ではパケットは発信された順番に受信
アドレスプロセスにかけられる。“相手固定接続”は一
つのネットワーク上で二人のユーザー間のパケットの交
換をする。各ユーザーは、ネットワークの提供者の準備
により、論理チャンネルを割当て、相手ユーザーとパケ
ットの交換を行う。チャンネルの構成や清掃などは不要
である。

【０１７１】ある種のパケットネットワークは、ネット
ワークに含まれるパケットアセンブラとパケット逆アセ
ンブラによりパケット内のメッセージをフォーマット化
する内部機能を有さないターミナルをサポートする。

【０１７２】米国における初期のパケットネットワーク
はＡＲＰＮＥＴで、多数の大学や政府研究機関でターミ
ナルとホストコンピュータを接続するために組み上げら
れた。その目的は一つの場所でのコンピュータユーザー
がその他の場所にあり、またたいてい異なったメーカー
のコンピュータにあるデータやプログラムを使用するこ
とにあった。ネットワークへのアクセスは、各場所にあ
り、ホストコンピュータに接続されているインタフェー
スメッセージプロセッサ（ＩＭＰ）と他の場所にあるＩ
ＭＰを使用することによりできる。ＩＭＰは相手のＩＭ
Ｐへは直接は接続されていない。発信ＩＭＰに直接接続
されていない目的ＩＭＰに配信されるパケットは目的処
理に到達するまで中間ＩＭＰで扱われる。ホストが存在
しない場所ではダムターミナルにアクセスをするためタ
ーミナルインタフェースプロセッサが使用される。

【０１７３】他のあるパケットネットワークは世界的に
構築されていて、たいていバーチャルコールモードで作
動している。

【０１７４】初期のパケットネットワークでは、メッセ
ージの各パケットのルーティングは独立である。各パケ
ットは目的地のネットワークアドレスと目的地にて適切
な順序でパケットを配置できるように順序番号をヘッダ
に含む。もっと新しく開発されたネットワークは“仮想
回線”構造と“仮想回線”プロトコルを使用している。
仮想回線はデータの発信初めに設定され、そのデータ発
信の全てのパケットにつきルーティング情報を含む。次
に続くパケットは仮想回線の表示をそのヘッダに含む。
あるネットワークでは、ルートの選択はネットワーク上
での全てのノードよりまた全てのノードへの遅延を測定
した結果に基づいている。

【０１７５】また、ほかのネットワークの構造におい
て、ネットワーク上のノードは他のあるノードまたは他
の全てのノードにたいして、二重または三重の冗長なル
ートで接続されている。Ｄｉａｌｏｇ、Ｔｙｍｓｈａｒ
ｅ、Ｔｅｌｅｎｅｔといったネットワークでは相互接続
には公衆電話システムが使用され、アナログの通信チャ
ンネルとディジタルデータをアナログデータに変換する
ためのモデムが使用されている。

【０１７６】ＷＡＮのような他のネットワーク構造で
は、マイクロ波と長距離通信のための地上局に接続され
た衛星の両者またはいずれか一方、ローカルエリアネッ
トワークかローカル着信のための公衆電話システムが利
用されている。

【０１７７】種々のネットワークの構造とプロトコルが
使用されている。更に、ネットワークとトランスポート
プロトコル、ネットワークインタフェースカード、ネッ
トワーク構造、ホストコンピュータとターミナル、サー
バプロトコルとトランスポート／ネットワーク層ソフト
ウェアの新たなデザインが次々に出現している。これは
ネットワークの設計と操作において不変であるべきこと
が絶えず変わっているということを意味する。指定した
タイプのデータが得られるネットワークのアドレスやこ
のデータを得るためのアクセスプロトコルは絶えず変わ
っている。本発明の通信インタフェースソフトウェアの
目的はアプリケーションプログラムを作成するプログラ
マが全ネットワーク、トランスポートプロトコル、ネッ
トワークアドレス、アクセスプロトコルおよび特定の主
題に関するデータを提供しているサービスの知識を修得
する必要性をなくしている。本発明のインタフェースソ
フトウェアにより変わり行く煩雑さを全てカプセル化し
モジュール化することによって、アプリケーションプロ
グラムへの投資が、ネットワークトポロジーやプロトコ
ル依存性がアプリケーションにプログラムされないよう
にすることで、保護している。このようにして、ネット
ワークに何か変更があっても、再プログラムしたり、ま
た全プログラムを廃棄したりする必要がなくなる。

【０１７８】これら目的は本発明の教えるところに従っ
て、三層構造のアーキテクチャ（以後ＴＩＢソフトウェ
アと呼称）を有するネットワーク通信ソフトウェアによ
り実現できる。図１７に示されるように、これら三層は
情報層、サービス層、分散型通信層である。各アプリケ
ーションプログラムはコンパイルリンク処理の間に情報
層とサービス層の自身のコピーにリンクされる。コンパ
イルリンク処理はアプリケーションプログラムのソース
コードを機械可読オブジェクトコードに変換する動作で
ある。例えば、アプリケーションプログラム１、３４０
は本発明のソフトウェアの層の自身のコピーへ直接リン
クされ、すなわち、情報層３４２とサービス層３４４へ
である。同様に、アプリケーション２、３４６はそれ自
身のコピーである情報層３４８とサービス層３５０へリ
ンクされる。この二つのアプリケーションは分散型通信
層３５２と呼ばれる本発明のソフトウェアの第三層を共
有する。一般的には、マルチタスクマシンで同時に複数
のアプリケーションを走らせるが、非マルチタスク環境
では割込みドライバとして作動するノードにつきただ一
つの分散型通信層しかない（ここでノードはネットワー
クに接続されているどんなコンピュータ、ターミナル、
サーバであっても良い）。

【０１７９】図１７の仮想ネットワークにおけるジュネ
ーブの第二のホスト３１４はアプリケーションプログラ
ム３、３５４を走らせている。このアプリケーションは
そのコピーである情報層３５６とサービス層３５８へリ
ンクされる。ホスト２で同時に走っている分散型通信層
３６０はアプリケーション３５４により使用されてい
る。サーバ３１０、３１２、３１６の各々は三層ＴＩＢ
ソフトウェアのデータ作成バージョンを有している。
“加入”機能を実行するＴＩＢソフトウェアのデータ消
費者バージョンと“発行”機能を実行するデータ作成バ
ージョンがある。一つの処理（実行中のプログラムがＵ
ＮＩＸ定義によるとき）がデータ消費とデータ発行の場
合は、それはプログラムのライブラリと、加入と発行機
能の両方を実行するＴＩＢソフトウェアのためのインタ
フェース仕様を有している。ホストの３００と３１４は
それぞれオペレーティングシステム３７０と３７２によ
り制御され、これらは異なっている。ホスト１とホスト
２は、サーバ３１０、３１２、３１６がそうであるよう
に、異なったメーカーのコンピュータでも良い。ホスト
１は共有メモリ３７４を有し、それによりアプリケーシ
ョン３４０と３４６は例えばＵＮＩＸパイプや他のプロ
セス間転送機構により通信できる。

【０１８０】本発明による考えを広義に解釈すれば、３
４２のような情報層はＴＩＢＮＦＯインタフェース機能
や図１５や図１６にあるＴＩＢソフトウェア通信ライブ
ラリ３０Ａの主題に基づくアドレス機能をカプセル化し
ている。ＴＩＢＩＮＦＯインタフェースは下記ソフトウ
ェア仕様のセクション４にて定義される。ＴＩＢＩＮＦ
Ｏはプログラムインタフェースを定義していて、そのイ
ンタフェースによりこの情報層にリンクされたアプリケ
ーションが主題アドレス加入サービス（ＳＡＳＳ）コン
ポーネントのプロトコルとサービスを呼び出す。

【０１８１】図１８は図１５の処理アーキテクチャ、図
１６のソフトウェアアーキテクチャ、図１７におけるＴ
ＩＢソフトウェアの三層構造の相互関係を示す。図１５
で通信ライブラリ３０Ａはアプリケーションライブラリ
１６にリンクされていて、アプリケーションライブラリ
１６はＲＭＤＰとＴＩＢＩＮＦＯインタフェースにより
呼び出される多重機能を提供している。主題アドレス加
入サービスはコンポーネント内で３０Ａと３０Ｂとして
示されている主題マッププログラムとサービス統制プロ
グラムにより提供される。このコンポーネント３０Ａ／
３０Ｂはまたライブラリプログラムを含み、そのライブ
ラリプログラムはＴＩＢ通信デーモン３０Ｂのプロトコ
ルエンジンプログラムをサポートすなわち、それと通信
し、それにデータを供給するような共通のインフラスト
ラクチャプログラムコードを提供する。

【０１８２】ＴＩＢＩＮＦＯインタフェースはプログラ
ムインタフェースを提供するようになっていて、そのプ
ログラムインタフェースによりリンクされた顧客アプリ
ケーションはネットワーク上でデータ作成者により提供
されたデータを求めて、そのデータがあればどこでも、
主題アドレス加入を起動し、使用する。

【０１８３】ＲＭＤＰインタフェースはプログラムイン
タフェースを提供し、そのプログラムインタフェースに
より加入が入力され、データがネットワーク上のサービ
スからリンクされた顧客アプリケーションにより受信さ
れる。このとき、顧客アプリケーションにとりこのデー
タを提供するサービスの名称は既知である。図１５の通
信ライブラリ３０Ａはライブラリプログラムを支給する
が、そのライブラリプログラムはマーケットデータ加入
サービス（ＭＤＳＳ）を実行するためにリンクされた顧
客アプリケーションにより呼び出される。この機能は、
デーモンの適当なプロトコルエンジンの支援により、要
求データを供給する一つ以上のサーバへの高信頼性通信
チャンネルを設定し、サービス名称で要求された加入デ
ータを作成する。各サーバの故障は顧客には分からな
い。ＭＤＳＳは、適当なプロトコルエンジンを用いて同
様なサービスを提供する新たなサーバに自動的に切り替
えられるからである。ＭＤＳＳはまた自動的にサーバ間
のバランスを調整し、誰がサービスにたいするアクセス
を得るかを制御する許可機能を実行する。インテリジェ
ント多重放送や高信頼性放送やデーモン３０Ｂのプロト
コルエンジンといったＤＣＣライブラリ３０Ａ／３０Ｂ
の高信頼性通信プロトコルはＭＤＳＳライブラリプログ
ラムにより呼び出される。更に詳しいことはＴＩＢ仕様
のセクション３に述べられている。

【０１８４】ある特定の主題に関する加入を実行し、そ
の主題にたいするデータを受信するために、加入処理側
での三層の各々で実行される処理のフローチャートは図
１９と図２０により示される。ステップ４００はある特
定の主題に関するデータを求めるユーザーよりの要求を
受信する処理を示している。この要求は他の処理から、
または他のマシンより来ても良いし、あるいはいくつか
の実施例のオペレーティングシステムより来ても良い。
この例で目的に従い、要求はユーザーより図１７におけ
るアプリケーション１に来ているとしている。

【０１８５】アプリケーション１（アプリケーション層
上でまたはＩＳＯモデルの層１上で）は図１７で情報層
３４２へ“加入要求”を発信する。この処理は図１９で
ステップ４０２で示される。この加入要求は、ＴＩＢ−
ＩＮＦＯインタフェースを含むリンクされているライブ
ラリプログラム内の適当なライブラリプログラムを呼び
出すことによって、入力される。このサブルーチンの呼
出は、データが要求されている主題とポインタを、主題
に関するメッセージが受信されたとき情報層のＴＩＢ−
ＩＮＦＯライブラリプログラムが呼び出される要求処理
におけるコールバックルーチンに転送する。

【０１８６】情報層３４２は主題対サービス統制マップ
機能をカプセル化し、このマップ機能は要求処理とアー
キテクチャ上で切り離し機能を実行する。なお、この用
語は用語集で定義されている。図１９のステップ４０４
と４０６と図１７を参照すると、情報層にたいする入力
は主題であり、出力は図１７でサービス層３４４上のサ
ービス統制に対する呼出である。情報層はＴＩＢ−ＩＮ
ＦＯインタフェースと、主題対サービスマップに関連す
る図１５におけるリンクされている通信ライブラリ３０
Ａの全ライブラリを含む。情報層はステップ４０４で示
されているように主題に関するデータを提供するサービ
スへの主題をマップ化し、これらサービスと通信する通
信プロトコルをカプセル化している一つ以上のサービス
統制に対するサービスをマップ化する。この情報層はサ
ービス統制と共同して、ステップ４１０で示されるよう
に“ＴＩＢチャンネル”を割り当てる。

【０１８７】“ＴＩＢチャンネル”は手紙の宛名での
“ａｔｔｅｎｔｉｏｎ：Ｆｒａｎｋ Ｊｏｎｅｓ”とい
ったようなものである。このＴＩＢチャンネルデータ
は、そのＴＩＢチャンネルにいかなる主題が割り当てら
れていようと、その主題に関するデータを要求した処理
へメッセージを転送する。各主題には加入が入力された
ときＴＩＢチャンネルが割り当てられる。加入処理、そ
のネットワークアドレス、加入割当される主題、これら
主題に割り当てられるＴＩＢチャンネルナンバーとの相
互関連を示す加入リストがある。このリストのデータは
デーモンにより使用されて、そのデーモンのポートアド
レスにて受信されたメッセージを適当な要求処理に転送
する。このリストはまたデータ発行者側でも使用されて
いて、要求処理が走っているマシンのポートアドレス
に、特定の主題が転送されるようになっている。サービ
スに関連するＴＩＢソフトウェアの通信層は特定の主題
に関するメッセージのパケットのヘッダにチャンネルナ
ンバーデータを、これらパケットがネットワーク上に発
信されない内に、書き込む。受信側ではヘッダのＴＩＢ
チャンネルデータはそのパケットの要求処理に適切に転
送されるように利用される。ＴＩＢチャンネル抽出とそ
れが示すルート機能は図１８のＤＣＣライブラリ部３０
Ａ／３０Ｂにより実行され、このＤＣＣライブラリ部は
各要求処理にリンクされている。

【０１８８】そのようなサービスが二つあるとすると、
これらサービスはサービス層のサービス統制によりサー
バへマップ化され、それらサーバがステップ４１２で示
されるようにこれらサービスを提供する。

【０１８９】一実施例では情報層はステップ４０６で示
されるようにサービス層のサービス統制サブルーチンの
一つのみを選択し呼出す。サービス統制はステップ４０
８で示されるように加入主題に対してＴＩＢチャンネル
を走らせ割り当てる。主題に関するメッセージが到着し
たとき呼び出されるように、情報層からの呼出はまた情
報層のコールバックルーチンへポインタを転送する。

【０１９０】これに替わる実施例では、情報層は全サー
ビスとの通信リンクを設定するため、主題対サービス統
制マップ処理で明示された全てのサービス統制を呼び出
すこともできる。

【０１９１】いくつかの実施例では、代替サービスと代
替サーバの名称が選別されたサービス統制かまたは情報
層により直接分散型通信層に転送されて、代替通信リン
ク設定用に利用される。これにより、選択したサーバが
故障した場合やネットワークの処理能力を増すために同
時通信リンク設定をしたい場合、分散型通信層は他のサ
ーバへの代替通信リンクを設定できる。またこれらの実
施例では、要求処理はサービス層を直接呼び出せるし、
アプリケーションそれ自体にある主題対サービス統制マ
ップを実行することにより適当なサービス統制を呼び出
すことができる。代替サービスと代替サーバについての
データは図１８のブロック３０Ａ／３０ＢのＤＣＣライ
ブラリのライブラリサブルーチンを呼び出して転送でき
る。ＤＣＣライブラリは代替についてのデータを走らせ
たり、記憶したりする。

【０１９２】上記に替わる実施例では、情報層はＴＩＢ
チャンネルを各主題に割り当てるか、またはサービス層
が、情報層との連携なしに単独で動作して、ＴＩＢチャ
ンネルを割り当ている。ステップ４１０は、サービス統
制が情報層と共同してＴＩＢチャンネルナンバーを割り
当てているような実施例を示す。データ提供者処理によ
り発信されたメッセージは、メッセージヘッダ情報の部
分として含まれる割当られた主題チャンネルデータを有
する。

【０１９３】ＴＩＢチャンネルは目的をフィルタで選別
し、転送するため通信層（ＤＣＣ）により使用される。
即ち、図１５のデーモン３０Ｂと図１８のプロトコルエ
ンジン３０Ｂは、主題のデータの加入があるようなヘッ
ダにて特定のＴＩＢチャンネルデータを有するデーモン
のポートアドレスにメッセージがいつ到着するかを知っ
ている。デーモン処理は加入があるチャンネルを知って
いる。理由はこの情報がサービス層により通信層に発信
されるからである。デーモン３０Ｂはオープンとなって
いる加入を有している全ＴＩＢチャンネルに関して、サ
ービス統制より受信したデータを記憶する。デーモンは
オープン加入を有する主題に関してのどんなメッセージ
をも、その主題に関してメッセージを加入させているポ
ートアドレスの処理に送る。デーモンは主題が何かは知
らないが、オープン加入を有するＴＩＢチャンネルと入
力メッセージの主題間に整合があるということは知って
いる。

【０１９４】ホスト３００のような図１７のコンピュー
タネットワークに連結された各ノードは一つのネットワ
ークインタフェースカードと一つのポートアドレスを有
する。このポートアドレスには、同じホスト上で同時に
走る多重処理によりネットワークカードを多重化するた
め、あるネットワークでは“論理チャンネル”が割り当
てられている。これらポートアドレスも以後時にはネッ
トワークアドレスとして引用される。データがネットワ
ークアドレス間をどのように行き来するかは図１７にお
ける層３５２のような通信層の責任となり、このような
通信層はオペレーティングシステム３７０と３７２に関
するトランスポート層、ネットワーク層、データリンク
層、物理層の機能を呼出し、またネットワークインタフ
ェースカード（図不指示）やゲートウェイ３０６やＷＡ
Ｎ３０８にみられるようなネットワーク自身上にある他
の回路を呼出す。

【０１９５】サービス層、情報層、通信層はＩＳＯモデ
ル層の上部におかれていて、すなわち、これらはＩＳＯ
モデルの層ではなしえないサービスを提供するか、また
はＩＳＯモデル層で実行されるサービスを補完するよう
な“付加価値”のあるサービスを提供する。

【０１９６】サービス層の目的は、この他にもあるが、
添付用語集で定義されているようにサービス切り離し機
能にある。サービス切り離し機能はサービスと通信を如
何にするかに関する詳細を提供してサーバのネットワー
クに関する所在をアプリケーションが知る必要性を無く
している。この機能を実行するには、サービス層は全サ
ーバに対する選択されたサービスをマップ化するプログ
ラムか機能を含み、これら全サーバはこのサービスを提
供し、それ選択する（図１９でステップ４１２）もので
ある。サービス層はそしてネットワークを横断するため
に必要な通信手順とプロトコルをカプセル化するプロト
コルエンジンに対して選択されたサーバをマップ化す
る。ネットワークを横断するとはすなわち、ネットワー
ク上でこのサーバに達するためには通過する必要がある
経路ということを考慮せず一つのデータリンクを設定
し、どのタイプのマシンかを考慮せず、どのタイプのネ
ットワークか、どのタイプのネットワークカードに接続
されているか、そしてどのタイプのオペレーティングシ
ステムが走っているかに関係なく選択されたサーバと通
信する。この処理はステップ４１４で示される。

【０１９７】代替実施例では、アプリケーションか加入
処理はそれ自身の主題に基づくアドレス指定を行い、そ
れ自身の通信プロトコルをカプセル化することによって
プロトコルエンジンを直接呼び出せる。他の代替実施例
では、ネットワークの処理能力を増すためか、あるいは
選択したサーバの故障の折りには他にすぐ切替えできる
ようにする為に、サービスを提供している全サーバを選
択し、通信層に同時にこれら全てとデータリンクを設定
するように要求する。

【０１９８】通常は選択されたサービスを提供する全サ
ービスは同一の通信プロトコルを使用していると思われ
るので、単一のサービス統制はそれら全てと通信可能で
ある。しかし同じサービスに関する異なった事例や同じ
主題に関するデータを提供している異なったサービスが
異なった通信プロトコルを使用していれば、本発明の教
えるところにより、サービス統制のサブクラスを指向す
る。この意味するところは、汎用の機能を実行するこの
サービス統制の全サブクラスにより共有され得るコード
を含む汎用サービス統制を情報層は呼出す；汎用機能と
は例えばこのサービスを提供する全サーバで同様になさ
れる加入や取消である。汎用サービス統制はサービスを
提供する異なったサーバの一つ以上に対する加入要求を
マップ化する。選択されたサーバに特有な通信手順をカ
プセル化しているサービス統制は、選択されたサーバに
加入データストリームの設定処理を完了させるため、呼
出を受け、実行される。

【０１９９】サービス層の出力は“次の主題のチャンネ
ル上で次のサーバかサービスにとり最も適当であると考
えられるどんな手段によっても通信リンクを形成する”
という意味で、通信層に対する要求である。サービス層
はまた要求主題に関するメッセージやパケットを取り扱
うサービス層コールバックルーチンへポインタを発信す
る。この処理はステップ４１６で示される。いくつかの
実施例では、要求主題に関するデータを供給しているサ
ービス処理を実行する全サーバのネットワークのアドレ
スはＤＣＣライブラリプログラムに転送され、そこで、
選択されたサーバが暴走した場合に故障からの復帰を可
能とする高信頼性通信リンクで使用できるように記憶さ
れる。

【０２００】ステップ４１８はオペレーティングシステ
ムにカプセル化されたトランスポート層プロトコルの選
択された機能を呼び出すことにより選択されたプロトコ
ルエンジンが要求データを設定するような処理を示す。
これらプロトコルは、ステップ４２０で示されるように
要求データリンクを設定し、サービスに記録するため
に、ネットワーク上で、データリンク上で、また物理層
上で他の通信プロトコルを呼び出す。サービス層サービ
ス統制は通常、サービスにメッセージを送って、ステッ
プ４２２にあるようにサービスに対して、加入とこの主
題に割り当てられた主題チャンネルを連絡する。主題チ
ャンネルは情報サービスとサービスにリンクされている
ＴＩＢソフトウェアの通信層の両者かまたはいずれか一
方により認識される。このことにより、主題チャンネル
データは対象とする主題に関する発信パケットのパケッ
トヘッダに付加される。いくつかの実施例では、この加
入メッセージがデータフローを起動されるが、他の実施
例ではサーバに対するデータリンクが最初にできた時に
データフローは起動される。

【０２０１】いくつかの実施例においては、単一の加入
によって多重サービスを呼出すことが必要となる場合も
あり、それにより情報層がその主題を多重サービス統制
に対してマッピングできるようにする。続いて、多重サ
ービスはその要求を多重プロトコルエンジンにマッピン
グし、多重プロトコルエンジンは同時に多重化サービス
へのデータリンクをセットアップする。

【０２０２】それに代わる他のいくつかの実施例にで
は、サービス統制がトランスポート層に直接対話し、現
在のネットワーク構成上での通信に必要なプロトコルを
カプセル化する。これらの実施例では、サービス層は、
情報層にあるコールバックルーチンを呼び出す前に主題
によって到来メッセージをフィルタリングすることがで
きる。

【０２０３】小規模のネットワークにおいて、ある代替
実施例は、特定の主題へのネットワーク加入の要求に関
する放送を行うものである。ネットワークに連結したサ
ービスは、この放送を聞き、当該主題に関するメッセー
ジを放送網に同定されているポートアドレスに送る。こ
れらのメッセージは次いでポートアドレス上のＤＣＣ層
により、本明細書中に別途記載されている方法で要求プ
ロセスへ差し向けられる。

【０２０４】また別の実施例では、サービス層が次のよ
うな他の機能をも果たす。すなわち、一定のサービスに
対するアクセスの規制、ＩＳＯモデルのセション層（論
理的通信路設定層）の従来の意味におけるセション管
理、反復サービスおよびサーバの反復管理、サービスの
故障の際の故障／回復管理、分散管理、他方のサービス
／サーバのニーズを満たすことができるときに一方のサ
ービス／サーバのデータ要求に十分応えられないような
不公平を防ぐためのロード調整、安全なコード化通信を
サーバに提供する機密保護機能等である。上記の代替実
施例のうち特に重要なものは、サービス層においてサー
ビス回復機能をカプセル化する実施例である。これらの
実施例では、あるサーバが停止した場合、適切なサービ
ス統制の別の箇所にカプセル化されている同じデータを
得るための回復機能が働いてステップ４２４で記号化さ
れているような代替サーバへの新たなデータリンクを確
立し直すようになっている。

【０２０５】より好ましい実施例では、サービス統制が
ＴＩＢチャンネルを主題に割り当て、アクセスするサー
バおよびサービス、使用するネットワークおよびネット
ワークプロトコルの特性といった観点から、また必要と
される信頼性の度合いの観点から使用すべきプロトコル
エンジンを選択する。

【０２０６】図１５および図１８のデーモン３０Ｂに
は、それぞれ異なる特性をもった多数の異なるプロトコ
ルエンジンを含ませることができる。例えば、ノベル(N
ovell)ネットワークのインタフェースカードを有して、
ノベルプロトコルを用いるノード間の二点間方式通信用
のプロトコルエンジンや、ＴＣＰプロトコルおよびＵＤ
Ｐプロトコル、関連のネットワークインタフェースカー
ドを用いるノード間の二点間方式通信用のプロトコルエ
ンジンがある。また、信頼性の高い放送を用いた高速デ
ータ発行者との通信用プロトコルエンジンや、インテリ
ジェントマルチキャスト（商標；Intelligent Multicas
t）プロトコルを用いる二点間方式の通信用もしくは信
頼性の高い放送用プロトコルエンジンがある。通信用プ
ロトコルのオプションに応じ、またサーバおよびサービ
スの種類に応じ、あるいはまた望まれる信頼性のオプシ
ョンに応じ、多数のプロトコルエンジンが作成可能であ
り、さらに必要に応じていつでもさらに多くのエンジン
の追加が可能である。

【０２０７】さらに、サービス統制のあるものは、オペ
レーティングシステムや他のアプリケーションのような
同一のマシン上での他のプロセスとの通信用のプロシー
ジャであってもよいし、また端末を通じてのユーザーと
の直接通信用のプロシージャであってもよい。サービス
統制は新しい情報源との通信用にいつでも追加されう
る。

【０２０８】サービス統制は、加入要求を受けると、そ
の主題のための特別のＴＩＢチャンネルを開放するか、
任意のＴＩＢチャンネルを使用可能とする。

【０２０９】選択されたサービス統制あるいはサービス
統制群はＤＣＣのライブラリプログラムを呼び出すこと
によって選択されたサービスとの通信が有効に行われる
ようにするための正しい特性をもつプロトコルエンジン
を選択する。ＤＣＣのライブラリプログラムは、新しい
加入やチャンネルデータで加入リストを更新し、メッセ
ージを共有メモリあるいはその他のプロセス間の転送機
構を経由して、選択されたプロトコルエンジンに送る。
ホストコンピュータに多重操作機能がない場合にはデー
モンが（その機能を肩代わりして）ＤＣＣのライブラリ
プログラムによって発生する干渉により作動するように
なる。選択されたプロトコルエンジンへのメッセージは
前述の通りに送られ、選択されたサーバの同定性も保持
される。プロトコルエンジンは、このサーバの同定性を
確認して、サーバのネットワークアドレスにマッピング
し、選択されたプロトコルエンジンにカプセル化されて
いる通信用プロトコルを実行し、データリンクを構成す
る。このプロトコルのあるものは、例えば、総括的なト
ランスポート層の放送プロトコルの信頼性を増したり、
あるいはインテリジェント多重放送機能を追加した付加
価値プロトコルである。この種の付加価値プロトコルに
ついて以下に説明する。このステップはステップ４２６
の番号で表されている。

【０２１０】分散型通信層３５２および３６０は、構成
切り離し機能を備えている。この機能により、要求プロ
セスはＴＣＰ、ＵＤＰ、放送等の種々の通信プロトコル
を用いたり、またこれらのプロトコルを実行可能とする
コードを備えたりするためのノウハウを知っておく必要
がなくなる。プロトコルエンジンは種々の通信用プロト
コルを実行し、またＤＣＣのライブラリはＴＩＢチャン
ネルの概念を実行し、到来するパケットのパケットヘッ
ダにあり、ＴＩＢチャンネルに基づいた主題内容によっ
てルーチン化あるいはフィルタリングする機能を有す
る。ＵＤＰプロトコルを用いる通信用のプロトコルエン
ジンはまた、メッセージをサービス向け、または送信側
向けにパケット分割して送ったり、加入プロセスまたは
受信側向けにそのパケットを再組立して完全なメッセー
ジとして復元することもできる。ＵＤＰのトランスポー
トプロトコルにはこのような分割および再組立の機能が
含まれないので、この機能は付加価値サービスの１つで
ある。ＴＣＰのトランスポートプロトコルにはこのメッ
セージ分割および再組立の機能が含まれているので、こ
のトランスポート層機能を起こすプロトコルエンジンに
はこの種の付加価値サービスが必要とされない。

【０２１１】この発明のいくつかの実施例では、ＵＤＰ
のプロトコルエンジンに通し番号が加えられ、パケット
ヘッダへの各々の完全なメッセージには何個のパケット
が含まれるかを指示するデータが加えられる。これによ
り受信プロセスＴＩＢ通信層のデーモンあるいはＤＣＣ
ライブラリが受信されたメッセージの完全性をチェック
し、パケットが全部受信されたか否かを確認することが
可能となる。

【０２１２】データパケットがネットワークから入って
くると、ＤＣＣライブラリ、サービス層および情報層を
経て要求プロセスに通される。ある実施例では、他の実
施例と同様にデーモンあるいはＤＣＣライブラリによる
フィルタリングの代わりにサービス層に主題内容により
到来メッセージをフィルタリングする機能をもたせるこ
ともできる。さらに他の実施例では、主題内容によるフ
ィルタリングを情報層にもたせることもできる。

【０２１３】ある実施例ではサービス層は、図１５のＴ
ＩＢフォームズインタフェース２３１または図１５のＴ
ＩＢフォームライブラリ３２中の呼出しプログラムによ
りデータボルマタイゼーション（vormatization）をも
実行する。

【０２１４】ある実施例では、要求プロセスが膨大なデ
ータベース中に必要とするであろうすべての情報を集め
ることにより主題に基づいたアドレス指定が実行され
る。サービス層はその際、データベースの適正な領域か
らデータを抽出するため、データベースアクセスプロト
コルに主題要求をマッピングするルーチンを含む。この
ような実施例での通信層は、データベース中において適
当な日付に更新するための更新プロトコルに入ってくる
最新のデータをマッピングする。

【０２１５】好ましい実施例では、データソースが分散
されるようにするもっと強力な概念を実行する。これに
より、新規のサーバやサービスが現在のすべてのアプリ
ケーションソフトウェアを大きく損なうことなく、シス
テムに連結することが可能となる。この発明の教示に従
って、ＴＩＢソフトウェアの情報層、サービス層、およ
び通信層を使用すると、アプリケーションソフトウェア
をそれ以下の絶えず変化しているネットワークからきわ
めて自由に切り離すことが可能となる。

【０２１６】好ましい実施例では、二点間方式プロトコ
ルへの主題内容によるフィルタリングは送信側のＴＩＢ
ソフトウェアで実行される。図１７において、サーバ３
１０、３１２、および３１６が、“ＴＩＢ ＩＦ”と表
示されたブロックで示されるＴＩＢインタフェースソフ
トウェアによってネットワークから切り離されているこ
とに注目されたい。ターミナル３２０もまた、同様な方
法で切り離され、ユーザーによるデータの手作業でのエ
ントリーのためのされるが可能となっている。とくにこ
のフィルタリングはデータを発行するサービス向けの情
報層によってなされる。放送用トランスポートプロトコ
ルを用いるサービスに対しては放送を受けるネットワー
クアドレスにあるＴＩＢ通信層がＴＩＢチャンネルデー
タを情報層によって発生する要求データに基づく要求テ
ーブル中に記録されている開放要求用のチャンネルデー
タと、またサービス層によって発生するＴＩＢチャンネ
ルデータと比較することにより、主題に対応する開放要
求をもつメッセージ以外の他のすべてのメッセージをフ
ィルタ除去する。サービスが単に、データを放送するだ
けの場合にはそのサービスにアクセスするためのサービ
ス統制は、“次のネットワークアドレスで到来するデー
タを注意して聞け、そして要求主題以外の他のメッセー
ジをフィルタ除去せよ”という簡単なものであることに
注目されたい。サービス統制は、そのとき、ＴＩＢフォ
ームライブラリに適正な機能を呼び起こすことによって
適正にデータをフォーマットし、それからそのデータを
情報層経由で要求プロセスに転送する。

【０２１７】通信層を使用すると、すべてのネットワー
ク構成パラメータをアプリケーションの枠外に外すこと
が可能となり、そしてシステム管理者によって、あるい
はまたネットワーク構成が変更されるときにそのパラメ
ータは改定に付される。こうしてアプリケーションソフ
トウェアは、ネットワークインタフェースから切り離さ
れ、ＩＳＯネットワーク層のすべての機能性に類似し
た、かつ少なくともそれを包含した機能性が提供され
る。

【０２１８】また、いくつかの実施例では、情報層、サ
ービス層、および通信層の機能性が好ましい実施例によ
るソフトウェアよりもハードウェアにおいて容易に実行
されることに注目されたい。サービス層および情報層
は、ＩＳＯモデルネットワーク、データリンク、および
物理層プラスアルファの機能性の大部分を実行する。

【０２１９】いくつかの実施例では、分散型通信層はデ
ータリンクを構成するために、サービス層からの一般要
求を受けるだけで使用するのにもっとも有効なプロトコ
ルか、どれかの決定を独自で行う。例えば、ＤＣＣは同
一の情報に対し、５個の別々の加入を受ける。ＤＣＣは
５個の別々のデータリンクを構成し、要求を束ねて１個
のデータリンクを構成し、到来するメッセージをプロセ
ス間転送により５個の要求プロセスの各々に分散するよ
う、選択を独自で行う。他の実施例では、ＤＣＣはどの
プロトコルを使うべきかの決定を独自で行う。しかしな
がら、“私はこれを速やかに必要とする”あるいは“私
はこれの信頼性を必要とする”といったサービス層から
の事項を受け付けることもできる。後者の場合、通信層
は同じ情報層に対する２つの要求を２つの異なったサー
ビスに選択して送ることができ、また別のネットワーク
通路によって同じサービスに２つの別々のリンクを構成
することもできる。

【０２２０】好ましい実施例において、通信ライブラリ
のＤＣＣライブラリ部分は、１つのネットワークアドレ
スから他のネットワークアドレスへ如何にして最も効率
よくデータを取得するかを決定するソールド機能を提供
する。すべての反復管理や故障回復プロトコルがサービ
ス統制中にカプセル化されている。

【０２２１】図２１および図２２において、送信側での
ＴＩＢソフトウェアの３層に含まれる処理のためのフロ
ーチャートが示され、発行プロセスあるいはサービスに
加入データストリームを発生させたり、またそれをＴＩ
Ｂソフトウェアを経由してネットワークを横断して加入
プロセスに送り下す状況が示されている。

【０２２２】ステップ４３０は、選択されたサービスが
加入プロセスからのメッセージを受け、データストリー
ムを開始するプロセスを示す。図１７のサーバ３１０に
作動しているクオトロン（Quatron）サービス、サーバ
３１２および３１６にそれぞれ作動しているマーケット
フィード（Marketfeed）２０００サービスやテレレート
（Telerate）サービスのような各サービスはこの発明の
教示に従った３層アーキテクチャＴＩＢソフトウェアの
バージョンによってネットワークから切り離される。こ
れはＴＩＢインタフェースソフトウェアを表示するサー
バボックス中のＴＩＢ ＩＦと表示されたブロックによ
って示されている。

【０２２３】各サービスへのＴＩＢインタフェースは、
フィルタリングやあるいは主題に基づいたアドレシング
をサポートしうる機能性をもつ如何なる要求からもその
サービスを切り離す。かくして、アドレスがすべての株
式価格をアメリカの株取引市場や店頭市場に放送するた
めに考案されたものであって、しかし加入が単にＩＢＭ
の株式価格に対してのみなされている場合には、サービ
スは通常通りに対応し、ＩＢＭの株式価格のみをフィル
タ除去する機能をもつ必要はない。この型サービスのた
めのサービス統制は、このような加入要求に対応してＩ
ＢＭの株式価格以外のすべてのメッセージをフィルタ除
去するのに適合する。

【０２２４】主題内容によって編成される多くの異なっ
たページ、例えば政府財務省証券レートに関するペー
ジ、長期企業債のレートに関するページ等を発行するテ
レレートのような他のサービスは、特定のページのみを
受け付けたり、特定のページの特定欄にのみ発行するサ
ービスをさせる特別のコマンドを受け付けたりすること
ができる。このような場合、このようなサービスに向け
られたサービス層は主題により、加入要求を受け、オー
プン加入をもつ主題に関係しない放送からメッセージを
フィルタ除去するサービス統制を含む。

【０２２５】ステップ４３０はまた、ＴＩＢ−ＩＮＦＯ
ライブラリの情報層のＴＩＢ発行機能を呼び出し、加入
プロセスに向けてのデータストリームをスタートさせる
サービスのプロセスを示す。このサービスは、主題によ
ってそれ自身でフィルタリングできる能力を備える必要
はない。サービスが受ける加入要求は、このサービスが
フォーマット化され、加入プロセスのサービス統制によ
って自国語に順序づけられているので、そのサービスが
理解する“自国語”の形でなされる。

【０２２６】主題内容によるフィルタリングの大部分
は、サービス統制によってなされる。しかしながら、ど
こでこのフィルタリングが行われるかはサービスの型に
よって変わる。あるサービスは、そのような発行者が発
行するすべての事項が加入プロセスにとって重要となる
ようにただ１つの型のデータを発行する。例えば、図１
７では現在の時間のみを表示するリアルタイムクロック
３７１がアクセスサービスであり、加入の主題は“私に
いまの時間を知らせてほしい”という主題であるという
ことによってもそれは分かるであろう。このような場
合、サービス統制はきわめて簡単で、フィルタリングの
必要性はなんら起こらない。このようなサービス統制は
如何にしてデータを要求プロセスに連絡し、それにどの
ＴＩＢチャンネルを割り当てるかを単に決めるためのプ
ロトコルであればよい。

【０２２７】サービスは、そのサービスが正規にデータ
を如何なる方法で送っても、データ送りをスタートさせ
るということが、ステップ４３２に示されている。この
ようにして、サービスがテレレートである場合には、そ
れはページイメージを送ることができ、多数の異なった
ページの中のどの１つのページでも更新することがで
き、その多数のページのただ１つのページに対する加入
を理解するが、一方、クオトロンサービスはＩＢＭ株式
価格だけの加入を理解することはできない。サービス層
の種々のサービス統制は、中でも特にそのサービスがも
っていない必要な機能性を提供する。

【０２２８】ステップ４３２は、多くの異なった主題に
ついてのメッセージおよびそれらの主題の中の１つまた
は少数の主題に対する加入要求を放送するサービスを引
き受ける。他の仮定的な例では、サービスが特定のテレ
レートページのような要求された情報だけを発行する。
テレレートの場合には、加入要求は特定のページだけ
か、そのページの特定の欄だけが送られ、専用のＴＩＢ
チャンネルを用いて二点間方式通信プロトコルにより、
ページイメージを要求するように指定することもでき
る。

【０２２９】ステップ４３４は、サービス層の加入要求
への応答プロセスの実施や、その結果発生するデータの
流れを示す。ステップ４３４では、サービス統制は主題
内容によるどんな必要なフィルタリングでも行い、ＴＩ
Ｂチャンネル数を割り当てる。主題内容によるフィルタ
リングは、高速の放送プロデューサの場合におけるよう
な、加入によって要求される場合よりも広範囲で多数の
データをプロデューサが発生させるときにだけ一般に交
換データプロデューサ側でのサービス統制により実施さ
れる。このような場合には外部からのデータがネットワ
ークを圧倒的に占有することになる。ＴＩＢチャンネル
数は、ステップ４３４のサービス統制によって割り当て
られるが、このチャンネル数はメッセージが通信層に到
達するまでパケットへのヘッダには実際には付け加えら
れない。ある他の実施例ではＴＩＢチャンネル数がサー
ビス統制によりパケットヘッダに書き込まれることので
きるものもある。

【０２３０】ＴＩＢチャンネル数の割当ては、使用され
るサービス、加入、および通信プロトコルの型に基礎を
置いているサービス統制によってなされる。放送プロト
コルが使用されつつあるところでは、ある実施例でのサ
ービス統制は、ステップ４３４で異なった主題に異なっ
たＴＩＢチャンネル数を単純に割り当て、情報層上のサ
ービス層によって保持されている加入テーブル中にリス
トされている加入者にメッセージを送る。メッセージは
単に、例えばＩＢＭ株式価格の更新に対してＴＩＢチャ
ンネル１００をモニタせよ、というようなものである。
ＴＩＢチャンネルデータはもっぱら、メッセージを適正
な加入プロセスに送るために受信ホストのＴＩＢソフト
ウェアによって使用されるということに注意すべきであ
る。ＴＩＢチャンネルは、論理チャンネルネットワー
ク、ルーチン化、あるいは他のネットワーク、データリ
ンク、または物理層発行とは何等の関係ももたない。

【０２３１】他の実施例では、放送プロトコルの場面
で、サービス統制は加入リスト診断し、オープン加入の
付いた主題以外の主題に関するすべてのメッセージをフ
ィルタ除去する。この主題に対し、ＴＩＢチャンネルが
割り当てられ、メッセージは顧客プロセスに送られるメ
ッセージに対し、どのＴＩＢチャンネルを聞けばよいか
という加入プロセスに連結したＴＩＢソフトウェアに送
られる。

【０２３２】二点間方式プロトコルの場合には、加入要
求は通常、加入プロセスに連結した情報層によって選択
されたサービス統制によって主題に割り当てられたＴＩ
Ｂチャンネル数を含む。このような場合には、ステップ
４３４は、加入要求において受信されたＴＩＢチャンネ
ル数をサービスから発生するメッセージに割り当てるプ
ロセスを表す。二点間方式プロトコルが選択された場合
には特定のＴＩＢチャンネルが使用されるべきであるこ
とを指定するテレレートページへの加入の典型的な場合
には、サービス統制は二点間方式プロトコルエンジンを
選定することによりページイメージを送る。サービス統
制はまた、加入を確認し、かつ加入プロセスのＴＩＢソ
フトウェアにそのページへの更新の放送のための特定の
ＴＩＢチャンネルを聞くように勧告するメッセージを送
る。受信側のＴＩＢソフトウェアは、その後で更新のた
めのＴＩＢ放送チャンネルを開放する。

【０２３３】ステップ４３６は、サービス統制がそれを
呼び出す後にＤＣＣライブラリによって実行されるプロ
セスを表す。好ましい実施例でのＤＣＣライブラリの独
占的機能は、サービス統制あるいは加入要求が使用され
るべき通信プロトコルを指示しない場合に、如何なる特
定のネットワークアドレスに対してもメッセージを送る
最良の方法を決定することである。ある実施例では、情
報層のＤＣＣライブラリはサービス層または加入要求か
らメッセージを送る方法についての暗示を受け取るが、
しかしそれがさらに有効であると考えられる場合には別
のプロトコルを選択することもできる。

【０２３４】さらに、ＤＣＣライブラリは、加入者の数
のような絶えず変化している条件に基づいて、使用され
つつある通信プロトコルを変更することができる。例え
ば、インテリジェントマルチタスクプロトコルを選択す
ることができる（詳細は後述）。このプロトコルでは、
加入者の数が一定の切り離し数（システム管理者により
プログラム化されうる）以下である場合には、二点間方
式プロトコルが使用され、また加入者数が切り離し数を
超える場合には、放送プロトコルへの切替えが自動的に
行われる。好ましい実施例では、“ハイ・ウォータ”お
よび“ロー・ウォータ”のマークが後述のように使われ
る。他の実施例では、単一の放送メッセージに対立する
ものとしての多重二点間方式メッセージを送るためのコ
ストおよび効率に基づく切替えポイントを設定するのに
コスト機能（どんなコスト機能でもよい）が使用でき
る。

【０２３５】ステップ４３６はまた、サービスのローカ
ルメモリからメッセージを検索し、それを図１５のプロ
トコルエンジン／デーモン３０Ｂに送るためのプロセス
間移動プロセスに入れるプロセスを示す。ステップ４３
８は、メッセージを加入プロセスに転送するためのサー
ビスのプロトコルエンジンによって実行されるプロセス
を示す。もし使用中のトランスポートプロトコルがＵＤ
Ｐである場合には、プロトコルエンジンはある実施例で
はパケット化機能を果たす。これはメッセージをパケッ
トに分割して送信側のヘッダデータに付加し、受信側で
正規の順序にパケットを再組立するプロセスである。Ｔ
ＣＰトランスポートプロトコルは、それ自身でパケット
化を行うので、このトランスポート層を呼び起こすプロ
トコルエンジンはパケット化する機能をもつ必要はな
い。非パケット型プロトコルエンジンはまた、その他の
タイプのトランスポートプロトコルに対しても存在す
る。

【０２３６】プロトコルエンジンはさらに、加入プロセ
スをメッセージヘッダに走らせるマシンのポートアドレ
スを記入したり、あるいは他の付加価値サービスを実行
することもできる。付加価値サービスには、高信頼性放
送やインテリジェントマルチキャスティングなどがあ
る。高信頼性放送サービスは後で説明されるが、基本的
にはこのサービスは現在の放送通信プロトコルには存在
しない機能を提供して信頼性を増大させるものである。

【０２３７】プロトコルエンジンは、それによってオペ
レーティングシステム中のトランスポート層ルーチンと
通信する標準的なプログラマインタフェースを備える。
プロトコルエンジンによって実行されるステップは、メ
ッセージを加入プロセスに伝達するようにトランスポー
ト層の機能性を呼び起こして、ネットワーク、データリ
ンク、および物理層プロトコルを動かすようにさせるこ
とである。正確には、これらのステップがどんなもので
あるかを詳細に説明することはできない。というのは、
これらのステップがネットワークの構造、構成、および
プロトコル並びにトランスポート層へのインタフェース
等の要因に高度に依存してその詳細を異にするからであ
る。上記の要因のどれかが変化すれば、プロトコルエン
ジンはネットワークの変化に対応して変更されねばなら
ない。しかし、このプロセスではこの際、構成切り離し
を備えることにより、アプリケーションソフトウェアを
変更する必要はなくなる。

【０２３８】メッセージはネットワークを通過した後、
加入プロセスにより共有されるポートアドレスをもつネ
ットワークインタフェースカードによりピックアップさ
れる。このプロセスはステップ４４４で示されている。
ネットワークカードはメッセージをバッファリングし、
到来メッセージを取り扱うトランスポート層ルーチンに
割込みを発生させる。

【０２３９】ステップ４４６は、トランスポート層ソフ
トウェアが図１７の層３５２または３６０などの通信層
においてデーモン３０Ｂの該当するプロトコルエンジン
を呼び出すプロセスを示している。到来メッセージやパ
ケットは、共用メモリなどの何らかのプロセス間転送機
構により該当するプロトコルエンジンへ引き渡される。
好ましい実施例においては、デーモンは多重タスク処理
マシーン上においてバックグラウンドを走行する継続プ
ロセスとなっている。他の実施例では、デーモンは割込
み駆動され、メッセージを受け取ったとき、または転送
しようとするときに実行されるにすぎない場合もある。
ステップ４４６はまた、ＴＣＰその他のトランスポート
層プロトコルに対するパケット再組立プロセスを示し、
ここでパケット再組立はトランスポート層によって行わ
れる。

【０２４０】ステップ４４８は、到来メッセージを処理
し、ルーチン化するためにデーモンにおいてプロトコル
エンジンによって行われるプロセスを示す。

【０２４１】ＵＤＰトランスポート層プロトコルエンジ
ンにおいては、パケット再組立が行われる。このことは
もちろん、データ発生プロセスにおけるプロトコルエン
ジンがパケットヘッダに対し、データを正しい順序で再
組立できるように一連番号を付加したことを意味する。
これにより、すべての一連番号を、本来到着していなけ
ればならない一連番号を示すデータと照合し、すべての
パケットが受け取られたかどうかを判定するといった他
の付加価値サービスを実行することもできる。実施例に
よっては、予期される一連番号に関するデータが、パケ
ットヘッダにおいてこの目的に使用されるフィールドに
書き込まれる。他の実施例では、このデータは別のメッ
セージとして送られる。

【０２４２】もしパケットが脱落している場合、これら
の実施例においては、受信通信層からデータ発生プロセ
スの通信層にメッセージが自動的に送り返され、脱落も
しくは誤伝送されたパケットの再転送を要求する。この
ことは当然、データプロセスのための通信層が全パケッ
トをメモリに記憶し、全パケットが順調に受け取られた
ことを示す肯定応答メッセージを受け取るまで再転送の
可能性に備えてそれらを保持することを意味する。

【０２４３】ステップ４４８はまた、受信メッセージに
おいて通信層デーモン／プロトコルエンジンが行う主要
機能を示している。その機能はヘッダにおけるＴＩＢチ
ャンネル情報に従って、該当する加入プロセスに対する
メッセージをルーチン化する。プロトコルエンジンは、
ヘッダにおけるＴＩＢチャンネル番号をサービス統制に
よってエンジンに送られた現在の加入リストと照合す
る。加入リストには、いずれか特定のＴＩＢチャンネル
に割り当てられたメッセージにおける関連サービス統制
コールバックルーチンおよび加入プロセスに対するポイ
ンタが含まれている。プロトコルエンジンはまた、メッ
セージが主題への加入者に関与しない加入プロセスＴＩ
Ｂソフトウェアに到達する実施例においては、ＴＩＢチ
ャンネル番号によってメッセージをフィルタリングす
る。これはサービス層や情報層で行ってもよいが、通信
層で行うのがもっとも効率的である。

【０２４４】プロトコルエンジンは続いて、メッセージ
を該当するプロセス間転送機構、通常は共用メモリある
いは UnixTM パイプに送り、ステップ４５０に示すＤＣ
Ｃライブラリに割込みをかける。この割込みによってそ
の後の処理は、該ＴＩＢチャンネルにおける加入および
主題が開放されたときにＤＣＣによってプロトコルエン
ジンに対して識別された該当ＤＣＣライブラリコールバ
ックルーチンへと向けられる。このようにして呼び出さ
れたＤＣＣライブラリルーチンは、加入を開始した加入
プロセスへ、またその一部へリンクされる。ＤＣＣライ
ブラリコールバックルーチンは次いでサービス層に割込
みをかけ、メッセージに係わるポインタに送る。

【０２４５】ステップ４５２は、到来メッセージについ
てサービス層が行うプロセスを表す。ＤＣＣライブラリ
からの割込みにより、ＤＣＣライブラリを通じてサービ
ス層によって送られた原加入メッセージにおいて識別さ
れたサービス統制コールバックルーチンが実行される。
コールバックルーチンは、ある実施例においては、必要
なデータフォーマット変換を行い、また他の実施例では
主題フィルタリングを行う。次いで、サービス統制が情
報層へ割込みをかけて情報層のコールバックルーチンを
実行させる。この割込みにはメッセージに対するポイン
タが含まれている。

【０２４６】ステップ４５４は、情報層による到来メッ
セージの処理を示す。実施例によっては、情報層に到達
したすべてのメッセージが、データが要求された主題と
正確に一致することをサービス層が保証しないものもあ
る。ステップ４５４に、これらの実施例においてＴＩＢ
チャンネルコードを加入の主題と比較し、それらが一致
することを確認するプロセスが示されている。

【０２４７】ステップ４５６は、主題における一致があ
った場合に、加入プロセスのコールバックルーチンに対
して割込みをかけるプロセスを示す。一致がない場合
は、割込みはかけられず、デーモンによって新たなメッ
セージの監視を続けながら、すべての割込み駆動プロセ
スが終了し、次の割込みがあるまでコンピュータ資源を
解除する。

【０２４８】ステップ４５８は、加入プロセスが元来そ
のデータを求めた目的に関わりなく行われるメッセージ
データの使用プロセスを示す。

【０２４９】高信頼性放送は、トランスポート層の通信
プロトコルを補完し、かつ向上させるために通信層が用
いることのできる付加価値サービスの１つである。従来
のトランスポート層によって提供されてきたこれまでの
放送プロトコルは信頼性が低い。例えば、パケットやメ
ッセージを損なったり破壊したりする回線ノイズが存在
する場合、あるいはネットワークインタフェースカード
がバッファにオーバーフローする場合、パケットあるい
はメッセージ全体が失われる可能性があり、この場合メ
ッセージを聞き取るプロセスはそのメッセージを全く得
られないか、不完全もしくは誤ったメッセージを得るこ
とになる。従来の放送には肯定応答機能はなく、したが
って上記プロセスの一部でメッセージが失われたり、不
完全もしくは誤メッセージが得られたりすると、転送プ
ロセスは発見することがない。これは１００パケットご
とに１回、または１０パケットごとに１回起こる可能性
がある。これまでの従来技術によるトランスポート層放
送プロトコルは、ホストのネットワークアドレスで受け
た放送メッセージを上記ホスト上を走る複数プロセスに
分散させる機能性、すなわちプログラムコードを備えて
いない。

【０２５０】この発明の教示に従う通信層は、その上に
構築された高信頼性放送プロトコルを実行し、かつ従来
のトランスポート層放送プロトコルを補完するために少
なくとも１つのプロトコルエンジンを備える。図２３、
図２４に、通信層によって実行される高信頼性放送プロ
トコルの１実施例におけるフローチャートが示されてい
る。ステップ５００は、ＤＣＣライブラリがサービス統
制から、特定のＴＩＢチャンネルが割り当てられたメッ
セージを送れという要求を受け取るプロセスを示してい
る。実施例によっては、この要求に、高信頼性放送プロ
トコルによってメッセージを送れという要求または命令
を含めてもよい。高信頼性放送プロトコルがサービス統
制により委任された実施例においては、サービス統制が
特定チャンネルに対する加入者数を判定し、かつ同一メ
ッセージを全加入者のポートアドレスへ何度も送るコス
トと、加入者の関心の対象となっている主題におけるデ
ータはＴＩＢチャンネルＸＸ（この主題に割り当てられ
ているＴＩＢチャンネル番号）を聞くようにとの全加入
者へのメッセージと共に放送によって一度だけ該メッセ
ージを送るコストとを比較判定する。図２３、図２４に
示した実施例では、このコスト判定機能が通信層ＤＣＣ
ライブラリ機能に含まれている。

【０２５１】ステップ５０２は、ＤＣＣライブラリによ
って行われる上記コスト判定プロセスを示している。こ
の機能を実行するＤＣＣライブラリの特定プログラム
は、加入リストをチェックし、当該メッセージに割り当
てられたＴＩＢチャンネルに対する加入者数をカウント
する。次いで、メッセージを二点間通信でこれらの全加
入者に送るコストが所望のコスト評価機能を用いて評価
される。実施例によっては、コスト機能を加入者数と所
定の打切り数との比較としてもよい。使用する特定のコ
スト機能は、この発明の本義にとって本質的に重要なも
のではない。

【０２５２】複数の加入者にメッセージを二点間通信で
送ることのコストは、データ生成ソフトウェアにより同
一メッセージをネットワーク上に何度も乗せなければな
らないことである。１つのメッセージを放送することの
コストは、すべてのネットワークカードがメッセージを
ピックアップし、プロセス間転送によってメッセージを
ＴＩＢデーモンに転送するホストのオペレーティングシ
ステムにおける転送プロトコルプログラムが中断され
て、該メッセージがホスト上を走るクライアントプロセ
スにとって関係のないものであるという結果が発生しう
ることである。コンピュータ資源は、この結果その種ホ
ストのいかなるものにおいても浪費されることとなる。

【０２５３】ステップ５０４は、上記コストを評価し、
二点間通信プロトコルか高信頼性放送かのいずれでメッ
セージを送るかを決定するためにＤＣＣライブラリが行
うプロセスを示している。このＴＩＢチャンネルに対す
る加入者数が十分少ないと判定された場合、二点間通信
プロトコルでメッセージを送る決定がなされる。ステッ
プ５０６に、二点間通信プロトコルエンジンで呼び出
し、そのプロトコルを使ってメッセージを送るプロセス
を示す。

【０２５４】加入者数が効率的な二点間通信による転送
を行うには大き過ぎる場合、ＤＣＣライブラリはステッ
プ５０８に示す高信頼性放送プロトコルエンジンを呼び
出す。

【０２５５】ステップ５１０は、高信頼性放送プロトコ
ル処理の第１ステップを示す。この発明の教示による高
信頼性放送プロトコルは、同一ホストの多重加入プロセ
スの実行をサポートしており、各々の加入プロセスがエ
ラーなくメッセージの全パケットを受け取り、かつメッ
セージの受取りに対して肯定応答することを要求する。
これらが順調に行われることを保証するために、各パケ
ットのヘッダに一連番号を付加する必要があり、一連番
号（メッセージ全体の受取りを完了するためにはその一
連番号のすべての受取りを完了していなければならな
い）を示すある種のデータを加入プロセスに送信しなけ
ればならない。実施例によっては、一連番号のみがパケ
ットヘッダに付加され、メッセージ全体から成る一連番
号に関するデータが別のメッセージによって該メッセー
ジに割り当てられたＴＩＢチャンネルへの開放加入を有
する各プロセスに送られる。他の実施例では、メッセー
ジ全体から成る一連番号が第１パケットのヘッダまたは
全パケットのヘッダに付加される。ＴＩＢ一連番号は１
つのメッセージの全パケットを受取り完了したかどうか
を判定するためにのみ使用されるため、パケットに付加
された一連番号は、ＴＣＰプロトコルにおけるオペレー
ティングシステムのトランスポートプロトコルのパケッ
ト化機能によって付加された一連番号とは異なる。実施
例によっては、全パケットが受取り完了したかどうか判
定するために、トランスポートプロトコルによって付加
されたパケット一連番号を加入プロセスのＴＩＢ通信層
が使用することもできる。ＵＤＰトランスポート層プロ
トコルを補完するための高信頼性放送プロトコルエンジ
ンの他の実施例においては、プロトコルエンジンのパケ
ット化機能は、あるメッセージの全パケットの受取りを
完了したことを確認する際、トランスポート／ネットワ
ーク／データリンク／物理層機能ばかりでなくＴＩＢ通
信層機能に対しても使用することのできる一連番号を付
加する。

【０２５６】一連番号が付加された後、パケットは、ス
テップ５１２に示すようにパケットの一部または全部を
後に再転送する必要が生じた場合に備える保存のための
一連番号と共に再転送バッファに書き込まれる。

【０２５７】メッセージを種々の加入プロセスに送るこ
とが可能となる前に、高信頼性放送プロトコルエンジン
はＴＩＢチャンネルデータを各パケットのヘッダに付加
し、このチャンネルに対する開放加入を有するものとし
て加入テーブルにリストアップされている各加入プロセ
スに対して、加入要求主題に関するデータについてはＴ
ＩＢチャンネルＸＸ（ここに、ＸＸはこの主題に割り当
てられたＴＩＢチャンネル番号）を聞くようにとのメッ
セージを送る。

【０２５８】ステップ５１６は、該当するオペレーティ
ングシステムプログラムを呼び出してポインタを各パケ
ットに送ることによりトランスポート層の標準放送プロ
トコルを介してパケットを転送するプロセスを示してい
る。

【０２５９】図２５、図２６に、高信頼性放送プロトコ
ルにおける加入プロセスの通信層による処理のフローチ
ャートが示されている。ネットワーク上でのパケット放
送は、ネットワーク上のすべてのホストのすべてのネッ
トワークインタフェースカードによってピックアップさ
れ、これは続いて種々のホストのオペレーティングシス
テムのトランスポートプロトコルソフトウェアを呼び起
こす。トランスポートプロトコルは次いで、放送メッセ
ージが到着した通信層をデーモンに知らせ、パケットを
プロセス間転送機構、通常は共用メモリに送り込む。続
いてデーモンが、ステップ５１８に示す通り、パケット
をプロセス間転送機構から取り込む。

【０２６０】ステップ５２０は、到来パケットのＴＩＢ
チャンネル番号をチェックしていずれかの開放加入のＴ
ＩＢチャンネルに対応するかどうかを判定するプロセス
を示す。対応すれば、信頼性一連番号が、高信頼性放送
プロトコルエンジンにより、完全なメッセージの受取り
を完了するためにはどのパケットおよび対応一連番号の
受取りを完了していなければならないかを示すデータと
照合される。実施例、とくにこの発明のＴＩＢインタフ
ェースソフトウェア以下の層でエラーチェック（ＥＣ
Ｃ）が行われないトランスポート、ネットワーク、デー
タリンク、および物理層を使用した実施例においては、
エラー検出およびエラー補正がパケットに添えられたＥ
ＣＣビットを用いてパケット上で行われる。ＥＣＣビッ
ト数が存在する場合に補正範囲を超えたエラーが発生す
ると、そのパケットが誤伝送されたとしてマークされ
る。

【０２６１】もし存在する場合、どのパケットが脱落も
しく誤伝送されたかを判定した後、受信プロトコルエン
ジンは引き続いてメッセージをサービスプロセスまたは
発行プロセスの通信層に送り返す。このメッセージは、
全パケットを順調に受け取ったことを肯定応答するか、
または特定のパケットを再転送するように要求する。こ
れはステップ５２２で示されている。

【０２６２】ステップ５２４は、データ生成プロセスま
たはサービスの通信層による脱落もしくは誤伝送パケッ
トの再転送プロセスを示す。実施例によっては、脱落も
しくは誤伝送パケットはそれが発生した加入者にのみ二
点間通信で送られる。他の実施例では、脱落もしくは誤
伝送パケットは、ＴＩＢチャンネルＸＸ（ＸＸはパケッ
トが放送されるＴＩＢチャンネル）を聞く必要のある加
入プロセスに送られる通知メッセージと共にノードに放
送される。ここで実際に用いられる“チャンネルＸＸを
お聞き下さい”というフレーズはその転送の実際の転送
周波数、タイムスロット、その他の物理特性とは関係し
ない。それは単に、脱落もしくは誤伝送パケットがこれ
から少しの間ネットワーク上に現れること、およびそれ
らのパケットがヘッダデータにおいてＴＩＢチャンネル
ＸＸルーチン化情報を有していることを意味するに過ぎ
ない。

【０２６３】ステップ５２６は、ステップ５２０の処理
と同様、交換パケットが正しく受け取られたことを受信
通信層がチェックするプロセスを示す。正しく受け取ら
れた場合、受信通信層はこの事実をサービスの通信層に
肯定応答する。そうでない場合、脱落もしくは誤伝送パ
ケットの再転送要求が転送プロセスの通信層にもう一度
送られ、この後再転送が行われ、すべてのパケットが順
調に受取り完了されるまでプロセス全体が繰り返され
る。全パケットが順調に受け取られたという受信通信層
から転送通信層への最終の肯定応答メッセージにより、
転送通信層の高信頼性放送プロトコルエンジンがステッ
プ５２８に示す再転送メモリからすべてのパケットを放
出する。

【０２６４】ステップ５３０は、高信頼性放送プロトコ
ルエンジンがＴＩＢチャンネルデータを加入リストと照
合してどのクライアントプロセスがこのＴＩＢチャンネ
ルに割り当てられてたデータを要求しているかを判定す
るルーチン化プロセスを示している。いったんこの情報
が知れると、プロトコルエンジンは、このＴＩＢチャン
ネルのデータへの加入が入力されたすべてのサービス統
制に該メッセージに対するポインタを送る。実施例によ
っては、プロトコルエンジンは、加入プロセスのための
分離プロセス間転送機構にメッセージのコピーを乗せ
る。他の実施例では、共用メモリがそのプロセス間転送
機構となり、該メッセージの同じコピーに対するポイン
タがすべての加入プロセスに送られる。加入プロセスは
次いで、情報層またはサービス層におけるメッセージへ
のアクセスのために調整を行う。

【０２６５】ステップ５３２は、加入が入力された際に
指定されたコールバックルーチンを実行させる連続割込
みによって、サービス層および情報層を介して加入プロ
セスへメッセージを送る前述のプロセスを示すものであ
る。加入する主題との一致を保証するため、実施例によ
っては、主題によるフィルタリングをサービス層および
／または情報層で行うこともできる。

【０２６６】図２７は、インテリジェント・マルチカー
スト（Intelligent Multicast）通信プロトコルによっ
てデータを転送するための処理のフローチャートであ
る。このプロトコルは、主題およびこの主題に開放され
ている加入者数に応じて、各メッセージに対して二点間
通信プロトコルまたは高信頼性放送プロトコルのいずれ
かを使用する。プロトコルの選択は、メッセージが発行
されるときの当該メッセージに対する加入プロセス／ネ
ットワークアドレスの数に応じて各メッセージごとに自
動的に行われる。ある主題に対する加入者数が十分変化
した場合、転送プロトコルは自動的に変化する。

【０２６７】ステップ６００は、データ発行プロセスの
サービス層において加入要求を受け取り、この加入を加
入プロセスに沿って通過させ、加入テーブルに新規の加
入をエントリーするプロセスを示す。

【０２６８】ステップ６０２で、サービスにより情報層
を介してサービス層へ１つのメッセージが発行される。
そのメッセージの主題は、直前に行われた新規の加入に
おける主題に関するものであってもよいし、なくてもよ
い。サービス層は、そのメッセージについて情報層が送
った主題データを調べ、ＴＩＢチャンネルがステップ６
０４に示される通り加入プロセスのサービス層および情
報層によって割り当てられていたなら、その１つのＴＩ
Ｂチャンネルを情報層と協同して該主題に割り当てる。

【０２６９】ステップ６０６において、サービス統制は
該メッセージの主題に対する加入者数を、二点間通信転
送コストと高信頼性放送による転送コストとの対比に基
づいたプログラマブルな打切り数と比較する。そのプロ
グラマブルな打切り数はシステムアドミニストレータに
より設定、変更ができ、所望のコスト機能に基づくもの
であるが、本質的にこれはこの発明が依拠する重要性を
もつものではない。好ましい実施例においては、そのコ
スト機能はハイ・ウォータマークとロー・ウォータマー
クから構成される。加入者数がハイ・ウォータマークを
超えると、メッセージは高信頼性放送によって送られ
る。この主題に対する加入者数がその後ロー・ウォータ
マーク以下になると、その後のメッセージは二点間通信
で送られる。実施例によっては、該コスト機能を自動学
習プログラムとすることができ、これはネットワークお
よび加入要求を聞き取って待ち時間または他のネットワ
ーク効率基準に基づいてその決定を行うものである。

【０２７０】ステップ６０８は、加入者数が打切り数よ
り大きい場合に、高信頼性放送プロトコルエンジンを呼
び出すプロセスを示す。メッセージは続いて、このプロ
トコルエンジンに向けられたプロセス間転送機構に送り
込まれる。

【０２７１】加入者数が打切り数を下回る場合、二点間
通信の方が効率的であるので、サービス統制は二点間通
信プロトコルエンジンを呼び出し、ステップ６１０に示
すこのプロトコルエンジンに向けられたプロセス間転送
機構にメッセージを送り込む。

【０２７２】ステップ６１２は、次のメッセージまたは
加入を待ち、加入を受け取った場合はステップ６００
へ、また他のメッセージを受け取った場合はステップ６
０２へ戻るプロセスを示している。

【０２７３】以上のように、この発明の思想は、ソフト
ウェア層を使用することにより、アプリケーションが従
来切り離されることがなかったような方法でアプリケー
ションをコンピュータネットワーク通信技術の複雑さか
ら切り離すことにある。例えば、情報層によって提供さ
れる主題に応じたアドレス指定の切り離しは、とくにサ
ービス層によって提供されるサービス切り離しと組み合
わせたとき、新規なものと思われる。新たなネットワー
クトポロジーなどの条件を変更しながら、さらに新た
な、または変更したサービスおよび／またはサーバをネ
ットワークに追加しながらサービスおよび構成の切り離
しを提供するために、新たにサービス統制およびプロト
コルエンジンを追加することによって容易に変更できる
ような拡張サービスや通信層を備えることは、新規なも
のであると思われる。多くの多様な通信プロトコルをカ
プセル化するように設計された多くの異なるサービス統
制を含むサービス層を備えることは新規である。例え
ば、これらのサービス統制は、端末に座るユーザーに対
してテレレートのようなサービスからオペレーティング
システムプログラムまで、他のマシーンにおける他のプ
ロセス（あるいは、同一マシーンや同一プロセスの別の
部分さえも）など、あらゆるものとの通信を取り扱うこ
とができる。さらに、このサービス層の故障監視・回
復、分配・反復管理、そして機密保護／アクセス制御サ
ービスを実行する能力は新規なものである。さらに、通
信層の構成切り離しおよび付加価値サービスを備えるこ
とは新規である。

【０２７４】この発明の教示は、これらの層の任意の１
層を使用することも、あるいはその種類が特定の機能や
本明細書で規定されているそれら機能の組合せを実行す
るものであるようなクラスもしくは類のソフトウェアプ
ログラムを規定している種々の実施例における３層の任
意の組み合わせを使用することも意図している。

【０２７５】以下に示すのは、種々のライブラリプログ
ラムと、この発明の教示に従う通信インタフェースの１
実施例における全体構成および機能化のより詳細な説明
である。

【０２７６】インフォメーション・ドリブン・アーキテ
クチャ（Information Driven Architecture）、テクネ
クロン・インフォメーション・バス（Teknekron Inform
ationBus）、ＴＩＢ、ＴＩＢＩＮＦＯ、ＴＩＢＦＯＲＭ
Ｓ、サブジェクト・ベースト・アドレッシング（Subjec
t-Based Addressing）、およびＲＭＤＰはテクネクロン
・ソフトウェア・システムズ社（Teknekron Software S
ystems, Inc.）の商標である。

【０２７７】

【用語集】以下に示すのは、本発明を説明するために用
いた言葉やフレーズの定義をリストアップしたものであ
る。

【０２７８】アクセス手順： 特定のサーバ、サービス、アプリケーションからのデー
タにアクセスする通信プロトコルよりも多くの概念を含
むものであり、サービス申し込み、サービスプロトコル
よりも広い概念である。アクセスの対象となる特定の主
題に関する情報を要求する手続を含んでいる。例えば、
要求が「データの時間を私に下さい」というものであれ
ば、この要求がサーバーレイヤー上ににマッピングされ
たアクセス手順は、要求を起こしたユーザのコンピュー
タ上のオペレーティングシステムへの呼びとすることが
可能である。また、アクセス手順は、ユーティリティプ
ログラムの呼出しを含んでいる。

【０２７９】アプリケーション：オペレーティングシス
テムプログラム以外の、コンピュータで実行するソフト
ウェアプログラム。

【０２８０】構築的（Architectural）切り離し： 本発明の教示を用いたシステムの特徴。この特徴は、サ
ービス及びサービス統制に主題をマッピングする主題の
主動型（subject-based）アドレスサービスを実行する
のに必要な情報層の機能によって与えられる。サービス
及びサービス統制からこれらの主題の情報を得ることが
できる。主題主動型アドレスは、データ消費プロセス
（data consuming process）のために、ネットワーク構
造及び特定の主題がネットワークデータ上のどこで見つ
けることが出来るかを知る必要性を取り除く。

【０２８１】フォームクラスの属性：クラスが原始であ
るか、構成されたものであるかというような、フォーム
クラスの性質。サイズは別の属性である。

【０２８２】クラス：クラス中の全てのフォームが同じ
フォーマットと同じ意味を有するようなフォームの群の
定義。

【０２８３】クラス／クラス記述子／クラス定義：同じ
内部表現、同じ構成及び同じ情報を有する特定のデータ
レコード群すなわち「フォーム」の構造と編成の定義。
クラス記述子というのは、クラス定義のそれらの全ての
パラメータを定めるデータを格納するメモリ内のデータ
レコードすなわち「オブジェクト」のことである。クラ
スというのはフォームの名称であり、クラス定義は群の
共通な特徴についての情報である。クラスは原始クラス
と構成されたクラスの何れかとすることが出来る。原始
クラスは、クラスを独特に識別するクラス名（この名に
はクラス番号をすなわちクラスｉｄが組合わされる）
と、１つのデータ値の表現の仕様とを含む。表現の仕様
は、ストリング２０EBCDID等のような、ホストコンピュ
ータと依頼人アプリケーションが理解する周知の原始で
ある。構成されたクラスの定義は独特の名称を有し、こ
の種のフォームにおいて見出されるの多数のフィールド
を名称と内容により定義する。フィールド名と、それの
データのフォームクラスを与えることにより、各フィー
ルドは指定される。というのは、各フィールド自体がフ
ォームだからである。フィールドというのは１つのフォ
ームの代りに同じクラスのフォームのリストとすること
が出来る。構成されたクラスの定義は実際のデータを含
まないが、クラス記述子は、この種のフォームの編成と
意味を定めるデータのフォーム中に実際のデータを含
む。フォームの例を定める全ての実際のデータは原始ク
ラスのフォームで格納され、原始クラスで格納されてい
るデータの種類は原始クラスのクラス定義で指定され
る。たとえば、「年令」という名称の原始クラスは、整
数 ３の種類の１つのフィールドを有する。それはフォ
ームの年令クラスに対するクラス定義において定義され
る。このクラスのフォームの例は３桁の整数値を含む。

【０２８４】クラスデータ構造：特定のクラスについて
の、クラスマネジャーに格納されている全てのデータ。
クラス記述子はこのデータ構造の最も重要な部分である
が、より多くの情報があることもある。

【０２８５】クラス定義：フォームクラスの仕様。

【０２８６】クラス記述子： フォームクラス定義を格納するメモリオブジェクト。ク
ラスマネジャーにおいては、それはフォームとして格納
される。ディスクでは、それはASCII ストリングとして
格納される。基本的には、それはクラス定義の為の特定
の表現すなわちフォーマットである。それはASCII ファ
イル型またはフォーム型の表現とすることが出来る。ク
ラスマネジャーが必要とするクラス記述子を持っていな
いとすると、クラス記述子の為にクラス定義を作成した
外部アプリケーションにクラスマネジャーは尋ねる。そ
れから、クラス、クラスマネジャーは、外部アプリケー
ションにより発生された時のフォームでクラス記述子を
受ける。あるいは、クラスマネジャーは、意味に依存す
るオペレーションを要求しているアプリケーションによ
りそれに対して識別された、またはクラスマネジャーに
より維持されているレコード中で識別されたファイルを
探索する。それらのファイルに格納されているクラス定
義はASCII テキストフォーマットである。それからクラ
スマネジャーは、そのようにして見つけたASCII テキス
トを、各種のフィールド名と、各フィールドにの内容に
ついての仕様に構文解析することにより、固有のフォー
マットのクラス記述子へ変換する。

【０２８７】クライエントアプリケーション：データ消費またはデータ提供処理、すなわち、本発明の
通信インターフェイスへ結合されたオペレーティング・
システム・プログラム以外のコンピュータ・プログラ
ム。

【０２８８】コンピュータネットワーク：ローカル及び
ワイドエリアネットワークのような接続ハードウェアに
接続する複数のコンピュータ間のまたは操作システムや
他のソフトウェアプログラムやプロセッサ間のユニック
スパイプを含む分担メモリによって与えられた機能を用
いて同じコンピュータ上で作動する複数のプロセッサ間
のデータパスウエイ。

【０２８９】切り離し構成： 本発明の教示を満たす分配通信層によって必然的に与え
られたコンピュータシステム／ネットワークの特徴であ
る。セットアップの仕方またコンピュータネットワーク
の為の特定の配列の通信網の破壊の仕方についての詳細
のプロトコルを要約することによって、この層は依頼プ
ロセスを、データの提供または消費であれこれらの詳細
を知ることから開放する。

【０２９０】ファイル構成： 使用中の種々のソフトウェアコンポネント、レコード、
フォームの特性及び属性及びパラメータを記述するデー
タを保存するファイル。

【０２９１】構成されたフィールド：他のフォームまたはデータレコードを含むフィールド 。

【０２９２】消費者（Consumer）：クライエント（依頼人） 及び消費者アプリケーションま
たはデータを要求する最終ユーザ。

【０２９３】切り離しデータ分配（Data distribution
decoupling）： 本発明の教示に係る希望のサービスを提供するサーバー
の為のネットワークアドレスを理解し提供する必要性か
らクライエント（依頼人）アプリケーションを開放する
通信インターフェイスソフトウェアの機能。

【０２９４】切り離し： それによりデータを交換する。通信プロトコル、データ
フォーマット、他の全てのプロセス、コンピュータ及び
ネットワークのロケーションを知る必要からプロセス、
ソフトウェアモジュールまたはアプリケーションを自由
にすること。

【０２９５】分配通信層（Distributed commnuication
layer）： 本発明の教示に係る装置及び方法の一部分。これは、サ
ービス層によって特定されたアクセス手続を、特定のネ
ットワークまたは透明層プロトコルエンジンへマッピン
グし、選択されたネットワークプロトコルエンジンを使
用する特定されたサービスに必要な通信チャンネルをセ
ットアップする。

【０２９６】フィールド： 各々には異なる名称が付けられ、異なることを各々意味
する１つまたは複数の構成要素を有することができるフ
ォームの例の内の１つの構成要素。フィールドが実際の
データを含んでおれば、そのフィールドは「原始（プリ
ミティブ）」であり、他のフォーム、すなわち、他のフ
ィールドの群、を含んでいれば、そのフィールドは「構
成（構造化）された」である。別のフォームを含む少な
くとも１つのフィールドを有するデータレコードまたは
フォームは「入れ子にされている」といわれる。

【０２９７】第１のフォームの構成されたフィールドに
記録された第２のフォームはそれ自身のフィールドを有
する。それらのフィールドは原始フィールドと構成され
たフィールドの何れかとすることが出来る。したがっ
て、無限に複雑な入れ子式の層を生じることがある。

【０２９８】外部の(Foreign)：別のコンピュータまた
はソフトプロセスのフォーマットデータレコードと異な
ったフォーマットデータレコードを使用するコンピュー
タまたはソフトウェアプロセス。

【０２９９】フォーム： クラス記述子、またはクラス定義に対応するクラス記述
子番号を含むフィールドを含むことにより、構造が自己
記述的であるデータレコードまたはデータオブジェク
ト。それらのクラス記述子はフォームのクラスであっ
て、それの例の全てが、同じ内容表現と、同じ編成と、
同じ意味情報を有するようなクラスを記述する。このこ
とは、このクラスのフォームの全ての例、すなわち、発
生、が同じ名称のフィールドを同数有し、対応するフィ
ールド内のデータが同じ表現を有し、対応するフィール
ド内のデータが同じ表現を有し、かつ対応する各フィー
ルドは同じことを意味する。１つのユニットのデータだ
けを格納するフォームが原始フォームである。フィール
ドと呼ばれる多数の内部構成要素を有するフォームが構
成されたフォームである。各フィールドは原始フォーム
または構成されたフォームとすることが出来るフォーム
そのものである。各フィールドは別のフォームのデータ
またはクラスｉｄ、すなわち、クラス番号、を格納す
る。

【０３００】フォーマットオペレーション： １つのフォーマットから別のフォーマットフォームへ変
換するオペレーション。

【０３０１】フォーマットまたは型： 構造データレコードのデータ表現及びデータ編成、すな
わち、フォーム。

【０３０２】取扱い（ハンドル）： オブジェクト、レコード、ファイル、クラス、記述子、
フォーム等に対するポインタ。このポインタはオブジェ
クトに対するアクセス経路を本質的に定める。絶対アド
レス、相対アドレス及びオフセットアドレスが取扱いの
例である。

【０３０３】ＩＤ：フォーム、レコード、クラス、メモ
リオブジェクト等の為の独特の識別子。この明細書にお
いてクラスに割当てられたクラス番号がＩＤの例であ
る。

【０３０４】情報層（情報レイヤー）： 本発明の教示に係る装置及び方法の一部分。これは、こ
れらのサービスと通信する為に使用される要求主題及び
サービス統制の情報を供給するサービス名の特定の主題
に情報要求をマッピングすることによって、主題の主動
型（主題に基づく）（subject-based）アドレスを行
う。

【０３０５】インターフェイス： あるタスクを実行するためにサポート機能を提供するア
プリケイションにより、またはインターフェイスの別の
モジュールにより呼出すことが出来るソフトウェアプロ
グラムまたはモジュールのライブラリ。本発明の場合に
は、通信インターフェイスは、外部プロセスおよびコン
ピュータとデータを交換する為にアプリケーションとの
簡単なプログラミングを行えるようにする為に、外部の
プロセス及びコンピュータの間で希望の切り離しを行う
プログラムのライブラリを提供する。

【０３０６】インターフェイスカード： ある接点でネットワークと物理的接続を形成する電気的
回路であって、ネットワーク上でデータのやり取りをす
る為にインターフェイスカードのオペレーティングシス
テムおよびネットワークおよびデータリンクプロトコル
プログラム内の透明な層のプロトコルプログラムによっ
て作動する。

【０３０７】固有のフォーマット／フォーム： アプリケーションまたはそのホストコンピュータに固有
のフォーマットまたはフォーム構造。

【０３０８】ネスティングされた（Ｎｅｓｔｅｄ）： それ自身が多数のフィールドを含んでいる他のデータレ
コードを各々が含むことできる多数のフィールドを有す
るデータレコードより成るデータ構造。

【０３０９】ネットワークプロトコルエンジン： ソフトウェア及びハードウェアの結合体。これは、特定
のプロトコルを使用するネットワーク上で通信を行うこ
とが出来る機能を提供する。

【０３１０】接点（Ｎｏｄｅ）： 各種コンピュータ、サーバーまたは端末をコンピュータ
ネットワークと接続する端子。

【０３１１】原始フィールド： 実際のデータを格納するデータレコードすなわちフォー
ムのフィールド。

【０３１２】プロセス：コンピュータで実行中のソフト
ウェアプログラムまたはモジュールの段階。

【０３１３】意味に依存するオペレーション：特定のフ
ォームがそのフォームからデータをある要求しているプ
ロセスへ供給する為に、クラス定義の少なくとも意味情
報に対するアクセスを求めるオペレーション。

【０３１４】意味情報：フォーム中の種々のフィールド
フォーム、名称及び意味に関するもの。

【０３１５】サーバー：大容量記憶装置に格納されてい
るファイル、またはテレレート（Telerate）のような情
報ソースからの生データを、ネットワークまたは他のコ
ンピュータ／ワークステーションへ供給して、サーバー
へ結合されている他のプロセスへ分配する、というよう
なあることを行う為に特定のプロセスを実行しているコ
ンピュータ。

【０３１６】サーバープロセス：テレレート（Telerat
e）、ダウ・ジョーンズ・ニュース・サービス等のよう
な特定のサービスにより指定されるデータの機能を供給
するアプリケーションプロセス。

【０３１７】サービス： 依頼人（クライエント）アプリケーションを送り出すこ
とが出来る機能またはデータの有意なセット。言換える
と、サービスというのは、特定のこと、たとえばダウ・
ジョーンズ・ニュース情報を供給するアプリケーショ
ン、クオトロン（Quotron）データ供給源もしくはトレ
ード・チケット・ルータを行うアプリケーションの全体
的なクラスである。一般には、１つのアプリケーション
は、１つのサービスを供給するが、これは多くの異なる
サービスを提供するものである。

【０３１８】サービス統制またはサービスプロトコル：
特定のサーバープロセス、アプリケーション、ローカル
エリアネットワークで通信する為のプロトコルである。
サービスを提供するいくつかのサーバの１つを選ぶルー
チンが含まれている。サービスと通信するためのプロト
コル、どのサーバが選択されているかの通信層のアドバ
イスおよび通信リンクのセットアップの要求が含まれて
いる。

【０３１９】サービスアクセスプロトコル：サービス統
制のサブセットである。サービスとの通信のための通信
プロトコルを包含している。

【０３２０】サービス例： 特定のコンピュータで実行され、指定されたサービスを
提供できるプロセス（サーバープロセスと呼ばれること
もある）。与えられたサービスのために、各種のサービ
ス例が共同してサービスを提供する。これにより、故障
に対する耐性もしくは実行能力が向上される。ＴＩＢ
（商標）通信ソフトウエアの分散型通信コンポーネント
は、故障したサービス例から同じサービスを提供してい
る他のものに自動的に切換えることにより「故障に強
い」通信を実現する。

【０３２１】サービス層（サービスレイヤー）： 本発明の教示による装置、方法の一部である。要求され
た情報のためのサービスや他のソースへのアクセスのた
めに使用するアクセス手順のために、情報レイヤーから
のデータをマッピングし、サービス切り離しを実現する
ものである。

【０３２２】サービス切り離し：この発明の通信インタ
ーフェイスソフトウエアにおけるサービスレイヤーの機
能である。これにより、クライエントアプリケーション
は、特定の主題データを供給するサービスのデータへの
アクセスにおいて、特定の通信プロトコルを知る必要や
実行する必要から解放される。

【０３２３】サービスレコード：指定されたサービスを
行うアプリケーションの重要な特徴を記述するフィール
ドを含むレコード。

【０３２４】主題ドメイン（主題領域）： 主題カテゴリーのセット（主題スペースも参照の事）。

【０３２５】主題スペース：主題カテゴリーの階層的な
セット。

【０３２６】申込み要求（Subscribe Request）：ソー
スサーバー、プロセス、または特定の主題についてのデ
ータをそれから得ることが出来るその場所を指定しない
その主題についてのデータに対する要求。トランスポー
ト層：本発明の通信インターフェイスが結合されるコン
ピュータの間のネットワークような標準的なISOモデル
の層。

【０３２７】トランスポートプロトコル： ゲートウエイまたは他のインターネットワーク・ルーチ
ンによって結合された特定のネットワークまたはグルー
プにおいて実現される特定の通信プロトコルまたは統
制。

【図面の簡単な説明】

【図１】本発明の一実施例の通信インターフェイスの各
種のソフトウェアモジュールとクライエントアプリケー
ションおよびネットワークの関係を示すブロック図であ
る。

【図２】構造化フォームクラス定義の例である。

【図３】別の構造化フォームクラスの定義の例である。

【図４】それ自身が構造化フォームであるフィールドを
含み、したがってネスティングの例であって、構造化フ
ォームクラスの定義の例である。

【図５】２つの原始フォームクラスの例である。

【図６】メモリに格納されている典型的なフォーム例で
ある。

【図７】意味データ、フォーマットデータ、および実際
のデータすなわち値データをフォームクラス定義とフォ
ーム例の間に区分した様子を示す。

【図８】フォーマットオペレーション中の処理の流れ図
である。

【図９】フォーマットオペレーションに使用するターゲ
ットフォーマット特有テーブルである。

【図１０】フォーマットオペレーションに使用する別の
ターゲットフォーマット特有テーブルである。

【図１１】フォーマットオペレーションに使用する一般
的な変換テーブルの例である。

【図１２】典型的な意味依存オペレーションに対する流
れ図である。

【図１３】それぞれクラス定義と、このクラス定義を格
納するクラス記述子フォームである。

【図１４】通信プロトコルの主題マッパモジュールおよ
びサービス統制モジュールと要求アプリケーションおよ
び主題をベースとするアドレッシングのためのサービス
との間の関係を示すブロック図である。

【図１５】本発明の別の実施例のインターフェイスの種
々のモジュールおよびライブラリィとクライエントアプ
リケーションの間の関係を示す。

【図１６】別の実施例の通信インターフェイスの種々の
モジュールの内部の関係を示す。

【図１７】典型的な分散形コンピュータネットワークの
ブロック図である。

【図１８】デーモンにおけるＤＣＣライブラリーのＤＣ
Ｃプロトコールエンジンに対する関係を示すプロセス構
成である。

【図１９】本発明に係るソフトウェアのとりわけ３つの
層において発生し、申し込み要求がサービスに送り出さ
れるプロセスのフローダイヤグラムである。

【図２０】本発明に係るソフトウェアのとりわけ３つの
層において発生し、申し込み要求がサービスに送り出さ
れるプロセスのフローダイヤグラムである。

【図２１】申し込み要求がデータ発生プロセスで受け取
られ、メッセージが申し込みプロセスに送り返された際
に、本発明の教示に従ってソフトウェアインターフェイ
スのとりわけ３つの層において発生するプロセスの流れ
図である。

【図２２】申し込み要求がデータ発生プロセスで受け取
られ、メッセージが申し込みプロセスに送り返された際
に、本発明の教示に従ってソフトウェアインターフェイ
スのとりわけ３つの層において発生するプロセスの流れ
図である。

【図２３】メッセージが信頼性のある同報通信プロトコ
ルによって送り返された際に、ＤＣＣライブラリーおよ
び信頼性のある同報通信プロトコルエンジンにおいて発
生するプロセスの流れ図である。

【図２４】メッセージが信頼性のある同報通信プロトコ
ルによって送り返された際に、ＤＣＣライブラリーおよ
び信頼性のある同報通信プロトコルエンジンにおいて発
生するプロセスの流れ図である。

【図２５】信頼性のある同報通信トランザクションのデ
ータ消費サイドにおける信頼性のある同報通信プロトコ
ルエンジンによる処理の流れ図である。

【図２６】信頼性のある同報通信トランザクションのデ
ータ消費サイドにおける信頼性のある同報通信プロトコ
ルエンジンによる処理の流れ図である。

【図２７】インテリジェントマルチキャスト（商標）プ
ロトコルを実現するためのサービス統制において発生す
る処理の流れ図である。

【符号の説明】

１０・・・ホストコンピュータ １２・・・ホストコンピュータ １４・・・ネットワーク １６・・・アプリケーション １８・・・アプリケーション ２０・・・通信インターフェイス ２２・・・通信インターフェイス ３０・・・通信コンポーネント ３２・・・データ交換コンポーネント ８６・・・フォームマネージャ ８８・・・データ交換コンポーネント ９６・・・通信コンポーネント １２２・・・フォームクラスマネージャ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 マーク ボーレス アメリカ合衆国，カリフォルニア州 94602，ウッドサイド，トリッピー コ ート 30 (56)参考文献 特開 昭63−174159（ＪＰ，Ａ) 特開 平２−87274（ＪＰ，Ａ) 特開 平１−200434（ＪＰ，Ａ) 特開 平２−151975（ＪＰ，Ａ) 特開 昭63−294035（ＪＰ，Ａ) 特開 平１−177147（ＪＰ，Ａ) 特開 昭62−212720（ＪＰ，Ａ) 特開 平１−243154（ＪＰ，Ａ) 特開 平１−270163（ＪＰ，Ａ) 特開 平１−159751（ＪＰ，Ａ) 情報処理学会第33回（昭和61年後期) 全国大会講演論文集 ｐ1905−1906 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 15/16,13/00,9/46

Claims (20)

(57)【特許請求の範囲】
1. 【請求項１】ネットワークその他の通信路によって結合
   された、異なるコンピュータ上で動作するアプリケーシ
   ョン間でのデータ通信のための装置であって、 主題のデータを含むデータサービスアプリケーションと
   の通信を可能とするため、少なくとも１つのアプリケー
   ションから、特定の主題に関する情報の申込要求を受け
   て、前記情報を１以上のサービス統制手段にマッピング
   する手段、 前記サービスアプリケーション中の前記主題に関するサ
   ービスにアクセスするとともに、前記主題のデータを通
   信するため、前記データサービスアプリケーションによ
   り用いられるネットワークその他の通信路によって通信
   リンクを確立するため、前記マッピング手段によって決
   定された前記１以上のサービス統制手段を発動する手
   段、 前記申込要求がキャンセルされた時、前記通信リンクを
   終了させる手段を備え、その主題に関する情報が通信されることになっている前
   記１以上のアプリケーションにコールバック手段を備
   え、 前記コールバック手段は、前記申込要求に含められた名
   前によって、前記マッピング手段に確認され、 前記マッピング手段は、前記コールバック手段に転送す
   べきデータを受信する特定のサービス統制を決定するよ
   う構成された装置。
2. 【請求項２】請求項１に係る装置において、 前記マッピング手段は、該当する主題の情報を与えるサ
   ービスのためのネットワークアドレスを決定するための
   手段を備えている。
3. 【請求項３】請求項１に係る装置において、 前記要求された主題に関するデータだけが、前記確立し
   た通信リンクによって前記要求プログラムに供給される
   ように、前記データサービスアプリケーションにより出
   力されたデータを、主題によってフィルタリングするた
   めの、前記発動手段によって選択された手段を備えたも
   の。
4. 【請求項４】請求項３に係る装置において、 前記サービス手段の１つが、前記フィルタ処理を行う。
5. 【請求項５】請求項１に係る装置において、 前記サービス統制手段は、特定のサービス統制が関係す
   るサービスにアクセスするために適切な通信プロトコル
   を内包している。
6. 【請求項６】請求項１に係る装置において、 どのサービスがどの主題に関する情報を供給するか、当
   該サービスがどこに位置するかを示すサービスレコード
   を見いだすディレクトリ・サービス手段と、通信のため
   にサービスによって使用される特定のサービス統制手段
   とを備え、 前記ディレクトリ・サービス手段は、希望する主題に関
   する特定のサービスを示すサービスレコードを見いだす
   まで、サービスレコードをサーチし、見いだしたレコー
   ドを前記マッピング手段に送り返すために、マッピング
   手段からの、主題パラメータを含んだサーチ要求に応答
   する。
7. 【請求項７】請求項６に係る装置において、 前記サービスの各々に対応する前記サービスレコード
   は、希望する主題に関する情報を提供するサービスの名
   前および、そのサービスにより使用されるサービス統制
   手段の名前と、そのサービスが動作しているコンピュー
   タの名前を特定するデータを含む。
8. 【請求項８】請求項６に係る装置において、 前記ディレクトリーサービス手段は、前記ネットワーク
   やその他の通信路に接続されたコンピュータ上で動作し
   ている単独のプロセスとして動作している。
9. 【請求項９】請求項１に係る装置において、さらに、 前記ネットワークその他のデータ通信路において、通信
   リンクをセットアップするために、前記サービス統制手
   段の、前記ネットワークその他のデータ通信路の通信プ
   ロトコールに対するインターフェイスをとるため、前記
   サービス統制手段に結合されたデータ交換手段を備えた
   もの。
10. 【請求項１０】請求項９に係る装置において、前記デー
    タ交換手段は下記のa)b)を備えている： a)下記i)ii)双方のデータを含んだ自己記述的データレ
    コードまたはフォームを生成し、取り扱うための手段、 i)データ、および ii)名前およびフィールドの構成を当該フォーム中にお
    いて定義するとともに、データ表現のフォーマットを当
    該フィールド中において定義する１以上のクラス定義に
    対応するクラス識別子データ、 b)第２のアプリケーションに転送されるべき第１のアプ
    リケーションに固有のフォーマットにおけるフォームの
    フォーマットを、前記第２のアプリケーションのフォー
    マットに変換するための手段。
11. 【請求項１１】ネットワークその他の通信路によって結
    合された、異なるコンピュータ上で動作するアプリケー
    ション間でのデータ通信のための方法であって、 (a)アプリケーションのうちの１つにより、特定の主題
    に関する情報の要求を生成し、 (b) 前記主題のデータを含むデータサービスアプリケー
    ションと通信可能な１以上のサービス統制に、前記主題
    をマッピングし、 (c) 前記主題に関するデータを出力するために前記デー
    タサービスアプリケーションにより使用される前記ネッ
    トワークその他の通信路によって、通信リンクを確立す
    るために１以上のサービス統制を発動し、 (d) 前記申込要求がキャンセルされた時に前記通信リン
    クを終了させるステップを備え、さらにその主題に関す
    る情報が通信されることになっている前記１以上のアプ
    リケー ションに含まれるコールバックプログラムのステ
    ップを備え、 前記コールバックプログラムは、前記マッピング手段に
    前記申込要求に加えられたネームで確認されるととも
    に、 前記マッピングステップは、前記コールバック手段に転
    送すべきデータを受信する特定のサービス統制を決定す
    るデータ通信のための方法。
12. 【請求項１２】請求項１１に係る方法において、 前記マッピングステップは、該当する主題の情報を与え
    るサービスのためのネットワークアドレスを決定するス
    テップを備えている。
13. 【請求項１３】請求項１１に係る方法において、 前記要求された主題に関するデータだけが、前記確立し
    た通信リンクによって前記要求プログラムに供給される
    ように、前記データサービスアプリケーションにより出
    力されたデータを、主題によってフィルタリングするた
    めのステップを備えている。
14. 【請求項１４】請求項１１に係る方法において、 前記サービス統制の１つが、前記フィルターステップを
    行う。
15. 【請求項１５】請求項１１に係る方法において、 前記サービス統制は、特定のサービス統制が関係するサ
    ービスにアクセスするために適切な通信プロトコルを内
    包している。
16. 【請求項１６】請求項１１に係る方法において、 どのサービスがどの主題に関する情報を供給するか、当
    該サービスがどこに位置するかを示すサービスレコード
    を見いだすステップと、通信のためにサービスによって
    使用される特定のサービス統制と、 前記マッピング・ステップによって生成され、主題パラ
    メータを含むサーチ要求に応じて、希望する主題に関す
    る特定のサービスを示すサービスレコードを見いだすま
    で、収集した前記サービスレコードをサーチするステッ
    プ、 見いだしたレコードを前記マッピング手段に送り返すス
    テップ、 を備えたもの。
17. 【請求項１７】請求項１６に係る方法において、 前記サービスの各々に対応する前記サービスレコード
    は、希望する主題に関する情報を提供するサービスの名
    前およびそのサービスにより使用されたサービス統制の
    名前と、そのサービスが動作しているコンピュータの名
    前を特定するデータを含む。
18. 【請求項１８】請求項１６に係る方法において、 前記サービスレコードを見いだす前記ステップは、前記
    ネットワークその他の通信路に接続されたコンピュータ
    上で動作している単独のプロセスとして構成されてい
    る。
19. 【請求項１９】請求項１１に係る方法において、 前記ネットワークその他の通信路において、前記通信リ
    ンクをセットアップするために、前記発動された１以上
    のサービス統制の、前記ネットワークその他の通信路の
    通信プロトコールに対するインターフェイスをとるた
    め、前記発動された１以上のサービス統制に対応するデ
    ータ交換ステップをさらに備えている。
20. 【請求項２０】請求項１９に係る方法において、前記デ
    ータ交換ステップは下記のステップa)b)を備えている： a)下記i)ii)双方のデータを含んだ自己記述的データレ
    コードまたはフォームを生成し、取り扱うステップ、 i)データ、および ii)名前およびフィールドの構成を当該フォーム中にお
    いて定義するとともに、データ表現のフォーマットを当
    該フィールド中において定義する１以上のクラス定義に
    対応するクラス識別子データ、 b)第２のアプリケーションに転送されるべき第１のアプ
    リケーションに固有のフォーマットにおけるフォームの
    フォーマットを、前記第２のアプリケーションのフォー
    マットに変換するステップ。