JP2001034583A - 分散オブジェクト性能管理機構 - Google Patents
分散オブジェクト性能管理機構Info
- Publication number
- JP2001034583A JP2001034583A JP11208547A JP20854799A JP2001034583A JP 2001034583 A JP2001034583 A JP 2001034583A JP 11208547 A JP11208547 A JP 11208547A JP 20854799 A JP20854799 A JP 20854799A JP 2001034583 A JP2001034583 A JP 2001034583A
- Authority
- JP
- Japan
- Prior art keywords
- server
- objects
- name
- application
- load
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Stored Programmes (AREA)
Abstract
(57)【要約】 （修正有）
【課題】一元的かつリアルタイムにサーバオブジェクト
の負荷情報を収集し、特定の負荷の偏りを防ぎ、個々の
サーバオブジェクトに要求された処理の実行時間増大を
防止する。 【解決手段】各サーバアプリケーション５２Ａに、処理
実行者としての個々のサーバオブジェクト１〜４の性能
データを収集・格納するモニタオブジェクト５５，５７
を設け、さらにサーバオブジェクト１〜４の性能データ
をモニタオブジェクト５５，５７から収集し、サーバオ
ブジェクト１〜４の各々の負荷値を算出し、予め設定さ
れた負荷・利用比率値対応テーブル５３を参照して、そ
れぞれの利用比率値を調べ、それらの値をネームサーバ
５１Ａに通知し、登録更新させる。ネームサーバ５１Ａ
は、登録更新した利用比率値を参照して要求者に返すオ
ブジェクトリファレンスを決定する。
の負荷情報を収集し、特定の負荷の偏りを防ぎ、個々の
サーバオブジェクトに要求された処理の実行時間増大を
防止する。 【解決手段】各サーバアプリケーション５２Ａに、処理
実行者としての個々のサーバオブジェクト１〜４の性能
データを収集・格納するモニタオブジェクト５５，５７
を設け、さらにサーバオブジェクト１〜４の性能データ
をモニタオブジェクト５５，５７から収集し、サーバオ
ブジェクト１〜４の各々の負荷値を算出し、予め設定さ
れた負荷・利用比率値対応テーブル５３を参照して、そ
れぞれの利用比率値を調べ、それらの値をネームサーバ
５１Ａに通知し、登録更新させる。ネームサーバ５１Ａ
は、登録更新した利用比率値を参照して要求者に返すオ
ブジェクトリファレンスを決定する。
Description
【０００１】
【発明の属する技術分野】本発明は、情報通信サービス
や通信網管理サービス（以下、単にサービスと呼ぶ）の
分野において、処理の実行を要求するクライアントアプ
リケーションと、要求された処理を実行し必要に応じて
上記クライアントアプリケーションに処理結果を返す１
以上のサーバオブジェクトを含むサーバアプリケーショ
ンのライフサイクルを管理し、また、クライアントアプ
リケーションとサーバオブジェクトの間の通信、同一の
サーバアプリケーション内のサーバオブジェクトの間の
通信、および別個のサーバアプリケーション内に存在す
るモニタオブジェクト間の通信を実行する分散オブジェ
クトプラットフォーム技術に関し、特に、アプリケーシ
ョンソフトウェアを構成する個々の分散オブジェクトを
適切な性能・負荷の下で動作させる分散オブジェクト性
能管理機構に関するものである。
や通信網管理サービス（以下、単にサービスと呼ぶ）の
分野において、処理の実行を要求するクライアントアプ
リケーションと、要求された処理を実行し必要に応じて
上記クライアントアプリケーションに処理結果を返す１
以上のサーバオブジェクトを含むサーバアプリケーショ
ンのライフサイクルを管理し、また、クライアントアプ
リケーションとサーバオブジェクトの間の通信、同一の
サーバアプリケーション内のサーバオブジェクトの間の
通信、および別個のサーバアプリケーション内に存在す
るモニタオブジェクト間の通信を実行する分散オブジェ
クトプラットフォーム技術に関し、特に、アプリケーシ
ョンソフトウェアを構成する個々の分散オブジェクトを
適切な性能・負荷の下で動作させる分散オブジェクト性
能管理機構に関するものである。
【０００２】
【従来の技術】分散オブジェクトプラットフォームの業
界標準仕様であるＣＯＲＢＡ（CommonObject Request B
roker Architecture）（例えば、Object Management Gr
oup,“The Common Object Request Broker. Architectu
re and Specification",Rev.2,3,ftp://ftp.omg.org/pu
b/docs/formal/99-12-01.pdf参照)に代表される分散オ
ブジェクトプラットフォームは、ＩＤＬ（Interface De
finition Language）で記載されたインタフェース定義
からオブジェクト間通信用のソースコードを生成するＩ
ＤＬコンパイラにより分散アプリケーションの効率的な
開発を支援し、また、ＩＩＯＰ（Internet Inter−ORB
Protocol）に代表されるＯＲＢ（ObjectRequest Broke
r）間の業界標準通信プロトコルを提供することで、複
数サービスの連携動作などで要求される分散アプリケー
ション間の相互運用を支援する。ここで、分散オブジェ
クトプラットフォームとは、処理の実行を要求するクラ
イアントアプリケーションと、要求された処理を実行
し、必要に応じて上記クライアントアプリケーションに
処理結果を返す1以上のサーバオブジェクトを含むサー
バアプリケーションのライフサイクルを管理し、また、
クライアントアプリケーションとサーバオブジェクトの
間の通信、同一のサーバアプリケーション内のサーバオ
ブジェクトの間の通信、および別個のサーバアプリケー
ション内に存在するサーバオブジェクト間の通信を実行
するソフトウェアおよびハードウェアを指すものであ
る。また、ＯＲＢは、オペレーティングシステム上で動
作する、分散オブジェクトプラットフォームの根幹を成
すソフトウェアで、クライアントアプリケーションから
発行された処理要求を、その処理を実行可能なサーバア
プリケーションに届けて実行させ、実行結果をサーバア
プリケーションからクライアントアプリケーションに届
ける機能を有する。
界標準仕様であるＣＯＲＢＡ（CommonObject Request B
roker Architecture）（例えば、Object Management Gr
oup,“The Common Object Request Broker. Architectu
re and Specification",Rev.2,3,ftp://ftp.omg.org/pu
b/docs/formal/99-12-01.pdf参照)に代表される分散オ
ブジェクトプラットフォームは、ＩＤＬ（Interface De
finition Language）で記載されたインタフェース定義
からオブジェクト間通信用のソースコードを生成するＩ
ＤＬコンパイラにより分散アプリケーションの効率的な
開発を支援し、また、ＩＩＯＰ（Internet Inter−ORB
Protocol）に代表されるＯＲＢ（ObjectRequest Broke
r）間の業界標準通信プロトコルを提供することで、複
数サービスの連携動作などで要求される分散アプリケー
ション間の相互運用を支援する。ここで、分散オブジェ
クトプラットフォームとは、処理の実行を要求するクラ
イアントアプリケーションと、要求された処理を実行
し、必要に応じて上記クライアントアプリケーションに
処理結果を返す1以上のサーバオブジェクトを含むサー
バアプリケーションのライフサイクルを管理し、また、
クライアントアプリケーションとサーバオブジェクトの
間の通信、同一のサーバアプリケーション内のサーバオ
ブジェクトの間の通信、および別個のサーバアプリケー
ション内に存在するサーバオブジェクト間の通信を実行
するソフトウェアおよびハードウェアを指すものであ
る。また、ＯＲＢは、オペレーティングシステム上で動
作する、分散オブジェクトプラットフォームの根幹を成
すソフトウェアで、クライアントアプリケーションから
発行された処理要求を、その処理を実行可能なサーバア
プリケーションに届けて実行させ、実行結果をサーバア
プリケーションからクライアントアプリケーションに届
ける機能を有する。
【０００３】図１は、サービスアプリケーションの構成
と運用形態を示す図である。図１に示すように、サービ
スのアプリケーション(図１のサービスアプリケーショ
ン３１）は、そのサービスを構成する機能処理の実行を
要求するクライアントアプリケーション（図１のクライ
アントアプリケーション１１）と、要求された処理を実
行し、クライアントに処理結果を返す一つ以上のサーバ
アプリケーション（図１のサーバアプリケーション１
２，１３）からなる。サーバアプリケーション（図１の
サーバアプリケーション１２，１３）は、０個以上のイ
ンタセプタ（図１のインタセプタ１，２）と１つ以上の
サーバオブジェクト（図１のサーバオブジェクト１〜
３，４〜５）を内包する。サーバオブジェクト（図１の
サーバオブジェクト３）は、クライアントアプリケーシ
ョン（図１のクライアントアプリケーション１１）、他
のサーバアプリケーション内のサーバオブジェクト（図
１のサーバオブジェクト５）、あるいは同一サーバアプ
リケーション内の他のサーバオブジェクトから要求され
た処理を実行して、その実行結果を要求者に返す。サー
ビスのアプリケーション（図１のサービスアプリケーシ
ョン３１）は、クライアントアプリケーション（図１の
クライアントアプリケーション１１）とサーバアプリケ
ーション（図１のサーバアプリケーション１２，１３）
を単位として、通信網内の１つ以上のノードシステム、
ワークステーション、あるいはパーソナルコンピュータ
など（以下、ノードと記す。図１のノード２１，２２，
２３）に必要に応じて分散して配備され、各々のノード
が備える分散オブジェクトプラットフォーム上で実行さ
れる。
と運用形態を示す図である。図１に示すように、サービ
スのアプリケーション(図１のサービスアプリケーショ
ン３１）は、そのサービスを構成する機能処理の実行を
要求するクライアントアプリケーション（図１のクライ
アントアプリケーション１１）と、要求された処理を実
行し、クライアントに処理結果を返す一つ以上のサーバ
アプリケーション（図１のサーバアプリケーション１
２，１３）からなる。サーバアプリケーション（図１の
サーバアプリケーション１２，１３）は、０個以上のイ
ンタセプタ（図１のインタセプタ１，２）と１つ以上の
サーバオブジェクト（図１のサーバオブジェクト１〜
３，４〜５）を内包する。サーバオブジェクト（図１の
サーバオブジェクト３）は、クライアントアプリケーシ
ョン（図１のクライアントアプリケーション１１）、他
のサーバアプリケーション内のサーバオブジェクト（図
１のサーバオブジェクト５）、あるいは同一サーバアプ
リケーション内の他のサーバオブジェクトから要求され
た処理を実行して、その実行結果を要求者に返す。サー
ビスのアプリケーション（図１のサービスアプリケーシ
ョン３１）は、クライアントアプリケーション（図１の
クライアントアプリケーション１１）とサーバアプリケ
ーション（図１のサーバアプリケーション１２，１３）
を単位として、通信網内の１つ以上のノードシステム、
ワークステーション、あるいはパーソナルコンピュータ
など（以下、ノードと記す。図１のノード２１，２２，
２３）に必要に応じて分散して配備され、各々のノード
が備える分散オブジェクトプラットフォーム上で実行さ
れる。
【０００４】クライアントアプリケーション（図１のク
ライアントアプリケーション１１）とサーバアプリケー
ション（図１のサーバアプリケーション１２，１３）の
間の通信は、各々のノードが備える分散オブジェクトプ
ラットフォームの中核構成要素であるＯＲＢ（図１のＯ
ＲＢ１，２，３）により実現され、サーバアプリケーシ
ョン（図１のサーバアプリケーション１２，１３）内で
適切なサーバオブジェクト（図１のサーバオブジェクト
１〜３，４〜５）に処理要求を渡すのは、ディスパッチ
ャにより行われる。実装では、ＯＲＢの一部とディスパ
ッチは、クライアントアプリケーション（図１のクライ
アントアプリケーション１１）、サーバアプリケーショ
ン（図１のサーバアプリケーション１２，１３）それぞ
れの論理空間（ＵＮＩＸでのプロセス）に含まれ得る。
なお、本発明では、ディスパッチャの存在を想定してい
るが、以後の図では便宜上それを記述しないことにす
る。また、インタセプタ（図１のインタセプタ１，２）
（例えば、Object Management Group,“The Common Obj
ect Request Broker. Architecture and Specificatio
n",Rev.2,3,ftp://ftp.omg.org/pub/docs/formal/99-12
-01.pdf参照)は、ＯＲＢ（図１のＯＲＢ２，３）上で動
作するオブジェクトであり、クライアントアプリケーシ
ョン（図１のクライアントアプリケーション１１）や他
のサーバオブジェクトから、サーバオブジェクト（図１
のサーバオブジェクト１〜３，４〜５）へ送られる処理
要求を仲介する。インタセプタには、クライアントアプ
リケーション側に存在するＯＲＢの間に存在するクライ
アントインタセプタと、サーバアプリケーション側に存
在するサーバインタセプタ（図１のインタセプタ１，
２）があるが、本発明では、サーバインタセプタをイン
タセプタと記すことにする。インタセプタを用いること
で、クライアントアプリケーションとサーバアプリケー
ション間の通信の内容を調べることが可能となる。サー
ビスアプリケーション実行時の性能を確保するには、サ
ービスアプリケーションを構成する個々のサーバオブジ
ェクトが過負荷状態に陥り、個々の要求された処理の実
行時間が増大することを防ぐ機構が必要となる。この機
構を提供する代表的な方式として、従来より（１）リク
エストキュー方式と（２）ネームサーバ方式の２つがあ
る。
ライアントアプリケーション１１）とサーバアプリケー
ション（図１のサーバアプリケーション１２，１３）の
間の通信は、各々のノードが備える分散オブジェクトプ
ラットフォームの中核構成要素であるＯＲＢ（図１のＯ
ＲＢ１，２，３）により実現され、サーバアプリケーシ
ョン（図１のサーバアプリケーション１２，１３）内で
適切なサーバオブジェクト（図１のサーバオブジェクト
１〜３，４〜５）に処理要求を渡すのは、ディスパッチ
ャにより行われる。実装では、ＯＲＢの一部とディスパ
ッチは、クライアントアプリケーション（図１のクライ
アントアプリケーション１１）、サーバアプリケーショ
ン（図１のサーバアプリケーション１２，１３）それぞ
れの論理空間（ＵＮＩＸでのプロセス）に含まれ得る。
なお、本発明では、ディスパッチャの存在を想定してい
るが、以後の図では便宜上それを記述しないことにす
る。また、インタセプタ（図１のインタセプタ１，２）
（例えば、Object Management Group,“The Common Obj
ect Request Broker. Architecture and Specificatio
n",Rev.2,3,ftp://ftp.omg.org/pub/docs/formal/99-12
-01.pdf参照)は、ＯＲＢ（図１のＯＲＢ２，３）上で動
作するオブジェクトであり、クライアントアプリケーシ
ョン（図１のクライアントアプリケーション１１）や他
のサーバオブジェクトから、サーバオブジェクト（図１
のサーバオブジェクト１〜３，４〜５）へ送られる処理
要求を仲介する。インタセプタには、クライアントアプ
リケーション側に存在するＯＲＢの間に存在するクライ
アントインタセプタと、サーバアプリケーション側に存
在するサーバインタセプタ（図１のインタセプタ１，
２）があるが、本発明では、サーバインタセプタをイン
タセプタと記すことにする。インタセプタを用いること
で、クライアントアプリケーションとサーバアプリケー
ション間の通信の内容を調べることが可能となる。サー
ビスアプリケーション実行時の性能を確保するには、サ
ービスアプリケーションを構成する個々のサーバオブジ
ェクトが過負荷状態に陥り、個々の要求された処理の実
行時間が増大することを防ぐ機構が必要となる。この機
構を提供する代表的な方式として、従来より（１）リク
エストキュー方式と（２）ネームサーバ方式の２つがあ
る。
【０００５】（１）リクェストキューを用いる方式 図２は、従来のリクェストキューを用いてサーバオブジ
ェクトの負荷制御を行う方式を示す図である。この方式
では、図２に示すように、ＯＲＢ（図２のＯＲＢ２，
３，４）内にリクェストキュー（図２のリクエストキュ
ー１，２，３）を設ける。図２で、クライアントアプリ
ケーション２１は、サーバオブジェクトに処理要求を送
信する代りに、そのリクェストキュー１に処理要求を送
る（図２の２０１）。処理を実行していないサーバオブ
ジェクト（サーバオブジェクト１）あるいは以前に要求
された処理を実行し終えたサーバオブジェクト（図に該
当するサーバオブジェクトはない）が、そのキューから
次の処理要求を取り出し（図２の２０２）、処理の実行
を開始する。ここで、リクェストキュー（図２のリクェ
ストキュー１，２，３）に処理要求が一定数以上たまっ
た場合には、所望の処理を実行するサーバオブジェクト
を含む新たなサーバアプリケーション２４を起動する
か、あるいはリクェストキュー内の要求処理の数が一定
値以下になるまで、クライアントアプリケーション２１
からの新たな処理要求を受け付けないようにする。この
方式により、特定のサーバオブジェクトに処理要求が偏
ることを防ぎ、また全体の要求処理頻度の変動に対処す
る。この方式は、従来のＴＰ（Transaction Processin
g）モニタ製品やＣＯＲＢＡ準拠ＯＲＢを内包するＯＴ
Ｍ（Object Transaction Monitor）製品（例えば、IONA
Technologies， OrbixOTM，http://www．iona.com/inf
o/products/orbixenter/orbixotm/index.htmlおよびINP
RISE Corporation,Inprisc Application Server,http:/
/www.inprise.com/appserver/参照）などで用いられ
る。なお、本発明では、ＯＲＢの存在を想定するが、以
後の図においては便宜上それを記述しない。
ェクトの負荷制御を行う方式を示す図である。この方式
では、図２に示すように、ＯＲＢ（図２のＯＲＢ２，
３，４）内にリクェストキュー（図２のリクエストキュ
ー１，２，３）を設ける。図２で、クライアントアプリ
ケーション２１は、サーバオブジェクトに処理要求を送
信する代りに、そのリクェストキュー１に処理要求を送
る（図２の２０１）。処理を実行していないサーバオブ
ジェクト（サーバオブジェクト１）あるいは以前に要求
された処理を実行し終えたサーバオブジェクト（図に該
当するサーバオブジェクトはない）が、そのキューから
次の処理要求を取り出し（図２の２０２）、処理の実行
を開始する。ここで、リクェストキュー（図２のリクェ
ストキュー１，２，３）に処理要求が一定数以上たまっ
た場合には、所望の処理を実行するサーバオブジェクト
を含む新たなサーバアプリケーション２４を起動する
か、あるいはリクェストキュー内の要求処理の数が一定
値以下になるまで、クライアントアプリケーション２１
からの新たな処理要求を受け付けないようにする。この
方式により、特定のサーバオブジェクトに処理要求が偏
ることを防ぎ、また全体の要求処理頻度の変動に対処す
る。この方式は、従来のＴＰ（Transaction Processin
g）モニタ製品やＣＯＲＢＡ準拠ＯＲＢを内包するＯＴ
Ｍ（Object Transaction Monitor）製品（例えば、IONA
Technologies， OrbixOTM，http://www．iona.com/inf
o/products/orbixenter/orbixotm/index.htmlおよびINP
RISE Corporation,Inprisc Application Server,http:/
/www.inprise.com/appserver/参照）などで用いられ
る。なお、本発明では、ＯＲＢの存在を想定するが、以
後の図においては便宜上それを記述しない。
【０００６】（２）ネームサーバを用いる方式 図３は、従来の代表的なネームサーバ仕様であるＯＭＧ
（Object ManagementGroup）ネーミングサービス仕様
（例えば、Object Managment Group,“CORBA Services:
Common Object Service Specification”，ftp://ftp.o
mg.org/pub/docs/formal/99-07-05.pdf.参照)に準拠す
るネームサーバ(例えば、IONA Technologies, OrbixOT
M,http://www.iona.com/info/products/orbixeenter/or
bixotm/index.htmlまたはINPRISE Corporation, VisiBr
oker Naming Service,http://www.inprise.com/visibro
ker/products/nameds.html参照）を用いた方式を示す図
である。ネームサーバ（図３のネームサーバ３３）は、
自身にとっての要求者であるクライアントアプリケーシ
ョン（図３のクライアントアプリケーション３１，３
２）やサーバアプリケーション（図３のサーバアプリケ
ーション３４，３５）内のサーバオブジェクトから、そ
の要求者サーバオブジェクト以外のサーバオブジェクト
（図３のサーバオブジェクト１，２でその要求者サーバ
オブジェクト以外のもの）の名前を指定された（図３の
３０１，３０２）ときに、後者（要求者でない方）のサ
ーバオブジェクトのオブジェクトリファレンスをその要
求者に提供する（図３の３０３，３０４），特殊なサー
バアプリケーションあるいはサーバオブジェクトであ
る。ここで、要求者から指定される名前は、ネームサー
バが管理するネーミンググラフ３６の階層構造に従った
形式で指定される。例えば、図３で、Ｂａｎｋ＿Ｂサー
バオブジェクトは、ネーミンググラフの上から下への階
層を辿って／Ｄｅｐａｒｔｍｅｎｔ＿Ｂ／Ｂａｎｋ＿Ｂ
という名前で識別される。要求者（図３のクライアント
アプリケーション３１，３２）は、所望の処理を実行す
るサーバオブジェクト（図３のサーバオブジェクト１，
２）に処理要求を送る前に、そのサーバオブジェクト
（図３のサーバオブジェクト１，２）のオブジェクトリ
ファレンスを獲得するために必要に応じてネームサーバ
（図３の３０３）にアクセスする（図３の３０１，３０
２，３０３，３０４）。オブジェクトリファレンスは、
サーバオブジェクト（図３のサーバオブジェクト１，
２）毎に対応して存在し、ノードアドレス（例えば、Ｉ
Ｐアドレスやノード名）、ポート番号、およびノード内
で一意な識別名など、対応するサーバオブジェクトへ処
理要求を送るために必要なデータを含む。例えば、図３
では、Ｂａｎｋ＿Ｂサーバオブジェクトのオブジェクト
リファレンスは、ノードアドレス：Ｈｏｓｔ＿Ｂ、ポー
ト番号：１２５９、識別子：Ｂａｎｋ＿Ｂのデータを含
む形で、／Ｄｅｐａｒｔｍｅｎｔ＿Ｂ／Ｂａｎｋ＿Ｂと
いう名前でネームサーバに登録されている。なお、サー
バオブジェクト（図３のサーバオブジェクト１，２）の
名前とオブジェクトリファレンスは、対応するサーバオ
ブジェクト自身からの要求によりネームサーバ（図３の
ネームサーバ３３）に予め登録される（図３の３０５，
３０６）。また、クライアントアプリケーション（図３
のクライアントアプリケーション３１，３２）とネーム
サーバ（図３のネームサーバ３３）間、サーバオブジェ
クト（図３のサーバオブジェクト１，２）とネームサー
バ（図３のネームサーバ３３）間の通信もＯＲＢ（図示
省略）を介して行わる。
（Object ManagementGroup）ネーミングサービス仕様
（例えば、Object Managment Group,“CORBA Services:
Common Object Service Specification”，ftp://ftp.o
mg.org/pub/docs/formal/99-07-05.pdf.参照)に準拠す
るネームサーバ(例えば、IONA Technologies, OrbixOT
M,http://www.iona.com/info/products/orbixeenter/or
bixotm/index.htmlまたはINPRISE Corporation, VisiBr
oker Naming Service,http://www.inprise.com/visibro
ker/products/nameds.html参照）を用いた方式を示す図
である。ネームサーバ（図３のネームサーバ３３）は、
自身にとっての要求者であるクライアントアプリケーシ
ョン（図３のクライアントアプリケーション３１，３
２）やサーバアプリケーション（図３のサーバアプリケ
ーション３４，３５）内のサーバオブジェクトから、そ
の要求者サーバオブジェクト以外のサーバオブジェクト
（図３のサーバオブジェクト１，２でその要求者サーバ
オブジェクト以外のもの）の名前を指定された（図３の
３０１，３０２）ときに、後者（要求者でない方）のサ
ーバオブジェクトのオブジェクトリファレンスをその要
求者に提供する（図３の３０３，３０４），特殊なサー
バアプリケーションあるいはサーバオブジェクトであ
る。ここで、要求者から指定される名前は、ネームサー
バが管理するネーミンググラフ３６の階層構造に従った
形式で指定される。例えば、図３で、Ｂａｎｋ＿Ｂサー
バオブジェクトは、ネーミンググラフの上から下への階
層を辿って／Ｄｅｐａｒｔｍｅｎｔ＿Ｂ／Ｂａｎｋ＿Ｂ
という名前で識別される。要求者（図３のクライアント
アプリケーション３１，３２）は、所望の処理を実行す
るサーバオブジェクト（図３のサーバオブジェクト１，
２）に処理要求を送る前に、そのサーバオブジェクト
（図３のサーバオブジェクト１，２）のオブジェクトリ
ファレンスを獲得するために必要に応じてネームサーバ
（図３の３０３）にアクセスする（図３の３０１，３０
２，３０３，３０４）。オブジェクトリファレンスは、
サーバオブジェクト（図３のサーバオブジェクト１，
２）毎に対応して存在し、ノードアドレス（例えば、Ｉ
Ｐアドレスやノード名）、ポート番号、およびノード内
で一意な識別名など、対応するサーバオブジェクトへ処
理要求を送るために必要なデータを含む。例えば、図３
では、Ｂａｎｋ＿Ｂサーバオブジェクトのオブジェクト
リファレンスは、ノードアドレス：Ｈｏｓｔ＿Ｂ、ポー
ト番号：１２５９、識別子：Ｂａｎｋ＿Ｂのデータを含
む形で、／Ｄｅｐａｒｔｍｅｎｔ＿Ｂ／Ｂａｎｋ＿Ｂと
いう名前でネームサーバに登録されている。なお、サー
バオブジェクト（図３のサーバオブジェクト１，２）の
名前とオブジェクトリファレンスは、対応するサーバオ
ブジェクト自身からの要求によりネームサーバ（図３の
ネームサーバ３３）に予め登録される（図３の３０５，
３０６）。また、クライアントアプリケーション（図３
のクライアントアプリケーション３１，３２）とネーム
サーバ（図３のネームサーバ３３）間、サーバオブジェ
クト（図３のサーバオブジェクト１，２）とネームサー
バ（図３のネームサーバ３３）間の通信もＯＲＢ（図示
省略）を介して行わる。
【０００７】図４は、オブジェクトグループをサポート
するネームサーバを示す従来例を示す図である。一部の
ネームサーバ（例えば、IONA Technologies, OrbixOTM,
http://www.iona.com/info/products/orbixenter/orbix
otm/index,html参照）（図４のネームサーバ４３）で
は、同一のインタフェースを提供するサーバオブジェク
ト群（図４のサーバオブジェクト１と２、３と４）があ
るとき、個々のサーバオブジェクトのオブジェクトリフ
ァレンスをオブジェクトグループとしてまとめてグルー
プ化し、そのオブジェクトグループと名前を対応させる
（図４のサーバオブジェクト１と２に対して４０９、サ
ーバオブジェクト３と４に対して４１０）方式を用いて
いる。要求者としてのクライアントアプリケーション
（図４のクライアントアプリケーション４１，４２）あ
るいはサーバオブジェクトは、オブジェクトグループの
名前を指定してネームサーバ（図４のネームサーバ４
３）に所望の処理を実行するサーバオブジェクト（図４
のサーバオブジェクト１〜４）のオブジェクトリファレ
ンスを要求する（図４の４０１，４０２）。ネームサー
バ（図４のネームサーバ４３）は、オブジェクトリファ
レンスの要求を受けると、指定されたオブジェクトグル
ープ（図４の４０９，４１０）に登録（図４の４０５〜
４０８）されたオブジェクトリファレンスの中の１つを
選定し、その要求者に返す（図４の４０３，４０４）。
これ以後、そのネームサーバ（図４のネームサーバ４
３）が新たなオブジェクトリファレンスの要求（図４の
４０１，４０２）を受けたときには、指定されたオブジ
ェクトグループ（図４の４０９，４１０）に登録（図４
の４０５〜４０８）されたオブジェクトリファレンスの
中で、先に返したオブジェクトリファレンスの次に登録
されたオブジェクトリファレンスを要求者に返す（図４
の４０３，４０４）。ここで、次に登録されたオブジェ
クトリファレンスが存在しない場合には、そのオブジェ
クトグループ（図４の４０９，４１０）で最初に登録
（図４の４０５〜４０８）されたオブジェクトリファレ
ンス情報を返す（図４の４０３，４０４）。なお、オブ
ジェクトグループ（図４の４０９，４１０）に登録され
たオブジェクトリファレンスの中から１つを選定する他
の方法として、予め固定的に定められた割合（確率）値
を基に選定する方法もある。これにより、同一の機能を
有する複数のサーバオブジェクト（図４のサーバオブジ
ェクト１と２、３と４）が存在するとき、そのサーバオ
ブジェクト（図４のサーバオブジェクト１と２、３と
４）が順次起動され、サーバオブジェクト（図４のサー
バオブジェクト１と２、３と４）間での負荷分散を図
る。
するネームサーバを示す従来例を示す図である。一部の
ネームサーバ（例えば、IONA Technologies, OrbixOTM,
http://www.iona.com/info/products/orbixenter/orbix
otm/index,html参照）（図４のネームサーバ４３）で
は、同一のインタフェースを提供するサーバオブジェク
ト群（図４のサーバオブジェクト１と２、３と４）があ
るとき、個々のサーバオブジェクトのオブジェクトリフ
ァレンスをオブジェクトグループとしてまとめてグルー
プ化し、そのオブジェクトグループと名前を対応させる
（図４のサーバオブジェクト１と２に対して４０９、サ
ーバオブジェクト３と４に対して４１０）方式を用いて
いる。要求者としてのクライアントアプリケーション
（図４のクライアントアプリケーション４１，４２）あ
るいはサーバオブジェクトは、オブジェクトグループの
名前を指定してネームサーバ（図４のネームサーバ４
３）に所望の処理を実行するサーバオブジェクト（図４
のサーバオブジェクト１〜４）のオブジェクトリファレ
ンスを要求する（図４の４０１，４０２）。ネームサー
バ（図４のネームサーバ４３）は、オブジェクトリファ
レンスの要求を受けると、指定されたオブジェクトグル
ープ（図４の４０９，４１０）に登録（図４の４０５〜
４０８）されたオブジェクトリファレンスの中の１つを
選定し、その要求者に返す（図４の４０３，４０４）。
これ以後、そのネームサーバ（図４のネームサーバ４
３）が新たなオブジェクトリファレンスの要求（図４の
４０１，４０２）を受けたときには、指定されたオブジ
ェクトグループ（図４の４０９，４１０）に登録（図４
の４０５〜４０８）されたオブジェクトリファレンスの
中で、先に返したオブジェクトリファレンスの次に登録
されたオブジェクトリファレンスを要求者に返す（図４
の４０３，４０４）。ここで、次に登録されたオブジェ
クトリファレンスが存在しない場合には、そのオブジェ
クトグループ（図４の４０９，４１０）で最初に登録
（図４の４０５〜４０８）されたオブジェクトリファレ
ンス情報を返す（図４の４０３，４０４）。なお、オブ
ジェクトグループ（図４の４０９，４１０）に登録され
たオブジェクトリファレンスの中から１つを選定する他
の方法として、予め固定的に定められた割合（確率）値
を基に選定する方法もある。これにより、同一の機能を
有する複数のサーバオブジェクト（図４のサーバオブジ
ェクト１と２、３と４）が存在するとき、そのサーバオ
ブジェクト（図４のサーバオブジェクト１と２、３と
４）が順次起動され、サーバオブジェクト（図４のサー
バオブジェクト１と２、３と４）間での負荷分散を図
る。
【０００８】
【発明が解決しようとする課題】分散オブジェクトプラ
ットフォーム製品は、それぞれ異なる特徴を持ち得るた
め、機能、性能、規模などサービス開発時や運用時の様
々な要望に応じて、１つのサービスアプリケーションを
構成する個々のサーバオブジェクトがそれを動作させる
ために、最適な分散オブジェクトプラットフォーム上で
動作させる状況が存在する。このような状況では、複数
種類の分散オブジェクトプラットフォームを用いて１つ
のサービスアプリケーションを動作させることになる。
この場合においても、個々のサーバオブジェクトの負荷
制御を一元的に行える必要がある。ところが、既存のＯ
ＴＭ製品に代表される分散オブジェクトプラットフォー
ム製品などで用いられているリクェストキューを用いる
方式では、処理要求者によるサーバオブジェクトのオブ
ジェクトリファレンスの入手法や、クライアントアプリ
ケーションやサーバアプリケーションからのキューへの
アクセス方法およびキューの操作方法が、製品毎に異な
っている。このため、例えば、分散オブジェクトプラッ
トフォーム製品Ａ上で動作するサーバアプリケーション
の負荷情報あるいはメッセージキューに関する情報など
を、製品Ｂ上で動作している管理アプリケーションとし
てのクライアントアプリケーションが入手することは、
そのアクセス方法および操作方法の違いにより実現が困
難である。すなわち、従来、複数種類の分散オブジェク
トプラットフォーム製品を混在させた環境下でサービス
アプリケーションの性能管理を行う場合、個々の製品毎
にそれ性能管理ツールを導入する必要がある。結果的に
個々のサーバオブジェクトの負荷制御を一元的に行うこ
とができないため、既存製品でのリクエストキューを用
いる方式では、複数種類の分散オブジェクトプラットフ
ォーム製品を混在させた環境下において、サーバオブジ
ェクトでの個々の要求された処理の実行時間が増大する
ことを防止できないという問題があった。
ットフォーム製品は、それぞれ異なる特徴を持ち得るた
め、機能、性能、規模などサービス開発時や運用時の様
々な要望に応じて、１つのサービスアプリケーションを
構成する個々のサーバオブジェクトがそれを動作させる
ために、最適な分散オブジェクトプラットフォーム上で
動作させる状況が存在する。このような状況では、複数
種類の分散オブジェクトプラットフォームを用いて１つ
のサービスアプリケーションを動作させることになる。
この場合においても、個々のサーバオブジェクトの負荷
制御を一元的に行える必要がある。ところが、既存のＯ
ＴＭ製品に代表される分散オブジェクトプラットフォー
ム製品などで用いられているリクェストキューを用いる
方式では、処理要求者によるサーバオブジェクトのオブ
ジェクトリファレンスの入手法や、クライアントアプリ
ケーションやサーバアプリケーションからのキューへの
アクセス方法およびキューの操作方法が、製品毎に異な
っている。このため、例えば、分散オブジェクトプラッ
トフォーム製品Ａ上で動作するサーバアプリケーション
の負荷情報あるいはメッセージキューに関する情報など
を、製品Ｂ上で動作している管理アプリケーションとし
てのクライアントアプリケーションが入手することは、
そのアクセス方法および操作方法の違いにより実現が困
難である。すなわち、従来、複数種類の分散オブジェク
トプラットフォーム製品を混在させた環境下でサービス
アプリケーションの性能管理を行う場合、個々の製品毎
にそれ性能管理ツールを導入する必要がある。結果的に
個々のサーバオブジェクトの負荷制御を一元的に行うこ
とができないため、既存製品でのリクエストキューを用
いる方式では、複数種類の分散オブジェクトプラットフ
ォーム製品を混在させた環境下において、サーバオブジ
ェクトでの個々の要求された処理の実行時間が増大する
ことを防止できないという問題があった。
【０００９】一方、ネームサーバを用いる方式では、グ
ループに登録された個々のオブジェクトリファレンス情
報に対応するサーバオブジェクトに順番に処理要求が発
行される。しかし、サーバオブジェクトにおいて要求さ
れた処理を実行し終えるのに要する時間が、処理要求の
内容や入力パラメータなどに応じて大きく変動する場合
がある。この場合、グループに登録された個々のオブジ
ェクトリファレンス情報に対応するサーバオブジェクト
に順番に処理要求が発行されても、あるいは予め定めら
れた固定的な割合で個々のサーバオブジェクトに処理要
求が発行されても、各々のサーバオブジェクトでの要求
された処理の実行時間にばらつきが生じ、結果的に特定
のサーバオブジェクトに負荷が偏り得るため、個々の要
求された処理の実行時間が増大することを防ぐことがで
きないという問題がある。従って、複数のＯＲＢ製品を
導入した環境においても、サービスアプリケーションを
構成するサーバオブジェクト群の間で、一元的に個々の
サーバオブジェクトの負荷状況に応じて負荷制御および
負荷分散を行い、必要に応じてサーバオブジェクト数を
調整しながら、特定のサーバオブジェクトでの負荷の偏
りを防止し、個々の要求された処理の実行時間増大を防
止する機構が必要である。
ループに登録された個々のオブジェクトリファレンス情
報に対応するサーバオブジェクトに順番に処理要求が発
行される。しかし、サーバオブジェクトにおいて要求さ
れた処理を実行し終えるのに要する時間が、処理要求の
内容や入力パラメータなどに応じて大きく変動する場合
がある。この場合、グループに登録された個々のオブジ
ェクトリファレンス情報に対応するサーバオブジェクト
に順番に処理要求が発行されても、あるいは予め定めら
れた固定的な割合で個々のサーバオブジェクトに処理要
求が発行されても、各々のサーバオブジェクトでの要求
された処理の実行時間にばらつきが生じ、結果的に特定
のサーバオブジェクトに負荷が偏り得るため、個々の要
求された処理の実行時間が増大することを防ぐことがで
きないという問題がある。従って、複数のＯＲＢ製品を
導入した環境においても、サービスアプリケーションを
構成するサーバオブジェクト群の間で、一元的に個々の
サーバオブジェクトの負荷状況に応じて負荷制御および
負荷分散を行い、必要に応じてサーバオブジェクト数を
調整しながら、特定のサーバオブジェクトでの負荷の偏
りを防止し、個々の要求された処理の実行時間増大を防
止する機構が必要である。
【００１０】そこで、本発明の目的は、このような従来
の課題を解決し、異なる分散オブジェクトプラットフォ
ーム製品を導入した環境下でも、全てのサーバオブジェ
クトの負荷状況を一元的に逐次把握し、その負荷状況に
対応して負荷制御および負荷分散をリアルタイムに行
い、その結果として個々の要求された処理の実行時間の
増大を防止することが可能な分散オブジェクト性能管理
機構を提供することにある。また、本発明のさらなる目
的としては、サーバオブジェクトの実装に影響を及ぼさ
ず分散オブジェクト性能管理機構を導入でき、しかもモ
ニタオブジェクトの実装への影響なしにサーバオブジェ
クトの実装を変更できる分散オブジェクト性能管理機構
を提供することにある。
の課題を解決し、異なる分散オブジェクトプラットフォ
ーム製品を導入した環境下でも、全てのサーバオブジェ
クトの負荷状況を一元的に逐次把握し、その負荷状況に
対応して負荷制御および負荷分散をリアルタイムに行
い、その結果として個々の要求された処理の実行時間の
増大を防止することが可能な分散オブジェクト性能管理
機構を提供することにある。また、本発明のさらなる目
的としては、サーバオブジェクトの実装に影響を及ぼさ
ず分散オブジェクト性能管理機構を導入でき、しかもモ
ニタオブジェクトの実装への影響なしにサーバオブジェ
クトの実装を変更できる分散オブジェクト性能管理機構
を提供することにある。
【００１１】
【課題を解決するための手段】上記目的を達成するた
め、本発明の分散オブジェクト性能管理機構では、処理
実行者としての個々のサーバオブジェクト（図５のサー
バオブジェクト１〜４）における要求者（図５のクライ
アントアプリケーション５４Ａ）から要求された処理の
実行状況に関するサーバオブジェクト性能データ（以
後、性能データと記す。図５の性能データ５６、５８）
を格納するモニタオブジェクト（図５のモニタオブジェ
クト５５）を設ける。モニタオブジェクト（図５のモニ
タオブジェクト５５，５７）はサーバオブジェクト（図
５のサーバオブジェクト１，２）とは独立した別個のオ
ブジェクトであり、サーバアプリケーション（図５のサ
ーバアプリケーション５２Ａ，５９Ａ）内に１つ設けら
れる。性能データ（図５の性能データ５６，５８）は、
サーバオブジェクト（図５のサーバオブジェクト１〜
４）が要求者から要求され、実行した個々の処理につい
て、その処理の実行開始・終了時刻、処理名、およびそ
の処理を実行したサーバオブジェクト名を記録したもの
である。また、その性能データ（図５の性能データ５
６，５８）を基に各々のサーバオブジェクト（図５のサ
ーバオブジェクト１〜４）の負荷値を算出し、負荷値・
利用比率値対応テーブル（図５の５３）を参照して、各
々のサーバオブジェクト（図５のサーバオブジェクト１
〜４）の利用比率値を決定し、その各サーバオブジェク
ト毎の利用比率値をネームサーバ（図５のネームサーバ
５１Ａ）に通知（図５の５１１）するサーバマネージャ
アプリケーション（図５のサーバマネージャアプリケー
ション５３Ａ）を設ける。負荷値は、サーバオブジェク
トで実行した個々の処理の平均実行時間と、実行時間が
予め処理内容毎に指定された許容実行時間を超えた処理
の回数の２つのパラメータを含み、サーバオブジェクト
（図５のサーバオブジェクト１〜４）の負荷の変動に対
応して、サーバマネージャアプリケーション（図５のサ
ーバマネージャアプリケーション５３Ａ）で逐次計算・
更新される。更新された負荷値に対応した各サーバオブ
ジェクトの新しい利用比率値は、サーバマネージャアプ
リケーションから定期的にネームサーバ（図５のネーム
サーバ５１Ａ）へ通知（図５の５１１）される。また、
負荷値・利用比率値対応テーブル（図５の５３）は、予
めサービスアプリケーション運用管理者により設定され
る。典型的には、大きい負荷値に対しては、利用比率値
を小さく設定する。ネームサーバ（図５のネームサーバ
５１Ａ）は、要求者（図５のクライアントアプリケーシ
ョン５４Ａ）からオブジェクトリファレンスの要求を受
けると（図５の５０１）、指定されたオブジェクトグル
ープに登録されている個々のオブジェクトリファレンス
に対応するサーバオブジェクトの利用比率値の割合（図
５の５１）を参照して、その割合に従って１つ以上のオ
ブジェクトリファレンスを選定し、要求者に返す（図５
の５０２）。
め、本発明の分散オブジェクト性能管理機構では、処理
実行者としての個々のサーバオブジェクト（図５のサー
バオブジェクト１〜４）における要求者（図５のクライ
アントアプリケーション５４Ａ）から要求された処理の
実行状況に関するサーバオブジェクト性能データ（以
後、性能データと記す。図５の性能データ５６、５８）
を格納するモニタオブジェクト（図５のモニタオブジェ
クト５５）を設ける。モニタオブジェクト（図５のモニ
タオブジェクト５５，５７）はサーバオブジェクト（図
５のサーバオブジェクト１，２）とは独立した別個のオ
ブジェクトであり、サーバアプリケーション（図５のサ
ーバアプリケーション５２Ａ，５９Ａ）内に１つ設けら
れる。性能データ（図５の性能データ５６，５８）は、
サーバオブジェクト（図５のサーバオブジェクト１〜
４）が要求者から要求され、実行した個々の処理につい
て、その処理の実行開始・終了時刻、処理名、およびそ
の処理を実行したサーバオブジェクト名を記録したもの
である。また、その性能データ（図５の性能データ５
６，５８）を基に各々のサーバオブジェクト（図５のサ
ーバオブジェクト１〜４）の負荷値を算出し、負荷値・
利用比率値対応テーブル（図５の５３）を参照して、各
々のサーバオブジェクト（図５のサーバオブジェクト１
〜４）の利用比率値を決定し、その各サーバオブジェク
ト毎の利用比率値をネームサーバ（図５のネームサーバ
５１Ａ）に通知（図５の５１１）するサーバマネージャ
アプリケーション（図５のサーバマネージャアプリケー
ション５３Ａ）を設ける。負荷値は、サーバオブジェク
トで実行した個々の処理の平均実行時間と、実行時間が
予め処理内容毎に指定された許容実行時間を超えた処理
の回数の２つのパラメータを含み、サーバオブジェクト
（図５のサーバオブジェクト１〜４）の負荷の変動に対
応して、サーバマネージャアプリケーション（図５のサ
ーバマネージャアプリケーション５３Ａ）で逐次計算・
更新される。更新された負荷値に対応した各サーバオブ
ジェクトの新しい利用比率値は、サーバマネージャアプ
リケーションから定期的にネームサーバ（図５のネーム
サーバ５１Ａ）へ通知（図５の５１１）される。また、
負荷値・利用比率値対応テーブル（図５の５３）は、予
めサービスアプリケーション運用管理者により設定され
る。典型的には、大きい負荷値に対しては、利用比率値
を小さく設定する。ネームサーバ（図５のネームサーバ
５１Ａ）は、要求者（図５のクライアントアプリケーシ
ョン５４Ａ）からオブジェクトリファレンスの要求を受
けると（図５の５０１）、指定されたオブジェクトグル
ープに登録されている個々のオブジェクトリファレンス
に対応するサーバオブジェクトの利用比率値の割合（図
５の５１）を参照して、その割合に従って１つ以上のオ
ブジェクトリファレンスを選定し、要求者に返す（図５
の５０２）。
【００１２】このように、サーバオブジェクト（図５の
サーバオブジェクト１〜４）の負荷の変動に伴い、リア
ルタイムに各々のサーバオブジェクト（図５のサーバオ
ブジェクト１〜４）の負荷値が算出され、その負荷値に
対応した利用比率値がネームサーバ（図５のネームサー
バ５１Ａ）に通知される（図５の５１１）。要求者がネ
ームサーバ（図５のネームサーバ５１Ａ）にオブジェク
トリファレンスを要求したときに、ネームサーバ（図５
のネームサーバ５１Ａ）は利用比率値の大きいサーバオ
ブジェクト（例えば、図５のサーバオブジェクト４）の
オブジェクトリファレンスを優先的に返すが、典型的に
は大きい利用比率値はサーバオブジェクト（例えば、図
５のサーバオブジェクト４）での小さい負荷を意味する
ので、ネームサーバ（図５のネームサーバ５１Ａ）は、
要求者に対して負荷の小さいサーバオブジェクト（例え
ば図５のサーバオブジェクト４）のオブジェクトリファ
レンスを優先的に返していることになる。しかも、実際
のサーバオブジェクト（図５のサーバオブジェクト１〜
４）の負荷状況に応じて負荷値が定期的に算出され、対
応した利用比率値がネームサーバ（図５のネームサーバ
５１Ａ）に通知され登録されるため、その負荷値と利用
比率値は実際のサーバオブジェクト（図５のサーバオブ
ジェクト１〜４）の負荷状況をリアルタイムに反映す
る。従って、本発明を用いることで、実際のサーバオブ
ジェクト（図５のサーバオブジェクト１〜４）の負荷状
況を考慮しながら特定のサーバオブジェクトでの負荷の
偏りを防止し、個々の要求された処理の実行時間の増大
を防止することが可能になる。また、ＯＲＢＰ製品毎の
ＯＲＢのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒ
ａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の違いにより、モ
ニタオブジェクト（図５のモニタオブジェクト５５，５
７）はＯＲＢ毎に異なる実装のものが提供されるが、全
てのモニタオブジェクト（図５のモニタオブジェクト５
５，５７）が提供するインタフェースは同一である。さ
らに、前記のＩＩＯＰなどの分散オブジェクトプラット
フォーム間の標準通信プロトコルを用いることで、イン
タフェースとプロトコルを整合させることが可能とな
り、複数種類の分散オブジェクトプラットフォーム製品
を混在させた環境下において、サーバマネージャアプリ
ケーション（図５のサーバマネージャアプリケーション
５３Ａ）から全てのサーバオブジェクト（図５のサーバ
オブジェクト１〜４）に対して処理の実行を要求するこ
とが可能になる。これにより、サーバマネージャアプリ
ケーション（図５のサーバマネージャアプリケーション
５３Ａ）が、異なる分散オブジェクトプラットフォーム
上で動作する全てのサーバオブジェクト（図５のサーバ
オブジェクト１〜４）から性能データを収集することが
可能となる。従って、複数種類の分散オブジェクトプラ
ットフォーム製品を混在させた環境下において、個々の
サーバオブジェクト（図５のサーバオブジェクト１〜
４）の負荷制御を一元的に行い、サーバオブジェクト
（図５のサーバオブジェクト１〜４）での個々の要求さ
れた処理の実行時間の増大を防止することが可能にな
る。また、モニタオブジェクトの実装をサーバオブジェ
クトの実装から分離する（図５で、モニタオブジェクト
５５とサーバオブジェクト１と２、モニタオブジェクト
５７とサーバオブジェクト３と４）ことで、サーバオブ
ジェクト（図５のサーバオブジェクト１〜４）の実装に
影響を及ぼさずに分散オブジェクト性能管理機構を導入
でき、しかもモニタオブジェクト（図５のモニタオブジ
ェクト５５，５７）の実装への影響なしにサーバオブジ
ェクト（図５のサーバオブジェクト１〜４）の実装を変
更することが可能になる。
サーバオブジェクト１〜４）の負荷の変動に伴い、リア
ルタイムに各々のサーバオブジェクト（図５のサーバオ
ブジェクト１〜４）の負荷値が算出され、その負荷値に
対応した利用比率値がネームサーバ（図５のネームサー
バ５１Ａ）に通知される（図５の５１１）。要求者がネ
ームサーバ（図５のネームサーバ５１Ａ）にオブジェク
トリファレンスを要求したときに、ネームサーバ（図５
のネームサーバ５１Ａ）は利用比率値の大きいサーバオ
ブジェクト（例えば、図５のサーバオブジェクト４）の
オブジェクトリファレンスを優先的に返すが、典型的に
は大きい利用比率値はサーバオブジェクト（例えば、図
５のサーバオブジェクト４）での小さい負荷を意味する
ので、ネームサーバ（図５のネームサーバ５１Ａ）は、
要求者に対して負荷の小さいサーバオブジェクト（例え
ば図５のサーバオブジェクト４）のオブジェクトリファ
レンスを優先的に返していることになる。しかも、実際
のサーバオブジェクト（図５のサーバオブジェクト１〜
４）の負荷状況に応じて負荷値が定期的に算出され、対
応した利用比率値がネームサーバ（図５のネームサーバ
５１Ａ）に通知され登録されるため、その負荷値と利用
比率値は実際のサーバオブジェクト（図５のサーバオブ
ジェクト１〜４）の負荷状況をリアルタイムに反映す
る。従って、本発明を用いることで、実際のサーバオブ
ジェクト（図５のサーバオブジェクト１〜４）の負荷状
況を考慮しながら特定のサーバオブジェクトでの負荷の
偏りを防止し、個々の要求された処理の実行時間の増大
を防止することが可能になる。また、ＯＲＢＰ製品毎の
ＯＲＢのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒ
ａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の違いにより、モ
ニタオブジェクト（図５のモニタオブジェクト５５，５
７）はＯＲＢ毎に異なる実装のものが提供されるが、全
てのモニタオブジェクト（図５のモニタオブジェクト５
５，５７）が提供するインタフェースは同一である。さ
らに、前記のＩＩＯＰなどの分散オブジェクトプラット
フォーム間の標準通信プロトコルを用いることで、イン
タフェースとプロトコルを整合させることが可能とな
り、複数種類の分散オブジェクトプラットフォーム製品
を混在させた環境下において、サーバマネージャアプリ
ケーション（図５のサーバマネージャアプリケーション
５３Ａ）から全てのサーバオブジェクト（図５のサーバ
オブジェクト１〜４）に対して処理の実行を要求するこ
とが可能になる。これにより、サーバマネージャアプリ
ケーション（図５のサーバマネージャアプリケーション
５３Ａ）が、異なる分散オブジェクトプラットフォーム
上で動作する全てのサーバオブジェクト（図５のサーバ
オブジェクト１〜４）から性能データを収集することが
可能となる。従って、複数種類の分散オブジェクトプラ
ットフォーム製品を混在させた環境下において、個々の
サーバオブジェクト（図５のサーバオブジェクト１〜
４）の負荷制御を一元的に行い、サーバオブジェクト
（図５のサーバオブジェクト１〜４）での個々の要求さ
れた処理の実行時間の増大を防止することが可能にな
る。また、モニタオブジェクトの実装をサーバオブジェ
クトの実装から分離する（図５で、モニタオブジェクト
５５とサーバオブジェクト１と２、モニタオブジェクト
５７とサーバオブジェクト３と４）ことで、サーバオブ
ジェクト（図５のサーバオブジェクト１〜４）の実装に
影響を及ぼさずに分散オブジェクト性能管理機構を導入
でき、しかもモニタオブジェクト（図５のモニタオブジ
ェクト５５，５７）の実装への影響なしにサーバオブジ
ェクト（図５のサーバオブジェクト１〜４）の実装を変
更することが可能になる。
【００１３】
【発明の実施の形態】以下、本発明の実施例を、図面に
より詳細に説明する。図５は、本発明の一実施例を示す
分散オブジェクト性能管理機構の構成図である。モニタ
オブジェクト５５，５７は、自分と同一のサーバアプリ
ケーション内に存在するサーバオブジェクト（モニタオ
ブジェクト５５に対してサーバオブジェクト１と２、モ
ニタオブジェクト５７に対してサーバオブジェクト３と
４）がクライアントアプリケーションなどの要求者から
要求され実行した個々の処理について、その実行開始・
終了時刻、処理名、およびその処理を実行したサーバオ
ブジェクト名を性能データ格納部（図５の性能データ５
６，５８）に記録する。
より詳細に説明する。図５は、本発明の一実施例を示す
分散オブジェクト性能管理機構の構成図である。モニタ
オブジェクト５５，５７は、自分と同一のサーバアプリ
ケーション内に存在するサーバオブジェクト（モニタオ
ブジェクト５５に対してサーバオブジェクト１と２、モ
ニタオブジェクト５７に対してサーバオブジェクト３と
４）がクライアントアプリケーションなどの要求者から
要求され実行した個々の処理について、その実行開始・
終了時刻、処理名、およびその処理を実行したサーバオ
ブジェクト名を性能データ格納部（図５の性能データ５
６，５８）に記録する。
【００１４】ネームサーバ５１Ａは、０個以上のオブジ
ェクトグループの情報を格納する。各々のオブジェクト
グループには、そのオブジェクトグループ名、そのオブ
ジェクトグループに登録されている１つ以上のオブジェ
クトリファレンス、およびそれらの個々のオブジェクト
リファレンスに対応するサーバオブジェクトの利用比率
値が含まれる（図５の５１）。なお、１つのオブジェク
トグループに登録される個々のオブジェクトリファレン
スに対応するサーバオブジェクトは、全ての同一のイン
タフェースを提供する。
ェクトグループの情報を格納する。各々のオブジェクト
グループには、そのオブジェクトグループ名、そのオブ
ジェクトグループに登録されている１つ以上のオブジェ
クトリファレンス、およびそれらの個々のオブジェクト
リファレンスに対応するサーバオブジェクトの利用比率
値が含まれる（図５の５１）。なお、１つのオブジェク
トグループに登録される個々のオブジェクトリファレン
スに対応するサーバオブジェクトは、全ての同一のイン
タフェースを提供する。
【００１５】クライアントアプリケーション５４Ａは、
オブジェクトグループ名を指定して、ネームサーバ５１
Ａに／Ｄｅｐａｒｔｍｅｎｔ＿Ａ／Ｐｒｉｎｔｅｒ＿Ａ
オブジェクトグループに属するオブジェクトリファレン
スを要求する（図５の５０１）。ネームサーバ５１Ａ
は、そのオブジェクトグループに属する各々のオブジェ
クトリファレンスの利用比率値を調べ、それらの利用比
率値の相対的割合に応じてサーバオブジェクト２のオブ
ジェクトリファレンスを選定してクライアントアプリケ
ーション５４Ａに返す（図５の５０２）。
オブジェクトグループ名を指定して、ネームサーバ５１
Ａに／Ｄｅｐａｒｔｍｅｎｔ＿Ａ／Ｐｒｉｎｔｅｒ＿Ａ
オブジェクトグループに属するオブジェクトリファレン
スを要求する（図５の５０１）。ネームサーバ５１Ａ
は、そのオブジェクトグループに属する各々のオブジェ
クトリファレンスの利用比率値を調べ、それらの利用比
率値の相対的割合に応じてサーバオブジェクト２のオブ
ジェクトリファレンスを選定してクライアントアプリケ
ーション５４Ａに返す（図５の５０２）。
【００１６】図６は、本発明方式を用いたネームサーバ
の役割を説明するための適用例を示す図である。図５で
のネームサーバ５１が要求者に返すオブジェクトリファ
レンスを選定する方法を、図６を用いて説明する。図６
に示すように、サーバアプリケーション６８，６９，７
０の中でそれぞれサーバオブジェクト１，２，３が存在
し、それらのサーバオブジェクト１，２，３のオブジェ
クトリファレンス（ＯＲ１，ＯＲ２，ＯＲ３）が、ネー
ムサーバ中で同一オブジェクトグループに登録されてい
る。図６にあるように、サーバオブジェクト１，２，３
のオブジェクトリファレンスＯＲ１，ＯＲ２，ＯＲ３の
利用比率値がそれぞれ１，２，３で、６つのクライアン
トアプリケーション６１〜６６からオブジェクトリファ
レンスの要求があった場合（図６の６０１〜６０６）、
各々の要求に対して、オブジェクトリファレンスＯＲ
１，ＯＲ２，ＯＲ３を１：２：３の割合で選定し、それ
らの要求毎に選定されたオブジェクトリファレンスをク
ライアントアプリケーション６１〜６６に返す（図６の
６１１〜６１６）。
の役割を説明するための適用例を示す図である。図５で
のネームサーバ５１が要求者に返すオブジェクトリファ
レンスを選定する方法を、図６を用いて説明する。図６
に示すように、サーバアプリケーション６８，６９，７
０の中でそれぞれサーバオブジェクト１，２，３が存在
し、それらのサーバオブジェクト１，２，３のオブジェ
クトリファレンス（ＯＲ１，ＯＲ２，ＯＲ３）が、ネー
ムサーバ中で同一オブジェクトグループに登録されてい
る。図６にあるように、サーバオブジェクト１，２，３
のオブジェクトリファレンスＯＲ１，ＯＲ２，ＯＲ３の
利用比率値がそれぞれ１，２，３で、６つのクライアン
トアプリケーション６１〜６６からオブジェクトリファ
レンスの要求があった場合（図６の６０１〜６０６）、
各々の要求に対して、オブジェクトリファレンスＯＲ
１，ＯＲ２，ＯＲ３を１：２：３の割合で選定し、それ
らの要求毎に選定されたオブジェクトリファレンスをク
ライアントアプリケーション６１〜６６に返す（図６の
６１１〜６１６）。
【００１７】クライアントアプリケーション５４Ａがネ
ームサーバ５１Ａからサーバオブジェクト２のオブジェ
クトリファレンスを受け取ると（図５の５０２）、クラ
イアントアプリケーション５４Ａはサーバアプリケーシ
ョン５２Ａに処理要求を送る（図５の５０３）。この処
理要求は、先ずサーバアプリケーション５２Ａ内で動作
するインタセプタ１で受け付けられる。インタセプタ１
は、性能データ格納用の新たなエントリ（図５の５２）
をモニタオブジェクト５５に作成するよう要求し（図５
の５０４）、さらに要求された処理名、処理を実行する
サーバオブジェクトの識別子、および処理開始時刻をエ
ントリ（図５の５２）に記録するよう要求する（図５の
５０５）。その後、インタセプタ１は、要求者から受け
取った処理要求をサーバオブジェクトに渡す（図５の５
０６）。その要求された処理の実行を終了したサーバオ
ブジェクト２は、インタセプタ１に処理実行結果を返す
（図５の５０７）。インタセプタ１では、その処理結果
を受け取ると、先ほどモニタオブジェクト５５内に作成
させたエントリ（図５の５２）に、処理終了時刻を追加
して記録するように要求する（図５の５０８）。その
後、インタセプタ１は、その処理実行結果をクライアン
トアプリケーション５４Ａに返す（図５の５０９）。こ
のように、本発明方式では、モニタオブジェクト５５，
５７を図５のサーバオブジェクト１〜４に埋め込まず、
図５のサーバオブジェクト１〜４とは別個の独立したオ
ブジェクトとしてサーバアプリケーション５２Ａ内に設
け、モニタオブジェクト５５，５７に、そのモニタオブ
ジェクト自身と同一サーバアプリケーション内に存在す
るサーバオブジェクト（図５で、モニタオブジェクト５
５に対してサーバオブジェクト１と２，モニタオブジェ
クト５７に対してサーバオブジェクト３と４）の性能デ
ータをインタセプタ（図５で、モニタオブジェクト５５
に対してインタセプタ１、モニタオブジェクト５７に対
してインタセプタ２）と協調して収集・管理させる。
ームサーバ５１Ａからサーバオブジェクト２のオブジェ
クトリファレンスを受け取ると（図５の５０２）、クラ
イアントアプリケーション５４Ａはサーバアプリケーシ
ョン５２Ａに処理要求を送る（図５の５０３）。この処
理要求は、先ずサーバアプリケーション５２Ａ内で動作
するインタセプタ１で受け付けられる。インタセプタ１
は、性能データ格納用の新たなエントリ（図５の５２）
をモニタオブジェクト５５に作成するよう要求し（図５
の５０４）、さらに要求された処理名、処理を実行する
サーバオブジェクトの識別子、および処理開始時刻をエ
ントリ（図５の５２）に記録するよう要求する（図５の
５０５）。その後、インタセプタ１は、要求者から受け
取った処理要求をサーバオブジェクトに渡す（図５の５
０６）。その要求された処理の実行を終了したサーバオ
ブジェクト２は、インタセプタ１に処理実行結果を返す
（図５の５０７）。インタセプタ１では、その処理結果
を受け取ると、先ほどモニタオブジェクト５５内に作成
させたエントリ（図５の５２）に、処理終了時刻を追加
して記録するように要求する（図５の５０８）。その
後、インタセプタ１は、その処理実行結果をクライアン
トアプリケーション５４Ａに返す（図５の５０９）。こ
のように、本発明方式では、モニタオブジェクト５５，
５７を図５のサーバオブジェクト１〜４に埋め込まず、
図５のサーバオブジェクト１〜４とは別個の独立したオ
ブジェクトとしてサーバアプリケーション５２Ａ内に設
け、モニタオブジェクト５５，５７に、そのモニタオブ
ジェクト自身と同一サーバアプリケーション内に存在す
るサーバオブジェクト（図５で、モニタオブジェクト５
５に対してサーバオブジェクト１と２，モニタオブジェ
クト５７に対してサーバオブジェクト３と４）の性能デ
ータをインタセプタ（図５で、モニタオブジェクト５５
に対してインタセプタ１、モニタオブジェクト５７に対
してインタセプタ２）と協調して収集・管理させる。
【００１８】サーバマネージャアプリケーション５３Ａ
に含まれるサーバマネージャオブジェクト５Ａは、定期
的にモニタオブジェクト５５，５７から性能データを収
集し（図５の５１０，５１２）、それらモニタオブジェ
クトと同一のサーバアプリケーション（図５で、モニタ
オブジェクト５５に対してサーバアプリケーション５２
Ａ，モニタオブジェクト５７に対してサーバアプリケー
ション５９Ａ）に含まれるサーバオブジェクト（図５
で、モニタオブジェクト５５に対してサーバオブジェク
ト１と２、モニタオブジェクト５７に対してサーバオブ
ジェクト３と４）で実行した個々の処理について実行時
間を算出し、それを基にさらにサーバの負荷値を算出す
る。サーバオブジェクトの負荷値は、サーバオブジェク
トで実行した個々の処理の平均実行時間と、実行時間が
予め処理内容毎に指定された許容実行時間を超えた処理
の回数の２つのパラメータを含む。さらに、サーバマネ
ージャオブジェクト５Ａは、その負荷値を基に、予め設
定された負荷値・利用比率値対応テーブル（図５の５
３）を参照して、サーバオブジェクト１〜４の利用比率
値を調べ、各々のサーバオブジェクトの利用比率値をネ
ームサーバ５１Ａに通知する（図５の５１１）。これ以
後、段落番号〔００１４〕以降の手続きを通してクライ
アントアプリケーション５４Ａなどのオブジェクトリフ
ァレンスの要求者に対して、ネームサーバ５１Ａから返
されるオブジェクトリファレンスは、新たに設定された
利用比率値を用いて選定される。この利用比率値は、サ
ーバオブジェクト１〜４の負荷値の変動に応じて定期的
に更新される。なお、サーバマネージャオブジェクト５
Ａの実装は、そのサーバマネージャオブジェクト５Ａを
動作させる分散オブジェクトプラットフォームにより異
なるが、全てのサーバマネージャオブジェクトのインタ
フェースは同一である。
に含まれるサーバマネージャオブジェクト５Ａは、定期
的にモニタオブジェクト５５，５７から性能データを収
集し（図５の５１０，５１２）、それらモニタオブジェ
クトと同一のサーバアプリケーション（図５で、モニタ
オブジェクト５５に対してサーバアプリケーション５２
Ａ，モニタオブジェクト５７に対してサーバアプリケー
ション５９Ａ）に含まれるサーバオブジェクト（図５
で、モニタオブジェクト５５に対してサーバオブジェク
ト１と２、モニタオブジェクト５７に対してサーバオブ
ジェクト３と４）で実行した個々の処理について実行時
間を算出し、それを基にさらにサーバの負荷値を算出す
る。サーバオブジェクトの負荷値は、サーバオブジェク
トで実行した個々の処理の平均実行時間と、実行時間が
予め処理内容毎に指定された許容実行時間を超えた処理
の回数の２つのパラメータを含む。さらに、サーバマネ
ージャオブジェクト５Ａは、その負荷値を基に、予め設
定された負荷値・利用比率値対応テーブル（図５の５
３）を参照して、サーバオブジェクト１〜４の利用比率
値を調べ、各々のサーバオブジェクトの利用比率値をネ
ームサーバ５１Ａに通知する（図５の５１１）。これ以
後、段落番号〔００１４〕以降の手続きを通してクライ
アントアプリケーション５４Ａなどのオブジェクトリフ
ァレンスの要求者に対して、ネームサーバ５１Ａから返
されるオブジェクトリファレンスは、新たに設定された
利用比率値を用いて選定される。この利用比率値は、サ
ーバオブジェクト１〜４の負荷値の変動に応じて定期的
に更新される。なお、サーバマネージャオブジェクト５
Ａの実装は、そのサーバマネージャオブジェクト５Ａを
動作させる分散オブジェクトプラットフォームにより異
なるが、全てのサーバマネージャオブジェクトのインタ
フェースは同一である。
【００１９】図７は、本発明の概略的な実行フローチャ
ートであり、図８は、図７におけるサービス実行フェー
ズの部分の実行フローチャートであり、図９は、図７に
おける利用者比率更新フェーズの部分の実行フローチャ
ートである。先ず、図７に示すように、サーバオブジェ
クト７４の負荷の変動に伴って、ネームサーバ７２に登
録された利用比率値を更新するための利用比率値更新フ
ェーズが定期的に実行され、各々の利用比率値更新フェ
ーズの間に、クライアントアプリケーション７１からの
オブジェクトリファレンス要求を処理する０回以上のサ
ービス実行フェーズが実行される。
ートであり、図８は、図７におけるサービス実行フェー
ズの部分の実行フローチャートであり、図９は、図７に
おける利用者比率更新フェーズの部分の実行フローチャ
ートである。先ず、図７に示すように、サーバオブジェ
クト７４の負荷の変動に伴って、ネームサーバ７２に登
録された利用比率値を更新するための利用比率値更新フ
ェーズが定期的に実行され、各々の利用比率値更新フェ
ーズの間に、クライアントアプリケーション７１からの
オブジェクトリファレンス要求を処理する０回以上のサ
ービス実行フェーズが実行される。
【００２０】図８のサービス実行フェーズにおいては、
クライアントアプリケーション７１からネームサーバ７
２にオブジェクトリファレンス要求があると、ネームサ
ーバ７２は、指定されたオブジェクトグループに登録さ
れた各々のオブジェクトリファレンスの利用比率値を参
照してオブジェクトリファレンスの選定を行い（図８の
８０１）、クライアントアプリケーション７１に返す。
次に、そのオブジェクトリファレンスのデータを用い
て、クライアントアプリケーション７１はサーバアプリ
ケーション７６に処理要求を送る。この処理要求は、先
ずサーバアプリケーション７６内で動作しているインタ
セプタ７３により受け取られる。インタセプタ７３は処
理要求を受けると、モニタオブジェクト７５に性能デー
タ格納用の新たなエントリを作成するよう要求し、さら
にクライアントアプリケーション７１から要求された処
理名、処理を実行するサーバオブジェクトの識別子、お
よび処理開始時刻をエントリに記録するよう要求する。
これにより、モニタオブジェクトにて新規のエントリが
作成され（図８の８０２）、そのエントリにデータが記
録される。次に、インタセプタ７３は、サーバオブジェ
クト７４に処理要求を渡し、処理実行結果をサーバオブ
ジェクト７４から受け取る。そして、インタセプタ７３
は、先に作成したエントリに処理終了時刻を記録するよ
うに、モニタオブジェクト７５に要求する。その後に、
インタセプタ７３はクライアントアプリケーション７１
に処理結果を返す。
クライアントアプリケーション７１からネームサーバ７
２にオブジェクトリファレンス要求があると、ネームサ
ーバ７２は、指定されたオブジェクトグループに登録さ
れた各々のオブジェクトリファレンスの利用比率値を参
照してオブジェクトリファレンスの選定を行い（図８の
８０１）、クライアントアプリケーション７１に返す。
次に、そのオブジェクトリファレンスのデータを用い
て、クライアントアプリケーション７１はサーバアプリ
ケーション７６に処理要求を送る。この処理要求は、先
ずサーバアプリケーション７６内で動作しているインタ
セプタ７３により受け取られる。インタセプタ７３は処
理要求を受けると、モニタオブジェクト７５に性能デー
タ格納用の新たなエントリを作成するよう要求し、さら
にクライアントアプリケーション７１から要求された処
理名、処理を実行するサーバオブジェクトの識別子、お
よび処理開始時刻をエントリに記録するよう要求する。
これにより、モニタオブジェクトにて新規のエントリが
作成され（図８の８０２）、そのエントリにデータが記
録される。次に、インタセプタ７３は、サーバオブジェ
クト７４に処理要求を渡し、処理実行結果をサーバオブ
ジェクト７４から受け取る。そして、インタセプタ７３
は、先に作成したエントリに処理終了時刻を記録するよ
うに、モニタオブジェクト７５に要求する。その後に、
インタセプタ７３はクライアントアプリケーション７１
に処理結果を返す。
【００２１】図９の利用比率値更新フェーズにおいて
は、サーバマネージャアプリケーション７７のサーバマ
ネージャオブジェクト７８が、定期的にモニタオブジェ
クト７５からサーバオブジェクト７４の性能データを収
集し、収集した性能データからサーバオブジェクト７４
の負荷値を算出し、その負荷値に対応する利用比率値を
調べ、得られた利用比率値をネームサーバ７２に通知す
る。ネームサーバ７２では、通知された利用比率値をサ
ーバオブジェクト７４に対応するオブジェクトリファレ
ンスの利用比率値として、更新登録する。これ以後は、
ネームサーバ７２から要求者に返されるオブジェクトリ
ファレンスは、新たに設定された利用比率値を用いて選
定される。
は、サーバマネージャアプリケーション７７のサーバマ
ネージャオブジェクト７８が、定期的にモニタオブジェ
クト７５からサーバオブジェクト７４の性能データを収
集し、収集した性能データからサーバオブジェクト７４
の負荷値を算出し、その負荷値に対応する利用比率値を
調べ、得られた利用比率値をネームサーバ７２に通知す
る。ネームサーバ７２では、通知された利用比率値をサ
ーバオブジェクト７４に対応するオブジェクトリファレ
ンスの利用比率値として、更新登録する。これ以後は、
ネームサーバ７２から要求者に返されるオブジェクトリ
ファレンスは、新たに設定された利用比率値を用いて選
定される。
【００２２】このように、本発明においては、サーバオ
ブジェクトの負荷の変動に伴いリアルタイムに各々のサ
ーバオブジェクトの負荷値が算出され、その負荷値に対
応した利用比率値がネームサーバに通知される。要求者
がネームサーバにオブジェクトリファレンスを要求した
ときに、ネームサーバは、利用比率値の大きい、すなわ
ち小さい負荷のサーバオブジェクトのオブジェクトリフ
ァレンスを優先的に返す。しかも、実際のサーバオブジ
ェクトの負荷状況に応じて負荷値が定期的に算出され、
対応した利用比率値がネームサーバに通知され登録され
るため、その負荷値と利用比率値は実際のサーバオブジ
ェクトの負荷状況をリアルタイムに反映する。従って、
実際のサーバオブジェクトの負荷状況を考慮しながら特
定のサーバオブジェクトでの負荷の偏りを防止し、個々
の要求された処理の実行時間の増大を防止することが可
能になる。また、モニタオブジェクトは分散オブジェク
トプラットフォーム対応に異なる実装のものが提供され
るが、全てのモニタオブジェクトが提供するインタフェ
ースは同一である。さらに、ＩＩＯＰなどの分散オブジ
ェクトプラットフォーム間の標準通信プロトコルを用い
ることで、インタフェースとプロトコルを整合させるこ
とが可能となり、複数種類の分散オブジェクトプラット
フォーム製品を混在させた環境下において、サーバマネ
ージャアプリケーションから全てのサーバオブジェクト
に対して処理の実行を要求することが可能となる。これ
により、サーバマネージャアプリケーションが、異なる
分散オブジェクトプラットフォーム上で動作する全ての
サーバオブジェクトから性能データを収集することが可
能となる。従って、複数種類の分散オブジェクトプラッ
トフォーム製品を混在させた環境下において、個々のサ
ーバオブジェクトの負荷制御を一元的に行い、サーバオ
ブジェクトでの個々の要求された処理の実行時間の増大
を防止することが可能になる。また、モニタオブジェク
トの実装をサーバオブジェクトの実装から分離すること
で、サーバオブジェクトの実装に影響を及ぼさずに分散
オブジェクト性能管理機構を導入でき、しかもモニタオ
ブジェクトの実装への影響なしにサーバオブジェクトの
実装を変更することが可能になる。
ブジェクトの負荷の変動に伴いリアルタイムに各々のサ
ーバオブジェクトの負荷値が算出され、その負荷値に対
応した利用比率値がネームサーバに通知される。要求者
がネームサーバにオブジェクトリファレンスを要求した
ときに、ネームサーバは、利用比率値の大きい、すなわ
ち小さい負荷のサーバオブジェクトのオブジェクトリフ
ァレンスを優先的に返す。しかも、実際のサーバオブジ
ェクトの負荷状況に応じて負荷値が定期的に算出され、
対応した利用比率値がネームサーバに通知され登録され
るため、その負荷値と利用比率値は実際のサーバオブジ
ェクトの負荷状況をリアルタイムに反映する。従って、
実際のサーバオブジェクトの負荷状況を考慮しながら特
定のサーバオブジェクトでの負荷の偏りを防止し、個々
の要求された処理の実行時間の増大を防止することが可
能になる。また、モニタオブジェクトは分散オブジェク
トプラットフォーム対応に異なる実装のものが提供され
るが、全てのモニタオブジェクトが提供するインタフェ
ースは同一である。さらに、ＩＩＯＰなどの分散オブジ
ェクトプラットフォーム間の標準通信プロトコルを用い
ることで、インタフェースとプロトコルを整合させるこ
とが可能となり、複数種類の分散オブジェクトプラット
フォーム製品を混在させた環境下において、サーバマネ
ージャアプリケーションから全てのサーバオブジェクト
に対して処理の実行を要求することが可能となる。これ
により、サーバマネージャアプリケーションが、異なる
分散オブジェクトプラットフォーム上で動作する全ての
サーバオブジェクトから性能データを収集することが可
能となる。従って、複数種類の分散オブジェクトプラッ
トフォーム製品を混在させた環境下において、個々のサ
ーバオブジェクトの負荷制御を一元的に行い、サーバオ
ブジェクトでの個々の要求された処理の実行時間の増大
を防止することが可能になる。また、モニタオブジェク
トの実装をサーバオブジェクトの実装から分離すること
で、サーバオブジェクトの実装に影響を及ぼさずに分散
オブジェクト性能管理機構を導入でき、しかもモニタオ
ブジェクトの実装への影響なしにサーバオブジェクトの
実装を変更することが可能になる。
【００２３】
【発明の効果】以上説明したように、本発明によれば、
複数の分散オブジェクトプラットフォーム製品を導入し
た環境下でも、全ての本機構の構成要素間で通信が可能
になる。従って、異なる製品を導入した環境下でも、サ
ーバマネージャオブジェクトが、定期的かつ一元的にモ
ニタオブジェクトからサーバオブジェクトの性能データ
を収集し、個々のサーバオブジェクトの負荷値を算出
し、その負荷値に応じた新しい利用比率値をネームサー
バに通知し更新させることが可能となる。これにより、
必要に応じてサーバオブジェクト数を調整しつつ、サー
バオブジェクトの負荷の変動にリアルタイムに対応し
て、それらのサーバオブジェクトの負荷制御および負荷
分散を行うことが可能となる。従って、特定のサーバオ
ブジェクト間での負荷の偏りを防ぎ、個々の要求された
処理の実行時間増大を防ぐことが可能となる。また、サ
ーバオブジェクトの実装に影響を及ぼさずに分散オブジ
ェクト性能管理機構を導入でき、しかもモニタオブジェ
クトの実装への影響なしにサーバオブジェクトの実装を
変更することが可能となる。
複数の分散オブジェクトプラットフォーム製品を導入し
た環境下でも、全ての本機構の構成要素間で通信が可能
になる。従って、異なる製品を導入した環境下でも、サ
ーバマネージャオブジェクトが、定期的かつ一元的にモ
ニタオブジェクトからサーバオブジェクトの性能データ
を収集し、個々のサーバオブジェクトの負荷値を算出
し、その負荷値に応じた新しい利用比率値をネームサー
バに通知し更新させることが可能となる。これにより、
必要に応じてサーバオブジェクト数を調整しつつ、サー
バオブジェクトの負荷の変動にリアルタイムに対応し
て、それらのサーバオブジェクトの負荷制御および負荷
分散を行うことが可能となる。従って、特定のサーバオ
ブジェクト間での負荷の偏りを防ぎ、個々の要求された
処理の実行時間増大を防ぐことが可能となる。また、サ
ーバオブジェクトの実装に影響を及ぼさずに分散オブジ
ェクト性能管理機構を導入でき、しかもモニタオブジェ
クトの実装への影響なしにサーバオブジェクトの実装を
変更することが可能となる。
【図１】分散オブジェクトプラットフォームを導入した
環境でのサービスアプリケーションの構成と運用形態を
示す図である。
環境でのサービスアプリケーションの構成と運用形態を
示す図である。
【図２】サーバオブジェクト負荷制御のための従来方式
として、リクエストキューを用いた方式を示す図であ
る。
として、リクエストキューを用いた方式を示す図であ
る。
【図３】従来における分散オブジェクトプラットフォー
ムで用いられるネームサーバを説明する図である。
ムで用いられるネームサーバを説明する図である。
【図４】従来の分散オブジェクトプラットフォームで用
いられているネームサーバのうちで、オブジェクトグル
ープをサポートするものを説明する図である。
いられているネームサーバのうちで、オブジェクトグル
ープをサポートするものを説明する図である。
【図５】本発明の一実施例を示す分散オブジェクト性能
管理機構の構成図である。
管理機構の構成図である。
【図６】本発明の中でのネームサーバの部分の役割を説
明するための実施例を示す図である。
明するための実施例を示す図である。
【図７】本発明における概略的な全体の実行フローを示
す図である。
す図である。
【図８】図７におけるサービス実行フェーズの部分の実
行フローチャートである。
行フローチャートである。
【図９】図７における利用者比率更新フェーズの部分の
実行フローチャートである。
実行フローチャートである。
４０９，４１０…オブジェクトリファレンス（群）、５
１…オブジェクトグループ情報、５２…新規エントリ、
５３…負荷値・利用比率値対応表、７１…クライアント
アプリケーション、７２…ネームサーバ、７３…インタ
セプタ、７４…サーバオブジェクト、７５…モニタオブ
ジェクト、７６…サーバアプリケーション、７７…サー
バマネージャアプリケーション、７８…サーバマネージ
ャオブジェクト。
１…オブジェクトグループ情報、５２…新規エントリ、
５３…負荷値・利用比率値対応表、７１…クライアント
アプリケーション、７２…ネームサーバ、７３…インタ
セプタ、７４…サーバオブジェクト、７５…モニタオブ
ジェクト、７６…サーバアプリケーション、７７…サー
バマネージャアプリケーション、７８…サーバマネージ
ャオブジェクト。
Claims (6)
- 【請求項１】 処理の実行を要求するクライアントアプ
リケーションと、要求された処理を実行し、必要に応じ
て上記クライアントアプリケーションに処理結果を返す
１以上のサーバオブジェクトを含むサーバアプリケーシ
ョンのライフサイクルを管理し、また、クライアントア
プリケーションとサーバオブジェクトの間の通信、同一
サーバアプリケーション内のサーバオブジェクト間の通
信、および別個のサーバアプリケーション内に存在する
サーバオブジェクト間の通信を実行する役割を持つ分散
オブジェクトプラットフォームを導入した環境におい
て、 サーバアプリケーション内に設けられ、同一のサーバア
プリケーション内で動作する各々のサーバオブジェクト
がクライアントアプリケーションあるいは他のサーバオ
ブジェクトから要求された処理を実行するときに、その
処理の開始時刻と終了時間、処理名、およびその処理を
実行したサーバオブジェクトの名前を含む性能データを
取得し保持するモニタオブジェクトを備えることを特徴
とする分散オブジェクト性能管理機構。 - 【請求項２】 上記モニタオブジェクトに関して、複数
種類の分散オブジェクトプラットフォームを導入した環
境において、 異種の分散オブジェクトプラットフォーム上で動作する
サーバアプリケーション内のモニタオブジェクトに同一
のインタフェースを持たせることで、該モニタオブジェ
クトが動作するサーバアプリケーション内で動作するサ
ーバオブジェクトに関する上記性能データを、そのモニ
タオブジェクトを動作させる分散オブジェクトプラット
フォームと同一のプラットフォーム上で動作するクライ
アントアプリケーションあるいはサーバオブジェクトの
みならず、異種のプラットフォームで動作するクライア
ントアプリケーションあるいはサーバオブジェクトに対
しても上記性能データの提供を可能とし、 複数種類の分散オブジェクトプラットフォームを導入し
た場合に、一元的な性能データの収集・管理を行うこと
を特徴とする請求項１に記載の分散オブジェクト性能管
理機構。 - 【請求項３】 クライアントアプリケーションあるいは
サーバオブジェクトから所望のサーバオブジェクトへ処
理要求を届けるときに分散オブジェクトプラットフォー
ムが必要とするサーバオブジェクトのアドレス情報など
を記したオブジェクトリファレンスを、同一機能を提供
する個々のサーバオブジェクトの分について、一つのオ
ブジェクトグループに登録でき、 かつオブジェクトグループの名前を入力引数として、オ
ブジェクトリファレンスの要求者としてのクライアント
アプリケーションあるいはサーバオブジェクトから所望
の機能を提供するサーバオブジェクトのオブジェクトリ
ファレンスを要求されたときに、指定された名前のオブ
ジェクグループに登録されている個々のオブジェクトリ
ファレンスに対して設定され、サーバオブジェクトの負
荷変動に対応して定期的に更新される利用比率値を参照
し、それら個々のオブジェクトリファレンスの利用比率
値の相対的割合により、それらの中からオブジェクトリ
ファレンスを決定して要求者に返す機能を持つネームサ
ーバを設け、 該ネームサーバを用いることでサーバオブジェクトの負
荷の変動にリアルタイムに追従してサーバオブジェクト
の負荷制御を行うことを特徴とする分散オブジェクト性
能管理機構。 - 【請求項４】 上記ネームサーバを用いる環境におい
て、上記モニタオブジェクトからサーバオブジェクトに
関する上記性能データを定期的に収集し、収集した性能
データから各々のサーバオブジェクトの負荷値を算出
し、自分の保持する負荷値・利用比率値対応テーブルを
参照して、それらの負荷値から各サーバの利分比率値を
調べ、得られた各サーバ毎の利用比率値をネームサーバ
に通知し、利用比率値データを更新させるサーバマネー
ジャオブジェクトを用いることを特徴とする請求項３に
記載の分散オブジェクト性能管理機構。 - 【請求項５】 上記ネームサーバを用いる環境におい
て、指定された名前のオブジェクトグループに登録され
ているオブジェクトリファレンスに対応したサーバオブ
ジェクト全てが過負荷あるいは小負荷になったときに
は、必要に応じてサーバオブジェクト数を増加または減
少させることで、サーバオブジェクトの負荷の変動にリ
アルタイムに追従してサーバオブジェクトの負荷制御と
サーバを動作させるためのＣＰＵやメモリなどのリソー
スの制御を行うことを特徴とする請求項３に記載の分散
オブジェクト性能管理機構。 - 【請求項６】 前記モニタオブジェクトが、各々のサー
バオブジェクトに埋め込まれることなく、サーバオブジ
ェクトとは別個の独立したオブジェクトとしてサーバア
プリケーション内に設けられ、 モニタオブジェクトが、該モニタオブジェクトと同一サ
ーバアプリケーション内に存在し処理要求者とサーバオ
ブジェクトとの間の通信を仲介するインタセプタと協調
して、該モニタオブジェクトと同一サーバアプリケーシ
ョン内に存在するサーバオブジェクトに関する前記性能
データを収集・保持することを特徴とする請求項１また
は２に記載の分散オブジェクト性能管理機構。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP11208547A JP2001034583A (ja) | 1999-07-23 | 1999-07-23 | 分散オブジェクト性能管理機構 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP11208547A JP2001034583A (ja) | 1999-07-23 | 1999-07-23 | 分散オブジェクト性能管理機構 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2001034583A true JP2001034583A (ja) | 2001-02-09 |
Family
ID=16558001
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP11208547A Pending JP2001034583A (ja) | 1999-07-23 | 1999-07-23 | 分散オブジェクト性能管理機構 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2001034583A (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002091937A (ja) * | 2000-07-27 | 2002-03-29 | Hewlett Packard Co <Hp> | スペアサーバを自動でアクティブにするサーバ |
| JP2005258757A (ja) * | 2004-03-11 | 2005-09-22 | Nec Corp | アプリケーションサービス管理システムおよび方法とプログラム |
| JP2005267547A (ja) * | 2004-03-22 | 2005-09-29 | Nec Corp | 分散オブジェクトシステム及びサーバ |
| JP2006515734A (ja) * | 2003-01-31 | 2006-06-01 | モトローラ・インコーポレイテッド | インターネット・プロトコル・ベースの通信システムにおけるリソース・プーリング |
| JP2007264734A (ja) * | 2006-03-27 | 2007-10-11 | Fujitsu Ltd | チューニング支援装置、チューニング支援プログラム、チューニング支援プログラムを記録したコンピュータ読み取り可能な記録媒体およびチューニング支援方法 |
| US7581211B2 (en) | 2004-07-14 | 2009-08-25 | International Business Machines Corporation | Method and apparatus for on demand debugging, tracing, and logging of applications |
-
1999
- 1999-07-23 JP JP11208547A patent/JP2001034583A/ja active Pending
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002091937A (ja) * | 2000-07-27 | 2002-03-29 | Hewlett Packard Co <Hp> | スペアサーバを自動でアクティブにするサーバ |
| JP2006515734A (ja) * | 2003-01-31 | 2006-06-01 | モトローラ・インコーポレイテッド | インターネット・プロトコル・ベースの通信システムにおけるリソース・プーリング |
| JP2005258757A (ja) * | 2004-03-11 | 2005-09-22 | Nec Corp | アプリケーションサービス管理システムおよび方法とプログラム |
| JP2005267547A (ja) * | 2004-03-22 | 2005-09-29 | Nec Corp | 分散オブジェクトシステム及びサーバ |
| US7581211B2 (en) | 2004-07-14 | 2009-08-25 | International Business Machines Corporation | Method and apparatus for on demand debugging, tracing, and logging of applications |
| JP2007264734A (ja) * | 2006-03-27 | 2007-10-11 | Fujitsu Ltd | チューニング支援装置、チューニング支援プログラム、チューニング支援プログラムを記録したコンピュータ読み取り可能な記録媒体およびチューニング支援方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4294879B2 (ja) | サービスレベル制御機構を有するトランザクション処理システム及びそのためのプログラム | |
| US7660887B2 (en) | Systems and methods for providing dynamic quality of service for a distributed system | |
| EP1212680B1 (en) | Graceful distribution in application server load balancing | |
| US6393458B1 (en) | Method and apparatus for load balancing in a distributed object architecture | |
| US7827217B2 (en) | Method and system for a grid-enabled virtual machine with movable objects | |
| Zhou et al. | Utopia: a load sharing facility for large, heterogeneous distributed computer systems | |
| US7287179B2 (en) | Autonomic failover of grid-based services | |
| US6845503B1 (en) | System and method for enabling atomic class loading in an application server environment | |
| US6327622B1 (en) | Load balancing in a network environment | |
| US8140674B2 (en) | Autonomic service routing using observed resource requirement for self-optimization | |
| US8117641B2 (en) | Control device and control method for information system | |
| US20050160424A1 (en) | Method and system for grid-enabled virtual machines with distributed management of applications | |
| US6470346B2 (en) | Remote computation framework | |
| US20050034130A1 (en) | Balancing workload of a grid computing environment | |
| WO1993020511A1 (en) | An integrated remote execution system for a heterogenous computer network environment | |
| JPH04230567A (ja) | 計算システムのための分散型構成プロフィル | |
| Elmroth et al. | An interoperable, standards-based Grid resource broker and job submission service | |
| US6418517B1 (en) | Optimized function execution for a multiprocessor computer system | |
| WO2000010084A2 (en) | Object load balancing | |
| US20050160135A1 (en) | Method and system for managing programs for distributed processing systems | |
| JP2001034583A (ja) | 分散オブジェクト性能管理機構 | |
| Barth et al. | Load distribution in a CORBA environment | |
| Khanli et al. | Grid-JQA a new architecture for qos-guaranteed grid computing system | |
| JP2001117887A (ja) | 分散型アプリケーションサーバシステム，サービス方法および記録媒体 | |
| Andrade et al. | The Tuxedo tm system: An open on-line transaction processing environment |