JP2000500940A - レジストリ通信ミドルウェア - Google Patents

Abstract

(57)【要約】 コンピュータ・システムは、選択的にネットワーク（１０８）上で相互接続された複数の互換性のないクライアント（１０２）およびサーバ（１１０）を有しており、各クライアントは関連する互換性のあるサーバを伴うアプリケーション（１２４）を開始することができる。クライアントとサーバとの間の通信は、予め選択されたサーバへの宛てられた、クライアントからのアプリケーションの特定のメッセージの受容、およびこれらを標準的なレジストリの特定のメッセージ（１２８）内にカプセル化することを含む第１のレジストリ・プロセス（１０４、１２６）を必然的に伴う。メッセージの経路選択は、経路選択データを提供するために、特定のクライアントからのバーブ・コマンドに応答するデータベースにより決定される。次いで、レジストリの特定のメッセージを予め選択されたプロトコル（１０６、１３０）への翻訳がある。第２のレジストリ・プロセス（１０４、１２６）は、ネットワークの通過後に、メッセージを復元するために遠端において発生する。第２のレジストリは翻訳されたメッセージを受容し、またこれらを、予め選択された互換性のあるサーバによる使用のために、プロトコルのフォーマットから元のアプリケーションの特定のフォーマットに変換する。

Description

【発明の詳細な説明】 レジストリ通信ミドルウェア 関連出願 本出願は、１９９５年１２月２日に出願され、「ＥＸＩＴＳ：拡張された情報 転送サービス」と題された、共願の米国特許出願第０８／５８０，９５０号に関 連するものである。 発明の分野 本発明は分散型コンピューティング・ネットワーク、より詳しくは、クライア ント／サーバのアプリケーションとネットワークのメッセージ通信用製品との間 で標準化された通信層を提供するシステムに関するものである。 分散型コンピューティングは、いくつかのコンピューティング・リソースの間 でアプリケーションのデータ処理を割り振る方法である。この技術は、共通のア プリケーションのためにいくつかの異なるプロセッサを利用することによる効率 性のために、急速に成長している分野である。 分散型コンピューティングのプラットフォームはまた、各コンピューティング ・リソースがクライアントあるいはサーバのいずれかに表れることから、クライ アント／サーバのプラットフォームとしても知られている。クライアントのリソ ースはアプリケーション・サービスのカスタマである。これは、サーバに対して 要求メッセージを送信するという基本的なプロセスを実行する。クライアントは 、一般的には、ワークステーションのアプリケーションを実行する人のような、 システムのユーザを表している。 サーバのリソースはアプリケーション・サービスのプロバイダである。これは 、クライアントからのメッセージを受信するプロセス、およびクライアントへの 応答メッセージを送信する基本的なプロセスを実行する。サーバは、一般的には 、企業のデータ・リソースを保守し業務戦略を実行する要素を表している。 分散型コンピューティングのプラットフォームを実行するための基本的な要件 は、種々のタイプのコンピューティング・リソースおよびネットワーク・リソー スを単一で、企業規模のネットワーク内に統合することである。これを行うため に利用可能な多くの製品、規格、および通信プロトコルがあり、多くの企業では これらのいくつかを使用している。これによって、相互運用性に関して著しい問 題が生じる。種々のオペレーティング・システムおよびハードウェア上で実行さ れるいくつかの異なるアプリケーションは多数のメッセージ通信およびネットワ ーク通信プロトコルとインターフェースしなければならない。アプリケーション のプログラマーは、そのアプリケーションを分散型コンピューティング・プラッ トフォーム上で動作させるために、これらのプロトコルのすべての複雑性および 錯綜性を処理しなければならない。 さらに、プログラマーは、そのアプリケーションに対してメッセージの最適な 転送機構を決定するための手段を提供しなければならない。これはクライアント ・リソースおよびサーバ・リソース上の両方で必要となる。 明らかなように、分散型コンピューティングのリソースおよびネットワークを 利用するビジネスのために、これらのリソースを使用するアプリケーションに対 して標準的なインターフェースを提供する必要性がある。現在の市場ではこれを 行うための製品はない。 本発明の簡単な説明 レジストリとして識別される、本発明は、分散型コンピューティングのプラッ トフォームの各アプリケーションのリソース（クライアントおよびサーバの両方 ）上に存在するシステムである。 一連の通信のためのメッセージ通信用製品とネットワークのプロトコルとをサ ポートするのは、通信エージェントである。これは、アプリケーションとネット ワークのトランスポート機構との間の通信の論理的な層として機能する。このよ うに機能することで、レジストリは、アプリケーションのプログラマーを、所有 するメッセージ通信およびトランスポート・プロトコルの潜在する全ての複雑性 から保護することができる。 レジストリは、クライアントからのアプリケーション特定のメッセージを受容 し、これらを標準的なレジストリ特定のメッセージ内にカプセル化し、また次い でこれらを、使用されるトランスポートおよびメッセージ通信機構のために必要 なプロトコルに翻訳する。他方、レジストリは、クライアントが送信したメッセ ージを受取り、これを使用されるトランスポート・プロトコルからサーバにより 使用されるアプリケーション特定のメッセージに翻訳する。 よって、このレジストリによれば、オペレーティング・システム、ハードウェ アのプラットフォーム、メッセージ通信用製品およびネットワーク・プロトコル の広範囲のアレイを介して企業規模のアプリケーションの接続性を提供できると いう特長がある。 また、レジストリは、アプリケーションへの単一で、標準的なインターフェー スを提供する一方、いくつかの異なるメッセージ通信およびネットワーク通信用 製品のそれぞれの製品特定のインターフェースを提供できる特長がある。 また、アプリケーションのプログラマーがそのアプリケーションに低水準のメ ッセージ通信およびトランスポートのセマンテックス（semantics）をプログラ ミングする必要性を回避でき、プログラマーはビジネス向きのセマンテックスに 焦点を絞ることができることも、レジストリの他の特長である。この特長により 、アプリケーションの融通性が増大し、また複雑性が低減される。 また、各アプリケーションが使用される種々のメッセージ通信およびトランス ポートプロトコルに対する特定のインターフェースを有する必要性を省くことが できることも、レジストリの他の特長である。 また、各トランザクションのための最適なトランスポート機構を決定する手段 をアプリケーションに提供できることも、レジストリの他の特長である。 また、アプリケーションがプラットフォームやプロトコルに依存しないように できることもレジストリの他の特長である。つまり、アプリケーションのプログ ラマーは、アプリケーションのクライアントおよびサーバによってどんなオペレ ーティング・システム、ハードウェアのプラットフォーム、および通信プロトコ ルが使用されるのかを知る必要がなくなり、レジストリへの標準的なインターフ ェース内でプログラムするだけで良い。同様に、クライアントおよびサーバを、 １つのプラットフォーム／プロトコルから他のものへ、各アプリケーション内に 対応する変更をプログラムすることなく、出力（port）することができる。 さらに、論理的なネットワークの経路選択デイレクトリを使用する場合でも、 物理的なリソースのアドレスにおける変更は、各アプリケーション上ではなく、 レジストリのデイレクトリ更新要求のみとなることも、レジストリの他の特長で ある。 図面の簡単な説明 本発明の上記した目的および特長は、添付図面とともに考察した場合において より明確に理解される。 図１は、レジストリを使用する、一例の分散型コンピューティング・プラット フォームにおける高水準のシステム・アーキテクチャを示したブロック図である 。 図１ａは、クライアント／サーバの通信の論理層およびレジストリが適合され る場所を示した図表である。 図２は、レジストリの内部アーキテクチャ、およびそれが利用する分散型コン ピューティングのプラットフォームの単一スレッドを例示したブロック図である 。 図２ａは、図２において識別された汎用ＩＰＣインターフェースの詳細を示し たデータ流れの図表である。 図２ｂは、レジストリ・プロセス・モニタをより詳細に示したブロック図であ る。 図３ａは、レジストリの動作を例示したプロセスの流れ図である。 図３ｂは、図３ａにおけるプロセスの続きである。 発明の詳細な説明 図１を参照して、レジストリは、クライアントおよびサーバのアプリケーショ ンの両方に対して、単一で、標準的なインターフェースとして図示されている。 レジストリは、実際には、それぞれの個々のクライアントおよびサーバのリソー ス上に存在するシステムである。これは、各クライアントおよびサーバのアプリ ケーションに対して、これらのアプリケーションが種々の所有するメッセージ通 信用製品およびネットワーク・プロトコルの複雑性から保護するために、単一で 、 標準的なインターフェースを提供する。図示したオペレーティング・システム、 メッセージ通信用製品、およびネットワークプロトコルはレジストリによりサポ ートされる一例である。 レジストリ１０４は、対話の一部としてクライアント・アプリケーション１０ ２から要求メッセージを受容する。アプリケーション１０２は、示したような、 種々の運用システム下で動作する。これらの要求メッセージは、プロセスを実行 するために応答および／または命令のための請求を表している。これらは、サー バ・アプリケーションに配信されることを意図してクライアント・アプリケーシ ョンにより生成される。アプリケーション１１０はまた、図示したような種々の オペレーティング・システム下で実行される。レジストリのソフトウェアはアプ リケーションとして同一ハードウェア要素上に存在することから、レジストリ１ ０４とクライアント・アプリケーション１０２との間のリンクはソフトウェアの プロセスを表している。４つのオペレーティング・システムおよび端末エミュレ ータの例を例示したが、レジストリはさらに多くのものをサポートすることがで きる。 レジストリ１０４は次いで、クライアントの要求メッセージをレジストリ−規 定のメッセージ内にカプセル化するプロセスを実行する。このプロセスは図２お よび図４を参照してより詳細に示されている。レジストリは適切なメッセージ通 信用製品１０６を決定し、メッセージをこのメッセージ通信用製品の所有のプロ トコルに変換する。場合によっては、レジストリは実際にはメッセージ通信用製 品として機能し、この場合、レジストリはネットワークのトランスポート１０８ （つまり、ＳＮＡ ＬＵ６．２、ＴＣＰ／ＩＰなど）の所有のプロトコルにメッ セージを変換する。 メッセージ通信用製品１０６は、利用可能なネットワーク１０８上でメッセー ジを移送するための適切なネットワークのプロトコルを使用する。遠端において 、メッセージ通信用製品１０６はメッセージを受信し、またこれをレジストリ１ ０４に進める。レジストリはメッセージをメッセージ通信用製品１０６の所有の プロトコルからサーバのアプリケーションに認識可能なメッセージに変換する。 サーバのアプリケーション１１０からの応答が要求された場合、応答メッセージ を クライアントのアプリケーション１０２に戻して送信するために先のプロセスが 繰り返される。 図１ａを参照して、クライアント／サーバの通信の論理層内にレジストリ１０ ４が果たす役割が例示されている。この図表において、リソースは各層の前で識 別され、それが提供するインターフェースは各層の上部で識別され、またインタ ーフェースにおいて使用されるセマンテックスは各層の右側で識別される。 最上層１２２はアプリケーションのユーザを表している。これは、アプリケー ションとビジネス用情報を交換する、アプリケーション規定のユーザ／リソース のインターフェースを経てアプリケーションとインターフェースする。 次に下の層１２４はアプリケーションを表している。これは、標準的なバーブ ・セット（ＳＶＳ）を使用してレジストリとインターフェースする。使用される セマンテックスは「バーブ（verb）」として知られている、ビジネス用のクライ アント／サーバのトランザクションであり、アプリケーションのプログラマーが 取り扱う必要のあるプロトコルだけを表している。 次に下の層１２６はレジストリを表している。これは、製品−特定のインター フェースを経てメッセージ通信用製品（別名、通信用ミドルウェア）とインター フェースする。使用されるセマンテックスはメッセージ通信用製品に特定のもの である。 次に下の層１２８は通信用ミドルウェア、つまりメッセージ通信用製品である 。これは、データ転送用セマンテックスを使用し、ネットワークのプロトコルの インターフェースを経てネットワークとインターフェースする。底の層１３０は 、ネットワークのプロトコルを表し、ＳＮＡ ＬＵ６．２あるいはＴＣＰ／ＩＰ のようなタイプのものから構成されている。 場合によっては、レジストリ１２６は通信用ミドルウェア層１２８を横切って 実際に広がっている。例えば、レジストリは、クライアントの要求メッセージを 実際のＴＣＰ／ＩＰメッセージに翻訳し、またＴＣＰ／ＩＰネットワーク上に直 接的に送信する。 図２を参照して、レジストリを利用した一般的なクライアント／サーバの会話 を例示するために、レジストリの内部論理構造を示した。 クライアントのアプリケーション２０２は、遠くのサーバのアプリケーション ２２２に送信される必要がある要求メッセージを発生する。要求メッセージの典 型的な例は、遠くのサーバ上に位置した会社のカスタマ課金用データベースから のカスタマの月毎の課金収入である。クライアントとサーバは企業のデータ・ネ ットワーク２１８により接続されており、またネットワーク２１８上でそれらの メッセージを移送するために利用可能ないくつかのメッセージ通信用製品２１６ を有している。これらは、全てのメッセージ通信用製品２１６およびネットワー ク２１８のプロトコルへのインターフェースとしてレジストリ２０４を使用する 。 クライアントのアプリケーション２０２はレジストリのアプリケーション・プ ログラミング・インターフェース（ＡＰＩ）２０６を経てレジストリ２０４と通 信する。ＡＰＩは、以下のように規定され、標準的なバーブ・セット（ＳＶＳ） として知られているコマンドのセットを含んでいる。 標準的なバーブ・セット レジストリの標準的なバーブ・セット（ＳＶＳ）は、レジストリがクライアン トおよびサーバのアプリケーションと通信するために使用する、コマンドのセッ トである。このコマンドの限定されたセットは、クライアント／サーバのアプリ ケーションのプログラマーがそれらのアプリケーションをレジストリ、および企 業のネットワークと通信させるために使用するのに必要な全ての通信プロトコル を表している。 １つはクライアントのアプリケーションにより使用され、また１つはサーバの アプリケーションにより使用される、２つのバーブのセットがある。アプリケー ションはクライアントあるいはサーバのいずれかとして潜在的に機能することが できるので、両方のバーブのセットはあらゆるアプリケーションのためのＳＶＳ 内に含まれている。上記したように、ＳＶＳは各クライアントおよびサーバのア プリケーションと同様に、レジストリのＡＰＩ２０６内で保守されている。 クライアントのバーブおよびそれらのパラメータは次のように規定される。 ＲＥＧＩＳＴＥＲ− 呼び出し側アプリケーションとレジストリとの間 でセッションを設立する。このセッションは、呼び出し側のアプリケーションと レジストリとの間でだけであり、アプリケーション間ではない。このセッション は、レジストリ内でＲＥＧＩＳＴＥＲバーブにより割り当てられたメモリである 、登録制御領域（Registration Control Area）から構成され、呼び出し側のア プリケーションに戻って渡される。ＲＣＡは登録プロセスの単一のインスタンス を表し、またクライアントによるＲＥＧＩＳＴＥＲの発行に対して新しいＲＣＡ が必要とされる。ＲＥＧＩＳＴＥＲのパラメータは、 ＦＥＥＤＢＡＣＫ− 呼び出し側アプリケーションに戻るために使用される フィールドであり、レジストリが要求された機能を完了することができるかどう かの表示。 ＲＥＧ−ＯＰＴＩＯＮＳ− これは、多くは任意である、いくつかのフィー ルドを含み、クライアントのアプリケーションを識別するために使用される情報 を提供する。このパラメータの１つの必要とされるフィールドは、呼び出し側の アプリケーションがクライアントあるいはサーバであるかを表す１つのキャラク タの指定の表示である。 ＲＣＡ−ＰＴＲ− ＲＣＡへのポインタとして機能することによりＲＣＡを 単一的に識別するために使用されるフィールドである。これは、ＲＥＧＩＳＴＥ Ｒバーブにより設立された特定のセッションを指定し、また特定のセッションの 一部としてレジストリへの続く呼び出しを識別する。ＲＥＧＩＳＴＥＲの各発行 は異なるセッションを指定しなければならず、よってこのフィールドに対して異 なる値を有する（例えば、ＲＣＡ−ＰＴＲ１、ＲＣＡ−ＰＴＲ２など）。 ＤＥＲＥＧＩＳＴＥＲ− クライアント／サーバのアプリケーションの活動 を終了し、また関連するレジストリ−管理されたリソースを解放する。パラメー タはＲＥＧＩＳＴＥＲの場合と同じである。 ＳＥＮＤＲＥＱＵＥＳＴ− クライアントの要求をサーバに送るために使用 される。ＲＥＧＩＳＴＥＲと同じおよび次のパラメータを含む。 ＷＳ−ＴＥＳＴ−ＭＳＧ− このフィールドはクライアントからサーバ に実際に送られたメッセージのアドレスである。 ＷＳ−ＭＳＧ−ＬＥＮ− このフィールドはクライアントのメッセージ の長さを表す。 ＲＥＣＥＩＶＥＲＥＰＬＹ− 先の要求に対する応答を受信するために使用 される。ＲＣＡはＳＥＮＤＲＥＱＵＥＳＴバーブに対して使用されたものと同じ でなければならない。ＲＥＧＩＳＴＥＲと同じおよび以下のパラメータを含んで いる。 ＷＥ−ＯＵＴ−ＭＳＧ−ＰＴＲ− このフィールドは応答メッセージへ のポインタである。 ＷＥ−ＯＵＴ−ＭＳＧ−ＬＥＮ− このフィールドは応答メッセージの 長さを表している。 ＣＯＮＶＥＲＳＥ− 同期的な要求／応答トランザクションを行うために使 用される。ＳＥＮＤＲＥＱＵＥＳＴおよびＲＥＣＥＩＶＥＲＥＰＬＹを組み合わ せたのと同じパラメータを含む。 サーバのバーブおよびそれらのパラメータは次のように規定される。 ＲＥＧＩＳＴＥＲ− バーブのクライアント版と同じ定義である。サーバは レジストリのそれを行う要求に応答してＲＥＧＩＳＴＥＲバーブを発行する。 ＤＥＲＥＧＩＳＴＥＲ− バーブのクライアント版と同じ定義である。 ＲＥＣＥＩＶＥＲＥＱＵＥＳＴ− クライアントにより送られた要求メッセ ージを受信するために使用される。メッセージはそれ自体で変更されてないでレ ジストリにより受信され、次いでサーバにより処理される。ＲＥＧＩＳＴＥＲと 同じおよび以下のパラメータを含む。 ＷＥ−ＲＥＱＵＥＳＴＥＤ−ＭＳＧ− このフィールドはクライアント によりサーバに対して送られたメッセージのアドレスである。 ＷＥ−ＲＥＱＵＥＳＴ−ＬＥＮ− このフィールドはメッセージの長さ を表す。 ＳＥＮＤＲＥＰＬＹ− サーバの応答をクライアントのメッセージに送るた めに使用される。ＲＥＧＩＳＴＥＲおよび以下のパラメータを含む。 ＷＥ−ＳＥＮＤＲＥＰＬＹ−ＭＳＧ このフィールドはサーバによりク ライアントに送られた応答のアドレスである。 ＷＥ−ＳＥＮＤＲＥＰＬＹ−ＬＥＮ− このフィールドは応答の長さを 表す。 図２を再び参照して、クライアントのアプリケーション２０２は、それ自体を レジストリ２０４を備えたクライアントとして登録することによりセッションを 開始する。これは、ＡＰＩ２０６により読み出される、ＲＥＧＩＳＴＥＲバーブ を発行する。バーブ実行部２０８として識別されるレジストリ要素はパラメータ を有効性検査するとともに各バーブを処理する役目がある。ＲＥＧＩＳＴＥＲバ ーブがＡＰＩ２０６により受信されたとき、バーブ実行部２０８は登録制御エリ ア（ＲＣＡ）を生成しＲＣＡのアドレスをＡＰＩ２０６を経てクライアント２０ ２に戻す。このＲＣＡはクライアントとレジストリとの間の通信を記憶し処理す るために使用される。 クライアントのアプリケーション２０２は次いでＳＥＮＤＲＥＱＵＥＳＴバー ブをレジストリに発行する。このバーブは、先にクライアントにより生成された クライアントの要求メッセージを、サーバ２２２に送信することをレジストリに 指令する。実際の要求メッセージはまたＳＥＮＤＲＥＱＵＥＳＴのパラメータと してレジストリに送信される。このメッセージは、それを生成した特定のクライ アントのアプリケーション２０２により規定されるフォーマットであり、またレ ジストリにより変更されないまま維持される。レジストリは単にこれをサーバ２ ２２に配信する。 代わりに、クライアント２０２は、双方向の、サーバ２２２と会話型のダイロ グを設立するＣＯＮＶＥＲＳＥバーブを発行しても良い。これは、ＳＥＮＤＲＥ ＱＵＥＳＴとＲＥＣＥＩＶＥＲＥＰＬＹバーブを組み合わせて発行することと等 価である。ＳＥＮＤＲＥＱＵＥＳＴバーブを単に発行することにより、バーブの パラメータに応じて、クライアント２０２は対話型あるいは一方向のいずれかの ダイアログをサーバ２２２と設立する。 図２をさらに参照して、ＳＥＮＤＲＥＱＵＥＳＴバーブはＡＰＩ２０６により 受信され認識される。レジストリは次いでバーブ実行部２０８のプロセスを開始 する。 バーブ実行部２０８はバーブのパラメータを有効性検査する。これはまた、宛 先アドレスを分析する。これは、クライアントのアプリケーションのメッセージ から、クライアントの要求が意図されるサーバのアプリケーション２２２の名前 を読み出す。次いで、サーバのアプリケーション２２２に対する物理的なネット ワーク宛先を決定するためにデイレクトリ・サービス・データベース２１０に照 会する。デイレクトリ・サービス２１０は、ネットワーク上の各クライアント／ サーバのアプリケーションに対する物理的なネットワーク経路選択コードを含ん でいる。ネットワーク上で特定のアプリケーションを配信するために要求あるい は応答メッセージがレジストリに与えられたとき、レジストリはデイレクトリ・ サービスを経て物理的なネットワーク・ノードにその名前を翻訳することにより そのアプリケーションがどこに存在するのかを決定する。この方法においては、 アプリケーションがネットワーク上の他のノードに移行したときには、各クライ アント／サーバのアプリケーションを更新するのではなく、デイレクトリ・サー ビスの更新だけが必要となる。 好ましい実施の形態において、アプリケーションのネットワークの宛先は、ド メイン、サービス名、およびサービス修飾子から構成される、３つの部分の名前 により表される。ドメインは企業規模のネットワークの別個のサブ−ネットワー クを参照する。サービス名は、宛先ノードの、物理的なロケーションではなく、 機能を参照し、またこれは宛先の基本的な識別名である。サービス修飾子は、２ つ以上のインスタンスがある場合において、サービス名機能の特定のインスタン スを参照する。一例として、地理的なカスタマ・データのサービス名機能はサー ビス修飾子において「東」あるいは「西」で特定される。 図２をさらに参照して、バーブ実行部２０８は、汎用ＩＰＣ要求を汎用ＩＰＣ インターフェース２１２に発行することによりＳＥＮＤＲＥＱＵＥＳＴバーブの 実行を始める。ＩＰＣ（プロセス間通信）は全ての要素を参照し、またクライア ント端におけるレジストリとサーバ端におけるレジストリの間で処理を行う。こ れは、メッセージ通信用製品２１６、データ・ネットワーク２１８、およびクラ イアント・プロセスとサーバ・プロセスの間の通信をサポートするものを含んで いる。 汎用ＩＰＣインターフェース２１２は、クライアントのメッセージをサーバに 移送するための適切なＩＰＣ製品を選択する役目のある要素である。汎用ＩＰＣ インターフェース２１２は、利用可能なメッセージ通信用製品２１６およびネッ トワーク製品２１８の全ての汎用化されたビューを含んでおり、また現在のセッ ションにおいて使用するための１つを選択する。また、メッセージ・エンベロー プ（メッセージ自体は変更されない）を選択されたＩＰＣ製品の適切なフォーマ ットに翻訳する役目がある。汎用ＩＰＣ要求は、バーブ実行部２０８により汎用 ＩＰＣインターフェース２１２に発行されるコマンドである。これには、クライ アントのメッセージ、サーバのネットワーク・アドレス、およびメッセージを送 信するための要求が含まれる。 汎用ＩＰＣインターフェース２１２は、インターフェース２１２の動作を例示 したデータ流れの図表である図２ａにより詳細に示されている。図２ａを参照し て、汎用ＩＰＣインターフェースは、破線内で識別される。これは、３つの主要 な要素、つまり汎用ＩＰＣインターフェース要求プロセッサ２３０、ＩＰＣ製品 修飾部２３２、ＩＰＣメッセージ通信用インターフェース２３４などから構成さ れる。これはまた、デイレクトリ・サービス２１０の区分されたデータベース、 あるいは別個のデータベースである、利用可能なサービス情報２３６のデータベ ースを含んでいる。 汎用ＩＰＣインターフェース要求プロセッサ２３０はバーブ実行部２０８への 形式的および最初のインターフェースを提供する。また、汎用ＩＰＣ要求２４０ を受信し、要求を処理するために必要なサービスを決定する。次いで、これらの サービスを要求されたサービスのリスト２４２内にコンパイルし、これはＩＰＣ 製品修飾部２３２に送られる。要求されたサービスのリスト２４２はデータ項目 のセットであり、各項目は要求を処理するために必要なレジストリ−規定のサー ビスを識別している。このようなサービスの例は持続的なキューイング、メッセ ージ回復、およびタイムアウトである。 ＩＰＣ製品修飾要素２３２は、データ・ネットワーク２１８上でクライアント のメッセージを移送するためにどのメッセージ通信用製品２１６を使用するのか を決定する。この決定は、要求プロセッサ２３０からの要求されたサービスのリ スト２４２、および利用可能なサービス情報データベース２３６からの利用可能 なＩＰＣ製品２４４のリストの、２つの入力に基づくものである。レジストリの 好ましい実施の形態においてはデレクトリ・サービス２１０とともに存在してい る利用可能なサービス情報データベース２３６は、全ての利用可能なＩＰＣ製品 （メッセージ通信用製品２１６およびデータネットワーク２１８のプロトコルを 含む）のプログラムされたリストおよびそれらの要件を含んでいる。特定の要求 に対する要求されたサービス２４２、および利用可能なＩＰＣ製品２４４に基づ いて、ＩＰＣ製品修飾要素２３２は使用する適切なＩＰＣ製品２１６を選択する 。次いで、この選択されたＩＰＣ製品２４６の識別をＩＰＣメッセージ通信イン ターフェース２３４に送信する。 ＩＰＣメッセージ通信インターフェース２３４は、選択されたメッセージ通信 用製品２１６を含めて、レジストリのインターフェースに選択されたＩＰＣ製品 を提供する。上記したように、ＩＰＣはクライアントのレジストリからサーバの レジストリにメッセージを移送するために必要とされる全ての要素について参照 している。これには、主として産業分野で標準的なメッセージ通信用製品２１６ およびデータ・ネットワーク製品２１８が含まれる。ＩＰＣは、汎用ＩＰＣ要求 ２４０を選択されたメッセージ通信用製品２１６によって規定され要求されるフ ォーマットに翻訳する。また、メッセージ通信用製品２１６とダイアログを開始 する。汎用ＩＰＣ要求２４０（クライアントのネイテブな要求メッセージを含む ）は、適切なメッセージ通信用製品２１６のフォーマットに翻訳されたときに、 データ・ネットワーク２１８上で遠隔のサーバ２２２に移送するためにメッセー ジ製品２１６に進む。 図２を参照して、サーバ端において、メッセージ通信用製品２１６はネットワ ーク２１８からメッセージを受信し、またメッセージ２２４を汎用ＩＰＣインタ ーフェース２１２を経てレジストリ２０４に配信する。このレジストリ２０４へ のメッセージ２２４配信は、サーバ端においてレジストリにより行われる全体の プロセスとともに、レジストリ・プロセス・モニタ２２０として識別されるレジ ストリ要素により制御される、レジストリ・プロセス・モニタ２２０は、サーバ ２２２のメッセージの受信および処理を制御する。この目的は、メッセージのサ ーバのスループットを最大にし、作業負荷を処理するためにサーバのタスクの所 望の数を管理し、作業負荷の要求変更としてのサーバのタスクの終了／再起動す ることによりサーバの容量および利用度を制御し、またサーバのリソースの割り 当ての制御のためのアプリケーション−規定の機構を提供することである。 図２ｂを参照して、レジストリ・プロセス・モニタ（ＲＰＭ）２２０がその動 作を例示するために詳細に示されている。ＲＰＭは、キュー・モニタ（ＱＭ）２ ６０、プロセス・モニタ（ＰＭ）２６２、および制御モニタ（ＣＭ）などの、３ つの主要な要素から構成される。 サーバ−バウンド（server-bound）のメッセージは、メッセージ通信用製品２ １６によりネットワーク２１８から検索され、レジストリ２０４により検索待ち のキュー内に保持される。各キューにはその優先度を示すためにサービスのクラ スが割り当てられている。各ＱＭ２６０にはキューあるいはキューの範囲、つま りサービスのクラスあるいはクラスの範囲が割り当てられている。ＱＭ２６０は 、メッセージ通信用製品２１６からキュー・ステータス・データ２２６を受信す ることにより、これらのキューをモニタする。サーバの処理に対して解放された メッセージを追跡することにより、ＱＭ２６０はサーバにおける現在の利用度の レベルおよび別のメッセージの処理のためのその容量を知る。ＱＭ２６０が、サ ーバが別のメッセージを処理するための十分なリソースの容量を有することを決 定したとき、ＱＭ２６０は続く処理のための特定のキューからのメッセージを選 択する。次いで、ＰＭ２６２に、メッセージを検索するために必要とされるサー バのスレッドに対する要求２７０を送信する。このサーバのスレッド２７６は、 サーバ２２２のオペレーティング・システムとレジストリ２０４の間の処理リン クを表している。これは、クライアントのメッセージを要求および受信するため にサーバのアプリケーション２２２により使用される。 ＰＭ２６２は、それ自体をレジストリに登録することによりスレッドをセット アップするために、要求２７２をサーバ２２２に送る。サーバ２２２は次いで、 レジストリにＲＥＧＩＳＴＥＲバーブを発行する。これにより、クライアント２ ０２が行ったのと同じ方法で、サーバ２２２とレジストリ２０４との間でセッシ ョンが設立される。サーバ２２２は次いで、サーバのスレッド２７６を経てクラ イアントの要求メッセージを受信することを許容する、ＲＥＣＥＩＶＥＲＥＱＵ ＥＳＴバーブを発行する。 ＲＥＣＥＩＶＥＲＥＱＵＥＳＴバーブはＡＰＩ２０６により受信され、また処 理のためにバーブ実行部２０８に進む。バーブ実行部２０８はパラメータを有効 性検査する。ＷＳ−ＲＥＱＵＥＳＴ−ＭＳＧパラメータから、レジストリはメッ セージがどこにあるのか、およびそれを汎用ＩＰＣインターフェース２１２を経 て検索できるのかを知る。ＩＰＣパラメータ２１２はメッセージ２２４を検索し 、これからクライアントのネイテブ要求メッセージを抽出する。このクライアン トの要求メッセージは次いでアプリケーション−特定の処理のためにサーバ２２ ２に進む。 ＣＭ２６４は、レジストリに対するシステム管理および構成を提供する、ユー ティリティ機能を行う。これは、オペレータがシステムの管理機能を行うことが できるように、システムのオペレータにグラフィカル・ユーザ・インターフェー ス（ＧＵＩ）２６６を提供する。また、オペレータに各ＱＭ２６０により管理さ れるキューのドメインを変更することを許容する。 図２に戻って、クライアントの要求メッセージの処理後、および応答が必要で ある場合、サーバはＳＥＮＤＲＥＰＬＹバーブを発行する。このバーブは、ＷＳ −ＳＥＮＤＲＥＰＬＹ−ＭＳＧとして識別される、サーバの応答メッセージをパ ラメータとして含んでいる。このバーブはＳＥＮＤＲＥＱＵＥＳＴバーブが先に 処理された方法と同様に処理される。 図３に戻って、サーバのアプリケーションにメッセージを送信するためにクラ イアントのアプリケーションがＳＥＮＤＲＥＱＵＥＳＴバーブを発行したときに おけるレジストリの動作を例示したプロセスの流れ図が例示されている。ＣＯＮ ＶＥＲＳＥバーブが発行された場合には同様な動作が行われる。 ステップ３０２において、クライアントのアプリケーション２０２は処理する ためにサーバのアプリケーション２２２に対して要求を開始する。この要求は、 遠隔の装置上に存在する、サーバのアプリケーション２２２に配信されなければ ならない。ステップ３０２において、要求はよって、クライアントのアプリケー ション２０２内で遠くに含まれる。 ステップ３０４において、クライアント２０２はレジストリ２０４にＲＥＧＩ ＳＴＥＲバーブを発行する。ＲＥＧＩＳＴＥＲバーブは、クライアント２０２と レジストリ２０４との間で通信セッションを設立するコマンドである。ステップ ３０６において、レジストリ２０４のバーブ実行要素２０８はＲＥＧＩＳＴＥＲ バーブのパラメータを有効性検査する。次いで、ステップ３０８において、バー ブ実行部２０８は、クライアント２０２とレジストリ２０４の間にバーブ・パラ メータ（クライアントのメッセージを含む）を進めるために使用されるメモリ割 り当てである、登録制御領域（ＲＣＡ）を組み込む。 ステップ３１０において、クライアント２０２はＳＥＮＤＲＥＱＵＥＳＴバー ブをレジストリ２０４に発行する。クライアント２０２はこの要求メッセージを ＳＥＮＤＲＥＱＵＥＳＴバーブのパラメータとして送信する。ステップ３１２に おいて、レジストリ２０４のバーブ実行要素２０８はＳＥＮＤＲＥＱＵＥＳＴバ ーブのパラメータを有効性検査する。次いで、ステップ３１４において、バーブ 実行部２０８は意図したサーバのアプリケーション２２２の物理的なネットワー ク経路選択アドレスを決定する。これは、クライアントのメッセージからサーバ のアプリケーションの名前を抽出し、この名前をデイレクトリ・サービス２１０ への照会を経てネットワーク宛先に翻訳することにより行われる。デイレクトリ ・サービス２１０は、先に図２を参照して特定したように、ドメイン、サービス 名、およびサービス修飾子の形式でネットワーク宛先を戻す。 ステップ３１６において、バーブ実行要素２０８は、汎用ＩＰＣインターフェ ース２１２に汎用ＩＰＣ要求を発行することにより、ＳＥＮＤＲＥＱＥＳＴに関 するその最終的な機能を実行する。汎用ＩＰＣ要求は、ＩＰＣインターフェース ２１２にクライアントのメッセージを配信するために必要な一定の機能を実行す ることを指示するコマンドである。これらの機能はステップ３１８から３２４に おいて特定されている。汎用ＩＰＣ要求はまた、クライアントのメッセージおよ びサーバのネットワーク・アドレスを含んでいる。汎用ＩＰＣ要求の発行は図２ ａにおいて項目２４０で示されている。 次いで図３ａを参照して、ステップ３１８において、汎用ＩＰＣインターフェ ース要求・プロセッサ２３０は、汎用ＩＰＣ要求を処理するために必要とされる サービスのリストをコンパイルする。これらの必要とされるサービスは、メッセ ージ通信製品２１６において行われる。生成され必要とされたサービス・リスト ２４２は、ＩＰＣ製品２４４を選択するためにステップ３２０においてＩＰＣ製 品修飾要素２３２により使用される。ＩＰＣ製品修飾部２３２はまた、利用可能 なサービス情報データベース２３６から利用可能なＩＰＣ製品２４４のリストを 受信する。 ステップ３２０において、ＩＰＣ製品周力部２３２は要求されたサービス・リ スト２４２からの要求されたサービスを利用可能なＩＰＣ製品リスト２４４内で 識別された一定のＩＰＣ製品から提供されるものと突き合わせる、また適当なＩ ＰＣ製品を選択する。選択されたＩＰＣ製品はメッセージ通信製品２１６および ／またはデータ・ネットワーク２１８のトランスポート・プロトコルである。選 択されたＩＰＣ製品の識別は、次いでＩＰＣメッセージ通信インターフェース要 素２３４に送られる。 ステップ３２２において、ＩＰＣメッセージ通信インターフェース要素２３４ は汎用ＩＰＣ要求（図２ａで示したようにバーブ実行部２０８から受信した）を 選択されたＩＰＣ製品の所有のメッセージにフォーマットする。このフォーマッ トの翻訳のための手順はＩＰＣメッセージ通信インターフェース要素２３４内に プログラムされている。次いで、ステップ３２４において、インターフェース２ ３４は、メッセージ通信製品のために標準的な方法で選択されたメッセージ通信 製品２１６と通信セッションを設立する。セッションが設立されると、メッセー ジは、データ・ネットワーク２１８上でメッセージを配信するための処理をする 、メッセージ通信製品に進む。ここで、「メッセージ」は、レジストリが選択さ れたＩＰＣ製品に対して特別にフォーマットしたエンベロープ内にパッケージさ れたクライアントのネイテイブな要求メッセージから構成される。 ステップ３２６は、使用される特定のネットワーク・プロトコルに対して標準 的な方法でネットワーク２１８上でメッセージを移送することを表している。 ステップ３２８において、サーバのサイトにおけるレジストリは、メッセージ を受信するために準備されている。レジストリ・プロセス・モニタ２２０のキュ ー・モニタ（ＱＭ）要素２６０は一定のキューのメッセージをモニタする。これ は、接続されたメッセージ通信製品２１６のそれぞれからキューのステータス・ データ２２６を受信することにより行われる。ＱＭ２６０はまた、最初のサーバ 容量でプログラムされることによりサーバのリソース容量を追跡し、またサーバ に送られた各メッセージをトラッキングする。この方法において、ＱＭ２６０は 現在のサーバの利用度および別の処理をするためのその容量を知る。ステップ３ ２８の一部として、ＱＭ２６０はサーバの現在の容量を評価するとともに次のメ ッセージが何時検索されるのかを決定する。 ステップ３３０において、ＱＭ２６０は検索される次のメッセージを決定し、 またサーバのスレッド２７６に対する要求を発行する。先に説明したように、こ のサーバのスレッド２７６はサーバ２２２のオペレーティング・システムとレジ ストリ２０４の間の処理リンクを表している。これは、メッセージを要求および 受信するためにサーバのアプリケーション２２２により使用される。サーバのス レッドの要求はＱＭ２６０によりプロセス・モニタ（ＰＭ）２６２に対して発行 される。 ステップ３３２において、ＰＭ２６２はサーバのオペレーティング・システム にサーバのスレッドに対する要求を発行する。これは、レジストリ２０４とセッ ションを設立するためにサーバのアプリケーション２２２に対するトリガとして 機能する。これは、クライアント２０２により先に行われたように、ＲＥＧＩＳ ＴＥＲバーブを発行することにより行われる。 ステップ３３４において、サーバ２２２は、レジストリのＡＰＩ２０６により 読み出されバーブ実行部２０８に進む、ＲＥＧＩＳＴＥＲバーブを発行する。こ れにより、サーバのレジストリとのセッションが設立される。処理は図３ｂのペ ージ外の接続部Ａに続く。 次に図３ｂを参照して、ステップ３３６において、バーブ実行部２０８は、ク ライアントについて行ったのと同様にサーバのＲＥＧＩＳＴＥＲバーブを処理す る。またこれは、現在のセッションに特定のＲＣＡを組み立てる。次いで、ステ ップ３３８において、サーバ２２２はレジストリにＲＥＣＥＩＶＥＲＥＱＵＥＳ Ｔバーブを発行する。ＲＥＣＥＩＶＥＲＥＱＵＥＳＴバーブはクライアントのメ ッセージをサーバ２２２に送るためにレジストリに指示する。 ステップ３４０において、バーブ実行部２０８はＲＥＣＥＩＶＥＲＥＱＵＥＳ Ｔバーブのパラメータを有効性検査する。パラメータの１つはクライアントの要 求メッセージのメモリ内にアドレスに集団化（populate）される。ステップ３４ ２において、バーブ実行部２０８は、ネットワーク２１８上で配信されパッケー ジ化されたメッセージからクライアントのネイテイブな要求メッセージを抽出し 、またこの要求メッセージをサーバ２２２に進める。 ステップ３４４において、サーバ２２２は、アプリケーションに特定でレジス トリに無関係な方法でクライアントの要求メッセージを処理する。サーバは、ス テップ３４６において決定された、必要あるいは不必要の選択に対応して、サー バの要求に応答する。応答が必要とされる場合、サーバ２２２はＳＥＮＤＲＥＰ ＬＹバーブをステップ３４８において発行し、これはステップ３１０において開 始される、クライアントのＳＥＮＤＲＥＱＵＥＳＴバーブと同じ方法で処理され る。サーバの応答は次いで、ステップ３５０に示したように、クライアントに配 信される。サーバ２２２は次いで、ステップ３５２において他のＲＥＣＥＩＶＥ ＲＥＱＵＥＳＴを発行するための処理をする。 ステップ３４６において決定されたように、応答が必要ない場合、サーバ２２ ２はステップ３５２において他のＲＥＣＥＩＶＥＲＥＱＵＥＳＴバーブを発行す る。サーバに対するキュー内に要求メッセージがない場合、ステップ３５４に示 したように、「もうメッセージがなし」を述べたメッセージがレジストリ２０４ からサーバ２２２に戻される。次いで、プロセスはステップ３５６で終了し、こ こでサーバ２２２はＤＥＲＥＧＩＳＴＥＲバーブを発行する。ＤＥＲＥＧＩＳＴ ＥＲバーブはレジストリにセッションの終りを指示する。 ステップ３５４において、「もうメッセージがなし」のメッセージが戻らなか った場合、要求メッセージがキュー内にあるという仮定がなされる。プロセスは ステップ３４０に戻り、ここでバーブ実行部２０８はパラメータを有効性検査す ることによりＲＥＣＥＩＶＥＲＥＱＵＥＳＴバーブの処理を進める。 上記の説明は本発明の範囲を制限するものではなく、好ましい実施の形態を説 明したものに過ぎない。当業者には他の自明な変更および修正が可能である。 当業者には自明な変更は適宜行うことができるので、本発明は図示し説明した 詳細に限定されるものではない。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，Ｓ Ｚ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ， ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，Ｉ Ｌ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ， ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，Ｒ Ｕ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＲ ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ 【要約の続き】 択された互換性のあるサーバによる使用のために、プロ トコルのフォーマットから元のアプリケーションの特定 のフォーマットに変換する。

Claims (1)

1. 【特許請求の範囲】 １． アプリケーションとデータ・ネットワークのトランスポート機構との間の 通信の論理層として機能するクライアント−サーバ・システムにおいて、 それぞれ異なるオペレーティング・システムにより制御されるアプリケーショ ンを実行することができる、複数のクライアント手段を含み、 （ａ）予め選択されたサーバ手段に宛てられた、クライアント手段からのア プリケーションの特定のメッセージを受容し、またこれらを標準的なレジストリ の特定のメッセージ内にカプセル化し、および （ｂ）レジストリの特別なメッセージを予め選択されたプロトコル内に翻訳 する ために各クライアント手段に接続された第１のレジストリ手段を含み、 翻訳されたメッセージを遠端まで通信するためのネットワークを含み、 （ａ）翻訳されたメッセージを受容し、および （ｂ）メッセージをプロトコルのフォーマットから元のアプリケーションの 特定のメッセージに変換する ために遠端に配置された第２のレジストリ手段を含み、 アプリケーションの特定のメッセージをサーバ手段に通信するためにレジスト リ手段を予め選択されたサーバ手段に接続するための手段を含んでなる、システ ム。 ２． 予め選択されたプロトコル内のレジストリの特定のメッセージを、ネット ワークに通信するために、第１のレジストリ手段とネットワークの間に接続され た第１のメッセージ通信手段、および 予め選択されたプロトコル内のレジストリの特定のメッセージを受信しこれら を第２のレジストリに転送するためにネットワークと第２のレジストリ手段の入 力との間に接続された第２のメッセージ通信手段、をさらに含んでなる請求の範 囲第１項記載のシステム。 ３． 第１のレジストリ手段が、クライアント手段からバーブ・コマンドを受信 するとともにクライアント手段からの関連するアプリケーションの特定のメッセ ージを対応するレジストリ・フォーマットに翻訳するために、クライアント手段 の出力に接続された、アプリケーション・プログラミング・インターフェース、 をさらに含んでなる請求の範囲第１項記載のシステム。 ４． 第１のレジストリ手段が、バーブ・コマンドのパラメータを有効性検査し 続いてクライアント手段からのメッセージに対する宛先アドレスを分解するため の手段、および クライアントのメッセージが意図されるサーバ手段への論理的なネットワーク の宛先を決定するために、有効性検査されたバーブ・コマンドにより照会される デレクトリ・サービス・データベース、をさらに含んでなる請求の範囲第３項記 載のシステム。 ５． 第１のレジストリ手段が、デレクトリ・サービス・データベース手段から 導出された宛先情報に応答して、レジストリ・フォーマットであるメッセージを その出力に平行に接続された複数のアダプタの１つにスイッチするためのプロセ ス間通信手段をさらに含んでなり、アダプタは選択された第１のメッセージ通信 手段により要求されるとともにサーバ手段に宛てられた特定のプロトコルのフォ ーマットにレジストリ・メッセージをマッピングする、請求の範囲第２項記載の システム。 ６． 第２のレジストリ手段が、 特定のプロトコル内のメッセージをレジストリのフォーマットに翻訳するため に第２のメッセージ通信手段の出力に接続された、複数の平行に接続されたアダ プタ、 アダプタからの翻訳されたメッセージを別の処理のために選択的に受信するた めのプロセス間通信手段、および レジストリのフォーマットである、メッセージをサーバ・アプリケーションに より必要とされるフォーマットに翻訳するとともにこれを指定されたサーバに接 続するためにプロセス間通信手段の出力に接続された、アプリケーション・プロ グラムイング・インターフェース、を含んでなる請求の範囲第２項記載のシステ ム。 ７． 指定されたサーバによるスケジューリング処理のための、アプリケーショ ン・プログラミング・インターフェースの入力に接続されたレジストリ・モニタ リング手段をさらに含んでなる請求の範囲第６項記載のシステム。 ８． 第２のレジストリ手段が （ａ）照会に応答して、サーバにより生成されたバーブ・コマンドのパラメー タを有効性検査し続いてクライアント手段からのメッセージに対する宛先アドレ スを分解するための手段、 （ｂ）サーバ手段から最初の照会を生成したクライアント手段への、応答のた めに論理的なネットワーク宛先を決定するために、クライアント手段からのバー ブ有効性検査コマンドにより照会されるデイレクトリ・サービス・データベース 、 （ｃ）選択された第２のメッセージ通信手段の入力へ応答を通信するために第 ２のレジストリ手段内のアダプタを選択する第２のレジストリ手段内のプロセス 間通信手段、および メッセージ通信手段をネットワークに接続するために、第２のレジストリ手段 の外側に配置された、アダプタ手段、 をさらに含んでなる請求の範囲第７項記載のシステム。 ９． アプリケーションとデータ・ネットワークのトランスポート機構との間の 通信の論理層として機能するクライアントーサーバ・システムにおいて、 それぞれ対応するオペレーティング・システムにより制御されるアプリケーシ ョンを開始することができる、複数のクライアントを含み、 （ａ）予め選択されたサーバに宛てられた、クライアントからのアプリケー ションの特定のメッセージを受容し、またこれらを標準的なレジストリの特定の メッセージ内にカプセル化し、および （ｂ）レジストリの特別なメッセージを予め選択されたプロトコル内に翻訳 する ために各クライアントに接続された第１のレジストリを含み、 翻訳されたメッセージを遠端に通信するためのネットワークを含み、 予め選択されたプロトコル内のレジストリの特別なメッセージを、ネットワー クに通信するために、第１のレジストリとネットワークとの間に接続された第１ のメッセージ通信装置を含み、 （ａ）翻訳されたメッセージを受容し、および （ｂ）メッセージをプロトコルのフォーマットから元のアプリケーションの 特定のメッセージに変換する ために遠端に配置された第２のレジストリを含み、 アプリケーションの特定のメッセージをサーバに通信するために第２のレジス トリは予め選択されたサーバに接続されており、 予め選択されたプロトコル内のレジストリの特定のメッセージを受信するとと もにこれらを第２のレジストリに転送するためにネットワークと第２のレジスト リの入力との間に接続された、第２のメッセージ通信装置を含んでなる、システ ム。 １０． 第１のレジストリがさらに クライアントからバーブ・コマンドを受信するとともにクライアントからの関 連するアプリケーションの特定のメッセージを対応するレジストリ・フォーマッ トに翻訳するために、クライアントの出力に接続された、アプリケーション・プ ログラミング・インターフェースを含み、 バーブ・コマンドのパラメータを有効性検査し続いてクライアントからのメッ セージに対する宛先アドレスを分解するための有効性検査デバイスを含み、 クライアントのメッセージが意図されるサーバへの論理的なネットワークの宛 先を決定するために有効性検査されたバーブ・コマンドにより照会されるデイレ クトリ・サービス・データベースを含み、 デレクトリ・サービス・データベースから導出された宛先情報に応答して、レ ジストリ・フォーマットであるメッセージをその出力に平行に接続された複数の アダプタの１つにスイッチするためのプロセス間通信機構をさらに含んでなり、 アダプタは選択された第１のメッセージ通信装置により要求されるとともにサー バに宛てられた特定のプロトコルのフォーマットにレジストリ・メッセージをマ ッピングする、請求の範囲第９項記載のシステム。 １１． 第２のレジストリが、 特定のプロトコル内のメッセージをレジストリのフォーマットに翻訳するため に第２のメッセージ通信装置の出力に接続された、複数の平行に接続されたアダ プタ、 アダプタからの翻訳されたメッセージを別の処理のために選択的に受信するた めのプロセス間通信機構、および レジストリのフォーマットである、メッセージをサーバ・アプリケーションに より必要とされるフォーマットに翻訳するとともにこれを指定されたサーバに接 続するためにプロセス間通信機構の出力に接続された、アプリケーション・プロ グラムイング・インターフェース、 指定されたサーバによるスケジューリング処理のための、アプリケーション・ プログラミング・インターフェースの入力に接続されたレジストリ・モニタ、 照会に応答して、サーバにより生成されたバーブ・コマンドのパラメータを有 効性検査し続いてクライアントからのメッセージに対する宛先アドレスを分解す るための第２の有効性検査機構、 サーバから最初の照会を生成したクライアントへの、応答のための論理的なネ ットワーク宛先を決定するために、クライアントからのバーブ有効性検査コマン ドにより照会されるデイレクトリ・サービス・データベース、 選択された第２のメッセージ通信手段の入力へ応答を通信するために第２のレ ジストリ内のアダプタを選択する第２のレジストリ内のプロセス間通信機構、お よび メッセージ通信装置をネットワークに接続するために、第２のレジストリの外 側に配置された、アダプタ、を含んでなる請求の範囲第９項記載のシステム。 １２． それぞれ異なるオペレーティング・システムにより制御されるアプリケ ーションを実行することができ、ネットワーク上で選択的に相互接続された複数 のクライアント装置およびサーバ装置、これら装置の間の通信の論理層を有する コンピュータ・システムにおいて、 （ａ）予め選択されたサーバに宛てられた、クライアントからのアプリケー ションの特定のメッセージを受容し、またこれらを標準的なレジストリの特定の メッセージ内にカプセル化するステップ、および （ｂ）レジストリの特別なメッセージを予め選択されたプロトコル内に翻訳 するステップ を含む第１のレジストリ・プロセスを行うステップ、 予め選択されたプロトコル内のレジストリの特定のメッセージを、ネットワー クに、通信するためにレジストリの特定のメッセージをメッセージ通信するステ ップ、 （ｃ）翻訳されたメッセージを受容するステップ、および （ｄ）メッセージをプロトコルのフォーマットから元のアプリケーションの 特定のメッセージに変換するステップ を含む遠端における第２のレジストリ・プロセスを行うステップ、 変換されたアプリケーションの特定のメッセージを予め選択されｓｔあサーバ に接続するステップを含んでなる、方法。 １３． 第１のレジストリ・プロセスがさらに クライアントからバーブ・コマンドを受信するとともにクライアントからの関 連するアプリケーションの特定のメッセージを対応するレジストリ・フォーマッ トに翻訳するために、アプリケーション・プログラミングをインターフェースす るステップを含み、 バーブ・コマンドのパラメータを有効性検査し続いてクライアントからのメッ セージに対する宛先アドレスを分解するステップを含み、 クライアントのメッセージが意図されるサーバへの論理的なネットワークの宛 先を決定するために有効性検査されたバーブ・コマンドによりデイレクトリ・サ ービス・データベースを照会するステップを含み、 デレクトリ・サービス・データベースから導出された宛先情報に応答して、レ ジストリ・フォーマットであるメッセージを複数のアダプタの１つにプロセス間 通信スイッチングするステップを含んでなり、アダプタは選択された第１のメッ セージ通信装置により要求されるとともにサーバに宛てられた特定のプロトコル のフォーマットにレジストリ・メッセージをマッピングする、請求の範囲第１２ 項記載の方法。 １４． 第２のレジストリ・プロセスがさらに、 特定のプロトコル内のメッセージを逆に処理してメッセージをレジストリのフ ォーマットに翻訳するステップ、 翻訳され処理されたメッセージを別の処理のために選択的にプロセス間通信ス イッチングするステップ、 レジストリのフォーマットである、メッセージをサーバ・アプリケーションに より必要とされるフォーマットに翻訳するとともにこれを指定されたサーバに接 続するためにアプリケーション・プログラムイングをインターフェース処理する ステップ、 指定されたサーバによるスケジューリング処理のために、アプリケーション・ プログラミングのインターフェース処理をモニタするステップ、 クライアントからの照会に応答して、サーバにより生成されたバーブ・コマン ドのパラメータを有効性検査し続いてクライアントからのメッセージに対する宛 先アドレスを分解するステップ、 サーバから最初の照会を生成したクライアントへの、応答のための論理的なネ ットワーク宛先を決定するために、クライアントからのバーブ有効性検査コマン ドによりデイレクトリ・サービス・データベースを照会するステップ、 アプリケーションを開始したクライアントへの最終的な配信のために応答をク ライアントの方向に通信するステップを含んでなる、請求の範囲第１２項記載の 方法。