JP3888093B2 - Ｗｅｂシステム、ノード装置、ロケータ装置及びプログラム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明はＷｅｂシステムに関し、特にサーバが提供するサービスの少なくとも一部を代行するフロントエンドを使って負荷分散を図ったＷｅｂシステムに関する。
【０００２】
【従来の技術】
近年、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）の使用はインターネット上で爆発的な速さで拡大しており、オンラインショッピングなどＷＷＷを利用した様々なサービスが登場してきている。ＷＷＷを利用したサービスは今後益々増加していくことは確実であり、それに伴い、サービスを提供するサーバの負荷が増大することは容易に想像できる。そのため、サーバが提供するサービスの少なくとも一部を代理実行するフロントエンドを使って、サーバの負荷を分散するシステムが開発されている（例えば、“アプリケーションフロントエンドとその管理ミドルウェア”，信学技法ＴＭ９９−３２，１１，９９（文献１）、“アプリケーションフロントエンドによるサービスとその検索”，信学技法，ＴＭ２００１−８，２００１．５（文献２））。以下、文献１及び文献２に記載された従来技術を説明する。
【０００３】
図１８にフロントエンドを使って負荷分散を行ったＷｅｂシステムの従来構成例を示す。Ｗｅｂサービスを提供するサーバ１００とそのサービスを利用するクライアント１０１−１〜１０１−５とは、インターネット等のネットワーク１０２に接続されており、このネットワーク１０２中のノード１０３−１〜１０３−３上にフロントエンド１０４−１〜１０４−３が設けられている。各々のフロントエンド１０４−１〜１０４−３は、サーバ１００が提供する機能の全部または一部をサーバ１００に代わってクライアントに提供するプログラムである。図１８では、フロントエンド１０４−１が２つのクライアント１０１−４、１０４−５に対してサービスを提供し、フロントエンド１０４−２が３つのクライアント１０１−１〜１０１−３に対してサービスを提供している。
【０００４】
サーバ１００は、ネットワーク１０２中に配置するフロントエンドの個数を、負荷の状況に応じて変化させることができる。つまり、クライアントの増加などによりサービス品質の劣化が確認された場合、サービスを提供するフロントエンドの個数を増やすことでサービス品質を保証し、逆に、サービス品質が過剰になった場合には、フロントエンドの個数を減らすことでリソースを有効に活用することができる。これは分散動的ホスティング機能とも呼ばれる。
【０００５】
分散動的ホスティング機能を提供する際には、フロントエンドの個数が大きく変化してしまう可能性があるため、配置管理サービス（ＡｌｌｏｃａｔｉｏｎＭａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｃｅ；ＡＭＳ）装置１０５が導入される。配置管理サービス装置１０５は、プログラムとして提供されるフロントエンドの動作を保証する実行環境を提供することの可能なノード１０３−１〜１０３−３の集合を特定する機能や、フロントエンドの動作ノードが特定された後、どのクライアントにも均一なサービス品質でサービスを提供することが可能となるフロントエンドの配置情報を提供する機能を有する。サーバ１００は、このような配置管理サービス装置１０５の支援の下に、ネットワーク１０２中のノード１０３−１〜１０３−３上にフロントエンド１０４−１〜１０４−３を動的に生成し、また生成したフロントエンドを削除する。フロントエンドの生成や削除のために、文献１ではそれ専用の管理ミドルウェアを提供している。
【０００６】
上述したようにフロントエンドは動的に生成、削除されるため、ネットワーク１０２内でのフロントエンドの配置は固定されない。このため、クライアントに対してフロントエンドの位置情報を提供する仕組みが必要である。そこで、ロケータ１０６とサービス検索サービス（Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｓｅｒｖｉｃｅ；ＳＤＳ）装置１０７という２つのコンポーネントが用意されている。ロケータ１０６は、ネットワーク１０２に展開されているフロントエンドの位置情報や負荷状況などを収集し、同一のサービスを提供するグループ毎にフロントエンドの位置情報などを保持管理しており、或るクライアントが或るサービスを利用するのに好適なフロントエンドを検索する機能（ルックアップ機能）を有する。他方、サービス検索サービス装置１０７は、クライアントとロケータ１０６との間に介在し、サーバ１００を含めて全てのサーバが提供するサービスカテゴリに関する情報やサービス提供者情報を管理し、またクライアントに代わってロケータ１０６へのルックアップ処理を代行する機能を有している。図１８のクライアント１０１−１を例に、クライアントが所望のサービスを提供するフロントエンドへアクセスするまでの過程を以下説明する。
【０００７】
クライアント１０１−１は、自身が利用したいサービスを特徴付けるキーワードを指定した検索要求をサービス検索サービス装置１０７へ送信する。サービス検索サービス装置１０７は、キーワードに適合するサービス名を検索し、検索結果をクライアント１０１−１に返却する。クライアント１０１−１は、検索結果の中から自身が利用したいサービス名を選択する。サービス検索サービス装置１０７は、選択されたサービス名を指定してロケータ１０６へ接続する。ロケータ１０６は、指定されたサービス名のサービスを提供するグループに属するフロントエンドの中から、クライアントのアクセスに有利なフロントエンド、例えばクライアント１０１−１に最も近いフロントエンド１０４−２を決定し、その位置情報をサービス検索サービス装置１０７へ返却する。サービス検索サービス装置１０７は、返却されたフロントエンドの位置情報をクライアント１０１−１に提供する。クライアント１０１−１は、この位置情報に従ってフロントエンド１０４−２にアクセスし、サービスの提供を受ける。
【０００８】
上述した従来技術と類似する技術を記載した文献として、特開２０００−１７２６５４号公報（文献３）がある。文献３中、複製オブジェクトがフロントエンドに相当し、ネーミングサービスプログラムを持つ管理コンピュータがサービス検索サービス装置１０７及びロケータ１０６に相当する。
【０００９】
【発明が解決しようとする課題】
上述したようにフロントエンドを使って負荷分散を行うＷｅｂシステムでは、フロントエンドの配置が変化する可能性がある。従来は、ロケータ１０６及びサービス検索サービス装置１０７を用意することで、フロントエンドの配置が変化しても、クライアントが自身の利用したいサービスを提供するフロントエンドにアクセスできるようにしている。しかし、それはクライアントがサービス検索サービス装置１０７経由でサービスをアクセスする場合に限られ、過去にアクセスしたサービスをブックマークし、そのブックマークを利用した場合には、サービスへのアクセスを保証することができない。その理由は、ブックマークによるアクセスでは、フロントエンドが搭載されるノードが直接にアクセスされるが、ブックマーク以後、そのノード上からフロントエンドが削除されている可能性があるからである。
【００１０】
本発明はこのような事情に鑑みて提案されたものであり、その目的は、フロントエンドを使って負荷分散を行うＷｅｂシステムにおいて、クライアントがブックマークを利用してフロントエンドの搭載されるノードを直接にアクセスした場合でも、サービスへのアクセスを保証することにある。
【００１１】
【課題を解決するための手段】
本発明の第１のＷｅｂシステムは、サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたＷｅｂシステムにおいて、
サービス名を指定した問い合わせに対して、当該サービス名のサービスを提供するフロントエンドの位置情報を応答する代替フロントエンド検索部を備え、
前記ノードのそれぞれは、前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しない場合にサービス名を指定した問い合わせを前記代替フロントエンド検索部に行い、その応答として得られたフロントエンドの位置情報を、好ましくはＨＴＴＰプロトコルで規定されたリダイレクト機能によって前記クライアントに提供する問合せ部を備えている。
【００１２】
本発明の第２のＷｅｂシステムは、サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたＷｅｂシステムにおいて、
前記ネットワーク中の前記フロントエンドの情報を定期的に収集し、この収集した情報を参照して、サービス名を指定した問い合わせに対して、当該サービス名のサービスを提供するフロントエンドの位置情報を応答するロケータと、
前記サーバが提供するサービスに関する情報を記憶し、この記憶した情報を参照して、前記クライアントからのキーワードを指定した問い合わせに対して該当するサービス名を決定し、且つ、決定したサービス名を指定した問い合わせを前記ロケータに送出することによって前記ロケータから得たフロントエンドの位置情報をＨＴＴＰプロトコルで規定されたリダイレクト機能によって前記クライアントに提供するサービス検索サービス装置とを備え、且つ、
前記ノードのそれぞれは、前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しない場合にサービス名を指定した問い合わせを前記ロケータに行い、その応答として得られたフロントエンドの位置情報をＨＴＴＰプロトコルで規定されたリダイレクト機能によって前記クライアントに提供する問合せ部を備えている。
【００１３】
本発明の第３のＷｅｂシステムは、サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたＷｅｂシステムにおいて、
前記ネットワーク中の前記フロントエンドの情報を定期的に収集し、この収集した情報を参照して、サービス名を指定した問い合わせに対して当該サービス名のサービスを提供するフロントエンドの位置情報を応答するロケータを備え、且つ、 前記サーバは、前記クライアントからのアクセス時、前記クライアントがアクセスしたサービスの位置情報によって一意に決定されるサービス名を指定した問い合わせを前記ロケータに送出することによって前記ロケータから得たフロントエンドの位置情報をＨＴＴＰプロトコルで規定されたリダイレクト機能によって前記クライアントに提供するサーバ側問合せ部を備え、且つ、
前記ノードのそれぞれは、前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しない場合にサービス名を指定した問い合わせを前記ロケータに行い、その応答として得られた代替フロントエンドの位置情報をＨＴＴＰプロトコルで規定されたリダイレクト機能によって前記クライアントに提供するノード側問合せ部を備えている。
【００１４】
本発明の第４のＷｅｂシステムは、第２及び第３のＷｅｂシステムにおいて、前記ロケータは、フロントエンドの位置情報を応答する前に当該フロントエンドが実際に動作しているか否かを検査する検査部を備えている。
【００１５】
本発明の第５のＷｅｂシステムは、第２及び第３のＷｅｂシステムにおいて、前記ロケータは、利用可能なフロントエンドが１つも存在しなかった場合、エラー処理情報の位置情報を応答として返却する構成を有する。
【００１６】
また本発明のノード装置は、サービスを提供するサーバと前記サービスの提供を受けるクライアントとを相互に接続するネットワーク中に存在し、前記サーバが提供するサービスの少なくとも一部を提供するフロントエンドが動的に生成、削除されるノード装置において、
前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在するか否かを確認する確認手段と、
前記フロントエンドが自ノード上に存在しない場合に、サービス名を指定した問い合わせに対して当該サービス名のサービスを提供するフロントエンドの位置情報を応答するロケータに対して、サービス名を指定した代替フロントエンドの問い合わせを行い、その応答として得られた代替フロントエンドの位置情報をＨＴＴＰプロトコルで規定されたリダイレクト機能によって前記クライアントに提供する問合せ部を備えている。
【００１７】
また本発明のロケータ装置は、サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたＷｅｂシステムにおける前記ノードと相互に通信可能なロケータ装置であって、
前記ネットワーク中の前記フロントエンドの情報を定期的に収集して記憶する手段と、
収集した情報を参照して、前記クライアントからのアクセス時に自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しなかった前記ノードからのサービス名を指定した問い合わせに対して当該サービス名のサービスを提供するフロントエンドの位置情報を応答する手段とを備えている。
【００１８】
【作用】
本発明にあっては、クライアントが過去にアクセスしたフロントエンドの位置情報をブックマークし、そのブックマークを利用してネットワーク上のノードを直接にアクセスした際、負荷状況によりそのノード上からフロントエンドが既に削除されてしまっていると、当該ノードからロケータに対して代替フロントエンドの位置情報が問い合わされ、得られたフロントエンドの位置情報がリダイレクト機能によってクライアントに提供される。
【００１９】
【発明の実施の形態】
次に本発明の実施の形態の例について図面を参照して詳細に説明する。
【００２０】
図１を参照すると、本発明の実施の形態にかかるＷｅｂシステムは、サービスを提供するサーバ１と、そのサービスの提供を受けるクライアント２と、それらを相互に接続するインターネット等のネットワーク３と、ネットワーク３のノード４−１、４−２上で動作するフロントエンド５−１、５−２と、代替フロントエンド検索部６とを含んで構成されている。
【００２１】
フロントエンド５−１、５−２は、サーバ１が提供するサービスの少なくとも一部を提供するプログラムであり、負荷状況に応じて適宜にノード４−１、４−２上に生成され、また削除される。つまり、サーバ１は、クライアントの増加などによりサービス品質の劣化が確認された場合、フロントエンドの個数を増やすことでサービス品質を保証し、逆に、サービス品質が過剰になった場合には、フロントエンドの個数を減らすことでリソースを有効に活用する。
【００２２】
代替フロントエンド検索部６は、同一のサービスを提供する複数のフロントエンド５−１、５−２を１つのグループとして管理し、ネットワーク３内のノード４−１、４−２からのサービス名を指定した代替フロントエンドの問い合わせに対して、同じサービス名のサービスを提供するフロントエンドの位置情報を応答する機能を持つ。同じサービスを提供するフロントエンドが複数存在する場合、どの１つのフロントエンドを選択するかは予め定められた選択基準に従う。選択基準としては、問い合わせ元のノードに接続しているクライアントに、より近い位置のフロントエンドを選択する、最も負荷の低いフロントエンドを選択する等がある。また、同じサービスを提供するフロントエンドが１つも存在しない場合、エラー処理情報への位置情報を返却する。エラー処理情報は、例えば他のサービスを紹介するＨＴＭＬページの位置情報（ＵＲＬ）や、サーバ１自身がサービスの提供を行う場合にはサーバ１の当該サービスの位置情報（ＵＲＬ）などである。
【００２３】
ネットワーク３内に存在する、フロントエンドの動作を保証する実行環境を提供することの可能なノード４−１、４−２のそれぞれは、クライアント２からの接続時、クライアント２から要求されたサービスを提供するフロントエンド５−１、５−２が自ノード上に生成されているか否かを調べる。生成されていればそのフロントエンド５−１、５−２によってサービスをクライアント２に提供する。生成されていなれば、従来技術ではエラーとなり、クライアント２はサービスを一切受けることができなかった。しかし、本実施の形態では、生成されていないことが検出されると、当該ノード４−１、４−２は、クライアント２から要求されたサービスを提供可能な他のフロントエンドを代替フロントエンド検索部６に問い合わせ、その結果返される他のフロントエンドの位置情報をクライアント２に提示する機能を有している。
【００２４】
特に、本実施の形態の場合、各ノード４−１、４−２は、ＨＴＴＰプロトコルで規定されているリダイレクト機能を利用して、クライアント２に他のフロントエンドの位置情報を提供する。リダイレクト機能とは、ＨＴＴＰプロトコルで規定された機能の１つであり、クライアント２側のブラウザへ指定されたＵＲＬ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）をリダイレクト命令と共に送信すると、クライアント２側のブラウザが指定されたＵＲＬへ自動的に移動する機能である。
【００２５】
他方、代替フロントエンドがなく、代替フロントエンド検索部６からエラー処理情報への位置情報が返された場合、ノード４−１、４−２は、それをリダイレクト機能を利用してクライアント２に提供する。
【００２６】
本実施の形態は上述した構成を有するため、クライアント２が過去にアクセスしたフロントエンド５−１をブックマークしており、そのブックマークを利用してノード４−１を直接にアクセスした際、ブックマーク時点以降の負荷状況の変化に応じてフロントエンド５−１がノード４−１から削除されていると、ノード４−１から代替フロントエンド検索部６に同じサービスを提供する他のフロントエンドの問い合わせが行われる。従って、若し、ノード４−２に生成されているフロントエンド５−２が代替フロントエンドとして選択されると、その位置情報が代替フロントエンド検索部６からノード４−１へ送信され、ノード４−１からリダイレクト機能によりクライアント２へ伝達される。これにより、クライアント２のブラウザは、アクセス先をノード４−２のフロントエンド５−２へ切り替え、サービスの提供を受けることができる。また、若し、他のフロントエンドが存在しない場合、ノード５−１を通じて代替フロントエンド検索部６から通知されるエラー処理情報へのアクセスに自動的に切り替わり、例えば他のサービスを紹介するＨＴＭＬページの参照や、サーバ１自身が提供するサービスを利用することが可能となる。
【００２７】
【第１の実施例】
次に本発明の第１の実施例について図面を参照して詳細に説明する。
【００２８】
図２に本発明の第１の実施例にかかるＷｅｂシステムの構成例を示す。この例のＷｅｂシステムは、Ｗｅｂサービスを提供するサーバ１、そのサービスを利用するクライアント２−ｉ（ｉ＝１〜５）、両者を接続するインターネット等のネットワーク３、ネットワーク３中のノード４−ｊ（ｊ＝１〜３）上に設けられたフロントエンド５−ｊ、配置管理サービス装置７、ロケータ８及びサービス検索サービス装置９を含んで構成される。なお、クライアント２−ｉにＷｅｂサービスを提供するサーバは一般に複数存在するが、図２では一つのサーバ１だけを図示してある。
【００２９】
フロントエンド５−ｊのそれぞれは、サーバ１が提供する機能の全部または一部をサーバ１に代わってクライアント２−ｉに提供するプログラムである。配置管理サービス装置７は、フロントエンドの動作を保証する実行環境を提供することの可能なノード４−ｊの集合を特定する機能、フロントエンドの動作ノードが特定された後、どのクライアントにも均一なサービス品質でサービスを提供することを可能とするフロントエンドの配置情報を提供する機能を有する。サーバ１は、このような配置管理サービス装置７の支援の下に、ネットワーク３中のノード４−ｊ上に自サーバ１用のフロントエンド５−ｊを動的に生成し、また生成したフロントエンドを削除することによって、サービス品質の保証とリソースの有効活用を図っている。
【００３０】
ロケータ８は、ネットワーク３に展開されているフロントエンド５−ｊの位置情報や負荷状況などを収集し、同一のサービスを提供するグループ毎にフロントエンド５−ｊの位置情報などを保持管理している。このロケータ８は、図１８に示した従来のロケータ１０６と同様な機能に加えて、図１に示した代替フロントエンド検索部６の機能も兼ね備えている。サービス検索サービス装置９は、クライアント２−ｉとロケータ８との間に介在し、サーバ１を含めて全てのサーバが提供するサービスカテゴリに関する情報やサービス提供者情報を管理し、またクライアントに代わってロケータ８へのルックアップ処理を代行する機能を有している。
【００３１】
図３を参照すると、サービス検索サービス装置９は、クライアント２−ｉとの間でＨＴＴＰによってデータの入力及び出力を行う入力部９１及び出力部９２と、クライアント２−ｉに対してサービスを提供するサーバ１の当該サービスに関する情報（サービス情報）を記憶するサービス情報記憶部９３と、このサービス情報記憶部９３へサーバ１から送信されてきたサービス情報を登録するサービス情報登録部９４と、サーバ１が事前に用意したエラー処理情報を記憶するエラー処理情報記憶部９５と、このエラー処理情報記憶部９５へサーバ１から送信されてきたエラー処理情報を登録するエラー処理情報登録部９６と、サービス情報記憶部９３に記憶されたサービス情報を参照してクライアント２−ｉからのサービス検索要求を処理するサービス検索部９７と、クライアント２−ｉが欲するサービスを提供可能なフロントエンド５−ｉの位置情報をロケータ８に問い合わせる問合せ部９８とを含んで構成されている。
【００３２】
図３に示す記録媒体Ｍ１は、ＣＤ−ＲＯＭ、半導体メモリ、磁気ディスク等の機械読み取り可能な記録媒体であり、サービス検索サービス装置用プログラムを記録している。ここに記録されたプログラムは、サービス検索サービス装置９を構成するコンピュータ（ＣＰＵ、メモリ及び通信ポートを備える）に読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータ上に、入力部９１、出力部９２、サービス情報登録部９４、エラー処理情報登録部９６、サービス検索部９７及び問合せ部９８といった機能部を実現する。
【００３３】
図４にサービス検索サービス装置９の処理例を示す。サービス検索サービス装置９は、先ず、サービス情報登録部９４によって、インターネットや専用回線等の通信路を通じて、サーバ１からサービス情報を受信し、サービス情報記憶部９３へ登録する（ステップＳ１）。ここで登録されるサービス情報は、ルックアップを行うために必要となるサービス名と、このサービス名をクライアントからのサービス検索要求中のキーワードによって検索する際のキー情報とを含む。キー情報は、１つはサービスカテゴリに関する情報であり、他の１つはサービス提供者の情報である。前者のサービスカテゴリに関する情報とは、サービスの内容が属するサービスのジャンルといったサービス自身に関する情報のことであり、具体的には、「オンラインショッピング」、「携帯端末対応」、「家電製品」、「本屋」などのキーワードで表現される。後者のサービス提供者の情報とは、サービスを提供する企業、団体、個人の名称やメールアドレス、電話番号、住所などのことである。
【００３４】
次にサービス検索サービス装置９は、エラー処理情報登録部９６によって、インターネットや専用回線等の通信路を通じて、サーバ１からエラー処理情報を受信し、エラー処理情報記憶部９５へ登録する（ステップＳ２）。ここで登録されるエラー処理情報は、例えば、他のサービスを紹介するＨＴＭＬページの位置情報（ＵＲＬ）や、サーバ１自身がサービスの提供を行う場合にはサーバ１の当該サービスの位置情報（ＵＲＬ）である。なお、このエラー処理情報の登録は必須ではない。
【００３５】
以上のようなサービス情報及びエラー処理情報の登録後、サービス検索サービス装置９は、クライアント２−ｉに対するサービス検索サービスの提供を開始する。サービス検索サービスでは、以下のような処理が行われる。
【００３６】
先ず、インターネット等の通信路を通じてクライアント２−ｉから送信されてくるサービス検索要求を入力部９１で入力する（ステップＳ３）。クライアント２−ｉから送信されるサービス検索要求には、クライアントが利用したいサービスに関するキーワードと、クライアント自身に関する情報とが含まれる。サービスに関するキーワードは、利用したいサービスの属するジャンルに関する情報やそのサービスの提供者に関する名称、メールアドレス、電話番号、住所などである。クライアント自身に関する情報とは、クライアント自身の住所などの位置情報や、使用言語、使用している端末の種類、サービスを利用する時間などの情報である。
【００３７】
入力部９１で受信されたクライアント２−ｉからのサービス検索要求は、サービス検索部９７に伝達され、サービス検索部９７は、サービス検索要求中のクライアントが利用したいサービスに関するキーワードに適合するキー情報を持つサービス名をサービス情報記憶部９３から検索することで、利用サービスを特定する（ステップＳ４）。例えば、クライアントが利用したいサービスに関するキーワードとして、「家電製品」、「オンラインショッピング」を指定している場合、「家電製品」、「オンラインショッピング」をキー情報に持つサービス名をサービス情報記憶部９３から検索する。なお、クライアント自身の情報もキーワードに含めて検索するようにしても良い。例えば、クライアントが利用したいサービスに関するキーワードが「家電製品」、「オンラインショッピング」であり、クライアント自身に関する情報中に「携帯端末」が含まれていた場合、「家電製品」、「オンラインショッピング」、「携帯端末」をキー情報に持つサービス名をサービス情報記憶部９３から検索する。
【００３８】
なお、サービス検索部９７は、キーワード検索によって検索したサービス名が１つでなく、複数存在した場合は、それら全てのサービス名を記載した一覧を出力部９２を通じて検索要求元のクライアント２−ｉに提示し、クライアント２−ｉに１つのサービス名を選択させることにより、サービス名を１つに決定する処理をステップＳ４で実施する。
【００３９】
サービス名が決定すると、サービス検索部９７は、決定したサービス名とサービス検索要求中のクライアント自身に関する情報とを問合せ部９８に伝達し、問合せ部９８はそれらを含むルップアップ要求を通信路を通じてロケータ８へ送信する（ステップＳ５）。そして、ロケータ８からの応答データを受信すると、問合せ部９８は、応答データで示されるフロントエンドの位置情報やエラー処理情報の位置情報を、ＨＴＴＰプロトコルで規定されるリダイレクト機能を利用してクライアント２−ｉへ提供する（ステップＳ６）。
【００４０】
図５を参照すると、ロケータ８は、ノード４−ｊ及びサービス検索サービス装置９との間でデータの入力及び出力を行う入力部８１及び出力部８２と、ネットワーク３内のフロントエンドに関する情報及びネットワーク３に関する情報を定期的に収集する情報収集部８３と、この情報収集部８３で収集された情報を記憶する情報記憶部８４と、ノード４−ｊ上のフロントエンド５−ｊが正常に動作しているか否かを検査する検査部８５と、情報記憶部８４に記憶された情報及び検査部８５を使用してノード４−ｊまたはサービス検索サービス装置９からの問い合わせに答えるルックアップ部８６とを含んで構成されている。
【００４１】
図５に示す記録媒体Ｍ２は、ＣＤ−ＲＯＭ、半導体メモリ、磁気ディスク等の機械読み取り可能な記録媒体であり、ロケータ用プログラムを記録している。ここに記録されたプログラムは、ロケータ８を構成するコンピュータ（ＣＰＵ、メモリ及び通信ポートを備える）に読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータ上に、入力部８１、出力部８２、情報収集部８３、検査部８５及びルックアップ部８６といった機能部を実現する。
【００４２】
情報収集部８３が定期的に収集するフロントエンドに関する情報は、フロントエンド５−ｊの位置情報（ＵＲＬ）、フロントエンド５−ｊの提供するサービス名、フロントエンド５−ｊの負荷状況などである。また、情報収集部８３が定期的に収集するネットワーク３に関する情報は、ネットワーク３内の障害情報や混雑状況などである。
【００４３】
図６に、サービス検索サービス装置９からルックアップ要求にかかる問い合わせがあった際のロケータ８の処理例を示す。ロケータ８は、サービス検索サービス装置９からの問い合わせを入力部８１を通じて入力すると、それをルックアップ部８６に伝達する（ステップＳ１１）。サービス検索サービス装置９からの問い合わせでは、ルップアップを行うサービス名と、クライアント自身に関する情報とが指定されている。ルックアップ部８６では、以下のような処理が実行される。
【００４４】
先ず、問い合わせで指定されたサービス名をキーにして情報記憶部８４に記憶されているフロントエンドに関する情報を検索し、当該サービス名のサービスを提供している全てのフロントエンドを特定する（ステップＳ１２）。次に、特定したフロントエンドが複数存在した場合には、所定の規則に従って、その内の１つを選択する（ステップＳ１３）。このステップＳ１３の処理の詳細については後述する。次に、選択したフロントエンドが実際に動作しているか否かを検査部８５を通じて検査する（ステップＳ１４）。この検査は、例えば、選択したフロントエンドが存在するノードに対して当該フロントエンドが提供するサービス名を通知し、該当するフロントエンドが動作しているか否かを調べることで行われる。次に、当該フロントエンドが実際に動作していた場合（ステップＳ１５でＹＥＳ）、当該フロントエンドの位置情報（ＵＲＬ）を出力部８２を通じて問い合わせ元のサービス検索サービス装置９に通知する（ステップＳ１６）。
【００４５】
他方、当該フロントエンドが実際に動作していなかった場合（ステップＳ１５でＮＯ）、ステップＳ１２で特定したフロントエンドが複数存在し、未だ候補にしていない他のフロントエンドがあれば（ステップＳ１７でＹＥＳ）、ステップＳ１３に戻って、それらの他のフロントエンドから１つのフロントエンドを選択し、そのフロントエンドの動作確認を行う（ステップＳ１４）。このステップＳ１３からステップＳ１７のループ処理は、正常に動作しているフロントエンドが発見されるか、候補とすべきフロントエンドがなくなるまで続けられる。
【００４６】
ステップＳ１２で特定した全てのフロントエンドが正常に動作していなかった場合（ステップＳ１７でＮＯ）、ルックアップ部８６は、サービス検索サービス装置９のエラー処理情報記憶部９５を参照し、そこにルップアップを行うサービス名のサービスを提供するサーバ１によって登録されたエラー処理情報が記憶されていれば（ステップＳ１８でＹＥＳ）、このエラー処理情報が示す位置情報（ＵＲＬ）を出力部８２を通じて問い合わせ元のサービス検索サービス装置９に通知する（ステップＳ１９）。他方、サーバ１によるエラー処理情報がエラー処理情報記憶部９５に登録されていなければ（ステップＳ１８でＮＯ）、ルックアップ部８６内に事前に登録されているエラー処理情報の位置情報（ＵＲＬ）を出力部８２を通じて問い合わせ元のサービス検索サービス装置９に通知する（ステップＳ２０）。
【００４７】
図７に、ノード４−ｊからルックアップ要求にかかる問い合わせがあった際のロケータ８の処理例を示す。ロケータ８は、ノード４−ｊからの問い合わせを入力部８１を通じて入力すると、それをルックアップ部８６に伝達する（ステップＳ２１）。ノード４−ｊからの問い合わせでは、ルップアップを行うサービス名と、クライアント自身に関する情報としてクライアントのＩＰアドレスとが指定されている。ルックアップ部８６では、以下のような処理が実行される。
【００４８】
先ず、問い合わせで指定されたサービス名をキーにして情報記憶部８４に記憶されているフロントエンドに関する情報を検索し、当該サービス名のサービスを提供している全てのフロントエンドを特定する（ステップＳ２２）。但し、問い合わせ元のノード４−ｊ上のフロントエンドはたとえ検索されても除外する。次に、特定したフロントエンドが複数存在した場合には、所定の規則に従って、その内の１つを選択する（ステップＳ２３）。このステップＳ２３の処理の詳細については後述する。次に、選択したフロントエンドが実際に動作しているか否かを検査部８５を通じて検査する（ステップＳ２４）。この検査は、例えば、選択したフロントエンドが存在するノード４−ｋ（ｋ≠ｊ）に対して当該フロントエンドが提供するサービス名を通知し、該当するフロントエンドが動作しているか否かを調べることで行われる。次に、当該フロントエンドが実際に動作していた場合（ステップＳ２５でＹＥＳ）、当該フロントエンドの位置情報（ＵＲＬ）を出力部８２を通じて問い合わせ元のノード４−ｊに通知する（ステップＳ２６）。
【００４９】
他方、当該フロントエンドが実際に動作していなかった場合（ステップＳ２５でＮＯ）、ステップＳ２２で特定したフロントエンドが複数存在し、未だ候補にしていない他のフロントエンドがあれば（ステップＳ２７でＹＥＳ）、ステップＳ２３に戻って、それらの他のフロントエンドから１つのフロントエンドを選択し、そのフロントエンドの動作確認を行う（ステップＳ２４）。このステップＳ２３からステップＳ２７のループ処理は、正常に動作しているフロントエンドが発見されるか、候補とすべきフロントエンドがなくなるまで続けられる。
【００５０】
ステップＳ２２で特定した全てのフロントエンドが正常に動作していなかった場合（ステップＳ２７でＮＯ）、ルックアップ部８６は、サービス検索サービス装置９のエラー処理情報記憶部９５を参照し、そこにルップアップを行うサービス名のサービスを提供するサーバ１によって登録されたエラー処理情報が記憶されていれば（ステップＳ２８でＹＥＳ）、このエラー処理情報が示す位置情報（ＵＲＬ）を出力部８２を通じて問い合わせ元のノード４−ｊに通知する（ステップＳ２９）。他方、サーバ１によるエラー処理情報がエラー処理情報記憶部９５に登録されていなければ（ステップＳ２８でＮＯ）、ルックアップ部８６内に事前に登録されているエラー処理情報の位置情報（ＵＲＬ）を出力部８２を通じて問い合わせ元のノード４−ｊに通知する（ステップＳ２０）。
【００５１】
次に、図６のステップＳ１３及び図７のステップＳ２３におけるフロントエンドの選定方法について説明する。同じサービスを提供する複数のフロントエンドが存在した場合に、その何れのフロントエンドを選択すべきかについては、幾つかの基準が考えられる。その一つは、クライアントとフロントエンドとの距離的な近さを考慮し、クライアントに最も近い位置で動作するフロントエンドを選択する方法である。この選択方法を採用する場合、フロントエンドの位置とクライアントの位置とを求める必要がある。
【００５２】
フロントエンドの位置は、例えば以下のような方法で求めることができる。先ず、情報収集部８３は、ネットワーク３内で固定されているルータ（図示せず）に関する位置情報を事前に把握し保持しておく。次に、ネットワーク３内に存在するフロントエンドに対して、“ｔｒａｃｅｒｏｕｔｅ”と呼ばれるコマンドを発行する。この“ｔｒａｃｅｒｏｕｔｅ”と呼ばれるコマンドは、発信地点から目的とする地点へ到達するまでの経路情報を教えてくれるコマンドである。こうして情報収集部８３は、フロントエンドに対して、ｔｒａｃｅｒｏｕｔｅコマンドを発行し、フロントエンドへの経路情報を獲得する。そして、獲得した経路情報の中で、フロントエンドに到達する直線に経由したルータの情報を取得し、このルータの情報を予め保持しているルータの位置情報と比較することで、フロントエンドの位置を予測する。この処理をネットワーク３に存在するフロントエンド全てに対して行うことで、全てのフロントエンドの位置を予測する。予測した各フロントエンドの位置は情報記憶部８４に記憶し、必要時に参照する。
【００５３】
クライアントの位置は、そのクライアントのＩＰアドレスが分かっている場合には、フロントエンドの位置を求める上述したｔｒａｃｅｒｏｕｔｅコマンドによる方法と同じ方法で求めることができる。また、クライアントから自身の位置情報が入力されている場合には、この位置情報から直ちに判明する。
【００５４】
さて、クライアントとフロントエンドとの距離的な近さを考慮してフロントエンドを選定する場合、図６のステップＳ１３にあっては、ステップＳ１２で特定されたフロントエンドのうち、ステップＳ１１で入力した問い合わせ中で指定されたクライアント自身の位置情報が示す位置に最も近い位置に存在するフロントエンドが第１候補として選択される。また、ステップＳ１７からステップＳ１３に再度戻ってきた場合には、次に距離の近いフロントエンドが第２候補として選択される。以下、同様に第３候補、第４候補、…の選択が行われる。
【００５５】
また、図７のステップ２３にあっては、ステップＳ２２で特定されたフロントエンドのうち、ステップＳ２１で入力した問い合わせ中で指定されたクライアントのＩＰアドレスから求めたクライアントの位置に最も近い位置に存在するフロントエンドが第１候補として選択される。また、ステップＳ２７からステップＳ２３に再度戻ってきた場合には、次に距離の近いフロントエンドが第２候補として選択される。以下、同様に第３候補、第４候補、…の選択が行われる。
【００５６】
図６のステップＳ１３及び図７のステップＳ２３におけるフロントエンドの選定方法の別の例は、フロントエンドの負荷状況を考慮し、より負荷の小さなフロントエンドを選択する方法である。この選択方法を採用する場合、情報収集部８３が定期的に収集して情報記憶部８４に記憶している各フロントエンドの負荷状況を参照してフロントエンドの選択が行われる。即ち、図６のステップＳ１３及び図７のステップ２３とも、ステップＳ１２及びステップＳ２２で特定されたフロントエンドのうち、情報記憶部８４に記録されている負荷が最も小さいフロントエンドが第１候補として選択される。また、ステップＳ１７及びステップＳ２７からステップＳ１３及びステップＳ２３に再度戻ってきた場合には、次に負荷の小さいフロントエンドが第２候補として選択される。以下、同様に第３候補、第４候補、…の選択が行われる。
【００５７】
図８を参照すると、ノード４−ｊは、クライアント２−ｉとの間でＨＴＴＰによってデータの入力及び出力を行う入力部４１及び出力部４２と、フロントエンド５−ｊの実行環境４５と、所定のサービス名のサービスを提供するフロントエンド５−ｊが実行環境４５上に存在しているか否かの確認を行う確認部４３と、ロケータ８に対して代替フロントエンドのルップアップにかかる問い合わせを行う問合せ部４４とを含んで構成されている。
【００５８】
図８に示す記録媒体Ｍ３は、ＣＤ−ＲＯＭ、半導体メモリ、磁気ディスク等の機械読み取り可能な記録媒体であり、ノード用プログラムを記録している。ここに記録されたプログラムは、ノード４−ｊを構成するコンピュータ（ＣＰＵ、メモリ及び通信ポートを備える）に読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータ上に、入力部４１、出力部４２、確認部４３、問合せ部４４及び実行環境４５といった機能部を実現する。
【００５９】
図９にクライアント２−ｉからアクセスがあった際のノード４−ｊの処理例を示す。ノード４−ｊは、クライアント２−ｉからアクセスがあると、クライアント２−ｉがアクセスする位置情報（ＵＲＬ）とクライアント２−ｉのＩＰアドレスとを入力部４１を通じて確認部４３に入力する（ステップＳ３１）。確認部４３は、クライアント２−ｉがアクセスする位置情報（ＵＲＬ）を元に、当該位置情報に対応するサービス名のサービスを提供するフロントエンド５−ｊが自ノード４−ｊの実行環境４５上に存在しているか否かを判定する（ステップＳ３２）。該当するフロントエンド５−ｊが存在した場合（ステップＳ３２でＹＥＳ）、ノード４−ｊは当該フロントエンド５−ｊによってクライアント２−ｉに対してサービスを提供する（ステップＳ３３）。提供されるサービスにかかるテキストや画像等は出力部４２を通じてフロントエンド５−ｊからクライアント２−ｉに送られる。
【００６０】
他方、該当するフロントエンド５−ｊが自ノード上に存在しなかった場合（ステップＳ３２でＮＯ）、確認部４３は、位置情報（ＵＲＬ）から特定されるサービス名とクライアント２−ｉのＩＰアドレスとを問合せ部４４に伝達し、問合せ部４４はこれらを指定したルックアップ要求にかかる問い合わせをロケータ８に対して送信する（ステップＳ３４）。そして、ロケータ８からの応答データを受信すると、問合せ部４４は、応答データで示されるフロントエンドの位置情報やエラー処理情報の位置情報を、ＨＴＴＰプロトコルで規定されるリダイレクト機能を利用してクライアント２−ｉへ提供する（ステップＳ３５）。
【００６１】
一方、ノード４−ｊの確認部４３は、ロケータ８の図６のステップＳ１４及び図７のステップＳ２４で自ノードに対してサービス名を指定して該当するフロントエンドの動作状況の問い合わせがあった場合、該当するフロントエンド５−ｊが自ノード４−ｊの実行環境４５上に存在しているか否かを調べ、その結果をロケータ８に応答する処理も行っている。
【００６２】
次に図１０の実行シーケンスを参照して、本実施例の動作を説明する。
【００６３】
図１０を参照すると、サーバ１はノード４−１〜４−３上にフロントエンド５−１〜５−３をそれぞれ生成し（ステップＳ４１）、ロケータ８はフロントエンド５−１〜５−３の位置情報や各ノード４−１〜４−３の負荷状況などを定期的に収集している（ステップＳ４２）。また、サーバ１はサービス情報及びエラー処理情報をサービス検索サービス装置９へ送信し、登録を行っている（ステップＳ４３）。このような状況の下、クライアント２−１からサービス検索サービス装置９に対してサービス検索要求が送信されると（ステップＳ４４）、サービス検索サービス装置９は、サービス検索要求中のキーワード等と自身が保有するサービス情報とからクライアント２−１が欲するサービス名を検索し、検索結果をクライアント２−１に提示し（ステップＳ４５）、クライアント２−１はその検索結果の中から１つのサービス名を選択する（ステップＳ４６）。
【００６４】
次にサービス検索サービス装置９は、クライアント２−１が選択したサービス名及びクライアント２−１の位置などを指定したルックアップ要求をロケータ８へ送信する（ステップＳ４７）。ロケータ８は、サービス名に基づいて当該サービスを提供可能な複数のフロントエンド５−１〜５−３を特定し、その中から例えばクライアント２−１に最も近い場所にあるフロントエンド５−２を選択する（ステップＳ４８）。そして、フロントエンド５−２が動作していることを確認し（ステップＳ４９）、フロントエンド５−２の位置情報（ＵＲＬ）をサービス検索サービス装置９へ通知する（ステップＳ５０）。サービス検索サービス装置９は、フロントエンド５−２の位置情報をリダイレクト機能によりクライアント２−１に提供する（ステップＳ５１）。これによりクライアント２−１は、ノード４−２上にあるフロントエンド５−２のサービスをアクセスし（ステップＳ５２）、サービスの提供を受ける（ステップＳ５３）。また、クライアント２−１は、後の利用に備えてフロントエンド５−２のサービスをブックマークする（ステップＳ５４）。
【００６５】
その後、フロントエンド５−２の利用率が低下したため、サーバ１はノード４−２上のフロントエンド５−２を削除している（ステップＳ５５）。この削除後にクライアント２−１がブックマークを利用してフロントエンド５−２のサービスにアクセスすると（ステップＳ５６）、ノード４−２上に該当するフロントエンド５−２が存在しないことが検出され（ステップＳ５７）、ノード４−２からロケータ８に対して代替フロントエンドの問い合わせが行われる（ステップＳ５８）。ロケータ８は、例えばフロントエンド５−３を代替フロントエンドに決定し（ステップＳ５９）、その動作を確認後（ステップＳ６０）、フロントエンド５−３の位置情報（ＵＲＬ）をノード４−２へ通知する（ステップＳ６１）。ノード４−２は、フロントエンド５−２の位置情報（ＵＲＬ）をリダイレクト機能によりクライアント２−１に提供する（ステップＳ６２）。これにより、クライアント２−１は、ノード４−３上にあるフロントエンド５−３のサービスをアクセスし（ステップＳ６３）、そのサービスの提供を受ける（ステップＳ６４）。このようにブックマーク後にフロントエンドが削除されてしまっていても、他のフロントエンドによってクライアントに対して同種のサービスを提供することが可能となる。
【００６６】
なお、ノード４−３上のフロントエンド５−３及びノード４−１上のフロントエンド５−１が動作していない場合、クライアント２−１にサーバを提供するフロントエンドが１つも存在しないため、ロケータ８は、サービス検索サービス装置９に登録されたサーバ１用のエラー処理情報が示す位置情報（ＵＲＬ）をノード４−２に通知し、ノード４−２はそれをリダイレクト機能によりクライアント２−１に提供する。このため、全てのフロントエンド５−１〜５−３が使用できない場合でも、クライアント２−１はサーバ１自身が提供するサービスを利用することが可能となる。
【００６７】
【第２の実施例】
次に本発明の第２の実施例について図面を参照して詳細に説明する。
【００６８】
図１１に本発明の第２の実施例にかかるＷｅｂシステムの構成例を示す。この例のＷｅｂシステムは、Ｗｅｂサービスを提供するサーバ１Ａ、そのサービスを利用するクライアント２−ｉ（ｉ＝１〜５）、両者を接続するインターネット等のネットワーク３、ネットワーク３中のノード４−ｊ（ｊ＝１〜３）上に設けられたフロントエンド５−ｊ、配置管理サービス装置７及びロケータ８Ａを含んで構成され、図２に示した第１の実施例と異なりサービス検索サービス装置は存在しない。また、サーバ１Ａとロケータ８Ａとは相互に通信可能に接続されている。なお、クライアント２−ｉにＷｅｂサービスを提供するサーバは一般に複数存在するが、図１１では一つのサーバ１Ａだけを図示してある。
【００６９】
フロントエンド５−ｊのそれぞれは、サーバ１Ａが提供する機能の全部または一部をサーバ１Ａに代わってクライアント２−ｉに提供するプログラムである。配置管理サービス装置７は第１の実施例におけるものと同じであり、サーバ１Ａは配置管理サービス装置７の支援の下に、ネットワーク３中のノード４−ｊ上に自サーバ１Ａ用のフロントエンド５−ｊを動的に生成し、また生成したフロントエンド５−ｊを削除することによって、サービス品質の保証とリソースの有効活用を図っている。
【００７０】
図１２を参照すると、サーバ１Ａは、クライアント２−ｉとの間でＨＴＴＰによってデータの入力及び出力を行う入力部１１及び出力部１２と、サーバ１Ａ用の全てのフロントエンド５−ｊが使用できない場合にサーバ１Ａ自身がクライアント２−ｉに対してサービスを提供するためのサービス提供部１３と、サービス提供部１３が提供するサービスの位置情報（ＵＲＬ）をエラー処理情報として記憶するエラー処理情報記憶部１４と、クライアント２−ｉに対するサービスを提供可能なフロントエンド５−ｊの位置情報をロケータ８Ａに問い合わせる問合せ部１５とを含んで構成されている。ここで、サーバ１Ａがフロントエンド５−ｊを通じてクライアント２−ｉに提供するサービスの位置情報（ＵＲＬ）と、サーバ１Ａ自身がクライアント２−ｉに提供するサービスの位置情報（ＵＲＬ）とは相違している。前者を複製サービス用位置情報、後者をエラー時サービス用位置情報と呼んで区別する。
【００７１】
図１２に示す記録媒体Ｍ４は、ＣＤ−ＲＯＭ、半導体メモリ、磁気ディスク等の機械読み取り可能な記録媒体であり、サーバ用プログラムを記録している。ここに記録されたプログラムは、サーバ１Ａを構成するコンピュータ（ＣＰＵ、メモリ及び通信ポートを備える）に読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータ上に、入力部１１、出力部１２、サービス提供部１３及び問合せ部１５といった機能部を実現する。
【００７２】
図１３にサーバ１Ａの処理例を示す。サーバ１Ａは、インターネット等の通信路を通じてクライアント２−ｉから自サーバ１Ａがアクセスされると、クライアント２−ｉが接続してきたサービスの位置情報（ＵＲＬ）及びクライアント２−ｉのＩＰアドレス等のクライアント情報を入力部１１を通じて入力する（ステップＳ１０１）。次に、サービスの位置情報（ＵＲＬ）が複製サービス用位置情報か、エラー時サービス用位置情報かを判別する（ステップＳ１０２）。複製サービス用位置情報であれば、複製サービス用位置情報からサービス名が一意に決定されるので、この決定されるサービス名とクライアント情報とを指定して問合せ部１５を通じてロケータ８Ａにルックアップ要求にかかる問い合わせを行う（ステップＳ１０３）。そして、ロケータ８Ａからの応答データを受信すると、問合せ部１５は、応答データで示されるフロントエンドの位置情報やエラー処理情報の位置情報を、ＨＴＴＰプロトコルで規定されるリダイレクト機能を利用してクライアント２−ｉへ提供する（ステップＳ１０４）。他方、エラー時サービス用位置情報であれば（ステップＳ１０２でＮＯ）、サービス提供部１３によりクライアント２−ｉに対して出力部１２を通じてサービスを提供する（ステップＳ１０５）。
【００７３】
ロケータ８Ａは、ネットワーク３に展開されているフロントエンド５−ｊの位置情報や負荷状況などを収集し、同一のサービスを提供するグループ毎にフロントエンド５−ｊの位置情報などを保持管理している。このロケータ８Ａは、サーバ１Ａからのルックアップ要求を処理する機能に加えて、図１に示した代替フロントエンド検索部６の機能も兼ね備えている。
【００７４】
図１４を参照すると、ロケータ８Ａは、ノード４−ｊ及びサーバ１Ａとの間でデータの入力及び出力を行う入力部８１及び出力部８２と、ネットワーク３内のフロントエンドに関する情報及びネットワーク３に関する情報を定期的に収集する情報収集部８３と、この情報収集部８３で収集された情報を記憶する情報記憶部８４と、ノード４−ｊ上のフロントエンド５−ｊが正常に動作しているか否かを検査する検査部８５と、情報記憶部８４に記憶された情報及び検査部８５を使用してノード４−ｊまたはサーバ１Ａからの問い合わせに答えるルックアップ部８６とを含んで構成されている。
【００７５】
図１４に示す記録媒体Ｍ５は、ＣＤ−ＲＯＭ、半導体メモリ、磁気ディスク等の機械読み取り可能な記録媒体であり、ロケータ用プログラムを記録している。ここに記録されたプログラムは、ロケータ８Ａを構成するコンピュータ（ＣＰＵ、メモリ及び通信ポートを備える）に読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータ上に、入力部８１、出力部８２、情報収集部８３、検査部８５及びルックアップ部８６といった機能部を実現する。
【００７６】
情報収集部８３が定期的に収集するフロントエンドに関する情報は、フロントエンド５−ｊの位置情報（ＵＲＬ）、フロントエンド５−ｊの提供するサービス名、フロントエンド５−ｊの負荷状況などである。また、情報収集部８３が定期的に収集するネットワーク３に関する情報は、ネットワーク３内の障害情報や混雑状況などである。
【００７７】
図１５に、サーバ１Ａからルックアップ要求にかかる問い合わせがあった際のロケータ８Ａの処理例を示す。ロケータ８Ａは、サーバ１Ａからの問い合わせを入力部８１を通じて入力すると、それをルックアップ部８６に伝達する（ステップＳ１１）。サーバ１Ａからの問い合わせでは、ルップアップを行うサービス名と、クライアント自身に関する情報としてクライアントのＩＰアドレスが指定されている。ルックアップ部８６では、以下のような処理が実行される。
【００７８】
先ず、問い合わせで指定されたサービス名をキーにして情報記憶部８４に記憶されているフロントエンドに関する情報を検索し、当該サービス名のサービスを提供している全てのフロントエンドを特定する（ステップＳ１２）。次に、特定したフロントエンドが複数存在した場合には、第１の実施例と同様な規則に従って、その内の１つを選択する（ステップＳ１３）。次に、選択したフロントエンドが実際に動作しているか否かを第１の実施例と同様に検査部８５を通じて検査する（ステップＳ１４）。次に、当該フロントエンドが実際に動作していた場合（ステップＳ１５でＹＥＳ）、当該フロントエンドの位置情報（ＵＲＬ）を出力部８２を通じて問い合わせ元のサーバ１Ａに通知する（ステップＳ１６）。
【００７９】
他方、当該フロントエンドが実際に動作していなかった場合（ステップＳ１５でＮＯ）、ステップＳ１２で特定したフロントエンドが複数存在し、未だ候補にしていない他のフロントエンドがあれば（ステップＳ１７でＹＥＳ）、ステップＳ１３に戻って、それらの他のフロントエンドから１つのフロントエンドを選択し、そのフロントエンドの動作確認を行う（ステップＳ１４）。このステップＳ１３からステップＳ１７のループ処理は、正常に動作しているフロントエンドが発見されるか、候補とすべきフロントエンドがなくなるまで続けられる。
【００８０】
ステップＳ１２で特定した全てのフロントエンドが正常に動作していなかった場合（ステップＳ１７でＮＯ）、ルックアップ部８６は、サーバ１Ａのエラー処理情報記憶部１４を参照し、エラー処理情報が記憶されていれば（ステップＳ１８でＹＥＳ）、このエラー処理情報が示す位置情報（ＵＲＬ）を出力部８２を通じて問い合わせ元のサーバ１Ａに通知する（ステップＳ１９）。他方、エラー処理情報がエラー処理情報記憶部１４に登録されていなければ（ステップＳ１８でＮＯ）、ルックアップ部８６内に事前に登録されているエラー処理情報の位置情報（ＵＲＬ）を出力部８２を通じて問い合わせ元のサーバ１Ａに通知する（ステップＳ２０）。
【００８１】
図１６に、ノード４−ｊからルックアップ要求にかかる問い合わせがあった際のロケータ８Ａの処理例を示す。ロケータ８Ａは、ノード４−ｊからの問い合わせを入力部８１を通じて入力すると、それをルックアップ部８６に伝達する（ステップＳ２１）。ノード４−ｊからの問い合わせでは、ルップアップを行うサービス名と、クライアント自身に関する情報としてクライアントのＩＰアドレスが指定されている。ルックアップ部８６では、以下のような処理が実行される。
【００８２】
先ず、問い合わせで指定されたサービス名をキーにして情報記憶部８４に記憶されているフロントエンドに関する情報を検索し、当該サービス名のサービスを提供している全てのフロントエンドを特定する（ステップＳ２２）。但し、問い合わせ元のノード４−ｊのフロントエンド５−ｊはたとえ検索されても除外する。次に、特定したフロントエンドが複数存在した場合には、第１の実施例と同様に所定の規則に従って、その内の１つを選択する（ステップＳ２３）。次に、選択したフロントエンドが実際に動作しているか否かを検査部８５を通じて検査する（ステップＳ２４）。次に、当該フロントエンドが実際に動作していた場合（ステップＳ２５でＹＥＳ）、当該フロントエンドの位置情報（ＵＲＬ）を出力部８２を通じて問い合わせ元のノード４−ｊに通知する（ステップＳ２６）。
【００８３】
他方、当該フロントエンドが実際に動作していなかった場合（ステップＳ２５でＮＯ）、ステップＳ２２で特定したフロントエンドが複数存在し、未だ候補にしていない他のフロントエンドがあれば（ステップＳ２７でＹＥＳ）、ステップＳ２３に戻って、それらの他のフロントエンドから１つのフロントエンドを選択し、そのフロントエンドの動作確認を行う（ステップＳ２４）。このステップＳ２３からステップＳ２７のループ処理は、正常に動作しているフロントエンドが発見されるか、候補とすべきフロントエンドがなくなるまで続けられる。
【００８４】
ステップＳ２２で特定した全てのフロントエンドが正常に動作していなかった場合（ステップＳ２７でＮＯ）、ルックアップ部８６は、ルックアップを行うサービス名のサービスを提供するサーバ１Ａのエラー処理情報記憶部１４を参照し、エラー処理情報が記憶されていれば（ステップＳ２８でＹＥＳ）、このエラー処理情報が示す位置情報（ＵＲＬ）を出力部８２を通じて問い合わせ元のノード４−ｊに通知する（ステップＳ２９）。他方、サーバ１Ａにエラー処理情報が登録されていなければ（ステップＳ２８でＮＯ）、ルックアップ部８６内に事前に登録されているエラー処理情報の位置情報（ＵＲＬ）を出力部８２を通じて問い合わせ元のノード４−ｊに通知する（ステップＳ３０）。
【００８５】
ノード４−ｊの構成と動作は、図８及び図９に示した第１の実施例におけるノードと同じである。
【００８６】
次に図１７の実行シーケンスを参照して、本実施例の動作を説明する。
【００８７】
図１７を参照すると、サーバ１Ａはノード４−１〜４−３上にフロントエンド５−１〜５−３をそれぞれ生成し（ステップＳ１１１）、ロケータ８Ａはフロントエンド５−１〜５−３の位置情報や各ノード４−１〜４−２の負荷状況などを定期的に収集している（ステップＳ１１２）。このような状況の下、クライアント２−１が複製サービス用位置情報（ＵＲＬ）を使ってサーバ１Ａのサービスにアクセスすると（ステップＳ１１３）、サーバ１Ａは、複製サービス用位置情報（ＵＲＬ）からサービス名を決定し、このサービス名とクライアント情報（ＩＰアドレス）とを指定したルックアップ要求をロケータ８Ａへ送信する（ステップＳ１１４）。ロケータ８Ａは、サービス名に基づいて当該サービスを提供可能な複数のフロントエンド５−１〜５−３を特定し、その中から例えばクライアント２−１に最も近い場所にあるフロントエンド５−２を選択する（ステップＳ１１５）。そして、フロントエンド５−２が動作していることを確認し（ステップＳ１１６）、フロントエンド５−２の位置情報（ＵＲＬ）をサーバ１Ａへ通知する（ステップＳ１１７）。サーバ１Ａは、フロントエンド５−２の位置情報をリダイレクト機能によりクライアント２−１に提供する（ステップＳ１１８）。これによりクライアント２−１は、ノード４−２上にあるフロントエンド５−２のサービスをアクセスし（ステップＳ１１９）、サービスの提供を受ける（ステップＳ１２０）。また、クライアント２−１は、後の利用に備えてフロントエンド５−２のサービスをブックマークする（ステップＳ１２１）。
【００８８】
その後、フロントエンド５−２の利用率が低下したため、サーバ１Ａはノード４−２上のフロントエンド５−２を削除している（ステップＳ１２２）。この削除後にクライアント２−１がブックマークを利用してフロントエンド５−２のサービスにアクセスすると（ステップＳ１２３）、ノード４−２上に該当するフロントエンド５−２が存在しないことが検出され（ステップＳ１２４）、ノード４−２からロケータ８Ａに対して代替フロントエンドの問い合わせが行われる（ステップＳ１２５）。ロケータ８Ａは、例えばフロントエンド５−３を代替フロントエンドに決定し（ステップＳ１２６）、その動作を確認後（ステップＳ１２７）、フロントエンド５−３の位置情報（ＵＲＬ）をノード４−２へ通知する（ステップＳ１２８）。ノード４−２は、フロントエンド５−２の位置情報（ＵＲＬ）をリダイレクト機能によりクライアント２−１に提供する（ステップＳ１２９）。これにより、クライアント２−１は、ノード４−３上にあるフロントエンド５−３のサービスをアクセスし（ステップＳ１３０）、そのサービスの提供を受ける（ステップＳ１３１）。このようにブックマーク後にフロントエンドが削除されてしまっていても、他のフロントエンドによってクライアントに対して同種のサービスを提供することが可能となる。
【００８９】
なお、ノード４−３上のフロントエンド５−３及びノード４−１上のフロントエンド５−１が動作していない場合、クライアント２−１にサーバを提供するフロントエンドが１つも存在しないため、ロケータ８Ａは、サーバ１Ａのエラー処理情報記憶部１４に記憶されたエラー処理情報（エラー時サービス用位置情報）をノード４−２に通知し、ノード４−２はそれをリダイレクト機能によりクライアント２−１に提供する。このため、全てのフロントエンド５−１〜５−３が使用できない場合でも、クライアント２−１はサーバ１Ａのサービス提供部１３が提供するサービスを利用することが可能となる。
【００９０】
【発明の効果】
以上説明したように本発明によれば、フロントエンドを使って負荷分散を行うＷｅｂシステムにおいて、クライアントがブックマークを利用してフロントエンドの搭載されるノードを直接にアクセスした場合でも、サービスへのアクセスを保証することができる。その理由は、当該ノード上のフロントエンドが既に削除されている場合、当該ノードからロケータ（代替フロントエンド検索部）に対して他のフロントエンドの位置情報の問い合わせが行われ、その位置情報がクライアントに提供されるからである。
【００９１】
また、フロントエンドの位置情報をリダイレクト機能によってクライアントに提供することにより、サービスに接続するまでに要する時間を短縮でき、サービスへのシームレスな接続が可能となる。
【００９２】
更に、ロケータはフロントエンドの位置情報を応答する前にそのフロントエンドが実際に動作していることを確認しているため、信頼性の高いサービスアクセスを実現することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態にかかるＷｅｂシステムのブロック図である。
【図２】本発明の第１の実施例にかかるＷｅｂシステムのブロック図である。
【図３】本発明の第１の実施例にかかるＷｅｂシステムにおけるサービス検索サービス装置のブロック図である。
【図４】本発明の第１の実施例にかかるＷｅｂシステムにおけるサービス検索サービス装置の処理例を示すフローチャートである。
【図５】本発明の第１の実施例にかかるＷｅｂシステムにおけるロケータのブロック図である。
【図６】本発明の第１の実施例にかかるＷｅｂシステムにおけるロケータにおいて、サービス検索サービス装置からルックアップ要求にかかる問に合わせがあった際の処理例を示すフローチャートである。
【図７】本発明の第１の実施例にかかるＷｅｂシステムにおけるロケータにおいて、ノードからルックアップ要求にかかる問い合わせがあった際の処理例を示すフローチャートである。
【図８】本発明の第１の実施例にかかるＷｅｂシステムにおけるノードのブロック図である。
【図９】本発明の第１の実施例にかかるＷｅｂシステムにおけるノードにおいて、クライアントからアクセスがあった際の処理例を示すフローチャートである。
【図１０】本発明の第１の実施例にかかるＷｅｂシステムの動作を説明するための実行シーケンス図である。
【図１１】本発明の第２の実施例にかかるＷｅｂシステムのブロック図である。
【図１２】
本発明の第２の実施例にかかるＷｅｂシステムのサーバのブロック図である。
【図１３】
本発明の第２の実施例にかかるＷｅｂシステムのサーバの処理例を示すフローチャートである。
【図１４】本発明の第２の実施例にかかるＷｅｂシステムのロケータのブロック図である。
【図１５】本発明の第２の実施例にかかるＷｅｂシステムのロケータにおいて、サーバからルックアップ要求にかかる問い合わせがあった際の処理例を示すフローチャートである。
【図１６】本発明の第２の実施例にかかるＷｅｂシステムのロケータにおいて、ノードからルックアップ要求にかかる問い合わせがあった際の処理例を示すフローチャートである。
【図１７】本発明の第２の実施例にかかるＷｅｂシステムの動作を説明するための実行シーケンス図である。
【図１８】フロントエンドを使って負荷分散を行ったＷｅｂシステムの従来構成例を示すブロック図である。
【符号の説明】
１、１Ａ…サーバ
２、２−１〜２−５…クライアント
３…ネットワーク
４−１〜４−３…ノード
５−１〜５−３…フロントエンド
６…代替フロントエンド検索部
７…配置管理サービス（Ａｌｌｏｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｃｅ；ＡＭＳ）装置
８、８Ａ…ロケータ
９…サービス検索サービス（Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｓｅｒｖｉｃｅ；ＳＤＳ）装置

Claims (10)

1. サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたＷｅｂシステムにおいて、
   サービス名を指定した問い合わせに対して、当該サービス名のサービスを提供するフロントエンドの位置情報を応答する代替フロントエンド検索部を備え、
   前記ノードのそれぞれは、前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しない場合にサービス名を指定した問い合わせを前記代替フロントエンド検索部に行い、その応答として得られたフロントエンドの位置情報を前記クライアントに提供する問合せ部を備えることを特徴とするＷｅｂシステム。
2. 前記問合せ部は、ＨＴＴＰプロトコルで規定されたリダイレクト機能によって代替フロントエンドの位置情報を前記クライアントに提供する構成を有する請求項１記載のＷｅｂシステム。
3. サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたＷｅｂシステムにおいて、
   前記ネットワーク中の前記フロントエンドの情報を定期的に収集し、この収集した情報を参照して、サービス名を指定した問い合わせに対して、当該サービス名のサービスを提供するフロントエンドの位置情報を応答するロケータと、
   前記サーバが提供するサービスに関する情報を記憶し、この記憶した情報を参照して、前記クライアントからのキーワードを指定した問い合わせに対して該当するサービス名を決定し、且つ、決定したサービス名を指定した問い合わせを前記ロケータに送出することによって前記ロケータから得たフロントエンドの位置情報をＨＴＴＰプロトコルで規定されたリダイレクト機能によって前記クライアントに提供するサービス検索サービス装置とを備え、且つ、
   前記ノードのそれぞれは、前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しない場合にサービス名を指定した問い合わせを前記ロケータに行い、その応答として得られたフロントエンドの位置情報をＨＴＴＰプロトコルで規定されたリダイレクト機能によって前記クライアントに提供する問合せ部を備えることを特徴とするＷｅｂシステム。
4. サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたＷｅｂシステムにおいて、
   前記ネットワーク中の前記フロントエンドの情報を定期的に収集し、この収集した情報を参照して、サービス名を指定した問い合わせに対して当該サービス名のサービスを提供するフロントエンドの位置情報を応答するロケータを備え、且つ、 前記サーバは、前記クライアントからのアクセス時、前記クライアントがアクセスしたサービスの位置情報によって一意に決定されるサービス名を指定した問い合わせを前記ロケータに送出することによって前記ロケータから得たフロントエンドの位置情報をＨＴＴＰプロトコルで規定されたリダイレクト機能によって前記クライアントに提供するサーバ側問合せ部を備え、且つ、
   前記ノードのそれぞれは、前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しない場合にサービス名を指定した問い合わせを前記ロケータに行い、その応答として得られた代替フロントエンドの位置情報をＨＴＴＰプロトコルで規定されたリダイレクト機能によって前記クライアントに提供するノード側問合せ部を備えることを特徴とするＷｅｂシステム。
5. 前記ロケータは、フロントエンドの位置情報を応答する前に当該フロントエンドが実際に動作しているか否かを検査する検査部を備える請求項３または４記載のＷｅｂシステム。
6. 前記ロケータは、利用可能なフロントエンドが１つも存在しなかった場合、エラー処理情報の位置情報を応答として返却する構成を有する請求項３または４記載のＷｅｂシステム。
7. サービスを提供するサーバと前記サービスの提供を受けるクライアントとを相互に接続するネットワーク中に存在し、前記サーバが提供するサービスの少なくとも一部を提供するフロントエンドが動的に生成、削除されるノード装置において、
   前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在するか否かを確認する確認手段と、
   前記フロントエンドが自ノード上に存在しない場合に、サービス名を指定した問い合わせに対して当該サービス名のサービスを提供するフロントエンドの位置情報を応答するロケータに対して、サービス名を指定した代替フロントエンドの問い合わせを行い、その応答として得られた代替フロントエンドの位置情報をＨＴＴＰプロトコルで規定されたリダイレクト機能によって前記クライアントに提供する問合せ部を備えることを特徴とするノード装置。
8. サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたＷｅｂシステムにおける前記ノードと相互に通信可能なロケータ装置であって、
   前記ネットワーク中の前記フロントエンドの情報を定期的に収集して記憶する手段と、
   収集した情報を参照して、前記クライアントからのアクセス時に自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しなかった前記ノードからのサービス名を指定した問い合わせに対して当該サービス名のサービスを提供するフロントエンドの位置情報を応答する手段とを備えたロケータ装置。
9. サービスを提供するサーバと前記サービスの提供を受けるクライアントとを相互に接続するネットワーク中に存在し、前記サーバが提供するサービスの少なくとも一部を提供するフロントエンドが動的に生成、削除されるノード装置を構成するコンピュータを、
   前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在するか否かを確認する確認手段、
   前記フロントエンドが自ノード上に存在しない場合に、サービス名を指定した問い合わせに対して当該サービス名のサービスを提供するフロントエンドの位置情報を応答するロケータに対して、サービス名を指定した代替フロントエンドの問い合わせを行い、その応答として得られた代替フロントエンドの位置情報をＨＴＴＰプロトコルで規定されたリダイレクト機能によって前記クライアントに提供する問合せ手段、
   として機能させるプログラム。
10. サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたＷｅｂシステムにおける前記ノードと相互に通信可能なロケータを構成するコンピュータを、
    前記ネットワーク中の前記フロントエンドの情報を定期的に収集して記憶する手段、
    前記収集した情報を参照して、前記クライアントからのアクセス時に自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しなかった前記ノードからのサービス名を指定した問い合わせに対して当該サービス名のサービスを提供するフロントエンドの位置情報を応答する手段、
    として機能させるプログラム。

Images