(57)【要約】【課題】ポリシの変更が容易な分散処理システム用サーバ装置を提供する。【解決手段】リモート機器からのリクエストをＣＯＲＢＡ仕様の基本サービス提供と分散環境におけるオブジェクト間のやり取りを実現するためのミドルウエアを介して受け付けることが可能な分散オブジェクト生成すると共に、生成されるオブジェクトは分散環境におけるオブジェクトを特定する情報としてのオブジェクト・リファレンスの生成や破棄、オブジェクトの活性化などの機能を司るコンポーネントにより管理されるものであり、前記コンポーネントはその振る舞いまたは通信プロトコルのうち、少なくともいずれかを定めた仕様であるＰＯＡ（ポータブル・オブジェクト・アダプタ）により定まる仕様に基づいて動作させるようにしたサーバ装置において、ＰＯＡ１２に与える仕様を、書き換え可能に保持する保持手段３０から取得してＰＯＡに設定する設定手段２０を備えたことを特徴とする。【選択図】　　図１
2004078457.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークで接続されたリモート機器からのリクエストをＣＯＲＢＡ仕様の基本サービス提供と分散環境におけるオブジェクト間のやり取りを実現するためのＯＲＢを介して受け付ける分散オブジェクト生成すると共に、生成されるオブジェクトは分散環境におけるオブジェクトを特定する情報としてのオブジェクト・リファレンスの生成や破棄、オブジェクトの活性化などの機能を司るコンポーネントにより管理されるものであり、前記コンポーネントはその振る舞いまたは通信プロトコルのうち、少なくともいずれかを定めたＰＯＡ（ポータブル・オブジェクト・アダプタ）に対する設定パラメータに基づいて動作させるようにしたサーバ装置において、
前記ＰＯＡに与える前記設定パラメータを、書き換え可能に保持する保持手段から取得して前記ＰＯＡの生成・活性化時にこのＰＯＡに設定する手段
を備えたことを特徴とする分散処理システム用サーバ装置。
【請求項２】
ネットワークで接続されたリモート機器からのリクエストをＣＯＲＢＡ仕様の基本サービス提供と分散環境におけるオブジェクト間のやり取りを実現するためのＯＲＢを介して受け付ける分散オブジェクト生成すると共に、生成されるオブジェクトは分散環境におけるオブジェクトを特定する情報としてのオブジェクト・リファレンスの生成や破棄、オブジェクトの活性化などの機能を司るコンポーネントにより管理されるものであり、前記コンポーネントはその振る舞いまたは通信プロトコルのうち、少なくともいずれかを定めたＰＯＡ（ポータブル・オブジェクト・アダプタ）に対する設定パラメータに基づいて動作させるようにしたサーバ装置において、
前記ＰＯＡに与える前記設定パラメータを、書き換え可能に保持する保持手段と、
この保持手段から前記仕様を取得して前記ＰＯＡの生成時にこのＰＯＡに設定する手段とを備えたことを特徴とする分散処理システム用サーバ装置。
【請求項３】
ネットワークで接続されたリモート機器からのリクエストをＣＯＲＢＡ仕様の基本サービス提供と分散環境におけるオブジェクト間のやり取りを実現するためのＯＲＢを介して受け付ける分散オブジェクト生成すると共に、生成されるオブジェクトは分散環境におけるオブジェクトを特定する情報としてのオブジェクト・リファレンスの生成や破棄、オブジェクトの活性化などの機能を司るコンポーネントにより管理されるものであり、前記コンポーネントはその振る舞いまたは通信プロトコルのうち、少なくともいずれかを定めたＰＯＡ（ポータブル・オブジェクト・アダプタ）に対する設定パラメータに基づいて動作させるようにしたサーバ装置において、
前記ＯＲＢに与える設定パラメータと前記ＰＯＡに与える前記設定パラメータを、書き換え可能に保持する保持手段から取得して前記ＯＲＢに与える設定パラメータは前記ＯＲＢの初期化時にこのＯＲＢに設定すると共に、前記取得した設定パラメータは前記ＰＯＡの生成時にこのＰＯＡに設定する設定手段を備えたことを特徴とする分散処理システム用サーバ装置。
【請求項４】
ネットワークで接続されたリモート機器からのリクエストをＣＯＲＢＡ仕様の基本サービス提供と分散環境におけるオブジェクト間のやり取りを実現するためのＯＲＢを介して受け付ける分散オブジェクト生成すると共に、生成されるオブジェクトは分散環境におけるオブジェクトを特定する情報としてのオブジェクト・リファレンスの生成や破棄、オブジェクトの活性化などの機能を司るコンポーネントにより管理されるものであり、前記コンポーネントはその振る舞いまたは通信プロトコルのうち、少なくともいずれかを定めたＰＯＡ（ポータブル・オブジェクト・アダプタ）に対する設定パラメータに基づいて動作させるようにしたサーバ装置における前記ＰＯＡの設定方法において、
保持手段を設けて前記ＰＯＡに与える前記設定パラメータを、書き換え可能に保持させ、前記ＰＯＡの生成時に、前記設定パラメータを前記保持手段から取得して当該生成したＰＯＡに設定することを特徴とする分散処理システム用サーバ装置におけるＰＯＡの設定方法。
【請求項５】
ネットワークで接続されたリモート機器からのリクエストをＣＯＲＢＡ仕様の基本サービス提供と分散環境におけるオブジェクト間のやり取りを実現するためのＯＲＢを介して受け付ける分散オブジェクト生成すると共に、生成されるオブジェクトは分散環境におけるオブジェクトを特定する情報としてのオブジェクト・リファレンスの生成や破棄、オブジェクトの活性化などの機能を司るコンポーネントにより管理されるものであり、前記コンポーネントはその振る舞いまたは通信プロトコルのうち、少なくともいずれかを定めたＰＯＡ（ポータブル・オブジェクト・アダプタ）に対する設定パラメータに基づいて動作させるようにしたサーバ装置におけるＯＲＢおよびＰＯＡの設定方法において、
前記ＯＲＢに与える設定パラメータと前記ＰＯＡに与える前記設定パラメータを、書き換え可能に保持する保持手段から取得して前記取得したＯＲＢに与える設定パラメータは前記ＯＲＢの初期化時にこのＯＲＢに設定すると共に、前記取得した設定パラメータは前記ＰＯＡの生成時にこのＰＯＡに設定することを特徴とする分散処理システム用サーバ装置におけるＯＲＢおよびＰＯＡの設定方法。
【請求項６】
ネットワークで接続されたリモート機器からのリクエストをＣＯＲＢＡ仕様の基本サービス提供と分散環境におけるオブジェクト間のやり取りを実現するためのＯＲＢを介して受け付ける分散オブジェクト生成すると共に、生成されるオブジェクトは分散環境におけるオブジェクトを特定する情報としてのオブジェクト・リファレンスの生成や破棄、オブジェクトの活性化などの機能を司るコンポーネントにより管理されるものであり、前記コンポーネントはその振る舞いまたは通信プロトコルのうち、少なくともいずれかを定めたＰＯＡ（ポータブル・オブジェクト・アダプタ）に対する設定パラメータに基づいて動作させるようにしたサーバ装置におけるＰＯＡの設定プログラムであって、
ＰＯＡが生成されると、当該ＰＯＡに与える前記設定パラメータを、内容変更可能に保持する保持手段から取得する取得処理手段と、
この取得処理手段にて取得した設定パラメータを当該生成したＰＯＡに設定する手段と
を具備することを特徴とする分散処理システム用サーバ装置におけるＰＯＡの設定のためのコンピュータプログラム。
【請求項７】
ネットワークで接続されたリモート機器からのリクエストをＣＯＲＢＡ仕様の基本サービス提供と分散環境におけるオブジェクト間のやり取りを実現するためのＯＲＢを介して受け付ける分散オブジェクト生成すると共に、生成されるオブジェクトは分散環境におけるオブジェクトを特定する情報としてのオブジェクト・リファレンスの生成や破棄、オブジェクトの活性化などの機能を司るコンポーネントにより管理されるものであり、前記コンポーネントはその振る舞いまたは通信プロトコルのうち、少なくともいずれかを定めたＰＯＡ（ポータブル・オブジェクト・アダプタ）に対する設定パラメータに基づいて動作させるようにしたサーバ装置におけるＯＲＢおよびＰＯＡの設定変更プログラムであって、
内容変更可能な保持手段に保持させてある前記ＯＲＢに与える設定パラメータを、前記ＯＲＢの初期化時に取得してこのＯＲＢに設定する設定処理手段と、
内容変更可能な前記保持手段に保持させてあるＰＯＡに与えるための前記設定パラメータを、ＰＯＡが生成されると取得してこの取得した設定パラメータを当該生成したＰＯＡに設定する手段と
を具備することを特徴とする分散処理システム用サーバ装置におけるＯＲＢおよびＰＯＡの仕様変更のためのコンピュータプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワークで接続される複数の計算機要素による分散処理環境、例えば、ＣＯＲＢＡを導入した分散処理システムの如き、分散オブジェクト環境に係わり、特にネットワークで接続されたリモート機器からのリクエストを受け付けることが可能な分散オブジェクトを有するサーバのＯＲＢやＰＯＡの設定を簡便に行えるようにした分散処理システム用サーバ装置およびその設定方法および設定のためのコンピュータプログラムに関する。
【０００２】
【従来の技術】
多数の組み込み機器（エンベッド機器）を用いて構成したシステムであって、そのシステムの組み込み機器それぞれがＣＰＵ（プロセッサ）を制御の中枢に持つ独立したインテリジェントなシステムであり、分散環境をもつシステムがある。
【０００３】
ここで、分散環境とは、ネットワーク・アプリケーションを構築する主要な技術の一つである分散オブジェクト指向技術による処理環境であって、これはデータの処理や操作を、手続きの流れとしてではなく、「もの（オブジェクト）」同士の関係としてとらえる考え方で、各種オブジェクト（オブジェクト指向プログラミングにおいて、プログラムを構成する基本的なモジュール）を分散配置して処理を分担させて進めていく方式である。
【０００４】
そして、複数のオブジェクトがあって、各オブジェクトに定義するオペレーションを、所定のインタフェース言語（ＩＤＬ）で定義する仕様を与え、定義されたオブジェクトをクライアントから所定の手続で呼べるようにするためのルールを決めたものとしてＣＯＲＢＡ仕様がある。
【０００５】
周知のように、ＣＯＲＢＡとは、“Ｃｏｍｍｏｎ　Ｏｂｊｅｃｔ　Ｒｅｑｕｅｓｔ　Ｂｒｏｋｅｒ　Ａｒｃｈｉｔｅｃｔｕｒｅ”の略であり、分散オブジェクト指向技術における標準的技術の一つであって、分散オブジェクト技術の標準化団体であるＯＭＧ（Ｏｂｊｅｃｔ　Ｍａｎａｇｅｍｅｎｔ　Ｇｒｏｕｐ）　が策定した規格である。
【０００６】
ＣＯＲＢＡは、個別のハードウエアやＯＳ（オペレーティング・システム）に依存せずに、分散したオブジェクトをネットワーク上で共有化し、統合するアーキテクチャの開発を目的とした標準仕様であり、ＣＯＲＢＡの規格では、バージョン２．４　（ＣＯＲＢＡ　２．４　）において、特にリアルタイム処理分野や、組み込みシステム分野を対象とした、処理優先度の概念を分散オブジェクトに導入した規格としてリアルタイム・コルバ（Ｒｅａｌ−ｔｉｍｅ　ＣＯＲＢＡ、以下、ＲＴ−ＣＯＲＢＡと称する）が追加された。そして、その処理優先度に関する標準仕様の部分を、特に、ＲＴ−ＣＯＲＢＡ　１．０と呼んでいる。従って、ＣＯＲＢＡ２．３以前の規格には、ＲＴ−ＣＯＲＢＡ仕様は含まれていない。
【０００７】
また、ＲＴ−ＣＯＲＢＡ１．０自体は、ＣＯＲＢＡのオプション仕様であるので、ＣＯＲＢＡ２．４以後に対応するＣＯＲＢＡ製品であっても、必ずしもＲＴ−ＣＯＲＢＡ仕様に準拠しているとは限らない。従って、以下で、「ＲＴ−ＣＯＲＢＡを含まないＣＯＲＢＡ」と記載する場合は、上記の両者を指すものである。
【０００８】
ＲＴ−ＣＯＲＢＡの環境においては、優先度を扱うひとつの典型的な方法として、オブジェクトは、そのオブジェクトを生成作成する段階で所望の優先度を指定しておき、当該優先度で活性化しておく方法がある（サーバ・デクリアード優先度）。また、別の方法では、クライアントがリクエストを出す際に、処理優先度をオブジェクトに伝え、その優先度でオブジェクトの処理を実施する方法もある（クライアント・プロパゲーティッド優先度）。いずれの方法にしても、そのオブジェクトに対するリクエストが、リモートにあるクライアントから到着したとき、先に指定した優先度を与えたタスクが生成され、リクエストの処理をそのタスク上で実行する。処理の要求（リクエスト）が同時に多数発生した場合、優先度の高いリクエストから実行されることになるが、優先度が同じ場合は、所定のタスク・スケジューリングに従って処理される。
【０００９】
これらタスクへの優先度の割り当てや、タスク・スケジューリングなどの処理は、実際にはＯＳが実施するのであるが、後に説明するＯＲＢが、これらの処理の橋渡しを行う。
【００１０】
ＣＯＲＢＡ仕様のＯＲＢ環境で動作するオブジェクトはＣＯＲＢＡオブジェクトと呼ばれ、一般的な利用方法として、ＣＯＲＢＡオブジェクトは一つ以上のオペレーションを提供する。そして、ＣＯＲＢＡオブジェクトが用意するオペレーションを呼び出すには、ＯＲＢを経由してオペレーションの呼び出しを実施すればよい。すなわち、ＯＲＢを利用してオペレーションの呼び出しを実施するプログラムがＣＯＲＢＡのクライアントである。ＣＯＲＢＡクライアントは、同時にＣＯＲＢＡオブジェクトであってもよいし、また、そうでなくともよい。
【００１１】
また、ＣＯＲＢＡの分野では、オペレーションの呼び出しに伴う通信のことを、特に「リクエスト」とよぶ。以下では、「リクエスト」と「オペレーションの呼び出し」は、同じ意味で使用している。
【００１２】
あるオブジェクトが、どのようなリクエストを受け付けることが可能であるかという情報は、リクエストを発行する側で知っておく必要がある。従って、どのようなインタフェースを有するかという情報を明らかにするために、ＣＯＲＢＡにおいてはＩＤＬ（Ｉｎｔｅｒｆａｃｅ　Ｄｅｆｉｎｉｔｉｏｎ　Ｌａｎｇｕａｇｅ）が利用される。
【００１３】
このように、ＣＯＲＢＡは、ヘテロジニアスな分散環境を許容する。ＯＳが違っていても差し支えないのである。
【００１４】
その一方で、特にＲＴ−ＣＯＲＢＡを使用する場合においては、優先度設定や各種ポリシの調整の問題が付きまとう。
【００１５】
すなわち、ここで対象とする各組み込み機器はＣＰＵを制御の中枢とするインテリジェントな機器であるが、それぞれ自身に組み込まれているＯＳの管理下で稼動するような仕組みを持つ。そして、それぞれは開発したベンダの違いにより、使用ＯＳの種類も様々である。このような組み込み機器同士がネットワークで繋がっているようなシステムの場合、あるいはこのような組み込み機器が組み込み機器制御用のＰＣ（コンピュータ）に繋がっているような環境を許容する。このような場合には、各組み込み機器に対する処理の優先度（プライオリティ）については、重要度や緊急性の度合に応じた設定となる必要がある。
【００１６】
例えば、組み込み機器が各種センサなどの場合、ここでのオブジェクトはクライアントからの要求により応答するサーバとして動作するサーバ側がセンサである以上、クライアントからの要求される処理それぞれに優先度があり、重要度や緊急性の高い処理ほど、高い優先度を与えて処理を優先させる必要がある。煙検知センサと炎検知センサがあったとして、これが火災検知システムとしてのセンサとして機能しているならば、煙検知処理より火炎検知処理の要求の方が高い優先度で処理されなければならないといった具合である。
【００１７】
ＲＴ−ＣＯＲＢＡ仕様を採用している場合には、ＣＯＲＢＡ世界独自の優先度（ＣＯＲＢＡプライオリティ）があり、また、ＯＳを採用していることからそのＯＳ独自の優先度（ネイティブ・プライオリティ）もあって、ＣＯＲＢＡ世界ではＣＯＲＢＡプライオリティで優先度を指定して授受し、ＯＳに渡すときはネイティブ・プライオリティに変換する。
【００１８】
ＣＯＲＢＡプライオリティが使用する優先度値は例えば０〜３２７６７といった具合に幅があり、しかも、ＣＯＲＢＡプライオリティとネイティブ・プライオリティの間にはその値と優先度の高低には共通性はなく、各種ＯＳによってもその扱いは異なっている。そのため、ＣＯＲＢＡにおいてはその優先度値の変換を行うためのマップである優先度マップを用意してＯＲＢにおいてこの優先度マップを利用して優先度値の変換を行い、与えた優先度値対応の優先度で処理されるように伝達する。
【００１９】
しかし、システムを構築した段階では、各組み込み機器やネットワークの伝送路状態が正確には把握できないので、実際に運用試験を行ってみないと、各機器の各オブジェクトが想定通りの優先度で機能して満足のいく動作を確保できているか否かはわからない。そのため、運用試験を試みるが、多くの場合、各機器の各オブジェクトに与える優先度値や優先度マップが適正なものとなっていないことが多い。そこで、手直しが必要となる。
【００２０】
また、ポリシなどに関しても運用試験をして、結果を知り、目的の動作を確保できるよう、条件の手直しをすることになる。
【００２１】
分散処理システムのサーバ装置においては、ＯＲＢやＰＯＡに優先度マップやポリシ対応の条件となるよう設定して運用することになるが、これら条件の手直しや優先度マップの手直しは、これらの変更すべき値や条件がＣＯＲＢＡサーバ・プログラムに埋め込まれているがために、プログラムの変更という手続が必要となり、簡単なものではない。
【００２２】
すなわち、ソースプログラムの修正と修正後のソースプログラムのコンパイルと云う作業が入り、はじめて実行形式のＣＯＲＢＡサーバ・プログラムが完成する。ポリシや優先度を手直しするにはこのような工程を踏むことから、新しい設定での運用試験、その結果をみて設定の変更、そして、再び運用試験といった手順を繰り返す試行錯誤的な調整作業は非能率的であり、調整コストの増大を招く。
【００２３】
【発明が解決しようとする課題】
ＣＯＲＢＡ仕様の分散処理システムにおいては、組み込み機器を所望に組み合わせてネットワークで接続し、サーバ側となる各組込み込み機器のオブジェクトを、リモート側となるクライアント側からリクエストして動作させ、結果を受け取ってクライアント側での処理に利用する。各組み込み機器はそれぞれ任意のＯＳ上で動作するようにしており、従って、リクエストに対する処理の優先度や伝送の条件、動作の条件などをクライアント側およびサーバ側でそれぞれ設定して目的の動作状態が得られるようにする。
【００２４】
分散環境であるが故に、所期の動作を確保するためには、クライアント側はもちろんのこと、サーバ側としても接続条件や動作条件などの詳細であるポリシに従った条件設定を行い、その条件下でクライアント側と接続し、動作させる必要があるわけである。
【００２５】
この設定について、サーバ側から眺めてみると、
（ａ）使用するサーバ・プロトコル・ポリシ
（ｂ）スレッド・プール・ポリシ
（ｃ）優先度ポリシ
（ｄ）プライオリティ・バンド
（ｅ）スレッド・ポリシ
（ｆ）その他
といった各種ポリシに基づく設定が必要である。ＣＯＲＢＡは周知にように、ＯＲＢ（Ｏｂｊｅｃｔ　Ｒｅｑｕｅｓｔ　Ｂｒｏｋｅｒ）、ＲＴ−ＰＯＡ（Ｒｅａｌ−Ｔｉｍｅ　Ｐｏｔａｂｌｅ　Ｏｂｊｅｃｔ　Ａｄａｐｔｅｒ）、オブジェクトという階層に分かれ、これらのうち、ＯＲＢに設定するものとして、優先度マップがあり、ＲＴ−ＰＯＡに設定するものとして上記（ａ）〜（ｆ）があり、オブジェクトに設定するものとして、優先度がある。
【００２６】
ここで、ＯＲＢとは、ＣＯＲＢＡ仕様の機器に設けられるミドルウエアであって、ＣＯＲＢＡの基本サービスを提供すると共に、分散環境におけるオブジェクト間のやり取りを実現するためのメカニズムを提供するソフトウエアであり、リモート・オブジェクト同士の相互的なやり取りを実現するために必要なものであって、オブジェクト間での要求と応答をシームレスに実現するための仲介役としての機能を果たすものである。
【００２７】
また、ＲＴ−ＰＯＡはＲＴ−ＣＯＲＢＡで定められている優先度を付けたり、ポリシ（方針や原則や方策）を設定したりするためのもので、出番の生じたオブジェクトが生成されて活性化（あるＰＯＡとあるオブジェクトを結びつけてそのＰＯＡの上でそのオブジェクトが動くようにするということを指す）されたそのオブジェクトが、ＲＴ−ＰＯＡ　上で動作することにより、上記優先度やポリシに従った条件で動作することになるものである。
【００２８】
上述の優先度マップは、ＣＯＲＢＡ世界の抽象的な優先度に対してそれぞれのＯＳの持つ優先度の値のどれに該当するか適正なものに変換するためのものであるが、その優先度マップをＣＯＲＢＡサーバ・プログラムに埋め込んでおくことにより、ＯＲＢの初期化時にＣＯＲＢＡオブジェクトから読み出してＯＲＢにセットする。なお、ＣＯＲＢＡサーバ・プログラムはＣＯＲＢＡサーバとしての必要な振る舞いを記述したサーバ・プログラムであり、ＯＲＢの初期化、ＰＯＡやＣＯＲＢＡオブジェクトの生成、活性化などを初めとする必要な処理を司る。
【００２９】
また、ＰＯＡへの設定としては、上述の（ａ）〜（ｆ）があるが、これらのうち、（ａ）の使用するサーバ・プロトコル・ポリシの設定とは、サーバ側でどのプロトコルで通信できるかを設定するもので、ＣＯＲＢＡ固有のプロトコルであるＩＩＯＰの他、ＭＩＯＰ（ｕｎｒｅｌｉａｂｌｅ　Ｍｕｌｔｉｃａｓｔ　Ｉｎｔｅｒ−Ｏｒｂ　Ｐｒｏｔｏｃｏｌ）と呼ばれるプロトコルなど、使用可能なプロトコルのうちのいずれを利用するかを設定するものである。
【００３０】
そして、当該サーバ・プロトコル・ポリシをセットしておくと、オブジェクト・レファレンスにそのプロトコル情報が入り、クライアント側はそれをみてどのプロトコルを使用すればよいかがわかるようになる。
【００３１】
（ｃ）の優先度ポリシの設定とは、分散システム上での優先度の与え方や管理方法を定めるモデルのことを指すもので、ＲＴ−ＣＯＲＢＡ１．０で定められるモデルには、“サーバ・デクリアード・モデル”と“クライアント・プロパゲーティッド・モデル”という２つのモデルが定義されている。オブジェクトに対する優先度の付け方の選択であり、いずれのモデルにするかを決める。“サーバ・デクリアード・モデル”を選択した場合、オブジェクト単位で優先度が設定でき、“クライアント・プロパゲーティッド・モデル”を選択した場合にはクライアント側から指定された優先度でオブジェクトを動作させることができる。
【００３２】
（ｂ）のスレッド・プール・ポリシは、マルチ・スレッドで動作させるＣＯＲＢＡサーバにおいて、スレッドを予め複数、活性化しておき、何時でも直ぐに利用できるようにプールしておく場合での、そのプールするスレッドの数等を設定をするためのポリシである。なお、スレッドとは、ＯＳが１つのアプリケーションの処理を並行して行う場合での処理の最小単位を指すものである。
【００３３】
（ｄ）のプライオリティ・バンドの設定とは、通信にコネクションを張ってそのコネクションを用いて通信する場合の設定のポリシであり、幾つかのコネクションを張って、第１のコネクションは優先度値いくつからいくつまでの範囲に当たる優先度を指定したリクエストに対して利用し、第２のコネクションは優先度値いくつからいくつまでの範囲に当たる優先度を指定したリクエストに対して利用すると云った具合に、優先度値の範囲対応に利用するコネクションを定めるようにする場合でのポリシである。
【００３４】
（ｅ）のスレッド・ポリシは、ＯＲＢの機能で、シングル・スレッドで動作するようにするか、マルチ・スレッドで動作するようにするかを定めるポリシである。（ｆ）のその他は、上述ＲＴ−ＰＯＡ以外のポリシである。
【００３５】
ＣＯＲＢＡ仕様を適用した分散処理システムでは、優先度をはじめ、これらのポリシを適宜に設定して運用に供するが、それらの設定は机上の設定であり、最善をもくろんではいるが、システムを構築した初期段階では、各組み込み機器やネットワークの伝送路状態といった実際の状況を把握しているわけではないので、実際に運用試験を行ってみないと、各機器の各オブジェクトが設定通りの優先度やポリシで想定通りの満足のいく動作を確保できているか否かはわからない。そのため、運用試験を試みるが、多くの場合、手直しが必要となる。
【００３６】
また、ポリシや優先度の手直しは、これらの変更すべき値や条件がオブジェクトに埋め込まれているがために、プログラムの変更という手続が必要となり、簡単なものではない。ソースプログラム上での該当箇所の修正と修正後のソースプログラムのコンパイルと云う作業が入り、はじめて実行形式のプログラムであるオブジェクトが完成するからである。このような工程を踏むことから、ポリシや優先度の手直しには新しい設定での運用試験、その結果をみて設定の変更、そして、再び運用試験といった手順を繰り返す試行錯誤的な調整作業は非能率的であり、調整コストの増大を招く。
【００３７】
また、分散型の組み込みシステムにおけるポリシや優先度は構築対象のシステム全体のリアルタイム性に関わるパラメータであることから、手直ししたい部分を手直しすると、その手直しされた部分（修正部分）が非修正部分に影響を及ぼし、修正部分は意図した通りに改善されても、非修正部分が逆に悪化してしまうということも考えられる。このことから、これらのパラメータの調整作業は非常に困難であり、さらに修正ミスの可能性等も考慮すると、これらの設定値を一括で管理して修正箇所を極小化することが望ましいケースもある。
【００３８】
また、プログラム開発者にとって、ＲＴ−ＣＯＲＢＡを活用したプログラミングを行うには、通常、それぞれのポリシの効果に関する深い理解が要求される。そのため、ＣＯＲＢＡの知識はあっても、ＲＴ−ＣＯＲＢＡの知識や経験のない開発者の場合にはＲＴ−ＣＯＲＢＡの適用システムの開発に参加するのには困難が伴う。各々のエンベッド機器の構築を担当する各開発者がすべてＲＴ−ＣＯＲＢＡに精通することは、教育実施の経費等を考慮すると、現実的に困難であるという課題があった。
【００３９】
従って、このような障壁を除くことができ、優先度マップやポリシ等の変更を容易にするＣＯＲＢＡシステムの早急な開発が嘱望される。
【００４０】
そこで、本発明の目的とするところは、ＣＯＲＢＡサーバ装置におけるポリシ等を容易に変更可能とする分散処理システム用サーバ装置およびその設定方法を提供することにある。
【００４１】
また、ＣＯＲＢＡの知識があってもＲＴ−ＣＯＲＢＡの知識や経験のない開発者でもＲＴ−ＣＯＲＢＡ適用のサーバシステムの開発に参加できるようにしたＣＯＲＢＡサーバ装置におけるポリシ等を容易に変更可能とする分散処理システム用サーバ装置およびその設定方法を提供することにある。
【００４２】
【課題を解決するための手段】
上記目的を達成するため、本発明は次のように構成する。すなわち、ネットワークで接続されたリモート機器からのリクエストをＣＯＲＢＡ仕様の基本サービス提供と分散環境におけるオブジェクト間のやり取りを実現するためのＯＲＢを介して受け付けることが可能な分散オブジェクト生成すると共に、生成されるオブジェクトは分散環境におけるオブジェクトを特定する情報としてのオブジェクト・リファレンスの生成や破棄、オブジェクトの活性化などの機能を司るコンポーネントにより管理されるものであり、前記コンポーネントはその振る舞いまたは通信プロトコルのうち、少なくともいずれかを定めたＰＯＡ（ポータブル・オブジェクト・アダプタ）に対する設定パラメ−タに基づいて動作させるようにしたサーバ装置において、
第１には、前記ＰＯＡの生成時に、前記ＰＯＡに与える前記設定パラメータを書き換え可能に保持する保持手段から取得して前記ＰＯＡに設定する設定手段を備えたことを特徴とする。
【００４３】
また、第２には、前記ＯＲＢに与える優先度管理のための優先度マップと前記ＰＯＡに与える前記設定パラメータを、書き換え可能に保持する保持手段から取得するようにし、前記優先度マップは前記ＯＲＢの初期化時に取得してこのＯＲＢに設定すると共に、前記設定パラメータは前記ＰＯＡの生成時に取得してこのＰＯＡに設定する設定手段を備えたことを特徴とする。
【００４４】
このような構成の本システムは、ネットワークで接続されたリモート機器からのリクエストをＣＯＲＢＡ仕様の基本サービス提供と分散環境におけるオブジェクト間のやり取りを実現するためのメカニズムを提供するミドルウエア（ＯＲＢ）を介して受け付けることが可能な分散オブジェクト生成すると共に、生成されるオブジェクトは分散環境におけるオブジェクトを一意に特定する情報であるオブジェクト・リファレンスの生成や破棄、オブジェクトの実装、活性化や非活性化などの機能を司るコンポーネント（オブジェクト・アダプタと呼ばれるコンポーネント）により管理されるものであり、前記コンポーネントはその詳細な振る舞いまたは通信プロトコルのうち、少なくともいずれかを定めたＰＯＡ（ポータブル・オブジェクト・アダプタ）に対する設定パラメータに基づいて動作させるようにしたサーバ装置を対象としており、
第１の構成においては、前記ＰＯＡに与える前記設定パラメータを、書き換え可能に保持する保持手段（サービス・ポリシ・リポジトリ）に用意し、設定手段（イニシャライザ）は、ＰＯＡの生成時にこの保持手段から前記設定パラメータ（サービス・ポリシ）を取得して前記ＰＯＡに設定するようにした。
【００４５】
また、第２の構成においては、前記ＯＲＢに与える優先度マップと、前記ＰＯＡに与える前記設定パラメータを、書き換え可能に保持する保持手段（サービス・ポリシ・リポジトリ）に用意し、設定手段（イニシャライザ）は、ＯＲＢの初期化時にこの保持手段からＯＲＢリクエストに対する処理優先度の扱いを決める変換マップとしての前記優先度マップを取得して当該ＯＲＢに設定し、ＰＯＡの生成時には前記保持手段より当該ＰＯＡに適用する前記設定パラメータ（サービス・ポリシ）を取得して前記生成したＰＯＡに設定する構成とした。
【００４６】
このように、優先度マップや前記設定パラメータ（サービス・ポリシ）の変更は、保持手段に保持させる設定内容（ポリシ定義）の書き換え（リポジトリ定義ファイル３１の書き換え）により行い、この書き替えた新たな設定内容（ポリシ定義）を保持手段（サービス・ポリシ・リポジトリ）により解釈して定義内容を設定する手段（イニシャライザ）に渡し、当該設定する手段ではこの受け取った設定パラメータ（定義内容）をＯＲＢの初期化時やＰＯＡの生成・活性化時に渡して設定内容（ポリシ）の反映されたＯＲＢやＰＯＡとして機能させるようにしたので（ポリシ定義外出し形式）、優先度マップや設定パラメータ変更（ポリシ変更）はポリシ定義の書き換えだけで済むようになる。従って、優先度マップや設定パラメータ変更（ポリシ変更）する必要が生じた場合に、設定パラメータ（ポリシ定義）の書き換え（リポジトリ定義ファイルの書き換え）のみでその反映ができるようになるので、従来、ポリシ内部埋込み型であったためにポリシ変更に際しては必要であったクライアントプログラムの書き換えが不要で、ソースプログラムの書き換えの場合に付きまとうその書き換え後のソースプログラムのコンパイルといった面倒な作業も不要となる。
【００４７】
従って、本発明によれば、設定パラメータ変更（ポリシ変更）等が極めて簡便に行えるようになる分散処理システム用サーバ装置およびその設定方法を実現できるようになる。
【００４８】
また、プログラム開発者にとって、ＲＴ−ＣＯＲＢＡを活用したプログラミングを行うには、通常、それぞれのポリシの効果に関する深い理解が要求されるが、本発明においては、ＲＴ−ＣＯＲＢＡに関わる設定内容（ポリシ定義）を保持手段（サービス・ポリシ・リポジトリ）により解釈して定義内容を設定する手段（イニシャライザ）に渡し、当該設定手段によりポリシや優先度マップを設定可能としたことによって、ＲＴ−ＣＯＲＢＡを含まない以前のバージョンのＣＯＲＢＡに習得した作業者であれば、ＲＴ−ＣＯＲＢＡのレベルを熟知していなくとも、ＲＴ−ＣＯＲＢＡの機能を活用したシステムを構築することが可能となり、ＲＴ−ＣＯＲＢＡによるシステム構築参入への門戸を開放して開発者を確保し易くする効果が得られる。
【００４９】
また、ＲＴ−ＣＯＲＢＡの設定に費やす労力や負担が軽減される。
【００５０】
また、本発明においては、事後にポリシや優先度マップを変更可能としたことによって、ＲＴ−ＣＯＲＢＡによるシステム構築に必要とされる工数低減をも図ることができる効果も得られる。
【００５１】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を参照して説明する。
【００５２】
本発明は、多数の組み込み機器をネットワークで接続して分散環境上で動作させるＣＯＲＢＡ仕様のシステムにおいて、サーバ側における上述した優先度マップやポリシの設定を容易に実施できるようにする技術を提供する。
【００５３】
本発明技術を適用して好適な典型的応用事例としては、単数または複数のリアルタイム・システムや、エンベット型システムをネットワークで接続し、別の計算機により制御または監視するシステムであり、このようなシステムにおいて、クライアント側からのリクエスト（要求）によりサーバ側のオブジェクトが動作するようなクライアント−サーバの関係にある場合に、ＣＯＲＢＡ仕様を適用したクライアントとサーバ間での通信に必要な条件や各種設定内容の詳細であるポリシの特にサーバ側におけるポリシや優先度マップの設定を容易にするものである。
【００５４】
（本発明の概念）
以下、本発明の一実施例について図面を参照して説明するが、それに先立ち、はじめに、本発明の概念を説明しておく。本発明システムの概念的構成図を図１に示す。図において、１０はサーバ側となるサービス機器であって、ＣＯＲＢＡサーバ・プログラム１１とＲＴ−ＰＯＡ１２とＯＲＢ（Ｏｂｊｅｃｔ　Ｒｅｑｕｅｓｔ　Ｂｒｏｋｅｒ：オブジェクト・リクエスト・ブローカ）１３とＣＯＲＢＡオブジェクト１４とイニシャライザ２０とを備えたＣＯＲＢＡサーバ装置である。
【００５５】
ＲＴ−ＰＯＡ１２は、ＲＴ−ＣＯＲＢＡで定められている優先度を付けたり、ポリシを設定したりするためのもので、ＣＯＲＢＡサーバ・プログラム１１によって生成されて使用される。また、ＣＯＲＢＡオブジェクト１４は所要の機能を実現するための分散処理プログラムであって、必要時にＣＯＲＢＡサーバ・プログラム１１によって生成され、活性化されて動作可能になるもので、クライアント側からのリクエストにより動作するものである。
【００５６】
また、ＯＲＢ１３は、初期化時に優先度マップが設定されると共に、この設定された優先度マップを用いての優先度管理を初めとするＣＯＲＢＡの基本サービスを提供し、また、分散環境におけるオブジェクト間のやり取りを実現するメカニズムを提供するミドルウエアである。
【００５７】
３０はサービス・ポリシ・リポジトリ機能部であり、４０はＣＯＲＢＡクライアント機器であり、５０はネーミング・サービス機能部である。
【００５８】
サービス・ポリシ・リポジトリ機能部３０はＣＯＲＢＡサーバ装置１０側に設定するポリシ及びオブジェクトの優先度をイニシャライザ２０に提供すると共に、ＯＲＢ１３で必要な優先度マップをイニシャライザ２０に提供するものである。
【００５９】
サービス・ポリシ・リポジトリ機能部３０が提供するポリシとしては、上述した（ａ）使用するサーバ・プロトコル・ポリシ、（ｂ）スレッド・プール・ポリシ、（ｃ）優先度ポリシ、（ｄ）プライオリティ・バンド、（ｅ）スレッド・ポリシ、（ｆ）その他があり、これらを定義した情報を保持してこれをイニシャライザ２０が理解できるかたちで咀嚼して当該イニシャライザ２０に与えることができる構成となっている。
【００６０】
また、イニシャライザ２０は、これら与えられたポリシに従って、ＰＯＡ１２やＯＲＢ１３に各種設定を行うものである。
【００６１】
また、ネーミング・サービス機能部５０は、ネーミング・サービス機能部５０はＣＯＲＢＡのネーミング・サービスを提供するものであって、オブジェクトを名前によって管理するためのサービスであり、ＯＲＢに接続されるオブジェクト間で名前による検索を可能にする環境を提供するものである。
【００６２】
なお、サービス・ポリシ・リポジトリ機能部３０およびネーミング・サービス機能部５０は独立したコンピュータ上に置いてネットワーク（ＮＷ）で接続してあっても良いし、前記ＣＯＲＢＡサーバ装置１０またはＣＯＲＢＡクライアント装置４０のいずれかに組み込んであっても良い。
【００６３】
また、クライアント側となる機器としてのＣＯＲＢＡクライアント装置４０は、ＣＯＲＢＡクライアント・プログラム４１とＯＲＢ４２を備えている。
【００６４】
本発明においては、ＣＯＲＢＡにおける従来からのＯＲＢ（Ｏｂｊｅｃｔ　Ｒｅｑｕｅｓｔ　Ｂｒｏｋｅｒ）、ＲＴ−ＰＯＡ（Ｒｅａｌ−Ｔｉｍｅ　Ｐｏｔａｂｌｅ　Ｏｂｊｅｃｔ　Ａｄａｐｔｅｒ：ポータブル・オブジェクト・アダプタ）、ネーミング・サービスの利用の他に、今回、新たにイニシャライザ（設定変更反映処理部）２０、サービス・ポリシ・リポジトリ（条件設定指示機能部）３０の概念を導入した。
【００６５】
ここで、基礎知識としてＯＲＢ、ＲＴ−ＰＯＡ（以下、単にＰＯＡと呼ぶ）、ネーミング・サービスについて説明しておく。
【００６６】
ＣＯＲＢＡの基本サービス等を提供するためのソフトウエアであるＯＲＢは、分散環境におけるオブジェクト間のやり取りを実現するためのメカニズムを提供するソフトウエアであって、リモートオブジェクト同士の相互的なやり取りを実現するミドルウエアであり、クライアントとＣＯＲＢＡオブジェクトの間での要求と応答をシームレスに実現するための仲介役としての機能を果たすものであるが、ＲＴ−ＣＯＲＢＡ規格を搭載するＯＲＢには、大きく次の２点に分類される仕様を定めている。
【００６７】
１つは“プロセッサ・リソースの管理”であり、もう一つは“ＯＲＢ間の通信の制御”である。
【００６８】
“プロセッサ・リソースの管理”とは、分散オブジェクトにおける優先度モデルとその実装手段の提供や、スレッド・プール管理手段の提供などを指しており、また、“ＯＲＢ間の通信の制御”とは、優先度の逆転を避けるようなコネクションの確立や、プロトコルの選択手段などを指している。
【００６９】
また、上述の優先度モデルとは、分散システム上での優先度の与え方や管理方法を定めるモデルのことを指す。ＲＴ−ＣＯＲＢＡ１．０では、“サーバ・デクリアード・モデル”と“クライアント・プロパゲーティッド・モデル”という２つのモデルが定義されている。このモデルの選択は、一般のＣＯＲＢＡサーバ構築における一般の方法と同様に、ＰＯＡへのポリシ指定という形で実装することができる。
【００７０】
なお、サーバ側におけるオブジェクト・リファレンスの生成や破棄、オブジェクトの実装、活性化や非活性化などの機能を実現する部分については、ＯＲＢとは切り離したコンポーネントとする（つまり、オブジェクト・アダプタというコンポーネントとする）が、前記のＰＯＡは、このコンポーネントにおける通信プロトコルおよびオブジェクト・アダプタの詳細な振る舞いを定めた仕様を指し、これはＣＯＲＢＡ仕様の重要な一部を構成する。
【００７１】
また、上記優先度モデルのうちの“サーバ・デクリアード・モデル”とは、サーバ側で特定の優先度をオブジェクト毎に設定するモデルである。このモデルは、典型的な使用方法としては、一度与えた優先度は変更しない用途向けであり、ＣＯＲＢＡオブジェクト毎に固定的な優先度を設定して差し支えないような用途のアプリケーションに向く。
【００７２】
また、“クライアント・プロパゲーティッド・モデル”とは、ＣＯＲＢＡクライアント側で、希望する優先度を指定してリクエストを発行するモデルであり、優先度は、リクエストの一部として埋め込まれてサーバ側に渡される。このモデルは、リクエストの内容（引数値）や、リクエストを発行するまでの文脈によって優先度を変える必要があるアプリケーションに向いており、サーバ・デクリアード・モデルと比較すれば、より汎用的な用途向けのモデルと云える。
【００７３】
ＣＯＲＢＡ仕様の特徴的な点として、ＯＲＢにより分散オブジェクトを実現するための仕様を提供する他に、多くのアプリケーションでしばしば必要となる種々の機能をＣＯＲＢＡオブジェクトとして実現したオブジェクトを仕様として盛り込んでいることがあげられる。これらはＣＯＲＢＡサービスと呼ばれており、ＣＯＲＢＡサービスを分散システムを構成する一部品として利用することで、高度な機能を持つ分散オブジェクト・システムを容易に開発できるようにしている。
【００７４】
当該ＣＯＲＢＡサービスは実装言語に依存しないインタフェース記述ための言語であるＩＤＬ（インタフェース定義言語）で定義されたインタフェースを装備するサービスの集合であり、ＯＲＢに接続されたＣＯＲＢＡオブジェクトの集まりであって、これらはＯＲＢを介して利用できる。
【００７５】
一例をあげるとＣＯＲＢＡサービスには、ＯＲＢによって接続されたコンポーネント（オブジェクト）をシステム上でユニークに命名した名前で見つけ出すためのサービスを提供するネーミング・サービス（Ｎａｍｉｎｇ　Ｓｅｒｖｉｃｅ）、オブジェクト間におけるイベントの登録や管理を行うためのサービスを提供するイベント・サービス（Ｅｖｅｎｔ　Ｓｅｒｖｉｃｅ）、オブジェクト間におけるトランザクション制御を行うためのサービスであるトランザクション・サービス（Ｔｒａｎｓａｃｔｉｏｎ　Ｓｅｒｖｉｃｅ）、等が用意されている。
【００７６】
オブジェクトを名前によって管理するサービスである上述のネーミング・サービス（Ｎａｍｉｎｇ　Ｓｅｒｖｉｃｅ）は、ＯＲＢに接続されるオブジェクト間で名前による検索を可能にする環境を提供するが、それにはネーミング・コンテキスト（Ｎａｍｉｎｇ　Ｃｏｎｔｅｘｔ）と呼ばれるいわゆるオブジェクト検索用のデータベースを用いる。ネーミング・コンテキストではオブジェクトの名前と、そのＩＤＬ言語上の型と、オブジェクト・リファレンスとの計３つの情報を１件の情報として管理する。オブジェクト・リファレンスは、ネーミング・サービスに限らず、分散オブジェクトを一意に特定するデータとして使用するもので、その内容は、ＣＯＲＢＡ仕様により定められたものである。ＯＲＢは、オブジェクト・リファレンスを解析することにより、特定の分散オブジェクトにアクセスできるように構成されている。
【００７７】
ネーミング・サービスに対して、ｂｉｎｄというオペレーションを用いることにより、ネーミング・コンテキストに対して前記１件の情報の追加登録を行うことができ、ｕｎｂｉｎｄというオペレーションにより、ネーミング・コンテキストから前記１件の情報の削除を行うことができ、更にはｒｅｓｏｌｖｅというオペレーションにより、名前をキーとして、対応するオブジェクト・リファレンスの情報を取得することができる。
【００７８】
ネーミング・サービスの具体的利用形態について説明しておく。
サーバ側機器であるＣＯＲＢＡサーバ装置１０にはＣＯＲＢＡサーバ・プログラム１１があり、これを起動させると、まずはじめに、ＰＯＡ１２を生成する。ＰＯＡ１２　はＲＴ−ＣＯＲＢＡで定められている優先度を付けたり、ポリシ（方針や原則や方策）を設定したりするためのものであり、これによってＰＯＡ１２がサーバ装置１０に用意されたことになる。そして、ＣＯＲＢＡオブジェクト１４が必要なときはＣＯＲＢＡサーバ・プログラム１１は当該ＣＯＲＢＡオブジェクト１４を生成し、活性化する。
【００７９】
ＣＯＲＢＡオブジェクト１４にリモートからアクセスする場合には、いま、このオブジェクトが利用可能であることを知らせるための公開情報であるオブジェクト・リファレンスを外部に出す（公開する）必要がある。
【００８０】
ＣＯＲＢＡサーバ・プログラム１１はＣＯＲＢＡオブジェクト１４を生成・活性化するときに当該オブジェクト１４についてのリファレンス（その分散オブジェクトに付与した優先度の情報を含む当該オブジェクトを一意に示すことができる情報）を公開する。その際に利用されるのがネーミング・サービスである。
【００８１】
ＣＯＲＢＡの規格上、ＣＯＲＢＡオブジェクトには優先度情報も中に含んでいる。
【００８２】
クライアント側のＣＯＲＢＡプログラムであるＣＯＲＢＡクライアントプログラム４１は、オブジェクト・リファレンスを辞書引きのようなかたちでネーミング・サービス機能部５０に問い合わせて、リクエスト先となるＣＯＲＢＡオブジェクト１４のリファレンスをもらってくる。
【００８３】
ネーミング・サービスは開発時にオブジェクトに付けられた固有の名前を手掛かりに、目的のオブジェクトを特定するサービス機能である。ＣＯＲＢＡプログラムの開発に当たって、機能実現に必要な各オブジェクトそれぞれについて、最初からそれぞれ固有の名前を決めておくと便利である。これにより、どの機器でオブジェクトが稼動するかとは無関係に、その固有の名前を用いてオブジェクトを特定することができる。
【００８４】
ここでは、機器１０のオブジェクト１１をリクエストする機器４０におけるＣＯＲＢＡクライアントプログラム４１では、ネーミング・サービス機能部５０の提供するネーミング・サービスを利用したオブジェクト・リファレンスの問い合わせを実行し、これによりネーミング・サービスから返された機器ＡにおけるＸなる名前のオブジェクトについてのＣＯＲＢＡ世界での特定できる情報であるオブジェクト・レファレンスを取得して、これを用いてＣＯＲＢＡオブジェクト１４にリクエストを出す。
【００８５】
ネーミング・サービスに対するオブジェクト・リファレンスの問い合わせは、具体的には、設計やメンテナンス時において、もっとも便宜となる名前の文字列を引数にして対応するオブジェクトのリファレンスをこのネーミング・サービス機能部からとってくることであり、ＣＯＲＢＡクライアント・プログラム４１はこれにより得られたオブジェクト・リファレンスを利用することで、ＣＯＲＢＡクライアント・プログラム４１の実行に伴う当該クライアント・プログラム４１からオブジェクト１４に対するリクエストができることになる。
【００８６】
なお、ＣＯＲＢＡでは、オブジェクト・リファレンスをクライアントに渡す方法として、ネーミング・サービスを使用しない手法もある。その１つはオブジェクト・リファレンスをＣＯＲＢＡで定められた文字列形式と呼ぶ形式に変換し、それをファイルとして別途のネットワーク手段により、クライアントに引き渡すと云う方法である。従って、オブジェクト・リファレンスをクライアントに渡す方法にはとらわれない。本発明は、ネーミング・サービスを使用する場合でも、使用しない場合でもいずれにも対応できることを断っておく。
【００８７】
図１の構成例は、ネーミング・サービスを利用できるようにしている例であり、従って、図１のシステムではネーミング・サービス機能部５０にオブジェクト・リファレンスの問い合わせをすることで、ＣＯＲＢＡクライアント・プログラム４１からサーバ装置１０のＣＯＲＢＡオブジェクト１４に対するリクエストができることになる。
【００８８】
本発明システムにおいては、このようなＣＯＲＢＡにおける従来からのＰＯＡ、ＯＲＢの利用、さらにはケース・バイ・ケースであるがネーミング・サービスの利用の他に、新たに、ＣＯＲＢＡサーバ装置１０側で利用する機能として、イニシャライザ（設定変更反映処理部）２０とサービス・ポリシ・リポジトリ（条件設定指示機能部）３０の概念を導入したものであるが、これらのうち、サービス・ポリシ・リポジトリ３０は、サーバ側における優先度マップやポリシ（方針や原則や方策等に関する設定条件）、優先度を各ＯＲＢ別、ＰＯＡ別、ＣＯＲＢＡオブジェクト別に持ち、ＣＯＲＢＡサーバ装置側からの要求により、その要求のあったＯＲＢ、ＰＯＡ、ＣＯＲＢＡオブジェクトに対するポリシを取り出して当該サーバ装置に渡す機能を有するもので、各ＯＲＢ、ＰＯＡ、ＣＯＲＢＡオブジェクトのポリシや優先度や優先度マップはその設定を当該サービス・ポリシ・リポジトリ３０に入力することで自由に変更可能である。
【００８９】
また、イニシャライザ２０は、ＣＯＲＢＡサーバ装置１０に搭載される機能であって、ＣＯＲＢＡサーバ・プログラム１１からの要求によりサービス・ポリシ・リポジトリ３０に自己のＣＯＲＢＡサーバ装置上のＯＲＢの優先度マップやＰＯＡのポリシやＣＯＲＢＡオブジェクト優先度の転送要求を出し、この要求に対してサービス・ポリシ・リポジトリ３０から送られてきた優先度マップやポリシや優先度を取り込み、その優先度マップをＣＯＲＢＡサーバ装置１０の前記ＯＲＢ１３に設定し、また、取り込んだポリシに従った設定をＣＯＲＢＡサーバ装置１０における前記ＰＯＡ１２にセットし、ＣＯＲＢＡサーバ・プログラム１１によるＣＯＲＢＡオブジェクト１４の生成後に取り込んだ優先度でＣＯＲＢＡオブジェクトを活性化すると云った機能と仕組みを持たせたソフトウエア部品である。
【００９０】
サーバ装置１０の有するＣＯＲＢＡオブジェクト１４は、ＣＯＲＢＡクライアント装置４０の有するＣＯＲＢＡクライアント・プログラム４１によりリクエスト（アクセス）され動作して、結果をＣＯＲＢＡクライアント・プログラム４１に返すなどするが、そのやり取りは前記イニシャライザ２０により条件設定されたＯＲＢ１３やＰＯＡ１２を介して行われることになる。
【００９１】
図２を参照して本発明システムの分散オブジェクトの起動の概要を説明する。
【００９２】
ＣＯＲＢＡサーバ・プログラム１１は起動すると、まずはじめにイニシャライザ２０を起動させる（丸囲み数字１のステップ）。すると、イニシャライザ２０は、サービス・ポリシ・リポジトリ３０に自サーバ装置１０のＯＲＢ、ＰＯＡに対する優先度マップおよび各種ポリシ値および設定値の提供を依頼し、これを受けたサービス・ポリシ・リポジトリ３０ではサーバ装置１０から要求のあった優先度マップおよび各種ポリシ値および設定値を読み出して送る（ステップ（ｉ１））。これらを受け取ったイニシャライザ２０は、各種ポリシ値等をＲＴ−ＰＯＡ１２に、そして、優先度マップをＯＲＢ１３にそれを設定する（ステップ（ｉ２），（ｉ３））。
【００９３】
設定が終わるとイニシャライザ２０は、制御をＣＯＲＢＡサーバ・プログラム１１に返すので、ＣＯＲＢＡサーバ・プログラム１１は動作を再開する。そして、ＣＯＲＢＡオブジェクト１４を生成する（丸囲み数字２のステップ）。
【００９４】
ＣＯＲＢＡオブジェクトの生成が終わると、ＣＯＲＢＡサーバ・プログラム１１は再度イニシャライザ２０を呼び出す。すると、イニシャライザ２０は、サービス・ポリシ・リポジトリ３０に自サーバ装置１０のＣＯＲＢＡオブジェクトに対する優先度の提供を依頼し、これを受けたサービス・ポリシ・リポジトリ３０ではサーバ装置１０から要求のあった優先度を読み出して送る（ステップ（ｉ４））。これらを受け取ったイニシャライザ２０は、この優先度を与えてＣＯＲＢＡオブジェクトを活性化する（ステップ（ｉ５））。
【００９５】
これにより、サーバ装置１０のＣＯＲＢＡオブジェクト１４は動作可能な状態になり、ＣＯＲＢＡクライアント装置４０のＣＯＲＢＡクライアント・プログラム４１によるリクエストがあれば動作を実行することになる。
【００９６】
このように、本願発明ではサービス・ポリシ・リポジトリ３０を設けてここに優先度マップとポリシを保持させるようにし、ＯＲＢの初期化時とＲＴ−ＰＯＡの生成時にこれをサービス・ポリシ・リポジトリ３０に問い合わせ、得られた優先度マップとポリシ、優先度の情報をイニシャライザ２０によりＯＲＢ１３とＲＴ−ＰＯＡ１２にそれを設定するという「優先度マップおよびポリシ、優先度の外出し方式」としたのが本発明方式である。
【００９７】
一方、比較のために従来方式での分散オブジェクトの起動の概要を説明すると、従来の場合、図３に示すように、システムにはイニシャライザ２０とサービス・ポリシ・リポジトリ３０が無い。
【００９８】
優先度マップやポリシや優先度は外部に問い合わせて得るという手法ではなく、ＣＯＲＢＡサーバ・プログラム１１に埋め込んだかたちとなっている（優先度マップおよびポリシ、優先度の埋込方式）。そのため、ＣＯＲＢＡサーバ・プログラム１１は起動すると、まずはじめにＯＲＢ１３を初期化し、プログラムに埋め込んだＯＲＢ１３に関連するポリシ値および設定値に基づいて当該ＯＲＢ１３に設定する（図３の丸囲み数字１のステップ）。次に、ＣＯＲＢＡサーバ・プログラム１１はＲＴ−ＰＯＡ１２を生成し、プログラムに埋め込んだＲＴ−ＰＯＡ１２に関連する各種ポリシ値および設定値に基づいてＲＴ−ＰＯＡ１２にそれを設定する（図３の丸囲み数字２のステップ）。設定が終わるとＣＯＲＢＡサーバ・プログラム１１はＣＯＲＢＡオブジェクト１４を生成し、プログラムに埋め込んだ優先度値に基づいて活性化する（丸囲み数字３のステップ）。
【００９９】
これにより、サーバ装置１０のＣＯＲＢＡオブジェクト１４は動作可能な状態になり、ＣＯＲＢＡクライアント装置４０のＣＯＲＢＡクライアント・プログラム４１によるリクエストがあれば動作を実行することになる。
【０１００】
従来方式の場合、ＣＯＲＢＡサーバ・プログラムにポリシ等の情報を予め埋め込んだソースプログラムを作成してこれをコンパイルし、実行形式のプログラムとしてサーバ装置１０に実装するのに対して、本発明システムにおいてはサービス・ポリシ・リポジトリ３０とイニシャライザ２０を用意し、ポリシはサービス・ポリシ・リポジトリ３０に用意しておくと、サーバ装置１０内のイニシャライザ２０は初期時に、サービス・ポリシ・リポジトリ３０からポリシを取得し、これをサーバ装置１０内のＯＲＢとＰＯＡにセットするようにした。
【０１０１】
従来方式の場合は、ポリシ変更はソースプログラムの書き換えと再コンパイルという手間が掛かるが、本発明システムではサービス・ポリシ・リポジトリ３０に用意するポリシを変更するだけで済み、ポリシ変更が非常に簡便に行えるようになることがわかる。
【０１０２】
本発明システムと従来システムでのＯＲＢに対する優先度マップの設定とＰＯＡに対するポリシの設定およびＣＯＲＢＡオブジェクトに対する優先度の設定について、もう少し詳細に比較してみる。図４（ｂ）は従来システムにおけるＣＯＲＢＡサーバ・プログラムの動作の概要を示すフローチャートであり、これを参照して動作の比較をしてみる。
【０１０３】
従来方式の場合、優先度マップとポリシはＣＯＲＢＡサーバ・プログラム１１中に埋め込まれているもので、次のように動作する。ＣＯＲＢＡサーバ・プログラム１１は起動すると、まずはじめにＯＲＢの初期化をする（図４（ｂ）のステップＳ１１）。つぎにＣＯＲＢＡサーバ・プログラム１１は、プログラムに埋め込まれている優先度マップの情報に基づいて、これをＯＲＢにセットすることで優先度マップの定義をする（図４（ｂ）のステップＳ１２）。優先度マップはＣＯＲＢＡ優先度値と各種ＯＳの優先度値間の数値の変換のための対応表である。
【０１０４】
つぎに、ＣＯＲＢＡサーバ・プログラム１１は、プログラムに埋め込まれているＲＴ−ＰＯＡ関連のポリシ等に基づいて、ＲＴ−ＰＯＡのためのポリシ・リストを作成する（図４（ｂ）のステップＳ１３）。
【０１０５】
ポリシ・リストは、（ａ）使用するサーバ・プロトコル・ポリシ、（ｂ）スレッド・プール・ポリシ、（ｃ）優先度ポリシ、（ｄ）プライオリティ・バンド、（ｅ）スレッド・ポリシ、（ｆ）その他を定義した情報リストである。
【０１０６】
そして、このリストに従ってＲＴ−ＰＯＡを生成し、そのＰＯＡの優先度を与えて活性化する（図４（ｂ）のステップＳ１３）。そして、更に必要があればその必要に応じて追加のＲＴ−ＰＯＡの作成を行うために（ＰＯＡは条件を変えて複数作成することができる）、この処理を必要なＲＴ−ＰＯＡの数分、繰り返す。
【０１０７】
これが終わったならば、つぎにＣＯＲＢＡサーバ・プログラム１１は、使用するオブジェクトを生成する。必要なオブジェクト全てを生成するまで繰り返す（図４（ｂ）のステップＳ１４）。次にＣＯＲＢＡサーバ・プログラム１１は、生成したオブジェクト毎に必要なＲＴ−ＰＯＡ上でプログラムに埋め込まれている優先度を与えて活性化する（図４（ｂ）のステップＳ１５）。このとき、ネーミング・サービスを利用する方式の場合には、更にオブジェクトの活性化前にネーミング・サービスのリファレンスを取得し、オブジェクトの活性化後に生成したオブジェクト毎にオブジェクト・リファレンスをネーミング・サービスに登録する処理をする（図４（ｂ）のステップＳ１５）。
【０１０８】
つぎにＣＯＲＢＡサーバ・プログラム１１は、リクエストの受付待ち（ＯＲＢイベント・ループ）となり（図４（ｂ）のステップＳ１６）、リクエストが来たならばそのリクエストを受けたオブジェクトにリクエストを渡して動作させることになるが、ＯＲＢのシャットダウンの指令を受けたならば、ＣＯＲＢＡサーバ・プログラム１１は、ＯＲＢのシャットダウンをして処理を終了する（図４（ｂ）のステップＳ１７）。
【０１０９】
図には示していないが、サーバ側での分散オブジェクトとクライアント側との間での呼出や情報授受を行う際には、サーバ装置１０でのＯＲＢ１３やＲＴ−ＰＯＡ１２はポリシ・リストに従ったポリシで機能する。
従来システムはこのような動作となる。
【０１１０】
これに対して、本発明方式の場合は、優先度マップとポリシとＣＯＲＢＡオブジェクトの優先度はサービス・ポリシ・リポジトリ３０に用意されており、図４（ａ）のような動作となる。ＣＯＲＢＡサーバ・プログラム１１は起動すると、まずはじめにＯＲＢの初期化をする（図４（ａ）のステップＳ２１）。つぎにＣＯＲＢＡサーバ・プログラム１１は、イニシャライザ２０の生成と、ＯＲＢの設定を行う。その際、使用するＯＲＢのリファレンスとサービス・ポリシ・リポジトリ３０のリファレンスをイニシャライザ２０に渡す。そして、イニシャライザ２０内部でサービス・ポリシ・リポジトリ３０から得た情報に基づき、優先度マップをＯＲＢに定義する（図４（ａ）のステップＳ２２）。
【０１１１】
当該ステップＳ２２での処理により、サービス・ポリシ・リポジトリ３０から与えられたポリシに従った設定がＯＲＢに対して成されることになる。
【０１１２】
つぎに、ＣＯＲＢＡサーバ・プログラム１１は、イニシャライザ２０に処理を渡し、イニシャライザ２０はこれによりＲＴ−ＰＯＡの生成と設定を行う。イニシャライザ２０の内部ではサービス・ポリシ・リポジトリ３０から得た情報に基づき、必要なＲＴ−ＰＯＡを生成し、活性化する。ＣＯＲＢＡにおいてはＲＴ−ＰＯＡは必要に応じて複数作ることができるので、この処理を必要なＲＴ−ＰＯＡ数分繰り返す（図４（ａ）のステップＳ２３）。
【０１１３】
当該ステップＳ２３での処理により、サービス・ポリシ・リポジトリ３０から与えられたポリシに従ったポリシ・リストが作成され、これによる設定がＲＴ−ＰＯＡに対して成されることになる。すなわち、サービス・ポリシ・リポジトリ３０から与えられた（ａ）使用するサーバ・プロトコル・ポリシ、（ｂ）スレッド・プール・ポリシ、（ｃ）優先度ポリシ、（ｄ）プライオリティ・バンド、（ｅ）スレッド・ポリシ、（ｆ）その他についての定義情報組み合わせ種別分、ＲＴ−ＰＯＡが生成されることになる。
【０１１４】
これが終わったならば、イニシャライザ２０からＣＯＲＢＡサーバ・プログラム１１に制御が戻されるので、つぎにＣＯＲＢＡサーバ・プログラム１１は、使用するオブジェクトを生成する。必要なオブジェクト全てを生成するまで繰り返す（図４（ａ）のステップＳ２４）。
【０１１５】
次にＣＯＲＢＡサービスプログラム１１は、イニシャライザ２０に制御を移してイニシャライザ２０にオブジェクトの活性化をさせる。このとき、イニシャライザ２０の内部ではサービス・ポリシ・リポジトリ３０から得た情報に基づき、オブジェクトを必要なＲＴ−ＰＯＡ上で優先度を与えて活性化する。（図４（ａ）のステップＳ２５）。
【０１１６】
当該ステップＳ２５での処理により、必要なポリシに従った設定が成されたＲＴ−ＰＯＡを介してオブジェクトは機能することになり、ポリシ対応の条件での動作が可能になる。
【０１１７】
このとき、ネーミング・サービスを利用する方式の場合には、更にオブジェクトの活性化前にネーミング・サービスのリファレンスを取得し、オブジェクトの活性化後に生成したオブジェクト毎にオブジェクト・リファレンス（オブジェクトのメソッドを起動する際に必要な識別子）をネーミング・サービスに登録する処理をする（図４（ａ）のステップＳ２５）。
【０１１８】
つぎにＣＯＲＢＡサーバ・プログラム１１は、リクエストの受付待ち（ＯＲＢイベント・ループ）となり（図４（ａ）のステップＳ２６）、リクエストが来たならばそのリクエストを受けたオブジェクトにリクエストを渡して動作させることになるが、ＯＲＢのシャットダウンの指令を受けたならば、ＣＯＲＢＡサーバ・プログラム１１は、ＯＲＢのシャットダウンをして処理を終了する（図４（ａ）のステップＳ２７）。
【０１１９】
図には示していないが、サーバ側での分散オブジェクトとクライアント側との間での呼出や情報授受を行う際には、サーバ装置１０でのＯＲＢ１３やＲＴ−ＰＯＡ１２はポリシ・リストに従ったポリシで機能する。
【０１２０】
このように、優先度マップとポリシ、優先度を従来のようにＣＯＲＢＡサーバ・プログラム１１中に埋め込まず、サービス・ポリシ・リポジトリ３０に保持させると共に、サーバにイニシャライザを生成させてこれによりサービス・ポリシ・リポジトリ３０から優先度マップとポリシ、優先度を取り込み、ＯＲＢの設定と、ＲＴ−ＰＯＡの生成および活性化、オブジェクトの活性化を行うことで優先度マップとポリシ、優先度の反映を可能にしたことが本発明方式の最大の特徴点であり、従来方式との最大の相違点である。そして、このように優先度マップとポリシをサービス・ポリシ・リポジトリ３０から与える構成としたことで、優先度マップとポリシ、優先度はサービス・ポリシ・リポジトリ３０への保持内容の変更で済むようになり、優先度マップとポリシ、優先度の変更が極めて容易になる。
【０１２１】
（具体例）
次に具体例を説明する。図５は一例としての本発明摘要システムのブロック図である。図中１０はＣＯＲＢＡサーバ装置であり、当該サーバ装置１０はインテリジェントな例えば測定機器などのサービス機器であって、ＣＯＲＢＡサーバ・プログラム１１を備えており、これを起動させることにより、イニシャライザ２０の生成、ＣＯＲＢＡ仕様のミドルウエアであるＯＲＢ１３の初期化、ＰＯＡ１２の生成と活性化、ＣＯＲＢＡオブジェクト１４ａ，１４ｎの生成と活性化を行ってＣＯＲＢＡオブジェクト１４ａ，１４ｎの動作を可能にするサービス機器である。
【０１２２】
また、４０はクライアント機器であり、クライアント機器４０はクライアント・プログラム４１およびＣＯＲＢＡ仕様のミドルウエアであるＯＲＢ４２を備えたサービス機器である。
【０１２３】
イニシャライザ２０は、サービス・ポリシ・リポジトリ３０からの定義情報に基づいてＯＲＢ１３に設定する優先度マップやＰＯＡ１２に設定するポリシ、ＣＯＲＢＡオブジェクトの優先度を与えるものであり、システムの起動初期時にＣＯＲＢＡサーバ・プログラム１１より生成、活性化されて機能するようになっている。
【０１２４】
３０は既に説明した通りのサービス・ポリシ・リポジトリであり、ＣＯＲＢＡサーバ装置１０のＯＲＢ１３およびＰＯＡ１２に与えるべき優先度マップおよびポリシ（ポリシは上記（ａ）から（ｆ））、優先度の設定内容を与えるものである。
【０１２５】
イニシャライザ２０に与えるべき優先度マップの情報及びポリシ、優先度の設定内容は、予め、アクセス・ポリシ・リポジトリ３０に設定しておくが、これを定めるのがリポジトリ定義ファイル３１である。設定対象のポリシとしては、（ａ）使用するサーバ・プロトコル・ポリシ、（ｂ）スレッド・プール・ポリシ、（ｃ）優先度ポリシ、（ｄ）プライオリティ・バンド、（ｅ）スレッド・ポリシ、（ｆ）その他であって、このようなポリシの設定情報は、ＯＲＢ、ＰＯＡ別にさらにＣＯＲＢＡオブジェクト別にそれぞれ定義してある。
【０１２６】
サービス・ポリシ・リポジトリ定義ファイル３１の例を図６に示す。
【０１２７】
リポジトリ定義ファイル３１は、サービス・ポリシ・リポジトリ３０の設定用のファイルであって、図６に示す例はＸＭＬで記述したファイル例であり、『ＯＲＢは初期化時の内容であり、名称“ｔｈｅＲｔＰｏａ”なるＲＴ−ＰＯＡは優先度値が“１００００”であり、優先度モデルは“サーバ・デクリアード”であり、…』といった内容であることを示している。なお、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ　ｍａｒｋｕｐ　ｌａｎｇｕａｇｅ；構造をもつ情報を記述するためのマークアップ言語（ｍａｒｋｕｐ　ｌａｎｇｕａｇｅ；特定の記号を用い、テキストファイルに文書の構造やデザイン、レイアウトなどの情報を付加するための言語））であり、ユーザが独自のタグを作って利用することができるので、表示するデータの意味を情報として記述しておくことができ、これを基にＷｅｂページ内のデータを検索したり、一部を抜き出して別の形式で保存するなど、データの再利用が可能になる特徴がある。
【０１２８】
もちろん、リポジトリ定義ファイル３１はＸＭＬ言語記述に限るものではなく、定義内容が記述できれば良いので、例えば、単なるテキストファイルであっても良く、他の言語であってもよい。
【０１２９】
サービス・ポリシ・リポジトリ３０は、イニシャライザ２０からの要求を受けてこの定義情報内容を読み取り、イニシャライザ２０が理解できるように咀嚼してその定義内容を渡す機能を備えており、その機能は図７に示す如きインタフェースプログラムにより実現される。
【０１３０】
図７は、ＩＤＬによるサービス・ポリシ・リポジトリの外部インタフェース実装例であるが、その動作内容は図８のフローチャートに示す如きである。すなわち、設定ファイル（リポジトリ定義ファイル３１）を読み込んで計算機毎（ＣＯＲＢＡサーバ装置１０毎）のＲＴ−ＰＯＡの設定と、オブジェクトの設定を取得（リポジトリ定義ファイル３１の読み込み、ＣＯＲＢＡサーバ装置１０毎のＲＴ−ＰＯＡの設定と、オブジェクトの設定を取得；図８のステップＳ３１）してから、各イニシャライザ２０からのリクエスト待ちとなる（図８のステップＳ３２）。
【０１３１】
あるイニシャライザからリクエストが出されたとすると、そのリクエストがＰＯＡデータの取得要求が受信されたか否か、オブジェクトデータの取得要求が受信されたか否か、ＯＲＢポリシの取得要求が受信されたか否か、をステップＳ３３，Ｓ３４，Ｓ３５でチェックする。すなわち、リクエストが受信されたとすると、まずはそれがＰＯＡデータの取得要求“ｇｅｔＰｏａＤａｔａ”であるかをチェックする（ステップＳ３３）。その結果、“ｇｅｔＰｏａＤａｔａ”であったならば、イニシャライザ２０にＰＯＡの情報を返信し（ステップＳ３７）、ステップＳ３２の処理に戻るが、ステップＳ３３でのチェックの結果、“ｇｅｔＰｏａＤａｔａ”でなかったならば、受信したリクエストがオブジェクトデータの取得要求“ｇｅｔＯｂｊＤａｔａ”の受信であるか否かをチェックする（ステップＳ３４）。
【０１３２】
チェックの結果、オブジェクトデータの取得要求の受信であったならばイニシャライザ２０にオブジェクトの情報を返信し（ステップＳ３８）、ステップＳ３２の処理に戻るが、ステップＳ３３でのチェックの結果、“ｇｅｔＯｂｊＤａｔａ”でなかったならば、受信したリクエストがポリシ取得要求“ｇｅｔＰｏｌｉｃｙＦｏｒＯｒｂ”の受信であるか否かをチェックする（ステップＳ３５）。
【０１３３】
そして、チェックの結果ＯＲＢポリシの取得要求の受信であったならば、イニシャライザ２０にＯＲＢの情報を返信し（ステップＳ３９）、ステップＳ３２の処理に戻るが、ステップＳ３５でのチェックの結果、ＯＲＢポリシの取得要求の受信でなかったならば、受信したリクエストが“ｓｈｕｔＤｏｗｎ”の受信であるか否かをチェックし（図９のステップＳ３６）、“ｓｈｕｔＤｏｗｎ”を受信していなければステップＳ３２の処理に戻ってＳ３２以降を繰り返すが、ステップＳ３６において“ｓｈｕｔＤｏｗｎ”を受信したならば処理を終了する。図８のプログラムによる処理内容はこのようなものである。これにより、サービス・ポリシ・リポジトリ３０はイニシャライザ２０からの要求に従い、必要なポリシ・リストを当該イニシャライザ２０に受け渡すことができるシステムとなる。
【０１３４】
Ｃ＋＋言語によるイニシャライザ２０のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍ　Ｉｎｔｅｒｆａｃｅ）としてのソースプログラム例を図９に示しておく。
【０１３５】
このような構成で実現する本システムの動作を説明する。ここでは、起動初期時に、ＣＯＲＢＡサーバ・プログラム１１からみたシステム挙動を、ネーミング・サービスを用いる場合と、ネーミング・サービスを用いない場合とに分けて説明する。
【０１３６】
図１０はネーミング・サービスを利用する場合の例であり、適用される構成は図５である。
【０１３７】
本発明方法では、サーバ装置１０のＣＯＲＢＡサーバ・プログラム（ＣＯＲＢＡサーバ・アプリケーション）１１においては図１２に示すように、起動開始するとまずはじめにＯＲＢ１３を生成し、当該ＯＲＢ１３を生成したことをイニシャライザ２０に知らせる（図１０のＰ７１）。
【０１３８】
すると、イニシャライザ２０が機能してサービス・ポリシ・リポジトリ３０に対し、ＯＲＢの情報を取得要求する（図１０のＰ７２）ので、サービス・ポリシ・リポジトリ３０は、定義ファイル３１よりＯＲＢの情報を読み出してイニシャライザ２０に理解できるかたちでこれを返す（図１０のＰ７３）。
【０１３９】
これを受け取ったイニシャライザ２０では受け取った情報のうち、優先度マップの情報を用いてＯＲＢ１３にセットし、ＯＲＢ１３の優先度マップの設定が終了したことをＣＯＲＢＡサーバ・プログラム１１に知らせる（図１０のＰ７４）。
【０１４０】
これを受けて次にＣＯＲＢＡサーバ・プログラム１１は、イニシャライザ２０にＰＯＡ１２の生成を依頼する（図１０のＰ７５）。これにより、イニシャライザ２０はサービス・ポリシ・リポジトリ３０に対し、ＰＯＡの情報を取得要求する（図１０のＰ７６）ので、サービス・ポリシ・リポジトリ３０は、定義ファイル３１よりＰＯＡの情報を読み出してイニシャライザ２０に理解できるかたちでこれを返す（図１０のＰ７７）。
【０１４１】
イニシャライザ２０はこれを受け取り、その内容に従ったポリシでＲＴ−ＰＯＡ１２を生成し、活性化する（図１０のＰ７８）。
【０１４２】
そして、イニシャライザ２０はＲＴ−ＰＯＡ１２の生成と活性化が終了したことをＣＯＲＢＡサーバ・プログラム１１に知らせる（図１０のＰ７９）。ＣＯＲＢＡサーバ・プログラム１１は必要数分のＰＯＡが生成、活性化されるまで上記Ｐ７１からＰ７９の処理を繰り返すようにする。
【０１４３】
必要数分のＰＯＡ１２が生成、活性化されると、次にＣＯＲＢＡサーバ・プログラム１１はＣＯＲＢＡオブジェクト１４ａの生成を行う（図１０のＰ８０）。そして、ＣＯＲＢＡサーバ・プログラムはオブジェクト名を渡し、この生成したＣＯＲＢＡオブジェクト１４ａの活性化をイニシャライザ２０に依頼すると共に、そのオブジェクト・リファレンスのネーミング・サービスへの登録をこのイニシャライザ２０に要求する（図１０のＰ８１）。
【０１４４】
オブジェクト・リファレンスは、分散オブジェクトを一意に特定するデータとして使用するもので、その内容は、ＣＯＲＢＡ仕様により定められたものである。オブジェクトの活性化に必要な情報は、サービス・ポリシ・リポジトリ３０に保持させておくので、これをイニシャライザ２０はサービス・ポリシ・リポジトリ３０に取得要求する（図１０のＰ８２）。要求を受けたサービス・ポリシ・リポジトリ３０はオブジェクト名対応のオブジェクトの情報（例えば、活性化対象ＰＯＡと優先度など）を読み出し、イニシャライザ２０の理解できる形式でイニシャライザ２０に渡す（図１０のＰ８３）。
【０１４５】
オブジェクトの情報を受け取ったイニシャライザ２０は指定のＰＯＡ上でオブジェクトを活性化し（図１０のＰ８４）、また、オブジェクトの・リファレンスの公開を行うべく、ネーミング・サービス５０に登録する（図１０のＰ８５）。そして、次にイニシャライザ２０はオブジェクト・リファレンスをＣＯＲＢＡサーバ・プログラム１１に返し、ＣＯＲＢＡサーバ・プログラム１１に保持させる（図１０のＰ８６）。Ｐ８０からＰ８５の処理を生成・活性化したい必要なオブジェクト数分、繰り返す。
【０１４６】
必要なオブジェクトが生成されたならば、ＣＯＲＢＡサーバ・プログラムは、オブジェクトのサービスを開始する。従って、クライアント側からリクエストがあれば、サーバ装置１０側のオブジェクトは機能することになる。
【０１４７】
以上の説明からわかるように、本発明では、優先度マップやポリシ、優先度の変更をポリシ定義の書き換え（リポジトリ定義ファイル３１の書き換え）により行い、この書き換えた新たなポリシ定義をサービス・ポリシ・リポジトリにより解釈して定義内容をイニシャライザに渡し、イニシャライザではこの受け取った定義内容をＯＲＢやＰＯＡの生成・活性化時、オブジェクト活性化時に渡してポリシの反映されたＰＯＡ上で機能させるようにしている（ポリシ定義外出し形式）。そのため、ポリシ変更はポリシ定義の書き換えだけで済むようになる。
【０１４８】
ネーミング・サービスを用いない場合の挙動を図１２に示す。なお、この場合での適用構成は図１１の如きである。
【０１４９】
本発明方法では、サーバ装置１０のＣＯＲＢＡサーバ・プログラム（ＣＯＲＢＡサーバ・アプリケーション）１１は図１２に示すように、起動開始するとまずはじめにＯＲＢ１３を生成し、当該ＯＲＢ１３を生成したことをイニシャライザ２０に知らせる（図１２のＰ５１）。
【０１５０】
すると、イニシャライザ２０が機能してサービス・ポリシ・リポジトリ３０に対し、ＯＲＢの情報を取得要求する（図１２のＰ５２）ので、サービス・ポリシ・リポジトリ３０は、定義ファイル３１よりＯＲＢの情報を読み出してイニシャライザ２０に理解できるかたちでこれを返す（図１２のＰ５３）。
【０１５１】
これを受け取ったイニシャライザ２０では受け取った情報のうち、優先度マップの情報を用いてＯＲＢ１３にセットし、ＣＯＲＢＡサーバ・プログラム１１にＯＲＢ１３の優先度マップの設定が終了したことを知らせる（図１２のＰ５３）。
【０１５２】
これを受けて次にＣＯＲＢＡサーバ・プログラム１１は、ＰＯＡ１２の生成を依頼する（図１２のＰ５５）。これにより、イニシャライザ２０はサービス・ポリシ・リポジトリ３０に対し、ＰＯＡの情報を取得要求する（図１２のＰ５６）ので、サービス・ポリシ・リポジトリ３０は、定義ファイル３１よりＰＯＡの情報を読み出してイニシャライザ２０に理解できるかたちでこれを返す（図１２のＰ５７）。
【０１５３】
イニシャライザ２０はこれを受け取り、その内容に従ったポリシでＲＴ−ＰＯＡ１２を生成し、活性化する（図１２のＰ５８）。そして、イニシャライザ２０はＲＴ−ＰＯＡ１２の生成と活性化が終了したことをＣＯＲＢＡサーバ・プログラム１１に知らせる（図１２のＰ５９）。ＣＯＲＢＡサーバ・プログラム１１は必要数分のＰＯＡ１２が生成、活性化されるまで上記Ｐ５１からＰ５９の処理を繰り返すようにする。
【０１５４】
必要数分のＰＯＡが生成、活性化されると、次にＣＯＲＢＡサーバ・プログラム１１はＣＯＲＢＡオブジェクト１４ａの生成を行う（図１２のＰ６０）。そして、ＣＯＲＢＡサーバ・プログラム１１はオブジェクト名を渡し、この生成したＣＯＲＢＡオブジェクト１４ａの活性化をイニシャライザ２０に依頼する（図１２のＰ６１）。
【０１５５】
オブジェクト・リファレンスは、分散オブジェクトを一意に特定するデータとして使用するもので、その内容は、ＣＯＲＢＡ仕様により定められたものである。オブジェクトの活性化に必要な情報は、サービス・ポリシ・リポジトリ３０に保持させておくので、これをイニシャライザ２０はサービス・ポリシ・リポジトリ３０に取得要求する（図１２のＰ６２）。要求を受けたサービス・ポリシ・リポジトリ３０はオブジェクト名対応のオブジェクトの情報（例えば、活性化対象ＰＯＡと優先度など）を読み出し、イニシャライザ２０の理解できる形式でイニシャライザ２０に渡す（図１２のＰ６３）。
【０１５６】
オブジェクトの情報を受け取ったイニシャライザ２０は指定のＰＯＡ上でオブジェクト１４ａを活性化し、オブジェクト・リファレンスをＣＯＲＢＡサーバ・プログラム１１に返す（図１２のＰ６４，Ｐ６５）。Ｐ５９からＰ６４の処理を生成・活性化したい必要なオブジェクト数分、繰り返す。
【０１５７】
必要なオブジェクトが生成されたならば、ＣＯＲＢＡサーバ・プログラム１１はオブジェクトの・リファレンスの公開を行い、オブジェクトのサービスを開始する。従って、クライアント側４０からリクエストがあれば、サーバ装置１０側のオブジェクト１４ａは機能することになる。
【０１５８】
このように、優先度マップやポリシの変更をポリシ定義の書き換え（リポジトリ定義ファイル３１の書き換え）により行い、この書き替えた新たなポリシ定義をサービス・ポリシ・リポジトリにより解釈して定義内容をイニシャライザに渡し、イニシャライザではこの受け取った定義内容をＯＲＢやＰＯＡの生成・活性化時、オブジェクト活性化時に渡してポリシの反映されたＰＯＡ上で機能させるようにしたので、（ポリシ定義外出し形式）、ポリシ変更はポリシ定義の書き換えだけで済むようになる。従って、ポリシを変更する必要が生じた場合に、ポリシ定義の書き換え（リポジトリ定義ファイルの書き換え）のみでその反映ができるようになる。
【０１５９】
従って、ポリシを変更する必要が生じた場合に、ポリシ定義の書き換え（リポジトリ定義ファイルの書き換え）のみでその反映ができるようになるので、従来、ポリシ内部埋込み型であったためにポリシ変更に際しては必要であったクライアント・プログラムの書き換えが不要で、ソースプログラムの書き換えの場合に付きまとうその書き換え後のソースプログラムのコンパイルといった面倒な作業も不要となって、優先度マップやポリシ変更が極めて簡便となるＣＯＲＢＡシステムが実現できることになる。
【０１６０】
また、プログラム開発者にとって、ＲＴ−ＣＯＲＢＡを活用したプログラミングを行うには、通常、それぞれのポリシの効果に関する深い理解が要求されるが、上述したいずれの本発明においても、ＲＴ−ＣＯＲＢＡ
に関するポリシや優先度マップ等の設定処理を隠蔽したことによって、ＲＴ−ＣＯＲＢＡを含まない以前のバージョンのＣＯＲＢＡに習得した作業者であれば、ＲＴ−ＣＯＲＢＡのレベルを熟知していなくとも、ＲＴ−ＣＯＲＢＡの機能を活用したシステムの構築に参画することが可能となり、ＲＴ−ＣＯＲＢＡによるシステム構築参入への門戸を開放して開発者を確保し易くする効果が得られる。
【０１６１】
また、いずれの本発明においても、事後にポリシや優先度マップ、優先度をソースコードの変更なしに容易に変更可能としたことによって、ＲＴ−ＣＯＲＢＡによるシステム構築に必要とされる工数低減をも図ることができる効果も得られる。
【０１６２】
なお、上記説明はあくまでも一例であり、種々変形して実施可能である。
【０１６３】
また、本発明において、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得るものである。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題の少なくとも１つが解決でき、発明の効果の欄で述べられている効果の少なくとも１つが得られる場合には、この構成要件が削除された構成が発明として抽出され得る。また、詳細な説明にて説明した本発明は、コンピュータに読み込ませて実行させるプログラムとして頒布して、利用することも可能である。
【０１６４】
【発明の効果】
以上詳述したように、本発明によれば、優先度マップやポリシ変更が極めて簡便となる効果が得られる。
【０１６５】
また、ＲＴ−ＣＯＲＢＡを活用したプログラミングを行うには、通常、それぞれのポリシの効果に関する深い理解が要求されるが、本発明においては、ＲＴ−ＣＯＲＢＡに関わる設定内容（ポリシ定義）を保持手段（サービス・ポリシ・リポジトリ）により解釈して定義内容を設定する手段（イニシャライザ）に渡し、当該設定手段によりポリシや優先度マップを設定可能としたことによって、ＲＴ−ＣＯＲＢＡを含まない以前のバージョンのＣＯＲＢＡしか習得していない作業者であっても、ＲＴ−ＣＯＲＢＡの機能を活用したシステムを構築することが可能となり、ＲＴ−ＣＯＲＢＡによるシステム開発参入への門戸を開放して開発者を確保し易くする効果が得られる。
【０１６６】
また、本発明においては、事後にポリシや優先度マップを変更可能としたことによって、ＲＴ−ＣＯＲＢＡの設定に費やす労力や負担の軽減をも図ることができる効果も得られる。
【図面の簡単な説明】
【図１】本発明を説明するための図である。
【図２】本発明による分散処理システムにおける分散オブジェクトの起動の概要を説明するための図である。
【図３】従来方式による分散処理システムにおける分散オブジェクトの起動の概要を説明するための図である。
【図４】本発明を適用した場合と従来技術を適用した場合でのＣＯＲＢＡサーバ・プログラムで実施すべき処理内容の違いを比較して説明する図である。
【図５】本発明システムの構成例を示すブロック図である。
【図６】本発明システムで用いるアクセス・ポリシ・リポジトリの設定ファイル定義例を説明する図である。
【図７】本発明システムで用いるアクセス・ポリシ・リポジトリのインタフェース定義例（ＩＤＬ言語による記述）を説明する図である。
【図８】本発明システムで用いるアクセス・ポリシ・リポジトリの動作例を示すフローチャートである。
【図９】本発明システムで用いるイニシャライザを実現するための実装プログラムのうち、サーバ・プログラムから操作するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍ　Ｉｎｔｅｒｆａｃｅ）を定義するソースプログラムファイル例（Ｃ＋＋言語記述）を説明する図である。
【図１０】本発明システムにおけるサーバ装置でのＣＯＲＢＡサーバ・プログラムを中心とした起動時処理の動作遷移を説明するための図である（ネーミング・サービスを組み合わせる方式）。
【図１１】本発明システムの簡易的な構成例を示すブロック図である。
【図１２】本発明システムにおけるサーバ装置でのＣＯＲＢＡサーバ・プログラムを中心とした起動時処理の動作遷移を説明するための図である（ネーミング・サービスを組み合わせない方式）。
【符号の説明】
１０…ＣＯＲＢＡサーバ装置（サーバ側）
１１…ＣＯＲＢＡサーバ・プログラム（ＣＯＲＢＡサーバ・アプリケーション）
１２…ＰＯＡ
１３…ＯＲＢ
１４，１４ａ，１４ｎ…ＣＯＲＢＡオブジェクト
２０…イニシャライザ（設定変更反映処理部）
３０…アクセス・ポリシ・リポジトリ（条件設定指示機能部）
４０…ＣＯＲＢＡクライアント装置（クライアント側）
５０…ネーミング・サービス機能部。
【図１】
2004078457.tif 000003
【図２】
2004078457.tif 000004
【図３】
2004078457.tif 000005
【図４】
2004078457.tif 000006
【図５】
2004078457.tif 000007
【図６】
2004078457.tif 000008
【図７】
2004078457.tif 000009
【図８】
2004078457.tif 000010
【図９】
2004078457.tif 000011
【図１０】
2004078457.tif 000012
【図１１】
2004078457.tif 000013
【図１２】
2004078457.tif 000014