JP2004038872A

JP2004038872A - Method and program for changing policy of client equipment and client system in distributed processing system

Info

Publication number: JP2004038872A
Application number: JP2002198755A
Authority: JP
Inventors: Yutaka Irie; 入江　豊; Toshihiko Kanda; 神田　敏彦; Koichi Shimohara; 下原　幸一; Kyoji Yamashita; 山下　恭司
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2002-07-08
Filing date: 2002-07-08
Publication date: 2004-02-05

Abstract

<P>PROBLEM TO BE SOLVED: To provide a client system of a distributed processing system for facilitating a change of an access policy. <P>SOLUTION: Client equipment as remote equipment has client software Ynew for issuing a request to a distributed object X capable of accepting a request from remote equipment B connected via a network and for performing transfer of the request to be issued by communication of the preliminarily provided access policy or operation conditions. The client equipment is provided with an acquisition means 200 for acquiring the access policy being details of the communication or the operation conditions in the remote equipment in the case of transferring the request from a means for holding it so that its contents can be changed; and a means 200 for transferring the access policy obtained via the acquisition means to the client software and for reflecting it on operation setting on the client's side so as to be conditions of communication or operations corresponding to the access policy. <P>COPYRIGHT: (C)2004,JPO

Description

【０００１】
【発明の属する技術分野】
本発明は、ネットワークで接続される複数の計算機要素による分散処理環境、例えば、ＣＯＲＢＡを導入した分散処理システムの如き、分散オブジェクト環境に係わり、特にネットワークで接続されたリモート機器からのリクエストを受け付けることが可能な分散オブジェクトのリクエスト授受に当たっての前記リモート機器に対する通信や動作の条件の詳細であるアクセス・ポリシを容易変更可能にした分散処理システムにおけるクライアント機器およびクライアントシステムのアクセス・ポリシ変更方法および分散処理プログラムに関する。
【０００２】
【従来の技術】
多数の組み込み機器（エンベッド機器）を用いて構成したシステムであって、そのシステムの組み込み機器それぞれがＣＰＵ（プロセッサ）を制御の中枢に持つ独立したインテリジェントなシステムであり、分散環境を持つシステムがある。ここで、分散環境とは、ネットワーク・アプリケーションを構築する主要な技術の一つである分散オブジェクト指向技術による処理環境であって、これはデータの処理や操作を、手続きの流れとしてではなく、「もの（オブジェクト）」同士の関係としてとらえる考え方で、各種オブジェクト（オブジェクト指向プログラミングにおいて、プログラムを構成する基本的なモジュール）を分散配置して処理を分担させて進めていく方式である。
【０００３】
そして、複数のオブジェクトがあって、各オブジェクトに定義するオペレーションを、所定のインタフェース言語（ＩＤＬ）で定義する仕様を与え、定義されたオブジェクトをクライアントから所定の手続で呼べるようにするためのルールを決めたものとしてＣＯＲＢＡ仕様がある。
【０００４】
周知のように、ＣＯＲＢＡとは、“Ｃｏｍｍｏｎ　Ｏｂｊｅｃｔ　Ｒｅｑｕｅｓｔ　Ｂｒｏｋｅｒ　Ａｒｃｈｉｔｅｃｔｕｒｅ”の略であり、分散オブジェクト指向技術における標準的技術の一つであって、分散オブジェクト技術の標準化団体であるＯＭＧ（Ｏｂｊｅｃｔ　Ｍａｎａｇｅｍｅｎｔ　Ｇｒｏｕｐ）　が策定した規格である。
【０００５】
ＣＯＲＢＡは、個別のハードウエアやＯＳに依存せずに、分散したオブジェクトをネットワーク上で共有化し、統合するアーキテクチャの開発を目的とした標準仕様であり、ＣＯＲＢＡの規格では、バージョン２．４（ＣＯＲＢＡ　２．４　）において、特にリアルタイム処理分野や、組み込みシステム分野を対象とした処理優先度の概念を分散オブジェクトに導入した規格としてリアルタイム・コルバ（Ｒｅａｌ−ｔｉｍｅ　ＣＯＲＢＡ、以下、ＲＴ−ＣＯＲＢＡと称する）が追加された。そして、その処理優先度に関する標準仕様の部分を、特に、ＲＴ−ＣＯＲＢＡ　１．０と呼んでいる。従って、ＣＯＲＢＡ２．３以前の規格には、ＲＴ−ＣＯＲＢＡ仕様は含まれていない。
【０００６】
また、ＲＴ−ＣＯＲＢＡ１．０自体は、ＣＯＲＢＡのオプション仕様であるので、ＣＯＲＢＡ２．４以後に対応するＣＯＲＢＡ製品であっても、必ずしもＲＴ−ＣＯＲＢＡ仕様に準拠しているとは限らない。従って、以下で、「ＲＴ−ＣＯＲＢＡを含まないＣＯＲＢＡ」と記載する場合は、上記の両者を指すものである。
【０００７】
ＲＴ−ＣＯＲＢＡの環境において優先度を扱うひとつの典型的な方法として、オブジェクトは、そのオブジェクトを生成する段階で所望の優先度を指定しておき、当該優先度で活性化しておく方法がある。また、別の方法では、クライアントがリクエストを出す際に、処理優先度をオブジェクトに伝え、その優先度でオブジェクトの処理を実施する方法もある。いずれの方法にしても、そのオブジェクトに対するリクエストが、リモートにあるクライアントから到着したとき、先に指定した優先度を与えたタスクが生成され、リクエストの処理をそのタスク上で実行する。処理の要求（リクエスト）が同時に多数発生した場合、優先度の高いリクエストから実行されることになるが、優先度が同じ場合は、所定のタスク・スケジューリングに従って処理される。これらタスクへの優先度の割り当てや、タスク・スケジューリングなどの処理は、実際にはＯＳが実施するのであるが、後に説明するＯＲＢが、これらの処理の橋渡しを行う。
【０００８】
ＣＯＲＢＡ仕様のＯＲＢ環境で動作するオブジェクトをＣＯＲＢＡオブジェクトと呼ぶ。一般的な利用方法として、ＣＯＲＢＡオブジェクトは一つ以上のオペレーションを提供する。そして、ＣＯＲＢＡオブジェクトが用意するオペレーションを呼び出すには、ＯＲＢを経由してオペレーションの呼び出しを実施すればよい。
【０００９】
すなわち、ＯＲＢを利用してオペレーションの呼び出しを実施するプログラムがＣＯＲＢＡのクライアントである。ＣＯＲＢＡクライアントは、同時にＣＯＲＢＡオブジェクトであってもよいし、また、そうでなくともよい。
【００１０】
また、ＣＯＲＢＡの分野では、オペレーションの呼び出しに伴う通信のことを、特に「リクエスト」とよぶ。以下では、「リクエスト」と「オペレーションの呼び出し」は、同じ意味で使用している。
【００１１】
あるオブジェクトが、どのようなリクエストを受け付けることが可能であるかという情報は、リクエストを発行する側で知っておく必要がある。故に、どのようなインタフェースを有するかという情報を明らかにするために、ＩＤＬ（Ｉｎｔｅｒｆａｃｅ　Ｄｅｆｉｎｉｔｉｏｎ　Ｌａｎｇｕａｇｅ）が利用される。
【００１２】
このように、ＣＯＲＢＡは、ヘテロジニアスな分散環境を許容する。ＯＳが違っていても差し支えないのである。
【００１３】
その一方で、特にＲＴ−ＣＯＲＢＡを使用する場合においては、ポリシの調整の問題がある。これは、機器の持つＣＰＵの能力や通信能力、ネットワークの伝送速度といったリソースの能力が密接に絡む問題である。すなわち、機器がネットワークで接続され、各機器はハードウエアやソフトウエアとしての能力や要求される機能に差違があり、また、負荷の点から見た余力に差違があり、ネットワークの伝送状態に変動があり、…　といったように、種々の要件が重なって、運用状態でのシステム全体の動作にバランスを欠いたり、所望の性能が発揮できなくなったりする可能性があることから、ＣＯＲＢＡおよびＲＴ−ＣＯＲＢＡでは、数十種類ものポリシ・オブジェクトを定めており、ＣＯＲＢＡクライアント・プログラムや、サーバ・プログラムにおいて、そのポリシ・オブジェクトに、所定のポリシの値をパラメータとして設定する記述を追加することにより、ＯＲＢの挙動に原則を与え、性能に影響を与えることができる。
【００１４】
ところで、特に、ＲＴ−ＣＯＲＢＡを使ってシステムを構築する立場からは、これらのポリシに与えるべき値の中には、システムの設計段階では決めることができず、システムの構築が完了し、運用開始する段階においてポリシ（方針や原則や方策）を試行錯誤で調整したほうが明確に具合がよいものが多い。
【００１５】
例えば、クライアントからサーバにコネクションを確立し、このコネクションを利用して両者の間で伝送を行おうとした場合、コネクションに通常のコネクションとプライベートコネクションをコネクションとプライベートコネクションの双方を確保し、特別のセンサからの信号についてはプライベートコネクションを利用して伝送を行い、他の信号については通常のコネクションを利用して伝送を行うようにして、特別のセンサからの信号の伝送には他の信号の伝送に使われることのない専用のコネクションを用いて優先させるようにするといった設定は、与えられるポリシに従って成され、後述するＯＲＢにより管理運用されてその設定された内容のように利用に供されることになるが、このポリシの内容で試験運転してみたところ、敢えてプライベートコネクションを設けずとも、支障無く運用できることがわかった、といったことがあり、この場合、「プライベートコネクションと通常のコネクションの双方を確保する」という当初の構想から、「通常のコネクションのみ」とするといった方針の転換をはかることとなる。これは、一般に性能を確保しようとすればするほど、リソースの消費が多くなるという原則があり、それが設計、実装段階では、どちらが適性であるかを判別することができない例である。
【００１６】
これは試運転の結果、はじめて明らかとなって必要となったポリシの変更である。また、あるいは、運用中のシステムに機器を増設したり、機能を変更したりするものが生じとすると、これにより、今までは通常のコネクションのみを利用して全ての信号の伝送を行うようにしていたが、或る信号については支障を来すことになったといったようなこともあり、この場合、『通常のコネクションのみ』という当初の構想から、『プライベートコネクションと通常のコネクションの双方を確保する』とするといった方針の転換をはかることとなったとすると、これはシステム変更の結果、生じることとなったポリシの変更である。
【００１７】
このように、ポリシの設定方法は実際の稼動状況に合わせて調整する必要がある。これはクライアント（ｃｌｉｅｎｔ；ネットワーク上でほかのコンピュータやソフトウエアにサービスを要求する側のコンピュータまたはソフトウエア）がサーバ（ｓｅｒｖｅｒ；サービスを提供する側のコンピュータやソフトウエア）と接続しようとする際に発生する接続条件や動作条件などの設定に関しての問題であるが、極めて厄介な問題でもある。
【００１８】
ここでは、このポリシの変更についての問題を中心に考えることとするが、それに先立ち、分散オブジェクトのリクエストについて触れておく。
【００１９】
図１４は、従来の分散オブジェクトのリクエスト方法を説明する図であり、機器Ａと機器Ｂとの間でのリクエスト法を例として説明する図である。機器Ａはサーバ側の構成機器であって、ＣＯＲＢＡオブジェクトＸとＯＲＢ（Ｏｂｊｅｃｔ　Ｒｅｑｕｅｓｔ　Ｂｒｏｋｅｒ：オブジェクト・リクエスト・ブローカ）とを持つサービス機器であり、機器Ｂはクライアント側の構成機器であってＣＯＲＢＡクライアントプログラムＹとＯＲＢとを持つクライアント機器であり、ＣはＣＯＲＢＡのネーミング・サービスを提供する手段であり、別機器または機器Ａまたは機器Ｂいずれかに保持されている。そして、例えば、機器Ａ、Ｂは、それぞれ開発製造会社が異なる製品であるとし、それぞれ異なるＯＳ上で動作しているシステムであると仮定する。そして、これらがネットワーク上で接続されて動作するものとする。
【００２０】
機器Ａにおいては、ＣＯＲＢＡオブジェクトＸを生成・活性化するときに当該オブジェクトＸについてのリファレンス（その分散オブジェクトに付与した接続条件や動作条件等の必要情報を含む当該オブジェクトを一意に示すことができる情報）を公開する。そのときに、多くの場合に利用されるのが上述したネーミング・サービスである。
【００２１】
機器Ｂにおいては、ネーミング・サービス機能部Ｃに問い合わせ、リクエスト先となるＣＯＲＢＡオブジェクトＸのリファレンスをもらってくる。
【００２２】
要するに、ＣＯＲＢＡプログラムの開発に当たっては、機能実現に必要な各オブジェクトそれぞれについて、最初からそれぞれ固有の名前を決めておくと便利であることから固有名を利用する。これにより、どの機器でオブジェクトが稼動するかとは独立に、その固有の名前を用いてオブジェクトを特定することができる。
【００２３】
ここでは、機器ＡのオブジェクトＸをリクエストするクライアント側（機器Ａ）におけるＣＯＲＢＡクライアントプログラムＹでは、ネーミング・サービス機能部Ｃを利用したオブジェクト・リファレンスの問い合わせを実行し、これによりネーミング・サービス機能部Ｃから返された機器ＡにおけるＸなる名前のオブジェクトについてのＣＯＲＢＡ世界での特定できる情報すなわち、オブジェクト・リファレンスを取得し、これを用いてＣＯＲＢＡオブジェクトＸにリクエストを出す。
【００２４】
ネーミング・サービスに対するオブジェクト・レファレンスの問い合わせは、具体的には、設計やメンテナンスにおいて、もっとも便宜となる名前の文字列を引数にして対応するオブジェクトのリファレンスをこのネーミング・サービス機能部Ｃからとってくることであり、これにより、ＣＯＲＢＡクライアントプログラムＹの実行に伴う当該クライアントプログラムＹからオブジェクトＸに対するリクエストができることになる。
【００２５】
なお、ＣＯＲＢＡでは、オブジェクト・リファレンスをクライアントに渡す方法として、ネーミング・サービスを使用しない手段もあり、その１つはオブジェクト・リファレンスをＣＯＲＢＡで定められた文字列形式とよぶ形式に変換し、それをファイルとして別途のネットワーク手段により、クライアントに引き渡す方法もある。本発明は、ネーミング・サービスを使用する場合でも、使用しない場合の両者に対応する。
【００２６】
なお、ＣＯＲＢＡ仕様の機器Ａ，ＢにはＯＲＢを設けるが、このＯＲＢとは、ＣＯＲＢＡの基本サービスを提供すると共に、分散環境におけるオブジェクト間のやり取りを実現するためのメカニズムを提供するソフトウエアであって、リモートオブジェクト同士の相互的なやり取りを実現するために必要なミドルウエアであり、オブジェクト間での要求と応答をシームレスに実現するための仲介役としての機能を果たすものである。
【００２７】
動作を追ってみる。まず、機器ＡはＣＯＲＢＡサーバプログラムを持つが、このＣＯＲＢＡサーバプログラムはＲＴ−ＰＯＡ（Ｒｉａｌ−Ｔｉｍｅ　Ｐｏｔａｂｌｅ　Ｏｂｊｅｃｔ　Ａｄａｐｔｅｒ：ポータブル・オブジェクト・アダプタ）　を生成する。ＲＴ−ＰＯＡはＲＴ−ＣＯＲＢＡで定められている優先度を付けたり、ポリシ（方針や原則や方策）を設定したりするためのもので、このＲＴ−ＰＯＡ　を予め用意する。ＲＴ−ＣＯＲＢＡを利用するためには、このＲＴ−ＰＯＡ　は先に作っておかねばならないと規定されているので、まずこれを用意するのである。
【００２８】
ＣＯＲＢＡサーバプログラムには、前記のＣＯＲＢＡオブジェクトＸが含まれているとして、このＣＯＲＢＡオブジェクトＸの出番が生じたとする。すると、ＣＯＲＢＡサーバプログラムは当該オブジェクトＸを生成すると共に活性化する。活性化とは、あるＰＯＡとあるオブジェクトを結びつけてそのＰＯＡの上で、すなわちそのＰＯＡが持つポリシに従って、そのオブジェクトに対するクライアントからのリクエストを受け付けることを可能するということを指すものであり、ＲＴ−ＣＯＲＢＡの場合、ＲＴ−ＰＯＡ　上でそのオブジェクトＸを動作できる状態にすることである。そして、この活性化により、そのオブジェクトＸにはＲＴ−ＰＯＡ　に則った必要な優先度の付与された、しかも、前記ポリシに従った実行が可能となる。
【００２９】
ここでＣＯＲＢＡオブジェクトＸはクライアント側からのリクエスト待ちとなることから、サーバ側の処理は待ち状態となる。
【００３０】
ＣＯＲＢＡオブジェクトＸはリモートからアクセスしてもらわねばならないので、いま、このようなオブジェクトが利用可能であることを知らせるための公開情報であるオブジェクト・リファレンスを外部に出す（公開する）必要がある。
【００３１】
ＣＯＲＢＡサーバプログラムはＣＯＲＢＡオブジェクトＸを生成・活性化するときに当該オブジェクトＸについてのリファレンス（その分散オブジェクトに付与した優先度の情報を含む当該オブジェクトを一意に示すことができる情報）を公開し、ネーミング・サービスで利用できるようにする。
【００３２】
クライアント側（クライアント側のＣＯＲＢＡプログラムであるＣＯＲＢＡクライアントプログラムＹ）は、オブジェクト・リファレンスを辞書引きのようなかたちでネーミング・サービス機能部Ｃに問い合わせて、リクエスト先となるＣＯＲＢＡオブジェクトＸのリファレンスをもらってくる。
【００３３】
ここで、クライアントがサーバと接続しようとする段階を眺めてみる。まず、ＣＯＲＢＡでは、デフォルトのプロトコルとしてＩＩＯＰ（Ｉｎｔｅｒｎｅｔ　Ｉｎｔｅｒ−Ｏｒｂ　Ｐｒｏｔｏｃｏｌ）　を使用する規約であるが、その他のプロトコルを使用することもできる。ＲＴ−ＣＯＲＢＡでは、使用するプロトコルの優先順位を、１つのポリシとして保持できる。これは、クライアントとサーバで、共通して使用できるプロトコルで通信するように調整する必要があるため、使用するプロトコルの優先順位をプロトコルポリシーとして、保持するのである。つぎに、標準のＩＩＯＰを使用する場合は、これはＴＣＰに基づくコネクション型の通信であるので、サーバとクライアントの両者のＯＲＢ間でコネクションを確立する必要がある。
【００３４】
このコネクションの開設であるが、例えば、クライアントである機器Ｂからサーバである機器Ａに対してコネクション確立の手続を開始するに当たり、機器ＢのＣＯＲＢＡクライアントプログラムＹは接続条件や動作条件などについてそのポリシ設定内容に従った内容を持つようにコネクションを確立する。その際の条件は予め設定されたリクエスト（要求）の発信方式や通信方式などの詳細であるポリシ（アクセス・ポリシ）に従うことになるが、当該ポリシに従った条件は機器ＢのＣＯＲＢＡクライアントプログラムＹに埋め込まれるかたちとなり、これがＯＲＢに渡されて分散オブジェクトのリクエストの際に、従う条件としてＯＲＢで利用されることになる。
【００３５】
【発明が解決しようとする課題】
クライアントがサーバと接続しようとする段階において、例えば、クライアント機器Ｂからサーバ機器Ａに対してネットワークを経由するリクエストを開始するに当たり、クライアント機器ＢのＣＯＲＢＡクライアントプログラムＹは接続条件や動作条件などについてその設定内容に従った内容を持つように通信を実施する。その際の条件は予め設定されたアクセス・ポリシに従うことになるが、当該ポリシに従った条件は従来においては、クライアント機器ＢのＣＯＲＢＡクライアントプログラムＹに埋め込むようにしていた。そして、これがＣＯＲＢＡクライアントプログラムＹからクライアント機器ＢのＯＲＢに渡され、分散オブジェクトのリクエストの際に、従う条件として当該ＯＲＢで利用されることになる。
【００３６】
クライアント機器においては、サーバ側にリクエストするなどアクセスするに当たっては、（ａ）タイムアウト・ポリシ、（ｂ）クライアント・プロトコル・ポリシ、（ｃ）プライオリティ・ポリシ（優先度モデル）、（ｄ）コネクション，ｏｎｅｗａｙ，同期スコープといったアクセス・ポリシが関係する。
【００３７】
しかも、クライアント機器側でのポリシの設定情報は、自己から見てアクセスするサーバ別にそれぞれ必要となるから、それぞれＣＯＲＢＡクライアントプログラムＹ内に埋め込んで定義してある現状においては、いずれかに変更の要が生じるたびにソースプログラムの手直しというかたちをとらねばならなくなる。
【００３８】
そして、機器ＢのＣＯＲＢＡクライアントプログラムＹはその処理内容などをソースプログラムとして記述したものをコンパイルして実行プログラム化したものを用いるため、ポリシ変更は大変な手間がかかる。その一方で、ポリシ変更の要求は絶えることがない。
【００３９】
例えば、クライアントからサーバにリクエストを送信する場合に、コネクション型のプロトコル（ＩＩＯＰなど）を利用してクライアント側から或る要求を出し、その要求に対するサーバ側からの応答を待つという処理を行おうとした場合に、タイムアウト処理について考慮する必要がある。すなわち、そのタイムアウトの時間設定やタイムアウトの実行の有無などを設定する必要がある。そして、この設定は、予定したポリシに従ってソースプログラム中に記述しておくことにより行えることになるが、これが試験運転してみたところ、適切でないことがわかれば値を変更する必要に迫られる。
【００４０】
ＣＯＲＢＡを使用するネットワークでは、前述のクライアント、サーバ以外の機器も接続されていることが通常であり、一般に、ネットワークの稼動状況を事前に知ることは困難である。
【００４１】
開発現場や調整現場では最適値は値を加減しながら試行錯誤的に見つけ出すことになるので、最適値が見つかるまではその都度、ソースプログラムの手直し、再コンパイルと云った作業を経ることになる。また、最適値が見つかってその値で運用していても、機器の増設などのシステムに変更があった場合、最適値ではなくなってしまうこともあり、再び、最適値を見つけ直さねばならなくなる。ポリシの変更に伴うソースプログラムの変更はシステムの運用前はもちろんのこと、運用後もしばしば遭遇する問題である。
【００４２】
このように、多数の組み込み機器をネットワークで接続し、ＲＴ−ＣＯＲＢＡを適用するようにしたシステムにおいては、ＣＯＲＢＡクライアントプログラムよりサーバ（サーバ側のオブジェクト）をリクエストするに当たり、予め予定した接続条件などのポリシに従った接続と運用をＯＲＢにより行うようにするが、クライアント側とサーバとの間においては各クライアントはサーバ別にそのポリシの内容を細かく分けて定めるので、システム構成の変更などがあると、ポリシ変更が必要となる。そして、ポリシ変更には、ポリシの変更に伴うソースプログラムの変更が必要であり、この場合、ポリシ変更済みの実行プログラムを得るには、ソースプログラムの手直しと、その手直し済みのソースプログラムのコンパイルという作業が必要で、ポリシの変更には時間と手間がかかることになる。
【００４３】
その一方で、ポリシ変更の要求は絶えることがないことから、ポリシ変更をもっと手軽に行い得るようにする仕組みの早急な開発が嘱望されている。
【００４４】
本発明はネットワークを用いた分散処理環境におけるクライアントシステムにおいて、当該クライアントにおけるポリシ変更を容易に行えるようにしたクライアントシステムおよびクライアントシステムのポリシ変更方法およびポリシ変更容易なクライアントプログラムを提供することにある。
【００４５】
【課題を解決するための手段】
上記目的を達成するため、本発明は次のように構成する。すなわち、ネットワーク上の分散オブジェクトに対して、リクエストを発行し、その発行は予め与えられたアクセス・ポリシによる通信又は動作の条件に従って行うようにするリモート機器としてのクライアント機器において、
前記リクエスト授受に当たっての前記リモート機器における通信又は動作の条件の詳細であるアクセス・ポリシを内容変更可能に保持する手段より取得する取得手段と、この取得手段を介して得たアクセス・ポリシ対応の通信又は動作の条件となるようクライアント側動作設定に反映させる手段とを備えることを特徴とする。
【００４６】
また、前記リクエスト授受に当たっての前記リモート機器における通信又は動作の条件の詳細であるアクセス・ポリシを内容変更可能に保持する手段より取得する取得手段と、この取得手段を介して得たアクセス・ポリシをリスト化して参照可能な情報として前記分散オブジェクトに対してリクエストを発行するクライアント・ソフトウエアに渡す手段とを備え、
前記クライアント・ソフトウエアは前記参照可能な情報として渡されたアクセス・ポリシを取り込んで前記通信又は動作の条件となるようクライアント側動作設定に反映させる構成とすることを特徴とする。
【００４７】
このような構成によれば、ネットワークで接続されたリモート機器からのリクエストを受け付けることが可能な分散オブジェクトに対して、リクエストを発行するクライアント・ソフトウエアを有するクライアント機器において、システム全体の性能にかかわるそのリクエスト授受に当たっての前記リモート機器における通信や動作の条件の詳細であるアクセス・ポリシを、内容の書き換えが可能でシステム全体で管理可能な保持手段（アクセス・ポリシ・リポジトリ）から取得するようにし、この取得手段を介して得たアクセス・ポリシを前記クライアント・ソフトウエアに渡して前記アクセス・ポリシ対応の通信または動作の条件となるようクライアント側動作設定に反映させる。
【００４８】
また、システム全体の性能にかかわるそのリクエスト授受に当たっての前記リモート機器における通信や動作の条件の詳細であるアクセス・ポリシを、内容の書き換えが可能でシステム全体で管理可能な保持手段（アクセス・ポリシ・リポジトリ）から取得し、この取得したアクセス・ポリシをリスト化して参照可能な情報として前記クライアント・ソフトウエアに渡すようにし、クライアント・ソフトウエアはこの渡された情報を用いて前記アクセス・ポリシ対応の通信や動作の条件となるようクライアント側動作設定に反映する。すなわち、アクセス・ポリシをクライアント・ソフトウエアに埋め込んだプログラム形式ではなく、外部に置き、この外部に置いたアクセス・ポリシを参照してクライアント側動作設定に反映する外出し形式とし、アクセス・ポリシの内容を自由に変更できるようにした。
【００４９】
従って、本発明によれば、分散システムにおけるサーバ側のオブジェクト実体に対してのリクエスト時にクライアント側で用いる通信や動作の条件等の詳細を与えるための情報であるアクセス・ポリシについての変更の必要が生じた際には、アクセス・ポリシを内容変更可能に保持する手段の該当アクセス・ポリシ内容を変更すればそのポリシが反映されることになり、従って、ポリシ変更が極めて容易となる分散処理システムが実現できるようになる。
【００５０】
また、プログラム開発者にとって、ＲＴ−ＣＯＲＢＡを活用したプログラミングを行うには、通常、それぞれのポリシの効果に関する深い理解が要求されるが、本発明においては、事後にポリシを変更可能としたことによって、ＲＴ−ＣＯＲＢＡを含まない以前のバージョンのＣＯＲＢＡに習得した作業者であれば、ＲＴ−ＣＯＲＢＡのレベルを熟知していなくとも、ＲＴ−ＣＯＲＢＡの機能を活用したシステムを構築することが可能となり、ＲＴ−ＣＯＲＢＡによるシステム構築参入への門戸を開放して開発者を確保し易くすると共に、ＲＴ−ＣＯＲＢＡによるシステム構築に必要とされる工数低減をも図ることができる効果も得られる。
【００５１】
また、本発明は、ネットワークで接続されたリモート機器からのリクエストを受け付けることが可能な分散オブジェクトに対し、リクエストを発行するクライアント・ソフトウエアを有すると共に、発行するリクエストの授受は予め与えられたアクセス・ポリシに従った通信又は動作の条件にて行うようにするリモート機器としてのクライアント機器における前記アクセス・ポリシを設定変更するためのクライアントシステムのポリシ変更方法であって、
前記クライアント・ソフトウエアは前記リクエスト授受に当たっての前記リモート機器における通信又は動作の条件の詳細であるアクセス・ポリシを外部から受け取って用いるようにするために、前記クライアント・ソフトウエアは外部から受け取ったアクセス・ポリシを取り込んで、このアクセス・ポリシ対応の通信や動作の条件となるようクライアント側通信方式設定する形態とし、
前記アクセス・ポリシは内容変更可能に保持する手段に用意すると共に、前記保持手段から得たアクセス・ポリシを前記クライアント・ソフトウエアに渡して前記アクセス・ポリシ対応の通信又は動作の条件となるようクライアント側動作設定に反映させることを特徴とする。
【００５２】
本発明は、例えば、ＣＯＲＢＡを適用した分散処理システムを対象とするが、ＣＯＲＢＡのようなネットワークで接続された分散処理システムで、リモート機器からのリクエストを受け付けることが可能な分散オブジェクトに対し、リクエストを発行するクライアント・ソフトウエアのアクセス・ポリシを容易に設定変更できるようにするために、前記クライアント・ソフトウエアは前記リクエストの前記リモート機器に対する通信や動作の条件の詳細であるアクセス・ポリシを外部から受け取って用いるようにする。そのために、前記クライアント・ソフトウエアは外部から受け取ったアクセス・ポリシを取り込んでクライアント側通信方式設定する形態とし、
前記アクセス・ポリシは内容変更可能に保持する手段に用意すると共に、前記保持手段から得たアクセス・ポリシを前記クライアント・ソフトウエアに渡してクライアント側動作設定に反映させる。
【００５３】
具体的には、前記クライアント・ソフトウエアは前記リクエスト授受に当たっての前記リモート機器に対する通信や動作の条件の詳細であるアクセス・ポリシを外部から受け取って用いるようにするために、
前記アクセス・ポリシは内容変更可能に保持する手段に用意すると共に、この保持手段から得たアクセス・ポリシをリスト化して参照可能な情報にし、前記クライアント・ソフトウエアには前記参照可能な情報となったアクセス・ポリシを取り込んで前記アクセス・ポリシ対応の通信や動作の条件となるようクライアント側動作設定に反映させる。すなわち、アクセス・ポリシをクライアント・ソフトウエアに埋め込んだプログラム形式ではなく、外部に置いたアクセス・ポリシを参照してクライアント側動作設定に反映する外出し形式とし、アクセス・ポリシの内容を自由に変更できるようにした。
【００５４】
従って、本発明によれば、分散システムにおけるサーバ側のオブジェクト実体に対してのリクエスト時にクライアント側で用いる通信方式等の詳細を与えるための情報であるアクセス・ポリシについての変更の必要が生じた際には、当該ポリシ変更が極めて容易となるＣＯＲＢＡ分散処理システムにおけるクライアントシステムのポリシ変更方法が実現できるようになる。
【００５５】
また、プログラム開発者にとって、ＲＴ−ＣＯＲＢＡを活用したプログラミングを行うには、通常、それぞれのポリシの効果に関する深い理解が要求されるが、本発明においては、事後にポリシを変更可能としたことによって、ＲＴ−ＣＯＲＢＡを含まない以前のバージョンのＣＯＲＢＡに習得した作業者であれば、ＲＴ−ＣＯＲＢＡのレベルを熟知していなくとも、ＲＴ−ＣＯＲＢＡの機能を活用したシステムを構築することが可能となり、ＲＴ−ＣＯＲＢＡによるシステム構築参入への門戸を開放して開発者を確保し易くすると共に、ＲＴ−ＣＯＲＢＡによるシステム構築に必要とされる工数低減をも図ることができる効果も得られる。
【００５６】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を参照して説明する。
【００５７】
本発明は、多数の組み込み機器をネットワークで接続して分散環境上で動作させるＣＯＲＢＡ仕様のシステムにおいて、クライアントにおけるポリシの設定変更を容易に実施することができるようにする技術を提供する。
【００５８】
本発明技術を適用して好適な典型的応用事例としては、単数または複数のリアルタイム・システムや、エンベット型システムをネットワークで接続し、別の計算機により制御または監視するシステムであり、このようなシステムにおいて、クライアント側におけるクライアント側からサーバ側のオブジェクトにリクエスト（要求）を与えてやり取りする場合に両者間で用いる発信方式や通信方式などの詳細であるポリシ（アクセス・ポリシ）の変更を容易にするものである。
【００５９】
（本発明の概念）
以下、本発明の一実施例について図面を参照して説明するが、それに先立ち、はじめに、本発明の概念を説明しておく。本発明システムの概念的構成図を図１に示す。図において、Ａはサーバ側となるサービス機器であり、ＣＯＲＢＡオブジェクトＸとＯＲＢとを備えている。また、Ｂはクライアント側となる機器であり、ＣＯＲＢＡクライアントプログラムＹｎｅｗとＯＲＢおよびイニシャライザ２００とを備えている。ネーミング・サービス機能部ＣはＣＯＲＢＡのネーミング・サービスを提供するものであり、３００はポリシをイニシャライザ２００に提供するアクセス・ポリシ・リポジトリ機能部である。サービス機器Ａとクライアント機器Ｂはネットワーク（ＮＷ）を介して接続され、ネーミング・サービス機能部Ｃやアクセス・ポリシ・リポジトリ機能部３００は独立したコンピュータ上に置いてネットワーク（ＮＷ）で接続してあっても良いし、前記機器Ａ，Ｂのいずれかに組み込んであっても良い。
【００６０】
本発明においては、ＣＯＲＢＡにおける従来からのＯＲＢ（Ｏｂｊｅｃｔ　ＲｅｑｕｅｓｔＢｒｏｋｅｒ）、ネーミング・サービスの利用の他に、今回、新たにイニシャライザ（設定変更反映処理部）２００、アクセス・ポリシ・リポジトリ（条件設定指示機能部）３００の概念を導入した。
【００６１】
ここで、基本的知識としてＯＲＢ、ネーミング・サービスについて説明しておく。
【００６２】
ＣＯＲＢＡの基本サービスを提供するソフトウエアであるＯＲＢ（Ｏｂｊｅｃｔ　Ｒｅｑｕｅｓｔ　Ｂｒｏｋｅｒ：オブジェクト・リクエスト・ブローカ）は、分散環境におけるオブジェクト間の通信方法を実現するメカニズムを提供するソフトウエアであって、リモートオブジェクト同士の相互的なやり取りを実現するミドルウエアであり、オブジェクト間での要求と応答をシームレスに実現するための仲介役としての機能を果たすものである。一般的に、ＣＯＲＢＡと呼称する際は、その規格を意味するのに対し、ＯＲＢと呼ぶ場合には、ＣＯＲＢＡ規格を実現したミドルウエアであるソフトウエアを指す。本発明の記載においても、これに従う。
【００６３】
ＲＴ−ＣＯＲＢＡは、ＣＯＲＢＡ仕様に対する追加として策定された規格である。ＲＴ−ＣＯＲＢＡ規格では、大きく次の２点の仕様を定めている。
【００６４】
１つは“プロセッサ・リソースの管理”であり、もう一つは“ＯＲＢ間の通信の制御”である。
【００６５】
“プロセッサ・リソースの管理”とは、分散オブジェクトにおける優先度モデルとその実装手段の提供や、スレッド・プール管理手段の提供などを指しており、また、“ＯＲＢ間の通信の制御”とは、優先度の逆転を避けるようなコネクションの確立や、プロトコルの選択手段などを指している。
【００６６】
また、上述の優先度モデルとは、分散システム上での優先度の与え方や管理方法を定めるモデルのことを指す。ＲＴ−ＣＯＲＢＡ１．０では、“サーバ・デクリアード・モデル”と“クライアント・プロパゲーティッド・モデル”という２つのモデルが定義されている。このモデルの選択は、ＲＴ−ＣＯＲＢＡに定められた所定の手続きにより、いずれかを選択することができるようになっている。
【００６７】
また、上記の“サーバ・デクリアード・モデル”とは、サーバ側で特定の優先度をオブジェクト毎に設定するモデルである。このモデルは、典型的な使用方法としては、一度与えた優先度は変更しない用途向けであり、ＣＯＲＢＡオブジェクト毎に固定的な優先度を設定して差し支えないような用途のアプリケーションに向く。
【００６８】
また、“クライアント・プロパゲーティッド・モデル”とは、ＣＯＲＢＡクライアント側で、希望する優先度を指定してリクエストを発行するモデルであり、優先度は、リクエストの一部として埋め込まれてサーバ側に渡される。このモデルは、リクエストの内容（引数値）や、リクエストを発行するまでの文脈によって優先度を変える必要があるアプリケーションに向いており、サーバ・デクリアード・モデルと比較すれば、より汎用的な用途向けのモデルと云える。
【００６９】
ＣＯＲＢＡ仕様の特徴的な点として、ＯＲＢにより分散オブジェクトを実現するための仕様を提供する他に、多くのアプリケーションでしばしば必要となる種々の機能をＣＯＲＢＡオブジェクトとして実現したオブジェクトを仕様として盛り込んでいることがあげられる。これらはＣＯＲＢＡサービスと呼ばれており、ＣＯＲＢＡサービスを、分散システム構築を構成する一部品として利用することで、高度な機能を持つ分散オブジェクトシステムを容易に開発できるようにしている。
【００７０】
当該ＣＯＲＢＡサービスは実装言語に依存しないインタフェース記述ための言語であるＩＤＬ（インタフェース定義言語）で定義されたインタフェースを装備するサービスの集合であり、ＯＲＢに接続されたＣＯＲＢＡオブジェクトの集まりであって、これらはＯＲＢを介して利用できる。
【００７１】
一例をあげるとＣＯＲＢＡサービスには、ＯＲＢによって接続されたコンポーネント（オブジェクト）をシステム上でユニークに命名した名前で見つけ出すためのサービスを提供するネーミング・サービス（Ｎａｍｉｎｇ　ｓｅｒｖｉｃｅ）、オブジェクト間におけるイベントの登録や管理を行うためのサービスを提供するイベントサービス（Ｅｖｅｎｔ　Ｓｅｒｖｉｃｅ）、オブジェクト間におけるトランザクション制御を行うためのサービスであるトランザクションサービス（Ｔｒａｎｓａｃｔｉｏｎ　Ｓｅｒｖｉｃｅ）等が用意されている。
【００７２】
上述したネーミング・サービス（Ｎａｍｉｎｇ　ｓｅｒｖｉｃｅ）はＣＯＲＢＡ分散オブジェクトを、システム開発者が命名した便宜的な名前によって管理するためのサービスであり、ＯＲＢに接続されるオブジェクト間で名前による検索を可能にする環境を提供する。
【００７３】
ネーミング・サービスでは、オブジェクトの名前と、そのＩＤＬ言語上の型と、分散オブジェクトを一意に特定するオブジェクト・リファレンスとの、３つの情報を一件の情報として管理する。オブジェクト・リファレンスとは、分散オブジェクトを一意に特定するデータとして使用するもので、その内容は、ＣＯＲＢＡ仕様により定められたものである。ＯＲＢは、オブジェクト・リファレンスを解析することにより、特定の分散オブジェクトにアクセスできるように構成されている。
【００７４】
ネーミング・サービスに対して、ｂｉｎｄというオペレーションを用いることにより、前記１件の情報の追加登録を行うことができ、ｕｎｂｉｎｄというオペレーションにより、前記１件の情報の削除を行うことができ、更にはｒｅｓｏｌｖｅというオペレーションにより、名前をキーとして、に対応するオブジェクト・リファレンスの情報を取得することができる。
【００７５】
ネーミング・サービスの具体的利用形態について説明しておく。
サーバ側の機器であるサービス機器ＡにはＣＯＲＢＡサーバプログラムがあり、このサーバプログラムはＰＯＡをまずはじめに生成する。ＰＯＡ　はＲＴ−ＣＯＲＢＡで定められている優先度を付けたり、ポリシ（方針や原則や方策）を設定したりするためのもので、このＰＯＡを予め用意する。そして、ＣＯＲＢＡオブジェクトＸが必要なときはＣＯＲＢＡサーバプログラムは当該ＣＯＲＢＡオブジェクトＸを生成し、活性化する。
【００７６】
ＣＯＲＢＡオブジェクトＸはリモートからアクセスしてもらわねばならないので、いま、このオブジェクトが利用可能であることを知らせるための公開情報であるオブジェクト・リファレンスを外部に出す（公開する）必要がある。
【００７７】
ＣＯＲＢＡサーバプログラムはＣＯＲＢＡオブジェクトＸを生成・活性化するときに当該オブジェクトＸについてのリファレンス（その分散オブジェクトに付与した優先度の情報を含む当該オブジェクトを一意に示すことができる情報）を公開する。その際に利用されるのがネーミング・サービスである。
【００７８】
クライアント側（クライアント側のＣＯＲＢＡプログラムであるＣＯＲＢＡクライアントプログラムＹｎｅｗ）は、オブジェクト・リファレンスを辞書引きのようなかたちでネーミング・サービスに問い合わせて、リクエスト先となるＣＯＲＢＡオブジェクトＸのリファレンスをもらってくる。
【００７９】
ＣＯＲＢＡプログラムの開発に当たっては、機能実現に必要な各オブジェクトそれぞれについて、最初からそれぞれ固有の名前を決めておくと便利であることから、名前を付けて管理するので、これを利用するわけである。
【００８０】
この仕組みにより、機器ＡのオブジェクトＸをリクエストするクライアント側の構成機器ＢにおけるＣＯＲＢＡクライアントプログラムＹｎｅｗでは、ネーミング・サービス機能部Ｃの提供するネーミング・サービスを利用したオブジェクト・リファレンスの問い合わせを実行し、ＯＲＢは、これをＣＯＲＢＡ仕様で定められた方法によって解釈し、これを用いてＣＯＲＢＡオブジェクトＸにリクエストを出す、ということができることになる。
【００８１】
このように、各オブジェクトのリファレンスを他が参照して利用できるよう、提供の場として用意されたのがネーミング・サービスであり、本システムではネーミング・サービス機能部Ｃにより、このようなネーミング・サービスの機能が提供されている。
【００８２】
本発明においては、このようなＣＯＲＢＡにおける従来からのＯＲＢ、ネーミング・サービスの利用の他に、クライアント機器Ｂ側で利用する機能として新たにイニシャライザ（設定変更反映処理部）２００とアクセス・ポリシ・リポジトリ（条件設定指示機能部）３００の概念を導入したものであるが、これらのうち、アクセス・ポリシ・リポジトリ（条件設定指示機能部）３００は、クライアント側におけるアクセス・ポリシ（方針や原則や方策等に関する設定条件；以下、単にポリシと呼ぶ）を各クライアント別に持ち、クライアント側からの要求により、その要求のあったクライアントに対するポリシを取り出して当該クライアントに渡す機能を有するもので、各クライアント用のポリシはその仕様を当該アクセス・ポリシ・リポジトリ３００に入力することで自由に変更可能である。
【００８３】
また、イニシャライザ（設定変更反映処理部）２００は、クライアントに搭載される機能であって、当該イニシャライザ２００を搭載したクライアントのＣＯＲＢＡクライアントプログラムＹｎｅｗが必要とするタイミングにおいて、アクセス・ポリシ・リポジトリ３００に所定のポリシの転送要求を出し、この要求に対してアクセス・ポリシ・リポジトリ３００から送られてきたポリシを取り込み、クライアントのＯＲＢやオブジェクト・リファレンスに対してポリシの上書き更新を実施する仕組みを持たせたソフトウエアである。
【００８４】
ＢはＣＯＲＢＡクライアントプログラムＹｎｅｗを搭載したクライアント機器（クライアント側の機器）であるが、このクライアント機器Ｂには、イニシャライザ２００が搭載されている。サービス機器（サーバ側の機器）Ａに搭載されたＣＯＲＢＡオブジェクトＸは、ＣＯＲＢＡクライアントプログラムＹｎｅｗによりリクエスト（アクセス）され動作して、結果をＣＯＲＢＡクライアントプログラムＹｎｅｗに返す。クライアントＹｎｅｗがＣＯＲＢＡオブジェクトＸに対しリクエストを実施する際に、そこで用いるプロトコルの種類や、コネクションの確立方法や、リクエストの優先度などの条件を与えるのがアクセス・ポリシ・リポジトリ３００から送られてきたポリシであり、イニシャライザは、このポリシをクライアント側のＯＲＢに対しセットし、セット完了後に当該ＣＯＲＢＡクライアントプログラムＹｎｅｗに制御を戻すことで、クライアント機器ＢのＯＲＢは上記ポリシに従った条件で、サービス機器（サーバ側の機器）Ａ側のＣＯＲＢＡオブジェクトＸと、サービス側機器Ａ側のＯＲＢを介してのやり取りを行うことができる。
【００８５】
従来例として図１４で説明した構成に当て嵌めて比べてみると、サービス機器Ａは従来例の機器Ａに相当し、クライアント機器Ｂは従来例の機器Ｂに相当する。また、クライアント機器Ｂが搭載したＣＯＲＢＡクライアントプログラムＹｎｅｗは、機器ＢにおけるＣＯＲＢＡクライアントプログラムＹと基本的には同じであるが、本発明ではイニシャライザ２００により、アクセス・ポリシ・リポジトリ３００から与えられる当該クライアント機器Ｂ用のアクセス・ポリシの情報に従ったポリシ設定を行えるようにするために、ポリシ関係の部分はイニシャライザの内部に隠蔽された変数としてあり、ポリシ情報に従った値がこの変数に渡されてこの変数の内容による設定で動作するようなプログラムとなっている点が従来と異なる。
【００８６】
なお、クライアント機器Ｂで代表されるクライアント機器や機器Ａで段表されるサーバ側の機器は一般に複数有り、ネットワーク（ＮＷ）で接続されたシステム構成となっているが、ここでは簡単のため、クライアント機器はＢ一台のみを、また、サーバ側は機器Ａ一台のみによるシステム構成として説明する。
【００８７】
このような構成の本システムにおいては、クライアント機器である機器ＢのＣＯＲＢＡクライアントプログラムＹｎｅｗに与えるべきアクセス・ポリシの設定内容は、予め、アクセス・ポリシ・リポジトリ３００に設定しておく。
【００８８】
アクセス・ポリシは分散オブジェクト（ここではＣＯＲＢＡオブジェクト）等へのリクエスト等の授受に当たっての前記リモート機器に対する通信や動作の各種条件（方針や原則や方策等に関する設定条件）を指すものであるが、ここでの設定対象のポリシ種別としては、例えば、（ａ）タイムアウト・ポリシ（要求に対する相手側からの応答の許容待ち時間であるタイムアウトの実行の有無や、タイムアウト時間）、（ｂ）クライアント・プロトコル・ポリシ（ＣＯＲＢＡでは種々のプロトコルのうちから所望のプロトコルを選択できるのでそのプロトコルについての選択指定）、（ｃ）プライオリティ・ポリシ（優先度モデル（分散システム上での優先度の与え方や管理方法を定めるモデル、サーバ・デクリアードまたはクライアント・プロパゲーティッド）の指定）、（ｄ）コネクション，ｏｎｅｗａｙ，同期スコープ（確立させておくコネクションやその動作条件等）などがあり、このようなポリシの設定情報は、クライアント機器別に、しかも、クライアント機器側からみてアクセスするサーバ別にそれぞれ定義してある。
【００８９】
図２（ａ）を参照して動作を説明する。本システムにおいては、クライアント機器Ｂを起動させると、ＣＯＲＢＡクライアントプログラムＹｎｅｗは、ＣＯＲＢＡで定められた手続きである自機の有するＯＲＢの初期化を実施し（図２（ａ）のステップＳ１１）、次にイニシャライザ２００の設定を行うべく指令する（図２（ａ）のステップＳ１２）。イニシャライザ２００の設定は、ネーミング・サービスを利用して目的のサーバ・オブジェクトの参照（オブジェクト・リファレンス）を取得し、これをイニシャライザ２００に保持させるという処理である。
【００９０】
次に、ＣＯＲＢＡクライアントプログラムＹｎｅｗはイニシャライザ２００に目的サーバ・オブジェクトの参照（オブジェクト・リファレンス）の取得要求を出し、これにより、イニシャライザ２００より目的のサーバ・オブジェクトの参照（オブジェクト・リファレンス）を取得する。このとき、このサーバ・オブジェクトに対するリクエストにおいて採用するポリシ（群）を、イニシャライザ２００が、アクセス・ポリシ・リポジトリ３００より取得し、ＣＯＲＢＡ仕様に定められた方法に従ってオブジェクト・リファレンスに対してそのポリシを有効にする処理を実施する。合わせて、ＣＯＲＢＡクライアントプログラムＹｎｅｗに取得したオブジェクト・リファレンスを戻り値として戻す（図２（ａ）のステップＳ１３）。
【００９１】
次にＣＯＲＢＡクライアントプログラムＹｎｅｗは、ステップＳ１３で取得したオブジェクト・リファレンスに対し、ＣＯＲＢＡに定められた手続きであるダウンキャストを実施して目的のサーバ・オブジェクトのリファレンスを取得し（ＣＯＲＢＡ特有のステップ；（図２（ａ）のステップＳ１４））、サーバ・オブジェクトに対する分散オブジェクトの呼出を行い、必要に応じてこれを繰り返して実施する（図２（ａ）のステップＳ１５）。アプリケーションの終了時点においては、ＯＲＢをシャットダウンをして（図２（ａ）のステップＳ１６）から処理を終了する。
【００９２】
図には示していないが、サーバ・オブジェクトに対する分散オブジェクトの呼出を行う際にクライアント機器側のＯＲＢは指定したポリシ群に従ったポリシでアクセス対象のサーバをアクセスし、分散オブジェクトを呼び出して動作させる。
【００９３】
これが指定のポリシに基づいたクライアント機器Ｂでのサーバ側（機器ＡにおけるＣＯＲＢＡオブジェクト）に対するアクセスに至る一連のステップの概略である。
【００９４】
比較のために、イニシャライザおよびアクセス・ポリシ・リポジトリを備えない図１４に示す従来技術の場合の動作例を図２（ｂ）を用いて説明する。
【００９５】
図１４に示す従来構成のシステムにおいては、クライアント機器である機器ＢのＣＯＲＢＡクライアントプログラムＹに与えるべきポリシの設定内容は、予め、ＣＯＲＢＡクライアントプログラムＹ内に埋め込んである。（ａ）タイムアウト・ポリシ、（ｂ）クライアント・プロトコル・ポリシ、（ｃ）プライオリティ・ポリシ（優先度モデル）、（ｄ）コネクション，ｏｎｅｗａｙ，同期スコープといったクライアント機器側でのポリシの設定情報は、自己から見てアクセスするサーバ別にそれぞれＣＯＲＢＡクライアントプログラムＹ内に埋め込んで定義してある。
【００９６】
図２（ｂ）を参照して動作を説明する。本システムにおいては、クライアント機器Ｂを起動させると、ＣＯＲＢＡクライアントプログラムＹはＣＯＲＢＡで定められた手続きであるＯＲＢの初期化を実施し（図２（ｂ）のステップＳ１）、次にネーミング・サービスを利用して目的のサーバ・オブジェクトのリファレンス取得を行い（図２（ｂ）のステップＳ２）、ＣＯＲＢＡクライアントプログラムＹはこれを受け取る（図２（ｂ）のステップＳ３）。
【００９７】
次に、ＣＯＲＢＡクライアントプログラムＹは自己に埋め込まれたポリシの情報からサーバにアクセスする際のポリシを設定したポリシ・リストを作成し（図２（ｂ）のステップＳ４）、ポリシ・リストをサーバ・オブジェクトにセットする（図２（ｂ）のステップＳ５）。
【００９８】
次にＣＯＲＢＡクライアントプログラムＹはダウンキャストによる目的のサーバ・オブジェクトのリファレンスを取得し（ＣＯＲＢＡ特有のステップ；（図２（ｂ）のステップＳ６））、サーバ・オブジェクトに対する分散オブジェクトの呼出を行い（図２（ｂ）のステップＳ７）、ＯＲＢのシャットダウンをして（図２（ｂ）のステップＳ８）処理を終了する。
【００９９】
図には示していないが、サーバ・オブジェクトに対する分散オブジェクトの呼出を行う際にＯＲＢはポリシ・リストに従ったポリシでアクセス対象のサーバをアクセスし、分散オブジェクトを呼び出して動作させる。
【０１００】
これが従来システムにおける指定のポリシに基づいたクライアント機器Ｂでのサーバ側（機器ＡにおけるＣＯＲＢＡオブジェクト）に対するアクセスに至る一連のステップの概略である。
【０１０１】
図２からわかるように、本発明方式と従来技術とを比較すると、ポリシの設定・変更に関してはイニシャライザに機能が移されており、そのため、ＣＯＲＢＡクライアントプログラムはポリシ指定に関する処理部分が省略できるので、その分、ＣＯＲＢＡクライアントプログラムに要求される処理の内容が低減される。従って、本発明方式ではＣＯＲＢＡクライアントプログラムの開発が従来に比べて容易となる。しかも、本発明方式はアクセス・ポリシ・リポジトリに各クライアント機器別、アクセス対象のサーバ別のポリシ情報内容を記述して保管し、このポリシ情報内容はクライアント機器に設けたイニシャライザにより必要なものを取り込ませてクライアント機器のＣＯＲＢＡクライアントプログラムに渡すようにした可変構造型としたことにより、ポリシ内容を変えるにはポリシ情報の記述を変えるだけで対応でき、従って、システムの変化対応にポリシを自由に調整できるようになり、プログラムの手直しをすることなく、システムを最適に運用できるようになる。
【０１０２】
差が明確にわかるよう、本発明方式と従来技術とを更に詳細に比較してみる。
【０１０３】
従来のシステムでは、クライアント機器のＣＯＲＢＡクライアントプログラムにおいては図３に示すように、起動開始するとまずはじめにＯＲＢの初期化を行う（図３のＰ１）。そして、ネーミング・サービスの参照のための情報獲得を、ＯＲＢに対して要求する（図３のＰ２）。このとき、ＯＲＢはネーミング・サービスの参照のための情報を、ネーミング・サービス機能部Ｃから既に獲得しているものとする（図３のＰ０）。ネーミング・サービスの参照の獲得要求を受けたＯＲＢではネーミング・サービスの参照のための情報をＣＯＲＢＡクライアントプログラムに返すので、これを受けたＣＯＲＢＡクライアントプログラムでは、この参照情報から目的のオブジェクト（ターゲットとするオブジェクト）のリファレンスを取得すべくネーミング・サービス機能部Ｃに問い合わせを行う（図３のＰ３，Ｐ４）。オブジェクトのリファレンスはオブジェクトのメソッドを起動する際に必要な識別子であることから、この情報を得ることでターゲットとするオブジェクトへの要求が可能になる。
【０１０４】
ネーミング・サービス機能部ＣはＣＯＲＢＡクライアントプログラムからの上記問い合わせに対して要求に該当するオブジェクトのリファレンスを見つけ出し、ＣＯＲＢＡクライアントプログラムに返す（図３のＰ５）。これを受けてＣＯＲＢＡクライアントプログラムでは、目的のオブジェクトを起動できる準備が整う。
【０１０５】
ＣＯＲＢＡクライアントプログラムでは、次にポリシ・リストを生成し、必要なポリシの数をセットした後、ＯＲＢにポリシ生成の依頼を出す（図３のＰ６〜Ｐ８）。ＯＲＢではポリシ生成のためのプログラムであるポリシ・オブジェクトを起動し、クライアントプログラム中のポリシを一つ、ポリシ・リストに代入する処理をする（図３のＰ９，Ｐ１０）。この処理をＣＯＲＢＡクライアントプログラムは前記セットした数分、繰り返えすことにより、ポリシ・リストには、ＣＯＲＢＡクライアントプログラムに記述されたポリシの情報のうち、必要分が代入される。
【０１０６】
次にＣＯＲＢＡクライアントプログラムはこのポリシ・リストをアクセスに適用するポリシとして登録しておくリストに上書きする（図３のＰ１１）。内容の更新である。
【０１０７】
このようにして準備が整ったならば、サーバ側とアクセス可能な状態になる。サーバ側に対するアクセスは、目的のオブジェクトに対する目的のリクエストをＣＯＲＢＡクライアントプログラムがＯＲＢに対して行うことで、ＯＲＢは前記アクセスのポリシと前記取り込んだオブジェクト・リファレンスとを用い、オブジェクトの実体に対してリクエストを行う（図３のＰ１２）。これによりポリシに従った内容で管理運用されてオブジェクトの実体に対してリクエストが成され、当該オブジェクトの実体が機能されることになる（図３のＰ１３）。
【０１０８】
以上、従来の方法はすべて、ＣＯＲＢＡ仕様に定められた可能な方法のうちの典型的な方法を示したものである。これに対して本発明方法では、クライアント機器のＣＯＲＢＡクライアントプログラムにおいては図４に示すように、起動開始するとまずはじめにＯＲＢの初期化を行う（図４のＰ２１）。そして、次にＣＯＲＢＡクライアントプログラムは、イニシャライザ２００を起動する（図４のＰ２２）。これによりイニシャライザ２００は、ネーミング・サービスの参照のための情報を、ＣＯＲＢＡクライアントプログラムに返す（図４のＰ２３）。
【０１０９】
但し、これに先駆け、イニシャライザ２００はＯＲＢよりネーミング・サービスの参照のための情報を、ＯＲＢより取得しているものとする。また、当然のことながらＯＲＢはネーミング・サービスの参照のための情報を、ネーミング・サービス機能部Ｃから既に獲得しているものとする（図４のＰ０）。
【０１１０】
ネーミング・サービスの参照のための情報をイニシャライザ２００から受けたＣＯＲＢＡクライアントプログラムは、次に目的のオブジェクトの参照の情報取得をイニシャライザ２００に要求する（図４のＰ２４）。イニシャライザ２００は、これを受けてネーミング・サービスの参照のための情報獲得を、ＯＲＢに対して要求する（図５のＰ３１）。
【０１１１】
ネーミング・サービスの参照の獲得要求を受けたＯＲＢではネーミング・サービスの参照のための情報をイニシャライザ２００に返すので、これを受けたイニシャライザ２００では、この参照情報から目的のオブジェクト（ターゲットとするオブジェクト）のリファレンスを取得すべくネーミング・サービス機能部Ｃに問い合わせを行う（図５のＰ３２，Ｐ３３）。オブジェクトのリファレンスはオブジェクトのメソッドを起動する際に必要な識別子であることから、この情報を得ることでターゲットとするオブジェクトへの要求が可能になる。
【０１１２】
ネーミング・サービス機能部Ｃはイニシャライザ２００からの上記問い合わせに対して要求に該当するオブジェクトのリファレンスを見つけ出し、イニシャライザ２００に返す（図５のＰ３４）。これをイニシャライザ２００はＣＯＲＢＡクライアントプログラムに渡せる状態にするので、ＣＯＲＢＡクライアントプログラムでは、目的のオブジェクトを起動できる準備が整う。
【０１１３】
次にイニシャライザ２００は、ポリシ・リストの獲得（ＯＲＢ名称、オブジェクト名称）をアクセス・ポリシ・リポジトリ３００に対し要求する（図５のＰ３５および図４のＰ３５）。アクセス・ポリシ・リポジトリ３００はこれにより、該当のポリシ・リストを返す（図５のＰ３６）。このポリシ・リストは新たに渡されたものであり、クライアントのＯＲＢがもともと持っている設定は、そのままでは有効でありつづける。従って、新たなポリシ・リストでとデフォルトのポリシを上書き更新するために、イニシャライザ２００はポリシの更新を行う（図５のＰ３７）。
【０１１４】
そして、イニシャライザ２００はＣＯＲＢＡクライアントプログラムに対して当該更新によりポリシが更新されることとなったオブジェクトのリファレンスをクライアントプログラムに渡す（図５のＰ３８および図４のＰ３８）。
【０１１５】
このようにして準備が整ったならば、サーバ側と目的の通信条件によってアクセス可能な状態になる。サーバ側に対するアクセスは、目的のオブジェクトに対する目的のリクエストをＣＯＲＢＡクライアントプログラムがオブジェクト・リファレンスに対する呼び出しを実施することによって、ＯＲＢに対して行うことで（図４のＰ３９）、ＯＲＢは前記アクセスのポリシと前記取り込んだオブジェクト・リファレンスとを用い、オブジェクトの実体に対して目的とするポリシに従った通信条件によってリクエストを行う。これによりポリシに従った内容で管理運用されてオブジェクトの実体に対してリクエストが成され、当該オブジェクトの実体が機能されることになる（図４のＰ４０）。
【０１１６】
以上は本発明の動作概要である。
【０１１７】
（具体例）
次に具体例を説明する。図６は一例としての本発明摘要システムのブロック図である。図中１１及び１２はサーバであり、サーバ１１はＣＯＲＢＡオブジェクトであるサーバプログラム“ＳＶＲ＿Ａ”およびＣＯＲＢＡ仕様のミドルウエアであるＯＲＢを備えたインテリジェントな例えば測定機器などのサービス機器であり、サーバ１２はＣＯＲＢＡオブジェクトであるサーバプログラム“ＳＶＲ＿Ｂ”およびＣＯＲＢＡ仕様のミドルウエアであるＯＲＢを備えたインテリジェントな例えば、測定機器などのサービス機器である。
【０１１８】
また、２１および２２はクライアント機器であり、クライアント機器２１はクライアントプログラム“ＣＬＮ＿Ａ”およびＣＯＲＢＡ仕様のミドルウエアであるＯＲＢ（ＯＲＢ名“ＣＬＮ＿Ａ”のＯＲＢ（ＣＯＲＢＡではＯＲＢ名を定めて使用することが可能））およびＣＯＲＢＡオブジェクトとしてのクライアントプログラム“ＣＬＮ＿Ａ”およびイニシャライザ２００Ａを備えたサービス機器であり、ＯＲＢには“ＯＲＢ＿Ａ”なる名前を付して特定できるようにしてある。
【０１１９】
クライアント機器２２はクライアントプログラム“ＣＬＮ＿Ｂ”およびＣＯＲＢＡ仕様のミドルウエアであるＯＲＢ（ＯＲＢ名“ＣＬＮ＿Ｂ”のＯＲＢ）およびＣＯＲＢＡオブジェクトとしてのクライアントプログラム“ＣＬＮ＿Ｂ”およびイニシャライザ２００Ｂを備えたサービス機器であり、ＯＲＢには“ＯＲＢ＿Ｂ”なる名前を付して特定できるようにしてある。
【０１２０】
イニシャライザ２００Ａ，２００Ｂは、アクセス・ポリシ・リポジトリ３００からの定義情報に基づいてクライアントプログラム“ＣＬＮ＿Ａ”および“ＣＬＮ＿Ｂ”が自機実装のＯＲＢ（“ＯＲＢ＿Ａ”，“ＯＲＢ＿Ｂ”）に設定すべきポリシを与えるものであり、システムの起動初期時にクライアントプログラム“ＣＬＮ＿Ａ”および“ＣＬＮ＿Ｂ”に与える機能を有する。
【０１２１】
３００は既に説明した通りのアクセス・ポリシ・リポジトリであり、クライアント機器２１，２２のＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”、　“ＣＬＮ＿Ｂ”に与えるべきポリシ（ここではクライアント側で決めてクライアント側で使用するポリシ）の設定内容を与えるものである。ＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”、　“ＣＬＮ＿Ｂ”に与えるべきポリシの設定内容は、予め、アクセス・ポリシ・リポジトリ３００に設定しておくが、これを定めるのがリポジトリ定義ファイル３１０である。設定対象のポリシとしては、（ａ）タイムアウト・ポリシ（要求に対する相手側からの応答の許容待ち時間であるタイムアウトの実行の有無や、タイムアウト時間）、（ｂ）クライアント・プロトコル・ポリシ（所望のプロトコルの選択指定）、（ｃ）プライオリティ・ポリシ（優先度モデル（分散システム上での優先度の与え方や管理方法を定めるモデル）の指定）、（ｄ）コネクション，Ｏｎｅｗａｙ，同期スコープ（確立させておくコネクションやその動作条件等）などがあり、これらはいずれもクライアント側で決めてクライアント側で使用するポリシであって、このようなポリシの設定情報は、クライアント機器別に、しかも、クライアント機器側からみてアクセスするサーバ別にそれぞれ定義してある。
【０１２２】
図６の例では、クライアント機器２１はサービス機器１１とサービス機器１２の双方を相手としており、クライアント機器２２はサービス機器１２のみを相手として動作するシステムであることを示している。このシステム構成の場合におけるリポジトリ定義ファイル３１０の例を図７に示す。
【０１２３】
リポジトリ定義ファイル３１０は、アクセス・ポリシ・リポジトリ３００の設定用のファイルであって、図７に示す例ではＸＭＬで記述したファイル例を示している。なお、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ　ｍａｒｋｕｐ　ｌａｎｇｕａｇｅ；構造をもつ情報を記述するためのマークアップ言語（ｍａｒｋｕｐ　ｌａｎｇｕａｇｅ；特定の記号を用い、テキストファイルに文書の構造やデザイン、レイアウトなどの情報を付加するための言語）であり、ユーザが独自のタグを作って利用することができるので、表示するデータの意味を情報として記述しておくことができ、これを基にＷｅｂページ内のデータを検索したり、一部を抜き出して別の形式で保存するなど、データの再利用が可能になる特徴がある。
【０１２４】
もちろん、リポジトリ定義ファイル３１はＸＭＬ言語記述に限るものではなく、定義内容が記述できれば良いので、例えば、単なるテキストファイルであっても良く、他の言語であってもよい。
【０１２５】
クライアント機器２１，２２およびサービス機器１１，１２がネットワークＮＷで接続されており、クライアント機器２１はサービス機器１１とサービス機器１２の双方を相手としており、クライアント機器２２はサービス機器１２のみを相手として動作するシステムとした図６の構成例についてのＸＭＬによるファイル例である図７のファイル内容は次の如きである。
【０１２６】
まず第１行目の“＜？ｘｍｌ　ｖｅｒｓｉｏｎ＝　　　　…　…　＞”はＸＭＬの規格に基づく記述部分であり、本発明の内容には無関係な部分である。第２行目から第６行目の“＜！−−…　　　　　…−−＞”は注釈文（コメント）である。第７行目以下最終行までがアクセス・ポリシ・リポジトリの定義部分であり、“＜ＣＯＲＢＡ＿ＡＣＣＥＳＳ＿ＰＯＬＩＣＹ＿ＲＥＰＯＳＩＴＯＲＹ＞”が始まりのタグ、“＜／ＣＯＲＢＡ＿ＡＣＣＥＳＳ＿ＰＯＬＩＣＹ＿ＲＥＰＯＳＩＴＯＲＹ＞”が終わりのタグである。
【０１２７】
“＜ＲＴＯＲＢ　ｎａｍｅ＝“ＣＬＮ＿Ａ””以下第１８行目の“＜／ＲＴＯＲＢ＞”までが“ＣＬＮ＿Ａ”なる名前のリアルタイムＯＲＢの内容である。
【０１２８】
第１９行目　“＜ＲＴＯＲＢ　ｎａｍｅ＝“ＣＬＮ＿Ｂ””以下から第２３行目の“＜／ＲＴＯＲＢ＞”までが“ＣＬＮ＿Ｂ”なる名前のリアルタイムＯＲＢの内容である。
【０１２９】
“ＣＬＮ＿Ａ”なる名前のリアルタイムＯＲＢの内容は、ＣＯＲＢＡオブジェクトの一つである“ＳＶＲ＿Ａ”なる名前のサーバ・オブジェクトについてはその優先度（優先度値“１００００”）とタイムアウト・ポリシ（“１，０００，０００，０”）およびコネクションとして“ＳＶＲ＿Ａ”との通信専用とするように開設される伝送経路であるプライベートコネクションとすることが定められ、“ＳＶＲ＿Ｂ”なる名前のサーバ・オブジェクトについてはその優先度（優先度値“５０００”）で、リプライを必要としないリクエストすなわち、ｏｎｅｗａｙリクエストにおいて、ＣＯＲＢＡ仕様が定めるＳＹＮＣ＿ＷＩＴＨ＿ＴＲＡＮＳＰＯＲＴ方式でリクエストを実施することが定められ、“ＣＬＮ＿Ｂ”なる名前のリアルタイムＯＲＢの内容は、その優先度（優先度値“０”）とタイムアウト・ポリシ（“３，０００，０００，０”）が定められている、と云った内容である。優先度ポリシについては優先度ポリシクラス名と値、タイムアウト・ポリシはタイムアウトポリシクラス名と値といったように、ＣＯＲＢＡで定義されたポリシのインタフェースのクラスと同一クラス名を使用して定義したＸＭＬタグの例である。
【０１３０】
すなわち、この例は“ＣＬＮ＿Ａ”なるクライアントプログラムにおいては“ＳＶＲ＿Ａ”なる名前のサーバ・オブジェクトに対してアクセスあるいはやり取りする際には優先度（優先度値“１００００”の優先度で、且つ、タイムアウト時間は１０００［ｍｓ］（タイムアウト・ポリシ（“１，０００，０００，０”））、その他は指定なしで実施されるように、また、“ＳＶＲ＿Ｂ”なる名前のサーバ・オブジェクトに対してアクセスあるいはやり取りする際には優先度（優先度値“５０００”）、その他は指定なしで、すなわち、ＯＲＢがデフォルトで持っているポリシを更新しないでそのまま実施される、という具合に定めてある。
【０１３１】
また、“ＣＬＮ＿Ｂ”なるクライアントプログラムにおいてはその動作時には優先度値“０”なる優先度で、且つ、タイムアウト時間は３００［ｍｓ］（タイムアウト・ポリシ“３，０００，０００，０”）で、その他は指定なしで、すなわり、ＯＲＢがデフォルトで持っているポリシを更新しないでそのまま実施される、という具合に定めてある。この例は、クライアント毎に自己あるいは相手先別に動作条件が異なるようにする必要のある場合の例であるが、このようにクライアント毎に動作条件が異なるようにする必要がある場合には、条件が変わったり、システム内容が変更されたり、調整段階などである一部の内容変更が、全体のバランスに影響を与えるようなシステムでは、ポリシ内容を試行錯誤的に設定する必要が多々生じるが、アクセス・ポリシ・リポジトリ定義情報はＸＭＬやテキストなどにより定義して与えれば良いので変更が楽である。
【０１３２】
アクセス・ポリシ・リポジトリ３００は、イニシャライザ２００Ａ，２００Ｂからの要求を受けてこの定義情報内容を読み取り、イニシャライザ２００Ａ，２００Ｂが理解できるように咀嚼してその定義内容を渡す機能を備えており、その機能は図８に示す如きインタフェースプログラムにより実現される。
【０１３３】
図８は、ＩＤＬ言語によるアクセス・ポリシ・リポジトリ３００のインタフェース定義の例であるが、その動作内容は図９のフローチャートに示す如く、設定ファイルの読み込んでクライアント毎のＯＲＢデフォルト並びにアクセス先オブジェクト毎のポリシ定義を取得（リポジトリ定義ファイル３１０の読み込み、クライアント毎のＯＲＢデフォルト並びにアクセス先オブジェクト毎のポリシ定義を取得；図９のステップＳ３１）、各クライアントにおけるイニシャライザ２００Ａ，２００Ｂからのリクエスト待ちとなる（図９のステップＳ３２）。
【０１３４】
イニシャライザ２００Ａまたは２００Ｂからリクエストが出されたとすると、そのリクエストがポリシ取得要求であるか否か、ポリシ取得要求であればどのようなポリシ取得要求であるかをステップＳ３３，Ｓ３４，Ｓ３５でチェックする。すなわち、リクエストが出されたとすると、それが“ｇｅｔＰｏｌｉｃｙＦｏｒＯｒｂ”であるか否かをチェックする（ステップＳ３３）。
【０１３５】
その結果、その要求がＯＲＢのポリシ取得要求である“ｇｅｔＰｏｌｉｃｙＦｏｒＯｒｂ”であったとすると、　その要求を出したイニシャライザ２００用の該当ＯＲＢ用のポリシ・リストを返却する（ステップＳ３６）。要求されたクライアント機器に必要なＯＲＢ用のポリシ・リストを返却したならば、ステップＳ３２の処理に戻る。
【０１３６】
図９のステップＳ３３において、出されたイニシャライザ２００からのリクエストが“ｇｅｔＰｏｌｉｃｙＦｏｒＯｒｂ”でなければ、ポリシ取得要求が“ｇｅｔＰｏｌｉｃｙＦｏｒＯｂｊｅｃｔ”　であるか否かをチェックする（ステップＳ３４）。
【０１３７】
その結果、その要求が“ｇｅｔＰｏｌｉｃｙＦｏｒＯｂｊｅｃｔ”であったとすると、このＯＲＢ名のＯＲＢ上でこのサーバ・オブジェクト名のサーバにアクセスする場合のポリシが欲しいと云うかたちで要求が来るので、その要求を出したイニシャライザ２００に、ＯＲＢ名、オブジェクト名の該当するポリシ・リストを取り出してそのポリシ・リストを返却する（ステップＳ３７）。要求されたクライアント機器に必要なポリシ・リストを返却したならば、ステップＳ３２の処理に戻る。
【０１３８】
図９のステップＳ３４でリクエストが“ｇｅｔＰｏｌｉｃｙＦｏｒＯｂｊｅｃｔ”でなかったとすると、“ｓｈｕｔＤｏｗｎ”を受信したか否かをチェックし（図９のステップＳ３５）、“ｓｈｕｔＤｏｗｎ”を受信していなければステップＳ３２の処理に戻ってＳ３２以降を繰り返すが、ステップＳ３５において“ｓｈｕｔＤｏｗｎ”を受信したならば処理を終了する。
【０１３９】
図８のプログラムによる処理内容はこのようなものである。これにより、アクセス・ポリシ・リポジトリ３００はイニシャライザ２００Ａまたは２００Ｂからの要求に従い、必要なポリシ・リストを受け渡すことができるシステムとなる。
【０１４０】
Ｃ＋＋言語によるイニシャライザ２００のＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ　Ｉｎｔｅｒｆａｃｅ）を定義する部分のソースプログラム例を図１０に示しておく。図１０で定義されているメソッド名は、後に実施例として示す図１２および図１３における、クライアント・プログラムからイニシャライザを呼び出す際のメソッド名と対応したものになっている。具体的には、図１２のＰ５３、Ｐ５９および、図１３のＰ７３、Ｐ７７に対応する。
【０１４１】
この結果、図１１に示すように、クライアント機器２１はサーバ側であるサービス機器１１に対してはリクエスト優先度が“１００００”、タイムアウトは１０００［ｍｓ］、プライベートコネクションと云う内容で“ＯＲＢ＿Ａ”が動作し、サービス機器１２に対してはリクエスト優先度が“５０００”であり、“ＣＯＲＢＡ仕様が定めるＳＹＮＣ＿ＷＩＴＨ＿ＴＲＡＮＳＰＯＲＴ方式によるｏｎｅｗａｙリクエスト”であり、かつタイムアウトは１００［ｍｓ］、プライベートコネクションによる接続と云う内容で“ＯＲＢ＿Ａ”が動作し、クライアント機器２２はサーバ側であるサービス機器１２に対してのみ、接続可能でリクエスト優先度が“０”、タイムアウトは３０００［ｍｓ］と云う内容で“ＯＲＢ＿Ｂ”が動作するかたちに設定されることになる。
【０１４２】
ＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”の挙動を、ネーミング・サービスを用いない場合と、ネーミング・サービスを用いる場合とについて説明する。
【０１４３】
ネーミング・サービスを用いない場合の挙動を図１２に示す。
【０１４４】
本発明方法では、クライアント機器のＣＯＲＢＡクライアントプログラムにおいては図１２に示すように、起動開始するとまずはじめにＯＲＢの初期化を行う（図１２のＰ５１）。そして、次にＣＯＲＢＡクライアントプログラムは、イニシャライザ２００Ａを生成して起動し、初期化を指示する（図１２のＰ５２，Ｐ５３）。
【０１４５】
前記の初期化において、イニシャライザ２００Ａは、“ＣＬＮ＿Ａ”での必要とするＯＲＢポリシの取得の要求（問い合わせ）をアクセス・ポリシ・リポジトリ３００に対してリクエストする（図１２のＰ５４）。これを受けたアクセス・ポリシ・リポジトリ３００では、図９に示す動作ステップに従い、あらかじめ登録されている該当のＯＲＢポリシを検索または何らかのアルゴリズムにより抽出してイニシャライザ２００Ａにポリシ・リストとして返す（図１２のＰ５５）。
【０１４６】
イニシャライザ２００Ａはアクセス・ポリシ・リポジトリから受け取ったポリシ・リストに従って、ＯＲＢに対し、そのポリシを有効にするための、ＣＯＲＢＡ仕様で定められた所定の手続きを実施する。なお、実施例における本動作例においては、返されたポリシ・リストがヌル（リスト長が０）であるため、イニシャライザからＯＲＢに対するポリシの更新動作は行われていないという想定である。その後、ＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”に処理を戻す（図１２のＰ５６）。
【０１４７】
つぎに、ＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”は目的のオブジェクト（ここではアクセス対象となるサーバ側のオブジェクトは“ＳＶＲ＿Ａ”と“ＳＶＲ＿Ｂ”である）のリファレンスの取得要求を出す（図１２のＰ５７）。
【０１４８】
最初は“ＳＶＲ＿Ａ”の、次に“ＳＶＲ＿Ｂ”のリファレンス取得を要求するとすれば、Ｐ５７では“ＳＶＲ＿Ａ”のリファレンス取得を要求することとなる。ここでは、ネームサービスを使用しない構成であるので、オブジェクト・リファレンスは、ネームサービス以外の手段によって取得することになる。その手段は後述するが、ＣＯＲＢＡシステム構築においてよく実施されるいくつかの方法があり、それらのうち、いずれかの方法を用いて取得する。すなわち、取得の方法は、クライアントＣＬＮ＿Ａ・プログラムに開放されている。
【０１４９】
“ＳＶＲ＿Ａ”のリファレンス取得の具体例としては、つねに一定値の内容であることを保証する永続ＩＯＲ（Ｉｎｔｅｒｏｐｅｒａｂｌｅ　Ｏｂｊｅｃｔ　Ｒｅｆｅｒｅｎｃｅ）を使う方法やＣＯＲＢＡ仕様で定められている所定の文字列化形式を書き込んだファイルを渡す方法などがあり、ＣＯＲＢＡ仕様上で可能な方法ならば何を利用しても差し支えない。
【０１５０】
なお、本実施例の別の形態として、このリファレンスの検索の機能をアクセス・ポリシ・リポジトリ３００に組み込んだ構成とすることも可能である。すなわち、アクセス・ポリシ・リポジトリがネーミング・サービスの機能を代行する構成である。この場合、要求を受けたアクセス・ポリシ・リポジトリ３００は、“ＳＶＲ＿Ａ”のリファレンスを抽出し、ＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”に返す（図１２のＰ５８）。
【０１５１】
このように、いずれかの手段によって“ＣＬＮ＿Ａ”に必要な“ＯＲＢ＿Ａ”用のポリシと“ＳＶＲ＿Ａ”のリファレンス取得が終了したならばＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”は、イニシャライザ２００Ａに“ＳＶＲ＿Ａ”に対するアクセス（リクエスト）で用いるのポリシのセット（設定）依頼を出す（図１２のＰ５９）。
【０１５２】
これを受けてイニシャライザ２００Ａは、“ＯＲＢ＿Ａ”における“ＳＶＲ＿Ａ”　に対してのポリシ取得（問い合わせ）のリクエストをアクセス・ポリシ・リポジトリ３００に対して行う（図１２のＰ６０）。要求を受けたアクセス・ポリシ・リポジトリ３００は、図９の処理手順に従って、“ＯＲＢ＿Ａ”における“ＳＶＲ＿Ａ”　に対してのポリシを検索・抽出し、イニシャライザ２００Ａに該当するポリシ・リストを返す（図１２のＰ６１）。
【０１５３】
本例の場合、優先度“１００００”、タイムアウト“１０００［ｍｓ］”、“プライベートコネクション”機能利用という３件のポリシが抽出され、イニシャライザ２００Ａに返されることになる。
【０１５４】
イニシャライザ２００Ａはこの３件のポリシをサーバ側のオブジェクト“ＳＶＲ＿Ａ”に対しての接続する場合での条件としてオブジェクト“ＳＶＲ＿Ａ”用リファレンスにセットする（図１２のＰ６２）。このセットは、ＣＯＲＢＡ仕様に定められたオブジェクト・リファレンスに対するｓｅｔ＿ｐｏｌｉｃｙ＿ｏｖｅｒｒｉｄｅｓオペレーションにより、実施することができる。このセットにより、デフォルトのオブジェクト“ＳＶＲ＿Ａ”用リファレンスに対してこれとは別のオブジェクト“ＳＶＲ＿Ａ”用リファレンスが新たに返されるので（図１２のＰ６３）、この新たにできたオブジェクト“ＳＶＲ＿Ａ”用リファレンスをクライアントＣＬＮ＿Ａのプログラムに返す（図１２のＰ６４）。
【０１５５】
これによって、クライアントＣＬＮ＿Ａのプログラムにおいて、目的の通信設定によって、サーバ・オブジェクトＳＶＲ＿Ａに対するリクエストが可能な状態となる。その後のアクセス手順や方法は、クライアントＣＬＮ＿Ａ・プログラムの所望の手順で実施すればよい。同様な手続きを経て、オブジェクト“ＳＶＲ＿Ｂ”用レファレンスも取得して作成する。
【０１５６】
このようにしてオブジェクト“ＳＶＲ＿Ａ”用リファレンスおよびオブジェクト“ＳＶＲ＿Ｂ”用レファレンスが作成されたならば、ＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”はオブジェクト“ＳＶＲ＿Ａ”やオブジェクト“ＳＶＲ＿Ｂ”に新しいポリシに従ったアクセスが可能になる。例えば、オブジェクト“ＳＶＲ＿Ａ”にアクセスしようとするならば、ＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”はオブジェクト“ＳＶＲ＿Ａ”に対して目的のリモート・リクエストを出す（図１２のＰ６５）。
【０１５７】
このとき、ＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”はオブジェクト“ＳＶＲ＿Ａ”用リファレンスに基づき、“ＯＲＢ＿Ａ”における“ＳＶＲ＿Ａ”　に対してのポリシをクライアント機器２１のＯＲＢである“ＯＲＢ＿Ａ”に対して適用し、ＯＲＢはＣＯＲＢＡ仕様に基づいてこのポリシに従い、“ＯＲＢ＿Ａ”は“ＳＶＲ＿Ａ”　の実体に対してのリクエストを行うことになる（図１２のＰ６６）。
【０１５８】
以上の構成に基づき、総合的な性能上の理由や、個別のクライアント・プログラムの動作上の都合等により、通信動作のポリシを変更したい場合は、ポリシの変更をポリシ定義の書き換え（リポジトリ定義ファイル３１０の書き換え）により行い、この新たなポリシ定義をアクセス・ポリシ・リポジトリにより解釈して、ポリシ・リストとして定義内容をイニシャライザに渡し、イニシャライザではこの受け取ったポリシ・リストに基づいて、クライアントプログラムから所定のメソッド（図１０に例においては、ｉｎｉｔメソッドや、ｓｅｔＰｏｌｉｃｙメソッド）が呼び出されたタイミングにより、ＯＲＢやオブジェクト・リファレンスのポリシ定義を更新するようにし、サーバ側のオブジェクト実体に対してのリクエスト時に用いるポリシをクライアントプログラムに保持させることができるようにしたので（ポリシ定義外出し形式）、サーバ側のオブジェクト実体に対してのリクエスト時にクライアント側で用いる通信方式等の詳細であるアクセス・ポリシの変更は、アクセス・ポリシ・リポジトリに与えるポリシ定義の定義内容変更のみで可能となり、変更後のポリシ定義の定義内容はアクセス・ポリシ・リポジトリが解釈してイニシャライザに渡し、イニシャライザがリファレンス変更のかたちでクライアントプログラムに渡し、取り込ませＯＲＢに反映させるようになるので、このポリシに従った条件で、ＯＲＢにリクエスト先のサーバ側のオブジェクト実体にアクセスできるようになる。
【０１５９】
従って、ポリシを変更する必要が生じた場合に、ポリシ定義の書き換え（リポジトリ定義ファイルの書き換え）のみでその反映ができるようになるので、従来、ポリシ内部埋込み型であったためにポリシ変更に際しては必要であったクライアントプログラムの書き換えが不要となり、ソースプログラムの書き換えとその書き換え後のソースプログラムのコンパイルといった面倒な作業が不要となって、ポリシ変更が極めて容易なＣＯＲＢＡシステムが実現できることになる。
【０１６０】
以上は、ネーミング・サービスを用いない場合の例であったが、ネーミング・サービスを用いる場合でのＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”の挙動を、次に説明する。
【０１６１】
ネーミング・サービスを用いる場合の挙動を図１３に示す。
本発明方法では、クライアント機器のＣＯＲＢＡクライアントプログラムにおいては図１３に示すように、起動開始するとまずはじめにＯＲＢの初期化を行う（図１３のＰ７１）。そして、次にＣＯＲＢＡクライアントプログラムは、イニシャライザ２００Ａを生成して起動し、初期化を指示する（図１３のＰ７２，Ｐ７３）。このとき、ネーミング・サービスに対するオブジェクト・リファレンスを引数としてイニシャライザに渡す点が、ネーミング・サービスを使用しない構成の場合と異なる。
【０１６２】
前記の初期化において、イニシャライザ２００Ａは、“ＣＬＮ＿Ａ”での必要とするＯＲＢポリシの取得の要求（問い合わせ）をアクセス・ポリシ・リポジトリ３００に対してリクエストする（図１３のＰ７４）。これを受けたアクセス・ポリシ・リポジトリ３００では、図９に示す動作ステップに従い、あらかじめ登録されている該当のＯＲＢポリシを検索または何らかのアルゴリズムにより抽出してイニシャライザ２００Ａにポリシ・リストとして返す（図１３のＰ７５）。
【０１６３】
イニシャライザ２００Ａはアクセス・ポリシ・リポジトリから受け取ったポリシ・リストに従って、ＯＲＢに対し、そのポリシを有効にするための、ＣＯＲＢＡ仕様で定められた所定の手続きを実施する。なお、実施例における本動作例においては、返されたポリシ・リストがヌル（リスト長が０）であるため、イニシャライザからＯＲＢに対するポリシの更新動作は行われていないという想定である。その後、ＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”に処理を戻す（図１３のＰ７６）。
【０１６４】
つぎに、ＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”は目的のオブジェクト（ここではアクセス対象となるサーバ側のオブジェクトは“ＳＶＲ＿Ａ”と“ＳＶＲ＿Ｂ”である）のリファレンスの取得要求をイニシャライザ２００Ａに対して出す（図１３のＰ７７）。最初は“ＳＶＲ＿Ａ”の、次に“ＳＶＲ＿Ｂ”のリファレンス取得を要求するとすれば、これを受けたイニシャライザ２００ＡにおいてはＰ７８ではネーミング・サービスＣに対して“ＳＶＲ＿Ａ”のリファレンス取得を要求することとなる。
【０１６５】
要求を受けたネーミング・サービスでは、“ＳＶＲ＿Ａ”のリファレンスを抽出し、オブジェクト“ＳＶＲ＿Ａ”用のリファレンス（その１）としてイニシャライザ２００Ａに返す（図１３のＰ７９）。これをイニシャライザ２００Ａは、一時取り込み、　“ＣＬＮ＿Ａ”に必要な“ＯＲＢ＿Ａ”用のポリシと“ＳＶＲ＿Ａ”のリファレンス取得が終了したならばイニシャライザ２００Ａは、アクセス・ポリシ・リポジトリ３００に“ＳＶＲ＿Ａ”リクエスト用（アクセス用）のポリシの取得要求（問い合わせ）を出す（図１３のＰ８０）。
【０１６６】
要求（問い合わせ）を受けたアクセス・ポリシ・リポジトリ３００は、図９の処理手順に従って、“ＯＲＢ＿Ａ”における“ＳＶＲ＿Ａ”　に対してのポリシを検索・抽出し、イニシャライザ２００Ａに該当するポリシ・リストを返す（図１３のＰ８０）。
【０１６７】
本例の場合、優先度“１００００”、タイムアウト“１０００［ｍｓ］”、“プライベートコネクション”機能利用という３件のポリシが抽出され、ポリシ・リストとしてイニシャライザ２００Ａに返されることになる。イニシャライザ２００Ａは、この３件のポリシを、サーバ側のオブジェクト“ＳＶＲ＿Ａ”に対して接続する場合の通信の条件として前記オブジェクト“ＳＶＲ＿Ａ”用リファレンス（その１）にセットする。このセットは、ＣＯＲＢＡ仕様に定められたオブジェクト・リファレンスに対するｓｅｔ＿ｐｏｌｉｃｙ＿ｏｖｅｒｒｉｄｅｓオペレーションにより、実施することができる。
【０１６８】
この結果として、新たなポリシ設定が有効となったオブジェクト“ＳＶＲ＿Ａ”用リファレンス（その２）がイニシャライザにおいて得られるので、これをＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”に返す（図１３のＰ８２）。ＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”はこれを戻り値として受け取ることにより、上記３件のポリシが埋め込まれたオブジェクト“ＳＶＲ＿Ａ”用リファレンスを得ることになる。
【０１６９】
同様な手続きを経て、ポリシが更新されたオブジェクト“ＳＶＲ＿Ｂ”用レファレンスも取得して作成し、これをＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”に返す（図１３のＰ８２）。ＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”はこれを取り込むことにより、ポリシが埋め込まれたオブジェクト“ＳＶＲ＿Ｂ”用リファレンスを得ることになる。
【０１７０】
このようにして“ＣＬＮ＿Ａ”に必要な“ＯＲＢ＿Ａ”用のポリシと“ＳＶＲ＿Ａ”　、“ＳＶＲ＿Ｂ”のリファレンスの取得が終了したならば、ＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”はオブジェクト“ＳＶＲ＿Ａ”やオブジェクト“ＳＶＲ＿Ｂ”に新しいポリシに従ったアクセスが可能になる。例えば、オブジェクト“ＳＶＲ＿Ａ”にアクセスしようとするならば、ＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”はオブジェクト“ＳＶＲ＿Ａ”に対して目的のリモート・リクエストを出す（図１３のＰ８３）。このとき、ＣＯＲＢＡクライアントプログラム“ＣＬＮ＿Ａ”はオブジェクト“ＳＶＲ＿Ａ”用リファレンスに基づき、“ＯＲＢ＿Ａ”における“ＳＶＲ＿Ａ”　に対してのポリシをクライアント機器２１のＯＲＢである“ＯＲＢ＿Ａ”に対して適用し、ＯＲＢはＣＯＲＢＡ仕様に基づいてこのポリシに従い、“ＯＲＢ＿Ａ”は“ＳＶＲ＿Ａ”　の実体に対してのリクエストを行うことになる（図１３のＰ８４）。
【０１７１】
但し、これに先駆け、ネーミング・サービスに対するリファレンスはあらかじめ獲得しているものとする（図１３のＰ０）。
【０１７２】
以上の構成に基づき、総合的な性能上の理由や、個別のクライアント・プログラムの動作上の都合等により、通信動作のポリシを変更したい場合は、ポリシの変更をポリシ定義の書き換え（リポジトリ定義ファイル３１０の書き換え）により行い、この新たなポリシ定義をアクセス・ポリシ・リポジトリにより解釈して、ポリシ・リストとして定義内容をイニシャライザに渡し、イニシャライザではこの受け取ったポリシ・リストに基づいて、クライアントプログラムから所定のメソッド（図１０に例においては、ｉｎｉｔメソッドや、ｓｅｔＰｏｌｉｃｙメソッド）が呼び出されたタイミングにより、ＯＲＢやオブジェクト・リファレンスのポリシ定義を更新するようにし、サーバ側のオブジェクト実体に対してのリクエスト時に用いるポリシをクライアントプログラムに保持させることができるようにしたので（ポリシ定義外出し形式）、サーバ側のオブジェクト実体に対してのリクエスト時にクライアント側で用いる通信方式の詳細であるアクセス・ポリシの変更は、アクセス・ポリシ・リポジトリに与えるポリシ定義の定義内容変更のみで可能となる。
【０１７３】
従って、本実施例によれば、分散システムにおけるサーバ側のオブジェクト実体に対してのリクエスト時にクライアント側で用いる通信方式等の詳細を与えるための情報であるアクセス・ポリシについての変更の必要が生じた際には、当該ポリシ変更が極めて容易となるＣＯＲＢＡシステムが実現できることになる。加えて、本実施例によれば、オブジェクトの名前解決、すなわち、図１３の例で言えば名前’ＳＶＲ＿Ａ’に該当するオブジェクト・リファレンスを取得する動作に関しても、イニシャライザが代行して実施するため、クライアントＣＬＮ＿Ａプログラムにおいて記述すべきプログラム・コードを大幅に減少させることができる。
【０１７４】
また、プログラム開発者にとって、ＲＴ−ＣＯＲＢＡを活用したプログラミングを行うには、通常、それぞれのポリシの効果に関する深い理解が要求されるが、本発明においては、事後にポリシを変更可能としたことによって、ＲＴ−ＣＯＲＢＡを含まない以前のバージョンのＣＯＲＢＡに習得した作業者であれば、ＲＴ−ＣＯＲＢＡのレベルを熟知していなくとも、ＲＴ−ＣＯＲＢＡの機能を活用したシステムを構築することが可能となり、ＲＴ−ＣＯＲＢＡによるシステム構築参入への門戸を開放して開発者を確保し易くすると共に、ＲＴ−ＣＯＲＢＡによるシステム構築に必要とされる工数低減をも図ることができる効果も得られる。
【０１７５】
なお、上記説明はあくまでも一例であり、種々変形して実施可能である。
【０１７６】
また、本発明において、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得るものである。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題の少なくとも１つが解決でき、発明の効果の欄で述べられている効果の少なくとも１つが得られる場合には、この構成要件が削除された構成が発明として抽出され得る。また、詳細な説明にて説明した本発明は、コンピュータに読み込ませて実行させるプログラムとして頒布して、利用することも可能である。
【０１７７】
【発明の効果】
以上詳述したように、本発明によれば、分散システムにおけるサーバ側のオブジェクト実体に対してのリクエスト時にその授受に当たってのクライアント側で用いる通信や動作の条件等の詳細を与えるための情報であるアクセス・ポリシについての変更の必要が生じた際には、当該ポリシ変更が極めて容易となるＣＯＲＢＡシステムが実現できることになる。
【０１７８】
また、ＲＴ−ＣＯＲＢＡを活用したプログラミングを行うには、通常、それぞれのポリシの効果に関する深い理解が要求されるが、本発明においては、事後にポリシを変更可能としたことによって、ＲＴ−ＣＯＲＢＡを含まない以前のバージョンのＣＯＲＢＡに習得した作業者であれば、ＲＴ−ＣＯＲＢＡのレベルを熟知していなくとも、ＲＴ−ＣＯＲＢＡの機能を活用したシステムを構築することが可能となり、また、ＲＴ−ＣＯＲＢＡによるシステム構築にかかる工数を低減を図ることができる効果も得られる。
【図面の簡単な説明】
【図１】本発明を説明するための図である。
【図２】本発明を適用した場合と従来技術を適用した場合でのクライアント・プログラムで実施すべき処理内容の違いを比較して説明する図である。
【図３】従来方式における動作遷移例を示す図である。
【図４】図１に示す本発明システムでの一例としての動作遷移図である。
【図５】図１に示す本発明システムでのイニシャライザでの一例としての動作遷移図である。
【図６】本発明システムでの各クライアント機器でのリクエスト対象（アクセス対象）と各クライアント機器での利用ポリシの取得の例を説明する図である。
【図７】本発明システムで用いるアクセス・ポリシ・リポジトリの設定ファイル定義例を説明する図である。
【図８】本発明システムで用いるアクセス・ポリシ・リポジトリのインタフェース定義例（ＩＤＬ言語記述）を説明する図である。
【図９】本発明システムで用いるアクセス・ポリシ・リポジトリの動作例を示すフローチャートである。
【図１０】本発明システムで用いるイニシャライザを実現するための実装プログラムのうち、クライアント・プログラムから操作するＡＰＩ（アプリケーション・プログラム・インタフェース）を定義するソースプログラムファイル例（Ｃ＋＋言語記述）を説明する図である。
【図１１】図６に示す本発明システムにおける各クライアント機器でのリクエスト対象（アクセス対象）に対する各クライアント機器で要求される通信や動作の条件（ポリシ対応）の一設定例を説明する図である。
【図１２】本発明システムにおけるクライアント機器ＡでのＣＯＲＢＡクライアントプログラムの処理の動作遷移を、イニシャライザとアクセス・ポリシ・リポジトリとの関係を含めて説明するための図である（ネーミング・サービスを組み合わせない方式）。
【図１３】本発明システムにおけるクライアント機器ＡでのＣＯＲＢＡクライアントプログラムの処理の動作遷移を、イニシャライザとアクセス・ポリシ・リポジトリとネーミングサービスとの関係を含めて説明するための図である（ネーミング・サービスを組み合わせる方式）。
【図１４】従来技術を説明するための図である。
【符号の説明】
１１，１２，Ａ…サービス機器（サーバ側）
２１，２２，Ｂ…クライアント機器（クライアント側）
２００，２００Ａ，２００Ｂ…イニシャライザ（設定変更反映処理部）
３００…アクセス・ポリシ・リポジトリ（条件設定指示機能部）
Ｃ…ネーミング・サービス機能部。[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a distributed processing environment by a plurality of computer elements connected by a network, for example, a distributed object environment such as a distributed processing system in which CORBA is introduced, and in particular, to receive a request from a remote device connected by a network. Device and method for changing access policy of client system and client system in distributed processing system capable of easily changing access policy, which is a detail of communication and operation conditions for the remote device, in sending and receiving a request for a distributed object capable of transmitting and receiving the request About the program.
[0002]
[Prior art]
There is a system configured by using a large number of embedded devices (embedded devices), each of the embedded devices of the system is an independent intelligent system having a CPU (processor) at the center of control, and a system having a distributed environment. . Here, a distributed environment is a processing environment based on a distributed object-oriented technology, which is one of the main technologies for building network applications. This is a method in which various objects (basic modules that constitute a program in object-oriented programming) are distributed and arranged, and the processing is shared and proceeded based on the concept of grasping the relationship between "objects".
[0003]
Then, when there are a plurality of objects, a specification for defining an operation to be defined for each object in a predetermined interface language (IDL) is given, and rules for allowing the client to call the defined object in a predetermined procedure are defined. There is CORBA specification as decided.
[0004]
As is well known, CORBA is an abbreviation of “Common Object Request Broker Architecture”, which is one of the standard technologies in the distributed object-oriented technology, and is an OMG (Object Management Group) which is a standardization organization of the distributed object technology. It is a standard that has been formulated.
[0005]
CORBA is a standard specification for the purpose of developing an architecture for sharing and integrating distributed objects on a network without depending on individual hardware or OS. In the CORBA standard, version 2.4 (CORBA) is used. In 2.4), Real-time CORBA (RT-CORBA) is a standard that introduces the concept of processing priority especially for the real-time processing field and the embedded system field into distributed objects. added. The part of the standard specification relating to the processing priority is particularly called RT-CORBA 1.0. Therefore, the standards before CORBA 2.3 do not include the RT-CORBA specification.
[0006]
Further, since RT-CORBA 1.0 itself is an optional specification of CORBA, even a CORBA product corresponding to CORBA 2.4 or later does not always conform to the RT-CORBA specification. Accordingly, hereinafter, a description of “CORBA not including RT-CORBA” indicates both of the above.
[0007]
As a typical method of handling the priority in the RT-CORBA environment, there is a method of designating a desired priority at the stage of generating the object, and activating the object with the priority. In another method, when a client issues a request, there is a method in which a processing priority is transmitted to an object and the object is processed according to the priority. In either method, when a request for the object arrives from a remote client, a task having the previously specified priority is generated, and the request is processed on the task. If a large number of processing requests (requests) occur at the same time, the request with the highest priority is executed, but if the requests have the same priority, processing is performed according to predetermined task scheduling. Although the OS assigns priorities to these tasks and performs tasks such as task scheduling, the OSB actually implements them. The ORB described later bridges these processes.
[0008]
An object operating in the ORB environment of the CORBA specification is called a CORBA object. As a common use, a CORBA object provides one or more operations. Then, in order to call an operation prepared by the CORBA object, the operation may be called via the ORB.
[0009]
That is, a program that calls an operation using the ORB is a CORBA client. A CORBA client may or may not be a CORBA object at the same time.
[0010]
Further, in the field of CORBA, communication accompanying an operation call is particularly called a “request”. Hereinafter, "request" and "invocation of operation" are used interchangeably.
[0011]
It is necessary for an issuer of a request to know information about what kind of request an object can accept. Therefore, an IDL (Interface Definition Language) is used to clarify information on what kind of interface is provided.
[0012]
Thus, CORBA allows a heterogeneous distributed environment. The OS can be different.
[0013]
On the other hand, particularly when RT-CORBA is used, there is a problem of policy adjustment. This is a problem in which resource abilities such as CPU abilities, communication abilities, and network transmission speeds of the devices are closely involved. In other words, the devices are connected via a network, and each device has a difference in the capabilities and required functions as hardware and software, and there is a difference in the remaining capacity from the viewpoint of load, and the transmission status of the network fluctuates. Since various requirements overlap, as in, etc., there is a possibility that the operation of the entire system in an operational state may be out of balance or the desired performance may not be exhibited. Therefore, CORBA and RT-CORBA Defines dozens of types of policy objects. In the CORBA client program and server program, by adding a description for setting a predetermined policy value as a parameter to the policy object, the ORB of the ORB is defined. It can give principles to behavior and affect performance.
[0014]
By the way, especially from the standpoint of constructing a system using RT-CORBA, some of the values to be given to these policies cannot be determined at the system design stage, and the system construction is completed and operation starts. In many cases, it is clearly better to adjust policies (policies, principles, and measures) by trial and error.
[0015]
For example, when a connection is established from a client to a server and transmission is attempted between the two using this connection, a normal connection and a private connection are secured for the connection, and both the connection and the private connection are secured. The signal from the transmitter is transmitted using the private connection, the other signals are transmitted using the normal connection, and the signal from the special sensor is transmitted to other signals. The setting of giving priority by using a dedicated connection that is not used is made according to a given policy, and is managed and operated by the ORB described later, and is used like the set content. However, when I tried a test drive with the contents of this policy, In some cases, it was found that operation was possible without providing a private connection, and in this case, from the initial concept of "securing both private and normal connections", "only normal connections" Will be changed. This is an example in which, as a general rule, there is a principle that the more the performance is secured, the more the resource is consumed, and it is not possible to determine which is appropriate at the design and implementation stages.
[0016]
This is a policy change that became apparent for the first time as a result of trial operation and became necessary. Also, if it is necessary to add equipment or change functions in the operating system, this means that all signals will be transmitted using only normal connections until now. However, in some cases, a certain signal might be hindered. In this case, from the original concept of "normal connection only", "secure both private connection and normal connection" If you decide to change your policy, this is a policy change that will occur as a result of the system change.
[0017]
As described above, the policy setting method needs to be adjusted according to the actual operation status. This occurs when a client (a computer or software that requests a service from another computer or software on a network) attempts to connect to a server (a computer or software that provides a service). This is a problem concerning the setting of connection conditions and operating conditions that occur, but it is also a very troublesome problem.
[0018]
Here, we will focus on the issue of changing the policy, but before that, let's talk about requests for distributed objects.
[0019]
FIG. 14 is a diagram illustrating a conventional method of requesting a distributed object, and is a diagram illustrating an example of a request method between a device A and a device B. The device A is a component device on the server side, is a service device having a CORBA object X and an ORB (Object Request Broker: Object Request Broker), and the device B is a component device on the client side and has a CORBA client program. A client device having Y and ORB, C is a means for providing a CORBA naming service, and is held in another device or in either device A or device B. For example, it is assumed that the devices A and B have different development and manufacturing companies, and that the devices A and B are systems operating on different OSs. These are connected and operate on a network.
[0020]
In the device A, when generating and activating the CORBA object X, a reference to the object X (information that can uniquely indicate the object including necessary information such as connection conditions and operation conditions given to the distributed object) ). At that time, the naming service described above is often used.
[0021]
The device B makes an inquiry to the naming service function unit C and obtains a reference of the CORBA object X to be requested.
[0022]
In short, in developing a CORBA program, a unique name is used because it is convenient to determine a unique name from the beginning for each object necessary for realizing the function. This allows the object to be specified using its unique name, independent of which device the object runs on.
[0023]
Here, the CORBA client program Y on the client side (device A) that requests the object X of the device A executes an inquiry for an object reference using the naming service function unit C, and thereby the naming service function unit C And obtains information that can be specified in the CORBA world about the object named X in the device A returned from the device A, that is, an object reference, and issues a request to the CORBA object X using this.
[0024]
Inquiry of the object reference to the naming service, specifically, in design and maintenance, a character string of a name which is most convenient in design and maintenance is obtained from the naming service function unit C with a reference of the corresponding object as an argument. This means that the client program Y can make a request for the object X upon execution of the CORBA client program Y.
[0025]
In CORBA, as a method of passing an object reference to a client, there is a method that does not use a naming service. One of the methods is to convert an object reference into a character string format defined by CORBA and convert it into a character string format. There is also a method of delivering the file to the client by a separate network means. The present invention supports both the case where the naming service is used and the case where the naming service is not used.
[0026]
An ORB is provided for the devices A and B of the CORBA specification. The ORB is software that provides a basic service of CORBA and a mechanism for realizing exchange between objects in a distributed environment. This is middleware necessary for realizing mutual exchange between remote objects, and functions as an intermediary for seamlessly realizing requests and responses between objects.
[0027]
Follow the operation. First, the device A has a CORBA server program, and this CORBA server program generates an RT-POA (Rial-Time Portable Object Adapter). The RT-POA is for assigning a priority defined by the RT-CORBA and setting a policy (policy, principle, or measure), and the RT-POA is prepared in advance. In order to use RT-CORBA, it is specified that this RT-POA must be created first, so this is prepared first.
[0028]
It is assumed that the CORBA server program includes the CORBA object X, and that the CORBA object X comes into play. Then, the CORBA server program generates and activates the object X. Activation means that a certain POA is linked to a certain object, and it is possible to receive a request from the client for the object on the POA, that is, in accordance with the policy of the POA. In the case of CORBA, this means that the object X can be operated on the RT-POA. By this activation, the object X is given a necessary priority according to the RT-POA, and can be executed in accordance with the policy.
[0029]
Here, since the CORBA object X waits for a request from the client side, the processing on the server side is in a wait state.
[0030]
Since the CORBA object X must be accessed remotely, it is now necessary to externally publish (publish) an object reference that is public information for notifying that such an object is available.
[0031]
When generating and activating the CORBA object X, the CORBA server program publishes a reference to the object X (information that can uniquely indicate the object including information on the priority assigned to the distributed object) and names the object X・ Make the service available.
[0032]
The client side (the CORBA client program Y which is a CORBA program on the client side) inquires the object reference to the naming service function unit C in the form of a dictionary lookup and obtains the reference of the CORBA object X to be requested. .
[0033]
Now look at the stage where the client tries to connect to the server. First, in CORBA, the protocol uses IIOP (Internet Inter-Orb Protocol) as a default protocol, but other protocols can also be used. In RT-CORBA, the priority of a protocol to be used can be held as one policy. In this case, it is necessary to coordinate between the client and the server so as to communicate using a protocol that can be used in common. Therefore, the priority of the protocol to be used is stored as a protocol policy. Next, when the standard IIOP is used, since this is connection-type communication based on TCP, it is necessary to establish a connection between the ORB of both the server and the client.
[0034]
The connection is established. For example, when starting the procedure of establishing a connection from the device B as a client to the device A as a server, the CORBA client program Y of the device B uses the policy regarding connection conditions and operation conditions. Establish a connection so that it has the contents according to the settings. The condition at that time follows a policy (access policy) that is a detail of a request (request) transmission method and communication method set in advance, and the condition according to the policy is the CORBA client program Y of the device B. This is passed to the ORB and is used by the ORB as a condition to be followed when a request for a distributed object is made.
[0035]
[Problems to be solved by the invention]
At the stage when the client attempts to connect to the server, for example, when starting a request via the network from the client device B to the server device A, the CORBA client program Y of the client device B determines the connection conditions and operation conditions. Communication is performed so as to have the content according to the setting content. The condition at that time is in accordance with a preset access policy, but the condition in accordance with the policy has been conventionally embedded in the CORBA client program Y of the client device B. Then, this is passed from the CORBA client program Y to the ORB of the client device B, and is used in the ORB as a condition to be followed when a request for a distributed object is made.
[0036]
In the client device, when accessing the server by making a request or the like, (a) a timeout policy, (b) a client protocol policy, (c) a priority policy (priority model), (d) a connection, oneway And access policies such as synchronization scope.
[0037]
In addition, since the policy setting information on the client device side is required for each server accessed from the viewpoint of the user, in the present situation where each is embedded and defined in the CORBA client program Y, it is necessary to change any of them. Each time a problem occurs, the source program must be reworked.
[0038]
Since the CORBA client program Y of the device B uses a program in which the processing contents and the like are described as a source program and is compiled into an execution program, it takes a great deal of time to change the policy. On the other hand, requests for policy changes are endless.
[0039]
For example, when a request is transmitted from a client to a server, an attempt is made to issue a request from the client using a connection-type protocol (such as IIOP) and wait for a response from the server to the request. In this case, it is necessary to consider a timeout process. That is, it is necessary to set the time-out time, whether or not to execute the time-out, and the like. This setting can be made by describing it in the source program according to a predetermined policy. However, when this is tested and found to be inappropriate, it is necessary to change the value.
[0040]
In a network using CORBA, devices other than the above-described client and server are usually connected, and it is generally difficult to know in advance the operating status of the network.
[0041]
At the development site or adjustment site, the optimum value is found by trial and error while adjusting the value. Therefore, until the optimum value is found, each time the source program needs to be modified and recompiled. In addition, even if an optimum value is found and operated with that value, if the system is changed, such as the addition of equipment, the value may not be the optimum value, and the optimum value must be found again. The change of the source program accompanying the policy change is a problem that is often encountered not only before the operation of the system but also after the operation.
[0042]
As described above, in a system in which a large number of embedded devices are connected via a network and RT-CORBA is applied, when a CORBA client program requests a server (an object on the server side), a connection condition such as a connection condition that is scheduled in advance is required. The connection and operation according to the policy are performed by the ORB. However, between the client side and the server, since each client determines the contents of the policy finely for each server, if there is a change in the system configuration, etc., Policy change is required. In order to change the policy, it is necessary to change the source program in accordance with the policy change. In this case, in order to obtain an execution program in which the policy has been changed, it is necessary to modify the source program and compile the modified source program. Work is required, and changing policies takes time and effort.
[0043]
On the other hand, since policy change requests are incessant, rapid development of a mechanism that allows policy change to be performed more easily is expected.
[0044]
An object of the present invention is to provide a client system in a client system in a distributed processing environment using a network, a client system capable of easily changing a policy in the client, a policy changing method of the client system, and a client program capable of easily changing the policy.
[0045]
[Means for Solving the Problems]
To achieve the above object, the present invention is configured as follows. That is, a client device as a remote device that issues a request to a distributed object on a network and issues the request in accordance with communication or operation conditions according to a predetermined access policy.
Acquisition means for acquiring the access policy, which is the details of the communication or operation conditions in the remote device at the time of sending and receiving the request, from the means for enabling the content to be changed, and communication corresponding to the access policy obtained via the acquisition means Or means for reflecting the operation conditions on the client-side operation settings.
[0046]
Further, an acquisition unit for acquiring an access policy, which is a detail of communication or operation conditions in the remote device in the case of giving / receiving the request, from a unit for holding the contents in a modifiable manner, and an access policy acquired via the acquisition unit. Means for passing to a client software that issues a request to the distributed object as information that can be listed and referred to,
The client software is characterized in that the access policy passed as the referable information is fetched and reflected in the client-side operation setting so as to be a condition for the communication or operation.
[0047]
According to such a configuration, with respect to a distributed object capable of accepting a request from a remote device connected via a network, a client device having client software that issues a request affects the performance of the entire system. An access policy, which is a detail of communication and operation conditions in the remote device at the time of sending and receiving the request, is acquired from holding means (access policy repository) which can be rewritten and managed by the entire system, The access policy obtained via this acquisition means is passed to the client software and reflected in the client-side operation settings so as to be conditions for communication or operation corresponding to the access policy.
[0048]
In addition, an access policy which is a detail of communication and operation conditions in the remote device in transmitting and receiving the request related to the performance of the entire system is stored in a storage means (access policy. Repository), and the obtained access policy is listed and passed to the client software as information that can be referred to, and the client software uses the passed information to correspond to the access policy. The settings are reflected in the client-side operation settings so that they become communication and operation conditions. In other words, instead of a program format in which the access policy is embedded in the client software, the access policy is set to an external format in which the access policy placed outside is referred to and reflected in the operation settings on the client side. Content can be changed freely.
[0049]
Therefore, according to the present invention, it is necessary to change an access policy, which is information for giving details such as communication and operation conditions used on the client side at the time of a request for an object entity on the server side in a distributed system. When this occurs, if the contents of the relevant access policy of the means for holding the access policy so that the contents can be changed are changed, the policy will be reflected. Therefore, there is a distributed processing system that makes it extremely easy to change the policy. It can be realized.
[0050]
In addition, for a program developer, in order to perform programming utilizing RT-CORBA, a deep understanding of the effect of each policy is generally required. In the present invention, however, the fact that the policy can be changed afterwards makes it possible to change the policy. , Any worker who has learned to the previous version of CORBA that does not include RT-CORBA can construct a system utilizing the function of RT-CORBA without having to be familiar with the level of RT-CORBA, In addition to opening the door to entry into system construction by RT-CORBA, developers can be easily secured, and the effect of reducing man-hours required for system construction by RT-CORBA can be obtained.
[0051]
Further, the present invention has client software for issuing a request to a distributed object capable of accepting a request from a remote device connected via a network, and giving / receiving the issued request is performed by a predetermined access. A policy changing method of a client system for changing settings of the access policy in a client device as a remote device to be performed under communication or operation conditions according to a policy,
In order for the client software to externally receive and use an access policy that is a detail of communication or operation conditions in the remote device at the time of sending and receiving the request, the client software uses an externally received access policy.・ The policy is fetched, and the client side communication method is set so as to be the condition of communication and operation corresponding to this access policy,
The access policy is provided in a means for holding the contents so that the contents can be changed, and the access policy obtained from the holding means is passed to the client software so as to be a condition for communication or operation corresponding to the access policy. It is characterized in that it is reflected in the side operation setting.
[0052]
The present invention is directed to, for example, a distributed processing system to which CORBA is applied. In a distributed processing system connected by a network such as CORBA, a request is issued to a distributed object capable of receiving a request from a remote device. In order to make it easy to change the access policy of the client software that issues the request, the client software externally transmits an access policy that is a detail of the communication and operation conditions of the request to the remote device. To use it. For this purpose, the client software takes in an access policy received from the outside and sets a communication method on the client side.
The access policy is prepared in the means for holding the contents so that the contents can be changed, and the access policy obtained from the holding means is passed to the client software and reflected in the client-side operation settings.
[0053]
Specifically, the client software receives an external access policy that is a detail of communication and operation conditions with respect to the remote device in sending and receiving the request, and uses the access policy from outside.
The access policy is prepared in a means for holding the contents so that the contents can be changed, and the access policy obtained from the holding means is listed as referenceable information, and the client software becomes the referenceable information. The access policy is fetched and reflected in the client-side operation settings so as to be conditions for communication and operation corresponding to the access policy. In other words, instead of a program format in which the access policy is embedded in the client software, an external policy that refers to an external access policy and reflects it in the client-side operation settings is used, and the contents of the access policy can be freely changed Made it possible.
[0054]
Therefore, according to the present invention, when it is necessary to change an access policy which is information for giving details of a communication method and the like used on a client side when a request is made to an object entity on a server side in a distributed system. Thus, a policy change method for a client system in a CORBA distributed processing system in which the policy change becomes extremely easy can be realized.
[0055]
In addition, for a program developer, in order to perform programming utilizing RT-CORBA, a deep understanding of the effect of each policy is generally required. In the present invention, however, the fact that the policy can be changed afterwards makes it possible to change the policy. , Any worker who has learned to the previous version of CORBA that does not include RT-CORBA can construct a system utilizing the function of RT-CORBA without having to be familiar with the level of RT-CORBA, In addition to opening the door to entry into system construction by RT-CORBA, developers can be easily secured, and the effect of reducing man-hours required for system construction by RT-CORBA can be obtained.
[0056]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[0057]
The present invention provides a technology that enables a client to easily change a policy setting in a CORBA specification system in which a large number of embedded devices are connected in a network and operate in a distributed environment.
[0058]
Typical application examples suitable for applying the present technology include a system in which one or more real-time systems and an embed type system are connected via a network and controlled or monitored by another computer. In the above, when a request (request) is given from the client side to the server side and exchanged with the object on the client side, it is easy to change a policy (access policy) which is a detail of a transmission method and a communication method used between the two. Things.
[0059]
(Concept of the present invention)
Hereinafter, an embodiment of the present invention will be described with reference to the drawings. Prior to that, the concept of the present invention will be described first. FIG. 1 shows a conceptual configuration diagram of the system of the present invention. In the figure, A is a service device on the server side, and includes a CORBA object X and an ORB. B is a device on the client side, and includes a CORBA client program Ynew, an ORB, and an initializer 200. The naming service function unit C provides a naming service of CORBA, and 300 is an access policy repository function unit that provides a policy to the initializer 200. The service device A and the client device B are connected via a network (NW), and the naming service function unit C and the access policy repository function unit 300 are placed on independent computers and connected via the network (NW). Or may be incorporated in any of the devices A and B.
[0060]
In the present invention, in addition to the use of the conventional ORB (Object Request Broker) and the naming service in CORBA, an initializer (setting change reflection processing unit) 200 and an access policy repository (condition setting instruction function unit) ) 300 concepts were introduced.
[0061]
Here, ORB and naming service will be described as basic knowledge.
[0062]
An ORB (Object Request Broker), which is software for providing a basic CORBA service, is a software for providing a mechanism for realizing a communication method between objects in a distributed environment. Middleware that realizes mutual exchanges, and functions as an intermediary for seamlessly realizing requests and responses between objects. In general, when the term CORBA is used, it means the standard. On the other hand, when the term ORB is used, it is software that is middleware that implements the CORBA standard. In the description of the present invention, this is also followed.
[0063]
RT-CORBA is a standard formulated as an addition to the CORBA specification. The RT-CORBA standard largely defines the following two specifications.
[0064]
One is "management of processor resources" and the other is "control of communication between ORBs".
[0065]
“Management of processor resources” refers to provision of a priority model in distributed objects and implementation means thereof, provision of thread pool management means, and the like, and “control of communication between ORBs”. It refers to the establishment of a connection that avoids the inversion of the priority and the means for selecting a protocol.
[0066]
Further, the above-mentioned priority model refers to a model that determines how to give a priority and a management method on a distributed system. In RT-CORBA1.0, two models, a "server-declared model" and a "client-propagated model" are defined. This model can be selected by a predetermined procedure defined in RT-CORBA.
[0067]
The “server cleared model” is a model in which a server sets a specific priority for each object. This model is typically used for applications in which the priority once given is not changed, and is suitable for applications in which a fixed priority can be set for each CORBA object.
[0068]
The “client propagated model” is a model in which a CORBA client issues a request by designating a desired priority. The priority is embedded as a part of the request and is sent to the server. Passed. This model is suitable for applications that need to change the priority according to the contents of the request (argument value) and the context before issuing the request, and is more general-purpose than the server-cleared model. Model.
[0069]
As a characteristic of the CORBA specification, in addition to providing specifications for realizing a distributed object by the ORB, an object that realizes various functions often required by many applications as a CORBA object is included as a specification. Is raised. These are called CORBA services, and the CORBA service is used as one component of a distributed system construction, so that a distributed object system having advanced functions can be easily developed.
[0070]
The CORBA service is a set of services provided with an interface defined by IDL (Interface Definition Language) which is a language for describing an interface independent of an implementation language, and is a collection of CORBA objects connected to the ORB. Is available via the ORB.
[0071]
For example, the CORBA service includes a naming service (naming service) that provides a service for finding a component (object) connected by the ORB by a uniquely named name on the system, registration of an event between objects, An event service (Event Service) that provides a service for performing management, a transaction service (Transaction Service) that is a service for performing transaction control between objects, and the like are provided.
[0072]
The above-mentioned naming service is a service for managing CORBA distributed objects by a convenient name named by a system developer, and is an environment that enables searching by name between objects connected to the ORB. I will provide a.
[0073]
In the naming service, three pieces of information, that is, the name of an object, its type in the IDL language, and an object reference for uniquely specifying a distributed object are managed as one piece of information. An object reference is used as data for uniquely specifying a distributed object, and its contents are defined by the CORBA specification. The ORB is configured to access a particular distributed object by parsing the object reference.
[0074]
For the naming service, by using an operation called "bind", the one piece of information can be additionally registered. By an operation called "unbind", the one piece of information can be deleted. With the operation described above, the information of the object reference corresponding to can be acquired using the name as a key.
[0075]
A specific use form of the naming service will be described.
The service device A, which is a device on the server side, has a CORBA server program, and this server program first generates a POA. The POA is for assigning priorities defined by RT-CORBA and setting policies (policies, principles, and measures), and this POA is prepared in advance. When the CORBA object X is needed, the CORBA server program generates and activates the CORBA object X.
[0076]
Since the CORBA object X must be accessed remotely, it is now necessary to externally publish (publish) an object reference, which is public information for notifying that this object is available.
[0077]
When generating and activating the CORBA object X, the CORBA server program publishes a reference to the object X (information that can uniquely indicate the object including the priority information assigned to the distributed object). The naming service is used at that time.
[0078]
The client side (the CORBA client program Ynew, which is a CORBA program on the client side) inquires the object reference to the naming service in the form of a dictionary lookup and obtains the reference of the CORBA object X to be requested.
[0079]
In the development of the CORBA program, it is convenient to determine a unique name for each object necessary for realizing the function from the beginning. Therefore, it is used by assigning a name and managing it.
[0080]
According to this mechanism, the CORBA client program Ynew in the component device B on the client side that requests the object X of the device A executes an object reference inquiry using the naming service provided by the naming service function unit C, and Interprets this in accordance with the method defined in the CORBA specification, and makes a request to the CORBA object X using this.
[0081]
As described above, the naming service is provided as a place to be provided so that others can refer to and use the reference of each object. In the present system, the naming service function unit C provides such a naming service. Function is provided.
[0082]
In the present invention, in addition to the conventional use of the ORB and the naming service in CORBA, a new initializer (setting change reflection processing unit) 200 and an access policy repository are used as functions to be used on the client device B side. Although the concept of the (condition setting instruction function unit) 300 is introduced, the access policy repository (condition setting instruction function unit) 300 includes an access policy (policy, principle, policy, etc.) on the client side. (Hereinafter, simply referred to as a policy) for each client, and has a function of extracting a policy for the requested client and passing it to the client in response to a request from the client, and a policy for each client. Defines the specifications in the access policy / repository. It is can be freely changed to be input to the re-300.
[0083]
The initializer (setting change reflection processing unit) 200 is a function installed in the client, and is provided in the access policy repository 300 at a timing required by the CORBA client program Ynew of the client equipped with the initializer 200. A request to transfer the policy is issued, a policy sent from the access policy repository 300 is taken in response to the request, and a mechanism is provided for overwriting and updating the policy with respect to the client ORB and the object reference. It is software.
[0084]
B is a client device (device on the client side) on which the CORBA client program Ynew is mounted, and the client device B has an initializer 200 mounted thereon. The CORBA object X mounted on the service device (server-side device) A is requested (accessed) by the CORBA client program Ynew, operates, and returns a result to the CORBA client program Ynew. When the client Ynew makes a request to the CORBA object X, the access policy repository 300 sends conditions such as the type of protocol to be used there, the method of establishing a connection, and the priority of the request. The initializer sets this policy in the ORB on the client side, and returns the control to the CORBA client program Ynew after the setting is completed, so that the ORB of the client device B becomes a service device under the conditions according to the policy. (Server-side device) The CORBA object X on the A-side can be exchanged with the service-side device A via the ORB.
[0085]
When compared with the configuration described in FIG. 14 as a conventional example, the service device A corresponds to the conventional device A, and the client device B corresponds to the conventional device B. The CORBA client program Ynew installed in the client device B is basically the same as the CORBA client program Y in the device B. However, in the present invention, the client device provided from the access policy repository 300 by the initializer 200 in the present invention. In order to enable policy setting according to the information of the access policy for B, the policy-related portion is a variable hidden inside the initializer, and a value according to the policy information is passed to this variable. The difference is that the program operates according to the settings of the contents of this variable.
[0086]
In general, there are a plurality of client devices represented by the client device B and a plurality of device devices on the server side represented by the device A, and the system configuration is connected by a network (NW). A description will be given of a system configuration using only one client device B and the server side using only one device A.
[0087]
In this system having such a configuration, the setting contents of the access policy to be given to the CORBA client program Ynew of the device B as the client device are set in the access policy repository 300 in advance.
[0088]
The access policy indicates various conditions of communication and operation (setting conditions regarding policies, principles, measures, and the like) with respect to the remote device when a request or the like to a distributed object (here, a CORBA object) is transferred. Examples of the policy type to be set in (a) are: (a) timeout policy (presence or absence of execution of timeout, which is an allowable waiting time for a response from the other party to a request, and timeout time); (b) client protocol Policy (in CORBA, a desired protocol can be selected from various protocols, so selection designation of the protocol), (c) priority policy (priority model (priority assignment method and management method on distributed system) Model, server-cleared or client-defined (D) connection, one-way, synchronization scope (connection to be established and its operating conditions, etc.). Such policy setting information is provided for each client device and from the client device side. It is defined for each server accessed.
[0089]
The operation will be described with reference to FIG. In this system, when the client device B is activated, the CORBA client program Ynew initializes its own ORB, which is a procedure defined by CORBA (step S11 in FIG. 2A), and To set the initializer 200 (step S12 in FIG. 2A). The setting of the initializer 200 is a process of acquiring a reference (object reference) of a target server object using a naming service and causing the initializer 200 to hold the reference.
[0090]
Next, the CORBA client program Ynew issues a request for obtaining a reference (object reference) of the target server object to the initializer 200, and thereby obtains a reference (object reference) of the target server object from the initializer 200. At this time, the initializer 200 acquires a policy (group) to be adopted in the request for the server object from the access policy repository 300, and validates the policy with respect to the object reference according to the method defined in the CORBA specification. Is performed. In addition, the obtained object reference is returned to the CORBA client program Ynew as a return value (step S13 in FIG. 2A).
[0091]
Next, the CORBA client program Ynew obtains a target server object reference by performing downcasting, which is a procedure defined in CORBA, on the object reference acquired in step S13 (corba-specific steps; ( In step S14 in FIG. 2A, a distributed object is called for a server object, and this is repeated as necessary (step S15 in FIG. 2A). At the time of termination of the application, the ORB is shut down (step S16 in FIG. 2A), and the process ends.
[0092]
Although not shown in the figure, when calling a distributed object for a server object, the ORB on the client device accesses the server to be accessed with a policy according to a specified policy group, calls the distributed object, and operates it. .
[0093]
This is an outline of a series of steps leading to an access to the server side (the CORBA object in the device A) on the client device B based on the specified policy.
[0094]
For comparison, an operation example of the conventional technique shown in FIG. 14 without an initializer and an access policy repository will be described with reference to FIG. 2B.
[0095]
In the system having the conventional configuration shown in FIG. 14, the setting contents of the policy to be given to the CORBA client program Y of the device B as the client device are embedded in the CORBA client program Y in advance. (A) timeout policy, (b) client protocol policy, (c) priority policy (priority model), (d) connection setting, oneway, synchronization scope, etc. Are defined in the CORBA client program Y by embedding them for each server to be accessed.
[0096]
The operation will be described with reference to FIG. In this system, when the client device B is activated, the CORBA client program Y initializes the ORB, which is a procedure defined by CORBA (step S1 in FIG. 2B), and then executes the naming service. The reference of the target server object is acquired by using it (Step S2 in FIG. 2B), and the CORBA client program Y receives this (Step S3 in FIG. 2B).
[0097]
Next, the CORBA client program Y creates a policy list in which a policy for accessing the server is set from information of the policy embedded therein (step S4 in FIG. 2B), and stores the policy list in the server. The object is set (step S5 in FIG. 2B).
[0098]
Next, the CORBA client program Y acquires a reference of the target server object by downcasting (a CORBA-specific step; (step S6 in FIG. 2B)), and calls a distributed object for the server object (FIG. 2 (b) (step S7), the ORB is shut down (step S8 in FIG. 2 (b)), and the process ends.
[0099]
Although not shown in the figure, when the distributed object is called for the server object, the ORB accesses the access target server with a policy according to the policy list, calls the distributed object, and operates it.
[0100]
This is an outline of a series of steps leading to access to the server side (the CORBA object in the device A) on the client device B based on the designated policy in the conventional system.
[0101]
As can be seen from FIG. 2, comparing the method of the present invention with the prior art, the function has been moved to the initializer for setting and changing the policy. Therefore, the CORBA client program can omit the processing part relating to the policy specification. To that extent, the content of the processing required for the CORBA client program is reduced. Therefore, in the method of the present invention, the development of the CORBA client program is easier than before. Moreover, according to the method of the present invention, the policy information content for each client device and for each server to be accessed is described and stored in an access policy repository, and the necessary policy information content is fetched by an initializer provided in the client device. Variable structure type that is passed to the CORBA client program of the client device, it is possible to change the contents of the policy only by changing the description of the policy information. Therefore, the policy can be freely adjusted to respond to changes in the system. It will be possible to operate the system optimally without reworking the program.
[0102]
In order to clearly see the difference, the method of the present invention is compared with the prior art in more detail.
[0103]
In the conventional system, in the CORBA client program of the client device, as shown in FIG. 3, when the activation is started, the ORB is first initialized (P1 in FIG. 3). Then, it requests the ORB to acquire information for referencing the naming service (P2 in FIG. 3). At this time, it is assumed that the ORB has already obtained information for referencing the naming service from the naming service function unit C (P0 in FIG. 3). Since the ORB that has received the naming service reference acquisition request returns information for referencing the naming service to the CORBA client program, the CORBA client program that receives the naming service reference obtains a target object (target as a target) from the reference information. An inquiry is made to the naming service function unit C to obtain the reference of the object (P3, P4 in FIG. 3). Since the reference of the object is an identifier necessary for invoking the method of the object, a request to the target object can be made by obtaining this information.
[0104]
In response to the inquiry from the CORBA client program, the naming service function unit C finds the reference of the object corresponding to the request and returns it to the CORBA client program (P5 in FIG. 3). In response to this, the CORBA client program is ready to start the target object.
[0105]
Next, the CORBA client program generates a policy list, sets the required number of policies, and issues a policy generation request to the ORB (P6 to P8 in FIG. 3). In the ORB, a policy object, which is a program for generating a policy, is started, and processing for substituting one policy in the client program into a policy list is performed (P9, P10 in FIG. 3). This process is repeated by the CORBA client program for the set number, so that a necessary portion of the policy information described in the CORBA client program is substituted into the policy list.
[0106]
Next, the CORBA client program overwrites the policy list with a list registered as a policy applied to access (P11 in FIG. 3). Update the content.
[0107]
When the preparation is completed in this way, the server is accessible. For access to the server side, the CORBA client program makes a request to the ORB for a target object, and the ORB requests the entity of the object using the access policy and the fetched object reference. (P12 in FIG. 3). As a result, a request is made to the entity of the object by being managed and operated according to the contents in accordance with the policy, and the entity of the object functions (P13 in FIG. 3).
[0108]
All of the conventional methods described above are typical of the possible methods defined in the CORBA specification. On the other hand, in the method of the present invention, as shown in FIG. 4, in the CORBA client program of the client device, the ORB is first initialized when the activation is started (P21 in FIG. 4). Then, the CORBA client program starts the initializer 200 (P22 in FIG. 4). As a result, the initializer 200 returns information for referencing the naming service to the CORBA client program (P23 in FIG. 4).
[0109]
However, prior to this, it is assumed that the initializer 200 has acquired information for referencing the naming service from the ORB from the ORB. Naturally, it is assumed that the ORB has already obtained information for referencing the naming service from the naming service function unit C (P0 in FIG. 4).
[0110]
The CORBA client program that has received the information for referencing the naming service from the initializer 200 requests the initializer 200 to acquire the reference information of the target object (P24 in FIG. 4). In response to this, the initializer 200 requests the ORB to acquire information for referencing the naming service (P31 in FIG. 5).
[0111]
Since the ORB that has received the naming service reference acquisition request returns information for referencing the naming service to the initializer 200, the initializer 200 that has received the naming service reference obtains a target object (target object) from the reference information. The naming service function unit C is inquired to obtain the reference (P32, P33 in FIG. 5). Since the reference of the object is an identifier necessary for invoking the method of the object, a request to the target object can be made by obtaining this information.
[0112]
In response to the inquiry from the initializer 200, the naming service function unit C finds the reference of the object corresponding to the request and returns it to the initializer 200 (P34 in FIG. 5). Since the initializer 200 makes the CORBA client program ready for passing, the CORBA client program is ready to start a target object.
[0113]
Next, the initializer 200 requests the access policy repository 300 to acquire a policy list (ORB name, object name) (P35 in FIG. 5 and P35 in FIG. 4). Accordingly, the access policy repository 300 returns the relevant policy list (P36 in FIG. 5). This policy list is newly passed, and the setting originally held by the ORB of the client remains valid as it is. Therefore, in order to overwrite and update the default policy with the new policy list, the initializer 200 updates the policy (P37 in FIG. 5).
[0114]
Then, the initializer 200 passes to the client program a reference to the CORBA client program for the object whose policy has been updated by the update (P38 in FIG. 5 and P38 in FIG. 4).
[0115]
When the preparation is completed in this way, the server can be accessed according to the target communication conditions with the server. The access to the server side is performed by making a target request for the target object to the ORB by the CORBA client program making a call to the object reference (P39 in FIG. 4). A request is made to the entity of the object under the communication conditions in accordance with a target policy by using the fetched object reference. As a result, the object is managed and operated with the contents according to the policy, a request is made to the entity of the object, and the entity of the object functions (P40 in FIG. 4).
[0116]
The above is the outline of the operation of the present invention.
[0117]
(Concrete example)
Next, a specific example will be described. FIG. 6 is a block diagram of the summary system of the present invention as an example. In the figure, reference numerals 11 and 12 denote servers. The server 11 is an intelligent service device such as a measuring device provided with a server program "SVR_A" which is a CORBA object and an ORB which is middleware of CORBA specification. The server 12 is a CORBA object. It is an intelligent service device such as a measuring device provided with an object server program “SVR_B” and a CORBA specification middleware ORB.
[0118]
Reference numerals 21 and 22 denote client devices. The client device 21 can use a client program “CLN_A” and an ORB (ORB name “CLN_A”) that is middleware of the CORBA specification (ORB name can be determined and used in CORBA). )) And a service device provided with a client program “CLN_A” as a CORBA object and an initializer 200A, and the ORB can be specified with a name “ORB_A”.
[0119]
The client device 22 is a service device including a client program “CLN_B”, an ORB (ORB having an ORB name “CLN_B”) that is middleware of the CORBA specification, a client program “CLN_B” as a CORBA object, and an initializer 200B. Is specified by giving a name “ORB_B”.
[0120]
The initializers 200A and 200B give a policy to be set by the client programs “CLN_A” and “CLN_B” to the ORB (“ORB_A”, “ORB_B”) mounted on the own device based on the definition information from the access policy repository 300. And has a function of giving to the client programs “CLN_A” and “CLN_B” at the initial stage of system startup.
[0121]
Reference numeral 300 denotes an access policy repository as described above, and a policy to be given to the CORBA client programs “CLN_A” and “CLN_B” of the client devices 21 and 22 (here, a policy determined on the client side and used on the client side) Is given. The setting contents of the policy to be given to the CORBA client programs “CLN_A” and “CLN_B” are set in the access policy repository 300 in advance, and the repository definition file 310 determines this. The policies to be set include (a) a timeout policy (whether or not a timeout, which is a permissible waiting time for a response from a request, to a request, and a timeout period), and (b) a client protocol policy (a desired protocol). ), (C) Priority policy (designation of priority model (model that determines how to give priority and management method on distributed system)), (d) Connection, Oneway, synchronization scope Are set by the client side and are used on the client side. The setting information of such a policy is provided separately for each client device and from the client device side. It is defined for each server accessed.
[0122]
In the example of FIG. 6, the client device 21 is a system that operates on both the service device 11 and the service device 12, and the client device 22 operates on the service device 12 only. FIG. 7 shows an example of the repository definition file 310 in the case of this system configuration.
[0123]
The repository definition file 310 is a file for setting the access policy repository 300. In the example shown in FIG. 7, an example of a file described in XML is shown. XML (extensible markup language; a markup language for describing information having a structure; markup language; a language for adding information such as the structure, design, and layout of a document to a text file using specific symbols) Since the user can create and use a unique tag, the meaning of the data to be displayed can be described as information. Based on this, data in the Web page can be searched, There is a feature that data can be reused, such as extracting the data and saving it in another format.
[0124]
Of course, the repository definition file 31 is not limited to the XML language description, but may be a simple text file or another language, as long as the definition content can be described.
[0125]
The client devices 21 and 22 and the service devices 11 and 12 are connected by a network NW. The client device 21 operates with both the service device 11 and the service device 12 as a partner, and the client device 22 operates with only the service device 12 as a partner. The file contents in FIG. 7 which is an example of a file in XML for the configuration example in FIG.
[0126]
First, “<? Xml version =...>” On the first line is a description part based on the XML standard and is irrelevant to the contents of the present invention. “<! −−−−−−−−>” in the second to sixth lines are commentary sentences (comments). From the seventh line to the last line, the definition part of the access policy repository is a tag starting with “<CORBA_ACCESS_POLICY_REPOSITORY>”, and a tag ending with “</ CORBA_ACCESS_POLICY_REPOSITORY>”.
[0127]
The contents of the real-time ORB named “CLN_A” are described from “<RTORB name =“ CLN_A ”” to “</ RTORB>” on the 18th line.
[0128]
From the 19th line “<RTORB name =“ CLN_B ”” to the 23rd line “</ RTORB>” are the contents of the real-time ORB named “CLN_B”.
[0129]
The contents of the real-time ORB named “CLN_A” include the priority (priority value “10000”) and the timeout policy (“1,000”) of the server object named “SVR_A” which is one of the CORBA objects. , 000,0 ”) and a connection is established as a private connection, which is a transmission path opened to be dedicated to communication with“ SVR_A ”. The priority of a server object named“ SVR_B ”is (Priority value “5000”), it is determined that in a request that does not require a reply, that is, in an one-way request, the request is executed in the SYNC_WITH_TRANSPORT method defined by the CORBA specification. The contents of B are contents say their priorities and (priority value "0") Timeout policy ( "3,000,000,0") is defined, and. An XML tag defined using the same class name as the class of the interface of the policy defined by CORBA, such as the priority policy class name and value for the priority policy, and the timeout policy class name and value for the timeout policy, etc. It is an example.
[0130]
That is, in this example, in the client program “CLN_A”, when accessing or exchanging the server object named “SVR_A”, the priority (priority of the priority value “10000”) and the timeout time Is set to 1000 [ms] (timeout policy (“1,000,000, 0”)), the others are executed without specification, and the server object named “SVR_B” is accessed or exchanged. In this case, the priority (priority value “5000”) and others are not specified, that is, they are implemented as they are without updating the policy that the ORB has by default.
[0131]
In the client program “CLN_B”, the priority is “0” at the time of its operation, and the timeout time is 300 [ms] (timeout policy “3,000,000, 0”). Is specified, that is, the policy is executed without updating the policy that the ORB has by default. In this example, the operating conditions need to be different for each client or for each other. However, when the operating conditions need to be different for each client, the conditions must be different. In a system where some changes, such as changes in the system contents, changes in the system contents, and adjustment stages, etc. affect the overall balance, it is often necessary to set the policy contents by trial and error. The access policy repository definition information may be defined and provided in XML, text, or the like, so that it is easy to change.
[0132]
The access policy repository 300 has a function of reading the definition information content in response to a request from the initializers 200A and 200B, and passing the definition content by masticing so that the initializers 200A and 200B can understand. Is realized by an interface program as shown in FIG.
[0133]
FIG. 8 is an example of the interface definition of the access policy repository 300 in the IDL language. The operation is performed by reading the setting file and reading the ORB default for each client and each access destination object as shown in the flowchart of FIG. The policy definition is acquired (the repository definition file 310 is read, the ORB default for each client and the policy definition for each access destination object are acquired; step S31 in FIG. 9), and each client waits for a request from the initializers 200A and 200B (FIG. Nine steps S32).
[0134]
If a request is issued from the initializer 200A or 200B, it is checked in steps S33, S34 and S35 whether or not the request is a policy acquisition request, and if so, what kind of policy acquisition request is. That is, if a request is issued, it is checked whether or not the request is "getPolicyForOrb" (step S33).
[0135]
As a result, if the request is “getPolicyForOrb” which is an ORB policy acquisition request, a policy list for the corresponding ORB for the initializer 200 that issued the request is returned (step S36). After returning the ORB policy list required for the requested client device, the process returns to step S32.
[0136]
In step S33 of FIG. 9, if the issued request from the initializer 200 is not "getPolicyForOrb", it is checked whether or not the policy acquisition request is "getPolicyForObject" (step S34).
[0137]
As a result, if the request is "getPolicyForObject", the request comes in the form of wanting a policy for accessing the server of this server object name on the ORB of this ORB name, so the request is issued. The policy list corresponding to the ORB name and the object name is taken out to the initializer 200, and the policy list is returned (step S37). When the policy list necessary for the requested client device is returned, the process returns to step S32.
[0138]
If it is determined in step S34 of FIG. 9 that the request is not “getPolicyForObject”, it is checked whether “shutDown” has been received (step S35 in FIG. 9). If “shutDown” has not been received, the process proceeds to step S32. Returning to S32 and subsequent steps, the process ends if "shutDown" is received in step S35.
[0139]
The processing contents by the program in FIG. 8 are as described above. As a result, the access policy repository 300 becomes a system that can transfer a necessary policy list in accordance with a request from the initializer 200A or 200B.
[0140]
FIG. 10 shows an example of a source program of a portion that defines an API (Application Program Interface) of the initializer 200 in the C ++ language. The method names defined in FIG. 10 correspond to the method names when the initializer is called from the client program in FIGS. 12 and 13 to be described later as examples. Specifically, it corresponds to P53 and P59 in FIG. 12 and P73 and P77 in FIG.
[0141]
As a result, as shown in FIG. 11, the client device 21 has a request priority of “10000”, a timeout of 1000 [ms], and a “ORB_A” with the content of a private connection for the service device 11 on the server side. It operates, the request priority for the service device 12 is “5000”, the request is “oneway request according to the SYNC_WITH_TRANSPORT method defined by the CORBA specification”, the timeout is 100 [ms], and the connection is a connection by a private connection. “ORB_A” operates, and the client device 22 can connect to the service device 12 on the server side only, the request priority is “0”, and the timeout is 3000 [ms], and “ORB_B” operates. In form It will be constant.
[0142]
The behavior of the CORBA client program “CLN_A” will be described for a case where the naming service is not used and a case where the naming service is used.
[0143]
FIG. 12 shows the behavior when the naming service is not used.
[0144]
In the method of the present invention, as shown in FIG. 12, in the CORBA client program of the client device, first, when starting up, the ORB is initialized (P51 in FIG. 12). Then, the CORBA client program generates and starts the initializer 200A and instructs initialization (P52, P53 in FIG. 12).
[0145]
In the initialization, the initializer 200A requests the access policy repository 300 for a request (query) for acquiring the required ORB policy in “CLN_A” (P54 in FIG. 12). In response to this, the access policy repository 300 searches for or extracts the relevant ORB policy registered in advance by some algorithm and returns it to the initializer 200A as a policy list in accordance with the operation steps shown in FIG. 9 (see FIG. 12). P55).
[0146]
In accordance with the policy list received from the access policy repository, the initializer 200A performs a predetermined procedure defined by the CORBA specification on the ORB to validate the policy. In this operation example of the embodiment, since the returned policy list is null (the list length is 0), it is assumed that the operation of updating the policy from the initializer to the ORB is not performed. Thereafter, the process returns to the CORBA client program “CLN_A” (P56 in FIG. 12).
[0147]
Next, the CORBA client program “CLN_A” issues a reference acquisition request for a target object (here, the server-side objects to be accessed are “SVR_A” and “SVR_B”) (P57 in FIG. 12).
[0148]
Assuming that a reference acquisition of “SVR_A” is requested first and then a reference acquisition of “SVR_B” is requested, a request to acquire reference of “SVR_A” is made in P57. Here, since the configuration does not use the name service, the object reference is obtained by means other than the name service. Although the means will be described later, there are several methods frequently implemented in the construction of the CORBA system, and the acquisition is performed by using any of these methods. That is, the acquisition method is open to the client CLN_A program.
[0149]
As a specific example of obtaining the reference of “SVR_A”, a method using a permanent IOR (Interoperable Object Reference) that guarantees that the content is always a constant value, or a predetermined character string format defined in the CORBA specification is written. There is a method of transferring files, and any method that is possible according to the CORBA specifications can be used.
[0150]
As another form of the present embodiment, it is also possible to adopt a configuration in which this reference search function is incorporated in the access policy repository 300. That is, the configuration is such that the access policy repository substitutes for the function of the naming service. In this case, the access policy repository 300 that has received the request extracts the reference of “SVR_A” and returns it to the CORBA client program “CLN_A” (P58 in FIG. 12).
[0151]
As described above, when the policy for “ORB_A” necessary for “CLN_A” and the reference of “SVR_A” are completed by any means, the CORBA client program “CLN_A” accesses the initializer 200A for “SVR_A” ( A request for setting (setting) a policy used in the request) is issued (P59 in FIG. 12).
[0152]
In response to this, the initializer 200A makes a request for obtaining (inquiring) a policy for “SVR_A” in “ORB_A” to the access policy repository 300 (P60 in FIG. 12). The access policy repository 300 that has received the request searches and extracts a policy for “SVR_A” in “ORB_A” in accordance with the processing procedure of FIG. 9 and returns a policy list corresponding to the initializer 200A (FIG. 12). P61).
[0153]
In the case of this example, three policies of priority “10000”, timeout “1000 [ms]”, and use of the “private connection” function are extracted and returned to the initializer 200A.
[0154]
The initializer 200A sets the three policies as a reference for the object "SVR_A" as a condition for connecting to the server-side object "SVR_A" (P62 in FIG. 12). This set can be implemented by a set_policy_overrides operation on an object reference as defined in the CORBA specification. According to this set, another reference for the object “SVR_A” is newly returned for the default reference for the object “SVR_A” (P63 in FIG. 12), so that the reference for the newly created object “SVR_A” is obtained. Is returned to the program of the client CLN_A (P64 in FIG. 12).
[0155]
As a result, in the program of the client CLN_A, a request for the server object SVR_A is enabled according to the target communication setting. Subsequent access procedures and methods may be performed according to a desired procedure of the client CLN_A program. Through a similar procedure, a reference for the object “SVR_B” is also obtained and created.
[0156]
When the reference for the object “SVR_A” and the reference for the object “SVR_B” are created in this way, the CORBA client program “CLN_A” can access the object “SVR_A” and the object “SVR_B” according to the new policy. Become. For example, to access the object "SVR_A", the CORBA client program "CLN_A" issues a target remote request to the object "SVR_A" (P65 in FIG. 12).
[0157]
At this time, the CORBA client program “CLN_A” applies the policy for “SVR_A” in “ORB_A” to “ORB_A” which is the ORB of the client device 21 based on the reference for the object “SVR_A”. According to this policy based on the CORBA specification, “ORB_A” makes a request to the entity of “SVR_A” (P66 in FIG. 12).
[0158]
Based on the above configuration, if you want to change the communication operation policy for comprehensive performance reasons or for the convenience of operation of individual client programs, rewrite the policy change by rewriting the policy definition (repository definition file 310, the new policy definition is interpreted by the access policy repository, and the definition contents are passed to the initializer as a policy list, and the initializer sends a predetermined policy from the client program based on the received policy list. (In the example in FIG. 10, the init method and the setPolicy method) are called, and the policy definition of the ORB and the object reference is updated, and is used when a request is made to the server-side object entity. Po Since the client program can be stored in the client program (policy definition outside format), the change of the access policy, which is the details of the communication method used on the client side when requesting the server-side object entity, It is possible only by changing the definition of the policy definition given to the access policy repository.The changed policy definition is interpreted by the access policy repository and passed to the initializer, and the initializer changes the client program in the form of a reference change. To the ORB and reflect it on the ORB, so that the ORB can access the server-side object entity of the request destination under the conditions according to this policy.
[0159]
Therefore, when a policy needs to be changed, it can be reflected only by rewriting the policy definition (rewriting the repository definition file). This eliminates the need to rewrite the client program, and eliminates the need for complicated work such as rewriting the source program and compiling the source program after the rewriting, thereby realizing a CORBA system in which policy change is extremely easy.
[0160]
The above is an example where the naming service is not used, but the behavior of the CORBA client program “CLN_A” when the naming service is used will be described below.
[0161]
FIG. 13 shows the behavior when the naming service is used.
In the method of the present invention, as shown in FIG. 13, in the CORBA client program of the client device, the ORB is first initialized when the activation is started (P71 in FIG. 13). Then, the CORBA client program generates and starts the initializer 200A and instructs initialization (P72, P73 in FIG. 13). At this time, the point that the object reference to the naming service is passed to the initializer as an argument is different from the case where the naming service is not used.
[0162]
In the initialization, the initializer 200A requests the access policy repository 300 for a request (query) for acquiring the required ORB policy in “CLN_A” (P74 in FIG. 13). In response to this, the access policy repository 300 retrieves the pertinent ORB policy registered in advance according to the operation steps shown in FIG. 9 or extracts it by some algorithm, and returns it to the initializer 200A as a policy list (FIG. 13). P75).
[0163]
In accordance with the policy list received from the access policy repository, the initializer 200A performs a predetermined procedure defined by the CORBA specification on the ORB to validate the policy. In this operation example of the embodiment, since the returned policy list is null (the list length is 0), it is assumed that the operation of updating the policy from the initializer to the ORB is not performed. Thereafter, the process returns to the CORBA client program "CLN_A" (P76 in FIG. 13).
[0164]
Next, the CORBA client program “CLN_A” issues a request to acquire a reference to a target object (here, the objects on the server side to be accessed are “SVR_A” and “SVR_B”) to the initializer 200A (FIG. 13). P77). Assuming that the reference acquisition of "SVR_A" is requested first, and then the reference acquisition of "SVR_B" is requested, the initializer 200A that has received the request requests the naming service C to acquire the reference "SVR_A" at P78. .
[0165]
In the naming service that has received the request, the reference of “SVR_A” is extracted and returned to the initializer 200A as a reference (part 1) for the object “SVR_A” (P79 in FIG. 13). The initializer 200A temporarily captures this, and when the acquisition of the policy for “ORB_A” necessary for “CLN_A” and the reference of “SVR_A” is completed, the initializer 200A sends the access policy repository 300 a request for “SVR_A” ( An acquisition request (inquiry) for a policy for access is issued (P80 in FIG. 13).
[0166]
The access policy repository 300 that has received the request (inquiry) searches and extracts a policy for “SVR_A” in “ORB_A” according to the processing procedure of FIG. 9 and returns a policy list corresponding to the initializer 200A. (P80 in FIG. 13).
[0167]
In the case of this example, three policies of priority "10000", timeout "1000 [ms]", and use of the "private connection" function are extracted and returned to the initializer 200A as a policy list. The initializer 200A sets these three policies in the reference for the object "SVR_A" (No. 1) as communication conditions when connecting to the server-side object "SVR_A". This set can be implemented by a set_policy_overrides operation on an object reference as defined in the CORBA specification.
[0168]
As a result, a reference (No. 2) for the object “SVR_A” for which the new policy setting has become effective is obtained in the initializer, and this is returned to the CORBA client program “CLN_A” (P82 in FIG. 13). By receiving this as a return value, the CORBA client program “CLN_A” obtains a reference for the object “SVR_A” in which the above three policies are embedded.
[0169]
Through a similar procedure, a reference for the object “SVR_B” whose policy has been updated is also obtained and created, and this is returned to the CORBA client program “CLN_A” (P82 in FIG. 13). The CORBA client program “CLN_A” obtains the reference and obtains a reference for the object “SVR_B” in which the policy is embedded.
[0170]
When the acquisition of the policies for “ORB_A” necessary for “CLN_A” and the references of “SVR_A” and “SVR_B” is completed, the CORBA client program “CLN_A” executes the object “SVR_A” or the object “SVR_B”. Can be accessed according to the new policy. For example, to access the object “SVR_A”, the CORBA client program “CLN_A” issues a target remote request to the object “SVR_A” (P83 in FIG. 13). At this time, the CORBA client program “CLN_A” applies the policy for “SVR_A” in “ORB_A” to “ORB_A” which is the ORB of the client device 21 based on the reference for the object “SVR_A”. According to this policy based on the CORBA specification, “ORB_A” makes a request to the entity of “SVR_A” (P84 in FIG. 13).
[0171]
However, prior to this, it is assumed that a reference to the naming service has been obtained in advance (P0 in FIG. 13).
[0172]
Based on the above configuration, if you want to change the communication operation policy for comprehensive performance reasons or for the convenience of operation of individual client programs, rewrite the policy change by rewriting the policy definition (repository definition file 310, the new policy definition is interpreted by the access policy repository, and the definition contents are passed to the initializer as a policy list, and the initializer sends a predetermined policy from the client program based on the received policy list. (In the example in FIG. 10, the init method and the setPolicy method) are called, and the policy definition of the ORB and the object reference is updated, and is used when a request is made to the server-side object entity. Po Since the client program can be stored in the client program (policy definition outside format), the change of the access policy, which is the details of the communication method used on the client side when requesting the server-side object entity, It is possible only by changing the definition contents of the policy definition given to the access policy repository.
[0173]
Therefore, according to the present embodiment, it is necessary to change the access policy which is information for giving details such as the communication method used on the client side at the time of a request for the object entity on the server side in the distributed system. In this case, it is possible to realize a CORBA system in which the policy change becomes extremely easy. In addition, according to this embodiment, the initializer also performs the object name resolution, that is, the operation of acquiring the object reference corresponding to the name 'SVR_A' in the example of FIG. The program code to be described in the client CLN_A program can be greatly reduced.
[0174]
In addition, for a program developer, in order to perform programming utilizing RT-CORBA, a deep understanding of the effect of each policy is generally required. In the present invention, however, the fact that the policy can be changed afterwards makes it possible to change the policy. , Any worker who has learned to the previous version of CORBA that does not include RT-CORBA can construct a system utilizing the function of RT-CORBA without having to be familiar with the level of RT-CORBA, In addition to opening the door to entry into system construction by RT-CORBA, developers can be easily secured, and the effect of reducing man-hours required for system construction by RT-CORBA can be obtained.
[0175]
The above description is merely an example, and various modifications can be made.
[0176]
Further, in the present invention, the above embodiments include inventions at various stages, and various inventions can be extracted by appropriately combining a plurality of disclosed constituent elements. For example, even if some components are deleted from all the components shown in the embodiment, at least one of the problems described in the column of the problem to be solved by the invention can be solved, and the problem described in the column of the effect of the invention can be solved. If at least one of the effects described above can be obtained, a configuration from which this configuration requirement is deleted can be extracted as an invention. Further, the present invention described in the detailed description can be distributed and used as a program to be read and executed by a computer.
[0177]
【The invention's effect】
As described in detail above, according to the present invention, at the time of a request for an object entity on the server side in a distributed system, this is information for giving details such as communication and operation conditions used on the client side in giving and receiving the request. When it becomes necessary to change the access policy, a CORBA system in which the policy change becomes extremely easy can be realized.
[0178]
Also, in order to perform programming utilizing RT-CORBA, a deep understanding of the effect of each policy is usually required. In the present invention, however, the fact that the policy can be changed afterwards makes RT-CORBA Any worker who has learned the previous version of CORBA that does not include it can construct a system utilizing the function of RT-CORBA without having to be familiar with the level of RT-CORBA. Also, the effect that the man-hour required for the system construction by the method can be reduced can be obtained.
[Brief description of the drawings]
FIG. 1 is a diagram for explaining the present invention.
FIG. 2 is a diagram for comparing and explaining differences in processing contents to be executed by a client program when the present invention is applied and when a conventional technique is applied.
FIG. 3 is a diagram showing an example of an operation transition in a conventional method.
FIG. 4 is an operation transition diagram as an example in the system of the present invention shown in FIG. 1;
FIG. 5 is an operation transition diagram as an example in an initializer in the system of the present invention shown in FIG. 1;
FIG. 6 is a diagram illustrating an example of a request target (access target) at each client device and an acquisition of a usage policy at each client device in the system of the present invention.
FIG. 7 is a view for explaining an example of a setting file definition of an access policy repository used in the system of the present invention.
FIG. 8 is a diagram illustrating an example of an interface definition (IDL language description) of an access policy repository used in the system of the present invention.
FIG. 9 is a flowchart showing an operation example of an access policy repository used in the system of the present invention.
FIG. 10 is a view for explaining an example (C ++ language description) of a source program file defining an API (application program interface) operated from a client program among implementation programs for realizing an initializer used in the system of the present invention; It is.
11 is a diagram illustrating a setting example of communication and operation conditions (corresponding to policies) required by each client device with respect to a request target (access target) in each client device in the system of the present invention shown in FIG. 6; .
FIG. 12 is a diagram for explaining the operation transition of the processing of the CORBA client program in the client device A in the system of the present invention, including the relationship between the initializer and the access policy repository (the naming service is not combined) method).
FIG. 13 is a diagram for explaining the operation transition of the processing of the CORBA client program in the client device A in the system of the present invention, including the relationship among the initializer, the access policy repository, and the naming service (naming service) Combination method).
FIG. 14 is a diagram for explaining a conventional technique.
[Explanation of symbols]
11, 12, A: Service equipment (server side)
21, 22, B: Client device (client side)
200, 200A, 200B ... Initializer (setting change reflection processing unit)
300 access policy repository (condition setting instruction function section)
C: Naming service function unit.

Claims

A client device as a remote device that issues a request to a distributed object on a network and issues the request according to communication or operation conditions according to a given access policy.
Acquisition means for acquiring from the means for holding an access policy, which is a detail of communication or operation conditions in the remote device at the time of the request transfer, so that the content can be changed,
Means for reflecting on the client-side operation settings so as to be the condition of the communication or operation corresponding to the access policy obtained through this acquisition means,
A client device in a distributed processing system, comprising:

It has client software that issues requests for distributed objects that can accept requests from remote devices connected via a network, and gives and receives requests in accordance with a given access policy. In the client device as a remote device to be performed under the conditions of communication or operation,
Acquisition means for acquiring from the means for holding an access policy, which is a detail of communication or operation conditions in the remote device at the time of the request transfer, so that the content can be changed,
Means for listing the access policy obtained via the acquisition means and passing the access policy to the client software as information that can be referred to,
The client software is configured to take in an access policy passed as the referable information and reflect the access policy in a client-side operation setting so as to be a condition of communication or operation corresponding to the access policy. Client device in a distributed processing system.

The access policy that can be changed includes the priority of the request issued by the client, the protocol used by the request, the timeout period for setting the limit of waiting for a response to the server, and the retry when no response to the request is found. 3. The client device in the distributed processing system according to claim 1, wherein at least one of the number of times is included.

A request is issued to a distributed object on a network, and the issuance is performed under conditions of communication or operation in accordance with a predetermined access policy, and the access policy is set in the client device as a remote device. A policy change method of a client system for changing,
The client device receives an externally received access policy in order to externally receive and use an access policy which is a detail of communication or operation conditions in the remote device at the time of issuing the request. Set the client side communication method to be the condition of the operation,
The access policy is prepared in a means for holding the contents so that the contents can be changed, and an access policy obtained from the holding means is passed to the client device so that a client-side operation is performed so as to be a condition for communication or operation corresponding to the access policy. A policy change method for a client system in a distributed processing system, wherein the policy is reflected in a setting.

It has client software that issues requests for distributed objects that can accept requests from remote devices connected via a network, and sends and receives the issued requests in accordance with a given access policy. Or a policy change method of a client system for changing the setting of the access policy in a client device as a remote device to be performed under operation conditions,
The client software receives from outside the access policy which is the details of the condition of the communication or operation with respect to the remote device at the time of sending and receiving the request, and uses the access policy.
The access policy is prepared in a means for holding the contents so that the contents can be changed, and the access policy obtained from the holding means is listed as information that can be referred to, and the client software has the information that can be referred to. A method for changing a policy of a client system in a distributed processing system, characterized in that the access policy is taken in and reflected in a client-side operation setting so as to be a condition of communication or operation corresponding to the access policy.

The access policy that can be changed includes the priority of the request issued by the client, the protocol used by the request, the timeout period for setting the limit of waiting for a response to the server, and the retry when no response to the request is found. 6. The policy changing method for a client system in a distributed processing system according to claim 4, wherein at least one of the number of times is included.

A program for changing an access policy for client software that issues a request for a distributed object capable of accepting a request from a remote device connected via a network,
Means for holding an access policy, which is a detail of communication or operation conditions of the request to the remote device, so that the content can be changed,
Means for passing the access policy obtained from the holding means to the client software and reflecting the access policy in a client-side operation setting so as to be a condition for communication or operation corresponding to the access policy.