JP4469223B2 - 通信システム及び通信資源調整装置及び通信資源調整方法 - Google Patents

Description

本発明は、特に、分散オブジェクトシステムの品質制御技術に関する。

ＩＤＬ（Ｉｎｔｅｒｆａｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ） Ｃａｌｌを用いた分散オブジェクト技術の従来例として、ＯＭＧ（Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）による国際標準仕様ＣＯＲＢＡ（Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）を実現するミドルウェアＯＲＢ（Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ）技術がある。

図２０は、従来例における分散オブジェクトシステム構成、図２１は、従来例によるＣｌｉｅｎｔ計算機構成、図２２は、従来例によるＳｅｒｖｅｒ計算機構成である。図２３はＩＤＬ Ｃａｌｌを実現するために、クライアント／サーバ間で行われるオブジェクトメッセージ通信を一般化したモデルである。図２４はクライアントがサーバを識別するために利用するオブジェクト識別子の構成である。

図２０に示す分散オブジェクトシステムでは、Ｃｌｉｅｎｔ計算機（１）に搭載されるＣｌｉｅｎｔ（１０１）が、ＩＤＬ呼び出しにより、Ｎｅｔｏｒｋ（３）を介して、Ｓｅｒｖｅｒ計算機（２）に搭載されるＳｅｒｖｅｒ（２０１）に実装されるメソッドを呼び出す。ここでＣｌｉｅｎｔ（１０１）とＳｅｒｖｅｒ（２０１）は、Ｎｅｔｗｏｒｋ（３）の種別とは独立に開発可能な可搬性を実現するために、Ｃｌｉｅｎｔ計算機（１）は、Ｃｌｉｅｎｔ（１０１）と通信機器（１０３）を、ＯＲＢ（Ｃｌｉｅｎｔ Ｓｉｄｅ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ）（１０２）を介して分離し、またＳｅｒｖｅｒ計算機（２０２）は、Ｓｅｒｖｅｒ（２０１）と通信機器（１０３）を同じくＯＲＢ（Ｓｅｒｖｅｒ Ｓｉｄｅ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ）（２０２）を介して分離する構成を採用している。

次に図２３を用いてクライアント（１０１）とサーバ（２０１）間の相互接続動作を以下の３段階（接続準備段階、Ｒｅｑｕｅｓｔ段階、Ｒｅｐｌｙ段階）に分けて説明する。

接続準備段階では、クライアント（１０１）はサーバ（２０１）に対して期待するメソッドの存在確認と接続準備の完了を要求するために、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（ｍ１）を送信する。これに対してサーバ（２０１）は、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージ（ｍ２）にて準備完了を通知する。

Ｒｅｑｕｅｓｔ段階では、クライアント（１０１）はサーバ（２０１）に対して、呼び出すメソッド名とｉｎｐｕｔパラメータ情報をＲｅｑｕｅｓｔメッセージ（ｍ３）により送信する。これに対してサーバ（２０１）はメソッド呼び出しが成功した事をＲｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージ（ｍ４）にてクライアント（１０１）へ通知する。

Ｒｅｐｌｙ段階では、サーバ（２０１）はメソッド処理が終了した時に、Ｒｅｐｌｙメッセージ（ｍ５）にて、メソッド実行の結果であるｏｕｔｐｕｔパラメータとｒｅｔｕｒｎ情報をクライアント（１０１）へ通知する。

この動作においてクライアント（１０１）は、呼び出すサーバ（２０１）の識別子を図２４に示すオブジェクト識別子を用いて管理する。オブジェクト識別子は、サーバ（２０１）を識別するサーバ識別子（ｔ０１）、このサーバ（２０１）が動作するプロセスを識別するプロセス識別子（ｔ０２）、サーバ（２０１）が搭載される計算機の通信ポートなどを識別するネットワーク識別子（ｔ０３）から構成されており、サーバ計算機（２）のＯＲＢ（１０２）は、この識別子の情報を辿る事により計算機内のサーバ（２０１）へ接続できる。ＯＲＢ（１０２）は、このオブジェクト識別子を用いてクライアント（１０１）とサーバ（２０１）間の相互接続を実現するため、アプリケーション開発者は、オブジェクト識別子の詳細な情報量を知らる必要が無く、この分析処理をＯＲＢに任す事ができるため、アプリケーションとなるクライアントロジック（１０１１）とサーバインプリメンテーション（２０１１）は、ネットワーク環境や接続手順に関係なく独立する可搬性のある開発が可能となる。
また、特開２００１−３４５８３号公報では、一元的かつリアルタイムにサーバオブジェクトの負荷情報を収集し、特定の負荷の偏りを防ぎ、個々のサーバオブジェクトに要求された処理の実行時間増大を防止する分散オブジェクト性能管理機構が開示されている。
特開２００１−３４５８３号公報 ＣＯＲＢＡ／ＩＩＯＰ Ｓｐｅｃｉｆｉｃａｔｉｏｎ （ｈｔｔｐ：／／ｗｗｗ．ｏｍｇ．ｏｒｇ／ｔｅｃｈｎｏｌｏｇｙ／ｄｏｃｕｍｅｎｔｓ／ｆｏｒｍａｌ／ｃｏｒｂａ＿ｉｉｏｐ．ｈｔｍ） 「ＣＯＲＢＡ完全解説」小野沢博文著、ソフト・リサーチ・センター

従来の分散オブジェクトシステムは、ＩＤＬを用いてクライアントが分散環境上のサーバを呼び出すために、クライアント計算機とサーバ計算機の通信デバイスやプロセスメモリなどの経路情報の組み合わせにて構成していたため、クライアントロジックが期待するサーバインプリメンテーションまでのエンドツーエンド間の通信品質を保証できないという問題があった。

また、クライアント計算機からサーバ計算機までのルーティングの順番に中継する通信機器の利用方法を設定するため、アプリケーションが期待するＱｏＳ−Ｐｏｌｉｃｙに対する通信資源の割り当てを調整できないという問題点があった。

また、クライアント計算機は予め設定されたオブジェクト識別子を用いてサーバ計算機のサーバインプリメンテーションへＩＤＬ呼び出しを行うため、例えば一つの通信機器に同時に複数のＩＤＬ呼び出しが行われた場合に、クライアントロジックが期待するＱｏＳ品質に関係なく到着の順番に呼び出しが行われるため、優先度が高くても待ち時間が生じるという問題があった。

また、クライアントロジックが指定するＱｏＳ−Ｐｏｌｉｃｙ情報に基づいてクライアント計算機とサーバ計算機と、この間の通信機器がＩＤＬ通信路のために利用する資源を確保するため、必ずしもサーバインプリメンテーションのＱｏＳ設計値に基づくＩＤＬ呼び出しが行われないという問題点があった。

また、クライアントロジックが指定するＱｏＳ−Ｐｏｌｉｃｙ情報を満足する通信装置の資源を確保するために、通信機器が実現するルーティング情報に基づく通信路を辿りながら資源の割り当てが行われ、ネットワーク上のこの通信路を外れる通信機器の資源を考慮する事ができないという問題点があった。

この発明は上記の問題点を解決することを主な目的としており、クライアントとサーバが搭載される計算機とネットワークのＱｏＳ制御機構が連携する事により、クライアントロジックにて指定するＱｏＳ−Ｐｏｌｉｃｙに応じてサーバのメソッド呼び出しが起動される時に、クライアントロジックとサーバインプリメンテーション間のｅｎｄ−ｔｏ−ｅｎｄのネットワーク資源と計算機資源を予約する事によりメソッド呼び出し時の品質を保証する品質制御方式の実現を主な目的とする。

また、ネットワーク内に用意したＱｏＳ調整機能が、クライアント計算機、サーバ計算機、中継通信機器間で、要求されたＱｏＳ−Ｐｏｌｉｃｙを最適に配置する品質制御方式の実現を主な目的とする。

また、予めＱｏＳ−Ｐｏｌｉｃｙと同時に指定される優先度に基づいて、ＩＤＬ通信時に各ＱｏＳ−Ｐｏｌｉｃｙ処理部がオブジェクト識別子が指定する資源利用の優先度制御を行う品質制御方式の実現を主な目的とする。

また、クライアントロジックとサーバインプリメンテーションが指定するＱｏＳ−Ｐｏｌｉｃｙを比較する事により、サーバインプリメンテーションが指定するＱｏＳ−Ｐｏｌｉｃｙの条件を満たさないＩＤＬ呼び出しを拒絶する品質制御方式の実現を主な目的とする。

また、ＱｏＳ−Ｐｏｌｉｃｙ処理部に期待するＱｏＳ−Ｐｏｌｉｃｙの公募を行い、最適な応募を選択して利用する通信基盤のルーティングに依存しない品質制御方式の実現を主な目的とする。

本発明に係る通信システムは、
クライアント装置と、クライアント装置と通信を行ってクライアント装置に対してサービスを提供するサーバ装置とを有する通信システムであって、
クライアント装置は、
サーバ装置によるサービスの提供に先立ち、サービス提供時に要求される通信品質を要求通信品質として指定し、要求通信品質を実現するための通信資源を確保し、要求通信品質を通知するとともに要求通信品質を実現するための通信資源の確保を要求する要求通信品質通知を生成し、生成した要求通信品質通知をサーバ装置に対して送信し、
サーバ装置は、
クライアント装置より送信された要求通信品質通知を受信し、要求通信品質通知に示された要求通信品質を実現するための通信資源を確保し、要求通信品質を実現するために確保した通信資源を用いてクライント装置に対してサービスを提供することを特徴とする。

本発明によれば、サーバ装置によるサービスの提供に先立ち、クライアント装置及びサーバ装置のそれぞれが要求通信品質を実現するための通信資源を確保するため、クライアント装置は要求通信品質を実現した状態でサーバ装置からのサービスを受けることができる。

実施の形態１．
図１は本実施の形態に係る品質制御型分散オブジェクトシステム（通信システム）を示す構成図である。これは図２０に示す従来例のシステム構成に対して、クライアントとサーバが搭載されるクライアント計算機（１）とサーバ計算機（２）上のＯＲＢ（Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ）（１０２、 ２０２）と、ネットワーク（３）を構成するＰｒｏｘｙ計算機（６ａ、 ６ｂ、 ６ｃ、・・）上のＰｒｏｘｙ−Ｂｒｏｋｅｒ（６０２ａ、 ６０２ｂ、 ６０３ｃ、・・）がＩＤＬ Ｃａｌｌ時に連携して品質制御を行うための機能を追加した構成である。なお、以降、クライアント計算機（１）についてはＣｌｉｅｎｔ計算機（１）とも表記し、クライアント（１０１）についてもＣｌｉｅｎｔ（１０１）とも表記する。更に、サーバ計算機（２）についてもＳｅｖｅｒ計算機（２）とも表記し、サーバ（２０１）についてもＳｅｒｖｅｒ（２０１）とも表記する。また、クライアント計算機（１）はクライアント装置の例に、サーバ計算機（２）はサーバ装置の例に、Ｐｒｏｘｙ計算機（６）は中継装置の例に相当する。

次に、図１に示す構成における動作として、クライアント（１０１）からサーバ（２０１）へのＩＤＬ Ｃａｌｌを実現するために、Ｃｌｉｅｎｔ計算機（１）がＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（ｍ１）を発行して、Ｓｅｒｖｅｒ計算機（２）にてサーバ（２０１）が起動され、ここで生成されたオブジェクト識別子がＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージ（ｍ２）にてクライアント（１０１）へ返されるまでの処理の流れを、図１７〜図１９を用いて概説する。

図１７は、本実施の形態に係るクライアント計算機（１）の動作例を示すフローチャート図であり、
図１８は、本実施の形態に係るサーバ計算機（２）の動作例を示すフローチャート図であり、図１９は、本実施の形態に係るＰｒｏｘｙ計算機（６）の動作例を示すフローチャート図である。

まず、図１７に従ってクライアント計算機（１）の動作例を説明する。まず、ステップＳ１７０１において、クライアント（１０１）が、ＩＤＬ Ｃａｌｌを発行するためのＩＤＬ Ｃａｌｌ情報と、ＩＤＬ Ｃａｌｌによるメソッド呼出し時に要求する通信品質を示すＱｏＳ−Ｐｏｌｉｃｙ情報をクライアント側のＯＲＢ（１０２）に伝達する。ここで、ＱｏＳ−Ｐｏｌｉｃｙ情報はクライアント（１０１）が要求する要求通信品質が示された情報である。このため、ステップＳ１７０１では、クライント（１０１）が要求通信品質を指定するとともに、指定した要求通信品質が示されたＱｏＳ−Ｐｏｌｉｃｙ情報をクライアント側のＯＲＢ（１０２）に伝達する処理が行われる（要求通信品質指定ステップ）。次に、ステップＳ１７０２において、クライアント側のＯＲＢ（１０２）では、ＱｏＳ−Ｐｏｌｉｃｙ情報に示された要求通信品質を実現するための通信資源（具体的には、通信ポート）を確保（予約）する（通信資源確保ステップ）。次に、ステップＳ１７０３において、クライアント側のＯＲＢ（１０２）は、クライアント（１０１）からのＱｏＳ−Ｐｏｌｉｃｙ情報を含むＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージを生成する。このＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージは、ＱｏＳ−Ｐｏｌｉｃｙ情報を含むため、サーバ計算機（２）及びＰｒｏｘｙ計算機（６）に対して要求通信品質を実現するための通信資源の確保を要求する要求通信品質通知に相当する。このため、ステップＳ１７０２は、要求通信品質通知生成ステップに相当する。なお、詳細は後述するが、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージには、Ｓ１７０２で確保した通信ポートに対応するＰｒｏｘｙ識別子が付加される。クライアント側のＯＲＢ（１０２）では、例えば、図８に示すＱｏＳ−Ｐｒｏｘｙ管理テーブルを保有しており、Ｓ１７０２で確保した通信ポートに対応するＰｒｏｘｙ識別子をＱｏＳ−Ｐｒｏｘｙ管理テーブルから抽出して、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージに付加する。最後に、ステップＳ１７０４において、クライアント計算機（１）の通信機器（１０３）がＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージを送信する（送信ステップ）。

次に、図１９に従ってＰｒｏｘｙ計算機（６）の動作例を説明する。まず、クライアント計算機（１）とサーバ計算機（２）との間の通信を中継するＰｒｏｘｙ計算機（６）では、ステップＳ１９０１において、クライアント計算機（１）から送信されたＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージを受信する（受信ステップ）。次に、ステップＳ１９０２において、Ｉｎｉｔｉａｌ＿ＲｅｑｕｅｓｔメッセージのＱｏＳ−Ｐｏｌｉｃｙ情報に示された要求通信品質を実現するための通信資源（具体的には、通信ポート）を確保（予約）する（通信資源確保ステップ）。次に、ステップＳ１９０３において、Ｉｎｉｔｉａｌ＿ＲｅｑｕｅｓｔメッセージにＰｒｏｘｙ識別子を付加する（情報付加ステップ）。Ｐｒｏｘｙ計算機（６）においても、図８に示したようなＱｏＳ−Ｐｒｏｘｙ管理テーブルを保有しており、Ｓ１９０２で確保した通信ポートに対応するＰｒｏｘｙ識別子をＱｏＳ−Ｐｒｏｘｙ管理テーブルから抽出して、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージに付加する。なお、クライアント計算機（１）及び各Ｐｒｏｘｙ計算機（６）においてＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージに付加されたＰｒｏｘｙ識別子の集合をＰｒｏｘｙリストと呼ぶ。最後に、ステップＳ１９０４において、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージを次のＰｒｏｘｙ計算機（６）又はサーバ計算機（２）に対して送信する（送信ステップ）。

次に、図１８に従ってサーバ計算機（２）の動作例を説明する。まず、ステップＳ１８０１において、サーバ計算機（２）の通信機器（１０３）がＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージを受信する（受信ステップ）。次に、ステップＳ１８０２において、サーバ側のＯＲＢ（２０２）がＩｎｉｔｉａｌ＿ＲｅｑｕｅｓｔメッセージのＱｏＳ−Ｐｏｌｉｃｙ情報に示された要求通信品質を実現するための通信資源（具体的には、通信ポート）を確保（予約）する（通信資源確保ステップ）。次に、ステップＳ１８０３において、サーバ側のＯＲＢ（２０２）がＱｏＳ−Ｐｏｌｉｃｙに対応した計算機資源であるプロセスを確保する。次に、ステップＳ１８０４において、サーバ側のＯＲＢ（２０２）がサーバ（２０１）を起動するためのオブジェクト識別子を作成し、更に、ステップＳ１８０５において、このオブジェクト識別子に該当するＳｅｒｖｅｒ（２０１）を起動する。これにより、ＩＤＬ Ｃａｌｌ呼出の準備が整ったので、ステップＳ１８０６において、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージを生成し、サーバ計算機（２）の通信機器（１０３）よりＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージをクライアント計算機（１）に対して送信する。

次に、図２〜図９を参照しながら、Ｃｌｉｅｎｔ計算機（１）がＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（ｍ１）を発行して、Ｓｅｒｖｅｒ計算機（２）にてサーバ（２０１）が起動され、ここで生成されたオブジェクト識別子がＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージ（ｍ２）にてクライアント（１０１）へ返されるまでの処理の流れを詳述する。

ここで、図２は、Ｃｌｉｅｎｔ計算機（１）の構成例を示しており、この図２の構成における処理の流れを図５に示す。また、図３は、Ｓｅｒｖｅｒ計算機（２）の構成例を示しており、この図３の構成における処理の流れを図６を示す。また、図４は、Ｐｒｏｘｙ計算機（６ａ）の構成例を示しており、この図４の構成における処理の流れを図７に示す。また、Ｃｌｉｅｎｔ計算機（１）、Ｓｅｒｖｅｒ計算機（２）、Ｐｒｏｘｙ計算機（６ａ）のそれぞれに搭載されるＱｏＳ−Ｐｒｏｘｙ処理部（１０２８）におけるＱｏＳ−Ｐｏｌｉｃｙ、Ｐｒｏｘｙによる予約される通信ポートの管理方法を図８を用いて説明し、Ｓｅｒｖｅｒ計算機（２）に搭載されるオブジェクト識別子管理部（２０２６）が生成するオブジェクト識別子の構造を図９を用いて説明する。

まず、Ｃｌｉｅｎｔ計算機の動作例を説明する。図５ではＣｌｉｅｎｔ計算機（１）上のＣｌｉｅｎｔ（１０１）がＩＤＬ Ｃａｌｌを発行する処理の流れを示している。Ｃｌｉｅｎｔ（１０１）はＩＤＬに規定された関数呼び出しを行うアプリケーションロジックであるＣｌｉｅｎｔ Ｌｏｇｉｃ（１０１１）から、呼び出される関数の情報をＯＲＢ（１０２）へ渡すためにＳｔｕｂ（１０１２）を利用する点は従来例と同様である。しかし、ＩＤＬ Ｃａｌｌに規定されている関数呼び出しの前に、Ｃｌｉｅｎｔ Ｌｏｇｉｃ（１０１１）がＯＲＢ（１０２）に品質情報であるＱｏＳ−Ｐｏｌｉｃｙを渡す動作が異なる。Ｃｌｉｅｎｔ Ｌｏｇｉｃ（１０１１）はｍ１０１にてＳｔｕｂ（１０１２）へＩＤＬ Ｃａｌｌ情報とともにＱｏＳ−Ｐｏｌｉｃｙ情報を伝え、さらにＳｔｕｂ（１０１２）はｍ１０２にてＯＲＢ（１０２）のＩＤＬ処理部（１０２１）へ、これらの情報を伝える。

ＩＤＬ Ｃａｌｌ情報とＱｏＳ−Ｐｏｌｉｃｙ情報を取得したＯＲＢ（１０２）では、ＩＤＬ処理部（１０２１）がＩＤＬ Ｃａｌｌによる関数呼び出しのための準備の情報をＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（ｍ１）の形態へ変換して送信オブジェクトメッセージ通信管理部（１０２２）を介してＳｅｒｖｅｒ計算機（２）へ送信する。ただし新たに、この間にＱｏＳ−Ｐｏｌｉｃｙが指定する品質に対応したＣｌｉｅｎｔ計算機（１）の通信機器（１０３）の通信ポートの予約処理を行う。

通信ポートの予約処理は、ＩＤＬ処理部（１０２３）がＱｏＳ−Ｐｏｌｉｃｙをｍ１０３によりＱｏＳ−Ｐｏｌｉｃｙ解釈部（１０２５）へ引き渡す事により開始される。ＱｏＳ−Ｐｏｌｉｃｙ解釈部（１０２５）は、ＱｏＳ−Ｐｏｌｉｃｙ情報を分析し、必要となる品質を持つ通信ポートを確保するために、ｍ１０４にてＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）に指示を行う。この指示を受けたＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）は、通信機器（１０３）を管理するＮｅｔｗｏｒｋ ＱｏＳ管理部（１０２７）へｍ１０５により期待する品質を持つ通信ポートの予約を指示する。この要求を受けたＮｅｔｗｏｒｋ ＱｏＳ管理部（１０２７）では、通信機器（１０３）の該当する通信ポートを確保し、この通信ポート識別子をｍ１０６を用いてＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）へ返す。ＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）は、通信ポート識別子の情報を保持するために、通信ポート識別子をｍ１０７によりＱｏＳ−Ｐｒｏｘｙ処理部（１０２８）へ通知する。ＱｏＳ−Ｐｒｏｘｙ処理部（１０２８）では、この情報を管理したテーブルの識別子であるＰｒｏｘｙ識別子と通信ポート識別子を、ｍ１０８にてＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）へ返す。この情報はｍ１０９にてＱｏＳ−Ｐｏｌｉｃｙ解釈部（１０２５）、さらにｍ１１０によりＩＤＬ処理部（１０２１）へ返される。この結果、通信ポート予約を要求したＩＤＬ処理部（１０２１）は、予約を完了する。ＩＤＬ処理部（１０２１）は、Ｐｒｏｘｙ識別子とＱｏＳ−Ｐｏｌｉｃｙを付加したＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（要求通信品質通知）（ｍ１）を作成し、ｍ１１１にて送信オブジェクトメッセージ通信管理部（１０２２）へＳｅｒｖｅｒ計算機（２）への送信を依頼する。この時に通信ポート識別子も通知する事により、この依頼を受けた送信オブジェクトメッセージ通信管理部（１０２２）は、ｍ１１２にてＮｅｔｏｒｋ ＱｏＳ管理部（１０２７）へ通信ポート識別子に該当する通信ポートを利用した通信を、ｍ１１３を用いて通信ドライバ部（１０２４）へ指示する。この結果、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（ｍ１）は、Ｃｌｉｅｎｔ計算機（２）上の通信機器（１０３）をＱｏＳ−Ｐｏｌｃｙにて要求した品質による通信が実現される。

なお、クライアント計算機（１）において、クライアント（１０１）は要求通信品質指定部の例に相当し、クライアント側のＯＲＢ（１０２）は通信資源確保部及び要求通信品質通知生成部の例に相当し、通信機器１０３は通信部の例に相当する。

次にＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（ｍ１）による要求に対応して、Ｓｅｒｖｅｒ計算機（３）からＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージ（ｍ２）が返された時のクライアント（１０１）の処理を説明する。
通信機器（１０３）を介してＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージ（ｍ２）を受信した通信ドライバ部（１０２４）は、この情報をｍ２０１を用いて受信オブジェクトメッセージ通信管理部（１０２３）へ通知する。受信オブジェクトメッセージ通信管理部（１０２３）は、この情報をｍ２０３を用いてＩＤＬ処理部（１０２３）へ通知する。ＩＤＬ処理部（１０２３）では、この情報をｍ２０４を用いてＣｌｉｅｎｔ（１０１）のＳｔｕｂ（１０１２）へ伝える。Ｓｔｕｂ（１０１２）はＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージ（ｍ２）の形式をＣｌｉｎｅｔ Ｌｏｇｉｃ（１０１１）がＩＤＬ Ｃａｌｌの応答の形式に変換し、Ｃｌｉｅｎｔ Ｌｏｇｉｃ（１０１１）へ返す。ここではＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージ（ｍ２）に記録されているオブジェクト識別子を返すとともに、Ｓｅｒｖｅｒ（２０１）が正常に起動され、ＩＤＬ Ｃａｌｌを受け付ける準備ができた事を伝える。

以上の動作により、Ｃｌｉｅｎｔ（１０１）はオブジェクト識別子を用いて、ＱｏＳ−Ｐｏｌｉｃｙを用いて要求した品質でＩＤＬ Ｃａｌｌを行う事ができる。

次に、Ｓｅｒｖｅｒ計算機の動作例を説明する。図６ではＳｅｒｖｅｒ計算機（２）上のＳｅｒｖｅｒ（２０１）において、ＩＤＬ Ｃａｌｌにより要求された関数が呼び出される処理の流れを示している。Ｓｅｒｖｅｒ（２０１）はＳｅｒｖｅｒ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（２０１１）に呼び出される関数が存在し、ＯＲＢ（２０２）からの要求がＳｋｅｌｅｔｏｎ（２０１２）を介して通知される操作は従来例と同様である。ただし、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（ｍ１）によるＩＤＬ Ｃａｌｌ呼び出し準備状況を確認する前に、このメッセージに搭載されたＱｏＳ−Ｐｏｌｉｃｙに基づきＳｅｒｖｅｒ計算機（２）の計算機資源の確保と、この情報とＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（ｍ１）により通知されたＣｌｉｅｎｔ計算機（１）からネットワーク（３）上をルーティングされるＰｒｏｘｙ計算機の通信ポート情報であるＰｒｏｘｙリストを用いてオブジェクト識別子を生成する処理が異なる。この処理は以下の３つの処理により構成される。
１） ＱｏＳ−Ｐｏｌｉｃｙに対応したＳｅｒｖｅｒ計算機（２）の通信資源確保
２） ＱｏＳ−Ｐｏｌｉｃｙに対応したＳｅｒｖｅｒ計算機（２）の計算機資源確保
３） オブジェクト識別子の生成とサーバの起動
１）〜３）の動作を以下に説明する。

まず、１） ＱｏＳ−Ｐｏｌｉｃｙに対応したＳｅｒｖｅｒ計算機（２）の通信資源確保について説明する。Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（ｍ１）を受信した通信ドライバ（１０２４）は、ｍ１２１を用いて、この情報を受信オブジェクトメッセージ通信管理部（１０２３）へ伝える。受信オブジェクトメッセージ通信管理部（１０２３）は、この情報をｍ１２２によりオブジェクト管理部（２０２４）へ伝える。オブジェクト管理部は、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（ｍ１）に記録されているＱｏＳ−ＰｏｌｉｃｙとＰｒｏｘｙリスト情報を抽出し、この情報をｍ１２３を用いてＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）へ伝える。ＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）は、ＱｏＳ−Ｐｏｌｃｙに該当する通信ポートを予約するために、ｍ１２４を用いてＮｅｔｏｒｋ ＱｏＳ管理部（１０２７）へ通信ポートの予約を指示する。Ｎｅｔｏｒｋ ＱｏＳ管理部（１０２７）は、要求に対応する通信ポートを確保し、これに対応する通信ポート識別子をｍ１２５を用いて、ＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）へ返す。ＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）は、確保した通信ポート識別子を保持するために、この情報をｍ１２６を用いてＱｏＳ−Ｐｒｏｘｙ処理部（１０２８）へ伝える。ＱｏＳ−Ｐｒｏｘｙ処理部（１０２８）は、通信ポート識別子を格納し、これに対応するＰｒｏｘｙ識別子をｍ１２７を用いて、ＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）へ返す。ＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）は、ｍ１２８を用いて確保したＰｒｏｘｙ識別子をオブジェクト管理部（２０２４）へ返す。この処理によりオブジェクト管理部（２０２４）によるＳｅｒｖｅｒ計算機（２）におけるＱｏＳ−Ｐｏｌｉｃｙに対応した通信資源の確保が終了する。

次に、２） ＱｏＳ−Ｐｏｌｉｃｙに対応したＳｅｒｖｅｒ計算機（２）の計算機資源確保について説明する。オブジェクト管理部（２０２４）は、ＱｏＳ−Ｐｏｌｉｃｙ情報をｍ１２９を用いて、並列処理制御部（２０２５）へ計算機資源の確保を要求する。この要求を受けた並列処理制御部（２０２５）は、ＱｏＳ−Ｐｏｌｉｃｙに対応した計算機資源であるプロセスを確保し、この識別子をｍ１３０を用いてオブジェクト管理部（２０２４）へ返す。この処理によりオブジェクト管理部（２０２４）によるＳｅｒｖｅｒ計算機（２）におけるＱｏＳ−Ｐｏｌｉｃｙに対応した計算機資源の確保が終了する。

次に、３） オブジェクト識別子の生成とサーバの起動について説明する。オブジェクト管理部（２０２４）は、取得したＰｒｏｘｙ識別子、通信ポート識別子、プロセスの識別子を用いてオブジェクト識別子の生成を、ｍ１３１によりオブジェクト識別子管理部（１０２６）へ要求する。オブジェクト識別子管理部（１０２６）は、これら３種類の情報を用いて、図８に示す構成にてオブジェクト識別子を生成し、この情報をｍ１３２を用いてオブジェクト管理部（２０２４）ヘ返す。オブジェクト管理部では、このオブジェクト識別子に該当するＳｅｒｖｅｒ（２０１）を起動する（ｍ０１）。以上の処理により、ＩＤＬ Ｃａｌｌ対象となるＳｅｒｖｅｒ（２０１）の起動を完了し、このオブジェクトを分散環境上で一意に識別できるようになる。

以降は従来例と同様であり、オブジェクト管理部（２０２４）は、ｍ１３３を用いてＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（ｍ１）の情報をＳｋｅｌｅｔｏｎ（２０１２）へ伝える。Ｓｋｅｌｅｔｏｎ（２０１２）は、このメッセージ形式の情報を関数呼び出しの形式に変換し、ｍ１３４を用いてＯｂｊｅｃｔ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（２０１１）へ伝える。この処理によりＩＤＬ Ｃａｌｌに対応したＳｅｒｖｅｒ（２０１）の準備が完了する。この完了情報は、ｍ２２１にてＳｋｅｌｅｔｏｎ（２０１２）からＯＲＢ（２０２）のＩＤＬ処理部（１０２１）へ伝えられる。さらにＩＤＬ処理部（１０２１）は、ｍ２２２を用いて、オブジェクト管理部（２０２４）へ完了情報を伝える。オブジェクト管理部（２０２４）は、Ｓｅｒｖｅｒ（２０１）によるＩＤＬ Ｃａｌｌ呼び出しの準備が整った事と、オブジェクト識別子をＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージ（ｍ２）に記録して、ｍ２２３により送信オブジェクトメッセージ通信管理部（１０２２）に送信を指示する。送信オブジェクトメッセージ通信管理部（１０２２）は、ｍ２２４によりＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージ送信を通信ドライバ（１０２４）に指示する事により、Ｓｅｒｖｅｒ計算機（２）の処理は終了する。なお、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージは、クライアント計算機（１）から要求された通信品質を実現するためにサーバ計算機（２）が確保した通信資源（通信ポート）を通知することを目的の一つとする情報であり、確保通信資源通知に相当する。

また、サーバ計算機（２）において、サーバ側のＯＲＢ（２０２）は、通信資源確保部及び確保通信資源通知生成部の例に相当し、通信機器（１０３）は通信部の例に相当する。
次に、Ｐｒｏｘｙ計算機の動作例を説明する。図７ではＰｒｏｘｙ計算機（６ａ）上でＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（ｍ１）とＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージ（ｍ２）を転送する動作を示している。従来例とは異なり本発明の動作では、Ｐｒｏｘｙ計算機（６ａ）に搭載されている通信機器（１０３）に対して、Ｃｌｉｅｎｔ（１０１）のＣｌｉｅｎｔ Ｌｏｇｉｃ（１０１１）が指定したＱｏＳ−Ｐｏｌｉｃｙに基づく通信資源の予約が行われる。

Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（ｍ１）を受信した通信ドライバ部（１０２４）は、この情報をｍ１４１により受信オブジェクトメッセージ通信管理部（１０２２）に通知する。受信オブジェクトメッセージ通信管理部（１０２２）は、この情報をｍ１４２によりＱｏＳ−Ｐｏｌｉｃ伝達管理部（６０２１）へ通知する。ＱｏＳ−Ｐｏｌｉｃｙ伝達管理部では、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（ｍ１）に記録されているＱｏＳ−Ｐｏｌｉｃｙ情報を抽出し、この情報に基づく通信資源を確保するために、ｍ１４３を用いてＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）へＱｏＳ−Ｐｏｌｃｙを伝える。ＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）は、ｍ１０４４にてＮｅｔｗｏｒｋ ＱｏＳ管理部（１０２７）へＱｏＳ−Ｐｏｌｉｃｙを伝える事により、これに対応した通信資源の確保を指示する。Ｎｅｔｗｏｒｋ ＱｏＳ管理部（１０２７）は、通信ドライバ部（１０２４）に対して該当する通信ポートの確保を指示し、予約された通信ポートを示す通信ポート識別子を得る。ＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）は、取得した通信ポート識別子を保持するために、ｍ１４６にてＱｏＳ−Ｐｒｏｘｙ処理部（１０２８）へ通信ポート識別子を通知する。ＱｏＳ−Ｐｒｏｘｙ処理部（１０２８）は、通信ポート識別子に対応したＰｒｏｘｙ識別子を生成し、この情報をｍ１４７にてＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）へ通知する。ＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）は、取得したＰｒｏｘｙ識別子をｍ１４８にてＱｏＳ−Ｐｏｌｉｃｙ伝達管理部（６０２１）へ通知する。ＱｏＳ−Ｐｏｌｉｃｙ伝達管理部（６０２１）は、転送するＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（ｍ１）のＰｒｏｘｙリストに取得したＰｒｏｘｙ識別子を追加し、ｍ１４９により送信オブジェクトメッセージ通信管理部（１０２７）へ送信を指示する。送信オブジェクトメッセージ通信管理部（１０２７）は、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージ（ｍ１）の送信をｍ１５０にて通信ドライバ部（１０２４）へ指示する事により送信が行われる。

なお、Ｐｒｏｘｙ計算機（６）において、Ｐｒｏｘｙ Ｂｒｏｋｅｒは、通信資源確保部及び情報付加部の例に相当し、通信機器（１０３）は通信部に相当する。

次に、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージ（ｍ２）の転送処理を説明する。Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージ（ｍ２）を受信した通信ドライバ部（１０２４）は、ｍ２４１にて受信オブジェクトメッセージ通信管理部（１０２３）へ、この情報を通知する。受信オブジェクトメッセージ通信管理部は、ｍ２４２にてＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージ（ｍ２）をＱｏＳ−Ｐｏｌｉｃｙ伝達管理部（６０２１）へ通知する。ＱｏＳ−Ｐｏｌｉｃｙ伝達管理部（６０２１）は、ｍ２４３にてＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージ（ｍ２）の送信を送信オブジェクトメッセージ通信管理部（１０２２）に指示する。この指示を受けた送信オブジェクトメッセージ通信管理部（１０２２）は、ｍ２４４にて通信ドライバ部（１０２４）へ指示を行う事により送信が行われる。
次に、ＱｏＳ−Ｐｒｏｘｙ処理部（１０２８）におけるＱｏＳ−Ｐｏｌｉｃｙ管理方法を説明する。図８を用いてＱｏＳ−Ｐｒｏｘｙ管理テーブルの役割と構成を説明する。ＱｏＳ−Ｐｒｏｘｙはクライアント計算機（１）、サーバ計算機（２）、Ｐｒｏｘｙ計算機（６ａ）が相互接続するために経由する各計算機の通信機器（１０３）のポート予約を行う単位である。１つの計算機における通信機器（１０３）において、クライアントロジック（１０１１）が指定するＱｏＳ−Ｐｒｏｘｙに応じて入側ポートをｉｎポート識別子（ｔ２２）とし、出側ポートをｏｕｔポート識別子（ｔ２３）として予約し、実際のＲｅｑｕｅｓｔメッセージ（ｍ３）とＲｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄメッセージ（ｍ４）、及びＲｅｐｌｙメッセージ（ｍ５）が通信する場合に指定する事により品質を保証できる。ｉｎポート識別子（ｔ２２）とｏｕｔポート識別子（ｔ２３）の組み合わせをＰｒｏｘｙ識別子（ｔ２１）として管理し、この分析をＱｏＳ−Ｐｒｏｘｙ処理部（１０２８）が行う事により、通信機器（１０３）が実現するプロトコル種別などの違いをクライアントロジック（１０１１）やサーバインプリメンテーション（２０１１）から隠蔽する事ができる。この結果、クライアントロジック（１０１１）とサーバインプリメンテーション（２０１１）は通信種別に依存しない可搬性を実現できる。
次に、図９を用いてオブジェクト識別子の構造を説明する。オブジェクト識別子は従来のプロセス識別子（ｔ０２）とネットワーク識別子（ｔ０３）に対して、Ｐｒｏｘｙリスト（ｔ３１）を追加した構成である。Ｐｒｏｘｙリスト（ｔ３１）は、図８にて説明したＰｒｏｘｙ識別子（ｔ２１）のリストであり、クライアント計算機（１）からサーバ計算機（２）までの経路として存在するＰｒｏｘｙ計算機（６ａ）毎の使用ポートを指定する。この結果、クライアントロジック（１０１１）からサーバインプリメンテーション（２０１１）までの通信路の品質を指定した相互接続が可能となる。

本実施の形態に係る分散オブジェクトシステムは以上に説明したように、クライアントロジックからサーバインプリメンテーションへのＩＤＬ呼び出しの実現において、クライアントロジックが指定した要求品質に基づいてクライアント計算機、サーバ計算機、Ｐｒｏｘｙ計算機の資源を確保したオブジェクト識別子を構成するため、要求品質を満たすＩＤＬ呼び出しを行う品質制御方式を実現できるという効果がある。

実施の形態２．
以上の実施の形態１では、クライアント計算機からサーバ計算機へルーティングする順番に従って、これらクライアント計算機とサーバ計算機と、これらの間に存在するＰｒｏｘｙ計算機の資源を確保するようにした品質制御方式を説明したが、次に要求される要求ＱｏＳ値を実現するために、各計算機の資源を最適に配置するＱｏＳ調整機能を実現する場合の実施の形態を示す。

実施の形態１では、クライアント計算機とサーバ計算機の間で要求ＱｏＳ値を満足する通信路を確保するために、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージを用いて、「クライアント計算機→Ｐｒｏｘｙ計算機Ａ→Ｐｒｏｘｙ計算機Ｂ→・・・・・・→Ｐｒｏｘｙ計算機Ｎ→サーバ計算機」の順番で品質を確保していた。しかし、この方式だと要求ＱｏＳ値を満足するための最適な資源の配置が困難である。このため、本実施の形態では、要求ＱｏＳ値を配分する集中管理の機能を追加する。

図１０は、このような場合の品質制御型分散オブジェクトシステム構成を示す。この構成は図１に示す実施の形態１による構成に対して、ＱｏＳ調整機能（７）を追加した構成である。ＱｏＳ調整機能（７）は、クライアント計算機（１）、サーバ計算機（２）、Ｐｒｏｘｙ計算機（６ａ、 ６ｂ、 ６ｃ、・・・）に搭載されるＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）が確保する資源間の調整を集中して管理するために、図１１に示す構成を持つ。ＱｏＳ調整部（７０１）はＱｏＳ管理テーブル（７０２）に格納される要求ＱｏＳ値と各ノードが確保できるＱｏＳ値の関係を管理し、必要に応じて各計算機のＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）に資源の再確保を要求する機能である。Ｑｏｓ調整機能（７）を実現する計算機は、通信資源調整装置の例に相当する。図１０では、Ｑｏｓ調整機能（７）は、クライアント計算機、サーバ計算機、Ｐｒｏｘｙ計算機以外の計算機上で実現されることになっているが、クライアント計算機、サーバ計算機、Ｐｒｏｘｙ計算機のいずれかで実現されてもよい。

図１２はＱｏＳ管理テーブル（７０２）にて実現されるＱｏＳ調整機能管理テーブルの構成を示している。ここでＱｏＳ−Ｐｏｌｉｃｙ識別子（Ｔ４１）は、１つのＩＤＬ通信のリンクを区別する識別子である。ノードＱｏＳ値（Ｔ４２）は、クライアント計算機（１）、サーバ計算機（２）、Ｐｒｏｘｙ計算機（６ａ、 ６ｂ、 ６ｃ、・・）にて確保される品質の値である。要求ＱｏＳ値（Ｔ４３）は、クライアントロジック（１０１１）が要求するＱｏＳ値である。ＱｏＳ調整は以下の手順（ＱｏＳ要求登録処理、ＱｏＳ処理部（１０２６）からの確保資源の通知処理、ＱｏＳ処理部（１０２６）における確保資源の再調整処理）により実現する。図１２では、要求ＱｏＳ値は処理時間を想定している。このため、例えば最大１０００ｍｓｅｃの遅延を許容値として要求した場合に、各計算機は必要となる処理時間を確保する。これらの計算機の処理時間の合計が１０００ｍｓｅｃを超えると、要求ＱｏＳ値を満足できない事になる。このため、ＱｏＳ調整機能（７）は、合計値が１０００ｍｓｅｃになる資源を確保するために資源の調整を行う。

まず、ＱｏＳ要求登録処理について説明する。クライアントロジック（１０１１）が要求する要求ＱｏＳ値は、ＩＤＬ変換部（１０２１）がＩＤＬ呼び出しを受けた時点で、送信オブジェクトメッセージ通信管理部（１０２２）を介してＱｏＳ調整機能（７）へ通知する。この通知はＱｏＳ調整機能（７）の通信ドライバ部（１０２４）を介してＱｏＳ調整部（７０１）が受け取り、ＱｏＳ管理テーブル（７０２）に新たな要求ＱｏＳ−Ｐｏｌｉｃｙ識別子（Ｔ４１）を生成して、この要求ＱｏＳ値（Ｔ４３）に格納する。この結果として要求ＱｏＳ−Ｐｏｌｉｃｙ識別子がＩＤＬ変換部（１０２１）に返される。以降では、この識別子がＩＤＬ 呼び出しを実現するメッセージであるＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔにて伝えられる。
次に、ＱｏＳ処理部（１０２６）からの確保資源の通知処理について説明する。クライアント計算機（１）、サーバ計算機（２）、Ｐｒｏｘｙ計算機（６ａ、 ６ｂ、 ６ｃ、・・・）の各ＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）は、それぞれの通信資源を確保した時点で、要求ＱｏＳ−Ｐｏｌｉｃｙ識別子と確保したＱｏＳ値（確保した通信資源により実現されるＱｏｓ値（通信品質））をＱｏＳ調整機能（７）へ通知する。これらの情報を受け取ったＱｏＳ調整部（７０１）は、ＱｏＳ管理テーブル（７０２）の該当する要求ＱｏＳ−Ｐｏｌｉｃｙ識別子（Ｔ４１）の該当するノードのＱｏＳ値（Ｔ４２）にＱｏＳ値を設定する。

次に、ＱｏＳ処理部（１０２６）における確保資源の再調整処理について説明する。クライアント計算機（１）、サーバ計算機（２）、Ｐｒｏｘｙ計算機（６ａ、 ６ｂ、 ６ｃ、・・・）の各ＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）が一度確保された資源の再構成を判断した場合は、上記のＱｏＳ処理部（１０２６）からの確保資源の通知処理にて説明した確保資源の通知処理と同様の手順にて、ＱｏＳ調整機能（７）のＱｏＳ調整部（７０１）に資源の再構成の要求を行う。この要求を受けたＱｏＳ調整部は、ＱｏＳ管理テーブル内の該当する要求ＱｏＳ−Ｐｏｌｉｃｙ識別子の要求ＱｏＳ値（Ｔ４３）に対する各ノードのＱｏＳ値（Ｔ４２）を比較して、適切な変更ノードを判断し、そのノードのＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）に指定するＱｏＳ値を実現する資源の再確保を要求する。再確保が正常に終了した場合には、ＱｏＳ調整部（７０１）は、新たなＱｏＳ値をＱｏＳ管理テーブル（７０２）の該当するノードＱｏＳ値を書き換える。ここで、再確保が必要な場合とは、ＱｏＳ調整機能（７）が要求ＱｏＳ値を実現するために、例えば各計算機に均一に資源を配置するようにスケジューリングしていた場合に、指定した資源の確保を実現できない計算機があった場合を想定している。この場合、一度資源を確保した計算機に対して、再度の資源確保を要求する。この結果、他の実施の形態では資源確保できない場合はＣｌｉｅｎｔ Ｌｏｇｉｃにエラーを返すが、この方式だと再度の確保を行う事ができる。つまり、ＱｏＳ調整機能（７）は、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージが順次、資源を確保してゆく過程で、例えばＰｒｏｘｙ計算機（６ｂ）に期待するＱｏＳ値が１００ｍｓｅｃであるのに対して１５０ｍｓｅｃしか確保できなかった場合は、他のＰｒｏｘｙ計算機（６ａ）や、次のＰｒｏｘｙ計算機（６ｃ）に不足分の５０ｍｓｅｃ分を加味して再確保を要求するというような、相互に資源確保の補完を実現することができる。サーバ識別子は全てＩＤの組み合わせで構成しているため、そのＩＤに対応する資源が１００なのか、５０なのかの違いは、クライアントとサーバからは透過であるため、この資源の再確保の手続きは、Ｃｌｉｅｎｔ ＬｏｇｉｃとＳｅｒｖｅｒ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎの処理には影響を与える事なく実現できる。

なお、オブジェクト識別子は図９に示すように具体的な資源情報ではなく、各ノードの資源をＰｒｏｘｙリストに示す識別子にて管理しているため、確保されたＱｏＳ値が変更されても、クライアントロジック（１０１１）からサーバインプリメンテーション（２０１１）に対するオブジェクト識別子を利用したＩＤＬ呼び出しには影響を与えない。

本実施の形態に係る分散オブジェクトシステムでは、要求品質に対して確保されたクライアント計算機、サーバ計算機、Ｐｒｏｘｙ計算機の資源情報を管理する品質調整機能をネットワーク上に持つ構成とするため、一部の資源の再構築が必要となった場合でも他の適切な計算機に対して資源の再確保を要求する最適な資源の再配置を行う品質制御方式を実現できるという効果がある。

実施の形態３．
以上の実施の形態１では、クライアント計算機、サーバ計算機、Ｐｒｏｘｙ計算機にて確保される資源に対して、要求されるＩＤＬ呼び出しの順番に資源を利用する品質制御方式を説明したが、次に各資源の利用を予め設定された優先度に基づいてスケジューリングする実施の形態を示す。

図１３は本実施の形態におけるＱｏＳ−Ｐｏｌｉｃｙ管理テーブル構成を示す。これは図８に示す実施の形態１におけるＱｏＳ−Ｐｏｌｉｃｙ管理テーブル構成に対して、優先度（Ｔ２４）を追加した構成である。この優先度（Ｔ２４）は、資源を確保する時に設定する。

クライアント計算機（１）、サーバ計算機（２）、Ｐｒｏｘｙ計算機（６ａ、 ６ｂ、 ６ｃ、・・）において、ＩＤＬ呼び出しを多重に実行された事をＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）が検出した場合、この優先度に従って資源の利用を実行する。

本実施の形態では、複数のクライアント／サーバ間の接続要求が同時に行われ、例えばＰｒｏｘｙ計算機（６ａ）に対する資源の確保が同時に要求された場合の処理を想定している。Ｐｒｏｘｙ計算機（６ａ）が確保できる資源が１０００である場合、同時に複数の１０００の要求が行われた場合は、最も高い優先度に対して資源を確保して、他の要求に対してはエラーを返す。これにより重要なクライアント／サーバ間接続に対して優先的に資源を割り当てる事ができる。

本実施の形態に係る分散オブジェクトシステムでは、クライアントロジックから要求品質と合わせて優先度を指定する機能と、クライアント計算機、サーバ計算機、Ｐｒｏｘｙ計算機のＱｏＳ−Ｐｏｌｉｃｙ処理部に優先度に基づいてＩＤＬ呼び出し処理のスケジューリングを実施する構成とするため、複数のＩＤＬ呼び出しが同時に実施された場合の資源の利用を優先度に基づいて実施する品質制御方式を実現できるという効果がある。

実施の形態４．
以上の実施の形態１では、クライアントロジックが指定するＱｏＳ値からＩＤＬ呼び出しに利用する品質を計算する品質制御方式を説明したが、次にサーバインプリメンテーションが指定するＱｏＳ値での動作を保証する実施の形態を示す。

図１４はＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ受信によりサーバ計算機がオブジェクト識別子を生成し、クライアント計算機に応答を返す過程で、ＱｏＳ妥当性分析を実施した結果からＩＤＬ接続を拒絶するＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｒｅｊｅｃｔを返す手順を説明している。

この構成は図６にて説明した実施の形態１によるＳｅｒｖｅｒ計算機の動作に対して、オブジェクト管理部（２０２４）にＱｏＳ妥当性分析の処理を追加し、この処理以降にＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｒｅｊｅｃｔを反す手順を加えたものである。ＱｏＳ妥当性分析はサーバインプリメンテーションが指定するＱｏＳ値に対して、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔによりクライアントロジック（１０１１）が指定するＰｒｏｘｙリストからクライアント計算機（１）とＰｒｏｘｙ計算機（６ａ、６ｂ、６ｃ、・・）にて確保された資源、及び自身のＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）、並列処理制御部（２０２５）の資源から計算されるＩＤＬ呼び出しの品質が満足できるものであるかどうかを判断する。この結果、満足する場合は図６にて説明したＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｓｕｃｃｅｅｄを返送する処理が実行される。満足しない場合には、ｍ３０１にて並列処理制御部（２０２５）へ計算機資源の解放を指示し、ｍ３０２にてＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）を介して、ｍ３０３がＮｅｔｗｏｒｋ ＱｏＳ管理部（１０２７）へ通信資源の解放を指示する。続けてオブジェクト管理部（２０２４）は、ｍ３０４にて送信オブジェクトメッセージ通信管理部（１０２２）に対してＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔ＿ｒｅｊｅｃｔの返送を指示し、さらにｍ３０５にて通信ドライバ部（１０２４）に対して実際の送信を命令する。

本実施の形態に係る分散オブジェクトシステムでは、サーバ計算機において予めサーバインプリメンテーションから優先度を指定する機能と、ＩＤＬ呼び出しの要求を受けた場合に、この呼び出しにて実現される品質がサーバにて指定された品質の条件を満足した場合に呼び出しを許可する構成とするため、サーバインプリメンテーションの品質に関する設計値を満足するＩＤＬ呼び出しを実施する品質制御方式を実現できるという効果がある。

実施の形態５．
以上の実施の形態１では、通信基盤が実現するルーティングの順番に、クライアント計算機からサーバ計算機までの間に介するＰｒｏｘｙ計算機の資源を確保する品質を計算する品質制御方式を説明したが、次にルーティングに関係なく公募形式によりルーティングを決定する実施の形態を示す。

図１５はＰｒｏｘｙ計算機においてＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔを中継する場合に、次にメッセージを伝達するＰｒｏｘｙ計算機を決定するために、公募を行う手順を示している。また図１６は、この公募に対応して、応募する側のＰｒｏｘｙ計算機の動作を示す。

図１５を用いてＰｒｏｘｙ計算機の公募処理を説明する。この処理は図７に示すＰｒｏｘｙ計算機に示すＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔの中継処理において、ｍ１４８によりＱｏＳ−Ｐｏｌｉｃｙ伝達管理部（６０２１）が自身となるＰｒｏｘｙ計算機の通信資源の確保を完了して、次にＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔを中継するＰｒｏｘｙ計算機を決定するためにＱｏＳ公募処理を実行する構成である。ここではｍ５０１にて通信ドライバ部（１０２４）に必要とするＱｏＳ値を利用できるＰｒｏｘｙ計算機を公募するために、広報通信にて通知を行う。これに対して応募があった場合には通信ドライバ部（１０２４）を介してＱｏＳ−Ｐｏｌｉｃｙ伝達管理部（６０２１）に対して通知される。この情報を受けたＱｏＳ−Ｐｏｌｉｃｙ伝達管理部（６０２１）は、図７に示すｍ１４９以降の処理を継続する。ここではＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔの中継先を応募のあった中から決定したＰｒｏｘｙ計算機に対して行う。

図１６を用いてＰｒｏｘｙ計算機の応募処理を説明する。図１５を用いて説明したＰｒｏｘｙ計算機からの応募を通信ドライバ部（１０２４）が受信した場合、ｍ５０３にてＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）に通知する。この通知を解析して必要とするＱｏＳ値が確保可能かどうかをｍ５０４にてＮｅｔｗｏｒｋ ＱｏＳ管理部（１０２７）へ問い合わせる。この結果をｍ５０５にて受け取ったＱｏＳ−Ｐｏｌｉｃｙ処理部（１０２６）は確保可能と判断した場合には、ｍ５０６を用いて通信ドライバ部（１０２４）へ応募の通知を指示し、確保できないと判断すれば処理を終了する。

本実施の形態に係る分散オブジェクトシステムでは、ＩＤＬ呼び出しの実行時にクライアント計算機とＰｒｏｘｙ計算機が、次に呼び出しをルーティングする先の計算機を公募するために必要とする品質の要求をマルチキャストなどを利用して広報する機能と、要求品質を満足できる場合に応募する機能を持つ構成とするため、各計算機の通信基盤が持つルーティングテーブルに関係なく、その時に要求品質を満足できる計算機を選択してＩＤＬ呼び出しを実施する品質制御方式を実現できるという効果がある。

前述した各実施の形態で、クライアント計算機（１）、サーバ計算機（２）、Ｐｒｏｘｙ計算機（６）は、コンピュータであり、図示していないが、クライアント計算機（１）、サーバ計算機（２）、Ｐｒｏｘｙ計算機（６）は、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を備えている。

例えば、ＣＰＵは、バスを介して、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、通信ボード、表示装置、Ｋ／Ｂ（キーボード）、マウス、ＦＤＤ（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、ＣＤＤ（コンパクトディスクドライブ）、磁気ディスク装置、光ディスク装置、プリンタ装置、スキャナ装置等と接続されている。ＲＡＭは、揮発性メモリの一例である。ＲＯＭ、ＦＤＤ、ＣＤＤ、磁気ディスク装置、光ディスク装置は、不揮発性メモリの一例である。前述した各実施の形態のクライアント計算機（１）、サーバ計算機（２）、Ｐｒｏｘｙ計算機（６）が扱うデータや情報は、これら記憶装置に保存され、クライアント計算機（１）、サーバ計算機（２）、Ｐｒｏｘｙ計算機（６）の各部により、記録され読み出されるものである。

また、通信ボードは、例えば、ＬＡＮ、インターネット、或いはＩＳＤＮ等のＷＡＮ（ワイドエリアネットワーク）に接続されている。

磁気ディスク装置には、オペレーティングシステム（ＯＳ）、ウィンドウシステム、プログラム群、ファイル群（データベース）が記憶されている。プログラム群は、ＣＰＵ、ＯＳ、ウィンドウシステムにより実行される。

上記クライアント計算機（１）、サーバ計算機（２）、Ｐｒｏｘｙ計算機（６）の各部は、一部或いはすべてコンピュータで動作可能なプログラムにより構成しても構わない。或いは、ＲＯＭに記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェア或いは、ハードウェア或いは、ソフトウェアとハードウェアとファームウェアとの組み合わせで実施されても構わない。

上記プログラム群には、実施の形態の説明において「〜部」として説明した処理をＣＰＵに実行させるプログラムが記憶される。これらのプログラムは、例えば、Ｃ言語やＨＴＭＬやＳＧＭＬやＸＭＬなどのコンピュータ言語により作成される。

また、上記プログラムは、磁気ディスク装置、ＦＤ（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ）、光ディスク、ＣＤ（コンパクトディスク）、ＭＤ（ミニディスク）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のその他の記録媒体に記憶され、ＣＰＵにより読み出され実行される。

ここで、実施の形態１〜５で説明した分散オブジェクトシステムの特徴を以下にて示す。

実施の形態１に示した分散オブジェクトシステムは、ネットワーク上でクライアントが、予め規定されたＩＤＬ（Ｉｎｔｅｒｆａｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ）仕様を用いてメソッド呼び出しのインタフェースを公開しているサーバへ相互接続する事によりサービスを提供する分散オブジェクトシステムであって、
オブジェクト識別子にクライアントとサーバ間のネットワーク上のパスを特定するためのＰｒｏｘｙリストを備え、
クライアントとサーバのそれぞれが搭載される計算機間の接続パスを中継する通信機器上に、それぞれが実現する通信上の品質制御を管理するＰｒｏｘｙ Ｂｒｏｋｅｒを備え、
ＩＤＬ Ｃａｌｌを行うクライアントが動作する計算機上のＯＲＢ（Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ）に、ＱｏＳ−Ｐｏｌｉｃｙを指定するＱｏＳ−Ｐｏｌｉｃｙ解釈部機能と、このＱｏＳ−Ｐｏｌｉｃｙが指定する通信品質を持つ通信ポートを予約するネットワークＱｏＳ制御部と、ネットワークＱｏＳ制御部へ予約要求を行うＱｏＳ−Ｐｏｌｉｃｙ処理部と、予約された通信ポートとＱｏＳ−Ｐｏｌｉｃｙの関係を管理するＰｒｏｘｙを保持してＰｒｏｘｙ識別子を返すＱｏＳ−Ｐｒｏｘｙ処理部と、ＩＤＬ Ｃａｌｌによるサーバ呼び出しを行うＩｎｉｔｉａｌ＿ＲｅｑｕｅｓｔメッセージにＰｒｏｘｙの識別子とＱｏＳ−Ｐｏｌｉｃｙを付加して送信する送信オブジェクトメッセージ処理部を備え、
このＩｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージを中継する通信機器上に、ＱｏＳ−Ｐｏｌｉｃｙを分析するＱｏＳ−Ｐｏｌｉｃｙ処理部と、このＱｏＳ−Ｐｏｌｉｃｙが指定する通信品質を持つ通信ポートを予約するネットワークＱｏＳ制御部と、ネットワークＱｏＳ制御部へ予約要求を行うＱｏＳ−Ｐｏｌｉｃｙ処理部と、予約された通信ポートとＱｏＳ−Ｐｏｌｉｃｙの関係を管理するＰｒｏｘｙを保持してＰｒｏｘｙ識別子を返すＱｏＳ−Ｐｒｏｘｙ処理部と、中継するＩｎｉｔｉａｌ＿ＲｅｑｕｅｓｔメッセージにＰｒｏｘｙの識別子を付加して送信する送信オブジェクトメッセージ処理部を備え、
サーバが動作する計算機上のＯＲＢに、受信したＱｏＳ−Ｐｏｌｉｃｙが指定する通信品質を持つ通信ポートを予約するネットワークＱｏＳ処理部と、ネットワークＱｏＳ制御部へ予約要求を行うＱｏＳ−Ｐｏｌｉｃｙ処理部と、予約された通信ポートとＱｏＳ−Ｐｏｌｉｃｙの関係を管理するＰｒｏｘｙを保持してＰｒｏｘｙ識別子を返すＱｏＳ−Ｐｒｏｘｙ処理部と、ＱｏＳ−Ｐｏｌｉｃｙが指定する計算機品質に応じたプロセス資源を予約して対応するプロセス識別子を返す並列処理制御部と、Ｉｎｉｔｉａｌ＿Ｒｅｑｕｅｓｔメッセージに記録されていたＰｒｏｘｙリスト、予約した新たなＰｒｏｘｙ識別子、プロセス資源識別子からオブジェクト識別子を生成するオブジェクト識別子管理部と、生成されたオブジェクト識別子に対応したサーバを起動するオブジェクト管理部を備える事により、
クライアントが実行するＩＤＬ Ｃａｌｌを用いた相互接続に対して、クライアントが指定するＱｏＳ−Ｐｏｌｉｃｙに対応した通信品質を保証する事を特徴とする。

実施の形態２に示した分散オブジェクトシステムは、
ネットワーク上にＱｏＳ−Ｐｏｌｉｃｙを最適に配置する調整手段を実現し、クライアント計算機とサーバ計算機と、この間に存在する通信機器の各ＱｏＳ−Ｐｏｌｉｃｙ処理部との間でＱｏＳ交渉手段を持つ事を特徴とする。

実施の形態３に示した分散オブジェクトシステムは、
クライアント計算機のクライアントロジックにて指定するＱｏＳ−Ｐｏｌｉｃｙに優先度を設定する機能を実現し、クライアント計算機とサーバ計算機と、この間に存在する通信機器の各ＱｏＳ−Ｐｏｌｉｃｙ処理部に、優先度に基づいてＩＤＬ通信の処理の順番を変更する機能を備えた事を特徴とする。

実施の形態４に示した分散オブジェクトシステムは、
サーバインプリメンテーションがＱｏＳ−Ｐｏｌｉｃｙを指定する機能と、このＱｏＳ−Ｐｏｌｉｃｙとクライアントロジックが指定するＱｏＳ−Ｐｏｌｉｃｙを比較する手段を実現し、クライアントロジックが指定するＱｏＳ−Ｐｏｌｉｃｙがサーバインプリメンテーションが指定するＱｏＳ−Ｐｏｌｉｃｙの条件を満たさない場合は接続を拒絶する事を特徴とする。

実施の形態５に示した分散オブジェクトシステムは、
クライアント計算機とサーバ計算機と、この間に存在する通信機器の各ＱｏＳ−Ｐｏｌｉｃｙ処理部に必要とするＱｏＳ−Ｐｏｌｉｃｙを広報する機能と、この広報に対して公募する機能を実現する事により、ネットワークのルーティングに関係なくＩＤＬ通信路を確保する事を特徴とする。

実施の形態１による品質制御型分散オブジェクトシステムを示す構成図。 実施の形態１によるＣｌｉｅｎｔ計算機を示す構成図。 実施の形態１によるＳｅｒｖｅｒ計算機を示す構成図。 実施の形態１によるＰｒｏｘｙ計算機を示す構成図。 実施の形態１によるＣｌｉｅｎｔ計算機の動作を示す図。 実施の形態１によるＳｅｒｅｒ計算機の動作を示す図。 実施の形態１によるＰｒｏｘｙ計算機の動作を示す図。 実施の形態１によるオブジェクト識別子構成を示す図。 実施の形態１によるＱｏＳ−Ｐｒｏｘｙ管理テーブル構成を示す図。 実施の形態２による品質制御型分散オブジェクトシステム構成を示す図。 実施の形態２によるＱｏＳ調整機能構成を示す図。 実施の形態２によるＱｏＳ調整機能管理テーブルを示す図。 実施の形態３によるＱｏＳ−Ｐｏｌｉｃｙ管理テーブル構成を示す図。 実施の形態４によるＳｅｒｖｅｒ計算機の動作を示す図。 実施の形態５によるＰｒｏｘｙ計算機の動作（公募側）を示す図。 実施の形態５によるＰｒｏｘｙ計算の動作（応募側）を示す図。 実施の形態１によるＣｌｉｎｅｔ計算機の動作を示す図。 実施の形態１によるＳｅｒｖｅｒ計算機の動作を示す図。 実施の形態１によるＰｒｏｘｙ計算機の動作を示す図。 従来例による分散オブジェクトシステムを示す構成図。 従来例によるＣｌｉｅｎｔ計算機を示す構成図。 従来例によるＳｅｒｖｅｒ計算機を示す構成図。 クライアント／サーバ間オブジェクトメッセージ通信の例を示す図。 従来例によるオブジェクト識別子構成を示す図。

符号の説明

１ Ｃｌｉｅｎｔ計算機、２ Ｓｅｒｖｅｒ計算機、３ Ｎｅｔｗｏｒｋ、４ Ｎａｍｅ Ｓｅｒｖｅｒ、５ 通信路、６ Ｐｒｏｘｙ計算機、７ ＱｏＳ調整機能、１０１ Ｃｌｉｅｎｔ、１０２ Ｃｌｉｅｎｔ Ｓｉｄｅ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ、１０３ 通信機器、２０１ Ｓｅｒｖｅｒ、２０２ Ｓｅｒｖｅｒ Ｓｉｄｅ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ、１０１１ Ｃｌｉｅｎｔ Ｌｏｇｉｃ、１０１２ Ｓｔｕｂ、１０２１ ＩＤＬ処理部、１０２２ 送信オブジェクトメッセージ通信管理部、１０２３ 受信オブジェクトメッセージ通信管理部
１０２４ 通信ドライバ部、２０１１ Ｓｅｒｖｅｒ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ、２０１２ Ｓｋｅｌｅｔｏｎ、２０２４ オブジェクト管理部、２０２５ 並列処理制御部、２０２６ オブジェクト識別子管理部、６０１ Ｐｒｏｘｙ、６０２ Ｐｒｏｘｙ Ｂｒｏｋｅｒ、７０１ ＱｏＳ調整部、７０２ ＱｏＳ管理テーブル、１０２５ ＱｏＳ−Ｐｏｌｉｃｙ解釈部、１０２６ ＱｏＳ−Ｐｏｌｉｃｙ処理部、１０２７ ネットワークＱｏＳ管理部、１０２８ ＱｏＳ−Ｐｒｏｘｙ処理部、６０２１ ＱｏＳ−Ｐｏｌｉｃｙ伝達管理部。

Claims (7)

1. 通信資源を有するクライアント装置と、
   通信資源を有し、クライアント装置と通信を行ってクライアント装置に対してサービスを提供するサーバ装置と、
   通信資源を有し、クライアント装置とサーバ装置との間の通信を中継する１つ以上の中継装置と、
   通信資源調整装置とを有し、
   クライアント装置は、
   サーバ装置によるサービスの提供に先立ち、サービス提供時に要求される通信品質を要求通信品質として指定し、要求通信品質に基づいてサービス提供時の通信に用いられる自装置の通信資源を確保し、確保した通信資源により実現される通信品質を通信資源調整装置に通知し、
   サーバ装置は、
   サービスの提供に先立ち、クライアント装置より指定された要求通信品質に基づいてサービス提供時の通信に用いられる自装置の通信資源を確保し、確保した通信資源により実現される通信品質を通信資源調整装置に通知し、
   中継装置は、
   サーバ装置によるサービスの提供に先立ち、クライアント装置より指定された要求通信品質に基づいてサービス提供時の通信に用いられる自装置の通信資源を確保し、確保した通信資源により実現される通信品質を通信資源調整装置に通知し、
   通信資源調整装置は、
   クライアント装置、サーバ装置及び中継装置のそれぞれから、クライアント装置、サーバ装置及び中継装置のそれぞれにおいて確保された通信資源により実現される通信品質を通知され、クライアント装置、サーバ装置及び中継装置のそれぞれより通知された通信品質と要求通信品質とを比較し、所定の場合に、クライアント装置、サーバ装置及び中継装置の少なくともいずれかに対して、通信資源の再確保を要求することを特徴とする通信システム。
2. 通信資源調整装置は、
   いずれかの装置における通信品質が十分でないため要求通信品質を実現できない場合に、通信品質が十分でない装置以外の他のいずれかの装置に対して、不足する通信品質の補完のために通信資源の再確保を要求することを特徴とする請求項１に記載の通信システム。
3. クライアント装置、サーバ装置及び中継装置のそれぞれは、
   複数のサービス提供に対して通信資源の確保が必要になった際に、それぞれのサービス提供に対する優先度を判断し、優先度の高いサービス提供に対して優先して通信資源を確保することを特徴とする請求項１に記載の通信システム。
4. 通信資源を有し、サービスの提供に先立ち、サービス提供時に要求される通信品質を要求通信品質として指定し、要求通信品質に基づいてサービス提供時の通信に用いられる自装置の通信資源を確保するクライアント装置と、
   通信資源を有し、サービスの提供に先立ち、クライアント装置により指定された要求通信品質に基づいてサービス提供時の通信に用いられる自装置の通信資源を確保し、クライアント装置に対してサービスを提供するサーバ装置と、
   通信資源を有し、サーバ装置によるサービスの提供に先立ち、クライアント装置により指定された要求通信品質に基づいてサービス提供時の通信に用いられる自装置の通信資源を確保し、クライアント装置とサーバ装置との間の通信を中継する１つ以上の中継装置とを有する通信システムに含まれ、
   クライアント装置、サーバ装置及び中継装置のそれぞれから、クライアント装置、サーバ装置及び中継装置のそれぞれにおいて確保された通信資源により実現される通信品質を通知され、クライアント装置、サーバ装置及び中継装置のそれぞれより通知された通信品質と要求通信品質とを比較し、所定の場合に、クライアント装置、サーバ装置及び中継装置の少なくともいずれかに対して、通信資源の再確保を要求することを特徴とする通信資源調整装置。
5. 通信資源調整装置は、
   いずれかの装置における通信品質が十分でないため要求通信品質を実現できない場合に、通信品質が十分でない装置以外の他のいずれかの装置に対して、不足する通信品質の補完のために通信資源の再確保を要求することを特徴とする請求項４に記載の通信資源調整装置。
6. 通信資源を有し、サービスの提供に先立ち、サービス提供時に要求される通信品質を要求通信品質として指定し、要求通信品質に基づいてサービス提供時の通信に用いられる自装置の通信資源を確保するクライアント装置と、
   通信資源を有し、サービスの提供に先立ち、クライアント装置により指定された要求通信品質に基づいてサービス提供時の通信に用いられる自装置の通信資源を確保し、クライアント装置に対してサービスを提供するサーバ装置と、
   通信資源を有し、サーバ装置によるサービスの提供に先立ち、クライアント装置により指定された要求通信品質に基づいてサービス提供時の通信に用いられる自装置の通信資源を確保し、クライアント装置とサーバ装置との間の通信を中継する１つ以上の中継装置
   のそれぞれから、クライアント装置、サーバ装置及び中継装置のそれぞれにおいて確保された通信資源により実現される通信品質の通知を受け、クライアント装置、サーバ装置及び中継装置のそれぞれより通知された通信品質と要求通信品質とを比較し、所定の場合に、クライアント装置、サーバ装置及び中継装置の少なくともいずれかに対して、通信資源の再確保を要求することを特徴とする通信資源調整方法。
7. 通信資源調整方法は、
   いずれかの装置における通信品質が十分でないため要求通信品質を実現できない場合に、通信品質が十分でない装置以外の他のいずれかの装置に対して、不足する通信品質の補完のために通信資源の再確保を要求することを特徴とする請求項６に記載の通信資源調整方法。

Images