(57)【特許請求の範囲】
【請求項１】
ネットワークによって接続された複数のノードを備え、前記ネットワークを介して各ノード間で仲介エージェントを移動させ、各ノードで仲介エージェントを動作させることにより情報処理を分散して行う情報処理装置において、
前記複数のノードは、当該ノード上における情報処理の実行手段である構成要素と、前記各構成要素をその固有の処理手順に従って動作させるためのアクセス部及び前記各ノード間をネットワークを介して移動する仲介エージェントとの通信機能を果たす通信部を有するエージェントラッパーとを備え、
前記各ノードに配置された各構成要素は、各構成要素間で行われる相互作用プロセスを構成要素間で行われるメッセージ交換のルールで表現し、かつ前記仲介エージェントが保持する一元化したインタラクションプロトコルに基づいて、その相互作用プロセスを実行するものであり、かつ、各構成要素に固有のローカルな処理を記述したインタラクションプロトコルについては、前記エージェントラッパーのアクセス部に記述され、
前記仲介エージェントは、前記一元化したインタラクションプロトコルを格納する格納部と、前記格納部から前記一元化したインタラクションプロトコルを読み出すロード部と、前記一元化したインタラクションプロトコルに基づいて、次にメッセージを交換すべきノードへ移動するための移動部と、各ノードに設けられたエージェントラッパーの通信部との間でメッセージを交換する通信部とが実現されることを特徴とする情報処理装置。
【請求項２】
ネットワークによって接続された複数のノードを備え、前記ネットワークを介して各ノード間で仲介エージェントを移動させ、各ノードで仲介エージェントを動作させることにより情報処理を分散して行う情報処理方法において、
前記複数のノードに、当該ノード上における情報処理の実行手段である構成要素と、前記各構成要素をその固有の処理手順に従って動作させるためのアクセス部及び前記各ノード間をネットワークを介して移動する仲介エージェントとの通信機能を果たす通信部を備えたエージェントラッパーとを配置し、前記各ノードに配置された各構成要素に、各構成要素間で行われる相互作用プロセスを構成要素間で行われるメッセージ交換のルールで表現し、かつ前記仲介エージェントが保持する一元化したインタラクションプロトコルに基づいて、その相互作用プロセスを実行するように構成した情報処理装置を使用し、
各構成要素に固有のローカルな処理を記述したインタラクションプロトコルを前記エージェントラッパーのアクセス部に記述するステップと、
前記仲介エージェントに、前記一元化したインタラクションプロトコルを格納する格納部と、前記格納部から前記一元化したインタラクションプロトコルを読み出すロード部と、前記一元化したインタラクションプロトコルに基づいて、次にメッセージを交換すべきノードへ移動するための移動部と、各ノードに設けられたエージェントラッパーの通信部との間でメッセージを交換する通信部とを実現させるステップと、
各構成要素間で共通する問題解決の手順に関する処理については、前記仲介エージェントによって実現された格納部から読み出した前記一元化したインタラクションプロトコルに基づいて実行するステップと、
各構成要素に特有のローカルな処理については、その構成要素を配置したノード上に設けられたアクセス部に記述された前記固有のローカルな処理を記述したインタラクションプロトコルに基づいて実行するステップを含むことを特徴とする情報処理方法。
【請求項３】
ネットワークによって接続された複数のノードを備え、前記ネットワークを介して各ノード間で仲介エージェントを移動させ、各ノードで仲介エージェントを動作させることにより情報処理を分散して行う情報処理用ソフトウェアを記録した記録媒体において、そのソフトウェアは、
前記複数のノードに、当該ノード上における情報処理の実行手段である構成要素と、前記各構成要素をその固有の処理手順に従って動作させるためのアクセス部及び前記各ノード間をネットワークを介して移動する仲介エージェントとの通信機能を果たす通信部を備えたエージェントラッパーとを配置し、前記各ノードに配置された各構成要素に、各構成要素間で行われる相互作用プロセスを構成要素間で行われるメッセージ交換のルールで表現し、かつ前記仲介エージェントが保持する一元化したインタラクションプロトコルに基づいて、その相互作用プロセスを実行するように構成した情報処理装置を実現させ、
各構成要素に固有のローカルな処理を記述したインタラクションプロトコルを前記エージェントラッパーのアクセス部に記述するステップと、
前記仲介エージェントに、前記一元化したインタラクションプロトコルを格納する格納部と、前記格納部から前記一元化したインタラクションプロトコルを読み出すロード部と、前記一元化したインタラクションプロトコルに基づいて、次にメッセージを交換すべきノードへ移動するための移動部と、各ノードに設けられたエージェントラッパーの通信部との間でメッセージを交換する通信部とを実現させるステップと、
各構成要素間で共通する問題解決の手順に関する処理については、前記仲介エージェントによって実現された格納部から読み出した前記一元化したインタラクションプロトコルに基づいて実行するステップと、
各構成要素に特有のローカルな処理については、その構成要素を配置したノード上に設けられたアクセス部に記述された前記固有のローカルな処理を記述したインタラクションプロトコルに基づいて実行するステップを実行させるものであることを特徴とする情報処理用ソフトウェアを記録した記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンピュータネットワークを使った情報処理の技術の改良に関するもので、より具体的には、仲介エージェントを使って複数の既存システムの柔軟な結合を容易に実現するものである。
【０００２】
【従来の技術】
近年、コンピュータネットワークの急速な普及に伴い、ネットワークを介したアプリケーション間の相互接続が大きな課題となっており、特に、急速なネットワークインフラの整備とアプリケーションソフトウェアのオープン指向への流れが重なり、ネットワークを介したアプリケーション間の相互接続への要求が高まりつつある（参考文献：Genesereth,M.R. and Ketchpel,S.P., "Software agents", Special Issue on Intelligent Agents, Communications of the ACM, Vol.37,No.7,pp.48-53,July.1994. ／本位田  真一、守安  隆、川村  隆浩、" ネットワーク社会を実現するモバイルエージェント技術" 、東芝レビュー、Vol.53,No.8,pp.2-6,Aug.1998.）。
【０００３】
具体的には、一般にレガシーシステムと呼ばれる従来から使ってきた専用のソフトウェアや既存のデータベースをできる限り流用し、それらを相互に連携させることで、効率的な分散システムを構築、運用していくことが望まれる。
【０００４】
この場合の代表的な領域としては、ＣＡＬＳ(Commerce At Light Speed) と呼ばれる製品のライフサイクル全般に渡って関連情報を電子化しようとする試みや、オンラインショッピングなどの消費者ＥＣ(Electric Commerce) 、企業間の電子的な商取引を目指した企業間ＥＣなどが挙げられる。これらにおいてネットワークを介したアプリケーション間の相互接続は１つの大きなキーとなっている。
【０００５】
そのため、昨今ではネットワークを介してシステム間でデータ交換を実現するために、多くの技術や規格が提案されている。具体例として、文書処理記述体系としてのＳＧＭＬや、それをネットワークに対応させたＸＭＬ、製品技術データの表現と交換に使われるＳＴＥＰなどを挙げることができる。
【０００６】
【発明が解決しようとする課題】
しかしながら、分散システムから一貫したシステム動作を得るためには、データ交換に基づく知識共有だけでなく、分間システムを構成する各構成要素間を如何に調整するかが重要なポイントになり、調整機能なくしては分散システムのメリットは半減する。しかし、現状ではそういった調整機能を充分にサポートしている分散システムの開発環境は少ない。
【０００７】
また、近年、分散システムの構成要素をオブジェクトとした分散オブジェクトシステムや、相互に協調しあう複数のエージェントから構成されたマルチエージェントシステムの開発が盛んである。しかし、それらの開発をサポートするツールの多くは、構成要素間の通信機能をメインに据えており、構成要素間相互の調整機能をサポートしていない。したがって、通信機能を保証するだけでなく、調整機能を提供するフレームワークが必要とされている。なお、フレームワークは、半分完成したソフトウェアであり、これをベースにもう少し具体的な部分を作り込むことで、分散システムを構築できるものである。
【０００８】
すなわち、近年、分散アーキテクチャの流れは従来のクライアントサーバモデル（図１４）から、より柔軟な構成を可能にする分散オブジェクトモデル（図１５）へと移りつつあり、このような分散オブジェクトモデルでは一般に、接続するシステム相互の理解とモデル化およびインターフェースの厳密な規定が必要とされる。例えば、リモートで呼び出す相手先オブジェクトに関する対象知識（IDL Interface など）はあらかじめ既知であることが必要である。さらに、従来の単なるオブジェクト指向プログラミングシステムでは、複数のオブジェクト間で協調的な処理をするためのロジックの記述がサポートされていないため、オブジェクトの設計者はそれぞれ独自にそうしたロジックを個々のオブジェクトに組み込むことが必要である。
【０００９】
一方で、マルチエージェントモデルに関する研究では、分散システムの構成要素をエージェントとみなし、複数のエージェント間で協調的な処理を実現するためのモデルがいくつか提案されている。
【００１０】
代表的なものとして、ＫＱＭＬファシリテータ（参考文献：Agha,G., "Actors: A Model of Concurrent Computation in Distributed Systems",The MIT Press,1986. ／Finin,T. and Wiederhold,G., "An Overview of KQML: A Knowledge Query and Manipulation Language", Department of Computer Science, Stanford University, 1993.／\bibitem{DARPA} Patil,P.S., Fikes,R.E., Patel-Schneider,P.E., McKay,D., Finin,T., Gruber,T.R. and Neches,R., "The DARPA Knowledge Scharing Effort: Progress report", Proceedings of the Third International Conference on Principles of Knowledge Representation and Reasoning, 1992. ）や連邦アーキテクチャと呼ばれるモデルが挙げられる。
【００１１】
しかし、これらは、接続されたエージェントがＫＱＭＬメッセージの交換を基に相互作用する場合に、個々のメッセージのルーティング処理を促進することに主眼を置いたものである。したがって、複数のエージェント間で受け取った、または自分が出したメッセージを基に、この後どのように問題解決を進めていくか、といったより高いレベルの調整機能はサポートされていない。
【００１２】
こういった高いレベルの調整機能を提供するエージェント開発ツールとしてはＣＯＯＬ（参考文献：Barbuceanu,M. and Fox,M.S., "Cool: A language for describing coordination in multi agent systems", Proceedings of the First International Conference on Multi-Agent Systems,1995. ）やＪＡＦＭＡＳ（参考文献：Chauhan,D., "JAFMAS: A Java-based Agent Framework for Multiagent Systems Development and Implementation", PhD thesis, ECECS Department, University of Cincinnati,1997.）が挙げられる。
【００１３】
これらは、Ｓｐｅｅｃｈ−Ａｃｔ（参考文献：Austin,J.L.(ed.), "How to do Things With Words", Oxford University Press, 1962. ）ベースのマルチエージェントシステムを開発するための一般的な方法論を提案し、同時にＫＱＭＬメッセージ間の相互依存性を陽に表現するインタラクションプロトコル（Interaction Protocol、以下ＩＰと呼ぶ）の記述をサポートしている。このＩＰは、アプリケーションなど個々の構成要素相互と通信し、構成要素間の調整を図ることで与えられた問題解決という目的を達成するための手順であり、主に通信と調整という２つの要素を持っている。
【００１４】
しかし、これらのツールにおいてＩＰの作成は非常に複雑な作業である。なぜなら、ＩＰは各々のエージェントに対して専用のそれが組み込まれる必要があり、かつそれらが全体として整合性が取れていることが前提となっているからである。したがって、初期開発時をはじめ、運用後に問題解決の手順を一部追加修正したい場合などには、全体としてのエージェント間の複雑なインタラクションの流れを個々のエージェントのＩＰとして矛盾なく分解していく作業が、繰り返し必要とされるからである。
【００１５】
特に、この作業は関連するエージェントの数が増えたり、問題解決に至る手順が複雑化した場合には非常に考えにくいものになる。また、同時に各エージェントのＩＰが全体として整合性が取れているかどうかを検証することが困難になる。
【００１６】
つまり、従来技術では、いわば方言のように個々の構成要素ごとに異なるインタフェースなどの形式の違いに対応することと、個々の構成要素間の調整を図るという異なる２つの目的を一体に解決しようとしていたため、ＩＰの効率的な開発が困難という問題があった。
【００１７】
本発明は、上記のような従来技術の問題点を解決するために提案されたもので、その目的は、レガシーシステムやパッケージソフトなど複数の既存システムの柔軟な結合を、仲介エージェントを使って容易に実現する技術を提供することである。
【００１８】
【課題を解決するための手段】
上記の目的を達成するために、本発明は、ネットワークによって接続された複数のノードを備え、前記ネットワークを介して各ノード間で仲介エージェントを移動させ、各ノードで仲介エージェントを動作させることにより情報処理を分散して行う情報処理装置において、前記複数のノードは、当該ノード上における情報処理の実行手段である構成要素と、前記各構成要素をその固有の処理手順に従って動作させるためのアクセス部及び前記各ノード間をネットワークを介して移動する仲介エージェントとの通信機能を果たす通信部を有するエージェントラッパーとを備え、前記各ノードに配置された各構成要素は、各構成要素間で行われる相互作用プロセスを構成要素間で行われるメッセージ交換のルールで表現したインタラクションプロトコルに基づいて、その処理手順を実行するものであり、かつ、各構成要素に特有のインタラクションプロトコルについては、前記エージェントラッパーのアクセス部に記述され、前記各ノードには、前記仲介エージェントによって、各ノードに設けられたエージェントラッパーの通信部との間でメッセージを交換する通信部と、前記ノードからのメッセージに従って各ノード間を移動するための移動部と、装置全体として一貫した動作を行うための各構成要素に共通なインタラクションプロトコルを格納する格納部と、前記各ノードからのメッセージに基づいて前記格納部からインタラクションプロトコルを読み出すロード部とが実現されることを特徴とする。
また、これを方法並びにコンピュータ読取可能な記録媒体の観点から把握したものも、本発明の一態様である。
【００１９】
このような構成を有する本発明によれば、構成要素間の相互作用を記述した複雑なＩＰについて、分散システムを構成するレガシーシステムやデータベース（ＤＢと表す）などの構成要素１つ１つに組み込むのではなく、構成要素間での問題解決手順に関する処理と各構成要素に依存したローカルな処理に分離する。そして、前者については、仲介エージェントが一元的に管理することで、構成要素相互間の調整と通信とを実現する。これにより、分散システムの開発者は各構成要素については、メッセージルーティングなどを含む調整機能を考慮することが不要になり、各構成要素の内部機能の設計に専念できる。一方、構成要素相互間の調整機能については、個々の構成要素での方言のような処理や形式を考慮する必要がなくなるので、より高度な相互作用の設計に集中することができ、ＩＰの開発が容易になる。また、個々の構成要素を変更したり、構成要素間の相互作用による問題解決手順を変更したい場合、他方の要素を考慮する必要がないので、システムの変更も容易になる。この結果、レガシーシステムやＤＢなどの既存システムをネットワークを介して柔軟に結合することで効率的な分散システムを構築することが容易になる。なお、仲介エージェントは単数でもよいが複数用いることで、調整をより効率化することができる。
【００２０】
本発明の他の態様は、前記各ノードに、前記仲介エージェントによって、情報処理の実行の各状態に対応した複数のインタラクションプロトコルを格納する格納部と、各構成要素と仲介エージェント間のメッセージに基づいて現在の情報処理の状態に対応したインタラクションプロトコルを前記ロード部を介して呼び出す状態管理部が実現されていることを特徴とする。また、前記格納部は、インタラクションプロトコルを、情報処理またはインタラクションプロトコルの複数の状態の集合を単位として格納するように構成されたことを特徴とする。前記状態管理部は、前記複数の状態にそれぞれ予め設定された前提条件に基づいて、現在の前記情報処理の状態に適合する状態を呼び出してあてはめるように構成されたことを特徴とする。
【００２１】
このような本発明の他の態様によれば、同じＩＰでも、クラスをインスタンス化するように、具体的な状態にあてはめて適用できるので、効率的にプロトコルを管理することができる。また、複数の状態の集合を単位としてＩＰを取り扱うので、ＩＰの構成がわかりやすくなるとともに、互いに遷移する可能性のある状態の集合を呼び出したり、集合を単位として再利用することも容易になる。更に、集合に含まれる各状態にそれぞれ前提条件を設定しておくことで、現在の具体的な情報処理の状態に適合する状態をＩＰのなかから呼び出すことが可能となる。
【００２９】
【発明の実施の形態】
以下、本発明の実施の形態（以下「実施形態」という）について図面を参照しながら説明する。なお、本発明は、周辺機器を持つコンピュータを、ソフトウェアで制御することによって実現されることが一般的と考えられる。この場合、そのソフトウェアは、この明細書の記載にしたがった命令を組み合わせることで作られ、上に述べた従来技術と共通の部分には従来技術で説明した手法も使われる。また、そのソフトウェアは、プログラムコードだけでなく、プログラムコードの実行のときに使うために予め用意されたデータも含む。
【００３０】
そして、そのソフトウェアは、ＣＰＵ、コプロセッサ、各種チップセットといった処理装置、キーボードやマウスといった入力装置、メモリやハードディスク装置といった記憶装置、ディスプレイやプリンタといった出力装置などの物理的な資源を活用することで本発明の作用効果を実現する。
【００３１】
但し、本発明を実現する具体的なソフトウェアやハードウェアの構成はいろいろ変更することができる。例えば、ソフトウェアの形式には、コンパイラ、インタプリタ、アセンブラなどいろいろあり、外部との情報をやり取りするにも、フロッピーディスクなどの着脱可能な記録媒体、ネットワーク接続装置などいろいろ考えられる。また、本発明を実現するソフトウェアやプログラムを記録したＣＤ−ＲＯＭのような記録媒体は、単独でも本発明の一態様である。さらに、本発明の機能の一部をＬＳＩなどの物理的な電子回路で実現することも可能である。
【００３２】
以上のように、コンピュータを使って本発明を実現する態様はいろいろ考えられるので、以下では、本発明や実施形態に含まれる個々の機能を実現する仮想的回路ブロックを使って、本発明と実施形態とを説明する。
【００３３】
〔１．構成〕
〔１−１．全体構成〕
本実施形態は、複数の構成要素によって情報処理を行うための情報処理装置であり、本実施形態の全体的な構成を図１の概念図に示す。すなわち、図１は、本発明の構成を単純化して示したもので、分散システムが複数のエージェントで構成され、それら複数のエージェント間の調整をいくつかの仲介エージェントが行う状態を示している。
【００３４】
また、本実施形態の具体的な構成を図２に示す。すなわち、本実施形態は、分散システム（本システムとも呼ぶ）を構成する複数の構成要素として、アプリケーションやデータベースにかかわる処理を実行するローカルホストＨ１，Ｈ２（前記ノードにあたる）、及びそれらをネットワークＮを介して接続するためのエージェントラッパー１０，３０、及び、これらラッパー１０，３０を介して各構成要素間の調整を行うことで協調的な処理を実現する仲介エージェントＭＡを備えている。
【００３５】
このうち、エージェントラッパー１０と３０の構成は共通しており、例えばエージェントラッパー１０は、主に仲介エージェントＭＡとの通信機能を果たす通信部１１と、エージェントラッパー１０が対象とするＲＤＢＭＳ（リレーショナルデータベースマネジメントシステム）と接続するためのネイティブな手段であるアクセス部１２と、を備えている。すなわち、ネイティブな手段とは、個々のアプリケーションやローカルホスト固有の処理手順で動作する手段である。
【００３６】
このうち通信部１１は、仲介エージェントＭＡと予め決められた形式で通信するための第１の通信手段であり、また、アクセス部１２が行うのは、データベースに対するＳＱＬによる問合わせやＷｅｂサーバに対するｈｔｔｐアクセスなど、個々の構成要素のローカルな処理である。
【００３７】
また、仲介エージェントＭＡは、調整部５０と、通信部６０と、移動部７０と、を有している。このうち、通信部６０は、仲介エージェントＭＡが、ラッパー１０，３０と前記予め決められた形式で通信するための通信機能を果たす部分であり、第２の通信手段にあたる。なお、ここでいう通信は、具体的には、仲介エージェントＭＡとエージェントラッパー１０，３０の間で交されるメッセージ交換である。また、移動部７０は、仲介エージェントがネットワークＮに接続されたラッパー間を移動するための移動機能を果たす部分であり、仲介エージェントがノードであるホストＨ１，Ｈ２間で移動する移動手段にあたる。
【００３８】
また、調整部５０は、主に分散システムが全体として一貫した動作を行えるように、各構成要素間の調整機能を果たすための調整手段にあたり、具体的には、仲介エージェントＭＡが、持っているＩＰにしたがって動作することで各構成要素間の調整を実現する。なお、ラッパー１０，３０は、複数の仲介エージェントＭＡが同時または排他的に動作することを許容するプラットフォームとして位置づけられる。
【００３９】
〔１−２．調整部の具体的な構成〕
続いて、調整部５０のさらに具体的な構成を説明する。すなわち、調整部５０は、ＩＰ管理部５２と、状態管理部５１と、を備えている。このうちＩＰ管理部５２は、各構成要素間の調整を行うためのＩＰを管理するプロトコル管理手段である。また、調整部５０は、本システム及びＩＰに含まれる各状態を、状態遷移図で表現できる形式で処理するように構成されていて、状態管理部５１は、ＩＰに基づいて情報処理の状態を管理することで前記調整を行う状態管理手段である。
【００４０】
また、ＩＰ管理部５２は、格納部５３と、ロード部５４と、を備えている。このうち格納部５３は、ＩＰを格納する格納手段であり、ロード部５４は、現在の状態に応じて、必要なＩＰを格納部５３から呼び出して、状態管理部５１に渡すロード手段である。そして、格納部５３は、ＩＰを複数の状態の集合を単位として格納するように構成され、また、状態管理部５１は、前記複数の状態にそれぞれ予め設定された前提条件に基づいて、現在の情報処理の状態に適合する状態をＩＰから呼び出すことで、現在の情報処理の状態にあてはめるように構成されている。
【００４１】
また、調整部５０はメッセージ管理部５５を備え、このメッセージ管理部５５は、受け取ったメッセージを保持し、状態管理部５１の問合わせに応じて該当するメッセージを返す部分であり、これは、本実施形態の構成要素である各ローカルホストＨ１，Ｈ２との間で交わされる一連の会話のコンテキスト（脈絡）を正しく維持し、進行するための役割を果たす。
【００４２】
そして、このような調整部５０を備えた仲介エージェントＭＡは、分散システムの構成要素間で協調的な問題解決を達成するための調整機能を提供する。なお、本実施形態における調整機能は、エージェントラッパー１０，３０と仲介エージェントＭＡの間で交されるSpeech-Actベースのメッセージに相互依存性をもたらすものであり、以下のようなＩＰによって明示的に定義される。
【００４３】
〔１−２−１．ＩＰ〕
本来、ＩＰはＦｏｘらにより提案されたOrganizational Theory （参考文献：Fox,M.S., "A Common-Sence Model of the Enterprise, Proceedings of Industrial Engineering Research Conference", pp.178-194,1993. ／Fox,M.S., Barbuceanu M. and Gruninger M., "An Organization Ontology for Enterprise Modeling: Preliminary Concepts for Linking Structure and Behavior", Proceedings of the Fourth Workshop on Enabling Techonologies, Infrastructure for Collaborative Enterprises, IEEE Computer Societh Press,pp.237-251,1995. ）に基づいている。
【００４４】
これは異なる主体間での調整問題を組織レベルで考察するものであり、主体間で行われる相互作用プロセスに関する知識を前提とする。いわばトップダウン的なアプローチである。この相互作用プロセスを、主体間で行われる会話として、Speech-Actベースのメッセージ交換のルールで表現したものがＩＰである。
【００４５】
このＩＰは、他と相互作用を行いながら何らかの目的を達成するための各主体毎のプランであるともいえる。これは多くの場合、有限状態機械(finite state machine)として表現され、この中にはその主体が取りうる状態、そこでのアクション、次状態への遷移などが含まれる。この場合、各主体の自律性は、遷移可能な次状態の選択として発揮される。
【００４６】
また、ＩＰの実行時にそれ以降の状態遷移を動的に書き換える研究なども行われている（参考文献：Martin,F.J., Plaza,E., Rodriguesz-Aguilar,J.A. and Sabater,J., "JIM: A Java Interagent for Multi-Agent Systems", Proceedings of the AAAI-98 Workshop on Software Tools for Developing Agents,1998.）。このようなＩＰを状態遷移図の一種としてモデル化した例を図３に示す。
【００４７】
〔１−２−２．ＩＰの一元化〕
また、本実施形態におけるＩＰでは、複数の構成要素を使って情報処理を行うための問題解決手順のためのＩＰを、各構成要素に固有のローカルな処理と分離することで一元化したものである。
【００４８】
すなわち、従来技術とその問題点で説明したように、調整機能を提供している従来のエージェント開発ツールは各主体にＩＰを組み込む方法をサポートしている。しかしながら、多くの場合において複数の主体に対して相互に矛盾のない適切なＩＰを組み込みことは非常に複雑な作業である。
【００４９】
主な理由としては、ＩＰを各主体それぞれに組み込むためには、組織レベルの相互作用プロセスを、ある主体から見た場合の他の主体とのインタラクションに分解していく必要があることが挙げられる。具体的に個々の主体単位でのＩＰを作成するためには、まず初期状態を決め、そこで自分が取り得るアクションや他からやってくる可能性のあるメッセージの組み合わせを求め、それに応じて複数の次状態を設定する。そして、それらの状態に対しても同様に複数の次状態を設定し、全ての状態があらかじめ決めておいた終了状態に到達するまで繰り返す。これを全ての主体に対して実行した後、つなぎあわせて全体として整合性が取れているかどうかを検証する。こうした作業は初期開発時に行うだけでなく、運用後に問題解決の手順を追加修正したい場合などにも繰り返される。
【００５０】
ＩＰの作成を複雑にしているもうひとつの理由としては、その中に問題解決の手順に関する処理と、各主体に依存するローカルな処理とが混在していることが挙げられる。例えば、ＤＢの種類に応じた検索方法や初期化処理、終了処理などはその主体独自のローカルな処理である。一方で、あるメッセージに応じて必要なアクションを実行してその結果を返す、といった一連の手順は他の主体とも共通する問題解決の手順の一部である場合が多い。
【００５１】
そこで、本実施形態では、ＩＰをどのように一元化するかと、それに対応したアーキテクチャを提案している。すなわち、これはＩＰを問題解決の手順に関する処理とローカルな処理に分離し、問題解決手順に関するＩＰを一元化するというものである。
【００５２】
また、アーキテクチャとしては、問題解決手順に関して一元化したＩＰを、既に説明しているように移動型の仲介エージェントＭＡが持ち、ローカルな処理を記述したＩＰを各エージェントラッパー１０，３０が持つというものである。そして、仲介エージェントＭＡはこのようなＩＰにしたがって問題解決の進め方を導き、個々のラッパー１０，３０に次に何をすればよいかを指示することで協調的な処理を促進する。これによって、個々の主体、つまり分散システムの各構成要素に複雑なＩＰを組み込むことなく、相互の調整が実現される。
【００５３】
そして、問題解決手順に関するＩＰの一元化とは、組織レベルの相互作用プロセスを、各主体から見た場合の他の主体とのインタラクションに分解することなく、自律的に動くエージェントの見地から主体間を横断的に考えることである。具体的には、主体間のメッセージ交換をメッセージの送り主の意図を持った仲介エージェントＭＡの移動動作で置き換えることで、個々の主体単位であったＩＰを結合していく。ここでは仲介エージェントＭＡの状態が問題解決手順の進み具合いを表している。
【００５４】
これは、図４の概念図に示すように、いわば主体単位での縦方向のＩＰを、主体間をまたがる横方向のＩＰに変えることを意味しており、本実施形態では、このようにＩＰを作成することによって、より設計者の思考の流れに沿い易くなる。
【００５５】
〔１−２−３．ＩＰ一元化の具体的手法〕
以下に、どのようにＩＰ一元化を行うかの例を示す。
（１）分散システムの構成要素を決定する
まず、分散システムの目的と提供サービスを設定し、それに必要とされるシステムの構成要素、例えば顧客ＤＢ（データベース）や、検索エンジン、ＷＷＷ（ワールド・ワイド・ウェブ）サーバなどを決定する。なお、構成要素となるシステムについては、既存のものだけでなく今後開発されるものを追加できることはもちろんである。
【００５６】
（２）構成要素間の相互作用プロセスを設計する
次に、分散システムの各構成要素が有する機能に関する知識を用いて、目的とするサービスを実現するための相互作用の大まかな流れを設計する。ここで、一般に相互作用の流れとは、単なるワークフロー的なものや、制約充足のためのアルゴリズムなどである。
【００５７】
（３）問題解決手順に関する一元的なＩＰを設計する
そして、構成要素間の相互作用プロセスをベースに、仲介エージェントによる問題解決手順を表すＩＰとして具体化する。ここで、問題解決手順に関する一連のＩＰを作成するためには、ある構成要素において問題が発生した状態を起点とし、そこで取り得るアクションとその結果の組み合わせを求め、それに応じて次の状態を設定していく。
【００５８】
但し、個々の構成要素のＩＰは仲介エージェントＭＡの移動によって結合される。例えば、ある構成要素Ａが別の構成要素Ｂにアクション１を依頼するメッセージを送信し、そして、構成要素Ｂはアクション１を実行して、その結果を基にアクション２を実行する、という場合を考える。この例では、従来技術によれば、構成要素ＡとＢはそれぞれの自分のＩＰに基づいて動作することになる。
【００５９】
一方、同じ例でも、本実施形態において問題解決手順を一元化したＩＰでは以下のようになる。すなわち、まず、仲介エージェントＭＡは構成要素Ａの状態を検知するか、あるいは、構成要素Ａからなんらかのイベントを受け取り、構成要素Ｂにアクション１を依頼することを決定する。そして、仲介エージェントＭＡは構成要素Ｂに自ら移動して、アクション１の実行を指示する。さらに、仲介エージェントＭＡは、構成要素Ｂからその結果を受取り、アクション２の実行を指示する。また、ＩＰの途中で影響が派生して別の処理が必要になるような場合、すなわち処理が分岐するような場合は、別の仲介エージェントを生成して処理を担当させることもできる。
【００６０】
そして、問題解決手順に関するＩＰは、構成要素間の相互作用プロセスに基づいて必要なアクションが存在しなくなった時点で終了する。なお、各構成要素の初期状態や終了状態、または仲介エージェントＭＡによって指示されたアクションを実行するにあたってのローカルな処理手順は、エージェントラッパー１０や３０内のアクセス部１２や３２に記述しておく。
【００６１】
〔１−３．通信部の具体的構成〕
次に、仲介エージェントＭＡとエージェントラッパー１０，３０の各通信部１１，３１は、分散システムの構成要素間で情報交換を行うための通信機能を提供するが、この通信機能について説明する。すなわち、この通信機能は、エージェントラッパー１０，３０と仲介エージェントＭＡの間で交されるSpeech-Actベースのメッセージ交換をサポートする。また、メッセージ交換は全てエージェントラッパー１０，３０とそこに物理的に存在する仲介エージェントＭＡとの間で行われ、エージェントラッパー１０，３０間のメッセージ交換はサポートしなくてもよい。また、メッセージ交換は同期／非同期通信が可能である。
【００６２】
また、通信言語としては、Speech-Act theory に基づいて、ＫＱＭＬ（参考文献：Finin,T. and Wiederhold,G., "An Overview of KQML: A Knowledge Query and Manipulation Language", Department of Computer Science, Stanford University, 1993.）をベースに開発されたＡＣＬ(Agent Common Language) （参考文献："FIPA97 Specification", http://www.cselt.it/fipa/spec/fipa97/fipa97.htm, 1997.）を採用する。
【００６３】
そして、このＡＣＬは以下の３つの要素から構成されている。
（１）エージェント間の意志を表現するための外部言語（ＡＣＬ）
（２）エージェント間で交換する情報をエンコードするための内部言語
（３）共通アプリケーションエリアに適したオントロジ（＝語彙）
コンテンツ言語と、オントロジについては独自に拡張を行うことができる。
【００６４】
さらに、メッセージフォーマットとしては、ＡＣＬの論理構造をＸＭＬ（参考文献："Extensible Markup Language (XML) 1.0", http://www.w3.org/TR/REC-xmlXML, 1998.  ）で表現したＸＭＬ／ＡＣＬを規定する。ここで、このＸＭＬ／ＡＣＬによる表現の一例を図５に示す。
【００６５】
すなわち、このようにＡＣＬをＸＭＬで表現することのメリットとしては以下のような点が挙げられる。
（１）エディタやパーザなど開発環境が整っている。
（２）他のＸＭＬを用いた通信規格とＤＴＤ変換により、相互接続が可能となる。
（３）ＸＭＬ関連規格にあるHyper Link機能をオントロジー変換機能として使用できる。
【００６６】
そして、仲介エージェントＭＡはエージェントラッパー１０，３０からこのような通信によって渡されたメッセージにしたがって、問題解決手順に関するＩＰを実行する。また、エージェントラッパー１０，３０は仲介エージェントＭＡからこのような通信にしたがって渡されたメッセージにしたがって、ローカルな処理に関するＩＰ、例えば対象とするアプリケーションの機能呼び出しなど、を実行する。
【００６７】
〔２．作用〕
上記のように構成された本実施形態は、次のように作用する。
〔２−１．全体的作用〕
まず、図６は、本実施形態において、仲介エージェントと各構成要素との間における処理手順を示すフローチャートであり、このような処理手順について、これら仲介エージェントＭＡとラッパー１０，３０、接続対象となるアプリケーション２０，４０との間での簡単な機能の連携を示しながら説明する。
【００６８】
例えば、この手順では、まず、
（１）例えば、アプリケーション２０が、接続しているラッパー１０にネイティブな手段でイベントを送出する（ステップ１）。
（２）ラッパー１０はそのイベントを受取ると、必要に応じて仲介エージェントに通信部１１を用いてメッセージを送る（ステップ２）。
（３）すると、仲介エージェントＭＡが通信部６０を用いてメッセージを受取り（ステップ３）、調整部５０を用いて、対応するＩＰにしたがって次の行動を決定する（ステップ４）。この場合、決定された行動が、ラッパー３０への移動であるとする。
（４）この場合、仲介エージェントは移動部７０を用いてラッパー３０へ移動し（ステップ５）、調整部５０を用いて対応するＩＰにしたがって次の行動を決定する。この場合、ラッパー３０へメッセージを送ることであるとする。
（５）この場合、仲介エージェントは通信部６０を用いてラッパー３０へメッセージを送る（ステップ６）。
（６）すると、ラッパー３０は通信部３１を用いてメッセージを受取り（ステップ７）、必要に応じて、対象としているアプリケーション４０にネイティブな手段でアクセスし、アプリケーション４０がメッセージにしたがって動作することになる（ステップ８）。
【００６９】
〔２−２．調整の手順〕
また、上記のような手順を実行する際、メッセージ管理部５５は、受け取ったメッセージを保持し、状態管理部５１の問合わせに応じて該当するメッセージを返すことによって、構成要素である各ローカルホストＨ１，Ｈ２との間で交わされる一連の会話のコンテキスト（脈絡）を正しく維持し、進行する。
【００７０】
また、調整部５０は、本システムの各状態と、ＩＰに含まれる各状態を、状態遷移図で表現できる形式で処理し、ＩＰ管理部５２は、各構成要素間の調整を行うためのＩＰを、このような各状態に基づいてＩＰを管理し、状態管理部５１は、ＩＰに基づいて情報処理の状態を管理する。つまり、格納部５３は、複数の状態を集合としてＩＰを格納しており、ロード部５４は、前記複数の状態にそれぞれ予め設定された前提条件に基づいて、現在の状態に応じて、必要なＩＰを格納部５３から呼び出して、状態管理部５１に渡す。
【００７１】
この場合、状態遷移図は、仲介エージェントＭＡと各構成要素との間で交わされる会話が継続している間に取りうる全状態を表している。そして、状態管理部５１は、この中で現在の状態を保持し、必要なアクションをＩＰから呼び出す。そして、あらかじめ定義された遷移条件にしたがって次状態への遷移を行う。
【００７２】
〔３．効果〕
〔３−１．効果の概略〕
以上説明したように、本実施形態によれば、構成要素間の相互作用を記述した複雑なＩＰについて、分散システムを構成するレガシーシステムやＤＢなどの構成要素１つ１つに組み込むのではなく、構成要素間での問題解決手順に関する処理と各構成要素に依存したローカルな処理に分離する。そして、前者については、仲介エージェントが一元的に管理することで、構成要素相互間の調整と通信とを実現する。これにより、分散システムの開発者は各構成要素については、メッセージルーティングなどを含む調整機能を考慮することが不要になり、各構成要素の内部機能の設計に専念できる。
【００７３】
一方、構成要素相互間の調整機能については、個々の構成要素での方言のような処理や形式を考慮する必要がなくなるので、より高度な相互作用の設計に集中することができ、ＩＰの開発が容易になる。また、個々の構成要素を変更したり、構成要素間の相互作用による問題解決手順を変更したい場合、他方の要素を考慮する必要がないので、システムの変更も容易になる。この結果、レガシーシステムやＤＢなどの既存システムをネットワークを介して柔軟に結合することで効率的な分散システムを構築することが容易になる。なお、仲介エージェントは単数でもよいが複数用いることで、調整をより効率化することができる。
【００７４】
また、本実施形態では、仲介エージェントが通信先の構成要素があるノードへ移動するため通信回数が減り、通信回線が不安定でもエラー発生の可能性を減らすことができるだけでなく、用のないノードについては仲介エージェントが立ち去ることでシステムリソースを解放することができる。
【００７５】
また、本実施形態では、仲介エージェントの調整部５０内に、格納部５３とロード部５４とを設けることで、ＩＰ自体と、ＩＰによる状態管理とを分離して設計できるため実装が容易になる。また、本実施形態では、同じＩＰでも、クラスをインスタンス化するように、具体的な状態にあてはめて適用できるので、効率的にプロトコルを管理することができる。
【００７６】
また、本実施形態では、複数の状態の集合を単位としてＩＰを取り扱うので、ＩＰの構成がわかりやすくなるとともに、互いに遷移する可能性のある状態の集合を呼び出したり、集合を単位として再利用することも容易になる。また、本実施形態では、集合に含まれる各状態にそれぞれ前提条件を設定しておくことで、現在の具体的な情報処理の状態に適合する状態をＩＰのなかから呼び出すことが可能となる。
【００７７】
また、本実施形態では、各状態を状態遷移図として表現、すなわち状態遷移図として表せるような情報の形式で取り扱うことによって、ＩＰが理解しやすくなり、開発やデバッグなどの作業が効率化される。
【００７８】
また、本実施形態では、構成要素間の調整を行う問題解決手順が、各構成要素固有なローカルな処理と分離することでどの構成要素にも適用可能となり、コンパクトになることで設計だけでなく追加修正なども容易になる。
【００７９】
また、本実施形態では、メッセージ管理部５５が、メッセージの入出力のほか、生成や解釈といった管理、特に、受け取ったメッセージを保持し、状態管理部５１からの問合わせに応じて該当するメッセージを返すといった処理を行う。このため、仲介エージェントと各構成要素との間で交わされる一連の会話のコンテキスト（脈絡）を正しく維持し、進行することが容易になる。また、本実施形態では、汎用性に優れたＸＭＬと、中間言語レベルの論理体系を持つＡＣＬを組み合わせたメッセージによって仲介エージェントが通信を行うので、より多くのアプリケーションに本発明を適用することが容易になる。
【００８０】
〔３−２．問題解決手順に関するＩＰの一元化のメリット〕
また、ＩＰの一元化は、前述した設計の容易さに加えて、次のようなメリットが考えられる。すなわち、問題解決手順に関して一元化したＩＰは、従来の各構成要素が保有していたＩＰを単に加え合わせたものとは以下の点で異なっている。
【００８１】
（１）個々の構成要素に依存する処理に関するＩＰが切り放され、問題解決手順に特化している。
（２）複数の構成要素において同じ状態とアクションを実行する場合はＩＰ内のループとして記述できる等、表現の簡略化が可能である。
（３）問題解決にあたって各構成要素の並びや順番が動的に変化し、それに応じて処理手順等が変更される場合、従来は個々の構成要素が全ての場合に対応したＩＰを保持していなければならず、ＩＰの総和は非常に大きなものになりがちであった。しかし、本実施形態では並びや順番に依存する部分は、各構成要素毎ではなく、問題解決手順に関するＩＰに集約されるため、ＩＰの総和に比べ表現が整理されている。
そのため、問題解決手順に関して一元化したＩＰの状態数は、従来の各構成要素のＩＰをメッセージを介して繋げた場合の全状態数よりも少なくなる。したがって、初期開発時や運用後にＩＰの追加修正を行いたい場合などに、探索すべき状態空間が減り、構築容易性や保守性が向上する。
【００８２】
〔３−３．機能面の特徴〕
特に、本実施形態を機能面からみた特徴として、まず、ＩＰを用いた調整機能の存在が挙げられる。すなわち構成要素間の調整機能は分散システムから一貫したシステム動作を得るのに不可欠な機能であるが、従来の分散システムの開発環境では、これを充分にサポートしていなかった。これに対して、本実施形態では、調整機能に関して問題解決手順に関するＩＰを一元化し、これを仲介エージェントが管理して各構成要素間を調整するアーキテクチャを提供している。なお、後述の実施例において、ＩＰの一元化によって運用後にＩＰの追加修正を行いたい場合に構築容易性や保守性が向上することの実現例を示す。
【００８３】
なお、問題解決手順に関するＩＰの一元化は、言い換えれば分散システムの構成要素間の会話をコンテキスト単位で集中化することに相当する（図７）。そのため、処理の並列性は部分的に失われるが、これは集中型システムを意味しているわけではない。なぜなら、処理自体は各構成要素で分散的に行われ、通信もなんらかのノードに集中することはないためである。また、異なる目的の問題解決は、コンテキストが分けられて複数の仲介エージェントによって同時並行的に実行されるからである。
【００８４】
一方、会話をコンテキスト単位でまとめることは、以下のようなメリットを産んでいる。まず、従来のＩＰでは、各構成要素に対してメッセージルーティング機能、すなわち、会話の流れに基づいて受信したメッセージを適切なエージェントにフォーワード（転送）したり、その返答を受けて、元メッセージの発信元に返したりなどの一連の宛先決定処理や、複数状態管理機能、すなわち複数の会話が同時に行われる場合に、自己の内部状態が複数発生してしまうために、その適切な管理と収拾を行う機能といった複雑な処理を組み込む必要があった。
【００８５】
しかし、本実施形態では、仲介エージェントが会話をコンテキスト単位で管理し、かつ場合によっては必要なデータを保持したまま自律的に移動するため、個々の構成要素がメッセージルーティング機能や状態管理機能などを持つ必要はない。
【００８６】
また、従来のＩＰでは、問題や状況によって問題解決方法を変更したい場合などには、あらかじめ全ての構成要素に必要なＩＰを組み込んでおくか、全ての構成要素を変更することが必要となる。しかし、本実施形態では必要に応じて仲介エージェントのみを切り換えることで各構成要素に変更を加える必要はない。これらのメリットは、各構成要素に対するエージェントラッパーの開発を容易にし、本実施形態の目的である既存システムの柔軟な活用を促進している。
【００８７】
次に、本実施形態によれば、通信機能に関しては、エージェント間共通言語ＡＣＬを採用することで相手によって異なる呼び出し方法に関する知識が不要になっている。すなわち、異種アプリケーションや異業種システムを対象とした連携を実現したい場合、接続相手に関する知識の不足から相手側のメソッド名を直接呼び出す形式の通信機能は設計しにくく、拡張性も乏しい。これに対し、本実施形態では、Speech-Actベースの共通言語の採用により、エージェントラッパーで個々の違いを吸収することができるだけでなく、不足した情報等を「問合わせる(query) 」等の動作が可能である。また、メッセージフォーマットとしてＸＭＬ／ＡＣＬを規定することで、将来的に他のＸＭＬ通信規格との相互接続が期待できる。
【００８８】
また、移動機能に関しては、本実施形態では、モバイルエージェントを用いることによる通信コストの削減を実現している（参考文献：White,J.E.,"Mobile Agents"，Software Agents, ed. Bradshaw,J.M.,pp.437-472,The MIT Press,Massachusetts,1997. ）。特に通信頻度に関して、ネットワークを挟んでメッセージ交換を繰り返すのに比べ、エージェントが移動してローカルにメッセージ交換を行うことで通信回数を大幅に減らすことができる。これは、不安定な通信回線を用いている場合など１回の通信データ量が多くても通信頻度を少なくした方がよい場合に有効である。
【００８９】
また、本実施形態では、メッセージ交換が全てローカルに行われることで、一連の処理の途中でネットワークトラブルなどによりエラーが発生する可能性が少なくなり、エラー処理機構の実現が容易になった。さらに、本実施形態では、モバイルエージェントは必要な処理を終えた後で移動することで、エージェントラッパーはそのような処理を行っていないときにシステムリソースを解放できる。
【００９０】
〔３−４．応用面の特徴〕
また、上記のような本実施形態は、いろいろな分野に応用することが考えられるが、本実施形態は、少なくとも以下のような事例に使用することができる。  （１）分散型電力系統設備作業停止計画支援システム（参考文献：川村  隆浩，加瀬  直樹，荒木  大，大須賀  昭彦， "スケジューラ間の調整交渉に基づく分散協調型スケジューリングシステムの開発" ，信学論(D-I) ，Vol.J81-D-I,No.5,pp.505-513,May. 1998.／川村  隆浩，加瀬  直樹，長谷川  哲夫，大須賀  昭彦，本位田  真一， "モバイルエージェントを用いた分散制約充足問題へのアプローチ" ，信学技報，Vol.98,No.58,pp.15-22,May. 1998.）
（２）ネットワークエージェントによるリサイクル情報システム
【００９１】
また、これらの開発事例から、本実施形態のシステムは、少なくとも次のような場合における分散システムの開発に適していると思われる。
（１）分散システムの処理フローをシステムの運用開始後にも部分的に変更したい。
（２）既存システムになるべく変更を加えることなく分散システムを構築したい。
（３）異種アプリケーション、異業種システムを対象とした連携を実現したい。
（４）モバイル端末からも利用したい。
【００９２】
なお、本発明は、トップダウン的なアプローチであるために、現状では各構成要素の位置や機能などは既知のものとしてＩＰが設計されているが、別途ディレクトリサービスを用意して、仲介エージェントがこれを利用する形にすることで、より柔軟な運用が可能となる。
【００９３】
さらに、本実施形態では会話をコンテキスト単位でまとめているが、各コンテキスト間の連携、つまり仲介エージェント間の連携は現状ではサポートされていない。したがって、例えばデータベースを構成要素とする分散システムにおいて複数トランザクションの制御を行いたい場合には、各トランザクションを担当する仲介エージェントを何らかの手段で排他処理する必要があるが、これに関しては各アプリケーション毎の作り込みが必要とされる。例えば、上記の停止計画システムでは、スケジュール対象となるリソース単位でのロック機構を設ければよい。
【００９４】
【実施例】
続いて、システムの実装とＩＰの開発事例を紹介し、これをN-queens問題の分散的な解法に適用した場合に関して具体的なＩＰを示す。
【００９５】
〔１．システム実装の概要〕
本実施例のシステムは、Ｊａｖａ言語を用いて実装されている。また、本実施例におけるアーキテクチャのレベル構成を図８に示す。また、仲介エージェントおよびエージェントラッパーはそれぞれＪａｖａのクラスとして実装されており、本実施例による分散システムの開発は適宜、必要なクラスをインスタンス化し、用意されたメソッドを、場合によっては拡張して使用することを意味する。また、エージェントラッパーはＪａｖａによるNative Method のサポートやＪＤＢＣの機能を用いることにより、対象とするアプリケーションと接続する。
【００９６】
なお、詳細なクラス構成やメソッド一覧はプログラミング上どのようにも構成しうるので省略するが、全クラス数は５０であり、このうち、実際の分散システム開発にあたって拡張が必要とされるクラス数は４である。また、開発にあっては一部ビジュアルインターフェースをサポートする。
【００９７】
また、上に述べた調整機能については、ＩＰはそれ自体が１クラスとして実装し、ＩＰライブラリと呼ばれるリポジトリの中に格納する。これはあらかじめシステム開発者によって提供され、仲介エージェントによる調整を実行する際にインスタンス化されて使用される。
【００９８】
そして、ＩＰクラスには、あらかじめ基本となるアクションを呼び出すメソッド、ＸＭＬ／ＡＣＬに基づいたメッセージの作成、エージェントラッパーとのメッセージ送受信、仲介エージェントの移動など、を提供する。また、ＩＰライブラリ内にはサンプルとなるＩＰクラスを幾つか用意する。なお、状態遷移を引き起こすためのメカニズムとしては、前もって定義された各状態を条件に適合したものから順番に呼び出していく機構を実現する。
【００９９】
また、上に述べた移動機能および通信機能に関しては、Ｊａｖａによる分散オブジェクト技術をベースにする。例えば、ＨＯＲＢ（参考文献：Hirano,S.,"HORB: Distributed Execution of Java Programs", Proceedings of International Conference on Worldwide Computing and its Applications97, Japan,P.A-1-2,1997.）パッケージを使用し、仲介エージェントの移動や仲介エージェントとエージェントラッパー間のメッセージ交換を実現する。
【０１００】
〔２．分散システムによるN-Queens問題の解法〕
ここでは、よく知られたN-Queens問題を対象として、前述した問題解決手順に関するＩＰを一元化するメリットについて考察する。まず、図９に、本実施例を用いて開発したN-Queens問題を解く分散システムの概要を示す。この問題は４＊４のマス目として、各Queensの位置を管理する個々の管理システムＱＡ〜ＱＤを分散システムの構成要素とする。そして、それらをエージェントラッパーＷＡからＷＤによってネットワークＮに接続し、仲介エージェントＭＡによってQueens間の位置制約を解消するものとする。
【０１０１】
そこで、ＩＰ一元化のメリットを考察するため、本実施例において用いている問題解決手順に関するＩＰを、従来からの分散システムの各構成要素がＩＰを持つ場合と比較する。すなわち、このための実験として、システム開発後にＩＰの追加修正を行うことを想定し、Queens間の制約解消の方法を一部変更する。そして、〔問題解決手順に関するＩＰの一元化のメリット〕で述べた構築容易性や保守性の向上を確認するため、ＩＰ変更時に探索する必要のあった状態数と、実際の変更箇所の数と分散度を比較対象とする。
【０１０２】
すなわち、以下では、バックトラックアルゴリズムによる制約解消において、手詰まりになった時に、一つ前のエージェントが代替案を考える方式から、最も先頭のエージェントまで戻って代替案を考える方式に変更する場合を例として、問題解決手順に関して一元化したＩＰと従来のＩＰの相違を示す。
【０１０３】
ここで、図１０は、従来の分散システムの各構成要素がＩＰを持つ場合における変更前のバックトラックアルゴリズムを表現したＩＰを示す。また、図１１は、従来の分散システムの各構成要素がＩＰを持つ場合における変更後のバックトラックアルゴリズムを表現したＩＰを示す。
【０１０４】
また、図１２は、問題解決手順に関してＩＰを一元化した場合における変更前のバックトラックアルゴリズムを表現したＩＰを示す。図１３は、問題解決手順に関してＩＰを一元化した場合における変更後のバックトラックアルゴリズムを表現したＩＰを示す。なお、図１２、１３において、各エージェントラッパーは対象とする構成要素に依存する初期化処理と確定処理およびQueen の移動処理を有しているものとする。そして、仲介エージェントからの指示に応じて各処理を行う。
【０１０５】
まず、図１０および図１２を見比べることで、〔問題解決手順に関するＩＰの一元化のメリット〕で述べた問題解決手順に関して一元化したＩＰと従来の各構成要素が保有していたＩＰを単に加え合わせたものとの違いを確認できる。つまり、図１０では問題解決手順に関する処理と個々の構成要素に依存した処理（初期化処理や確定処理など）が混在しているため、構成要素間での一連のやりとりが追いにくいものになっている。また、構成要素Ｂと構成要素Ｃにおける問題解決手順は同様であるが、ローカルな処理が含まれるために両者のＩＰは完全には一致せず、それらが並列に記述され表現が煩雑になっている。
【０１０６】
それに対し、一元化されたＩＰでは、構成要素に依存した処理は切り放され、かつ、問題解決手順が同様である場合はループで表現されているため、処理の流れが追いやすい。
さらに、図１０は構成要素ＡからＢ，Ｃ，Ｄと順番に制約解消処理を行う場合のバックトラックアルゴリズムを表しているが、構成要素Ｄから逆順にＣ，Ｂ，Ａと処理を行いたい場合には、各構成要素はそれぞれ自分の順番に依存した２通りのＩＰを持たなくてならない。また、それらを必要に応じて切り換えることも必要とされる。それに対し、一元化されたＩＰ（図１２）では順番に依存する処理手順はそこに集約されているため、各構成要素毎に持つ必要はない。
【０１０７】
次に、図１０と図１１、および図１２と図１３を見比べることで、〔問題解決手順に関するＩＰの一元化のメリット〕で述べたＩＰを一部変更する際の構築容易性や保守性の向上を確認できる。すなわち、ＩＰを変更する際に現ＩＰの全ての状態をチェックすることを前提とした場合、図１０から図１１への変更には状態数２２をチェックしなければならない。それに対し、図１２から図１３への変更には状態数６をチェックすればよいことがわかる。
【０１０８】
また、実際に変更される状態も図１０から図１１への変更の場合は状態数４（図中網掛け部分）であるのに対し、図１２から図１３への変更には状態数１（図中網掛け部分）でよいことがわかる。さらに、前者の場合、変更は４つの内３つの構成要素に及んでいるのに対し、後者の場合は一元化されたＩＰを有する仲介エージェントのみを変更すればよいことがわかる。
【０１０９】
〔３．他の実施の形態〕
なお、本発明は上記実施形態に限定されるものではなく、次に例示するような他の実施形態も含むものである。例えば、少なくとも１つの構成要素に、一部の構成要素について調整を行うための第２の調整手段を備えてもよい。このようにすれば、一部の構成要素間の調整を全体の調整とは別に行うことができるので、よりきめ細かな調整が可能となり、情報処理が効率化される。また、構成要素間の調整については、必ずしもＩＰによらず、他のアルゴリズムを使ってもよい。
【０１１０】
また、各構成要素に係るアプリケーションの種類や、構成要素と仲介エージェントとの間のメッセージ通信の形式、ＩＰの形式やその格納形式などの詳細は自由に決めることができる。
【０１１１】
【発明の効果】
以上説明したように、本発明によれば、レガシーシステムやパッケージソフトなど複数の既存システムの柔軟な結合を、仲介エージェントを使って容易に実現することができるので、分散システムの構築が効率化される。
【図面の簡単な説明】
【図１】本発明の実施形態の構成例を示す概念図。
【図２】本発明の実施形態の構成を示すブロック図。
【図３】本発明の実施形態において、ＩＰを状態遷移図の一種としてモデル化した例を示す概念図。
【図４】本発明の実施形態において、課題解決手順にかかわるＩＰを一元化する例を示す概念図。
【図５】本発明の実施形態において、仲介エージェントとラッパーとの間でやり取りされるメッセージの形式を例示する* 図。
【図６】本発明の実施形態における処理手順の一例を示すフローチャート。
【図７】本発明の実施形態において、分散システムに含まれる構成要素間の会話をコンテキスト単位で集中化する状態を示す概念図。
【図８】本発明の実施例におけるアーキテクチャのレベル構成を示す概念図。
【図９】本発明の実施例の構成を示す概念図。
【図１０】従来技術において各構成要素ごとに分散していたＩＰを加え合わせて示す概念図（アルゴリズム変更前）。
【図１１】従来技術において各構成要素ごとに分散していたＩＰを加え合わせて示す概念図（アルゴリズム変更後）。
【図１２】本発明の実施例において問題解決手順に関して一元化されたＩＰを示す概念図（アルゴリズム変更前）。
【図１３】本発明の実施例において問題解決手順に関して一元化されたＩＰを示す概念図（アルゴリズム変更後）。
【図１４】従来の分散システムのアーキテクチャであるクライアントサーバモデルを示す概念図。
【図１５】従来の分散システムのアーキテクチャである分散オブジェクトモデルを示す概念図。
【符号の説明】
Ｎ…ネットワーク
Ｈ１，Ｈ２…ローカルホスト
ＭＡ…仲介エージェント
１０，３０，Ｗ…エージェントラッパー
２０，４０…アプリケーション
１１，３１，６０…通信部
１２，３２…アクセス部
５２…ＩＰ管理部
５３…格納部
５４…ロード部
５５…メッセージ管理部
７０…移動部
Ｑ…管理システム
Ｓ…手順の各ステップ
【図１】
0004240601.tif 000002
【図２】
0004240601.tif 000003
【図３】
0004240601.tif 000004
【図４】
0004240601.tif 000005
【図５】
0004240601.tif 000006
【図６】
0004240601.tif 000007
【図７】
0004240601.tif 000008
【図８】
0004240601.tif 000009
【図９】
0004240601.tif 000010
【図１０】
0004240601.tif 000011
【図１１】
0004240601.tif 000012
【図１２】
0004240601.tif 000013
【図１３】
0004240601.tif 000014
【図１４】
0004240601.tif 000015
【図１５】
0004240601.tif 000016