JP4021518B2 - データベース・システム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は，複数のユーザと複数のデータベースが存在する場合に，ユーザとデータベースとの間を仲介する機能を，エージェントと呼ぶプロセスを分散して複数動作させることによって実現したデータベース・システムに関する。
【０００２】
【従来の技術】
近年のコンピュータおよびコンピュータ・ネットワークの発達により，多数のコンピュータが高速なネットワークで結合された環境が整いつつある。このようなネットワークを通して，コンピュータ上で動作する多数のデータベースが利用可能になりつつある。
【０００３】
しかし，これら多数のデータベースは，それぞれ異なる内容を異なる利用手順で提供している。したがって，ユーザにとっては，まず自分の要求にもっとも合致したデータベースを探索すること自体が，困難になってきている。また，データベース毎に異なる利用手順を習得するのも，ユーザにとって大きな負担になってきている。
【０００４】
例えば，今日インターネット上には多数の文献データベースが存在するが，これらを利用するためには，ユーザは，まずどこにデータベースがあるのかを知る必要がある。また，データベースには，網羅的に文献を登録してあるデータベースもあるし，特定の分野に偏って情報を保持しているものもある。したがって，多数存在するデータベースから，自分の要求を満たした適切なものを選択しなくてはならない。さらに，個々のデータベースの利用手順は一般に異なる。したがって，利用者は各データベースの利用の手引等を参照しつつ，個別に検索を行うことになる。
【０００５】
また最近では，ＣＡＬＳやＥＣと呼ばれる動きが活発である。これらでは，電子的に物品の調達，管理や広告，売買などを行う仕組みが盛んに開発され，運用され始めている。しかし，これらの電子的な商取引の場合にも，データベースの選択や，利用手順に関する問題が発生している。
【０００６】
例えば，商取引の発注者側は，複数の生産者のデータベースから最新の製品情報を入手したり，自分の期待に最も満足する生産者を選択して，その生産者から製品を購入したいという要求がある。また生産者側は，自分の持つ製品に興味を持つような適切な顧客を見つけ出したり，発注者に自社製品を納入した後で，保守のために納入先のデータベースにアクセスして，製品の稼動情報を取得したいといった要求がある。このように，会社間にまたがって，データベースを相互に参照・利用しようという要求は，現実のものとして強く存在する。
【０００７】
しかしながら，データベースの形式や利用手順の差が，会社間はもとより，社内にも存在する場合があり，相互利用の大きな障害になっている。また，実際の業務に用いる場合には，情報の機密の確保や，利用権限の管理を厳しく行う必要があり，これらの点も問題となっている。
【０００８】
このような問題を解決する方法として，ネットワーク上にエージェント（代理人）と呼ばれるプログラムを用いて，エージェントにユーザとデータベースとの間を仲介させる方法が提案されている。エージェントは多数のデータベースの内容や利用手順を知っており，データベースの選択や，利用手順の差異の吸収や，利用権限のチェックは，エージェントが行う。ユーザから見た場合，エージェントは多数のデータベースを統合したような，仮想統合データベースとして見える。
【０００９】
【発明が解決しようとする課題】
以上のような技術的背景のもとで，本発明は，複数のユーザと複数のデータベースが存在する場合に，ユーザとデータベースの間を仲介する機構を対象としている。本仲介機構は，以下のようなユーザやデータベースを仮定している。機種の異なる計算機上で複数のデータベースが動作するような，いわゆる異機種分散データベース環境では，ごく自然にこのような状況が発生する。
【００１０】
・ユーザは一般に複数存在し，ユーザの発行する要求や受け取る回答の形式が複数存在する。
・データベースは一般に複数存在し，データベースの発行する要求や受け取る回答の形式が複数存在する。
【００１１】
本仲介機構は，このような仮定の下で以下の機能の実現を図る。これらの機能を図２７に示す。図中，８０はユーザ，８１は仲介機構，８２〜８５はデータベースを表す。なお，本明細書では要求側をユーザ，回答側をデータベースと呼んでおり，本発明は狭義のユーザ，狭義のデータベースに限定されるわけではない。一般には適切な要求や回答が行える人間，情報機器，プログラム等が，要求側（本発明でのユーザ）や回答側（本発明でのデータベース）になり得る。
【００１２】
（１）ユーザ８０の指定する出力手順に沿って要求を受け取る。
（２）ユーザ８０の要求に基づいて，データベース８２〜８５の中から，その要求を処理する適切なデータベースを選択する。なお，選択されたデータベースは複数の場合もあり得る。
【００１３】
（３）データベースの指定する入力手順に合わせて，要求を送る。
（４）データベースの指定する出力手順に合わせて，回答を受け取る。選択されたデータベースが複数の場合には，複数の回答を取りまとめる。
【００１４】
（５）ユーザ８０の指定する入力手順に沿って回答を送付する。
このような仲介機構を単純に実現する方法として，集中構成による実装を行う方法が考えられる。図２８は，集中構成による仲介機構の説明図である。
【００１５】
仲介機能の集中構成とは，図２８のように，一つのプログラムで実現される仲介機構９３がすべてのユーザ９０〜９２からの出力を受信し，すべてのデータベース９４〜９７に入力する構成を指す。データベース９４〜９７からの回答は，この逆の道筋を通り，一度，仲介機構９３に集められたあとで，質問をしたユーザ９０〜９２に送られる。しかし，このような集中構成では，以下のような問題が発生する。
【００１６】
・「動作時の負荷の集中」
すべての仲介作業を一つのプログラムで行うため，負荷が大きくなりやすい。また，ユーザ，データベースの増加が直接負荷の増加になり，負荷を分散させることができない。
【００１７】
・「運用管理コストの集中」
ユーザやデータベースを登録するような運用形態の場合，それぞれが増加するたびにプログラムの設定変更が必要になり，システム全体に対して影響が発生する。また，入出力形式が変更，削除されたり新規に追加される場合にも，プログラムの変更が必要となるため，システム全体に対して影響が発生する。
【００１８】
・「情報の機密を保持できない」
例えば，どのデータベースがどのような要求を受け付けられるかは，場合によっては機密情報となりえるが，集中構成ではそのような情報が一箇所に集められるため，情報の機密が保持できない。例えば，図２８に示す仲介機構９３は，すべてのデータベース９４〜９７に対してアクセスすることができ，仲介機構９３の管理者は，データベース９４〜９７の情報を何らの制限なしに得ることができる。
【００１９】
本発明は，仲介機構を分散構成にすることによって，動作時の負荷の集中，運用管理コストの集中，情報の機密を保持できないという集中構成の問題点を解決することを目的とする。
【００２０】
【課題を解決するための手段】
図１は本発明の原理説明図である。
本発明では，一つの仲介機構を，エージェントと呼ばれる通信機能を持ったプロセスを複数用いることにより実現する。エージェントは，一般に複数の計算機上で動作するが，１台の計算機上で一つのエージェントのみが動作する場合もあるし，複数のエージェントが動作する場合もあり得る。
【００２１】
図１に示すように，分散構成による仲介機構を，３種類のエージェントを用いて構成する。エージェントの分類と役割は，以下の通りである。
・ユーザ・エージェント
ユーザ・エージェント２１〜２４は，ユーザ１１〜１３とエージェント群（仲介機構全体）とのインターフェイスを取り持つエージェントである。ユーザ毎にアクセスの方法や必要とする回答の書式が異なる場合には，その差異はユーザ・エージェント２１〜２４が吸収する。ユーザ数が増加した場合にも，ユーザ・エージェントを局所的に増加させることで，エージェント群全体を変更せずに対応できる。
【００２２】
・仲介エージェント
仲介エージェント３１〜３８は，ユーザ・エージェント２１〜２４とデータベース・エージェント（以下，ＤＢエージェントと記す）４１〜４４との間を仲介するエージェントである。ユーザ・エージェント２１〜２４は，仲介エージェント３１〜３８に要求を送付することで，ＤＢエージェント４１〜４４を選択する。
【００２３】
・ＤＢエージェント
ＤＢエージェント４１〜４４は，データベース５１〜５４とエージェント群との間のインターフェイスを取り持つエージェントである。データベース５１〜５４毎の利用手順の差異や，回答形式の差異は，ＤＢエージェント４１〜４４が吸収する。データベースが追加された場合でも，対応するＤＢエージェントを追加することで，エージェント群全体を変更せずに対応できる。
【００２４】
詳しくは，本発明のデータベース・システムは，ユーザからの検索要求を受信する複数のユーザ・エージェントと，複数のデータベースの各々に対応した複数のデータベース・エージェントと，ユーザ・エージェントとデータベース・エージェントとの仲介を行う複数の仲介エージェントとを有し，前記ユーザ・エージェントの各々，前記データベース・エージェントの各々，前記仲介エージェントの各々は，それぞれ，条件に対応した出力先のエージェントを記憶した記憶手段を有し，該記憶手段の記憶内容に基づく転送処理を行い，ユーザより前記ユーザ・エージェントに対する検索要求があると，該ユーザ・エージェントは対応する記憶手段の記憶内容に基づき，前記仲介エージェントのいずれかへデータベース選択要求の転送を行い，前記仲介エージェントは，各々，前記ユーザ・エージェントまたは前記仲介エージェントのいずれかからデータベース選択要求を受信した場合，該仲介エージェントが有する記憶手段の記憶内容に基づき，前記仲介エージェントまたは前記データベース・エージェントのいずれかへデータベース選択要求を転送し，前記データベース・エージェントは，データベース選択要求を受信すると，該データベース・エージェントが有する記憶手段の記憶内容に基づき，前記仲介エージェントのいずれかへ選択結果の転送を行い，さらに前記各仲介エージェントは，前記データベース・エージェントまたは前記仲介エージェントのいずれかから選択結果を受信すると，該仲介エージェントが有する記憶手段の記憶内容に基づき，前記仲介エージェントまたは前記ユーザ・エージェントへの転送処理を行い，前記ユーザ・エージェントは，さらに，選択結果を受信すると，該選択結果に基づき選択された前記データベース・エージェントへ，直接ユーザより受信した検索要求を送信することを特徴とする。
以上のユーザ・エージェント，仲介エージェントおよびＤＢエージェントを実現するプログラムは，計算機が読み取り可能な適当な記憶媒体に格納することができる。そのプログラムを記憶媒体から計算機のメモリにローディングし，実行することにより，ユーザ・エージェント，仲介エージェントおよびＤＢエージェントを動作させることができる。
【００２５】
【発明の実施の形態】
以下，本発明の実施の形態を図面を参照して説明する。
１．システム構成
図２は，本発明の実施の形態におけるシステム構成の例を示す。
【００２６】
図２において，６１〜６８はＣＰＵおよびメモリ等からなる計算機，ＵＡはユーザ・エージェント（User Agent) ，ＦＡは仲介エージェント（Facilitate Agent) ，ＤＡはＤＢエージェント（Database Agent），７１，７２はＷＡＮやＬＡＮなどのネットワーク，７３はネットワーク間の接続を行うルータを表す。
【００２７】
各エージェントＵＡ，ＦＡ，ＤＡは，他のエージェントと通信する機能を持つ。これらのエージェント群は，一般に複数の計算機上で動作する。１台の計算機上で一つのエージェントのみが動作する場合もあるし，複数のエージェントが動作する場合もあり得る。複数の計算機に分散された各データベース５１〜５４に対応して，これらのデータベース５１〜５４にそれぞれアクセスするためのＤＢエージェントＤＡが配置される。
【００２８】
例えば，計算機６２のユーザが，ユーザ・エージェントＵＡを介してデータベース選択要求を行うと，その要求に関する条件に応じて要求の送付先が順次決定され，データベース５１が該当する場合には，仲介エージェントＦＡ，ネットワーク７１，ネットワーク７２および計算機６４の仲介エージェントＦＡとデータベースエージェントＤＡを介してデータベース５１の選択が行われるようになっている。一つの要求に対して，複数のデータベースが該当する場合には，複数のデータベースの選択が行われる。
【００２９】
２．分散構成による仲介機構の動作
２．１ ユーザからの要求手順
仲介機構の動作の説明の前に，まず仲介機構に対して与えられるユーザからの要求について説明する。
【００３０】
図３は，本実施の形態で対象とするユーザからの要求形式の例を示す図である。本実施の形態で対象とするユーザからの要求形式は，インターフェイスの統一のため，例えば図３のような形式に限定する。すなわち，ユーザからの要求は，まずデータベースを選択するための要求が発行され，続いて選択されたデータベースに対する要求が必要な回数だけ発行され，最後に選択したデータベースへの要求を終了する通知がなされるものとする。
【００３１】
ユーザがデータベースの概要を把握している場合には，ユーザはデータベースを選択するための要求と，そのデータベースへの要求を区別して意識していると思われる。そのため，このような限定を加えても実際の利用には大きな不都合は生じない。また，このような限定を加えた事により，仲介機構の動作を，この要求のパターンに対応した，簡潔な理解しやすいものとすることが可能となる。この点は大きな利点である。
【００３２】
以下では，データベースを選択する要求を「ＤＢ選択要求」，選択されたデータベースに対しての要求を「ＤＢ操作要求」，要求終了の通知を「ＤＢ完了要求」，これらが複数個つながったものを「ＤＢ複合要求」，以上すべてをまとめて「ＤＢ関連要求」と呼ぶことにする。
【００３３】
また，ＤＢ選択要求からＤＢ完了要求までを，ひとつの「セッション」と呼び，ユーザはセッション毎に一意な識別番号（セッションＩＤ）を割り当てるものとする。上記のＤＢ関連要求は，セッションＩＤとともに仲介機構に送られるものとする。これは，ＤＢ操作要求などが単独でなされた場合，どのＤＢ選択要求に対応するかを識別する必要があるためである。
【００３４】
２．２ 個々のエージェント動作
３種類のエージェントは，それぞれ基本動作と拡張動作を行う。エージェントの基本動作とは，自分の持つ条件に応じて，要求を配送し，回答をまとめる動作を指す。各エージェントは，他のエージェントの宛先と，そのエージェントに要求を送る場合に満たさなくてはならない条件の組を持つ。この条件と宛先の記述されている表を「条件表」と呼ぶ。
【００３５】
図４は，このエージェントの持つ条件表の構成例を示している。エージェントに要求が与えられた場合，そのエージェントは条件表を参照してこの要求が条件を満たす宛先すべてに対して，その要求を配送する。エージェントは，要求の回答をすべてまとめて，もともとの要求元に回答する。
【００３６】
この基本動作では，同時にタイムアウト処理や，要求の二重処理の回避も行われるが，これらに関しては，それぞれ第２．４節，第２．５節において詳しく説明する。
【００３７】
以上の基本動作に加えて，ユーザ・エージェントはユーザとのインターフェイス機能が，ＤＢエージェントにはデータベースとのインターフェイス機能が，拡張機能として定義されている。
【００３８】
２．３ 全体的な仲介機構の動作
仲介機構のエージェント群の動作は，大きく２段階に別れる。なお，以下のように２段階に分割したのは，一旦選択した個別ＤＢに対して，異なる要求を何度も繰り返す可能性が大きいためである。
【００３９】
（１）個別ＤＢ群の選択
第１段階では，まず個別のデータベースの選択を行う。選択されたデータベースを，ＤＢ群と呼ぶ。データベースには，まだ実際の要求は転送しない。
【００４０】
（２）要求回答処理
第２段階では，第１段階で得られたＤＢ群に対して，実際の要求を発行し，得られた回答をまとめてユーザに返答する。
【００４１】
このような仲介機構の動作を図５および図６に従って説明する。
図５は，仲介機構の第１段階の動作例を示している。
第１段階ではユーザの要求を満たすような，個別のデータベースを選択する。まず，ユーザからの要求をもとにして，ＤＢ選択要求をユーザ・エージェントが発行する。ＤＢ選択要求は，その要求を受け取った仲介エージェントの持つ条件表に基づいて分岐していき，最後にはＤＢエージェントにまで到達する。
【００４２】
図５（Ａ）の例では，ユーザ１２のＤＢ選択要求をユーザ・エージェント２２が受け取り，各エージェントが持つ条件表に従って，順次，仲介エージェント３２，３１，３６へ送られている。仲介エージェント３６では，条件を満たす仲介エージェント３７とＤＢエージェント４１へ要求を送り，さらに仲介エージェント３７では，ＤＢエージェント４２，４４へ要求を送っている。
【００４３】
要求を受け取ったＤＢエージェント４１，４２，４４は，その要求が自分の持つ条件を満たしている場合には，自分の管理するデータベース５１，５２，５４の名前をそれぞれ返し，そうでなければエラーを返す。
【００４４】
なお，一度処理した要求が同じエージェントに二度来た場合には，そのエージェントがエラーを返答し，条件表による配送処理は行わない。図５（Ａ）中の点線の矢印は，同じ要求が二重に到着したためエラーになった経路である。例えば，仲介エージェント３１には，同じ要求が仲介エージェント３２，３４から送付されている。この場合，後からの要求はエラーとして棄却される。
【００４５】
図５（Ｂ）は，ＤＢ選択結果の集約の過程を示している。各エージェントは，自分が発行したすべてのメッセージの回答もしくはエラーがそろった時点で，それらをまとめて要求元に返答する。この動作が繰り返され，最終的には，送られてきた経路の逆を通って，すべての回答が最初のユーザ・エージェント２２に集められる。そのため，最初のユーザ・エージェント２２は，エージェント群によって選択された個別データベース５１，５２，５４の集合（ＤＢ群）を持つことになる。
【００４６】
図６は，仲介機構の第２段階の動作例を示している。
第２段階では，図６（Ａ）のように，選択されたＤＢ群に対応するＤＢエージェント４１，４２，４４に対して，最初のユーザ・エージェント２２から直接ＤＢ操作要求を送る。各ＤＢエージェント４１，４２，４４は，送られた要求をデータベース５１，５２，５４に与え，図６（Ｂ）のように，得られた回答をユーザ・エージェント２２に返答する。ユーザ・エージェント２２は，各ＤＢエージェント４１，４２，４４から得られた回答をまとめて，ユーザ１２に返答する。以上により，ユーザ１２の発行した質問に対して，仲介機構からの回答がなされたことになる。
【００４７】
２．４ タイムアウト処理
分散構成でシステムを構成した場合には，エージェントの予期せぬ動作や通信回線のトラブルなどにより，要求への回答が戻ってこない場合が考えられる。そのような場合には返答を永久に待ち続けるのではなく，一定時間待った後に返答がなければあきらめて，エラー処理を行う必要がある。このような処理を「タイムアウト処理」と呼ぶ。
【００４８】
従来のタイムアウト処理は，一回の通信に対してあらかじめ決められた時間だけ待つようにする方式であった。しかし，分散構成で仲介機構を実現する場合には，通信が何段にも連続して行われる。このような場合に，途中の通信すべてに同一のタイムアウト時間を設定すると，それぞれの通信や計算処理に要する時間が考慮されていないため，ユーザとの間のインターフェイスはタイムアウトで終了しているにもかかわらず，内部では回答を計算し続けるような，無駄な処理を行ってしまう可能性がある。
【００４９】
そのため，通信が何段も中継されるような場合に，途中の通信時間，計算時間などの処理時間を考慮して，タイムアウトまでの時間を決める方式を考える必要がある。ここでは，以下の二つの方式を考案した。
【００５０】
［方式１］タイムアウトする時刻を指定する方式
この方式は特定の時刻になったときにタイムアウト処理を行うように指定する方式である。次のエージェントに渡すタイムアウトの時刻は，自分の回答処理に必要な時間を差し引いた時刻とする。
【００５１】
［方式２］タイムアウトまでの猶予時間を引き継ぐ方式
この方式では，要求を受け取る際に，この要求に対する返答を行うまでの猶予時間を同時に受け取る。要求を受け取ったエージェントは，この猶予時間から自分の要求処理および回答処理に必要な時間を差し引いて，新しい猶予時間を計算する。次のエージェントに要求を配送する際には，要求と同時に新しい猶予時間を与え，自分も新しい猶予時間だけ返答を待ち，返答が時間内に到着しなければ，エラーを要求元に返答する。
【００５２】
方式１は，タイムアウトを時刻で管理するために，エージェントが自分の処理に必要な時間を不正確に見積もった場合にも，ユーザの指定した時刻を越えて不必要な処理が行われない点が利点である。逆に欠点としては，エージェントの参照する時計の時刻を，すべてのエージェントにおいて正しく設定しておく必要がある点が挙げられる。
【００５３】
方式２は，時刻ではなく時間間隔でタイムアウトを管理するために，各エージェントの参照する時計の時刻を正しく設定しておく必要が必ずしもない点が利点である。分散構成でエージェントを動作させる場合には，すべての時計が正しく設定されていることが期待できない場合が多い。このような場合には，時刻を用いる方式１は採用不可能である。逆に欠点としては，エージェントが自分の処理に必要な時間を短く見積もった場合には，ユーザの指定した時刻を過ぎても，回答を生成するための処理が，引き続き行われてしまう可能性がある。
【００５４】
ここでは，以上の点を総合的に考慮した結果，タイムアウトまでの猶予時間を引き継ぐ方式を採用した。
２．５ 要求の二重処理の回避方式
各エージェントは，図４に示すような条件表に基づいて，ＤＢ選択要求の次の配送先を決定するが，条件表の複数の項目が満たされた場合には，それぞれの配送先に同じ要求を配送する。このような同じ要求は，要求配送の経路がループ状につながってしまった場合には，そのままでは同じ要求がタイムアウトになるまで繰り返し処理され続けることになり，非効率的である。また，もとは同じ要求から複製されたいくつもの要求が，同じエージェントに配送される可能性もある。この場合も同じ要求が何度も処理されるため，同様に非効率的である。
【００５５】
このような事態を避けるため，ここでは要求を最初に発行するユーザ・エージェントが，要求に識別番号（要求ＩＤ）を付加する方式を採用する。識別番号はすべてのエージェント群を通して，重複することのないような番号にする。このような番号は，ユーザ・エージェントの動作する計算機のネットワーク上での名前（ホスト名など）と，シーケンス番号または要求を発行する時刻などを組み合わせることにより，容易に生成可能である。
【００５６】
各エージェントは，自分が過去に処理した要求の要求ＩＤを記録している。新たに要求が与えられた場合には，その要求ＩＤと記録中の番号とを比較する。一致した要求ＩＤが発見された場合には，二重に要求が届いた場合であるので，エラーを返答する。
【００５７】
古い要求の要求ＩＤを記憶から除去する方法には何通りか考えられる。例えば，記憶している要求ＩＤの個数が，あらかじめ定めておいた上限に達した場合に，古い要求ＩＤを除去する方式や，要求処理後一定時間を経過した場合にその要求ＩＤを除去する方法などが挙げられる。前者は，古い要求ＩＤが必ず一定数存在することになるので，新しい要求ＩＤとの比較に時間を要する。また後者は，消去するまでの待ち時間を適切に定める必要がある。
【００５８】
本実施の形態では，主に後者を用いる。すなわち，ある要求の要求ＩＤは，その要求に付属しているタイムアウト猶予時間が経過した後に消去するものとする。この方法で要求の二重処理が発生しないことは，以下のように説明できる。
【００５９】
まず，一つの要求が二つに分岐したのち，あるエージェントに別々に到着した場合を想定しよう。そのエージェントは，先に到着した方の要求の要求ＩＤを，その要求のタイムアウト猶予時間以上の間，保持しておく。このタイムアウト猶予時間は，「この時間が経過した時にメッセージを送ると，最初に要求を生成したユーザ・エージェントがタイムアウトする直前にメッセージが到着するような時間」を意味している。
【００６０】
さて，このタイムアウト猶予時間が経過したのちに，同じ要求ＩＤを持つ要求が，そのエージェントに到達する場合があるかどうかを考えよう。この要求は，はじめの要求と比べて遠回りをしてこのエージェントに到着している。そのため，このエージェントから回答がなされる場合にも，同じ経路を通って，遠回りで回答が伝達される。したがって，あとからの要求に付属するタイムアウト猶予時間は，はじめの要求のものと比べて，短くなっているはずである。つまり，あとの要求の回答は，はじめの回答の要求よりも，早い時刻に回答しなければ間に合わないはずである。したがって，はじめに到着した要求のタイムアウト猶予時間が経過した後で，同じ要求ＩＤを持つ別の要求が到着することは，原理的には有り得ない。そのため，要求ＩＤを保持しておく時間は，先に到着した要求のタイムアウト猶予時間で十分であるといえる。
【００６１】
ただし，実際にはタイムアウト猶予時間を次のエージェントに伝える際に，自分のエージェントの処理に必要な時間を正確に予測できない場合が発生すると予想される。そのため，現実的には，与えられたタイムアウト猶予時間よりも多少長めに要求ＩＤを記録しておくのが望ましい。
【００６２】
なお，要求ＩＤの記憶数には限界があるため，記憶している一定数を越えた場合には古い要求ＩＤから消去していく方法も，併せて採用する。これは十分な記憶容量が確保できない場合に用いられるものであり，補助的なものである。
【００６３】
３．各エージェントのモジュール構成およびフローチャート
３．１ ユーザ・エージェントの場合
ユーザ・エージェントのモジュール構成は，図７に示すようになっている。ユーザ・エージェントは，内部的には複数のプロセスで構成されている。図７において，入力受付部２０１，条件部２０３，要求ＩＤ記録部２０４，ＤＢ群記録部２０５は，常駐型のプロセスであり，ユーザ・エージェントが起動されてから終了要求が来るまでの間，外部からの入力を待ちながら動作し続けている。入力処理部２０２は，外部からの入力が入力受付部２０１に来るたびに生成されるプロセスである。
【００６４】
実際の処理は，主に入力処理部２０２が，他の内部プロセスや他のエージェントと通信を行いながら実行する。このように入力処理部２０２が外部入力のたびに生成されるのは，一つのプロセスで入力を処理しようとすると，一つの入力の処理が終らない限り，次の処理に進めなくなり，ユーザから見た時の仲介機構の反応が，鈍くなるのを避けるためである。なお，以下の説明において「〜部」と称する場合には独立して動作する内部プロセスを指し，「〜ルーチン」と称する場合には，ある内部プロセスの一部を構成するサブルーチンを表す。
【００６５】
入力受付部２０１は，図８に示すＤＢエージェントの入力受付部３０１と同じ仕様である。要求をチェックし，入力処理部２０２を起動して，要求の処理を依頼する。終了要求が管理者によって与えられた場合には，処理を終了する。またデバッグのための情報や，アクセス記録などの内部情報が要求された場合には，それらの情報を返答する。内部情報とは，具体的にはデバッグのための経路トレース情報や管理運用のための時間帯別の処理件数などの情報である。
【００６６】
入力処理部２０２は，ＤＢ複合要求が来た場合には個々のＤＢ関連要求に分解し，それぞれを個別要求処理ルーチンに渡して，要求に対する処理を行う。
ＤＢ群記録部２０５は，ＤＢ選択要求によって選択されたＤＢ群をセッションＩＤをキーにして記録し，ＤＢ群の検索，削除などに対応する。記録情報は，例えば次のようなものである。
【００６７】
（セッションＩＤ１，｛ＤＢ１１，ＤＢ１２，…｝）
（セッションＩＤ２，｛ＤＢ２１，ＤＢ２２，…｝）
……
条件部２０３，要求ＩＤ記録部２０４の仕様は，仲介エージェント（図８）の条件部３０３，要求ＩＤ記録部３０４，およびＤＢエージェント（図９）の条件部４０３，要求ＩＤ記録部４０４と共通である。
【００６８】
条件部２０３は，図４で説明したような要求の配送先を決定する条件表を保持し，入力処理部２０２からの要求に応じて条件表を回答する。また，エージェントの管理者からの条件の登録，削除要求なども処理する。
要求ＩＤ記録部２０４は，過去に処理を行ったことのある要求の識別番号（要求ＩＤ）と，その要求に対するタイムアウト猶予時間を記録しておく内部プロセスである。主に登録要求，検索要求を受け付ける。要求ＩＤ記録部２０４には，記録できる要求ＩＤの個数に上限が設定されており，その上限を越えて記録しようとした場合には，古い要求ＩＤを上書きする。また，検索要求がなされた場合には，記憶している過去の要求ＩＤと順に照合して行くが，一致する要求ＩＤが見つかればそのＩＤを，そうでなければ見つからなかった旨を返答する。
【００６９】
なお，第２．５節で述べたように，要求ＩＤは，そのエージェントのタイムアウト猶予時間を経過したものは削除してよい。本実施の形態では，削除処理を別個に設けることはせず，検索中に，十分古い要求ＩＤが見つかった場合には，その要求ＩＤを削除することにする。
【００７０】
他に，内部プロセスではないが，大きな処理単位として，個別要求処理ルーチン，ＤＢ操作要求処理ルーチンがある。これについては，処理フローチャートの説明で後述する。
【００７１】
３．２ 仲介エージェントの場合
仲介エージェントは，図８に示すように，入力受付部３０１，入力処理部３０２，条件部３０３および要求ＩＤ記録部３０４の４種類の内部プロセスから構成されている。ユーザ・エージェントの場合と同様に，入力処理部３０２は，外部からの入力が入力受付部に来るたびに生成されるプロセスであり，他は常駐プロセスである。
【００７２】
入力受付部３０１は，要求ＩＤをもとに二重要求（以前処理したことのある要求）かどうかをチェックし，そうならばエラーを返す。要求がＤＢ選択要求であれば，入力処理部３０２を起動し，処理を依頼する。
【００７３】
入力処理部３０２は，自分に与えられる要求はＤＢ選択要求のみであるので，そのままＤＢ選択要求処理ルーチン（後述する）を呼ぶ。
条件部３０３，要求ＩＤ記録部３０４は，全エージェントに共通であり，図７のユーザ・エージェントで説明した処理と同様な処理を行う。
【００７４】
３．３ ＤＢエージェントの場合
ＤＢエージェントは，図９に示すように，入力受付部４０１，入力処理部４０２，条件部４０３，要求ＩＤ記録部４０４およびＤＢインターフェイス部４０５の５種類の内部プロセスから構成されている。ユーザ・エージェントの場合と同様に，入力処理部４０２は，外部からの入力が入力受付部４０１に来るたびに生成されるプロセスである。
【００７５】
入力受付部４０１は，図７に示すユーザ・エージェントの入力受付部２０１と同じ仕様である。
入力処理部４０２は，ＤＢ選択要求が来ればＤＢ選択要求処理ルーチン（後述）を呼ぶ。ＤＢ操作要求であれば，ＤＢインターフェイス部４０５に要求を転送する。
【００７６】
ＤＢインターフェイス部４０５は，実際のデータベース５１と通信を行って，要求を依頼し，回答を受け取る。ＤＢインターフェイス部４０５は，同時に一度の要求しか処理しないようになっているので，複数の要求を同時に受け取れないようなデータベースにも対応している。
【００７７】
条件部４０３，要求ＩＤ記録部４０４は，全エージェントに共通であり，上述した処理を行う。
３．４ 各部の処理フロー
図１０は，ユーザ・エージェントの入力受付部２０１およびＤＢエージェントの入力受付部３０１の処理フローチャートである。
【００７８】
入力受付部２０１，３０１への入力情報は，(a) セッションＩＤとＤＢ関連要求，(b) 終了要求，(c) 内部情報要求のいずれかの情報である。入力受付部２０１，３０１は，入力待ちの状態（図１０のステップＳ１０）において，外部からの入力があると，まずステップＳ１１により二重要求チェックを行う。二重要求であれば，その要求を廃棄するエラー（ＥＲＲＯＲ）処理を行い（Ｓ１２，Ｓ１３），ステップＳ２０へ進む。
【００７９】
二重要求でない場合，ＤＢ関連要求であるかどうかを判定し（Ｓ１４），ＤＢ関連要求であれば入力処理部２０１，３０１を生成して，その要求を引数として入力処理部２０１，３０１に渡す。その後，ステップＳ２０へ進む。
【００８０】
終了要求であれば，処理を終了する（Ｓ１６）。
デバッグや管理運用のための内部情報要求であれば（Ｓ１７），要求された内部情報を要求元へ送り（Ｓ１８），ステップＳ２０へ進む。内部情報要求でもなければ，その要求をエラーとしてＥＲＲＯＲ処理を行い（Ｓ１９），ステップＳ２０へ進む。ステップＳ２０では，内部情報として提供するための処理件数やエラー情報などのアクセス記録の更新を行い，その後，ステップＳ１０の入力待ち状態に戻る。
【００８１】
図１１は，ユーザ・エージェントの入力処理部２０２の処理フローチャートである。
入力処理部２０２への入力情報は，セッションＩＤとＤＢ関連要求である。ステップＳ３０では，ＤＢ関連要求を内部形式に変換する。ステップＳ３１では，要求がＤＢ複合要求かどうかを判定し，ＤＢ複合要求でなければ，ステップＳ３２によって，個別要求処理ルーチン（図１２）を呼び出し，個別のＤＢ関連要求を処理する。その後，ステップＳ３７へ進む。
【００８２】
ＤＢ複合要求であれば，ステップＳ３３へ進み，一連の要求を個別要求に分解する。そして，分解した個別要求について，先頭から順番にすべての個別要求についての処理を行う（Ｓ３４〜Ｓ３６）。すべての個別要求について処理をしたならばステップＳ３７へ進む。
【００８３】
ステップＳ３７では，結果をユーザの要求する形式に変換して回答し，その後，処理を終了する。
図１２は，ユーザ・エージェントの個別要求処理ルーチンの処理フローチャートである。
【００８４】
個別要求処理ルーチンへの入力情報は，(a) セッションＩＤとＤＢ選択要求，(b) セッションＩＤとＤＢ操作要求，(c) セッションＩＤとＤＢ完了要求のいずれかの情報である。
【００８５】
最初に，ＤＢ選択要求であるかどうかを判定し（Ｓ４０），ＤＢ選択要求であれば，新規に要求ＩＤ，タイムアウト猶予時間を設定した後に，ＤＢ選択要求処理ルーチン（図１３）を呼び，条件表に基づいてＤＢ選択要求を仲介エージェント，ＤＢエージェントに配送し，条件を満たすＤＢ群を選択し，ＤＢ群記録部２０５にセッションＩＤとともに記録する（Ｓ４１〜Ｓ４４）。
【００８６】
要求がＤＢ操作要求であれば（Ｓ４５），ＤＢ操作要求処理ルーチン（図１５）を呼ぶ（Ｓ４６）。
要求がＤＢ完了要求であれば（Ｓ４７），付属するセッションＩＤを使って，対応するＤＢ群を，ＤＢ群記録部２０５に要求して削除する（Ｓ４８）。
【００８７】
図１３は，ＤＢ選択要求処理ルーチンの処理フローチャートである。なお，ＤＢ選択要求処理ルーチンは，全エージェントに共通のサブルーチンである。
ＤＢ選択要求処理ルーチンへの入力情報は，ＤＢ選択要求と要求ＩＤとタイムアウト猶予時間の情報である。まず，ステップＳ５０では，入力したタイムアウト猶予時間を自分の処理に必要な時間だけ減少させる。次に，ステップＳ５１では，タイムアウト猶予時間が０以下であるかどうかをチェックし（Ｓ５１），０以下になっていれば，エラー（ＥＲＲＯＲ）処理を行い（Ｓ５２），処理を終了する。
【００８８】
タイムアウト猶予時間が０以下になっていなければ，条件部から条件表を取得し（Ｓ５３），条件に合う出力先のリストを作成する（Ｓ５４）。そして，すべての出力先に対してステップＳ５５１〜Ｓ５５３を実行する（Ｓ５５）。すなわち，出力先が自分でなければ（Ｓ５５１），出力先に要求を送付する（Ｓ５５２）。出力先が自分となっている場合，ここでは特別な意味を持たせており，自分の宛先を回答する（Ｓ５５３）。すなわち，ＤＢエージェントの場合，自分が管理するデータベースの名前を回答する処理を行う。
【００８９】
次に，ステップＳ５６では，回答待ちルーチン（図１４）を呼び出し，その後，ステップＳ５７によって回答をまとめて，その回答を要求元へ返送する。
図１４は，回答待ちルーチンの処理フローチャートである。回答待ちルーチンは，全エージェントに共通のサブルーチンである。
【００９０】
回答待ちルーチンの入力情報は，タイムアウト猶予時間と回答を行うエージェント群の情報である。回答待ちルーチンは，タイムアウト処理を行う部分であり，返答がくるか，またはタイムアウト猶予時間が経過するのを待つ（Ｓ６０）。すべての返答が揃うか，タイムアウト猶予時間が経過するかのいずれかが満たされると，その時点までに得られている回答を返答し（Ｓ６１〜Ｓ６３），処理を終了する。
【００９１】
図１５は，ユーザ・エージェントのＤＢ操作要求処理ルーチンの処理フローチャートである。
ＤＢ操作要求処理ルーチンへの入力情報は，セッションＩＤとＤＢ操作要求である。ＤＢ操作要求処理ルーチンは，実際にＤＢ操作要求を処理する部分である。ステップＳ７０では，ＤＢ群記録部２０５から与えられたセッションＩＤに対応するＤＢ群を取得する。次に，ステップＳ７１では，要求ＩＤを新規に登録し，続いてステップＳ７２では，タイムアウト猶予時間を決定する。
【００９２】
ステップＳ７３では，ＤＢ群記録部２０５から得たＤＢ群内のすべてのＤＢエージェントに（ＤＢ操作要求，要求ＩＤ，タイムアウト猶予時間）の要求メッセージを発行する。その後，ステップＳ７４では，図１４の回答待ちルーチンを呼び出し，ステップＳ７５では，結果を集計してユーザへ回答する。
【００９３】
図１６は，ユーザ・エージェントのＤＢ群記録部２０５の処理フローチャートである。
ＤＢ群記録部２０５への入力情報は，検索または削除時の場合にはセッションＩＤ，登録時の場合にはセッションＩＤとＤＢ群の情報である。または内部情報要求であることを示す要求種別情報である。ＤＢ群記録部２０５は，入力待ち状態（Ｓ８０）において要求があると，登録要求に対しては，セッションＩＤとＤＢ群の登録処理（Ｓ８１，Ｓ８２），削除要求に対しては，該当するセッションＩＤのエントリの削除処理（Ｓ８３，Ｓ８４），検索要求に対しては，該当するセッションＩＤのエントリを回答し（Ｓ８５，Ｓ８６），終了要求に対しては，処理を終了する（Ｓ８７）。また，デバッグや管理運用のための内部情報要求に対しては，要求された内部情報を提供する（Ｓ８８，Ｓ８９）。以上の要求に該当しない場合については，所定のエラー処理を行う（Ｓ９０）。
【００９４】
その後，終了要求以外についてはアクセス記録を更新し（Ｓ９１），ステップＳ８０の入力待ち状態に戻る。
図１７は，条件部の処理フローチャートである。条件部の処理手続きは，全エージェントに共通である。
【００９５】
条件部への入力情報は，(a) 条件登録要求，(b) 条件削除要求，(c) 条件表取得要求，(d) 終了要求，(e) 内部情報要求のいずれかの情報である。
まず，ステップＳ１００では，初期条件として与えられた条件表を所定のファイルから読み込み，ステップＳ１０１で入力待ち状態に入る。何らかの要求があると，ステップＳ１０２へ移り，要求が条件登録要求または条件削除要求であるかどうかを判定する。条件登録要求または条件削除要求の場合，要求元がアクセス権限を持つかどうかをチェックし（Ｓ１０３），アクセス権限がなければエラー処理を行う（Ｓ１０４）。アクセス権限があれば，要求された条件表への条件の登録または条件の削除を行い，書き換えた結果をファイルに書き込み，処理した旨を回答する（Ｓ１０５，Ｓ１０６）。
【００９６】
要求が条件表取得要求の場合，条件表を要求者に回答する（Ｓ１０７，Ｓ１０８）。
終了要求に対しては，処理を終了する（Ｓ１０９）。
【００９７】
また，デバッグや管理運用のための内部情報要求に対しては，要求された内部情報を提供する（Ｓ１１０，Ｓ１１１）。以上の要求に該当しない場合については，所定のエラー処理を行う（Ｓ１１２）。
【００９８】
その後，終了要求以外についてはアクセス記録を更新し（Ｓ１１３），ステップＳ１０１の入力待ち状態に戻る。
図１８は，要求ＩＤ記録部の処理フローチャートである。要求ＩＤ記録部の処理手続きは，全エージェントに共通である。
【００９９】
要求ＩＤ記録部への入力情報は，(a) 登録要求と要求ＩＤ，(b) 検索要求と要求ＩＤのいずれかの情報である。ステップＳ１２０の入力待ち状態において，何らかの要求があると，その要求種別に応じて以下の処理を行う。
【０１００】
登録要求の場合（Ｓ１２１），要求ＩＤの記憶個数が上限に達したかどうかによって（Ｓ１２２），最も古いＩＤへの新しい要求ＩＤの上書き（Ｓ１２３），または空き領域への新しい要求ＩＤの追加登録（Ｓ１２４）を行う。
【０１０１】
検索要求の場合（Ｓ１２５），記録している要求ＩＤと順に照合し（Ｓ１２６），同一ＩＤを発見したときには該当エントリを回答する（Ｓ１２７）。全ＩＤと照合しても要求ＩＤが見つからないときは，該当無しを回答する（Ｓ１２８）。この照合の途中で，タイムアウト猶予時間よりも十分に古い要求ＩＤを発見したときには，その要求ＩＤを削除する（Ｓ１２９）。
【０１０２】
終了要求の場合，処理を終了する（Ｓ１３０）。
また，デバッグや管理運用のための内部情報要求に対しては，要求された内部情報を提供する（Ｓ１３１，Ｓ１３２）。以上の要求に該当しない場合については，所定のエラー処理を行う（Ｓ１３３）。
【０１０３】
その後，終了要求以外についてはアクセス記録を更新し（Ｓ１３４），ステップＳ１２０の入力待ち状態に戻る。
図１９は，仲介エージェントの入力受付部３０１の処理フローチャートである。
【０１０４】
入力受付部３０１は，外部から入力情報として，(a) ＤＢ選択要求と要求ＩＤとタイムアウト猶予時間，(b) 終了要求，(c) 内部情報要求のいずれかの情報を受け取る。入力待ち状態（Ｓ１５０）において，要求を受け取ると，要求ＩＤをもとに二重要求かどうかをチェックし（Ｓ１５１），二重要求であればエラー処理を行う（Ｓ１５２，Ｓ１５３）。
【０１０５】
二重要求でない場合，ＤＢ選択要求に対しては，入力処理部３０２を生成し，要求を引数として入力処理部３０２に渡す（Ｓ１５４，Ｓ１５５）。
終了要求に対しては，処理を終了する（Ｓ１５６）。
【０１０６】
また，デバッグや管理運用のための内部情報要求に対しては，要求された内部情報を提供する（Ｓ１５７，Ｓ１５８）。以上の要求に該当しない場合については，所定のエラー処理を行う（Ｓ１５９）。
【０１０７】
その後，終了要求以外についてはアクセス記録を更新し（Ｓ１６０），ステップＳ１５０の入力待ち状態に戻る。
図２０は，仲介エージェントの入力処理部３０２の処理フローチャートである。
【０１０８】
入力処理部３０２は，入力情報としてＤＢ選択要求，その要求ＩＤおよびタイムアウト猶予時間の情報を受け取ると，ステップＳ１４０において，ＤＢ選択要求処理ルーチンを呼び出す。ＤＢ選択要求処理ルーチンでは，図１３で説明した処理を行う。
【０１０９】
図２１は，ＤＢエージェントの入力処理部４０２の処理フローチャートである。
入力処理部４０２は，入力情報として，(a) ＤＢ選択要求，その要求ＩＤおよびタイムアウト猶予時間，(b) ＤＢ操作要求，その要求ＩＤおよびタイムアウト猶予時間のいずれかの情報を受け取る。
【０１１０】
ＤＢエージェントの入力処理部４０２は，ＤＢ選択要求に対しては，ＤＢ選択要求処理ルーチン（図１３）を呼び出す（Ｓ１６１，Ｓ１６２）。
ＤＢ操作要求に対しては，ＤＢインターフェイス部４０５に要求を転送し，ＤＢインターフェイス部４０５からの回答を要求元に転送する（Ｓ１６３〜Ｓ１６５）。それ以外の要求に対しては，所定のエラー処理を行い（Ｓ１６６），処理を終了する。
【０１１１】
図２２は，ＤＢエージェントのＤＢインターフェイス部４０５の処理フローチャートである。
ＤＢインターフェイス部４０５の入力情報は，(a) ＤＢ操作要求，その要求ＩＤおよびタイムアウト猶予時間，(b) 終了要求，(c) 内部情報要求のいずれかの情報である。
【０１１２】
ＤＢインターフェイス部４０５は，ステップＳ１７０の入力待ちの状態において，ＤＢ操作要求を受け取ると，データベース（ＤＢ）毎に指定された形式でデータベース（ＤＢ）に要求する（Ｓ１７１，Ｓ１７２）。ここで，指定された形式とは，例えばＤＢの種類によって定まるアクセス言語等を用いることを意味する。ＤＢからの回答があれば，本システムにおいてあらかじめ定められている内部形式に変換し，要求元に返答する（Ｓ１７３，Ｓ１７４）。
【０１１３】
終了要求に対しては，処理を終了する（Ｓ１７５）。
また，デバッグや管理運用のための内部情報要求に対しては，要求された内部情報を提供する（Ｓ１７６，Ｓ１７７）。以上の要求に該当しない場合については，所定のエラー処理を行う（Ｓ１７８）。
【０１１４】
その後，終了要求以外についてはアクセス記録を更新し（Ｓ１７９），ステップＳ１７０の入力待ち状態に戻る。
４．分散構成による仲介機構の特長および効果
以上の分散構成による仲介機構の要点を列挙すると，以下のとおりである。
【０１１５】
(1) 仲介機構を，ユーザ・エージェント，仲介エージェント，ＤＢエージェントの３種類のエージェントによって分散的に構成する。
(2) ３種類のエージェントの基本動作は同一とし，ユーザ・エージェント，ＤＢエージェントは，それらに拡張機能を付与した構成とする。
【０１１６】
(3) 複数のエージェントを別個の計算機上で動作させることにより，負荷を分散させる。
(4) 各エージェントの内部を処理毎にプロセスに分割し，並列動作を可能にする。
【０１１７】
(5) ユーザからの要求を，ＤＢ選択のための要求と，選択したＤＢに対する要求に分割する。
(6) 仲介機構の動作を，個別ＤＢの選択と，選択したＤＢへの要求の２段階とする。
【０１１８】
(7) 複数の仲介エージェントを経由した通信により，複数の仲介エージェントの保持する条件を合わせて用いて，データベースを選択する。
(8) エージェントが，自分に与えられたタイムアウトまでの猶予時間から，自分の処理に要する時間を差し引いて，要求を転送したエージェントからの回答のタイムアウト猶予時間とすることにより，分散構成において，最初に指定された時間内に間に合わないような無駄な処理を回避する。
【０１１９】
(9) 要求に識別番号を付与することで，要求の二重処理を回避する。
(10)要求の識別番号を記録しておく時間を，そのエージェントに与えられたタイムアウト猶予時間以上とすることにより，不要な要求ＩＤを消去する。
【０１２０】
(11)ユーザ・エージェントにより，ユーザとの間の様々な入出力手順の差異を一括して吸収する。
(12)ＤＢエージェントにより，データベースとの間の様々な入出力手順の差異を一括して吸収する。
【０１２１】
(13)ユーザの設定情報の変更を，対応するユーザ・エージェントにより処理し，エージェント群全体の設定変更は不要とする。
(14)データベースの設定情報の変更を，対応するＤＢエージェントにより処理し，エージェント群全体の設定変更は不要とする。
【０１２２】
(15)全エージェントに新規エージェントやエージェントの変更を登録することなしに，個別にエージェントの追加，拡張を許す。
(16)エージェント全体をエージェント群に分割し，エージェント群毎に機密保持を可能にする。
【０１２３】
(17)特定のユーザの情報を，対応するユーザ・エージェントや，エージェント群の一部に限定して保持することにより，ユーザの機密保持を可能にする。
(18)特定のデータベースの情報を，対応するＤＢエージェントや，エージェント群の一部に限定して保持することにより，ユーザの機密保持を可能にする。
【０１２４】
以上のように構成される仲介機構の特長としては，次のような点が挙げられる。
(a) 適用分野に依存しない構成
適用分野に依存するデータは，エージェントの持つ条件表にすべて押し込められており，他の部分は適用分野に依存しない。
【０１２５】
(b) エージェントの追加，拡張が容易
全エージェントに登録する必要があるような，グローバルなデータが存在しない。そのためエージェントの追加などの拡張が容易である。
【０１２６】
(c) 一定時間内での動作が期待可能
各エージェントの動作は，条件表を引いて出力先を決定し，その出力先に入力を転送するだけなので，エージェントの動作時間が見積もりやすい。また，ループなどの要求の二重処理を禁止しているため，一定時間内での動作が期待できる。
【０１２７】
(d) 異なる機種の混在した機器構成によって対応可能
各エージェントは，通信によって情報をやりとりし，共有のデータを持たない。そのため，エージェントが動作する計算機の機種などが異なるような，ヘテロな環境でも動作させることが可能である。大規模なシステムを構成する際には，単一の機種のみで構成するのは困難である場合が多いため，異なる機種の混在を許す点は，大きな利点である。
【０１２８】
【実施例】
次に本発明の具体的な実施例について，図２３〜図２６に従って説明する。
図２３は，Ｃ１，Ｃ２，Ｃ３の３社によるエージェント構成例を示す。
【０１２９】
図２３において，Ｃｏｍｐａｎｙは会社であり，Ｃ１，Ｃ２，Ｃ３は会社名である。ｇｒｏｕｐは，会社の系列を表し，ここではＧａ企業グループとＧｂ企業グループのどちらかである。ｒｅｇｉｏｎは，会社の所在地，例えば関東地域，ｘｘ県またはｙｙ市というような地域であり，ここではＲａ地域とＲｂ地域のどちらかである。ｃｏｎｔｅｎｔは，その会社の扱っている商品分類（Ｘ，Ｙ，Ｚのどれか）であり，例えば乗用車，食料品というようなものである。
【０１３０】
会社Ｃ１は，Ｇａ企業グループに所属していて，場所はＲａ地域にある。
会社Ｃ２は，Ｇｂ企業グループに所属していて，場所はＲａ地域にある。
会社Ｃ３は，Ｇｂ企業グループに所属していて，場所はＲｂ地域にある。
【０１３１】
すなわち，会社Ｃ２と会社Ｃ３とは，同じ企業グループの仲間同士であり，会社Ｃ１と会社Ｃ２とは，同じ地域にある。
会社Ｃ１が管理するエージェントは，ユーザ・エージェントＵＡ１ａ，ＵＡ１ｂ，仲介エージェントＦＡ１ｃ，ＤＢエージェントＤＡ１ｄ，ＤＡ１ｅである。会社Ｃ１のデータベース１ｆ，１ｇは，それぞれＸのｃｏｎｔｅｎｔ，ＹとＺのｃｏｎｔｅｎｔを持つ。
【０１３２】
会社Ｃ２が管理するエージェントは，ユーザ・エージェントＵＡ２ａ，ＵＡ２ｂ，仲介エージェントＦＡ２ｃ，ＤＢエージェントＤＡ２ｄである。会社Ｃ２のデータベース２ｅは，ＸとＹとＺのｃｏｎｔｅｎｔを持つ。
【０１３３】
会社Ｃ３が管理するエージェントは，ユーザ・エージェントＵＡ３ａ，仲介エージェントＦＡ３ｂ，ＦＡ３ｃ，ＤＢエージェントＤＡ３ｄ，ＤＡ３ｅ，ＤＡ３ｆである。会社Ｃ１のデータベース３ｇ，３ｈ，３ｉは，それぞれＸのｃｏｎｔｅｎｔ，Ｙのｃｏｎｔｅｎｔ，Ｚのｃｏｎｔｅｎｔを持つ。
【０１３４】
これらのエージェントおよびデータベースは，技術的には１台の計算機で実現することも可能であるが，現実には，次のような要素が考慮される。
(1) 異なる会社で同じ計算機上にサービスを実現するのは，機密上，好ましくない。
【０１３５】
(2) ユーザ・エージェントは，負荷分散の観点からは複数用いるのが望ましい。
(3) 仲介エージェントの負荷は，あまり大きくないと予想される。
【０１３６】
(4) データベースは，通常大きなアプリケーションであるので，１台の計算機に一つのみを動作させるのが望ましい。
(5) ＤＢエージェントは，対応するデータベースの近くで動作するほうがよい。
【０１３７】
以上の点を考慮すると，図２３に示すエージェントを実装するための好ましい計算機構成は，次のようになる。
(a) ユーザ・エージェント毎に１台の計算機を割り当てる。
【０１３８】
(b) データベースごとに１台の計算機を割り当て，対応するＤＢエージェントも同じ計算機上で動作させる。
(c) 仲介エージェントは，独立に計算機を割り当てるか，ユーザ・エージェントの動作する計算機上，またはＤＢエージェントの動作する計算機上で動作させる。
【０１３９】
図２４〜図２６は，各会社Ｃ１，Ｃ２，Ｃ３の各エージェントが持つ条件表の例を示している。条件で“＊”とあるのは，どのような条件（あるいは値）の場合にも，対応する出力先に要求を回送することを表す。また，ＤＢエージェントの条件表で，出力先が自分自身になっているのは，自分の管理下にあるデータベースにアクセスすることを示す。
【０１４０】
会社Ｃ１のユーザ・エージェントＵＡ１ａは，図２４（Ａ）に示すような条件表を持つ。ユーザ・エージェントＵＡ１ａは，どのような条件の要求に対しても，仲介エージェントＦＡ１ｃに要求を転送する。会社Ｃ１のユーザ・エージェントＵＡ１ｂの条件表も同様である（図２４（Ｂ））。
【０１４１】
会社Ｃ１の仲介エージェントＦＡ１ｃは，図２４（Ｃ）に示すような条件表を持つ。要求での指定が会社Ｃ１，グループＧａまたは地域Ｒａのいずれかであり，かつ商品分類がＸであれば，要求の出力先をＤＢエージェントＤＡ１ｄとする。要求での指定が会社Ｃ１，グループＧａまたは地域Ｒａのいずれかであり，かつ商品分類がＹまたはＺであれば，要求の出力先をＤＢエージェントＤＡ１ｅとする。
【０１４２】
また，要求での指定が会社Ｃ２，グループＧｂまたは地域Ｒａのいずれかであれば，要求の出力先を会社Ｃ２の仲介エージェントＦＡ２ｃとする。要求での指定が会社Ｃ３，グループＧｂまたは地域Ｒｂのいずれかであれば，要求の出力先を会社Ｃ３の仲介エージェントＦＡ３ｂとする。
【０１４３】
会社Ｃ１のＤＢエージェントＤＡ１ｄは，図２４（Ｄ）に示すような条件表を持つ。ＤＢエージェントＤＡ１ｄは，どのような条件の要求に対しても，出力先が自分自身であるので，データベース１ｆを対象とする処理を行い，結果を要求元へ返送する。会社Ｃ１のＤＢエージェントＤＡ１ｅの条件表も同様である（図２４（Ｅ））。
【０１４４】
会社Ｃ２のユーザ・エージェントＵＡ２ａは，図２５（Ａ）に示すような条件表を持つ。ユーザ・エージェントＵＡ２ａは，どのような条件の要求に対しても，仲介エージェントＦＡ２ｃに要求を転送する。会社Ｃ２のユーザ・エージェントＵＡ２ｂの条件表も同様である（図２５（Ｂ））。
【０１４５】
会社Ｃ２の仲介エージェントＦＡ２ｃは，図２５（Ｃ）に示すような条件表を持つ。要求での指定が会社Ｃ１，グループＧａまたは地域Ｒａのいずれかの場合，要求の出力先を仲介エージェントＦＡ１ｃとする。要求での指定が会社Ｃ２，グループＧｂまたは地域Ｒａのいずれかであれば，要求の出力先を自会社Ｃ２のＤＢエージェントＤＡ２ｄとする。要求での指定が会社Ｃ３，グループＧｂまたは地域Ｒｂのいずれかであれば，要求の出力先を会社Ｃ３の仲介エージェントＦＡ３ｂとする。
【０１４６】
会社Ｃ２のＤＢエージェントＤＡ２ｄは，図２５（Ｄ）に示すような条件表を持つ。ＤＢエージェントＤＡ２ｄは，どのような条件の要求に対しても，出力先が自分自身であるので，データベース２ｅを対象とする処理を行い，結果を要求元へ返送する。
【０１４７】
会社Ｃ３のユーザ・エージェントＵＡ３ａは，図２６（Ａ）に示すような条件表を持つ。ユーザ・エージェントＵＡ３ａは，要求での指定が会社Ｃ３でないか，地域Ｒａの場合に，仲介エージェントＦＡ３ｂに要求を転送する。また，要求での指定が会社Ｃ３であるか，グループＧｂであるか，または地域Ｒｂである場合に，仲介エージェントＦＡ３ｃに要求を転送する。
【０１４８】
会社Ｃ３の仲介エージェントＦＡ３ｂは，図２６（Ｂ）に示すような条件表を持つ。要求での指定が会社Ｃ１，グループＧａまたは地域Ｒａのいずれかであれば，要求の出力先を仲介エージェントＦＡ１ｃとする。要求での指定が会社Ｃ２，グループＧｂまたは地域Ｒａのいずれかであれば，要求の出力先を会社Ｃ２の仲介エージェントＦＡ２ｃとする。また，要求での指定が会社Ｃ３，グループＧｂまたは地域Ｒｂのいずれかであれば，要求の出力先を会社Ｃ３の仲介エージェントＦＡ３ｃとする。
【０１４９】
会社Ｃ３の仲介エージェントＦＡ３ｃは，図２６（Ｃ）に示すような条件表を持つ。仲介エージェントＦＡ３ｃは，要求された商品分類Ｘ，Ｙ，Ｚに応じて，それぞれ要求の出力先を，ＤＢエージェントＤＡ３ｄ，ＤＡ３ｅ，ＤＡ３ｆとする。
【０１５０】
会社Ｃ３のＤＢエージェントＤＡ３ｄ，ＤＡ３ｅ，ＤＡ３ｆは，それぞれ図２６（Ｄ），（Ｅ），（Ｆ）に示すような条件表を持つ。これらは，どのような条件の要求に対しても，出力先が自分自身であるので，それぞれデータベース３ｇ，３ｈ，３ｉを対象とする処理を行い，結果を要求元へ返送する。
【０１５１】
次に，(1) 会社名を直接指定する場合，(2) 会社のブランドを優先する場合など，企業グループのみを対象とする場合，(3) 近くにある会社から購入したい場合など，特定の地域にある会社を対象とする場合を想定し，それぞれについて，順に上記の条件を使った要求の回送例を説明する。
【０１５２】
(1) 会社名を直接指定する場合の要求の回送例
例えばユーザ・エージェントＵＡ１ａに接続しているユーザが，「company = C1 and content = X」というＤＢ選択要求を発行したとする。
【０１５３】
この要求は，まず図２４（Ａ）に示す条件表によって，仲介エージェントＦＡ１ｃへ回送され，次に図２４（Ｃ）に示す条件表によって，ＤＢエージェントＤＡ１ｄへ回送される。結果として，データベース１ｆが選択される。
【０１５４】
(2) 企業グループのみを対象とする場合の回送例
例えばユーザ・エージェントＵＡ２ａに接続しているユーザが，「group = Gb and content = Y」というＤＢ選択要求を発行したとする。
【０１５５】
この要求は，まず図２５（Ａ）に示す条件表によって，仲介エージェントＦＡ２ｃへ回送され，次に図２５（Ｃ）に示す条件表によって，ＤＢエージェントＤＡ２ｄと会社Ｃ３の仲介エージェントＦＡ３ｂへ回送される。仲介エージェントＦＡ３ｂからは，図２６（Ｂ）に示す条件表によって，仲介エージェントＦＡ２ｃと仲介エージェントＦＡ３ｃへ回送される。このうち仲介エージェントＦＡ２ｃへ回送された要求は，二重要求チェックにより廃棄される。
【０１５６】
さらに，仲介エージェントＦＡ３ｃから図２６（Ｃ）に示す条件表によって，ＤＢエージェントＤＡ３ｅへ回送され，結果として，会社Ｃ２のデータベース２ｅと会社Ｃ３のデータベース３ｈが選択される。
【０１５７】
(3) 特定の地域にある会社を対象とする場合の回送例
例えばユーザ・エージェントＵＡ３ａに接続しているユーザが，「region = Ra and content = Z 」というＤＢ選択要求を発行したとする。
【０１５８】
この要求は，まず図２６（Ａ）に示す条件表によって，仲介エージェントＦＡ３ｂへ回送され，次に図２６（Ｂ）に示す条件表によって，仲介エージェントＦＡ１ｃと仲介エージェントＦＡ２ｃへ回送される。仲介エージェントＦＡ１ｃからは，図２４（Ｃ）に示す条件表によって，ＤＢエージェントＤＡ１ｅへ回送され，仲介エージェントＦＡ２ｃからは，図２５（Ｃ）に示す条件表によって，ＤＢエージェントＤＡ２ｄへ回送される。結果として，会社Ｃ１のデータベース１ｇと会社Ｃ２のデータベース２ｅが選択される。
【０１５９】
以上のように，要求で指定された条件によって，該当するデータベースが自動的に選択される。なお，条件表への条件として，例えばユーザの識別情報やパスワードや回送元の情報などの条件を登録することも可能であり，会社間での各種条件による機密保護を条件表によって実現することも可能である。
【０１６０】
【発明の効果】
以上説明したように，本発明によれば，従来の集中構成の仲介機構と比較して，以下のような効果が得られる。
【０１６１】
(1) 動作時の負荷の分散が可能である。
個々のエージェントを別々の計算機上で動作させることにより，仲介作業の負荷を分散できるため，ユーザから見た場合に，待ち時間の少ない迅速な回答が期待できる。
【０１６２】
(2) 運用管理コストの分散が可能なスケーラブルな構成を実現できる。
ユーザ，データベースを登録するような運用形態でも，登録が必要なのは，特定のユーザ・エージェントやＤＢエージェントであるため，システム全体に対して設定変更などの作業をする必要はない。また，入出力形式が変更，削除，追加される場合にも，特定のユーザ・エージェント，ＤＢエージェントの変更や，削除，追加で対応可能であり，これもシステム全体に対して設定変更などの作業をする必要はない。したがって，ユーザ数やデータベース数の増加にも容易に対応できるような，スケーラブルな構成を実現できる。
【０１６３】
(3) 情報の機密を保持可能である。
本機構では情報をどこかに集めて管理するようなことは行わないため，機密が必要な単位でエージェント群を分割すれば，その情報が外部に漏れることはなく，機密を保持できる。
【図面の簡単な説明】
【図１】本発明の原理説明図である。
【図２】本発明の実施の形態におけるシステム構成の例を示す図である。
【図３】本実施の形態で対象とするユーザからの要求形式の例を示す図である。
【図４】エージェントの持つ条件表の構成例を示す図である。
【図５】仲介機構の動作例を説明するための図である。
【図６】仲介機構の動作例を説明するための図である。
【図７】ユーザ・エージェントのモジュール構成図である。
【図８】仲介エージェントのモジュール構成図である。
【図９】ＤＢエージェントのモジュール構成図である。
【図１０】ユーザ・エージェントの入力受付部およびＤＢエージェントの入力受付部の処理フローチャートである。
【図１１】ユーザ・エージェントの入力処理部の処理フローチャートである。
【図１２】ユーザ・エージェントの個別要求処理ルーチンの処理フローチャートである。
【図１３】ＤＢ選択要求処理ルーチンの処理フローチャートである。
【図１４】回答待ちルーチンの処理フローチャートである。
【図１５】ユーザ・エージェントのＤＢ操作要求処理ルーチンの処理フローチャートである。
【図１６】ユーザ・エージェントのＤＢ群記録部の処理フローチャートである。
【図１７】条件部の処理フローチャートである。
【図１８】要求ＩＤ記録部の処理フローチャートである。
【図１９】仲介エージェントの入力受付部の処理フローチャートである。
【図２０】仲介エージェントの入力処理部の処理フローチャートである。
【図２１】ＤＢエージェントの入力処理部の処理フローチャートである。
【図２２】ＤＢエージェントのＤＢインターフェイス部の処理フローチャートである。
【図２３】本発明の実施例におけるエージェント構成例を示す図である。
【図２４】会社Ｃ１の各エージェントが持つ条件表の例を示す図である。
【図２５】会社Ｃ２の各エージェントが持つ条件表の例を示す図である。
【図２６】会社Ｃ３の各エージェントが持つ条件表の例を示す図である。
【図２７】本発明が対象とする仲介機構に求められる機能の説明図である。
【図２８】集中構成による仲介機構の説明図である。
【符号の説明】
１１〜１３ ユーザ
２１〜２４ ユーザ・エージェント
３１〜３８ 仲介エージェント
４１〜４４ データベース・エージェント
５１〜５４ データベース

Claims (10)

1. ユーザからの検索要求を受信する複数のユーザ・エージェントと，
   複数のデータベースの各々に対応した複数のデータベース・エージェントと，
   ユーザ・エージェントとデータベース・エージェントとの仲介を行う複数の仲介エージェントとを有し，
   前記ユーザ・エージェントの各々，前記データベース・エージェントの各々，前記仲介エージェントの各々は，それぞれ，条件に対応した出力先のエージェントを記憶した記憶手段を有し，該記憶手段の記憶内容に基づく転送処理を行い，
   ユーザより前記ユーザ・エージェントに対する検索要求があると，該ユーザ・エージェントは対応する記憶手段の記憶内容に基づき，前記仲介エージェントのいずれかへデータベース選択要求の転送を行い，
   前記仲介エージェントは，各々，前記ユーザ・エージェントまたは前記仲介エージェントのいずれかからデータベース選択要求を受信した場合，該仲介エージェントが有する記憶手段の記憶内容に基づき，前記仲介エージェントまたは前記データベース・エージェントのいずれかへデータベース選択要求を転送し，
   前記データベース・エージェントは，データベース選択要求を受信すると，該データベース・エージェントが有する記憶手段の記憶内容に基づき，前記仲介エージェントのいずれかへ選択結果の転送を行い，
   さらに前記各仲介エージェントは，前記データベース・エージェントまたは前記仲介エージェントのいずれかから選択結果を受信すると，該仲介エージェントが有する記憶手段の記憶内容に基づき，前記仲介エージェントまたは前記ユーザ・エージェントへの転送処理を行い，
   前記ユーザ・エージェントは，さらに，選択結果を受信すると，該選択結果に基づき選択された前記データベース・エージェントへ，直接ユーザより受信した検索要求を送信する
   ことを特徴とするデータベース・システム。
2. 請求項１記載のデータベース・システムにおいて，
   前記ユーザ・エージェント，前記仲介エージェントおよび前記データベース・エージェントを含む複数のエージェントを，エージェントの数と同じまたはエージェントの数より少ない複数の計算機上に配置し，
   複数のエージェントを別個の計算機上で動作させることにより，負荷を分散させるようにした
   ことを特徴とするデータベース・システム。
3. 請求項１記載のデータベース・システムにおいて，
   前記ユーザ・エージェント，前記仲介エージェントおよび前記データベース・エージェントの各エージェントの内部を処理毎にプロセスに分割し，
   各エージェントにおける処理の並列動作を可能にした
   ことを特徴とするデータベース・システム。
4. 請求項１記載のデータベース・システムにおいて，
   前記各エージェントは，自分に与えられたタイムアウトまでの猶予時間から，自分の処理に要する時間を差し引いて，要求を転送したエージェントからの回答のタイムアウト猶予時間とし，タイムアウトを処理する手段を持つ
   ことを特徴とするデータベース・システム。
5. 請求項１記載のデータベース・システムにおいて，
   前記ユーザ・エージェントは，要求に識別番号を付与する手段を持ち，
   前記仲介エージェントおよび前記データベース・エージェントは，要求の識別番号を検査することにより異なる経路で伝達された同じ要求の二重処理を回避する手段を持つ
   ことを特徴とするデータベース・システム。
6. 請求項５記載のデータベース・システムにおいて，
   前記各エージェントは，自エージェントにおいて前記要求の識別番号を記録しておく時間を，そのエージェントに与えられたタイムアウト猶予時間以上とし，かつタイムアウト猶予時間が過ぎた要求の識別番号を消去する手段を持つ
   ことを特徴とするデータベース・システム。
7. 請求項１記載のデータベース・システムにおいて，
   前記ユーザ・エージェントは，ユーザからの要求を所定の内部形式のデータに変換する手段を持ち，
   ユーザとの間の様々な入出力手順の差異を一括して吸収するようにした
   ことを特徴とするデータベース・システム。
8. 請求項１記載のデータベース・システムにおいて，
   前記データベース・エージェントは，内部形式で表されたデータベースに対する要求を，データベースに対応して定められる要求形式に変換する手段と，データベースからのアクセス結果を所定の内部形式のデータに変換する手段とを持ち，
   各データベースとの間の様々な入出力手順の差異を一括して吸収するようにした
   ことを特徴とするデータベース・システム。
9. 請求項１記載のデータベース・システムにおいて，
   特定のユーザの情報を，対応するユーザ・エージェントまたはエージェント群の一部に限定して保持することにより，
   ユーザの機密保持を可能にした
   ことを特徴とするデータベース・システム。
10. 請求項１記載のデータベース・システムにおいて，
    特定のデータベースの情報を，対応するデータベース・エージェントまたはエージェント群の一部に限定して保持することにより，ユーザの機密保持を可能にした
    ことを特徴とするデータベース・システム。

Images