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