JP2003091512A - 分散型計算機システム - Google Patents

Abstract

(57)【要約】 【課題】分散型計算機システムにおいて所望の性能を満
たすために如何なる通信方式を適用し如何に処理の優先
度を割り当てるべきかをシステムの設計段階において簡
易に評価できるようにし、システム構築にかかるインパ
クトを軽減する。 【解決手段】システム内に、性能評価にかかる測定の対
象とするCORBAオブジェクトを複数起動する。各CORBAオ
ブジェクトをクライアントまたはサーバとして振る舞わ
せ、クライアントおよびサーバからなるペアを生成す
る。＜リクエスト／リプライ型＞などの各種の通信方式
に基づき、各ペアのクライアント−サーバ間でリモート
呼び出しを実施させる。クライアントにおいては、リク
エストの開始時刻及び終了時刻を計測する。サーバにお
いては、クライアントから送出されたメッセージを受信
した時刻を計測する。そして、これらの各時刻をもと
に、クライアント−サーバ間のリモート呼び出しの性能
を評価する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、クライアント−サ
ーバ間のリモート呼び出しの性能を評価する機能を備え
る分散型計算機システムに関する。特に本発明は、共通
オブジェクト・リクエスト・ブローカー・アーキテクチ
ャ（CORBA: Common Object Request Broker Architectu
re）規格に基づくオブジェクト・リクエスト・ブローカ
ー（ORB：Object Request Broker）を介したクライアン
ト−サーバ間で、サービス・リクエストを実施する分散
型計算機システムにおける、クライアント−サーバ間の
リモート呼び出しのリアルタイム性能を評価するシステ
ムに関する。

【０００２】

【従来の技術】分散型の計算機環境において、サーバに
存在するオブジェクトにクライアントがアクセスするた
めのメカニズムを提供する技術標準として、CORBA仕様
が広く用いられている。CORBA仕様は、広範囲にわたる
アプリケーションに幅広く対応できるように、その初期
の規格から次第に拡張されてきている。

【０００３】拡張型のCORBA仕様の一つとして、リアル
タイムCORBA仕様が策定されている。リアルタイムCORBA
仕様は、リアルタイム型のアプリケーション向けに、処
理の優先度が設定されたリクエストを与えるための規格
である。さらに、CORBA規格には、さまざまな種類のア
プリケーションを構築することが可能なように、比較的
単純な通信方式である「要求（リクエスト）／返答（リ
プライ）型」のほかに、他の数多くの通信方式による実
装方法が定められている。

【０００４】アプリケーションに応じて、クライアント
−サーバ間の通信方式を適宜選択することにより、アプ
リケーションに要求される通信モデルを素直に実装でき
るようになる。その結果、プログラミング上の制約を解
消したり、CORBAを用いたシステム構築を容易にした
り、機能上の要求を満たすことを容易にすることなどが
可能になる。

【０００５】ところで、当技術分野においては、構築し
ようとするシステムにおいて所望の性能を達成するため
に、どの通信方式を適用すべきかという情報は、ある程
度隠蔽された形で提供される。このため、CORBAにより
システムを設計する立場においては、数多く定められて
いるCORBA規格の中のどの方式を採用し、どのように組
み合わせるべきかについて、明確な指針を持ちにくい。
このことは、応答時間や遅延時間に関するリアルタイム
性が要求されるシステムを構築する立場においては、特
に顕著になる。

【０００６】このような事情から、リクエストの頻度、
データ量が様々に異なるリモート呼び出しを行なうシス
テムをCORBAを用いて構築するにあたっては、仮定（ほ
とんどの場合、裏付けに乏しい）に基づいてシステムを
構築し、システム全体が完成した後に性能を評価し、性
能が不足する場合は工程を後戻りして設計を修正すると
いうアプローチを取らざるを得ない。このような事態を
生じると、作業工程面でのインパクトや、特にコスト面
でのインパクトが非常に大きいという不具合を生じる。

【０００７】特に、リアルタイム系のシステムにおいて
は、エンタープライズ系のシステムと比較して、使用可
能なＣＰＵ（Central Processing Unit）の性能、メモ
リ容量、または通信帯域などの、システム資源の制約が
大きい。このため、リクエストに対する処理の優先度の
設定などの手段により、システム資源を適切に配分しな
がら所望の性能を得るためには、より大きな困難が伴
う。従って、後戻り作業を余儀なくされることがますま
す多くなり、上記の不具合はさらに深刻になる。

【０００８】一方、後戻り作業を極小化するために、シ
ステムの性能を事前に評価しようとすると、その作業自
体に大きな手間やコストがかかる。上記したように、当
技術分野においては通信方式やその組み合わせが多種多
様であり、リクエストの頻度、データ量、処理の優先度
が様々であるために、利用者が構築しようとするシステ
ムに合わせた評価環境を一から実装しようとすると、そ
の作業量が大きくならざるを得ないからである。

【０００９】

【発明が解決しようとする課題】以上述べたように従来
の分散型計算機システムにおいては、構築しようとする
システムの全体が完成した後になって性能の不足が判明
することが多いため、作業工程の後戻りを余儀なくされ
ることが多かった。このため作業工程面でのインパクト
や、特にコスト面でのインパクトが非常に大きいという
不具合があった。

【００１０】本発明は上記事情によりなされたもので、
その目的は、リクエストの頻度やデータ量が様々に異な
るリモート呼び出しを行なう分散型計算機システムにお
いて、要求される性能を達成するために如何なる通信方
式を適用し、如何に処理の優先度を割り当てるべきか
を、システムの設計段階において簡易に評価できるよう
にし、これによりシステム構築にかかる作業行程面やコ
スト面でのインパクトを軽減し得る分散型計算機システ
ムを提供することにある。

【００１１】

【課題を解決するための手段】上記目的を達成するため
に本発明は、クライアントがサーバのオブジェクトにア
クセスするためのサービス・リクエストを実施する分散
型計算機システムにおいて、クライアントとして振る舞
う第１の分散オブジェクト部品と、サーバとして振る舞
う第２の分散オブジェクト部品とを、分散型計算機シス
テム内において所定の数だけ起動する性能評価手段を具
備し、前記第１の分散オブジェクト部品に、前記分散型
計算機システムにおけるクライアント−サーバ間のリモ
ート呼び出しに適用される複数の通信方式を実装し、各
通信方式に基づいて前記第２の分散オブジェクト部品と
のリモート呼び出しを実施し、当該リモート呼び出しの
開始時刻及び終了時刻を計測させ、前記第２の分散オブ
ジェクト部品に、前記リモート呼び出しが実施されるに
あたり前記第１の分散オブジェクト部品から自己宛てに
送出されるメッセージの受信時刻を計測させ、前記性能
評価手段に、前記第１および第２の分散オブジェクト部
品で計測された前記開始時刻、終了時刻、及び受信時刻
をもとに、前記分散型計算機システムにおける前記各通
信方式の性能を評価させるようにした。

【００１２】特に、本発明は、通信方式として＜リクエ
スト／リプライ型＞、＜ワンウェイ・リクエスト型＞、
＜非同期メソッド呼出し型＞、または、＜イベントサー
ビス型＞のうち少なくとも一つを含むことを特徴とす
る。

【００１３】このような手段を講じたことにより、分散
型計算機システム内に複数の分散オブジェクト部品が生
成される。そうして、＜リクエスト／リプライ型＞、＜
ワンウェイ・リクエスト型＞、＜非同期メソッド呼出し
型＞、または＜イベントサービス型＞などの各種の通信
方式のもとで、各オブジェクト部品間のリモート呼び出
しが実施される。その際、クライアントとなる第１の分
散オブジェクト部品において、リモート呼び出しの開始
及び終了時刻が計測され、サーバとなる第２の分散オブ
ジェクト部品において、第１の分散オブジェクト部品か
ら自己宛てに送出されたメッセージの受信時刻が計測さ
れる。そして、これらの各時刻をもとに、性能評価手段
により、分散型計算機システム内における各通信方式の
性能が評価される。

【００１４】従って本発明によれば、リクエストの頻
度、データ量が様々に異なるリモート呼び出しを行なう
分散型計算機システムを構築する上で、いずれの通信方
式を適用することによりシステムに求められる性能を満
たすことができるかを、システム設計段階において事前
に評価することが可能になる。これにより、システム全
体が完成した後の性能評価によりリモート呼び出しの性
能の不足が判明することによる後戻り作業の極小化と、
事前評価に必要な作業量を軽減することが可能になる。

【００１５】例えば本発明を、CORBAを用いたリアルタ
イム分散システムに適用すると、許され得るシステム資
源の制約の範囲内で、CORBA規格で数多く定められてい
る通信方式をどのように組み合わせ、どのようにリクエ
ストの処理の優先度を割り当てることでシステムに求め
られるリアルタイム性要求を満たすことができるのか
を、システム設計段階において事前に評価することが可
能になる。

【００１６】なお、リアルタイム性の評価の指標として
は、リクエストの応答時間、遅延時間、周期のブレ（以
下、ジッタ時間と称する）並びにＣＰＵ、メモリ、通信
の負荷情報などがあげられる。

【００１７】

【発明の実施の形態】以下、図面を参照して本発明の実
施の形態につき説明する。図１は、本発明にかかる分散
型計算機システムの構成例を示す図である。図１のシス
テムは、主としてシステム全体を監視及び制御する役割
を担うメインシステム１と、主として特定の一部の業務
を担当する複数のサブシステム２−１〜２−ｎとを備え
る。メインシステム１とサブシステム２−１〜２−ｎと
は、例えば図示しないＬＡＮ（Local Area Network）な
どの通信網を介して互いに接続される。メインおよびサ
ブシステムは、共にリアルタイムORB（Object Request
Broker）／リアルタイム系のOS（Operating System）上
に構築される。

【００１８】この種のシステムは、例えば航空機に搭載
される組込み型制御システムとして実現される。この場
合、メインシステム１は操縦席においてパイロットの操
縦を補助するオートパイロットシステムとして、またサ
ブシステム２−１〜２−ｎは操舵翼やエンジン系統など
に備えられる制御コンピュータとして実現される。

【００１９】図１において、メインシステム１は、ユー
ザ・インタフェース部１１と、測定動作コントロール部
１２とを備える。ユーザ・インタフェース部１１は、評
価対象とするCORBAオブジェクトの起動要求、または測
定動作の開始要求などの、オペレータから与えられる要
求を測定動作コントロール部１２に対して通知し、要求
に応じた動作を指定する。ユーザ・インタフェース部１
１は、各種ウインドウを表示するモニタ、キーボード、
マウスなど（いずれも図示しない）のヒューマンマシン
インタフェースを備え、上記の要求は、ヒューマンマシ
ンインタフェースを介して入力される。

【００２０】またメインシステム１は、時刻同期部１４
を備える。サブシステム２−１〜２−ｎは、時刻同期部
２２を備える。時刻同期部１４、２２は、ＮＴＰ（Netw
orkTime Protocol）などの所定のプロトコルや他の手段
に基づいて互いに協調して動作し、メインシステム１と
サブシステム２−１〜２−ｎとを、システムに与えられ
た基準時刻（以下システムタイムと称する）に同期させ
る。

【００２１】さらにメインシステム１は、測定状況監視
部１５を備える。測定状況監視部１５は、ＣＰＵの負
荷、メモリの負荷、あるいは通信の負荷の状況を監視す
る。

【００２２】図１の測定動作コントロール部１２により
評価対象のCORBAオブジェクトを起動する時、または測
定動作を開始する時には、評価対象となるシステムを定
義するためのパラメータ（以下、評価パラメータと称す
る）が必要となる。評価パラメータ１３は、予め用意さ
れた電子ファイルのロード、あるいはモニタのウインド
ウを用いた入力操作などにより、システムに与えられ
る。

【００２３】図２は、評価パラメータ１３の構成を示す
模式図である。評価パラメータ１３は、リモート呼び出
しごとに固有のパラメータが定義されるタスク定義部
と、システム全体に関わるパラメータが定義される全体
構成定義部とを備える。このうちタスク定義部には、図
１に示される評価対象のCORBAオブジェクト（サーバ）
とCORBAオブジェクト（クライアント）との１組のペア
について、その挙動の内容が定義される。なおタスク定
義部には、評価目的に必要なオブジェクトインスタンス
の数に相当する、任意の個数を定義することができる。

【００２４】図２において、タスク定義部には、（タス
ク番号）、（サーバ名称）、（クライアント名称）、
（稼動機器の識別子）、（CORBA通信方式）、（CORBAプ
ライオリティ）、（周期／イベント区分）、（周期）、
（イベント・タイミング）、（データ長）、（時間計測
の実施の有無）、及び、（ユーザ定義送受信部使用の有
無）なるアイテムが定義される。

【００２５】（タスク番号）には、CORBAオブジェクト
（サーバ）とCORBAオブジェクト（クライアント）との
１組のペアに与えられるユニークな整数が定義される。
（サーバ名称）、及び（クライアント名称）には、タス
ク番号で定義されるペアに属するCORBAオブジェクト
（サーバ）とCORBAオブジェクト（クライアント）とに
それぞれ与えられる、ユニークな名称が定義される。こ
こで定義される名称は、測定結果を参照する際の便宜と
なるほか、CORBAオブジェクト（クライアント）からCOR
BAオブジェクト（サーバ）の参照を得るために、CORBA
システムの構築で一般的に利用されるネーミングサービ
スに付与する名称として使用される。なお、ネーミング
サービスは必ずしも必須ではなく、別の通信手段により
オブジェクトリファレンスを獲得する方法があるため、
図１には表示しない。

【００２６】（稼動機器の識別子）には、CORBAオブジ
ェクト（クライアント）、及びCORBAオブジェクト（サ
ーバ）のそれぞれについて、どの機器上で動作するかが
定義される。すなわち、CORBAオブジェクト（クライア
ント）、またはCORBAオブジェクト（サーバ）が、メイ
ンシステム１またはサブシステム２−１〜２−ｎのいず
れで稼動するかが定義される。（CORBA通信方式）に
は、CORBAのどの通信方式を利用するかが定義される。
本実施形態においては、CORBA通信方式として、＜リク
エスト・リプライ型＞、＜ワンウェイ・リクエスト型
＞、＜非同期メソッド呼出し型＞、または、＜イベント
サービス型＞のうちいずれかが選択的に指定される。

【００２７】（CORBAプライオリティ）には、CORBAリク
エストの優先度が定義される。（周期／イベント区分）
には、CORBAリクエストを周期的に行うか、またはイベ
ント的に行うかが定義される。（周期）には、CORBAオ
ブジェクト（クライアント）からCORBAオブジェクト
（サーバ）に対して実施される周期的なリクエストの呼
出し頻度が定義される。呼出しの間隔は、例えばミリ秒
単位で与えられる。（データ長）には、リクエストの引
数のデータ長が定義される。

【００２８】（イベント・タイミング）には、CORBAオ
ブジェクト（クライアント）からCORBAオブジェクト
（サーバ）に対して実施される、イベント的なリクエス
トの呼出しタイミングを表す量が定義される。イベント
的なタイミングを発生する一つの方法として、バラツキ
を含む周期として実現する方法がある。この方法を利用
するには、基本となる呼出しの間隔と、そのバラツキと
を、例えばミリ秒などの単位で与えるようにする。な
お、（イベント・タイミング）をタスク定義部に含めず
に、基本となる呼び出しの間隔を（周期）として指定
し、バラツキを（周期）に対する一定量としても良い。

【００２９】（時間計測の実施の有無）には、時間を計
測するCORBAオブジェクトと、計測しないCORBAオブジェ
クトとが定義される。リアルタイム型のアプリケーショ
ンにおいて、多数のオブジェクト（タスク）につき時間
の計測が同時に実施されると、測定動作による誤差が一
般に大きくなる。よって本実施形態のように、時間を計
測するタスクと、時間を計測しないタスクとを個別に定
義することにより、より正確な測定を必要とする場合、
または評価対象となるシステムの負荷を簡便に測定した
い場合など、評価の目的に応じてタスクを構成すること
が可能になる。また、その実施にかかる時間が計測され
ないタスクを、例えば評価環境に対する負荷として使用
することも可能である。

【００３０】（ユーザ定義送受信部使用の有無）には、
利用者（すなわちユーザ）側で追加定義した送受信部を
使用するか否かが定義される。このように、必要に応じ
て利用者側で追加定義した送受信部を組み込み可能にす
ることで、リクエストの引数の詳細定義、ＣＰＵに負荷
を与えるための処理内容の追加など、評価対象となるシ
ステムを利用者がより厳密に定義でき、評価対象システ
ムの実際の稼動状態により近い評価を実施することが可
能になる。

【００３１】図２において、全体構成定義部には、（測
定時間）、及び、（リアルタイムＰＯＡポリシー定義）
なる内容が定義される。（測定時間）には、タスク定義
部に記載された各CORBAオブジェクト（クライアント）
がリクエストを実施する時間が定義される。すなわち各
CORBAオブジェクト（クライアント）は、（測定時間／
周期）で算出される回数分だけ、CORBAオブジェクト
（サーバ）との間でのリモート呼び出しを実施する。な
お（測定時間）に定義される値は、測定動作の開始時に
オペレータにより入力される。

【００３２】（リアルタイムPOAポリシー定義）リアル
タイムCORBA仕様においては、リクエストに優先度を与
える方法として、サーバ側で固定的に優先度を定義する
サーバデクリアードモデルと、クライアント側からリク
エストに優先度をつけるクライアント・プロパゲーティ
ッド・モデルのいずかを選択することになっている。こ
の選択は、POA(Portable ObjectAdapter)というCORBAオ
ブジェクト（サーバ）を構成する要素オブジェクトの構
築時点に、所定の手順でポリシーを指定することによっ
て定義することがリアルタイムCORBA仕様として定めら
れており、（リアルタイムPOAポリシー定義）はこれを
指定する。

【００３３】図１において、まず、メインシステム１に
おいて測定動作コントロール部１２が起動され、またサ
ブシステム２−１〜２−ｎにおいてサブシステム起動部
２１が起動される。測定動作コントロール部１２は、ユ
ーザ・インタフェース部１１から与えられる起動指示に
より、評価パラメータ１３の指定に従って、評価の対象
とするCORBAオブジェクトを起動する。また測定動作コ
ントロール部１２は、各サブシステム２−１〜２−ｎの
サブシステム起動部２１に対して、評価パラメータ１３
により定められるオブジェクトを起動する指示を出す。

【００３４】システムのオペレータは、全てのCORBAオ
ブジェクト（クライアントおよびサーバ）の起動の完了
を確認すると、ユーザ・インタフェース部１１を介して
測定動作コントロール部１２に測定開始指示を発行す
る。これにより、各CORBAオブジェクトのうち、全ての
クライアントに対して測定開始がリクエストされる。

【００３５】そうすると、測定処理が開始される。測定
処理においては、評価パラメータ１３の全体構成定義部
で与えた測定時間の間、CORBAリクエスト呼出しが行わ
れ、評価パラメータ１３のタスク定義部で時間計測有り
と指定されたCORBAオブジェクト（以下、測定対象CORBA
オブジェクトと称する）に対して、リクエストの応答時
間、遅延時間、ジッタ時間の測定が繰り返される。

【００３６】測定結果は、測定動作コントロール部１２
に返される。本実施形態では、測定動作コントロール部
１２を、CORBAオブジェクト（サーバ）として構成す
る。これにより、メインシステム上の測定対象CORBAオ
ブジェクトだけでなく、全てのサブシステム２−１〜２
−ｎ上の測定対象CORBAオブジェクトから測定結果を得
ることが可能となる。最終的に、測定結果はユーザ・イ
ンタフェース部１１に返され、オペレータに知らされ
る。

【００３７】図３は、CORBA通信方式のうち＜リクエス
ト・リプライ型＞における測定対象CORBAオブジェクト
間で実施される処理について、本実施形態における動作
例を説明するための概念図である。図３において、測定
開始指示を受けた測定動作コントロール部１２は、評価
パラメータ１３に記載されている全ての測定対象CORBA
オブジェクトのうち、クライアント側の測定開始メソッ
ドを呼び出す。

【００３８】一般にCORBAでは、クライアント側は必ず
しもCORBAオブジェクトとして構成する必要は無い。し
かしながら、本実施形態に示すようにクライアントをCO
RBAオブジェクトとして構成することにより、メインシ
ステム、サブシステムの区別にかかわらず、全てのクラ
イアントに対する起動と測定動作の開始を、測定動作コ
ントロール部１２から呼び出すことが可能になる。

【００３９】測定開始の指示をクライアントに出す際
に、測定動作コントロール部１２は、必要となる評価パ
ラメータ１３をクライアント側に渡す。測定開始メソッ
ドを呼び出されたクライアントは、評価パラメータ１３
に示される優先度に応じて、実際に測定対象CORBAオブ
ジェクト（サーバ）のリモート呼び出しを行なうスレッ
ドを生成する。

【００４０】＜リクエスト・リプライ型＞の通信方式に
おいては、クライアント−サーバ間のリクエストは、評
価パラメータ１３により与えられる周期と測定時間とか
ら、（測定時間／周期）で表される回数だけ実施され
る。このリクエスト回数をN回とする。本実施形態にお
いては、各回のリクエストにおいて、前記開始時刻であ
るリクエスト直前の時刻（aとする）と、前記終了時刻
であるリクエスト直後の時刻(bとする)とを、稼動機器
上のシステムタイムから計測するようにする。これによ
り、リクエストしてからリプライが返されるまでの応答
時間（すなわち(b-a)）が、N回測定されることになる。

【００４１】一方、測定対象CORBAオブジェクト（サー
バ）側では、前記受信時刻であるリクエストを受け取っ
た直後の時刻(cとする)を、稼動機器上のシステムタイ
ムから計測する。そうして、サーバにおいてN回のリク
エストが受信されることにより、受信側での受信間隔が
（N−１）回分のデータとして測定されることになる。

【００４２】これらの測定結果は、クライアント側およ
びサーバ側から測定動作コントロール部１２に返され
る。ただし、時刻(c)については、リプライ時にサーバ
側から一旦クライアント側に返し、クライアント側から
測定動作コントロール部１２に返すようにしてもよい。

【００４３】測定動作コントロール部１２は、測定され
たN回分のa,b,cの各データを得ることができる。メイン
システム１とサブシステム２−１〜２−ｎとのシステム
タイムは、時刻同期部１４，２２の作用により同期して
いるため、測定動作コントロール部１２は通信遅延時間
(c-a)および(b-c)を計測することができる。前記受信時
刻(c)とは別に、リプライ直前の時刻(dとする)を計測し
ても良い。この場合、遅延時間を(c-a)および(d-b)のか
たちで計測することができる。これらの計測データをも
とに、平均値、最大値、最小値、標準偏差など、システ
ムのリアルタイム性能を評価するための指標となる応答
時間、遅延時間、およびジッタ時間の統計量（値）が算
出される。これらの指標は、最終的にユーザ・インタフ
ェース部１１により、測定結果としてオペレータに提示
される。なお、これらの統計量（値）は、測定対象CORB
Aオブジェクト内で算出し、その結果を測定動作コント
ロール部１２に返すようにしても良い。

【００４４】また、リアルタイム性能のほか、CORBAを
用いた対象システムの成立性を評価するための指標とし
てＣＰＵ、メモリ、及び通信の負荷状況がある。これら
の指標は、遅延時間の測定中に測定状況監視部１５によ
り監視され、ユーザ・インタフェース部１１により測定
状況としてオペレータに提示される。なお測定状況監視
部１５の機能を実現するための手段としては、市販のモ
ニタツールなどを使用してもよい。

【００４５】図４は、本発明に係わる分散型計算機シス
テムを構築する際の手順を示す図である。図４におい
て、測定システムIDL（Interface Definition Languag
e）は、図１に示される測定動作コントロール部１２、
サブシステム起動部２１や、評価対象CORBAのオブジェ
クトのインタフェースを定義する。測定システムIDLの
実装の例としては、以下に示されるような内容が記載さ
れる。

【００４６】

【表１】

【００４７】図４において、測定システムソースプログ
ラム部３は、図１及び図３において説明された動作を実
装するプログラムが記述されたソースファイルである。
すなわち、測定システムソースプログラム部３は、測定
システムIDLで定義された評価対象のCORBAオブジェクト
のサーバ、及びクライアントの実装クラス（CORBAで
は、サーバントと呼称される）を含む。つまり、測定シ
ステムソースプログラム部３には、次の（１）〜（８）
を実装するクラスが含まれる。

【００４８】（１）リクエスト・リプライ型のリクエス
トを受け取るサーバオブジェクト実装クラス （２）リクエスト・リプライ型のリクエストを行なうク
ライアントオブジェクト実装クラス （３）ワンウェイ・リクエスト型のリクエストを受け取
るサーバオブジェクト実装クラス （４）ワンウェイ・リクエスト型のリクエストを行なう
クライアントオブジェクト実装クラス （５）非同期メソッド呼出し型のリクエストを受け取る
サーバオブジェクト実装クラス（ただし、CORBA規格上
では（５）は（１）と同一のものである） （６）非同期メソッド呼出し型のリクエストを行なうク
ライアントオブジェクト実装クラス （７）イベントサービスにイベントを渡すイベントサプ
ライア実装クラス （８）イベントサービスからイベントを受け取るイベン
トコンシューマ実装クラス なお、測定システムソースプログラム部３には、測定動
作コントロール部１２実装するオブジェクト、およびサ
ブシステム起動部２１を実装するオブジェクトのソース
プログラムも含まれる。なお、これらのオブジェクトを
ソースプログラムの形式でなく、ライブラリの形で提供
することも可能である。

【００４９】本発明においては、測定システムソースプ
ログラム部３で定義されているオブジェクトをそのまま
使用し、評価パラメータ１３のみを例えばエディタで記
述するだけでも、対象システムを評価することは可能で
ある。ただし、測定システムソースプログラム部３にお
いては、リクエストの引数として可変長のバイト列であ
るCORBA規格のオクテットシーケンスが与えられている
だけである。このため、通信負荷を中心に評価する場合
には十分であるとしても、より多くの引数を使用するシ
ステムや、構造体などを使用したより複雑な構造の引数
を使用するシステムを評価する場合には、その評価の目
的によって十分でないケースがあると考えられる。

【００５０】そこで、図４の測定システムIDLで定義さ
れているrequestメソッド以外に、評価対象となるシス
テムで使用する引数の定義を与えられるようにする必要
がある。これを定義するために、評価対象に応じて、利
用者がユーザ定義用IDLを別途作成する。このIDL記述
は、次に示されるソースコードのように、測定システム
IDLの内容を継承して、簡潔に記載することができる。

【００５１】

【表２】

【００５２】さらに、IDL定義のほかに、そのユーザ定
義の引数となるデータの送信を行う箇所と、受信を行う
箇所の動作も与えなくてはならない。図４におけるユー
ザ定義送信部および受信部（符号４）は、その処理内容
を実装するプログラムである。

【００５３】符号４に相当するソースコードをC++やＪ
ａｖａ（登録商標）などのオブジェクト指向言語で記述
することにより、継承機構を利用できる。このようにす
ると、本発明にかかるシステムの利用者は、所定のメソ
ッド名の中に、リクエストを出力する部分およびリクエ
ストを入力する部分の最小限のコード記述を追加するだ
けで、図３に示される挙動をそのオブジェクトに与える
ように構成することが可能である。従って、動作ロジッ
クの全てを記述する必要が無くなり、利用者の便宜を図
ることができる。

【００５４】すなわち、リクエストリプライを実施する
具体オブジェクトを定義するには、それぞれ、 ・リクエスト・リプライ型通信を受け取るサーバオブジ
ェクト実装クラス ・リクエスト・リプライ型通信をリクエストするクライ
アントオブジェクト実装クラス という、２つの実装クラスをそれぞれ継承するクラスを
定義するようにする。

【００５５】このうち、サーバ側については、符号４の
ソースコードに受信処理を記述する。すわなち、ユーザ
定義IDLで定義した引数のうち、inパラメータのデータ
を受け取るコードと、outパラメータのデータを構築す
るコードとを記述する。一方、クライアント側について
は、ユーザ定義IDLで定義したパラメータのうち、inパ
ラメータを与えるデータを構築するコードと、outパラ
メータを受け取るコードとを記述すればよい。

【００５６】また、評価の目的により、ＣＰＵ、メモリ
などに負荷を与えるための処理内容を、符号４のソース
コードに追加することもできる。なお、ＣＰＵ、メモリ
などに負荷を与えるための機能は、図１に示されるＣＰ
Ｕ／メモリ負荷印加部１６のように、専用の機能ブロッ
クにより実現することも可能である。

【００５７】以上のようにソースコードを記述したの
ち、通常のCORBAアプリケーションを構築するのと同様
に、使用するORB（Object Request Broker）製品用のID
Lコンパイラを使用して、スタブおよびスケルトンと呼
ばれるソースコードを作成する。そして、これらのソー
スコードとその他のソースプログラムを合わせてコンパ
イルすることにより、本発明に係わる分散型計算機シス
テムを構築することができる。

【００５８】この構成によると、メインシステム１と各
サブシステム２−１〜２−ｎとが異なるハードウェアま
たはＯＳのもとに構築されている場合や、コンパイル言
語、ORB製品が異なる場合についても、それぞれの環境
を使用して、分散型計算機システムの評価環境を構築す
ることが可能である。

【００５９】また本実施形態によれば、特に、リクエス
トに対する応答時間や遅延時間、ジッタ時間などの性能
の保証を必要とするリアルタイムシステムの構築におい
て、クライアント−サーバ間のリモート呼び出しのリア
ルタイム性能を見積もることが可能となる。よって、リ
クエストの頻度、データ量が様々に異なるリモート呼び
出しを行なう個々のシステムに応じて、適用すべき通信
方式と、リクエストの処理の優先度を事前に選択するこ
とができるようになる。すなわち、個々のシステムにつ
き、その設計方式の妥当性を事前に評価することが可能
となり、従って後戻り作業を極小化でき、システム構築
にかかる作業工程面やコスト面でのインパクトを軽減す
ることが可能になる。

【００６０】なお、本発明は上記実施の形態に限定され
るものではない。例えば、図１から想起されるように、
互いに主従関係にあるメインシステムとサブシステム群
とから構成されるシステムだけでなく、互いに対等の関
係にあるサブシステム群により構成されるネットワーク
システムに対しても、本発明を適用することができる。

【００６１】また上記においては、メインシステムとサ
ブシステム群とがＬＡＮで接続される形態を示したが、
これに限らず、メインシステムとサブシステム群とが同
一の構成機器内に存在し、ネットワークを介さずに、例
えばＶＭＥバスや共有メモリなどを介して接続される形
態のシステムにおいても、本発明を適用することが可能
である。このほか、本発明の要旨を逸脱しない範囲で種
々の変形実施を行うことができる。

【００６２】

【発明の効果】以上詳述したように本発明によれば、分
散型計算機システムにおいて要求される性能を達成する
ために如何なる通信方式を適用し、如何に処理の優先度
を割り当てるべきかを、システムの設計段階において簡
易に評価できるようになり、これによりシステム構築に
かかるインパクトを軽減することができる。

【図面の簡単な説明】

【図１】 本発明にかかる分散型計算機システムの構成
例を示す図。

【図２】 図１に示されるシステムで使用される評価パ
ラメータ１３の構成を示す模式図。

【図３】 ＜リクエスト・リプライ型＞における測定対
象CORBAオブジェクト間で実施される処理について、本
実施形態における動作例を説明するための概念図。

【図４】 本発明に係わる分散型計算機システムを構築
する際の手順を示す図。

【符号の説明】

１…メインシステム ２−１〜２−ｎ…サブシステム ３…測定システムソースプログラム部 １１…ユーザ・インタフェース部 １２…測定動作コントロール部 １３…評価パラメータ １４、２２…時刻同期部 １５…測定状況監視部 １６…メモリ負荷印加部 ２１…サブシステム起動部

───────────────────────────────────────────────────── フロントページの続き (72)発明者 松本 一教 東京都府中市東芝町１番地 株式会社東芝 府中事業所内 (72)発明者 下原 幸一 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝小向工場内 (72)発明者 河込 和宏 東京都府中市東芝町１番地 株式会社東芝 府中事業所内 Ｆターム(参考） 5B042 GA12 HH20 MC21 5B045 BB01 BB28 BB42 GG01 5B098 AA10 GA01 GC16

Claims (4)

【特許請求の範囲】
1. 【請求項１】 クライアントがサーバのオブジェクトに
   アクセスするためのサービス・リクエストを実施する分
   散型計算機システムにおいて、 前記クライアントとして振る舞う第１の分散オブジェク
   ト部品と、前記サーバとして振る舞う第２の分散オブジ
   ェクト部品とを、分散型計算機システム内において所定
   の数だけ起動する性能評価手段を具備し、 前記第１の分散オブジェクト部品は、 前記分散型計算機システムにおけるクライアント−サー
   バ間のリモート呼び出しに適用される複数の通信方式を
   実装し、各通信方式に基づいて前記第２の分散オブジェ
   クト部品とのリモート呼び出しを実施し、当該リモート
   呼び出しの開始時刻及び終了時刻を計測するものであ
   り、 前記第２の分散オブジェクト部品は、 前記リモート呼び出しが実施されるにあたり前記第１の
   分散オブジェクト部品から自己宛てに送出されるメッセ
   ージの受信時刻を計測するものであり、 前記性能評価手段は、 前記第１および第２の分散オブジェクト部品で計測され
   た前記開始時刻、終了時刻、及び受信時刻をもとに、前
   記分散型計算機システムにおける前記各通信方式の性能
   を評価することを特徴とする分散型計算機システム。
2. 【請求項２】 前記通信方式に、＜リクエスト／リプラ
   イ型＞、＜ワンウェイ・リクエスト型＞、＜非同期メソ
   ッド呼出し型＞、または、＜イベントサービス型＞のう
   ち少なくとも一つを含むことを特徴とする請求項１また
   は２に記載の分散型計算機システム。
3. 【請求項３】 前記性能評価手段は、 前記リモート呼び出しのリクエストの頻度、リクエスト
   で渡されるデータ量、リクエストの優先度、および前記
   通信方式のうちどの方式を使用するかに関する情報を少
   なくとも含む評価パラメータに従って、前記第１および
   第２の分散オブジェクト部品を起動することを特徴とす
   る請求項１に記載の分散型計算機システム。
4. 【請求項４】 前記評価パラメータに、 前記第１および第２の分散オブジェクト部品のリクエス
   トの引数の詳細定義、および、当該オブジェクト間の通
   信における送信、受信の際の入出力のデータの処理を利
   用者が追加して定義するための情報を含むことを特徴と
   する請求項３に記載の分散型計算機システム。