JPH03148739A - ソフトウェア間の通信装置 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 ［産業上の利用分野］ 本発明は、ソフトウェアプロセスがデータの表現と編成
のために罵なるフォーマットを使用することがあり、ま
たは、同じフォーマットと編成を用いるが、後で再プロ
グラミングを要することなしに変更することがあるよう
な場合に、異なるコンピュータまたは同じコンピュータ
で行われているソフトウェアプロセスの間の情報交換を
切離す分野に関するものである。また、各ソフトウェア
プロセスが、外部のソフトウェアプロセスから受けたデ
ータを、意味の違いや、フィールド名の違−いとは無関
係に理解でき、かつ使用できるようにして「意味」情報
またはフィールド名情報を使用する。この意味情報はデ
ータ表現と編成情報から切離される。すなわち、本発明
はソフトウェア間の通信装置に関する。

［従来の技術と発明が解決しようとする課題Ｊ各種のコ
ンピュータおよびソフトウェアプログラムの増大と、種
々のソフトウェアプログラムで動作している種々のコン
ピュータに対してデータを交換するという常に存在する
必要性のために、そのようなデータ交換を可能にする装
置の需要が生じてきた。典型的には、互いに外部のもの
であるソフトウェアモジュールの間で交換せねばならな
いデータにはテキスト、データおよび図形が含まれる。

しかし、デジタル化した音声またはデジタル化したデー
タ、あるいはその他のより異なる態様の情報を交換する
必要もたまには生ずる。それら各種のデータは「原始」
と呼ばれる。ソフトウェアプログラムは、理解および取
扱いのためにそれがプログラムされる原始だ−けを取扱
うことができる。他の種類の原始は、データとしてソフ
トウェアに入れられた時に、誤りを生ずる。

ここで用いる「外部」という用語は、交換に含まれるソ
フトウェアモジュールまたはホストコンピュータが「異
なる言語を話す」ことを意味する。

たとえば、パーソナル・コンピュータおよびワークステ
ーションにおいて広く用いられているモトローラ（Ｍｏ
Ｌｏｒｏｌａ）およびインテル（Ｉｎｔｅｌ）のマイク
ロプロセッサは種々のデータ表現を用いており、マイク
ロプロセッサの１つの７１ミリイにおいては、複数バイ
ト語の最上位のバイトが最初に置かれ、プロセッサの他
のファミリイにおいては最上位のバイトが最後に置かれ
る。更に、アイビ−エム（ＩＢＭ）コンピュータにおい
てはテキスト文字がＥＢＣＤＩＣコードでコード化され
、他のほとんど全てのコンピュータにおいてはテキスト
文字はＡＳＣＩＩコードコード化される。また、整数、
浮動小数点等を含む数を表す何種類かのやり方がある。

更に、外部ソフトウェアモジュールが何種類かのデータ
編成法を用い、種々の意味情報、すなわち、データレコ
ード仲の各フィールドの名称と、それが意味するもの、
を用いる。

データ表現と編成のためにそれら各種のフォーマットを
用いることは、共通言語への翻訳、または１つのコンピ
ュータまたはプロセスの言語から別のコンピュータのま
たはプロセスの言語への翻訳を、有意な通信が行うこと
ができる前に、行わねばならない。更に、相互間に通信
を行う多くのソフトウェアモジュールが、互いに物理的
に離れていて、ローカルエリアネットワーク、広域ネッ
トワーク、ゲートウェイ、衛星等だけに接続される種々
のコンピュータにある。それら種々のネットワークは通
信のためにそれら自身の広く異なるプロトコルを有する
。また、少なくとも金融サービス業界において、ダウ・
ジョーンズ・ニュース（Ｄｏｗ　Ｊｏｎｅｓ　Ｎｅｗｓ
）またはＴｅｌｅｒａｔｅ？のような生データの種々の
ソースが種々のデータフォーマットと通信プロトコルを
用いる。それらのソースがらデータを受けるためにはそ
れらのフォーマットとプロトコルを理解しミそれらに従
わなければならない、普通株、証券、マネーマーケット
等についての金融データのような複雑なデータ状況にお
いては、データを入れ子式にすることがしばしば有川で
ある。すなわち、特定の主題についてのデータは、多数
の「フィールド」を有するデータレコードとしてしばし
ば編成される。各フィールドは主題の異なる面に属する
。特定のフィールドに副フィールドを持たせ、特定の副
フィールドにそれ自身の副フィールドを持たせる等と、
必要に応じた多くのレベルに対して副フィールドを持つ
ことができるようにするとしばしば有川である。ここで
の説明のために、この種のデータ編成を「入れ子」と呼
ぶことにする。フィールド名と、主題に対してフィール
ド名が意味するものを、ここでの説明のために「意味情
報」と呼ぶ特定のフィールドに対する実際のデータ表現
、すなわち、浮動小数点、整数、英数字等およびどれだ
けのフィールドを有するかという点でのデータレコード
の編成を、ここでの説明のために「フォーマット」情報
またはｒ種類」情報と呼ぶことにする。データだけを含
む（入れ子式の副フィールドを持たない）フィールドを
「原始フィールド」と呼び、他のフィールドを含むフィ
ールドをここでは「構成されたフィールド」と呼ぶこと
にする。

ソフトウェアモジュールの間のデータ交換において起る
ことが島る基本的な２種類の動作が島る。

第１の種類の動作は「フォーマット動作」と呼ばれ、１
つのデータレコード（以後、レコードのことを時に「フ
ォーム」と呼ぶことが島る）のフォーマットの別のフォ
ーマットへの変換を含む。そのようなフォーマット動作
の例は、浮動小数点フィールドおよびＥＢＣＤＩＣフィ
ールドを有するデータレコードのＥＴＩＩＥＲＮＥＴ？
ローカルエリアネットワークを介する伝送のために必要
なバックされた表現を有するデータレコードへの変換で
ある。受信プロセス端においては、ＥＴＩＩＥＲＮＥＴ
？パケットフォームから、受信プロセスモジュールまた
はソフトウェアモジュールにおける整フィールドおよび
ＡＳＣＩＩフィールドへの変換のための別のフォーマッ
ト動作が起ることがある。別の種類の動作をここでは「
意味依存動作」と呼ぶことにする。その理由は、それが
意味情報ピ対するアクセスを求めるとともに、フォーム
の特定のフィールド、たとえば、アイビ−エムの株の今
Ｈの値段またはアイビ−エムの株の昨日の安値、をそれ
を求めているあるソフトウェアモジュールへ供給すると
いうような、フォームに対しである作業を行うフォーム
についての種類情報またはフォーマット情報をアクセス
することを要求するからである。

またさらに、今日の環境においては、各種のデータの多
数のソースと、同じ種類のデータの多数のソースの少な
くとも一方がしばしば存在する。

この場合には、それらのソースは適用範囲が重なり合う
が、種々のフォーマットと種々の通信プロトコルを使用
する（または、同じフォーマットおよび同じ通信プロト
コルとも重なり合う）。その種の情報を供給するサービ
スのネットワークアドレスを知ることなしに、およびそ
の情報ソースと通信するために必要な特定の通信プロト
コルの詳細を知ることなしに、特定の主題についての情
報を得ることができることがソフトウェアモジュールに
とっては有川である（ソフトウェアモジュールのことを
以後「アプリケーション」と呼ぶことが時にある）。

したがって、種々のソフトウェアモジュールと種々のコ
ンピュータを「切離し」ながら、データの意義のある交
換を確実に行うために、種々のソフトウェアモジュール
と、種々のプロセスと、種々のコンピュータとの間にイ
ンターフェイスを設けることができる通信装置に対する
需要が生じてきた。「切離す」というのは、ソフトウェ
アモジュールプログラムが、他のソフトウェアと他のコ
ンピュータがネットワーク内のどこにあるのか、フォー
ムとデータが外部ソフトウェアにおいてとるフォーマッ
トと、外部のソフトウェアモジュールまたは外部のコン
ビーユータと通信するためにどの通信プロトコルを必要
とするか、または発信元プロセスと宛先プロセスの間の
任意のネットワークを通すためにどの通信プロトコルが
用いられるかを知ることなしに、および多数の生データ
ソ−スのうちのどれが要求されているデータを供給でき
るかを知ることなしに、ソフトウェアモジュールプログ
ラマが他のコンピュータまたは他のソフトウェアプロセ
スから情報をアクセスできることを意味する。更に、「
切離しＪは、ここで用いる用語としては、ある時にデー
タを供給でき、および１つのプロセスが、外部フォーマ
ットで作成されたフォームの例からの希望のデータと、
外部の意味データを、適切な意味オペレーションの通信
インターフェイスによる練習を通じて得て、外部フォー
ムから求められているデータを取出すことができること
を意味する。その取出し過程は要求しているプロセスに
とっては明らかである。

種々の切離し度を持つ外部ソフトウェアモジュールの間
で情報の交換を行えるようにする各種の装置が従来技術
に存在する。そのような種類の装置の１つが任意の電子
郵便ソフトウェアである。

このソフトウェアはＣＣＩＴＴのＸ、４０９規格を含　
めた電子文書交換規格を実現するものである。電子郵便
ソフトウェアは、フォーマットまたは種類のデータがデ
ータレコードすなわちフォームの各例に含まれていると
いう意味で、アプリケーションを切離す。しかし、意味
情報を記録または処理するための用意はされていない。

したがって、外部データ構造中の希望のフィールドの名
称または意味を基にしてデータの取出しまたは翻訳のよ
うな意味オペレーションは不可能である。意味に依存す
るオペレーションは、通信が成功したとするならば、非
常に重要である。更に、主題をベースとするアドレフシ
ングを実現できるようにする用意が電子郵便ソフトウェ
アには設けられていない。

この場合には、要求しているアプリケーションは、その
踵の情報のソースのアドレスを知ることなしに手段によ
る情報を単にたづねる。更に、そのソフトウェアは、通
信プロトコルがすでに設定されていないようなサービス
またはネットワークをアクセスできない。

関連するデータソフトウェアおよびデータ辞吉は、外部
プロセスがデータを共用できるようにするために、従来
技術におけるソーフトウェア装置の別の例である。この
種のソフトウェアの欠点は、それらのプログラムが「平
らな」表、レコードおよびレコード内のフィールドだけ
を取扱うことができ、レコード内の入れ子にされている
レコードを取扱うことができないことである。更に、電
子郵便ソフトウェアにおける上記欠点は関連するデータ
ベースソフトウェアにも存在する。

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

本発明のデータ通信インターフェイスソフトウェア装置
は、通信構成要素とデータ交換構成要素との２つの主な
構成要素に編成されたいくつかのプログラムライブラリ
ィでほぼ構成される。本発明のこの明細書で用いるイン
ターフェイスという用語は、外部プロセスと外部コンピ
ュータの少なくとも一方と通信を行うのに有用な作業を
行うために、アプリケーションにより呼出すことができ
る機能の集りを意味する。インターフェイスの呼出し機
能は、本発明に従って、アプリケーションから、または
通信インターフェイス内の別の構成要素からのサブルー
チン呼出しによるものとすることができる。

好適な実施例においては、インターフェイスの機能はサ
ブルーチンのライブラリィ中の種々のサブルーチンによ
り実行される。それらのサブルーチンが一緒になってイ
ンターフェイスを構成する。

もちろん、サブルーチンの代りに別々のプログラムまた
はモジュールを使用でき、ある場合には実際に好ましい
ことが当業者なら分かるであろう。

第１のフォーマットを有するデータレコードまたはフォ
ームを用いて第１のプロセスが、第２の異なるフォーマ
ットを有するデータレコードを有する第２のプロセスと
、第１のプロセスが第２のプロセスにより用いられるフ
ォーマットを知ったり、取扱うことができる必要なしに
、通信できるようにデータフォーマットの切離しが行わ
れる。

この切離しのフォームは通信インターフェイスソフトウ
ェアシステムのデータの交換構成要素を介して実現され
る。

本発明の通信インターフェイスのデータ交換構成要素は
フォームマネージャーモジュールとフォームクラスマネ
ージャーモジュールを含む。フォームマネージャーモジ
ュールはフォームの例の作成、格納、リコールおよび破
壊を取扱い、フォームクラスマネージャーの各種の機能
を呼出す。フォームクラスマネージャーは、特定のクラ
スのフォームに属するフォーマットと、意味情報を記録
するデータレコードであるフォームクラス記述子の作成
、格納、リコール、解釈、破壊を取扱う。

フォームクラスマネージャーはアプリケーション、また
は通信インターフェイスの別の構成要素からの要求も受
けて、フィールドの名称または意味により識別された時
に特定のフィールドを得、適切なフォームの例を検索し
、求められているデータを取出して、そのデータを適切
なフィールドに送る。フォームクラスマネージャーは、
そのようなりラス定義の既知の倉庫の中で調べることに
より、または、フォームの新しいクラスを作成した外部
プロセスに連結されているフォームクラスマネージャー
からのクラス定義を要求することにより、フォームの未
知クラスのクラス定義を探すこともできる。フィールド
名のような意味データが、データの表現または編成につ
いての情報を意味情報が含んでいないという意味におい
て、データの表現または編成から切離される。本発明の
通信インターフェイスは、意味的な意味およびデータフ
ォーマットの意味で、データの切離しを行う。意味的な
意味においては、意味に依存するオペレーションを実行
できる能力により実現される。それらのオペレーション
により、通信インターフェイスへ結合されている任意の
プロセスが、好適な実施例においては同じことを意味す
るデータのための同じフィールド名を用いることにより
、同じやり方で、または異なるやり方で編成されたデー
タを有する他の任意のプロセスとデータを交換できるよ
うにされる。別め実施例においては、意味に依存するオ
ペレーションは別名または同義変換機能を実現すること
により、異なる名を持つが、あることを意味する入来デ
ータが、要求しているプロセスにより理解されるフィー
ルド名を再びラベルづけされ、またはそれらがそのよう
に再びラベルづけされたかのように用いられる。

データ分配の切離しは、要求するプロセスが、データを
見つけることができるプロセスまたはサーバーのネット
ワークアドレスを知ることなしに、特定の主題について
のデータを要求できるように行われる。この種の切離し
は、通信インターフェイス内の主題をベースとするアド
レッシングシステムにより行われる。

主題をベースとするアドレッシングは、本発明の通信イ
ンターフェイスの通信構成要素により実現される。通信
構成要素は、データが要求されている主題を指定するア
プリケーションから「サブスクライブ」要求を受ける。

通信構成要素内の主題マツパモジュールがアプリケーシ
ョンから要求を受け、それからデータベース、表等内の
主題を探索する。データベースは、種々の主題について
のデータを供給する各種のサーバープロセスを指示する
「サービスレコード」を格納する。識別されたサーバプ
ロセスとの通信に使用するために、求められている種類
のデータと通信プロトコル（以後、時にはサービス訓練
と呼ぶ）を供給できる特定のサーバープロセスを識別す
る適切なサービスレコードが主題マツバモジュールへ戻
される。

主題マツパは「サービス訓練」と呼ばれる複数の通信プ
ログラムをアクセスする。各サービス訓練は、サーバー
プロセス、ネットワーク等に特有である所定の通信プロ
トコルを実現する。それから、サービスレコードにおい
て識別されている適切なサービス訓練を手段マブパが呼
込む。

サービス訓練には主題マツパによって主題が与えられ、
適切なサーバープロセスに対する通信の設定を続ける。

その後で、主題についてのデータを含んでいるフォーム
の例がサーバープロセスにより、通信を設定したサービ
ス訓練壱介して、要求するプロセスへ送られる。

サービスプロトコルの切離しは前節で述べたプロセスに
より行われる。

添字が代表的なものであるページに対してページの更新
を格納する実時間データベースをアクセスすることによ
り、Ｔｏｌｅｒａｔｅ？のようなページ向きのサーバー
プロセスへ向けられたあるサービス訓練において一時的
な切離しが実現される。

【実施例］ まず、本発明の通信インターフェイスを組込むことがで
きる典型的なシステムのブロック図が示されている第１
図を参照する。もつとも、広範囲のシステムアーキテク
チャが本発明の教示から利益を受けることができる。本
発明の通信インターフェイスのことを以下に説明する別
の実施例の説明においてＴＬＢすなわちテクネフロン（
Ｔｅｋｎｅｋ−ｒｏｎ）情報バスと時に呼ぶことにする
。この時点で、本発明を説明するためにここで用いるよ
り重要な用−のいくつかについて基本的な理解を得るた
めに、この明細書に含まれている用語について説明する
ことにする。本発明の教示はいくつかのコンピュータプ
ログラムのライブラリィに組込まれる。

それらのプログラムは、一緒になって、依頼人のアプリ
ケーションの開発のモジュールを容易にする多くの機能
を有し、各種の依頼人アプリケーションを「切離される
」やり方で一緒に結合することにより、ネットワーク通
信プロトコルまたはサービス通信プロトコルを変化する
過信インターフェイスを提供するものである。今后、本
発明の教示を通信インターフェイスと呼ぶことにする。

ここで用いる「切離す」という用語は、依頼人アプリケ
ーションのプログラマが、通信プロトコルの詳細と、デ
ータ表現フォーマットの細部と、データ交換を希望され
る他の全てのアプリケーションまたはサービスのデータ
レコード編成の細部とを知る必要から自由にされること
を意味する。更に、依頼人アプリケーションのプログラ
マは、特定の主題についてのデータを得ることができる
ために、それらの主題についてのデータを供給するサー
ビスまたはサーバーの場所を知る必要はない。通信イン
ターフェイスは、依頼人アプリケーションの間と、デー
タ消費者アプリケーションとデータ供給者サービスの間
のデータ交換における全ての細部に自動的に注意する。

第１図に示す装置は、多数のコンピュータをネットワー
クを介して、または共用するメモリにより結合する典型
的なネットワークである。

第１図には２つの依頼人アプリケーション１６．１８で
動作しているホストコンピュータ１０と１２が示されて
いる。もっとも、他の実施例ではそれら２つの依頼人ア
プリケーションは同じコンピュータで実行することがで
きる。それらのホストコンピュータはネットワーク１４
で結合できる。

そのネットワークはＥＴＩＩＣＲＮＥＴ？通信プロトコ
ル、トタンリングプロトコル等とすることができる。

データ交換のためのネットワークは本発明の実施例のた
めには不要である。というのは、従来技術で知られてい
る任意のデータ交換法が本発明を実施するために十分だ
からである。したがって、ホストコンピュータ１０と１
２が等しくアクセスする共用メモリファイルまたは共用
分布記憶装置も、本発明の教示を応用できる環境として
十分である。

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

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

第１図に示す例示的な装置においては、ホストコンピュ
ータ１０はそれのメモリに依頼人アプリケーションプロ
グラム１６を格納している。この依頼人アプリケーショ
ンプログラム１６は、有用な作業を行わせるためにホス
トコンピュータ１２を制御する別の依頼人アプリケーシ
ョンプログラムまたはサービス１８とのデータの交換を
求める。

また、ホストコンピュータ１６と１８はデータ表現のた
めに種々のフォーマットを使用し、アプリケーションプ
ログラム１６と１８は、それにより作成されるデータレ
コードのためのデータの表現と編成のために種々のフォ
ーマットを使用すると仮定する。それらのデータレコー
ドをここでは通常はフォームと呼ぶ。また、ホストコン
ピュータ１０と１２の間のデータ路１４がｌシＴＩＩＥ
ＲＮＥＴ？変形のローカルエリアネットワークで構成さ
れると仮定する。

各ホストコンピュータ１０と１２はプログラムのライブ
ラリィでもプログラムされる。それらのプログラムは通
信インターフェイス２０と２２をそれぞれ構成する。通
信インターフェイスプログラムは、結合器により依頼人
アプリケーションの編集されたレコードへ結合されて実
行時間コードを発生し、または通信プログラムのソース
コードが編集前に依頼人アプリケーションのソースコー
ドに含まれる。いずれにしても、通信ライブラリィはプ
ログラムは依頼人アプリケーションへ何とか結びつけら
れる。したがって、ホストコンピュータ１０が２つの依
頼人アプリケーションで動作しているとすると、各依頼
人アプリケーションはモジュール２０のような通信イン
ターフェイスモジュールへ結びつけられる。

通信インターフェイスモジュール２０の目的は、アプリ
ケーション１８と、アプリケーション１８のネットワー
クアドレスにより用いられるフォームでのデータのデー
タフォーマットと編成の細部と、アプリケーション１８
に用いられる通信プロトコルの細部と、ネットワーク１
４を通じてデータを送るために必要なデータフォーマッ
トの細部および通信プロトコルの細部とからアプリケー
ション１６を切離すことである。通信インターフェイス
モジュール２２はアプリケーション１８に対するのと同
じ機能を果し、それにより、アプリケーション１６とネ
ットワーク１４についての多くの細部を知る必要から自
由にする。通信インターフェイスモジュールはモジュー
ル化を容易にして、依頼人アプリケーションと、データ
フォーマットまたは編成と、ホストコンピュータとに変
更を生じることができるようにし、またはそれらの変更
の必要なしに上記の全てを一緒に結合させて、システム
全体にわたってリフプルさせ、継続して互換性を持たせ
る。

それらの機能のいくつかを実現するために、通信インタ
ーフェイス２０と２２はネットワーク１４を介して、主
題表１６とサービス表２８を含むネットワークファイル
システム２４をアクセスする。それらの表については、
後で主題を基にしたアドレッシングの説明に関連して詳
しく説明する。

それらの表には、各種の主題についての情報を提供する
サービスのネットワークアドレスが記されている。

通信インターフェイスを用いる典型的なシステムモデル
はユーザーと、ユーザー群と、ネットワークと、サービ
スと、サービスＭ（またはサーバー）と、主題とで構成
される。人間の端末ユーザーを表すユーザーはユーザー
ＩＤにより識別される。通信イ、ンターフエイスにおい
て用いられるユーザー！Ｄは通常はユーザーＩＤ１また
は基礎を成しているオペレーティングシステム（図示せ
ず）により用いられるログオンＩＤと通常は同じである
。しかし、これはそのような場合である必要はない。各
ユーザーは正確に１つの群の構成員である。

群は、類似のサービスアクセスパターンおよびアクセス
権を有するユーザーで構成される。サービスまたはシス
テム主題に対するアクセス権はユーザーのレベルと群の
レベルにおいて許可できる。

システム管理者はユーザーを群へ割当てる責任がある。

ここで用いる「ネットワーク」という用語は下側の「送
り層」　（この用語はＩＳＯネットワーク層モデルに用
いられるから）と、ＩＳＤネットワークモデル中の送り
層の下側の全ての層を意味する。アプリケーションは、
ホストコンピュータが取付けられている任意のネットワ
ークを介してデータを送信または受信できる。

本発明の通信インターフェイス、第１図におけるそれの
ブロック２０と２２は例である、は各依頼人アプリケー
ションに対して含む。そのアプリケーションには通信構
成要素３０とデータ交換構成要素３２が関係づけられる
。通信構成要素３０は共′通の通信機能セットであって
、たとえば、主題をベースとするアドレッシングとサー
ビス訓練切離しの少なくとも一方を実現−する。通信構
成要素は各依頼人アプリケーションへ結合される。また
、各通信構成要素は、それが結合されるネットワークの
標準的な送り層プロトコル、たとえばＴＣＰ、／ＩＰ、
へ結合される。各通信構成要素は多数の送り層プロトコ
ルへ結合されて、それらのプロトコルを支持できる。ネ
ットワークの送り層は次の事を行う。それは送り層アド
レスをネットワークアドレスにマシンし、送り層接続を
ネットワーク接続へ多重化してスループットを増大させ
、誤り検出とサービスの品質の監視を行い、誤りを訂正
し、セグメント化とブロッキング化を行い、ネットワー
クとセツション層への送り層の個々の接続の流れ制御と
、データ転送の促進とを行う。

通信構成要素は依頼人アプリケーションのために確実な
通信を行い、かつ場所の透過伝送機構とネットワークの
独立性を依頼人アプリケーションへ供給する。

通信インターフェイスのデータ交換構成要素、そのうち
の構成要素３２が典型的なものである、がデータをフォ
ームと呼ばれる自己記述データオブジェクト内にデータ
を包含させることにより、データを表現および送る協力
な方法を実現する。

それらのフォームは、対象とするデータばかりでなく、
データのために用いられる表現を記述する種類情報すな
わちフォーマット情報と、フォームの編成とを含む点で
自己記述的である。フォームはこの種類情報すなわちフ
ォーマット情報を含むから、１つのフォーマットを有す
る特定のフォームを別のフォーマットへ変換す−るため
のフォーマットオペレーションを、意味情報を与える、
データが読んだ他のクラス記述子すなわちクラス定義を
厳密に用いて行うことができる。クラス記述子における
意味情報の意味は、フォームのフィールドの名を基本的
に意味する。

フォームそれ自体のデータだけでフォーマットオペレー
ションを行う能力は、クラス記述子のような、他の場所
に設けられている他のデータオブジェクトに対してアク
セスせねばならない時に遭遇する遅延をそれが阻止する
から、非常に重要である。フォーマットオペレーション
単独で依頼人アプリケーションに対する処理時間の２０
〜５０％を典型的に占めるから、０己記述オブジェクト
を使用することにより、それを速くすることによフて処
理を能率的にする。

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

通信インターフェイスの最も下の層はＩＳＤモデルの送
り層に結合され、かつ、多数のネットワークを支持する
ための多数のサービス訓練プロトコルと多数の送り層プ
ロトコルを通信構成要素３０は含むから、ネットワーク
障害の場合に１つのネットワークから別のネットワーク
へ明らかに切換えるアプリケーション向きのプロトコル
を書くことが可能である。

「サービス」というは、アプリケーションの依頼人アプ
リケーションにより使用するために、そのアプリケーシ
ョンにより送り出されるる機能の有意セットを表すもの
である。サービスの例はダウ−ジョーンズ”　二＋Ｌ−
ス（Ｄｏｖ　Ｊｏｎｅｓ　Ｎｅｗｓ）、クオートロン（
Ｑｕｏｔｒｏｎ）データ送り、トレード・チケプト・ル
ータ−（Ｔｒａｄｅ　Ｔｉｃｋｅｔ　ｒｕｏｔｅｒ）の
ような歴史的ニュース検索サービスである。アプリケー
ションはただ１つのサービスを典型的に送り出すが、多
くの異なるサービスの送り出しも可能である。

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

ネットワークと、サービスおよびサーバーは従来技術で
知られている伝統的な構成要素であるが、従来技術の分
布された装置は、入れ子にされたデータオブジェクトを
自己記述することにより、主題のスペースまたはデータ
の独立性の概念を認識していない。主題スペースは、主
題をベースとするアドレフシングと呼ばれる切盾しの１
つのフォームを支持できる。多数のレベルにおいて入れ
子にできる自己記述データは新しい。ネットワークの他
の部分において優勢な種々の通信プロトコルおよびデー
タフォーマットからの依頼人アプリケーションの切離し
も非常に有用である。

主題をベースとするアドレッシングを実現するために用
いられる主題スペースは主題の部類の階層的なセットで
構成される。好適な実施例においては、４レベル主題ス
ペース階層が用いられる。

典型的な主題の例は「普通株、ｉｂｍ、混成、トレード
」である。通信インターフェイスへ結合されている依頼
人アプリケーションは、種々の主題部類の使用と解釈に
関する規約を制定するための自由と責任を有する。

各主題は、システムファイルに格納されているデータレ
コード中のその主題についてのデータを供給する１つま
たは複数のサービスに典型的に関連させられる。各サー
ビスには通信インターフェイスの通信構成要素において
サービス訓練、すなわち、そのサービスと通信するため
に必要な通信プロトコルすなわち手段が組合わされるか
ら、依頼人アプリケーションは、その主題についてのデ
ータを供給するサービス例が、その主題についての情報
を供給するサービスのネットワークアドレスなしに主題
だけを与えるように添字要求をすることにより、ネット
ワーク上に配置される。その主題についての情報をＩｉ
共する１つまたは複数のサービス例との実際の通信接続
に、それらの添字要求が通信インターフェイスにより翻
訳される。

主題部類のセットが主題領域と呼ばれる。多数の主題領
域が許される。各領域は領域に特有の主題と、メツセー
ジヘッダにおいて主題を表す効率的に表すコーディング
機能とを定めることができる。

データ独立：データ交換構成要素 通信インターフェイス−の第１図における構成要素３２
のようなデータ交換構成要素の全体的な目的は、アプリ
ケーション１６のような依頼人アプリケーションをデー
タ表現と、データ構成と、データの意味との細部から切
離すことである。

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

クラス定義はフィールドのリストを、フィールドの内容
の名とデータ表現により与える。各フィールドはフォー
ムを含み、各フォームは原始または構成されたとするこ
とができる。原始クラスフォームは実際のデータを格納
し、構成されたクラスは、原始または構成されたとする
ことができる他のフォームを含むフィールドを有する。

第２のクラス定義においては、評点、年齢、姓、名と名
づけられる４つのフィールドがある。各フィールドは原
始クラスフォームを含むから、このクラスのフォームに
おける各フィールドは実際のデータを含む。たとえば、
フィールド評点はクラス１１め原始フォームを常に含む
。クラス１１は浮動小数点と名づけられる原始クラスで
あって、このフィールドの内容に対して浮動小数点デー
タ表現を指定する。クラス浮動小数点、クラス１１、が
第５図に見られる。原始クラス１１のクラス定義はクラ
ス名、浮動小数点、を含む。それはクラス（クラス番号
、この例ではクラス１１、もクラスを独自に識別する）
と、１つのデータ値のデータ表現の仕様を独自に識別す
る。１つのデータ値の仕様は周知の予め定められたシス
テムデータ種類を用いる。それらのデータ種類はホスト
コンピュータと、このクラスのフォームを取扱うアプリ
ケーションにより理解される。

実際のデータ値のデータ表現に対する典型的な仕様は整
数、浮動小数点、ＡＳＣＩＩ文字列、またはＥＢＣＤＩ
Ｃ文字列等を含む。原始クラス１１の場合には、データ
値の仕様は浮動小数点１／１である。

これは、この原始クラスのフォームの例に格納されてい
るデータが２つのデジタル合計を有する浮動小数点であ
ることを示す表記法である。それの１つは小数点の右で
ある。

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

第３図はプレイヤーアドレス、クラス１００１、と名づ
けられた別の構成された−クラス定義を示す。

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

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

第４図のクラス定義はフォームの入れ子をどのようにし
て行うことができるかを示すものであって、フォームの
各フィールドはフォーム自体であり、あらゆるフォーム
は原始にでき、ただ１つのフィールドを有し、または構
成され、かついくつかのフィールドを有する。いいかえ
ると、フォームの例は必要な数のフィールドを有するこ
とができ、各フィールドは必要な数の副フィールドを有
することができる。更に、容態フィールドは必要な数の
副−副フイールドを有することができる。

この入れ子構造は任意の数のレベルにわたって進む。こ
のデータの構造により任意の複雑さのデータを容易に表
現し、かつ取扱うことができるようにされる。

次に、メモリにオブジェクトとして格納されている、ト
ーナメントエントリイ、クラス１００２、として名づけ
られている第６図を参照する。

データのブロック３８は、これがトーナメントエントリ
イと名づけられている構成されたクラスのフォームの例
であることを示す、構成されたクラス番号１００２を含
む。データブロック４０は、このクラスのフォームが３
つのフィールドを有することを示す。それら３つのフィ
ールドは、それらのフィールド内のフォームのクラス番
号を含んでいる、４２．４４．４６で示されているデー
タブロックを有する。第１のフィールドが第５図に示さ
れているようなりラスｌＯのフォームを含むことをデー
タブロック４２は示す。クラス１０フォームは、第５図
においてクラス１０に対するクラス定義で定義されてい
るＡＳＣＩＩ文字の２０文字列を含んでいる原始フォー
ムである。このフォームのこの特定の例に対するＡＳＣ
ＩＩ文字の実際の列が４８で示され、これはＵ、Ｓ、オ
ーブンテニストーナメントに対するトーナメントエント
リイであることを示す。データブロック４４は、第２の
フィールドが、クラス１０００の構成されたフォームの
例であるフォームを含んでいることを示す。

このクラス定義を参照すると、このクラスはプレイヤ一
名と名づけられていることを示す。データブロック５０
は、そのクラスの構成されたフォームが４つの副フィー
ルドを含むことを示す。それらのフィールドはデータブ
ロック５２．５４．５６．５８に記録されているクラス
のフォームを含む。それらのフィールドはフィールド４
４の副フィールドである。第１の副フィールドはデータ
ブロック５２を有して、この副フィールドが原始クラス
１１のフォームを含むことを示す。このクラスのフォー
ムは、第５図において、１つの少数場所を有する浮動小
数点の２桁の数を含んでいるものとして示されている。

フォームのこの例に対する実際のデータが６０で示され
て、このプレイヤーのエントリイ評点が３．５であるこ
とを示す。

第２の副フィールドはデータブロック５４を有し、この
副フィールドは原始クラス１−２のフォームを含むこと
を示す。第２図に示されているクラス１６００に対する
クラス定義は、クラスが整数と名づけられて、整数デー
タを含むことを示す。第２図に示されているクラス１０
００に対するクラス定義は、ブロック６２に示されてい
る、整数データがプレイヤーの年令であることを示す。

フィールド名についてのクラス定義意味データはフォー
ム例には格納されないことに注目されたい。フォーマッ
ト情報または種類情報だけが、各フィールドに対してク
ラスＩＤのフォーム中のフォーム例に格納される。第３
の副フィールドはデータブロック５６を含み、この副フ
ィールドがストリング２０ＡＳＣＩＩと名づけられた原
始クラス１０のフォームを含むことを示す。この副フィ
ールドは、第２図に示されている、クラスプレイヤ一名
、クラス１０００、のフォームのフィールド姓に対応す
る。原始クラス１０クラス定義は、この原始クラスの列
が２０文字ＡＳＣＩＩストリングを含むことを指定する
。このストリングはプレイヤーの姓をたまたま定める。

第６図に示す例においては、プレイヤーの姓は６４に示
すようにブララケット（旧ａｃｋｌｅｔ）である。

最後の副フィールドはデータブロック５８を有する。こ
れは、２０文字Ａ５ＣＩ　Ｉストリングである。

原始クラス１０の原始フォームをフィールドが含んでい
ることを示す。この副フィールドは、プレイヤの名を含
んでいるものとして、クラス１０００のクラス定義にお
いて定義される。このＡＳＣＩＩストリングが６６で示
されている。

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

次に、意味情輯と、フォーマット情報と、クラス定義と
このクラスのフォームの例との−間の実際のデータとの
区分が示されている第７図を参照する。フィールド名と
、フォーマットすなわち種類の情報とは、ボックス８２
に示されているようにクラス定義中に格納される。フォ
ーマットの情報すなわち種類情報（クラス１０のフォー
ムにおいて）と、実際のデータまたはフィールド値は、
ボックス７２に示すように、フォームの例に格納される
。たとえば、クラストーナメントエントリイ、第６図に
示されているクラス１００２、のフォームの例において
は、第１のフィールドに対するフォーマツ°トデータが
ブロック４２に格納されているデータであり、第１のフ
ィールドに対する実際のデータはブロック４８に示され
ているデータである。本質的には、クラス番号すなわち
クラス■Ｄは通信インターフェイスにより、その原始ク
ラスのフォームの例におけるデータの種類に対する仕様
に等しくされる。したがって、通信インターフェイスは
、クラス定義をアクセスする必要なしに、フォーム自体
の例に格納されているフォーマットデータだけを用いて
特定のフォームの例に対してフォーマットオペレーショ
ンを実行できる。

これは、ネットワークアクセスとディスクアクセスのス
トリングなくとも１つを含むことがあって、オペレーシ
ョンを十分に遅くする、クラス定義をアクセスすること
を要求するためのステップを行う必要をなくすことによ
り、フォーマットオペレーションの動作速度を向上させ
る。フォーマットの種類オペレーションは外部プロセス
内のデータ交換における全ての動作の集まりを有するか
ら、データ構造と、ここで定義されているデータ構造を
取扱うためのプログラムのライブラリィとは、外部プロ
セスと外部コンピュータの間のデータ交換の効率を大幅
に向上させる。

たとえば、第６図に示されているフォームの例が、デジ
タル・イクイップメント・コーポレーション（旧ｇｌＬ
ａｌ　Ｅｇｕｉｐ＠ｅｌｔ　ＣＯｒｐＯｒｒａｔｌＯｒ
ｔ）（ＤＥＧ）により製造されたコンピュータで行われ
るプロセスにより発生され、したがってテキストでＡＳ
ＣＩＩ文字で表されるものと仮定する。またフォームが
アイビ−エム（ＩＢＭ）コンピュータで行われているプ
ロセスへ送るべきものであると仮定する。アイビ−エム
コンピュータでは文字ストリングはＥＢＣＤＩＣコード
で表されている。更に、それら２台のコンピュータがＥ
ＴＩＩＥＲＩＩＩＥＴ？通信プロトコルを用いてローカ
ルエリアネットワークにより結合されるものと仮定する
。

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

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

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

フォーマットオペレーションは通信インターフェイスの
フォームマネジャーモジュールによって行われる。たと
えば、仮定的な転送における最初のフォーマットオペレ
ーションは第１図のフォームマネジャーモジュール８６
により行われ、一方、仮定的な転送における第２のフォ
ーマットオペレーションはデータ交換構成要素８８にお
けるフォームマネジャーモジュールにより実行される。

次に、フォーマットオペレーションの実行においてフォ
ームマネジャーモジュールにより行われるオペレーショ
ンの流れ図が示されている第８図を参照する。通信イン
ターフェイスのフォームマネジャーモジュールにおける
ルーチンの各種の機能についての詳細が、ここに含まれ
ている通信インターフェイスの各種のライブラリィルー
チンについての機能の使用中に見出だされる。第８図の
プロセスは、本発明の通信インターフェイスの中のデー
タ交換構成要素のフォームマネジャーモジュール中のソ
フトウェアプログラムにより実現される。第１のステッ
プはアプリケーションから、または通信インターフェイ
ス中の別のモジュールからフォーマット変換呼出しを受
けることである。

このプロセスはブロック９０と第１図の経路９２．９４
とにより記号化される。同じ種類の呼出しを第１図にお
けるホストコンピュータ１２に対してアプリケーション
１８または通信構成要素９６により、データ交換構成要
素８８中のフォームマネジャーモジュールに対して行う
ことができる。その理由は、これは、本発明の通信イン
ターフェイスにより全ての依頼人アプリケーションへ提
供される標準的な機能すなわち「ツール」だからである
。あらゆる依頼人アプリケーションは第１図のインター
フェイス２０のように通信インターフェイスへ結合され
る。

典型的には、第１図のモジュール３０と９６のような通
信構成要素からフォー４マネジャーモジュールへのフォ
ーマット変換呼出しは、フォーマット１のフォームをフ
ォーム２を用いる外部アプリケーションへ送るタスクを
命じられたサービス訓練モジュールからである。通信イ
ンターフェイス中の別のモジュールからのフォーマット
変換呼出しについての別の同様なシナリオは、サービス
訓練が、外部フォーマットであって、依頼人アプリケー
ションのフォーマットへ変換する必要がある別のアプリ
ケーションまたはサービスからフォームを受けた時であ
る。

フォーマット変換呼出しにはパラメータが組合わされ、
それらのパラメータはフォームマネジャーへ与えられる
。それらのパラメータは「取出し」フォーマットと「受
入れ」すなわち「ターゲット」フォーマットを指定する
。ブロック９８は指定された変換のための適切なターゲ
ットフォーマット特有の表をアドレッシングするプロセ
スを表す、すなわち、指定された「取出し」フォーマッ
トが、各原始「取出し」フォーマットクラスに対する適
切なターゲットフォーマットについての詳細を与えて、
変換を終らせる専用の表を有する。好適な実施例におい
ては、あらゆる変換オペレーション中に順次アドレスさ
れる２つの表がある。別の実施例においては、それら２
つの表を組み合わせることができる。好適な実施例にお
いて用いられる２つの表の例が第９〜１１図に示されて
いる。第９図はＤＥＣマシンからＸ、４０９フォーマッ
トへ変換するための特定のフォーマット変換表を示す。

第１０図はＸ、４０９フォーマットからアイビ−エム・
マシンフォーマットへの変換のためのフォーマット特有
変換表を示す。第１１図は、各「取出し」−「受入れ」
フォーマット対に対して特定の変換を行う通信インター
フェイスライブラリィ中の変換プログラムの名称を１則
する全体的な変換手順表を示す。

第９図と第１０図の表は、第１図のアプリケーション１
６からアプリケーション１８ヘッオームを送るために必
要なだけの表ではおそらくない。

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

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

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

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

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

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

次に、第８図のブロック１０４に示されているプロセス
は、第１１図に示されている全体的な変換手順をアクセ
スすることによって行われる。これは、フォームの１つ
の原始クラスをフォームの別の原始プログラムへ変換す
る実際の作業を実行するフォームマネジャー中の変換プ
ログラムを識別する表である。この表はあらゆる「取出
し」−「受入れ」フォーマット対のための１つのエント
リイで編成される。「取出し」−「受入れ」対に対する
表中のエントリイは、変換の実際の作業を行う変換ルー
チンの名称を含む。ブロック１０４　に示されているプ
ロセスは、ステップ１０２におけるフォーマット特有の
変換表をアクセスすることから決定される「取出し」−
「受入れ」対を取り、「取出し」−「受入れ」一致を有
するエントリイが見出だされるまで、全体的な変換手順
表のエントリイを探索する。この場合には、第１１図の
表の一番上からの第３のエントリイが、第９図へのアク
セスにおいて見出だされた「取出し」−［受入れ」フォ
ーマット対に一致する。このエントリイは読出され、こ
の変換を行うためのルーチンの名称がＡＳＣＩＩ　　Ｅ
ＴＩＩＥＲであると決定される。

（多くの実施例においては、名称ではなくて、ルーチン
のメモリアドレスが表に格納される。）第８図のブロッ
ク１０６は、ブロック１０４で識別された変換プログラ
ムを呼出し、この変換ルーチンを行って、ステップ１０
０で選択したフィールドの内容を、ステップ１０２で識
別された「受入れ」フォーマットすなわちターゲットフ
ォーマットへ変換することを行うプロセスを示す。

仮定した例においては、ルーチンＡＳＣＩＩ　　ＥＴＩ
ＩＥＲが呼出され、ステップ１０６により実行される。

このルーチンを呼出すと、ステップ１００のプロセスに
おいて選択されたフィールド、すなわち、第６図に示す
フォームの例のフィールド４２、に格納されている実際
のデータを供給して、テキストストリングｒＵ、ｉ　オ
ープン」がバブツされたＥＴＩＩＥＲＮＥＴ？フォーマ
ットへ変換されるようにする。

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

フォームの原始クラスを含んでいるフィールドが処理さ
れたままであるとすると、ブロック１１２で示されてい
るプロセスが実行される。このプロセスはフォームの原
始クラスを含んでいる次のフィールドを見つける。

その後で、フォームの原始クラスを含んでいる全てのフ
ィールドが適切な「受入れ」フォーマットへ変換される
まで、ブロック１０２．１０４．１０６．１０８により
示されている処理ステップが実行される。上記のように
、フォームの原始クラスを含んでいるフィールドを探索
するステップは、変換すべきフォームを通って直列に進
む。次に出会うフィールドが構成されたクラスのフォー
ムを含んでいるとすると、フォームの原始クラスを内部
に有する最初のフィールドが探索されるまで、フォーム
のそのクラス自体が探索される。全てのフィールドが処
理され、フォームに格納されている全てのデータが適切
なフォーマットに変換されるまで、その全てのフィール
ドに対するあらゆる入れ子レベルにわたってそのプロセ
スは続く。

これかどのようにして行われるかの例として、第６図の
フォームにおいては、第１のフィールド４２の処理の後
で、第８図のブロック１１２により示されているプロセ
スがフィールド４４に次に遭遇する（フィールドは、そ
のフィールドに格納されているフォームに対するクラス
ＩＤを含んでいるデータのブロックにより参照されるが
、フィールドの内容はクラスＩＤと実際のデータであり
、またはそのフィールドに格納されているオームのフィ
ールドと副フィールドである）。第６図により表されて
いるフォームの特定のクラスにおいては、いくつかの副
フィールドで構成されている構成されたフォームを第２
のフィールド４４が含むことに注目されたい。それから
処理はクラス１０００の構成されたフォームをアクセス
する。そのフォームは第２のフィールドにより格納され
、原始クラスのフォームを含んでいるそれの第１のフィ
ールドをそれが探すまで、その構成されたフォームの中
を直列に進む。第６図の仮定例においては、第１のフィ
ールドは５２におけるクラス番号１１により示される副
フィールドである。それから、ブロック１０２により示
されているプロセスは第９図の表中の「取出し」列内の
クラス１１を探索し、ターゲットフォーマットが原始ク
ラス１５のクラス定義により指定されるターゲットフォ
ーマットが指定されると決定される。それから、この「
取出し」−「受入れＪ対１１〜１５が第１１図の表のエ
ントリイと比較されて一致するエントリイを見出だす。

その後で、第８図のブロック１０６のプロセスが、ＦＩ
Ｏａｔｌ　　ＥＴＩＩＥＲと呼ばれる変換プログラムを
実行し、第６図の６０におけるデータのブロックを適切
なｃｒｎＥＲＮｃＴ？パックされたフォーマットへ変換
する。それから、このプロセスは全ての入れ子レベルを
続行する。

次に、典型的な意味依存オペレーションにっ−いての流
れ図が示されている第１２図を参照する。

フィールド名が既知で、フォーム例のアドレスが既知で
あるならば、外部アプリケーションにより発生されたフ
ォームの例の特定のフィールド中のデータを１つのアプ
リケーションが得ることができるようにすることにより
、アプリケーションの切離しを許す。本発明の通信イン
ターフェイスは、好適な実施例においては、フィールド
を得る呼出しの態様で依頼人アプリケーションから意味
依存オペレーション要求をうける。その好適な実施例に
おいては、全てのプロセスは、同じことを意味するデー
タフィールドに対する同じフィールド名を用いる（フォ
ームの編成、または外部プロセスにより発生されたフォ
ームでのフィールドのデータ表現とは無関係に）。別の
実施例においては、エイリアシング表または同義表ある
いはデータベースが用いられる。そのような実施例にお
いては、フィールドを得る呼出しを用いてクラスマネジ
ャー内の同義表をアクセスし、要求されたフィールド名
の全ての同義語を探す。求められているフィールド名と
同義である全てのフィールド名は戻される。それから、
クラスマネジャーは、求められているフィールド名また
は同義名のいずれかとの一致のためのクラス定義を探し
、一致フィールドを有するフィールドを検索する。

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

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

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

それから、クラスマネジャーはクラス定義フィールド名
を探索して、元の呼出しにおいて与えられたフィールド
名の一致を見出だす。このプロセスがブロック１２４に
示されている。−対象とするフィールドをクラス定義中
で探した後で、クラスマネジャーは相対的なアドレスポ
インタを、このクラスのフォームの例中め対象とするフ
ィールドへ戻す。このプロセスが第１２図のブロック１
２６に示されている。クラスマネジャーにより戻される
この相対的なアドレスポインタは第２図、第４図、第６
図を参照とすることによって最も良く理解される。フィ
ールドを得る呼出しを行ったアプリケーションが、特定
のプレイヤーの年令の決定に興味を持ったと仮定する。

フィールドを得る要求は、第６図に示すように、プレイ
ヤーのブラケット（Ｂｌａｃｋｔｔ）に対するクラス１
００２のフォームの例のためのアドレスを識別する。ま
た、フィールドを得る要求には対象とするフィールドの
名称、すなわち、「年令Ｊも含まれる。それからクラス
マネジャーは対象とするフォームの例をアクセスし、フ
ォームのこのクラスへ加えられる特定のクラス識別子ま
たはクラス定義を自己記述別するクラス番号を読出す。

それから、クラスマネジャーは第４図に示すように、ク
ラス１００２のだめのクラス記述子をアクセスし、クラ
ス定義を見つける。次に、クラスマネジャーはクラス定
義１００２の各フィールドに対するクラス定義をアクセ
スし、元のフィールドを得る要求中のフィールド名を、
クラス１００２に対するりラス定義を構成する種々のク
ラス定義中のフィールド名と比較する。いいかえると、
クラスマネジャーは、クラス１０．１００および１００
１に対するクラス定義中のフィールドの名、「年令」、
も含まれる。それからクラスマネジャーは対象とするフ
ォームの例をアクセスし、フォームのこのクラスへ加え
られる特定のクラス識別子またはクラス定義を識別する
クラス番号を読出す。それから、クラスマネジャーは第
４図に示すように、クラス１００２のだめのクラス記述
子をアクセスし、クラス定義を見つける。次に、クラス
マネジャーはクラス定義１００２の各フィールドに対す
るクラス定義をアクセスし、元のフィールドを得る要求
中のフィールド名を、クラス１００２に対するクラス定
義を構成する種々のクラス定義中のフィールド名と比較
する。いいかえると、クラスマネジャーは、クラス１０
．１０００および１００１に対するクラス定義中のフィ
ールドの名、「年令」、を対象とするフィールド名と比
較する。第２図かられかるように、クラス１０００につ
いてのクラス定義において一致が見出だされる。第６図
に示されている特定のレコードフォーマットに対して、
「年令」フィールドはデータブロック６２である。その
データブロックはレコードのスタートから１０番目のデ
ータブロックである。それからクラスマネジャーは第１
２図のブロック１２６内の１０の相対的なアドレスポイ
ンタを戻す。この総体的なア、ドレスポインタは、元の
フィールドを得る呼出しを行った依頼人アプリケーショ
ンへ戻される。それから依頼人アプリケーションはデー
タを得る呼出しをフォームマネジャーモジュールへ発し
、対象とするフォームの特定の鍔内の希望のフィールド
の相対的なアドレスをフォームマネジャーモジュールへ
供給する。フォームマネジャーモジュールは、元のフィ
ールドを得る呼出しがフォームマネジャーモジュールを
通ってきて、フォームクラスマネジャーへ戻されるなら
ば、それが既に有するであろう対象とするフォームの例
のアドレスも知らなければならない。フォームマネジャ
ーモジュールが対象とするフォームの特定の例のアドレ
スを有しないとすると、フォームマネジャーは依頼人ア
プリケーションからそれを要求する。データを得る呼出
しを受け、相対的なアドレスと、対象とするフォームの
例のアドレスとを得た後で、フォームマネジャーはフォ
ームのこの例をアクセスし、かつ求められているデータ
をアクセスし、それを依頼人へ戻す。データを得る呼出
しを受ける呼出しを受け、適切なデータを第１２図のブ
ロック１２８により、適切なデータを戻すこのプロセス
が示されている。

次に、切離しの２つの重要なフォームを実現するために
協同する各種のソフトウェアモジュールと、ファイルと
、ネットワークと、コンピュータとのブロック図が示さ
れている第１４図を参照する。切離しのそれらのフォー
ムはデータ分配切離しおよびサービスプロトコル切離し
である。データ分配切離し手段は希望のサービスを行う
サーバーに対するネットワークアドレスを知る必要から
依頼人アプリケーションを自由にする。したがって、た
とえば、ダウ・ジョーンズ・ニュース・サービス（Ｄｏ
ｖ　Ｊｏｉｅｓ　Ｎｅｗｓ　Ｓｅｒｖｌｓｅ）により供
給される情報を特定のアプリケーションが知る必要があ
るものとすると、依頼人アプリケーションは、どのサー
バーおよびどの場所がダウ・ジョーンズ・ニュース・サ
ービスから生のデータを供給しているかを知る必要がな
い。

データの交換が望まれるサーバー、サービス、その他の
アプリケーションにより用いられるネットワークプロト
コルおよび通信プロトコルの全ての層を横切るために特
定の通信プロトコルを、依頼人アプリケーションが知る
必要がないことをサービスプロトコル切離しは意味する
。

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

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

主題をベースとするアドレッシングは、ホストコンピュ
ータ１０で実行している依頼人アプリケーション１６に
より、主題マツパ１８０に対する申込み呼出し１８８で
開始される。申込み呼出しは特定の主題に関する情報に
対する要求である。

特定の主題が普通株主権、ＩＢＭ、ニュースであると仮
定する。この申込み呼出しは２つのパラメータを主題マ
ツパ１８０へ送る。それらのパラメータの１つは主題普
通株主権、ＩＢＭ、ニュースである。他のパラメータは
、主題についてのデータを送らねばならない依頼人アプ
リケーション１６における呼出しルーチンの名称である
。主題マツパ１８に対する申込み呼出しは標準的な手順
呼出しである。

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

線１９４により示されている。主題マツパへ送り返され
るサービスレコードは多くのフィールドを含む。サービ
スレコード内での求められる２つのレコードは、希望の
主題についての情報を提供するサービスの名称と、その
サービスにより用いられるサービス訓練の名称である。

供給できる他の選択できるフィールドは、そのサービス
を実施するサーバーの名称と、そのサーバーのネットワ
ークにおける場所である。

一般に、住所録サービス構成要素は主題サービスが存在
する全てのサービスレコードを供給する。

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

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

サービスレコードを受けると、主題マツパは識別された
各サービス訓練を呼出して、主題と、そのサービス訓練
へ加えることができるサービスレコードをそれへ送る。

第１４図にはただ３つのサービス訓練１８２．１８４．
１８６が示されているが、実際のシステムでは３つより
も多くのものを設けることができる。住所録サービス構
成要素１９２が存在しないか、一致を見出ださないとす
ると、主題マツパ１８０へはサービスレコードは戻され
ない。この場合には、主題マツパは省略時サービス訓練
を呼出して、それと主題および零レコードを送る。

谷サービス訓練はソフトウェアモジュールであって、そ
のサービス訓練に関連する特定のサービスと通信するた
めに最適にされた特注のサービスを含む。

主題マツパ１８０により呼出された各サービス訓練はそ
れへ送られたサービスレコードを調べ、通信を行うべき
サービスの場所を決定する。考察している特定の仮定し
た例においては、住所録サービモジュール１９２により
ただ１つのサービスレコードが戻されていること、その
サービスレコードがサーバー１９６で行われているダウ
ジョーンズニュースサービスを識別すること、および１
８２においてサービス訓練Ａを、サーバー１９６におけ
るダウジョーンズニュースサービスと通信するために適
切なサービス訓練として識別する。

それから、サービス訓練Ａは要求メツセージを線１９８
で示されているようにサーバー１９６へ送る。この要求
メツセージは主題をサービスへ送り、サービスレコード
の全部または一部を送ることができる。

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

通信がそのようにしてひとたび設定されたとすると、要
求されている主題に関連する情報の全ての項目を、経路
２０２で示されているように、適切なサービス訓練へ連
続して送る。ここで選択した例においては、サーバー１
９６で行われるサービスは、サービス訓練１８２へ送る
ためにアイビ−エムに関連する新しい事項だけを抽出す
る。

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

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

依頼人アプリケーション１６が取消し指令を主題マツパ
１８０へ明確に送るまでは、データは名称をつけられて
いる呼戻しルーチン２０４へこのようにして流れ続ける
。主題マツパ１８０は存在している全ての申込みのレコ
ードを保存して、有効である種々の申込みと取消し指令
を比較する。

一致が見出だされたとすると、適切なサービス訓練に取
消−し要求が知らされ、それからこのサービス訓練が取
消しメツセージを適切なサーバーへ送る。それからサー
ビスは、その主題についてのそれ以上のデータを、取消
し要求を送ったサービス訓練へ送ることを止める。

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

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

好適な実施例における実際の申込み機能は、仕様の４節
に述べられているＴＩＢ消費作成ライブラリィルーチン
を実行することにより行われる。

ＴＩＢ消費作成に対する呼出しは、それへ送られたパラ
メータの特性リストを含む。それの１つが、仕様の４節
における私のメツセージ／Ｘンドラーとに指定されてい
る呼戻しルーチンである。

仕様においては、主題をベースとするアドレッシング申
込みサービス機能がＴＩＢＩＮＦＯとして示されている
。このＴＩＢＩＮＦＯインターフェイスは２つ　　　　
　　のライブラリィより成る。初のライブラリィはデー
タの需要者に対するＴＵＢ冨ＮＰＯＣＯＮＳＵＮＥと呼
ばれる。第２のライブラリィはデータ供給者に対するＴ
ＩＢＩＮＰＯＰ［ｌＢＬＩＳｆｌと呼ばれる。あるアプ
リケーションは、それが消費需要者か、供給者か、ある
いは両方であるかに応じて、一方のライブラリィ１、ま
たは他方のライブラリィ、あるいは両方のライブラリィ
を含む。アプリケーションは需要者と供給者を同時に兼
ねることができる。

次に、本発明のインターフェイスとアプリケーション、
およびそれらのアプリケーションを結合するネットワー
クの関係のブロック図が示されている第１５図を参照す
る。第１図におけるブロックの参照番号と同じものがつ
けられているブロックは、第１図における対応するブロ
ックに類似の機能を有する。第１５図のブロック図は好
適な実施例のプロセスアーチキクチャを示す。第１５図
に与えられているプロセスアーチキクチャに対応するソ
フトウェアアーチキクチャが第１６図にブロックで示さ
れている。− 第１５図を参照して、第１図の通信構成要素３０は、第
１５図では２つの別々の機能ブロック３０Ａ、３０Ｂと
して示されている。すなわち、第１図における通信構成
要素の機能が第１５図のプロセスアーチキクチャでは２
つの機能ブロックの間に分割される。通信ライブラリィ
３０Ａは各依頼人アプリケーション１６へ結合され、バ
ックエンド通信デーモン３０Ｂがネットワーク１４と通
信ライブラリィ３０Ａへ結合される。ホストプロセッサ
当り１の通信デーモンが存在することが典型的である。

このホストプロセッサは第１５図には２３０で示されて
いるが、第１６図には全て示されていない。第１５図に
おいては、第１図の状況とは異なって、依頼人アプリケ
ーション１６と１８は同じホストコンピュータ２３０で
実行されることに注目されたい。各依頼人アプリケーシ
ョンは、通信ライブラリィ３０Ａと９６中の各種のライ
ブラリィプログラムのそれ自身のコピーと、データ交換
要素３２と８８のフォームライブラリィのそれ自身のコ
ピーとへ結合される。プログラムのそれらの結合された
ライブラリィは共通の通信デーモン３０Ｂを共用する。

　　一 種々のホストプロセッサにおける通信デーモンはそれら
自身の間で協同して、マシンの間で確実かつ効率的な通
信を行えるようにする。主題をアドレスされたデータに
対しては、デーモンは、主題によりメツセージを抽出す
るために低レベルのシステムサポートを行うことにより
、それの効率的な送信を助ける。

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

本発明の通信インターフェイスのデータ交換構成要素は
［フォームライブラリィ」と呼ばれるライブラリィとし
て実現される。このライブラリィは依頼人アプリケーシ
ョンへ結合され、データ交換構成要素の全ての中核機能
を提供する。フォームライブラリィは通信ライブラリィ
とは独立に結合でき、それの動作のために通信デーモン
３０Ｂを要求することはない。

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

第１５図におけるブロック２３１．２３３．２３５は、
通信ライブラリィ３０Ａとフォームライブラリィ３２中
のプログラムにより実現されるインターフェイス機能を
表す。ＴＩＢＩＮＦＯインターフェイス２３３は、申込
み呼出しとして知られている通信パラダイムにより、主
題をベースとするアドレッシングサービスを行う。この
パラダイムに　おいては、データ需要者はサービスまた
は主題を申込み、需要者が申込みを明確に終らせる（ま
たは障害が起る）まてせ、サービスまたは主題について
のデータの連続した流れを受ける。申込みパラダイムは
、株価のような動的に変化する値を監視する実時間応用
に良く適する。これとは対称的に、従来の要求／応答通
信は、データの需要者が変化を学ぶデータ提供者を「選
ぶ」ことを要するから、そのような実時間応用にはあま
り適さない。

インターフェイス２３５は１組のプロトコルと、第１６
図のマーケットデータ申込みサービス（ＭＤＳＳ）副構
成要素２３４を含むサービスとに対するプログラムイン
ターフェイスを構成する。このサービス訓練については
後で詳しく説明する。ＲＭＤＰインターフェイス２３５
はサービスアドレスプロトコルであって、データを交換
するサービスの名称についてデータを知ることを依頼人
アプリケーションに求める。

第１６図にはシステムのソフトウェアアーチキクチャが
示されている。分布通信構成要素２３２が各種のプロト
コルエンジン２３７．２３９．２４１を含む。プロトコ
ルオンジンは、サービス訓練プロトコルを特定のネット
ワークプロトコルとインターフェイスする通信プロトコ
ルを包含する。

分布構成要素２３２は各種のサービス訓練２３４．２３
６．２３８へ結合される。サービス訓練２３４は、ここ
ではマーケットデータ申込みサービスと呼ぶ動作を行う
。このプロトコルによりデータの需要者はデータの連続
した流れと、個々のデータソースの許容限度を受けるこ
とができるようにされる。この１組のプロトコルは負荷
の釣合と権利付与政策を管理する機構を提供する。

サービス訓練Ｉｓ＾、２３６、は更に異なる動作を行う
。サービス訓ｆｉＳＡｓｓＩＩ、２３８、は上記のよう
に主題をベースとするアドレス申込みサービスをサポー
トする。

第１５図と第１６図に詳しく説明されているソフトウェ
アアーチキクチャは、第１〜１４図を参照して先に述べ
た実施例とは異なる実施例を表す。

通常は、クラスマネジャーモジュールは、ホストプロセ
ッサのＲＡＭに意味依存オペレーションを行うために必
要なりラス定義をクラス記述子として格納する。クラス
定義はり°ラスを定める意味および形成情報の仕様であ
る。クラス記述子はクラス定義を具体化するメモリオブ
ジェクトである。

クラス記述子は少なくとも二通りのやり方で格納される
。ランダムアクセスメモり（ＲＡＭ）においては、クラ
ス記述子は、クラス定義を作成した依頼人アプリケーシ
ョンとマシンに固有のフォーマットでフォームとして格
納される。ディスクまたはテープに格納されているクラ
ス記述子はテキストＡＳＣＩＩストリングとして格納さ
れる。

クラスマネジャーモジュールが意味依存オペレーション
を行うことを頼まれると、そのモジュールはＲＡＭ内の
クラス記述子の格納内容を探索し、適切なりラス記述子
が存在するかどうかを確認する。もし存在するならば、
このクラス記述子を用いて、第１２図を参照して先に述
べたオペレーションを行う。もし適切なりラス記述子が
存在しなければ、クラスマネジャーはそれを得なければ
ならない。これは、第１図のシステムファイル２４に格
納されているクラス記述子の既知のファイルをサーチす
ることにより、または、クラス定義を要求しているモジ
ュールへ送るためにそのクラス定義を作成した外部アプ
リケーションに対する要求を行うことにより行われる。

クラス記述子を格納するファイルの場所は依頼人アプリ
ケーションには知られており、クラスマネジャーモジュ
ールもそれらのアドレスを格納する。意味に依存するオ
ペレーションが、適切なりラス記述子を見つけることが
できるファイルのアドレスを含むことがしばしばある。

要求がそのようなアドレスを含んでいないとすると、ク
ラスマネジャーはクラス記述子のそれ自身の記憶装置を
調べ、かつ、システムクラス記述子ファイルの場所を識
別するクラスマネジャーにより格納されているレコード
において識別されるファイルを調べる。

クラスマネジャーを発生した外部アプリケーションから
のクラス記述子に質関するとすると、外部アプリケーシ
ョンは、適切なりラス記述子をネットワークを介して要
求しているクラスマネジャーまたは要求しているモジュ
ールへ送る要求をそれのクラスマネジャーへ送る。それ
からクラス記述子は他の任意のフォームで送られ、求め
られている意味依存オペレーションを行うために、要求
するクラスマネジャーにより用いられる。

クラス記述子を得るためにクラスマネジャーがファイル
をアクセスせねばな′らないとすると、ディスクまたは
テープにクラス記述子が格納されているパックされたＡ
ＳＣｌｆ表現をＲＡＭに格納するための固有のフォーム
のフォーマットへ変換せねばならない。これは、各種の
フィールド名と、フィールドの内容の仕様と、クラス番
号を分離するために、ＡＳＣＩＩテキストを文法的に説
明することにより行われる。

第１３Ａ図と第１３８図は、第１３Ａ図のクラス定義の
ために、フォームとしてメモリに格納されているクラス
記述子の構造と編成をそれぞれ示す。第１３Ａ図に示さ
れているクラス定義は人クラスと名づけられ、最後およ
び最初の２つだけのフィールドを有する。それらの各フ
ィールドは２０文字ＡＳＣＩＩストリングを格納するた
めに指定される。

第１３８図は、フィールドがクラス番号１０２０を有す
る構成されたフォームであることを示す１０２１を含む
データブロック１４０を有する。

１４２におけるデータブロックは、フォームが３つのフ
ィールドを有することを示す。第１のフィールドは、Ａ
ＳＣＩＩストリングを含むことを指定された原始クラス
を含む。それはクラス名、人クラス、をデータブロック
にたまたま格納する。第２のフィールドは番号２を割り
当られた、データブロック１４８、原始クラスのもので
ある。その番号はプール値を含むことを指定される、デ
ータブロック１５０゜意味的には、第２のフィールドは
、クラス１０２１のためのクラス定義において定められ
て、フォームクラスが原始（真）であるか、構成された
（偽）のものであるかを定める。この場合には、データ
ブロック１５０は偽であって、クラス１０２１は構成さ
れたクラスであることを示す。！１１３のフィールドは
、データブロック１５２により示すように、クラス番号
１１２を与えられる構成されたクラスである。クラス１
０２１のためのクラス定義は、クラス定義におけるフィ
ールドの名称と仕様を与える構成されたクラスフォ−ム
として第３のフィールドを定める。データブロック１５
４はクラス１１２のフォームで２つのフィールドが存在
することを示す。クラス１１２の第１のフィールドはそ
れ自体は、クラス番号１５０が与えられた、構成された
クラスであり、データブロック１５６．２つの副フィー
ルドを有する、データブロック１５８゜第１の副フィー
ルドは原始クラスであり、データブロック、クラス１５
０に対するクラス定義において、クラス１０２１におけ
る第１のフィールドの名称を含むために指定される。デ
ータブロック１６２はクラス１０２１内の第１のフィー
ルドの名称を与える。第２の副フィールドは原始クラス
１５のものであり、データブロック１６４、クラス１０
２１の第１のフィールドに格納されている実際のデータ
の表現を指定する、データブロック１６６、ＡＳＣＩ　
Ｉストリングを含むためにクラス１５０（図示せず）の
クラス定義で指定される。クラス１１２の第２のフィー
ルドは、クラス１５０の構成されたフォーム、データブ
ロック１６８、を含むためにクラス１１２のクラス定義
で指定される。それは２つのフィールドを含み、データ
ブロック、クラス１０２１内の次のフィールドの名称を
与え、この第２のフィールドに格納されている実際のデ
ータの表現の種類を指定する。

用語集 以下に、本発明の説明に用いられた語句のいくつかの定
義をまとめて記す。

フォーマットまたは種類：構造データレコードのデータ
表現およびデータ編成、すなわち、フォーム。

外部：別のコンピュータまたはソフトウェアのプロセス
のフォーマットデータレコードとは異なるデータレコー
ドのフォーマットを用いるコンピュータまたはソフトウ
ェアのプロセス。

フォームニクラス記述子、またはクラス定義に対応する
クラス記述子番号を含むフィールドを含むことにより、
構造が自己記述的であるデータレコードまたはデータオ
ブジェクト。それらのクラス記述子はフォームのクラス
であって、それの例の全てが、同じ内部表現と、同じ編
成と、同じ意味情報を有するようなりラスを記述する。

このことは、このクラスのフォームの全ての例、すなわ
ち、発生、が同じ名称のフィールドを同数有し、対応す
るフィールド内のデータが同じ表現を有し、対応するフ
ィールド内のデータが同じ表現を有し、かつ各フィール
ドは同じことを意味する。フォームは原始フォームまた
は構成されたフォームとすることができる。１つのユニ
ットのデータだけを格納するフォームが原始フォームで
ある。フィールドと呼ばれる多数の内部構成要素を有す
るフォームが構成されたフォームである。各フィールド
は別のフォームのデータまたはクラスｉｄ１すなわち、
クラス番号、を格納できる。

クラス／クラス記述子／クラス定義二同じ内部表現、同
じ編成および同じ意味情報を有する特定のデータレコー
ド群すなわち「フォーム」の構造と編成の定義。クラス
記述子というのは、クラス定義のそれら全てのパラメー
タを定めるデータを格納するメモり内のデータレコード
すなわち「オブジェクト」のことである。クラスという
のはフォームの名称であり、クラス定義は群の共通な特
徴についての情報である。クラスは原始クラスと構成さ
れたクラスのいずれかとすることができる。

原始クラスは、クラスを独特に識別するクラス名（この
名にはクラス番号すなわちクラスＬｄが組合わされる）
と、１つのデータ値の表現の仕様とを含む。表現の仕様
は、ストリング２０ＡＳＣＩＩ。

浮動少数点、整数、ストリング２０　ＥＢＣＤＩＤ等の
ような、ホストタコンピュータと依頼人アプリケーショ
ンが理解する周知の原始である。構成されたクラスの定
義は独特の名称を有し、この種のフォームにおいて見出
だされる多数のフィールドを名称と内容により定義する
。クラス定義はフィールド名を指定することにより、編
成と、意味またはフォームを指定する。フィールド名は
フィールドへ意味を与える。フィールド名と、それのデ
ータのフォームクラスを与えることにより、各フィール
ドは指定される。というのは、各フィールド自体がフォ
ームだからである。フィールドというのは１つのフォー
ムの代りに同じクラスのフォームのリストとすることが
できる。構成されたクラスの定義は実際のデータを含ま
ないが、クラス記述子は、この種のフォームの編成と意
味を定めるデータのフォーム中に実際のデータを含む。

フ第一ムの例を定める全ての実際のデータは原始クラス
のフォームで格納され、原始クラスで格納されているデ
ータの種類は原始クラスのクラス定義で指定される。た
とえば、「年令」という名称の原始クラスは、整数　３
の種類の１つのフィールドを有する。それはフォームの
年令クラスに対するクラス定義において定義される。こ
のクラスのフォームの例は３桁の整数値を含む。

フィールド：１つまたは複数の構成要素（？）を有する
ことができるフォームの鍔内の１つの構成要素（？）。

各フィールドには異なる名称がつけられ、異なることを
おのおの意味する。フィールドが実際のデータを含んで
おれば、そのフィールドは「原始」であり、他のフォー
ム、すなわち、他のフィールドの群、を含んでおれば、
そのフィールドは「構成された」である。別のフォーム
を含む少なくとも１つのフィールドを有するデータレコ
ードまたはフォームは「入れ子にされている」といわれ
る。第１のフォームの構成されたフィールドに記録され
た第２のフォームはそれ自身のフィールドを有する。そ
れらのフィールドは原始フィールドと構成されたフィー
ルドのいずれかとすることができる。したがって、無限
に複雑な入れ予成の層が生じることがある。

プロセス：コンピュータで実行中のソフトウェアプログ
ラムまたはモジ、：Ｌ−ルの段階。

意味情報：フォーム中の種々のフィールドフォーム、名
称および意味に関するもの。

入れ子にされた：それ自身′力（多数のフィールドを含
んでいる他のデータレコードをおのおのが含むことがで
きる多数のフィールドを有するデータレコードより成る
データ構造。

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

ータレコードを含むフィールド。

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

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

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

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

　　クラス二クラス中の全てのフォームが同じフォーマ
ットと同じ意味を有するようなフォームの群の定義。　
− インターフェイス：あるタスクを実行するためにサポー
ト機能を提供するアプリケーションにより、またはイン
ターフェイスの別のモジュールにより呼出すことができ
るソフトウェアプログラムまたはモジュールのライブラ
リィ。手近の本発明の場合には、通信インターフェイス
は、外部プロセスおよびコンピュータとデータを交換す
るためにアプリケーションとの簡単なプログラミングを
行えるようにするために、外部のプロセスおよびコンピ
ュータの間で希望の切離しを行うプログラムのライブラ
リィを通信インターフェイスが提供する。

申込み要求：ソースサーバー、プロセス、または特定の
主題についてのデータをそれから得ることができるその
場所を指定しないその主題についてのデータに対する要
求。

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

サーバープロセス：テレレー）　（Ｔｅｌｅｒａｔｅ）
、ダウ・ジョーンズ・ニュース・サービス等のような特
定のサービスにより指定されるデータの機能を供給する
アプリケーションプロセス。

サービス訓練またはサービスプロトコル：特定のサーバ
ープロセス。アプリケーション。ローカルエリアネット
ワークで通信するためのプロトコル。

依頼人アプリケーション二本発明の通信インターフェイ
スへ結合され、またはサービスへ結合されたアプリケー
ション 送り層二本発明の通信インターフェイスが結合されるコ
ンピュータの間のネットワーク用の標準的なＫＳＯモデ
ルの層。

送り層プロトコル：特定のネットワークにおいて実現さ
れる特定の通信プロトコルまたは訓練。

サービス：依頼人アプリケーションにより使用するため
にアプリケーションを送り出すことができる機能または
データの有意なセット。いいかえると、サービスという
のは、特定のこと、たとえばダウジョーンズニュース情
報を供給するアプリケーション、を行うアプリケーショ
ンの全体的なりラスである。

サービス例二特定のコンピュータで実行され、指定され
たサービスを提供できるプロセス（サーバープロセスと
呼ばれることもある）。

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

モリオブジェクト。クラスマネジャーにおいては、それ
はフォームとして格納される。ディスクでは、それはＡ
ＳＣＩＩストリングとして格納される。基本的には、そ
れはクラス定義のための特定の表現すなわちフォーマッ
トである。それはＡＳＣＩＩファイル型またはフォーム
型の表現とすることができる。

クラスマネジャーが必要とするクラス記述子を持ってい
ないとすると、クラス記述子のためにクラス定義を作成
した外部アプリケーションにクラスマネジャーはたづね
る。それから、クラス、クラスマネジャーは、外部アプ
リケーションにより発生された時のフォームでクラス記
述子を受ける。

あるいは、クラスマネジャーは、意味に依存するオペレ
ージゴンを要求しているアプリケーションによりそれに
対して識別された、またはクラスマネジャーにより維持
されているレコード中で識別されたファイルをクラスマ
ネジャーは探索する。

それらのファイルに格納されているクラス定義はＡＳＣ
ＩＩテキストフォーマットである。それからクラスマネ
ジャーは、そのようにして見つけたＡＳＣＩＩテキスト
を、各種のフィールド名と、各フィールドにの内容につ
いての仕様に構文解析することにより、固有のフォーム
のフォーマットのクラス記述子へ変換する。

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

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

取扱いニオブシェクド、レコード、ファイル、クラス、
メモリオブジェクト等に対するポインタ。

このポインタはオブジェクトに対するアクセス経路を本
質的に定める。絶対アドレス、相対アドレスおよびオフ
セットアドレスが取扱いの例である。

クラスデータ構造：特定のクラスについての、クラスマ
ネジャーに格納されている全てのデータ。

クラス記述子はこのデータ構造の最も重要な部分である
が、より多くの情報があることもある。

構成ファイル二使用中の種々のソフトウェア構成要素、
レコード、フォームの特性、属性またはパラメータを記
述するデータを格納するファイル。

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

【図面の簡単な説明】

第１図は本発明の一実施例の通信インターフェイスの各
種のソフトウェアモジュールと依頼人アプリケージ、ヨ
ンおよびネットワークの関係を示すブロック図、第２図
は構成されたもののフォームクラス定義の例を示し、第
３図は別の構成されたフォームクラスの定義の例を示し
、第４図はそれ自身が構成されたフォームであフィール
ドを含み、したがって入れ子の例であって、構成された
フォームクラスの定義の例を示し、ｖＮ５図は−２つの
原始フォームクラスの例を示し、第６図はメモリに格納
されている典型的なフォームの例を示し、第７図は意味
データ、フォーマットデータ、および実際のデータすな
わち値データをフォームクラス定義とフォーム例の間に
区分した様子を示し、第８図はフォーマットオペレーシ
ョン中の処理の流れ図、第９図はフォーマットオペレー
ションに使用するターゲットフォーマット特有表、第１
０図はフォーマットオペレーションに使用する別のター
ゲットフォーマット特有表、第１１図はフォーマットオ
ペレーションに使用する一般的な変換表の例、第１２図
は典型的な意味依存オペレーショ　　−ンに対する流れ
図、第１３Ａ図および１３８図は、それぞれクラス定義
と、このクラス定義を格納するクラス記述子フォームを
示し−第１４図は通信プロトコルの主題マツパモジュー
ルおよびサービス訓練モジュールと要求アプリケーショ
ンおよび主題をベースとするアドレッシングのためのサ
ービスとの間の関係を示すブロック図、第１５図は本発
明の別の実施例のインターフェイスの種々のモジュール
およびライブラリィと依頼人アプリケーションの間の関
係を示し、第１６図は別の実施例の通信インターフェイ
スの種々のモジュールの内部の関係を示す。 １０．１２−・・ホストコンピュータ、１４−・・ネッ
トワーク、１６．１８−・・依頼人アプリケーション、
２０・−・フォームマネジャー、２２−・・通信構成要
素、２４・・・ネットワークファイルシステムまたは登
録簿サービス、２６・・・主題表、２８・・・サービス
表、３０．９０・・一通信構成要素、８６・・・フォー
ムクラスマネジャー、８８・・・データ交換構成要素。 ファームクラスニス○今・Ｉ フ０レノマ−ろ　：　クラス１０００ 評急う＋Ｊ『小区点クフス１１ 二詐：！叡クラス１２ 立：　スしし〕り２０　　ＡＳＣＩＩ　　クラス１０名
ニスＬりング２０　　ＡＳＣＩＩフラス１０７０しイヤ
ーヱドレス：　クラス１００１ストリーに　　ストリレ
ク２０　　ＡＳＣＩＩ　　　クラス１０う：　ストリ〕
クー２０　　ＡＳＣＩＩ　　　クラス１０Ｊ（１：　　
ストリレクー２０　　ＡＳＣＩＩ　　　クラス１０第３
図 １−ナラ）ト工〕１リー　　クラス１００２７−ナメ）
ト名　：　λ−リシ７２０　　Ａｓ（Ｊｌ　　　フラス
１０）・レイマー　：　７しイヤ一名　クラス１０００
アトしス　：　プレイＹ−７ばしスクラス！００１スト
リニク２０　　ＡＳＣＩＩクラス１０ス｝−ＩＪニア”
２０　ＡＳＣＩＩ Ｖ数、クラス１２ ！収３ ；フ初ホ収免：　クラス１１ ５７ｖＪ／Ｉ〜舅ご〔，６，１／１ 第５図 第６図 　　　　ろ　２　　　　■ファーマ１ン！−２１寅烹の
データ２１ｍ 第８図 ｌ累出しＩ受入れｌ　　　　　　　　　ｌｉ出しＩ受入
れ１１１１１　１５１　　　　　　　　Ｉｔｓ　　　！
　　３１　１１１２＋２２１　　　　　　１２２１３３
１１１０　　　　２５１　　　　　　　　１２５　　　
ｌ　　４２　１！５９７ｒ、ｒダシＱ−｝１９１９ 　取出し受入＃Ｌ　変１≧アククう＞ｌｌ　１１　　１
５１　ＦＬＱＡＴ１〜ＥＴＨＥＲｌｌ　　１２　　ｌ　
　２２　　ｌ　　ＩＮＴＥＧＥＲＩ−ＥＴＨＥＲｌｌ　
１０　ｊ　２５　　ＡＳＣｒｌ−ＥＴＨＥＲ１１＋ｓ　
　＋　　３１　１　　ＥＴＨＥＲ−ＦＬＯＡＴ２　　　
　　　　１＋　　３３　１　２２　１　　ＥＴＨＥＲ−
ＩＮＴＥＧＥＲ１１／、２　１　２５　１　　ＥＴＨＥ
Ｒ−ＥＢＣ（）Ｉｃ　　　　　　　　ｌ第１１図 意味依存ダリ里 　　　　　　　　　　１／″”− 第１２図 八〇−■ンクラス：　クラス１０２１ 〜　　　　最を麦　：　ストリ〕グ２０　　ＡＳＣＩＩ
最初ニストリシグ２０　ＡＳＣＩＩ つう人定工教 第１３図Ａ １６０ゴロ■１１６２ 第１３図Ｂ −一一−−−一−−一−−一−−一一一−−一一−−一
一−−一−−一土−−］ｉｌ　　ＲＭＤＰ　　Ｉ　　Ｔ
ＩＢＩＮＦＯＩＴＩＢＦＯＲＭｓ　　１１ファリグー）
ヨン　ｌ　：１θ　　　　１　　　　ネットワーク 第１５図 ソフトウエアヱーキテク予▼ ｌ　　　才ｌトワークィ）ターフエイス　　　　　Ｉ第
１６図 手続打ｎ正書（方式） ％式％ ３、補正をする者 ４、代　理　人　　（〒１０４）東京都中央区銀座２丁
１１１番２号５、補正命令の日付 平成２年１０月１５口

Claims (15)

【特許請求の範囲】
1. （１）第１のコンピュータプログラムまたはアプリケー
   ションへ結合され、自己記述データレコードまたはフォ
   ームおよびフォーマットであって、前記レコードと前記
   フォームはフォーム内のフィールドの名称と編成を定め
   る１つまたは複数のクラス定義に対応するデータおよび
   クラス識別データを含み、前記フォームフォーマットは
   前記フィールド内のデータ表現のためのものであり、前
   記レコードまたはフォームおよび前記フォーマットを作
   成し、取扱う第１の手段と、 この第１の手段へ結合され、前記第２のアプリケーショ
   ンへ送られる前記第１のアプリケーションに固有のフォ
   ーマットのフォームのフォーマットを、前記第２のアプ
   リケーションのフォーマットへ変換する第２の手段と、 を備え、第１のコンピュータプログラムまたはアプリケ
   ーションの固有のデータレコードまたはフォームフォー
   マットを、データレコードを交換すべき第２のコンピュ
   ータプログラムまたはアプリケーションの外部のデータ
   レコードまたはフォームフォーマットから切離すための
   ソフトウェア間の通信装置。
2. （２）送信アプリケーションからネットワークを介して
   の受信アプリケーションへのフォームの転送を容易にす
   るために、前記送信アプリケーションの固有のデータレ
   コードまたはフォームフォーマットを前記受信アプリケ
   ーションの外部データレコードまたはフォームフォーマ
   ットから切離すための通信インターフェイスにおいて、 前記送信アプリケーションへ結合され、フォームと呼ば
   れるデータオブジェクトであって、そのフォーム内のフ
   ィールドの名称および編成を定める１つまたは複数のク
   ラス定義に対応するデータとクラス識別データを含む前
   記データオブジェクトと、前記フィールド内のデータ表
   現のためのフォーマットとを作成し、格納し、リコール
   し、取扱い、かつ破壊する第１の手段と、 前記受信アプリケーションへ結合され、フォームと呼ば
   れる自己記述データであって、データ、および前記フォ
   ーム内のフィールドの名称と編成を定める１つまたは複
   数のクラス定義に対応するクラス識別データを含む前記
   データオブジェクトと、前記フィールド内のデータ表現
   のためのフォーマットとを作成し、格納し、リコールし
   、取扱い、かつ破壊する第２の手段と、 前記ネットワークと前記第１の手段へ結合され、フォー
   ムと呼ばれる自己記述データオブジョクトであって、デ
   ータ、および前記フォーム内のフィールドの名称と編成
   を定める１つまたは複数のクラス定義に対するクラス識
   別データを含む前記データオブジェクトと、前記フィー
   ルド内のデータ表現のためのフォーマットとを作成し、
   格納し、リコールし、取扱い、および破壊する第２の手
   段と、 前記ネットワークと前記第１の手段へ結合され、外部ア
   プリケーションへ送られる送信アプリケーションに固有
   のフォーマットのフォームのフォーマットを前記ネット
   ワークのフォーマットへ変換し、かつ前記フォームを前
   記ネットワークを介して送る第３の手段と、 前記ネットワークと前記第２の手段へ結合され、前記受
   信アプリケーションに固有のフォーマットで送られた前
   記フォームを受け、かつ前記フォームを前記受信アプリ
   ケーションへ供給する第４の手段と、 を備え、前記第１の手段に関連する前記フォームは前記
   送信アプリケーションの固有のフォームフォーマットで
   作成され、 前記第２の手段に関連する前記フォームは、前記送信ア
   プリケーションにより用いられる固有のフォーマットに
   対する外部フォームフォーマットであり、前記アプリケ
   ーションの固有のフォームフォーマットで作成され、送
   信アプリケーションの固有のデータレコードまたはフォ
   ームフォーマットを受信アプリケーションの外部データ
   レコードまたはフォームフォーマットから切離すための
   ソフトウェア間の通信装置。
3. （３）請求項２記載の装置において、 前記第３の手段は、１つまたは複数のターゲットフォー
   マット特有表を含み、各表は特定の取出しフォーマット
   を選択された受入れフォームフォーマットへマッピング
   するレコードを含み、かつ、特定の取出しフォーマット
   、受入れフォーマット対を、取出しフォーマットの原始
   クラスフォームを受入れフォーマットの対応する原始ク
   ラスフォームへ変換する特定の変換プログラムへマップ
   するレコードを含む手順マッピング表を更に備え、前記
   第３の手段はフォーマット変換オペレーションに対する
   要求を受ける手段を更に備え、前記要求は取出しフォー
   マットと、受入れフォーマットと、原始的にでき、ある
   いは構成できるフォームのアドレスとを含み、かつ１つ
   または複数のフィールドを包含し、各フィールドはフォ
   ームであって、前記フォームのクラスを独特に識別する
   クラス識別子が組合わされ、各前記フィールドが原始ク
   ラスのフォームであるならばある値を格納し、前記フィ
   ールドが構成されたクラスのフォームであるならば、値
   または他のフォームを格納するフィールドをそれ自身有
   する他のフォームを格納し、前記フォームは取出しフォ
   ーマットから受入れフォーマットへ変換し、原始フォー
   ムが見出だされるまで前記フォームのフィールドを通っ
   て探し、かつ前記フィールドに関連するクラス識別子を
   用い、割当てられたターゲットフォーマット−特有の表
   をアクセスし、エントリイであって、このエントリィの
   取出しフォーマット部分に一致エントリィを有するエン
   トリィを見出だし、更に前記取出しフォーマットクラス
   識別子に対する関連する受入れフォーマットクラス識別
   子を決定する手段を前記第３の手段内に更に備え、前記
   手順マッピング表をアクセスし、取出しフォーマット−
   受入れフォーマット対を一致させるエントリィを探し、
   その一致エントリィ内にリストされている適切なフォー
   マット変換プログラムの名称を決定する手段を面に備え
   、前記原始フィールドの取出しフォーマットを適切な受
   入れフォーマットへ変換するために前記フォーマット変
   換プログラムを呼出して実行し、その変換の結果を格納
   する手段を更に備え、原始フォームを格納する次のフォ
   ームを見出だすために変換すべき前記フォームを探索し
   、前記手順マッピング表中の前記フィールドの取出しフ
   ォーマット−受入れフォーマット対のためにリストされ
   ている変換プログラムを用いて、前記フィールドを適切
   なターゲット特有の表にリストされている受入れフオー
   マットへ変換し、結果を格納し、全てのフィールドが変
   換されるまで、前記フォーム中の各フィールドに対する
   探索と表アクセスおよび変換の機能を繰返す手段を更に
   備えるソフトウェア間の通信装置。
4. （４）１つのアプリケーションと別のアプリケーション
   へ結合され、各前記アプリケーションに固有のフォーマ
   ットで対応するアプリケーションに適切なデータを含む
   フォームを作成し、管理する手段と、 別のアプリケーションへ送るフォームのフォーマットを
   、送信を行うために必要な全てのフオーマットへ変換す
   る手段と、 を備え、各前記フォームは、そのフォームが属するクラ
   スの各フォーム例のフィールドの名称とデータの種類お
   よび編成を与える１つまたは複数のクラス定義に対応す
   る１つまたは複数の識別子を含み、各前記フィールドは
   別のクラスのデータまたは別のサブフォームを含むこと
   ができ、その各サブフォームは１つまたは複数のクラス
   識別子とフィールドと、データの種類と、、前記サブフ
   ォームのフィールドの編成とを格納し、前記サブフォー
   ムの各前記フィールドは、選択可能な入れ子レベル数に
   対してデータまたは別のサブ−サブフォーム等を含むこ
   とができ、 前記変換は、フォームを受信アプリケーションにより使
   用するために適当なフォーマットへの最後の変換を含む
   、１つのアプリケーションのデータフォーマットを、デ
   ータを交換すべき別のアプリケーションのデータフォー
   マットから切離すソフトウェア間の通信装置
5. （５）送信アプリケーションからネットワークを介して
   の受信アプリケーションへのフォームの転送を容易にす
   るために、前記送信アプリケーションの固有のデータレ
   コードまたはフォームフォーマットを前記受信アプリケ
   ーションの外部データレコードまたはフォームフォーマ
   ットから切離すための通信インターフェイスにおいて、 前記送信アプリケーションへ結合され、フォームと呼ば
   れるデータオブジェクトであって、そのフォーム内のフ
   ィールドの名称および編成を定める１つまたは複数のク
   ラス定義に対応するデータとクラス識別データを含む前
   記データオブジェクトと、前記フィールド内のデータ表
   現のためのフォーマットとを作成し、格納し、リコール
   し、取扱い、かつ破壊する第１の手段と、 前記受信アプリケーションへ結合され、フォームと呼ば
   れる自己記述データであって、データ、および前記フォ
   ーム内のフィールドの名称と編成を定める１つまたは複
   数のクラス定義に対応するクラス識別データを含む前記
   データオブジェクトと、前記フィールド内のデータ表現
   のためのフォーマットとを作成し、格納し、リコールし
   、取扱い、かつ破壊する第２の手段と、 前記第１の手段へ結合され、前記第１の手段により作成
   され、かつ用いられたフォームのフォームクラスのため
   の前記定義と、前記第２の手段により作成され、かつ用
   いられたフォームのフォームクラスのためのクラス定義
   を見出だすことができるファイルの場所とを格納する第
   ３の手段と、前記第２の手段へ結合され、前記第２の手
   段により作成され、かつ用いられたフォームのフォーム
   クラスのための前記定義と、前記第１の手段により作成
   され、かつ用いられたフォームのフォームクラスのため
   のクラス定義を見出だすことができるファイルの場所と
   を格納する第４の手段と、あるフォームでの特定のフィ
   ールド名を探索するために要求を受け、前記フォームで
   格納されているクラス識別子により識別された１つまた
   は複数のクラス定義をアクセスし、元の要求におけるフ
   ィールド名に一致するフィールド名についての前記クラ
   ス定義を探索し、名づけられているフィールドに格納さ
   れている値を見出だすために使用できるポインタアドレ
   スを戻し、元の要求において名づけられているフィール
   ドに格納されているデータを得るため要求を受け、前記
   ポインタアドレスを用いて前記フィールド内のデータを
   得るための、前記第３の手段内の第５の手段と、あるフ
   ォームでの特定のフィールド名を探索するために要求を
   受け、前記フォームで格納されているクラス識別子によ
   り識別された１つまたは複数のクラス定義をアクセスし
   、元の要求におけるフィールド名に一致するフィールド
   名についての前記クラス定義を探索し、名づけられてい
   るフィールドに格納されている値を見出だすために使用
   できるポインタアドレスを戻し、元の要求において名づ
   けられているフィールドに格納されているデータを得る
   ため要求を受け、前記ポインタアドレスを用いて前記フ
   ィールド内のデータを得るための、前記第４の手段内の
   第６の手段と、を備える送信アプリケーションの固有の
   フォームフォーマットを受信アプリケーションの外部フ
   ォームフォーマットから切離すためのソフトウェア間の
   通信装置。
6. （６）第１のアプリケーションへ結合され、自己記述デ
   ータレコードまたはフォームおよびフォーマットであっ
   て、前記レコードと前記フォームはフォーム内のフィー
   ルドの名称と編成を定める１つまたは複数のクラス定義
   に対応するデータおよびクラス識別データを含み、前記
   フォーマットは前記フィールド内のデータ表現のための
   ものである、前記レコードまたはフォームおよび前記フ
   ォーマットを作成し、取扱う第１の手段と、 この第１の手段へ結合され、前記第１のアプリケーショ
   ンによる要求を受けて、前記第２のアプリケーションに
   より用いられる外部フォームの任意の選択されたフィー
   ルド中のデータをアクセスし、フィールド名を定めるク
   ラス定義と、前記第２のアプリケーションにより用いら
   れる前記フォームの編成をアクセスし、ポインタアドレ
   スを前記フィールドへ戻し、前記フォームをアクセスし
   、前記ポインタアドレスを用いて、元の要求において名
   づけられているフィールドに格納されているデータを得
   、かつそのデータを前記第１のアプリケーションへ戻す
   第２の手段と、 を備える第１のアプリケーションの固有のフォームフォ
   ーマットを第２のアプリケーションの外部のフォームフ
   ォーマットから切離すためのソフトウェア間の通信装置
   。
7. （７）請求項６記載の装置において、 前記第１の手段へ結合され、前記フォームに格納されて
   いる前記クラス識別データを用い、意味データを定める
   クラス定義と前記フォームのフィールドの編成をアクセ
   スすることなしに、前記第２のアプリケーションへ送る
   べき前記第１のアプリケーションに固有のフォーマット
   のフォームのフォーマットを、前記外部アプリケーショ
   ンのフォーマットへ変換する手段を更に備えるソフトウ
   ェア間の通信装置。
8. （８）フォームと呼ばれるデータレコードに対するデー
   タ表現とデータの編成とに関して同じフォーマットを持
   つことができ、または持つことができないソフトウェア
   モジュールであって、フォームの例は、フォームにより
   定められるデータ表現とデータ編成における実際のデー
   タであり、ソフトウェアモジュールは同じコンピュータ
   に存在でき、または存在できず、かつ同じソフトウェア
   プロセス内に存在でき、または存在できず、更に、デー
   タの種々のフィールドに対して、それらのフィールドの
   名称を定める同じ意味情報を持つデータレコード中に存
   在でき、または存在できない前記ソフトウェアモジュー
   ルの間で情報の交換を実現するための装置において、 前記１つまたは複数の前記ソフトウェアモジュールへ結
   合され、コンピュータと、このコンピュータにより実行
   されるソフトウェアプログラムのライブラリィとを備え
   、クラス記述子を作成し、格納し、検索し、読みだすた
   めの第１の手段と、１つまたは複数の前記モジュールへ
   結合され、コンピュータと、このコンピュータにより実
   行されるソフトウェアプログラムのライブラリィとを備
   え、１つまたは複数のクラスのフォームの例を作成し、
   格納し、検索し、読出すための第２の手段と、 １つまたは複数の前記モジュールへ結合され、コンピュ
   ータと、このコンピュータにより実行されるソフトウェ
   アプログラムのライブラリィとを備え、前記ソフトウェ
   アモジュールと、前記第１の手段および前記第２の手段
   との間にインターフェイスを設けて、前記ソフトウェア
   モジュールが、前記第１の手段および前記第２の手段内
   の適切なソフトウェアプログラムを呼出すことによりフ
   ォームの例を有用に交換できるようにして組合わせ、交
   換された前記情報が、前記ソフトウェアモジュールの間
   のフォーマットの違いと意味の違いにもかかわらず、使
   用し、および他のモジュールとにより使用できる意味を
   有するようにして、前記モジュールの一方からの情報を
   翻訳し、取扱い、解釈し、かつ前記別のソフトウェアモ
   ジュールへ前記情報をフォームの例として送る第３の手
   段と、を備え、前記クラス記述子はデータレコードであ
   って、クラス記述子が適用するフォームクラスの例にお
   けるデータの名フィールドの名称についての意味情報と
   、前記クラス記述子が対応するクラスのフォームの例に
   おけるデータのフィールドのデータ表現と編成について
   のフォーマット情報とを定めるデータを含み、 前記第２の手段に関連する前記１つまたは複数のクラス
   のフォームの各前記例は、前記フォーム中のデータのデ
   ータ表現とデータの編成とについてのフォーマットデー
   タと、前記フォームの例を含む実際のデータとを含み、
   ソフトウェアモジュールの間の情報の交換を実現するソ
   フトウェア間の通信装置。
9. （９）請求項８記載の装置において、 前記第３の手段は、モジュールから要求を受けて前記ク
   ラス記述子のいずれかを得、かつ前記第１の手段に希望
   のクラス記述子の探索を開始させ、前記第１の手段は、
   クラス定義を格納するためのファイル場所の格納されて
   いるリストを検査し、前記ファイルのいずれかに前記ク
   ラス定義が見出されたとすると、前記希望のクラス定義
   に対する格納されているデータを検索し、もし見出ださ
   れなかったとすると、希望のクラス定義が格納されてい
   る場所についての情報を有する第１の手段からクラス定
   義を要求する手段を含むソフトウェア間の通信装置。
10. （１０）種々の構造とデータ表現フォーマットをおのお
    の有する第１のコンピュータプログラムと第２のコンピ
    ュータプログラムの間に通信機能を設ける装置において
    、 前記第１のコンピュータプログラムと前記第２のコンピ
    ュータプログラムのおのおのに固有の構造およびデータ
    表現フォーマットを有する、前記第１のプログラムと前
    記第２のプログラムのおのおのに対して入れ子式のデー
    タレコードを作成する手段と、 送りコンピュータプログラムのフォーマットから受けコ
    ンピュータプログラムのフォーマットへ、前記第１のコ
    ンピュータプログラムと前記第２のコンピュータプログ
    ラムのいずれによる処理も必要とせずに、自動的に翻訳
    することにより、前記第１のコンピュータプログラムと
    前記第２のコンピュータプログラムの間のデータレコー
    ドの転送を容易にする手段と、 を備え、任意の数の入れ子レベルに対して、任意の１つ
    のデータレコードが、他のデータレコード等を含む、１
    つまたは複数のフィールドを有することができる、とい
    う意味で、前記データレコードは入れ子式にされ、各デ
    ータレコードは、クラス識別子が組合わされているクラ
    スに割当てられ、データレコードの各例は、一緒にされ
    た時にデータレコードを構成する全てのデータレコード
    に対する全てのクラスのクラス識別子を含み、第１のコ
    ンピュータプログラムと第２のコンピュータプログラム
    の間に通信機能を設けるソフトウェア間の通信装置。
11. （１１）請求項１０記載の装置において、 対象とするフォーム例についての経路名と、希望のデー
    タを含んでいる前記データレコードの前記例中のフィー
    ルドに対するフィールド名とを受けることにより前記第
    ２のコンピュータプログラムにより用いられるフォーマ
    ットのデータレコードからのデータの前記第１のコンピ
    ュータプログラムによる取出しを容易にし、前記第１の
    コンピュータプログラムによる処理なしに、前記例が属
    するデータレコードのクラスについてのクラス定義を自
    動的に探し、かつ要求中に名づけられているフィールド
    を前記クラス定義中で探し、データレコードの前記クラ
    スの例中で、前記名づけられているフィールド中に格納
    されているデータ値を示すポインタアドレスを発生し、
    そのポインタアドレスを用いて、対象とする例から希望
    のデータ値をアクセスする手段を更に備えるソフトウェ
    ア間の通信装置。
12. （１２）請求項１１記載の装置において、 前記第１のコンピュータプログラムへ結合されて、前記
    第１のコンピュータプログラムへ通信インターフェイス
    機構を提供することにより、前記第１のコンピュータプ
    ログラムは、１つまたは複数の選択された主題に属する
    データレコードを要求できる、主題をベースとするアド
    レッシング手段を更に備え、前記第２のコンピュータプ
    ログラムが前記サブジェクトについての、または前記第
    ２のコンピュータプログラムがある場所についての、デ
    ータレコードを発生することを前記第１のコンピュータ
    プログラムが知ることなしに、前記第２のコンピュータ
    プログラムは前記選択された主題に対してデータレコー
    ドを発生し、前記主題をベースとするアドレッシング手
    段は添字要求の態様で前記第２のコンピュータプログラ
    ムとの通信を設定し、それにより、前記主題に属する全
    てのデータレコードを前記第２のコンピュータプログラ
    ムは前記第１のコンピュータプログラムへ自動的に送る
    ソフトウェア間の通信装置。
13. （１３）請求項１２記載の装置において、 前記主題をベースとするアドレッシング手段は、前記第
    ２のコンピュータプログラムにより用いられる適切な通
    信プロトコルを用いて、前記第２のコンピュータプログ
    ラムとの前記通信を設定するためのサービス訓練手段を
    含むソフトウェア間の通信装置。
14. （１４）請求項１３記載の装置において、 特定の主題に属するデータレコードに対する元の添字要
    求はコールバックソフトウェアプログラムを含み、前記
    サービス訓練手段は、添字要求を前記第２のコンピュー
    タプログラムへ送る手段を含み、前記添字要求は対象と
    する主題を含むとともに、前記主題についてのデータレ
    コードを供給できるものであるならば、前記第２のコン
    ピュータプログラムにより確認応答メッセージを送られ
    るアドレスと、主題に属するデータレコードを送られる
    第２のアドレスとを含み、前記サービス訓練手段は、前
    記第２のコンピュータプログラムから受けた前記データ
    を前記コールバックソフトウェアプログラムへ送る手段
    を含むソフトウェア間の通信装置。
15. （１５）特定の主題についてのデータを供給するサービ
    スのアドレスと、前記サービスとデータを交換するため
    の通信プロトコルを定める各前記サービスのための関連
    するサービス訓練の名称とに前記特定のサブジェクトを
    マッピングするデータを電子的に格納する登録簿サービ
    ス手段と、 前記のサブジェクトについてのデータだけを前記関連す
    るサービス訓練手段へ前記サービスが送るために利用す
    る添字通信リンクを設定し、前記サービスから受けた前
    記主題についてのデータを前記第１のソフトウェアアプ
    リケーションへ送る１つまたは複数のサービス訓練手段
    と、 前記第１のソフトウェアアプリケーションと前記登録簿
    サービス手段へ結合され、特定の主題についてのデータ
    を求める添字要求を前記第１のソフトウェアから受け、
    前記サービスとのデータ交換をどのようにして行うかを
    定める前記関連するサービス訓練の名称と前記主題につ
    いてのデータとを供給する奉仕コンピュータで行われて
    いるサービスのアドレスを電子的に探索し、前記添字要
    求中の主題データを、前記サービス登録簿手段をアクセ
    スすることにより識別されたサービス訓練手段へ送って
    、そのサービス訓練手段に関連するサービスの前記添字
    通信リンクを設定させる主題マッパ手段と、 を備え、データを交換すべき相手であるサービスソフト
    ウェアのアドレス、サービスの名称、またはプロトコル
    を知る必要から第１のソフトウェアアプリケーションを
    切離すソフトウェア間の通信装置。