米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> 計算機;電気通信 -> 日本電信電話株式会社

発明の名称 分散オブジェクト性能管理機構
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2001−34583(P2001−34583A)
公開日 平成13年2月9日(2001.2.9)
出願番号 特願平11−208547
出願日 平成11年7月23日(1999.7.23)
代理人 【識別番号】100077274
【弁理士】
【氏名又は名称】磯村 雅俊 (外1名)
【テーマコード(参考)】
5B045
5B076
【Fターム(参考)】
5B045 AA00 GG01 GG02 
5B076 EC10
発明者 田中 博樹
要約 目的


構成
特許請求の範囲
【請求項1】 処理の実行を要求するクライアントアプリケーションと、要求された処理を実行し、必要に応じて上記クライアントアプリケーションに処理結果を返す1以上のサーバオブジェクトを含むサーバアプリケーションのライフサイクルを管理し、また、クライアントアプリケーションとサーバオブジェクトの間の通信、同一サーバアプリケーション内のサーバオブジェクト間の通信、および別個のサーバアプリケーション内に存在するサーバオブジェクト間の通信を実行する役割を持つ分散オブジェクトプラットフォームを導入した環境において、サーバアプリケーション内に設けられ、同一のサーバアプリケーション内で動作する各々のサーバオブジェクトがクライアントアプリケーションあるいは他のサーバオブジェクトから要求された処理を実行するときに、その処理の開始時刻と終了時間、処理名、およびその処理を実行したサーバオブジェクトの名前を含む性能データを取得し保持するモニタオブジェクトを備えることを特徴とする分散オブジェクト性能管理機構。
【請求項2】 上記モニタオブジェクトに関して、複数種類の分散オブジェクトプラットフォームを導入した環境において、異種の分散オブジェクトプラットフォーム上で動作するサーバアプリケーション内のモニタオブジェクトに同一のインタフェースを持たせることで、該モニタオブジェクトが動作するサーバアプリケーション内で動作するサーバオブジェクトに関する上記性能データを、そのモニタオブジェクトを動作させる分散オブジェクトプラットフォームと同一のプラットフォーム上で動作するクライアントアプリケーションあるいはサーバオブジェクトのみならず、異種のプラットフォームで動作するクライアントアプリケーションあるいはサーバオブジェクトに対しても上記性能データの提供を可能とし、複数種類の分散オブジェクトプラットフォームを導入した場合に、一元的な性能データの収集・管理を行うことを特徴とする請求項1に記載の分散オブジェクト性能管理機構。
【請求項3】 クライアントアプリケーションあるいはサーバオブジェクトから所望のサーバオブジェクトへ処理要求を届けるときに分散オブジェクトプラットフォームが必要とするサーバオブジェクトのアドレス情報などを記したオブジェクトリファレンスを、同一機能を提供する個々のサーバオブジェクトの分について、一つのオブジェクトグループに登録でき、かつオブジェクトグループの名前を入力引数として、オブジェクトリファレンスの要求者としてのクライアントアプリケーションあるいはサーバオブジェクトから所望の機能を提供するサーバオブジェクトのオブジェクトリファレンスを要求されたときに、指定された名前のオブジェクグループに登録されている個々のオブジェクトリファレンスに対して設定され、サーバオブジェクトの負荷変動に対応して定期的に更新される利用比率値を参照し、それら個々のオブジェクトリファレンスの利用比率値の相対的割合により、それらの中からオブジェクトリファレンスを決定して要求者に返す機能を持つネームサーバを設け、該ネームサーバを用いることでサーバオブジェクトの負荷の変動にリアルタイムに追従してサーバオブジェクトの負荷制御を行うことを特徴とする分散オブジェクト性能管理機構。
【請求項4】 上記ネームサーバを用いる環境において、上記モニタオブジェクトからサーバオブジェクトに関する上記性能データを定期的に収集し、収集した性能データから各々のサーバオブジェクトの負荷値を算出し、自分の保持する負荷値・利用比率値対応テーブルを参照して、それらの負荷値から各サーバの利分比率値を調べ、得られた各サーバ毎の利用比率値をネームサーバに通知し、利用比率値データを更新させるサーバマネージャオブジェクトを用いることを特徴とする請求項3に記載の分散オブジェクト性能管理機構。
【請求項5】 上記ネームサーバを用いる環境において、指定された名前のオブジェクトグループに登録されているオブジェクトリファレンスに対応したサーバオブジェクト全てが過負荷あるいは小負荷になったときには、必要に応じてサーバオブジェクト数を増加または減少させることで、サーバオブジェクトの負荷の変動にリアルタイムに追従してサーバオブジェクトの負荷制御とサーバを動作させるためのCPUやメモリなどのリソースの制御を行うことを特徴とする請求項3に記載の分散オブジェクト性能管理機構。
【請求項6】 前記モニタオブジェクトが、各々のサーバオブジェクトに埋め込まれることなく、サーバオブジェクトとは別個の独立したオブジェクトとしてサーバアプリケーション内に設けられ、モニタオブジェクトが、該モニタオブジェクトと同一サーバアプリケーション内に存在し処理要求者とサーバオブジェクトとの間の通信を仲介するインタセプタと協調して、該モニタオブジェクトと同一サーバアプリケーション内に存在するサーバオブジェクトに関する前記性能データを収集・保持することを特徴とする請求項1または2に記載の分散オブジェクト性能管理機構。
発明の詳細な説明
【0001】
【発明の属する技術分野】本発明は、情報通信サービスや通信網管理サービス(以下、単にサービスと呼ぶ)の分野において、処理の実行を要求するクライアントアプリケーションと、要求された処理を実行し必要に応じて上記クライアントアプリケーションに処理結果を返す1以上のサーバオブジェクトを含むサーバアプリケーションのライフサイクルを管理し、また、クライアントアプリケーションとサーバオブジェクトの間の通信、同一のサーバアプリケーション内のサーバオブジェクトの間の通信、および別個のサーバアプリケーション内に存在するモニタオブジェクト間の通信を実行する分散オブジェクトプラットフォーム技術に関し、特に、アプリケーションソフトウェアを構成する個々の分散オブジェクトを適切な性能・負荷の下で動作させる分散オブジェクト性能管理機構に関するものである。
【0002】
【従来の技術】分散オブジェクトプラットフォームの業界標準仕様であるCORBA(CommonObject Request Broker Architecture)(例えば、Object Management Group,“The Common Object Request Broker. Architecture and Specification",Rev.2,3,ftp://ftp.omg.org/pub/docs/formal/99-12-01.pdf参照)に代表される分散オブジェクトプラットフォームは、IDL(Interface Definition Language)で記載されたインタフェース定義からオブジェクト間通信用のソースコードを生成するIDLコンパイラにより分散アプリケーションの効率的な開発を支援し、また、IIOP(Internet Inter−ORB Protocol)に代表されるORB(ObjectRequest Broker)間の業界標準通信プロトコルを提供することで、複数サービスの連携動作などで要求される分散アプリケーション間の相互運用を支援する。ここで、分散オブジェクトプラットフォームとは、処理の実行を要求するクライアントアプリケーションと、要求された処理を実行し、必要に応じて上記クライアントアプリケーションに処理結果を返す1以上のサーバオブジェクトを含むサーバアプリケーションのライフサイクルを管理し、また、クライアントアプリケーションとサーバオブジェクトの間の通信、同一のサーバアプリケーション内のサーバオブジェクトの間の通信、および別個のサーバアプリケーション内に存在するサーバオブジェクト間の通信を実行するソフトウェアおよびハードウェアを指すものである。また、ORBは、オペレーティングシステム上で動作する、分散オブジェクトプラットフォームの根幹を成すソフトウェアで、クライアントアプリケーションから発行された処理要求を、その処理を実行可能なサーバアプリケーションに届けて実行させ、実行結果をサーバアプリケーションからクライアントアプリケーションに届ける機能を有する。
【0003】図1は、サービスアプリケーションの構成と運用形態を示す図である。図1に示すように、サービスのアプリケーション(図1のサービスアプリケーション31)は、そのサービスを構成する機能処理の実行を要求するクライアントアプリケーション(図1のクライアントアプリケーション11)と、要求された処理を実行し、クライアントに処理結果を返す一つ以上のサーバアプリケーション(図1のサーバアプリケーション12,13)からなる。サーバアプリケーション(図1のサーバアプリケーション12,13)は、0個以上のインタセプタ(図1のインタセプタ1,2)と1つ以上のサーバオブジェクト(図1のサーバオブジェクト1〜3,4〜5)を内包する。サーバオブジェクト(図1のサーバオブジェクト3)は、クライアントアプリケーション(図1のクライアントアプリケーション11)、他のサーバアプリケーション内のサーバオブジェクト(図1のサーバオブジェクト5)、あるいは同一サーバアプリケーション内の他のサーバオブジェクトから要求された処理を実行して、その実行結果を要求者に返す。サービスのアプリケーション(図1のサービスアプリケーション31)は、クライアントアプリケーション(図1のクライアントアプリケーション11)とサーバアプリケーション(図1のサーバアプリケーション12,13)を単位として、通信網内の1つ以上のノードシステム、ワークステーション、あるいはパーソナルコンピュータなど(以下、ノードと記す。図1のノード21,22,23)に必要に応じて分散して配備され、各々のノードが備える分散オブジェクトプラットフォーム上で実行される。
【0004】クライアントアプリケーション(図1のクライアントアプリケーション11)とサーバアプリケーション(図1のサーバアプリケーション12,13)の間の通信は、各々のノードが備える分散オブジェクトプラットフォームの中核構成要素であるORB(図1のORB1,2,3)により実現され、サーバアプリケーション(図1のサーバアプリケーション12,13)内で適切なサーバオブジェクト(図1のサーバオブジェクト1〜3,4〜5)に処理要求を渡すのは、ディスパッチャにより行われる。実装では、ORBの一部とディスパッチは、クライアントアプリケーション(図1のクライアントアプリケーション11)、サーバアプリケーション(図1のサーバアプリケーション12,13)それぞれの論理空間(UNIXでのプロセス)に含まれ得る。なお、本発明では、ディスパッチャの存在を想定しているが、以後の図では便宜上それを記述しないことにする。また、インタセプタ(図1のインタセプタ1,2)(例えば、Object Management Group,“The Common Object Request Broker. Architecture and Specification",Rev.2,3,ftp://ftp.omg.org/pub/docs/formal/99-12-01.pdf参照)は、ORB(図1のORB2,3)上で動作するオブジェクトであり、クライアントアプリケーション(図1のクライアントアプリケーション11)や他のサーバオブジェクトから、サーバオブジェクト(図1のサーバオブジェクト1〜3,4〜5)へ送られる処理要求を仲介する。インタセプタには、クライアントアプリケーション側に存在するORBの間に存在するクライアントインタセプタと、サーバアプリケーション側に存在するサーバインタセプタ(図1のインタセプタ1,2)があるが、本発明では、サーバインタセプタをインタセプタと記すことにする。インタセプタを用いることで、クライアントアプリケーションとサーバアプリケーション間の通信の内容を調べることが可能となる。サービスアプリケーション実行時の性能を確保するには、サービスアプリケーションを構成する個々のサーバオブジェクトが過負荷状態に陥り、個々の要求された処理の実行時間が増大することを防ぐ機構が必要となる。この機構を提供する代表的な方式として、従来より(1)リクエストキュー方式と(2)ネームサーバ方式の2つがある。
【0005】(1)リクェストキューを用いる方式図2は、従来のリクェストキューを用いてサーバオブジェクトの負荷制御を行う方式を示す図である。この方式では、図2に示すように、ORB(図2のORB2,3,4)内にリクェストキュー(図2のリクエストキュー1,2,3)を設ける。図2で、クライアントアプリケーション21は、サーバオブジェクトに処理要求を送信する代りに、そのリクェストキュー1に処理要求を送る(図2の201)。処理を実行していないサーバオブジェクト(サーバオブジェクト1)あるいは以前に要求された処理を実行し終えたサーバオブジェクト(図に該当するサーバオブジェクトはない)が、そのキューから次の処理要求を取り出し(図2の202)、処理の実行を開始する。ここで、リクェストキュー(図2のリクェストキュー1,2,3)に処理要求が一定数以上たまった場合には、所望の処理を実行するサーバオブジェクトを含む新たなサーバアプリケーション24を起動するか、あるいはリクェストキュー内の要求処理の数が一定値以下になるまで、クライアントアプリケーション21からの新たな処理要求を受け付けないようにする。この方式により、特定のサーバオブジェクトに処理要求が偏ることを防ぎ、また全体の要求処理頻度の変動に対処する。この方式は、従来のTP(Transaction Processing)モニタ製品やCORBA準拠ORBを内包するOTM(Object Transaction Monitor)製品(例えば、IONA Technologies, OrbixOTM,http://www.iona.com/info/products/orbixenter/orbixotm/index.htmlおよびINPRISE Corporation,Inprisc Application Server,http://www.inprise.com/appserver/参照)などで用いられる。なお、本発明では、ORBの存在を想定するが、以後の図においては便宜上それを記述しない。
【0006】(2)ネームサーバを用いる方式図3は、従来の代表的なネームサーバ仕様であるOMG(Object ManagementGroup)ネーミングサービス仕様(例えば、Object Managment Group,“CORBA Services:Common Object Service Specification”,ftp://ftp.omg.org/pub/docs/formal/99-07-05.pdf.参照)に準拠するネームサーバ(例えば、IONA Technologies, OrbixOTM,http://www.iona.com/info/products/orbixeenter/orbixotm/index.htmlまたはINPRISE Corporation, VisiBroker Naming Service,http://www.inprise.com/visibroker/products/nameds.html参照)を用いた方式を示す図である。ネームサーバ(図3のネームサーバ33)は、自身にとっての要求者であるクライアントアプリケーション(図3のクライアントアプリケーション31,32)やサーバアプリケーション(図3のサーバアプリケーション34,35)内のサーバオブジェクトから、その要求者サーバオブジェクト以外のサーバオブジェクト(図3のサーバオブジェクト1,2でその要求者サーバオブジェクト以外のもの)の名前を指定された(図3の301,302)ときに、後者(要求者でない方)のサーバオブジェクトのオブジェクトリファレンスをその要求者に提供する(図3の303,304),特殊なサーバアプリケーションあるいはサーバオブジェクトである。ここで、要求者から指定される名前は、ネームサーバが管理するネーミンググラフ36の階層構造に従った形式で指定される。例えば、図3で、Bank_Bサーバオブジェクトは、ネーミンググラフの上から下への階層を辿って/Department_B/Bank_Bという名前で識別される。要求者(図3のクライアントアプリケーション31,32)は、所望の処理を実行するサーバオブジェクト(図3のサーバオブジェクト1,2)に処理要求を送る前に、そのサーバオブジェクト(図3のサーバオブジェクト1,2)のオブジェクトリファレンスを獲得するために必要に応じてネームサーバ(図3の303)にアクセスする(図3の301,302,303,304)。オブジェクトリファレンスは、サーバオブジェクト(図3のサーバオブジェクト1,2)毎に対応して存在し、ノードアドレス(例えば、IPアドレスやノード名)、ポート番号、およびノード内で一意な識別名など、対応するサーバオブジェクトへ処理要求を送るために必要なデータを含む。例えば、図3では、Bank_Bサーバオブジェクトのオブジェクトリファレンスは、ノードアドレス:Host_B、ポート番号:1259、識別子:Bank_Bのデータを含む形で、/Department_B/Bank_Bという名前でネームサーバに登録されている。なお、サーバオブジェクト(図3のサーバオブジェクト1,2)の名前とオブジェクトリファレンスは、対応するサーバオブジェクト自身からの要求によりネームサーバ(図3のネームサーバ33)に予め登録される(図3の305,306)。また、クライアントアプリケーション(図3のクライアントアプリケーション31,32)とネームサーバ(図3のネームサーバ33)間、サーバオブジェクト(図3のサーバオブジェクト1,2)とネームサーバ(図3のネームサーバ33)間の通信もORB(図示省略)を介して行わる。
【0007】図4は、オブジェクトグループをサポートするネームサーバを示す従来例を示す図である。一部のネームサーバ(例えば、IONA Technologies, OrbixOTM,http://www.iona.com/info/products/orbixenter/orbixotm/index,html参照)(図4のネームサーバ43)では、同一のインタフェースを提供するサーバオブジェクト群(図4のサーバオブジェクト1と2、3と4)があるとき、個々のサーバオブジェクトのオブジェクトリファレンスをオブジェクトグループとしてまとめてグループ化し、そのオブジェクトグループと名前を対応させる(図4のサーバオブジェクト1と2に対して409、サーバオブジェクト3と4に対して410)方式を用いている。要求者としてのクライアントアプリケーション(図4のクライアントアプリケーション41,42)あるいはサーバオブジェクトは、オブジェクトグループの名前を指定してネームサーバ(図4のネームサーバ43)に所望の処理を実行するサーバオブジェクト(図4のサーバオブジェクト1〜4)のオブジェクトリファレンスを要求する(図4の401,402)。ネームサーバ(図4のネームサーバ43)は、オブジェクトリファレンスの要求を受けると、指定されたオブジェクトグループ(図4の409,410)に登録(図4の405〜408)されたオブジェクトリファレンスの中の1つを選定し、その要求者に返す(図4の403,404)。これ以後、そのネームサーバ(図4のネームサーバ43)が新たなオブジェクトリファレンスの要求(図4の401,402)を受けたときには、指定されたオブジェクトグループ(図4の409,410)に登録(図4の405〜408)されたオブジェクトリファレンスの中で、先に返したオブジェクトリファレンスの次に登録されたオブジェクトリファレンスを要求者に返す(図4の403,404)。ここで、次に登録されたオブジェクトリファレンスが存在しない場合には、そのオブジェクトグループ(図4の409,410)で最初に登録(図4の405〜408)されたオブジェクトリファレンス情報を返す(図4の403,404)。なお、オブジェクトグループ(図4の409,410)に登録されたオブジェクトリファレンスの中から1つを選定する他の方法として、予め固定的に定められた割合(確率)値を基に選定する方法もある。これにより、同一の機能を有する複数のサーバオブジェクト(図4のサーバオブジェクト1と2、3と4)が存在するとき、そのサーバオブジェクト(図4のサーバオブジェクト1と2、3と4)が順次起動され、サーバオブジェクト(図4のサーバオブジェクト1と2、3と4)間での負荷分散を図る。
【0008】
【発明が解決しようとする課題】分散オブジェクトプラットフォーム製品は、それぞれ異なる特徴を持ち得るため、機能、性能、規模などサービス開発時や運用時の様々な要望に応じて、1つのサービスアプリケーションを構成する個々のサーバオブジェクトがそれを動作させるために、最適な分散オブジェクトプラットフォーム上で動作させる状況が存在する。このような状況では、複数種類の分散オブジェクトプラットフォームを用いて1つのサービスアプリケーションを動作させることになる。この場合においても、個々のサーバオブジェクトの負荷制御を一元的に行える必要がある。ところが、既存のOTM製品に代表される分散オブジェクトプラットフォーム製品などで用いられているリクェストキューを用いる方式では、処理要求者によるサーバオブジェクトのオブジェクトリファレンスの入手法や、クライアントアプリケーションやサーバアプリケーションからのキューへのアクセス方法およびキューの操作方法が、製品毎に異なっている。このため、例えば、分散オブジェクトプラットフォーム製品A上で動作するサーバアプリケーションの負荷情報あるいはメッセージキューに関する情報などを、製品B上で動作している管理アプリケーションとしてのクライアントアプリケーションが入手することは、そのアクセス方法および操作方法の違いにより実現が困難である。すなわち、従来、複数種類の分散オブジェクトプラットフォーム製品を混在させた環境下でサービスアプリケーションの性能管理を行う場合、個々の製品毎にそれ性能管理ツールを導入する必要がある。結果的に個々のサーバオブジェクトの負荷制御を一元的に行うことができないため、既存製品でのリクエストキューを用いる方式では、複数種類の分散オブジェクトプラットフォーム製品を混在させた環境下において、サーバオブジェクトでの個々の要求された処理の実行時間が増大することを防止できないという問題があった。
【0009】一方、ネームサーバを用いる方式では、グループに登録された個々のオブジェクトリファレンス情報に対応するサーバオブジェクトに順番に処理要求が発行される。しかし、サーバオブジェクトにおいて要求された処理を実行し終えるのに要する時間が、処理要求の内容や入力パラメータなどに応じて大きく変動する場合がある。この場合、グループに登録された個々のオブジェクトリファレンス情報に対応するサーバオブジェクトに順番に処理要求が発行されても、あるいは予め定められた固定的な割合で個々のサーバオブジェクトに処理要求が発行されても、各々のサーバオブジェクトでの要求された処理の実行時間にばらつきが生じ、結果的に特定のサーバオブジェクトに負荷が偏り得るため、個々の要求された処理の実行時間が増大することを防ぐことができないという問題がある。従って、複数のORB製品を導入した環境においても、サービスアプリケーションを構成するサーバオブジェクト群の間で、一元的に個々のサーバオブジェクトの負荷状況に応じて負荷制御および負荷分散を行い、必要に応じてサーバオブジェクト数を調整しながら、特定のサーバオブジェクトでの負荷の偏りを防止し、個々の要求された処理の実行時間増大を防止する機構が必要である。
【0010】そこで、本発明の目的は、このような従来の課題を解決し、異なる分散オブジェクトプラットフォーム製品を導入した環境下でも、全てのサーバオブジェクトの負荷状況を一元的に逐次把握し、その負荷状況に対応して負荷制御および負荷分散をリアルタイムに行い、その結果として個々の要求された処理の実行時間の増大を防止することが可能な分散オブジェクト性能管理機構を提供することにある。また、本発明のさらなる目的としては、サーバオブジェクトの実装に影響を及ぼさず分散オブジェクト性能管理機構を導入でき、しかもモニタオブジェクトの実装への影響なしにサーバオブジェクトの実装を変更できる分散オブジェクト性能管理機構を提供することにある。
【0011】
【課題を解決するための手段】上記目的を達成するため、本発明の分散オブジェクト性能管理機構では、処理実行者としての個々のサーバオブジェクト(図5のサーバオブジェクト1〜4)における要求者(図5のクライアントアプリケーション54A)から要求された処理の実行状況に関するサーバオブジェクト性能データ(以後、性能データと記す。図5の性能データ56、58)を格納するモニタオブジェクト(図5のモニタオブジェクト55)を設ける。モニタオブジェクト(図5のモニタオブジェクト55,57)はサーバオブジェクト(図5のサーバオブジェクト1,2)とは独立した別個のオブジェクトであり、サーバアプリケーション(図5のサーバアプリケーション52A,59A)内に1つ設けられる。性能データ(図5の性能データ56,58)は、サーバオブジェクト(図5のサーバオブジェクト1〜4)が要求者から要求され、実行した個々の処理について、その処理の実行開始・終了時刻、処理名、およびその処理を実行したサーバオブジェクト名を記録したものである。また、その性能データ(図5の性能データ56,58)を基に各々のサーバオブジェクト(図5のサーバオブジェクト1〜4)の負荷値を算出し、負荷値・利用比率値対応テーブル(図5の53)を参照して、各々のサーバオブジェクト(図5のサーバオブジェクト1〜4)の利用比率値を決定し、その各サーバオブジェクト毎の利用比率値をネームサーバ(図5のネームサーバ51A)に通知(図5の511)するサーバマネージャアプリケーション(図5のサーバマネージャアプリケーション53A)を設ける。負荷値は、サーバオブジェクトで実行した個々の処理の平均実行時間と、実行時間が予め処理内容毎に指定された許容実行時間を超えた処理の回数の2つのパラメータを含み、サーバオブジェクト(図5のサーバオブジェクト1〜4)の負荷の変動に対応して、サーバマネージャアプリケーション(図5のサーバマネージャアプリケーション53A)で逐次計算・更新される。更新された負荷値に対応した各サーバオブジェクトの新しい利用比率値は、サーバマネージャアプリケーションから定期的にネームサーバ(図5のネームサーバ51A)へ通知(図5の511)される。また、負荷値・利用比率値対応テーブル(図5の53)は、予めサービスアプリケーション運用管理者により設定される。典型的には、大きい負荷値に対しては、利用比率値を小さく設定する。ネームサーバ(図5のネームサーバ51A)は、要求者(図5のクライアントアプリケーション54A)からオブジェクトリファレンスの要求を受けると(図5の501)、指定されたオブジェクトグループに登録されている個々のオブジェクトリファレンスに対応するサーバオブジェクトの利用比率値の割合(図5の51)を参照して、その割合に従って1つ以上のオブジェクトリファレンスを選定し、要求者に返す(図5の502)。
【0012】このように、サーバオブジェクト(図5のサーバオブジェクト1〜4)の負荷の変動に伴い、リアルタイムに各々のサーバオブジェクト(図5のサーバオブジェクト1〜4)の負荷値が算出され、その負荷値に対応した利用比率値がネームサーバ(図5のネームサーバ51A)に通知される(図5の511)。要求者がネームサーバ(図5のネームサーバ51A)にオブジェクトリファレンスを要求したときに、ネームサーバ(図5のネームサーバ51A)は利用比率値の大きいサーバオブジェクト(例えば、図5のサーバオブジェクト4)のオブジェクトリファレンスを優先的に返すが、典型的には大きい利用比率値はサーバオブジェクト(例えば、図5のサーバオブジェクト4)での小さい負荷を意味するので、ネームサーバ(図5のネームサーバ51A)は、要求者に対して負荷の小さいサーバオブジェクト(例えば図5のサーバオブジェクト4)のオブジェクトリファレンスを優先的に返していることになる。しかも、実際のサーバオブジェクト(図5のサーバオブジェクト1〜4)の負荷状況に応じて負荷値が定期的に算出され、対応した利用比率値がネームサーバ(図5のネームサーバ51A)に通知され登録されるため、その負荷値と利用比率値は実際のサーバオブジェクト(図5のサーバオブジェクト1〜4)の負荷状況をリアルタイムに反映する。従って、本発明を用いることで、実際のサーバオブジェクト(図5のサーバオブジェクト1〜4)の負荷状況を考慮しながら特定のサーバオブジェクトでの負荷の偏りを防止し、個々の要求された処理の実行時間の増大を防止することが可能になる。また、ORBP製品毎のORBのAPI(Application Programming Interface)の違いにより、モニタオブジェクト(図5のモニタオブジェクト55,57)はORB毎に異なる実装のものが提供されるが、全てのモニタオブジェクト(図5のモニタオブジェクト55,57)が提供するインタフェースは同一である。さらに、前記のIIOPなどの分散オブジェクトプラットフォーム間の標準通信プロトコルを用いることで、インタフェースとプロトコルを整合させることが可能となり、複数種類の分散オブジェクトプラットフォーム製品を混在させた環境下において、サーバマネージャアプリケーション(図5のサーバマネージャアプリケーション53A)から全てのサーバオブジェクト(図5のサーバオブジェクト1〜4)に対して処理の実行を要求することが可能になる。これにより、サーバマネージャアプリケーション(図5のサーバマネージャアプリケーション53A)が、異なる分散オブジェクトプラットフォーム上で動作する全てのサーバオブジェクト(図5のサーバオブジェクト1〜4)から性能データを収集することが可能となる。従って、複数種類の分散オブジェクトプラットフォーム製品を混在させた環境下において、個々のサーバオブジェクト(図5のサーバオブジェクト1〜4)の負荷制御を一元的に行い、サーバオブジェクト(図5のサーバオブジェクト1〜4)での個々の要求された処理の実行時間の増大を防止することが可能になる。また、モニタオブジェクトの実装をサーバオブジェクトの実装から分離する(図5で、モニタオブジェクト55とサーバオブジェクト1と2、モニタオブジェクト57とサーバオブジェクト3と4)ことで、サーバオブジェクト(図5のサーバオブジェクト1〜4)の実装に影響を及ぼさずに分散オブジェクト性能管理機構を導入でき、しかもモニタオブジェクト(図5のモニタオブジェクト55,57)の実装への影響なしにサーバオブジェクト(図5のサーバオブジェクト1〜4)の実装を変更することが可能になる。
【0013】
【発明の実施の形態】以下、本発明の実施例を、図面により詳細に説明する。図5は、本発明の一実施例を示す分散オブジェクト性能管理機構の構成図である。モニタオブジェクト55,57は、自分と同一のサーバアプリケーション内に存在するサーバオブジェクト(モニタオブジェクト55に対してサーバオブジェクト1と2、モニタオブジェクト57に対してサーバオブジェクト3と4)がクライアントアプリケーションなどの要求者から要求され実行した個々の処理について、その実行開始・終了時刻、処理名、およびその処理を実行したサーバオブジェクト名を性能データ格納部(図5の性能データ56,58)に記録する。
【0014】ネームサーバ51Aは、0個以上のオブジェクトグループの情報を格納する。各々のオブジェクトグループには、そのオブジェクトグループ名、そのオブジェクトグループに登録されている1つ以上のオブジェクトリファレンス、およびそれらの個々のオブジェクトリファレンスに対応するサーバオブジェクトの利用比率値が含まれる(図5の51)。なお、1つのオブジェクトグループに登録される個々のオブジェクトリファレンスに対応するサーバオブジェクトは、全ての同一のインタフェースを提供する。
【0015】クライアントアプリケーション54Aは、オブジェクトグループ名を指定して、ネームサーバ51Aに/Department_A/Printer_Aオブジェクトグループに属するオブジェクトリファレンスを要求する(図5の501)。ネームサーバ51Aは、そのオブジェクトグループに属する各々のオブジェクトリファレンスの利用比率値を調べ、それらの利用比率値の相対的割合に応じてサーバオブジェクト2のオブジェクトリファレンスを選定してクライアントアプリケーション54Aに返す(図5の502)。
【0016】図6は、本発明方式を用いたネームサーバの役割を説明するための適用例を示す図である。図5でのネームサーバ51が要求者に返すオブジェクトリファレンスを選定する方法を、図6を用いて説明する。図6に示すように、サーバアプリケーション68,69,70の中でそれぞれサーバオブジェクト1,2,3が存在し、それらのサーバオブジェクト1,2,3のオブジェクトリファレンス(OR1,OR2,OR3)が、ネームサーバ中で同一オブジェクトグループに登録されている。図6にあるように、サーバオブジェクト1,2,3のオブジェクトリファレンスOR1,OR2,OR3の利用比率値がそれぞれ1,2,3で、6つのクライアントアプリケーション61〜66からオブジェクトリファレンスの要求があった場合(図6の601〜606)、各々の要求に対して、オブジェクトリファレンスOR1,OR2,OR3を1:2:3の割合で選定し、それらの要求毎に選定されたオブジェクトリファレンスをクライアントアプリケーション61〜66に返す(図6の611〜616)。
【0017】クライアントアプリケーション54Aがネームサーバ51Aからサーバオブジェクト2のオブジェクトリファレンスを受け取ると(図5の502)、クライアントアプリケーション54Aはサーバアプリケーション52Aに処理要求を送る(図5の503)。この処理要求は、先ずサーバアプリケーション52A内で動作するインタセプタ1で受け付けられる。インタセプタ1は、性能データ格納用の新たなエントリ(図5の52)をモニタオブジェクト55に作成するよう要求し(図5の504)、さらに要求された処理名、処理を実行するサーバオブジェクトの識別子、および処理開始時刻をエントリ(図5の52)に記録するよう要求する(図5の505)。その後、インタセプタ1は、要求者から受け取った処理要求をサーバオブジェクトに渡す(図5の506)。その要求された処理の実行を終了したサーバオブジェクト2は、インタセプタ1に処理実行結果を返す(図5の507)。インタセプタ1では、その処理結果を受け取ると、先ほどモニタオブジェクト55内に作成させたエントリ(図5の52)に、処理終了時刻を追加して記録するように要求する(図5の508)。その後、インタセプタ1は、その処理実行結果をクライアントアプリケーション54Aに返す(図5の509)。このように、本発明方式では、モニタオブジェクト55,57を図5のサーバオブジェクト1〜4に埋め込まず、図5のサーバオブジェクト1〜4とは別個の独立したオブジェクトとしてサーバアプリケーション52A内に設け、モニタオブジェクト55,57に、そのモニタオブジェクト自身と同一サーバアプリケーション内に存在するサーバオブジェクト(図5で、モニタオブジェクト55に対してサーバオブジェクト1と2,モニタオブジェクト57に対してサーバオブジェクト3と4)の性能データをインタセプタ(図5で、モニタオブジェクト55に対してインタセプタ1、モニタオブジェクト57に対してインタセプタ2)と協調して収集・管理させる。
【0018】サーバマネージャアプリケーション53Aに含まれるサーバマネージャオブジェクト5Aは、定期的にモニタオブジェクト55,57から性能データを収集し(図5の510,512)、それらモニタオブジェクトと同一のサーバアプリケーション(図5で、モニタオブジェクト55に対してサーバアプリケーション52A,モニタオブジェクト57に対してサーバアプリケーション59A)に含まれるサーバオブジェクト(図5で、モニタオブジェクト55に対してサーバオブジェクト1と2、モニタオブジェクト57に対してサーバオブジェクト3と4)で実行した個々の処理について実行時間を算出し、それを基にさらにサーバの負荷値を算出する。サーバオブジェクトの負荷値は、サーバオブジェクトで実行した個々の処理の平均実行時間と、実行時間が予め処理内容毎に指定された許容実行時間を超えた処理の回数の2つのパラメータを含む。さらに、サーバマネージャオブジェクト5Aは、その負荷値を基に、予め設定された負荷値・利用比率値対応テーブル(図5の53)を参照して、サーバオブジェクト1〜4の利用比率値を調べ、各々のサーバオブジェクトの利用比率値をネームサーバ51Aに通知する(図5の511)。これ以後、段落番号〔0014〕以降の手続きを通してクライアントアプリケーション54Aなどのオブジェクトリファレンスの要求者に対して、ネームサーバ51Aから返されるオブジェクトリファレンスは、新たに設定された利用比率値を用いて選定される。この利用比率値は、サーバオブジェクト1〜4の負荷値の変動に応じて定期的に更新される。なお、サーバマネージャオブジェクト5Aの実装は、そのサーバマネージャオブジェクト5Aを動作させる分散オブジェクトプラットフォームにより異なるが、全てのサーバマネージャオブジェクトのインタフェースは同一である。
【0019】図7は、本発明の概略的な実行フローチャートであり、図8は、図7におけるサービス実行フェーズの部分の実行フローチャートであり、図9は、図7における利用者比率更新フェーズの部分の実行フローチャートである。先ず、図7に示すように、サーバオブジェクト74の負荷の変動に伴って、ネームサーバ72に登録された利用比率値を更新するための利用比率値更新フェーズが定期的に実行され、各々の利用比率値更新フェーズの間に、クライアントアプリケーション71からのオブジェクトリファレンス要求を処理する0回以上のサービス実行フェーズが実行される。
【0020】図8のサービス実行フェーズにおいては、クライアントアプリケーション71からネームサーバ72にオブジェクトリファレンス要求があると、ネームサーバ72は、指定されたオブジェクトグループに登録された各々のオブジェクトリファレンスの利用比率値を参照してオブジェクトリファレンスの選定を行い(図8の801)、クライアントアプリケーション71に返す。次に、そのオブジェクトリファレンスのデータを用いて、クライアントアプリケーション71はサーバアプリケーション76に処理要求を送る。この処理要求は、先ずサーバアプリケーション76内で動作しているインタセプタ73により受け取られる。インタセプタ73は処理要求を受けると、モニタオブジェクト75に性能データ格納用の新たなエントリを作成するよう要求し、さらにクライアントアプリケーション71から要求された処理名、処理を実行するサーバオブジェクトの識別子、および処理開始時刻をエントリに記録するよう要求する。これにより、モニタオブジェクトにて新規のエントリが作成され(図8の802)、そのエントリにデータが記録される。次に、インタセプタ73は、サーバオブジェクト74に処理要求を渡し、処理実行結果をサーバオブジェクト74から受け取る。そして、インタセプタ73は、先に作成したエントリに処理終了時刻を記録するように、モニタオブジェクト75に要求する。その後に、インタセプタ73はクライアントアプリケーション71に処理結果を返す。
【0021】図9の利用比率値更新フェーズにおいては、サーバマネージャアプリケーション77のサーバマネージャオブジェクト78が、定期的にモニタオブジェクト75からサーバオブジェクト74の性能データを収集し、収集した性能データからサーバオブジェクト74の負荷値を算出し、その負荷値に対応する利用比率値を調べ、得られた利用比率値をネームサーバ72に通知する。ネームサーバ72では、通知された利用比率値をサーバオブジェクト74に対応するオブジェクトリファレンスの利用比率値として、更新登録する。これ以後は、ネームサーバ72から要求者に返されるオブジェクトリファレンスは、新たに設定された利用比率値を用いて選定される。
【0022】このように、本発明においては、サーバオブジェクトの負荷の変動に伴いリアルタイムに各々のサーバオブジェクトの負荷値が算出され、その負荷値に対応した利用比率値がネームサーバに通知される。要求者がネームサーバにオブジェクトリファレンスを要求したときに、ネームサーバは、利用比率値の大きい、すなわち小さい負荷のサーバオブジェクトのオブジェクトリファレンスを優先的に返す。しかも、実際のサーバオブジェクトの負荷状況に応じて負荷値が定期的に算出され、対応した利用比率値がネームサーバに通知され登録されるため、その負荷値と利用比率値は実際のサーバオブジェクトの負荷状況をリアルタイムに反映する。従って、実際のサーバオブジェクトの負荷状況を考慮しながら特定のサーバオブジェクトでの負荷の偏りを防止し、個々の要求された処理の実行時間の増大を防止することが可能になる。また、モニタオブジェクトは分散オブジェクトプラットフォーム対応に異なる実装のものが提供されるが、全てのモニタオブジェクトが提供するインタフェースは同一である。さらに、IIOPなどの分散オブジェクトプラットフォーム間の標準通信プロトコルを用いることで、インタフェースとプロトコルを整合させることが可能となり、複数種類の分散オブジェクトプラットフォーム製品を混在させた環境下において、サーバマネージャアプリケーションから全てのサーバオブジェクトに対して処理の実行を要求することが可能となる。これにより、サーバマネージャアプリケーションが、異なる分散オブジェクトプラットフォーム上で動作する全てのサーバオブジェクトから性能データを収集することが可能となる。従って、複数種類の分散オブジェクトプラットフォーム製品を混在させた環境下において、個々のサーバオブジェクトの負荷制御を一元的に行い、サーバオブジェクトでの個々の要求された処理の実行時間の増大を防止することが可能になる。また、モニタオブジェクトの実装をサーバオブジェクトの実装から分離することで、サーバオブジェクトの実装に影響を及ぼさずに分散オブジェクト性能管理機構を導入でき、しかもモニタオブジェクトの実装への影響なしにサーバオブジェクトの実装を変更することが可能になる。
【0023】
【発明の効果】以上説明したように、本発明によれば、複数の分散オブジェクトプラットフォーム製品を導入した環境下でも、全ての本機構の構成要素間で通信が可能になる。従って、異なる製品を導入した環境下でも、サーバマネージャオブジェクトが、定期的かつ一元的にモニタオブジェクトからサーバオブジェクトの性能データを収集し、個々のサーバオブジェクトの負荷値を算出し、その負荷値に応じた新しい利用比率値をネームサーバに通知し更新させることが可能となる。これにより、必要に応じてサーバオブジェクト数を調整しつつ、サーバオブジェクトの負荷の変動にリアルタイムに対応して、それらのサーバオブジェクトの負荷制御および負荷分散を行うことが可能となる。従って、特定のサーバオブジェクト間での負荷の偏りを防ぎ、個々の要求された処理の実行時間増大を防ぐことが可能となる。また、サーバオブジェクトの実装に影響を及ぼさずに分散オブジェクト性能管理機構を導入でき、しかもモニタオブジェクトの実装への影響なしにサーバオブジェクトの実装を変更することが可能となる。




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013