JP2005032150A - Ｗｅｂサービス提供サーバ、その方法及びプログラム - Google Patents

Abstract

【課題】 ディレクトリサーバへのアクセスによるボトルネック、及び端末のアクセスでのオーバーヘッドを低減し、ディレクトリサービスの処理能力を向上するＷｅｂサービス提供システムを提供する。
【解決手段】 本発明のWebサービス提供サーバはディレクトリサーバへアクセスし、検索条件に対応したWebサービスのディレクトリ情報を取得するWebサービス提供サーバであり、検索条件と、検索条件で検索されたディレクトリ情報との対応を示すキャッシュテーブルを有する記憶部と、検索条件をテーブルで検索し、一致する検索条件がある場合、検索条件に対応するディレクトリ情報を出力し、一致する検索条件が無い場合、ディレクトリサーバで検索する検索処理制御部とを有し、検索処理制御部が、ディレクトリサーバから得られたディレクトリ情報を、検索条件に対応してテーブルに書き込むことを特徴とする。
【選択図】 図１

Description

本発明は、クライアントがディレクトリサービス・サーバ（以下、ディレクトリサーバ）にサービスのＵＲＬ等の検索を依頼し、この検索結果によりサービスを利用するＷｅｂ（インターネット上において情報をハイパーテキスト形式で表した分散データベースシステム；ワールドワイドウェブ）サービス提供システムに関するものである。

Ｗｅｂサービスを提供する方法においては、ディレクトリサービスを利用したシステムを用いて、ネットワーク資源の管理、すなわち、Ｗｅｂを介した各種サービスの検索，登録及び抹消などの管理が行われている。
ここで、図１２に示すように、サービスプロバイダＡ，Ｂ，Ｃなどは、提供するサービスをディレクトリサーバに登録するとき、また提供を停止するサービスをディレクトリサーバから抹消するとき、ディレクトリサーバにアクセスして登録及び抹消の処理を要求する。
また、同様に、クライアント（末端ユーザの端末）などは、利用したいサービスを行っているサービスプロバイダのＵＲＬや、インターネットショッピングにおいて希望する金額の商品を扱っているネット上のショップのＵＲＬの検索を行う（特許文献１）。

さらに、最近は、ディレクトリサービスにおける検索の精度を高めるため、ディレクトリサーバを利用して、クライアントからの検索要求に対して、複数のサービスプロバイダを連携させた検索サービスを行うシステムも使用されている。
すなわち、図１３に示すように、Ｗｅｂサービスにおけるネットワーク管理にモバイルエージェントの技術を用いて、サーバ（例えば、サービスプロバイダＡ，Ｂ，Ｃ）間をエージェントが自律的に移動し、クライアントから要求された情報の収集を、移動先のサーバにより順次、または並列に行うことにより、大規模な検索サービスが実現できる。
特開２００３−０９９４５３号公報

しかしながら、上述した従来のＷｅｂサービス提供方法は、サービスの登録／抹消やサービスの検索により、ディレクトリサービスへの負荷が集中し、多重クライアントがサービスを利用する際に、ディレクトリサーバへのアクセスが性能的なボトルネックとなり、全体のスループットが悪化するという問題がある。

また、Ｗｅｂサービス提供方法は、モバイルエージェントを用いることにより、大規模な検索が可能となるが、各クライアント上に複数のサービス要求クライアントが存在し、次の異動先を検索するクライアントも加わり、同じ端末からディレクトリサーバへのアクセスがモバイルエージェントを使用しない場合に比較して大幅に増加し、クライアント及びディレクトリサーバの双方の回線使用率が上昇する。
これにより、モバイルエージェントを用いたＷｅｂサービス提供は、ディレクトリサーバに性能的なボトルネックが発生し、端末にアクセスにおけるオーバーヘッドがかかり、相互の処理能力を低下させる欠点がある。

また、図１４に示すＷｅｂプロキシ（プロキシサーバ）におけるキャッシュ技術のように、クライアントがＷｅｂサーバに対してアクセスして取得したサービス情報（ディレクトリ情報も含まれる）を、Ｗｅｂプロキシの記憶部に指定時間内においてキャッシュするものがある。
これにより、クライアントはＷｅｂプロキシにキャッシュされているサービスであれば、検索の度に、一々Ｗｅｂサーバにアクセスすることなく、所望のサービス情報を取得（コンテンツ閲覧）することが可能である。
しかしながら、Ｗｅｂプロキシの記憶部にキャッシュされたサービスが更新されないため、クライアントはいつの時点のサービスの情報を見ているのか不明であり、場合によっては最新情報が得られないという欠点がある。

本発明はこのような事情に鑑みてなされたもので、ディレクトリサーバへのアクセスによるボトルネック、及び端末のアクセスにおけるオーバーヘッドを低減させることで、ディレクトリサービスの処理能力を向上させ、かつ常に最新のディレクトリ情報を取得することができるＷｅｂサービス提供システムを提供することを目的とする。

上記目的を達成するために、本発明のＷｅｂサービス提供サーバは、ディレクトリサーバへアクセスし、検索条件に対応したＷｅｂサービスのディレクトリ情報を取得するＷｅｂサービス提供サーバであり、検索条件と、この検索条件により検索されたディレクトリ情報との対応を示すキャッシュテーブルが記憶されている記憶部と、入力される検索条件を前記テーブルにより検索し、一致する検索条件がある場合、この検索条件に対応するディレクトリ情報を検索結果として出力し、一致する検索条件が無い場合、ディレクトリサーバにアクセスして検索を行う検索処理制御部とを有し、前記検索処理制御部が、ディレクトリサーバにアクセスして得られたディレクトリ情報を、検索に用いた検索条件に対応して前記テーブルに書き込むことを特徴とする。

本発明のＷｅｂサービス提供サーバは、所定の時間間隔毎に、前記ディレクトリサーバにアクセスし、前記テーブルにおける検索条件に対応するディレクトリ情報を取得して、テーブルのディレクトリ情報を更新するリフレッシュ部を有することを特徴とする。

本発明のＷｅｂサービス提供サーバは、前記検索処理制御部が、前記テーブルにおいて、各ディレクトリ情報が読み出される毎に、このディレクトリ情報に対応して読み出された読出時間を書き込み、新たな検索条件及びディレクトリ情報を書き込むとき、現在時刻と読出時間との差が最も大きい検索条件を検出し、この検出された検索条件と新たな検索条件とを入れ替えることを特徴とする。

本発明のＷｅｂサービス提供サーバは、前記テーブルが、前記ディレクトリ情報と読出時間とが対応して示されたディレクトリテーブルと、検索条件とこの検索条件に対応したディレクトリ情報とが対応して示された検索テーブルとから構成され、各々独立してアクセスされることを特徴とする。

本発明のＷｅｂサービス提供サーバは、前記リフレッシュ部が、ディレクトリ情報の更新を行うとき、各ディレクトリ情報の示すサービスの動作の有無を検出し、動作していないサービスを検出した場合、このサービスに対応するディレクトリ情報を読み出し不可とすることを特徴とする。

本発明のＷｅｂサービス提供サーバは、ディレクトリサーバへアクセスし、検索条件に対応したＷｅｂサービスのディレクトリ情報を取得するＷｅｂサービス提供方法であり、検索条件と、この検索条件により検索されたディレクトリ情報との対応を示すキャッシュテーブルを記憶部に記憶する記憶過程と、入力される検索条件を前記テーブルにより検索し、一致する検索条件がある場合、この検索条件に対応するディレクトリ情報を検索結果として出力し、一致する検索条件が無い場合、ディレクトリサーバにアクセスして検索を行う検索処理制御過程とを有し、前記検索処理制過程において、ディレクトリサーバにアクセスして得られたディレクトリ情報を、検索に用いた検索条件に対応して前記テーブルに書き込むことを特徴とする。

本発明のＷｅｂサービス提供プログラムは、ディレクトリサーバへアクセスし、検索条件に対応したＷｅｂサービスのディレクトリ情報を取得するＷｅｂサービス提供をコンピュータに実行させるプログラムであり、検索条件と、この検索条件により検索されたディレクトリ情報との対応を示すキャッシュテーブルを記憶部に記憶する記憶処理と、入力される検索条件を前記テーブルにより検索し、一致する検索条件がある場合、この検索条件に対応するディレクトリ情報を検索結果として出力し、一致する検索条件が無い場合、ディレクトリサーバにアクセスして検索を行う検索制御処理とを有し、前記検索制御処理において、ディレクトリサーバにアクセスして得られたディレクトリ情報を、検索に用いた検索条件に対応して前記テーブルに書き込むことを特徴とするコンピュータが実行可能なプログラムである。

以上説明したように、本発明によるＷｅｂサービス提供サーバによれば、下記の効果を得ることができる。
本発明のＷｅｂサービス提供サーバは、キャッシュ部にディレクトリ情報をキャッシュするので、ディレクトリサーバへのアクセスを大幅に削減することが可能となり、全体のスループットを向上させ、検索処理の性能を向上させることができ、キャッシュ部が一定間隔により記憶内容を更新処理するため、常に検索条件に対応する最新のディレクトリ情報を得ることが可能である。

また、本発明のＷｅｂサービス提供サーバは、モバイルエージェントの技術を用いた場合にも、クライアントからディレクトリサーバに対するアクセスを大幅に低減させることができるので、ディレクトリサーバにおけるスループットを向上し、かつクライアント側のアクセス増加によるオーバーヘッドを防止することができ、クライアント側の処理能力を向上させることが可能で流ある。

さらに、本発明のＷｅｂサービス提供サーバは、キャッシュ部が、検索情報とディレクトリ情報テーブルとを対応付けるキャッシュテーブルと、ディレクトリ情報と最終検索時間とを対応付けたディレクトリ情報テーブルとの２つに分離して構成されており、ディレクトリ情報を更新するためにディレクトリ情報テーブルをロックしている間も、キャッシュテーブルにより他のディレクトリ情報テーブルの検索を行うことができ、キャッシュ部全体がロックされ、更新処理の間に検索処理が行え無くなる不都合を防止する。

以下、本発明の一実施形態によるＷｅｂサービス提供サーバを、図面を参照して説明する。図１は、一実施形態によるＷｅｂサービス提供サーバを用いたＷｅｂ検索システムの構成例を示すブロック図である。
図１において、Ｗｅｂサービス提供サーバ１は、検索要求が入力されると、サービスを検索するための検索条件に対応するディレクトリ情報、すなわち、サービスオブジェクト（サービスを行っているサービスプロバイダのサーバのＵＲＬ，またはＪＡＶＡ（登録商標）のスタブ等）を出力する。
また、Ｗｅｂサービス提供サーバ１は、ディレクトリサーバ２，サービスサーバ４，５，６等とネットワーク７を介して接続されている。
ここで、ネットワーク７は、公衆通信回線，専用通信回線，インターネット及びＬＡＮ（ローカルエリアネットワーク）等の組み合わせにより構成されたものである。

Ｗｅｂサービス提供サーバ１は、キャッシュ制御部１ａ，キャッシュ部１ｂ，リフレッシュ部１ｃ及び強制リフレッシュ部１ｄから構成されている。
このＷｅｂサービス提供サーバ１は、図１２に示すクライアントのサーバである場合もあり、図１２及び図１３に示すサービスプロバイダＡ，Ｂ，Ｃのサーバである場合もあり、さらにネットワーク間の接続ノード、例えばルータ等に上記構成を設ける場合もある。

以下の説明では、サービスプロバイダのサーバとして説明する。
キャッシュ部１ｂには、図２に示すように、複数の各検索条件に対応して最終検索時刻とサービスオブジェクトとが示されているテーブルが記憶されている。
キャッシュ制御部１ａは、入力された検索条件により、検索クエリを生成し、上記キャッシュ部１ｂのテーブルからこの検索条件と一致する検索条件を検索し、一致する検索条件を検出すると、このテーブルにおいて検出された検索条件に対応するサービスオブジェクトを、このテーブルから読み出して出力する。

また、キャッシュ制御部１ａは、上記テーブルにおいて、入力された検索条件と一致する検索条件が検出されない場合、ディレクトリサーバ２へアクセスして、検索条件に対応したサービスオブジェクトの検索を要求する。
ディレクトリサーバ２は、各サービスプロバイダＡ，Ｂ，Ｃにより登録されたサービスの検索を行い、すなわち、登録されたサービスが検索キーに対応して、内部のディレクトリ記憶部にディレクトリ情報として記憶されており、入力される検索条件を検索キーとして、ディレクトリ記憶部から、検索キーに対応するサービスのディレクトリ情報を抽出し、検索要求したＷｅｂサービス提供サーバへ出力する。

リフレッシュ部１ｃは、所定の時間毎、例えば、１週間毎に、キャッシュ部１ｂに記憶されたテーブルにおけるディレクトリ情報のリフレッシュ処理を行う。
すなわち、リフレッシュ部１ｃは、ディレクトリサーバ２へアクセスし、上記テーブルに記憶されている検索条件により、デイレクトリサーバ２のディレクトリ記憶部に記憶されている最新のディレクトリ情報を取得し、テーブルに記憶されているディレクトリ情報を更新する。

また、強制リフレッシュ部１ｄは、Ｗｅｂサービス提供サーバ１に入力されるリフレッシュ要求を検出すると、このリフレッシュ要求を検出した時点で、上述したリフレッシュ部１ｃが行うリフレッシュ動作と同様な処理を行う。
この図１におけるサービスサーバ４，５，６は、所定のサービス（商品売買、製品紹介、技術紹介、交通情報等）をクライアントに提供する。

次に、図１及び図３を参照して、後に示すフローチャートを用いて、本発明の一実施形態であるＷｅｂサービス提供サーバ１の動作例を説明する。図３は上記Ｗｅｂサービス提供サーバ１の動作を説明する概念図である。
キャッシュ制御部１ａの動作について、図４のフローチャートを用いて説明する。
ステップＳ１において、キャッシュ制御部１ａは、検索要求及び検索条件が入力されたことを検出した場合、処理をステップＳ２へ進め、入力されない場合、処理をステップＳ１に戻す処理を行う。

次に、ステップＳ２において、キャッシュ制御部１ａは、キャッシュ部１ｂを検索して、入力された検索条件と一致する検索条件の有無を検出（図２における参照）する。
そして、キャッシュ制御部１ａは、一致した検索条件を検出した場合、処理をステップＳ３へ進める。
次に、ステップＳ３において、キャッシュ制御部１ａは、検出した検索条件に対応するディレクトリ情報を、キャッシュ部１ｂから読み出し、処理をステップＳ４へ進める。
そして、ステップＳ４において、キャッシュ制御部１ａは、最終検索時刻を現在時刻に更新し、処理をステップＳ５へ進める。

一方、ステップＳ２において、キャッシュ制御部１ａは、一致した検索条件がキャッシュ部１ｂにキャッシュ（一時記憶）されていないことを検出した場合、処理をステップＳ６へ進める。
次に、ステップＳ６において、キャッシュ制御部１ａは、ディレクトリサーバ２へアクセスして、検索要求及び検索条件を出力し、この検索条件に対応するディレクトリ情報を取得し、処理をステップＳ７へ進める。

そして、ステップＳ７において、キャッシュ制御部１ａは、キャッシュ部１ｂが、検索条件と、この検索条件により新たに取得したディレクトリ情報との合計容量を記憶させることが可能か否かの検出を行う。
すなわち、キャッシュ制御部１ａは、現在のキャッシュ部１ｂの残りの記憶容量が、上記合計容量より小さいか否かの判定を行う（または残りの記憶容量と合計容量との加算値がキャッシュ容量を超えるかいなかの検出を行ってもよい）。

そして、キャッシュ制御部１ａは、上記残りの記憶容量が合計容量より小さくないことを検出した場合（または残りの記憶容量と合計容量との加算値がキャッシュ容量を超えない場合）、処理をステップＳ９へ進める。
一方、キャッシュ制御部１ａは、残りの記憶容量が合計容量より小さいことを検出した場合（または残りの記憶容量と合計容量との加算値がキャッシュ容量を超える場合）、処理をステップＳ８へ進める。

次に、ステップＳ８において、キャッシュ制御部１ａは、キャッシュ部１ｂ内において、最終検索時刻が最も古い時刻の検索条件を検索し、この検索条件及びこの検索条件に対応するディレクトリ情報を削除し、検索条件及びこの検索条件により検索されたディレクトリ情報を、新たに記憶させることが可能な空き容量を作成し、ステップＳ９へ進める。
そして、ステップＳ９において、キャッシュ制御部１ａは、新たに、検索条件及びこの検索条件により検索されたディレクトリ情報を対応させて、キャッシュ部１ｂのテーブルに記憶させ、処理をステップＳ４へ進める。
次に、キャッシュ制御部１ａは、検索されたディレクトリ情報を、検索要求を行った要求元へ出力して、ステップＳ１へ処理を戻す。

上述した図において、キャッシュ部１ｂに対する検索及び内容更新の処理について以下に、詳細に説明する。
ここで、キャッシュ部１ｂは、図５に示すキャッシュテーブルと、ディレクトリ情報テーブルとの２つのテーブルから構成されている。
上記キャッシュテーブル（Ｍテーブル）は、インデックスとして、検索情報を示す検索クエリ（Query）と、ディレクトリ情報（ServiceObject：サービスオブジェクト）テーブルの参照アドレス（ServicePointer）との対応を示すテーブルである。
また、ディレクトリ情報テーブルは、検索情報毎に対応して設けられ、検索情報に基づき検索された１つまたは複数の情報元のディレクトリ情報と、この検索情報が最後に検索された最終検索時刻（LastUpdateTime）とが対応付けられて記憶されている。

次に、図６のフローチャートを参照して、図４のステップＳ３の詳細な動作説明を行う。
ステップＳ３１において、キャッシュ制御部１ａは、検索情報がキャッシュテーブル（以下、Ｍテーブル）に記憶されていることを検出すると、検索処理を行う検索メソッドが記載されたプログラムをコール（起動）して、ディレクトリ情報の取得処理を開始する。
次に、ステップＳ３２において、キャッシュ制御部１ａは、Ｍテーブルにおいて、検索クエリをインデックスとして、検索情報に対応する参照アドレスを取得する。

これにより、ステップＳ３３において、キャッシュ制御部１ａは、取得した参照アドレスの示すディレクトリ情報テーブル（stオブジェクト）をロック（他の検索メソッドからのアクセスを排他制御する）し、最終検索時間を現在時間に書き換えて更新し、この更新の後ロックを解除する。
次に、ステップＳ３４において、キャッシュ制御部１ａは、ディレクトリ情報テーブルからディレクトリ情報（例えば、複数のサービスプロバイダのＵＲＬs1，s2，s3）を取得して、検索要求した要求元に取得したディレクトリ情報を出力する。

次に、図７のフローチャートを参照して、図１のステップＳ９の動作を詳細に説明する。
ステップＳ９１において、キャッシュ制御部１ａは、検索クエリと、この検索クエリに対応してディレクトリサーバ２において検索されたディレクトリ情報とを、キャッシュ部１ｂにおけるＭテーブル及びディレクトリ情報テーブルに記憶させるため、更新メソッドのプログラムをコールして実行する。
そして、ステップＳ９２において、キャッシュ制御部１ａは、新たなディレクトリ情報テーブルを作成し、このディレクトリ情報テーブルをロックして、ディレクトリ情報と最終検索時刻とを書き込む。

そして、キャッシュ制御部１ａは、ディレクトリ情報テーブルへの書き込み処理が終了した後、ロックを解除して、このディレクトリ情報テーブルの参照アドレスを出力して、処理をステップＳ９３へ進める。
次に、ステップＳ９３において、キャッシュ制御部１ａは、Ｍテーブルをロックして、ディレクトリ情報の検索に用いた検索クエリと、このディレクトリ情報が書き込まれたディレクトリ情報テーブルの上記参照アドレスとを対応させて、このＭテーブルに書き込んだ後、Ｍテーブルに対するロックを解除する。

次に、リフレッシュ部１ｃのキャッシュ部１ｂに対するリフレッシュ動作を、図８のフローチャートを参照して説明する。
ステップＳ１１において、リフレッシュ部１ｃは、所定のウェイト時間が経過するまで、リフレッシュ動作を行わず、ウェイト時間が経過した後、処理をステップＳ１２へ進める。

次に、ステップＳ１２において、リフレッシュ部１ｃは、キャッシュ部１ｃのＭテーブルから検索情報を１つ取り出す。
そして、ステップＳ１３において、リフレッシュ部１ｃは、ディレクトリサーバ２へアクセスし、検索要求を行い、上記検索情報に対応する、最新のディレクトリ情報を取得する。

これにより、ステップＳ１４において、リフレッシュ部１ｃは、pingサービス処理を行い、取得したディレクトリ情報の示すサービス提供先にアクセスして、各サービスが生きているか否か（サービスを提供しているか否か）を検出する。
このとき、リフレッシュ部１ｃは、pingサービス処理において、サービス提供を停止しているサービス元（サービスサーバ）のディレクトリ情報を、ディレクトリ情報テーブルにおいて、参照できない状態とする。
また、リフレッシュ部１ｃは、強制リフレッシュ部１ｄからリフレッシュ要求が入力されると、ステップＳ１１におけるウェイト時間内であっても、この待機処理を解除し、ステップＳ１２へ処理を進め、リフレッシュ動作を開始する。

次に、ステップＳ１５において、リフレッシュ部１ｃは、検索した検索情報に対応して、キャッシュ部１ｂ（ディレクトリ情報テーブル）のディレクトリ情報を最新のデータに更新する。
そして、ステップＳ１６において、リフレッシュ部１ｃは、所定のウェイト調整時間の間、処理をホールドし、ウェイト調整時間が経過した後、処理をステップＳ１７へ進める。
ここで、ウェイト調整時間は、Ｗｅｂサービス提供システムの動作において、必要に応じて時間が調整される。

次に、ステップＳ１７において、リフレッシュ部１ｃは、Ｍテーブルの全検索情報に対してリフレッシュ処理、すなわち更新処理が終了したか否かの検出を行い、終了したことを検出した場合、処理をステップＳ１１へ進め、処理が終了していないことを検出した場合、処理をステップＳ１２へ進める。

次に、図８のフローチャートにおけるステップＳ１５のディレクトリ情報の更新処理を、図９のフローチャートを参照して詳細に説明する。
ステップＳ１５１において、リフレッシュ部１ｃは、キャッシュ部１ｂにおけるディレクトリ情報テーブルの更新処理を行うため、すなわち、検索情報（検索クエリ）と、この検索クエリに対応してディレクトリサーバ２において検索された最新のディレクトリ情報（サービスオブジェクト）とをディレクトリ情報テーブルに記憶させるため、更新メソッドのプログラムをコールして実行する。

次に、ステップＳ１５２において、リフレッシュ部１ｃは、Ｍテーブルから上記検索情報をインデックスとして、この検索情報に対応するディレクトリ情報テーブルの参照アドレス（ServicePointer）を取得する。
そして、ステップＳ１５３において、リフレッシュ部１ｃは、検索された上記参照アドレスにより、ディレクトリ情報テーブル（ｓｔオブジェクト）をアクセスする。
次に、ステップＳ１５４において、リフレッシュ部１ｃは、上記ディレクトリ情報テーブルをロックし、最新のディレクトリ情報を書き込んだ後、ロックを解除する。

上述したように、本発明のＷｅｂサービス提供サーバは、キャッシュ部１ｂにディレクトリ情報をキャッシュしているため、ディレクトリサーバ２へのアクセスを大幅に削減することができ、全体のスループットを向上させ、検索処理の性能を向上させることが可能であり、また、キャッシュ部１ｂが一定間隔によりリフレッシュ（更新処理）されるため、常に検索条件に対応する最新のディレクトリ情報を得ることが可能である。

また、本発明のＷｅｂサービス提供サーバは、モバイルエージェントの技術を用いた場合にも、クライアントからディレクトリサーバ２に対するアクセスを大幅に低減させることができるので、ディレクトリサーバ２におけるスループットを向上し、かつクライアント側のアクセスのためのオーバーヘッドを防止することができ、クライアント側の処理能力を向上させることが可能である。

さらに、本発明のＷｅｂサービス提供サーバは、キャッシュがリフレッシュされているときに、キャッシュがロックされ、キャッシュ全体がアクセス出来なくなる欠点を解消するため、キャッシュ部１ｂが、検索情報とディレクトリ情報テーブルとを対応付けるＭテーブルと、ディレクトリ情報と最終検索時間とを対応付けたディレクトリ情報テーブルとの２つに分離して構成されており、ディレクトリ情報を更新するためにディレクトリ情報テーブルをロックしている間も、Ｍテーブルにより他のディレクトリ情報テーブルの検索を行うことができ、上述したキャッシュ部１ｂ全体がロックされ、更新処理の間に検索処理が行え無くなる不都合を防止することが可能である。

また、図４のフローチャートのステップＳ８において、キャッシュ制御部１ａは、キャッシュ部１ｂに対して、新たな検索条件及びこの検索条件により検索されたディレクトリ情報を書き込むとき、キャッシュ部１ｂの容量がこれらを書き込むのに十分でない場合、書き込みのための容量を確保するため、最終検索時刻が最も古いものを削除していたが、参照回数（参照される頻度）を考慮すると以下の欠点がある。
最終検索時刻から、削除を行う可否を判断する場合、参照回数が少なくても、最終検索時間が新しいと削除されず、検索回数が多いが一定期間検索されないと、最終検索時間が古いと削除されてしまう。

しかしながら、最終検索時間でなく参照回数により、検索条件及びディレクトリ情報を削除の可否を判定する場合、過去に頻繁に参照されていたが、現在時刻までの所定の期間において全く参照されない検索条件であっても削除されない欠点がある。
したがって、上述した欠点を解決するために、参照回数だけでなく、参照回数をカウントする期間を含んで、Ｍテーブルからの検出条件の削除において、参照頻度を評価することが必要となる。

そこで、図１０に示すように、上述したＭテーブルからの削除の判断を行うため、カウンタ有効期間と削除免除期間との２つの時間を定義する。
このとき、最終検索時刻に付いての項目はなく、各フローチャートのステップにおいても最終検索時刻をディレクトリ情報テーブルに書き込む処理がなくなる。
ここで、カウンタ有効期間は検索回数をカウントする期間を示しており、削除免除期間はこのカウンタ有効期間が開始されてから削除を免除される期間を示している（カウント有効期間が短いと検索回数のカウント値が小さくなり、削除の対象となるため）。
カウント有効期間の開始の時刻は、直前のカウント有効期間が終了した後に、検索情報が最初に検索された時刻である。

また、ディレクトリ情報テーブルは、図１１に示すように、例えば、検索終了時刻が無くなり、カウンタ有効期間の開始時刻が時刻Ｔ1と時刻Ｔ2との項に各々ｔ1，ｔ2として記載され、カウンタ値ａは時刻ｔ1から時刻ｔ2までの検索回数であり、カウンタ値ｂは時刻ｔ2からの検索回数を示している。
このとき、時刻Ｔ1の欄が直前（過去）のカウンタ有効期間の開始時刻を示し、時刻Ｔ2の欄が現在のカウンタ有効期間の開始時刻を示している。

次に、時刻Ｔ2からの経過時間がカウンタ有効期間を経過すると、カウンタ値ａ1が「０」クリアされ、時刻ｔ2から時刻ｔ1までの検索回数がカウンタ値ｂ1となり、この対応する検索条件が検索されると、時刻Ｔ1の欄にこの検索された時刻ｔ1が書き込まれ、時刻Ｔ1に対応してカウンタ有効期間が開始され、時刻ｔ1からの検索回数がカウンタ値ａ1となる。
このとき、時刻Ｔ2の欄が直前（過去）のカウンタ有効期間の開始時刻を示し、時刻Ｔ1の欄が現在のカウンタ有効期間の開始時刻を示している。

このように、時刻Ｔ1及びＴ2の項目欄は、各々カウンタ有効期間が経過する度に、前後の時間（過去及び現在の開始時刻）の格納が交互に切り替えて用いられる。
図１０に示すように、時刻t1が前の時刻として、時刻ｔ2が後の時刻として、以下の動作の説明を行う。
ここで、時刻ｔ1から時刻ｔ2のカウンタ有効期間において検索回数がカウンタ値ａ1であり、時刻ｔ2からの検索回数がカウンタ値ｂ1である。

キャッシュ制御部１ａは、Ｍテーブルの検索情報毎にディレクトリ情報テーブルを検索し、検索回数の合計として、カウンタ値ａ1とカウンタ値ｂ1とを加算し、検索情報毎に、時刻ｔ1から現在時刻までの総検索回数（前回のカウンタ有効期間における検索回数と、現在のカウンタ有効期間における検索回数との加算値）を求め、Ｍテーブルに対応させて、検索条件と総検索回数との対応表を作成する。

そして、キャッシュ制御部１ａは、カウンタ有効期間が開始されてから削除免除期間が経過、すなわち時刻ｔ2から削除免除期間が経過していない検索条件を、上記対応表から削除する。
ここで、キャッシュ制御部１ａは、現在時刻から、時刻ｔ2を減算して、この減算結果が削除免除期間以下か否かにより、削除免除期間を経過したか否かの検出を行う。
次に、キャッシュ制御部１ａは、この対応表の中から総検索回数（ａ1＋ｂ1）が最も少ない検索情報を検出し、Ｍテーブルから検出された検索情報を削除する。

これにより、カウンタ値ａ1は過去の検索回数を示し、カウンタ値ｂ1は最近の検索回数を示している。
したがって、上記削除対象の検索方法は、過去の検索回数が多く、現在の検索回数が少ないものを削除することができ、かつ削除免除期間を検出しているため、最近検索された結果を反映させることができ、検索され始めた検索情報を削除対象から除き、削除対象の検索が公平となり、適切に削除対象を検索することができる。

また、図１におけるキャッシュ制御部１ａ及びリフレッシュ部１ｂを実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより施工管理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可般媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合に、短時間の間、動的にプログラムを保持するもの、例えば、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

本発明の一実施形態のＷｅｂサービス提供サーバを用いたＷｅｂサーシス提供システムの構成例を示す概念図である。 図１におけるキャッシュ部１ｂの構成例を説明する概念図である。 図１のＷｅｂサーシス提供システムの動作例を説明するための概念図である。 キャッシュ制御部１ａの検索処理の動作例を説明するフローチャートである。 キャッシュ部１ｂの構成例を示す概念図である。 キャッシュ制御部１ａがキャッシュ部１ｂの検索処理の動作例を説明するフローチャートである。 キャッシュ制御部１ａがキャッシュ部１ｂの更新処理の動作例を説明するフローチャートである。 リフレッシュ部１ｃのキャッシュ部１ｂに対するリフレッシュ動作例を説明するフローチャートである。 リフレッシュ部１ｃのキャッシュ部１ｂに対する更新処理の動作例を説明するフローチャートである。 図１のステップＳ８の他の動作を説明するための概念図である。 図１０において用いるディレクトリ情報テーブルの構成を示す概念図である。 ネットワークにおけるディレクトリサービスの概要を説明する概念図である。 モバイルエージェント技術を利用した場合のディレクトリサービスの概要を説明する概念図である。 Ｗｅｂプロキシ（プロキシサーバ）におけるキャッシュ技術を説明する概念図である。

符号の説明

１，３ Ｗｅｂサービス提供サーバ
１ａ キャッシュ制御部
１ｂ キャッシュ部
１ｃ リフレッシュ部
１ｄ 強制リフレッシュ部
２ ディレクトリサーバ
４，５，６ サービスサーバ

Claims (7)

1. ディレクトリサーバへアクセスし、検索条件に対応したＷｅｂサービスのディレクトリ情報を取得するＷｅｂサービス提供サーバであり、
   検索条件と、この検索条件により検索されたディレクトリ情報との対応を示すキャッシュテーブルが記憶されている記憶部と、
   入力される検索条件を前記テーブルにより検索し、一致する検索条件がある場合、この検索条件に対応するディレクトリ情報を検索結果として出力し、一致する検索条件が無い場合、ディレクトリサーバにアクセスして検索を行う検索処理制御部と
   を有し、
   前記検索処理制御部が、ディレクトリサーバにアクセスして得られたディレクトリ情報を、検索に用いた検索条件に対応して前記テーブルに書き込むことを特徴とするＷｅｂサービス提供サーバ。
2. 所定の時間間隔毎に、前記ディレクトリサーバにアクセスし、前記テーブルにおける検索条件に対応するディレクトリ情報を取得して、テーブルのディレクトリ情報を更新するリフレッシュ部を有することを特徴とする請求項１記載のＷｅｂサービス提供サーバ。
3. 前記検索処理制御部が、前記テーブルにおいて、各ディレクトリ情報が読み出される毎に、このディレクトリ情報に対応して読み出された読出時間を書き込み、新たな検索条件及びディレクトリ情報を書き込むとき、現在時刻と読出時間との差が最も大きい検索条件を検出し、この検出された検索条件と新たな検索条件とを入れ替えることを特徴とする請求項１または請求項２に記載のＷｅｂサービス提供サーバ。
4. 前記テーブルが、前記ディレクトリ情報と読出時間とが対応して示されたディレクトリテーブルと、検索条件とこの検索条件に対応したディレクトリ情報とが対応して示された検索テーブルとから構成され、各々独立してアクセスされることを特徴とする請求項３に記載のＷｅｂサービス提供サーバ。
5. 前記リフレッシュ部が、ディレクトリ情報の更新を行うとき、各ディレクトリ情報の示すサービスの動作の有無を検出し、動作していないサービスを検出した場合、このサービスに対応するディレクトリ情報を読み出し不可とすることを特徴とする請求項２から請求項４のいずれかに記載のＷｅｂサービス提供サーバ。
6. ディレクトリサーバへアクセスし、検索条件に対応したＷｅｂサービスのディレクトリ情報を取得するＷｅｂサービス提供方法であり、
   検索条件と、この検索条件により検索されたディレクトリ情報との対応を示すキャッシュテーブルを記憶部に記憶する記憶過程と、
   入力される検索条件を前記テーブルにより検索し、一致する検索条件がある場合、この検索条件に対応するディレクトリ情報を検索結果として出力し、一致する検索条件が無い場合、ディレクトリサーバにアクセスして検索を行う検索処理制御過程と
   を有し、
   前記検索処理制過程において、ディレクトリサーバにアクセスして得られたディレクトリ情報を、検索に用いた検索条件に対応して前記テーブルに書き込むことを特徴とするＷｅｂサービス提供方法。
7. ディレクトリサーバへアクセスし、検索条件に対応したＷｅｂサービスのディレクトリ情報を取得するＷｅｂサービス提供をコンピュータに実行させるプログラムであり、
   検索条件と、この検索条件により検索されたディレクトリ情報との対応を示すキャッシュテーブルを記憶部に記憶する記憶処理と、
   入力される検索条件を前記テーブルにより検索し、一致する検索条件がある場合、この検索条件に対応するディレクトリ情報を検索結果として出力し、一致する検索条件が無い場合、ディレクトリサーバにアクセスして検索を行う検索制御処理と
   を有し、
   前記検索制御処理において、ディレクトリサーバにアクセスして得られたディレクトリ情報を、検索に用いた検索条件に対応して前記テーブルに書き込むことを特徴とするコンピュータが実行可能なＷｅｂサービス提供プログラム。
   

Images