JP3888093B2 - Webシステム、ノード装置、ロケータ装置及びプログラム - Google Patents
Webシステム、ノード装置、ロケータ装置及びプログラム Download PDFInfo
- Publication number
- JP3888093B2 JP3888093B2 JP2001221088A JP2001221088A JP3888093B2 JP 3888093 B2 JP3888093 B2 JP 3888093B2 JP 2001221088 A JP2001221088 A JP 2001221088A JP 2001221088 A JP2001221088 A JP 2001221088A JP 3888093 B2 JP3888093 B2 JP 3888093B2
- Authority
- JP
- Japan
- Prior art keywords
- service
- client
- provides
- node
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Description
【発明の属する技術分野】
本発明はWebシステムに関し、特にサーバが提供するサービスの少なくとも一部を代行するフロントエンドを使って負荷分散を図ったWebシステムに関する。
【0002】
【従来の技術】
近年、WWW(World Wide Web)の使用はインターネット上で爆発的な速さで拡大しており、オンラインショッピングなどWWWを利用した様々なサービスが登場してきている。WWWを利用したサービスは今後益々増加していくことは確実であり、それに伴い、サービスを提供するサーバの負荷が増大することは容易に想像できる。そのため、サーバが提供するサービスの少なくとも一部を代理実行するフロントエンドを使って、サーバの負荷を分散するシステムが開発されている(例えば、“アプリケーションフロントエンドとその管理ミドルウェア”,信学技法TM99−32,11,99(文献1)、“アプリケーションフロントエンドによるサービスとその検索”,信学技法,TM2001−8,2001.5(文献2))。以下、文献1及び文献2に記載された従来技術を説明する。
【0003】
図18にフロントエンドを使って負荷分散を行ったWebシステムの従来構成例を示す。Webサービスを提供するサーバ100とそのサービスを利用するクライアント101−1〜101−5とは、インターネット等のネットワーク102に接続されており、このネットワーク102中のノード103−1〜103−3上にフロントエンド104−1〜104−3が設けられている。各々のフロントエンド104−1〜104−3は、サーバ100が提供する機能の全部または一部をサーバ100に代わってクライアントに提供するプログラムである。図18では、フロントエンド104−1が2つのクライアント101−4、104−5に対してサービスを提供し、フロントエンド104−2が3つのクライアント101−1〜101−3に対してサービスを提供している。
【0004】
サーバ100は、ネットワーク102中に配置するフロントエンドの個数を、負荷の状況に応じて変化させることができる。つまり、クライアントの増加などによりサービス品質の劣化が確認された場合、サービスを提供するフロントエンドの個数を増やすことでサービス品質を保証し、逆に、サービス品質が過剰になった場合には、フロントエンドの個数を減らすことでリソースを有効に活用することができる。これは分散動的ホスティング機能とも呼ばれる。
【0005】
分散動的ホスティング機能を提供する際には、フロントエンドの個数が大きく変化してしまう可能性があるため、配置管理サービス(AllocationManagement Servece;AMS)装置105が導入される。配置管理サービス装置105は、プログラムとして提供されるフロントエンドの動作を保証する実行環境を提供することの可能なノード103−1〜103−3の集合を特定する機能や、フロントエンドの動作ノードが特定された後、どのクライアントにも均一なサービス品質でサービスを提供することが可能となるフロントエンドの配置情報を提供する機能を有する。サーバ100は、このような配置管理サービス装置105の支援の下に、ネットワーク102中のノード103−1〜103−3上にフロントエンド104−1〜104−3を動的に生成し、また生成したフロントエンドを削除する。フロントエンドの生成や削除のために、文献1ではそれ専用の管理ミドルウェアを提供している。
【0006】
上述したようにフロントエンドは動的に生成、削除されるため、ネットワーク102内でのフロントエンドの配置は固定されない。このため、クライアントに対してフロントエンドの位置情報を提供する仕組みが必要である。そこで、ロケータ106とサービス検索サービス(Service Discovery Service;SDS)装置107という2つのコンポーネントが用意されている。ロケータ106は、ネットワーク102に展開されているフロントエンドの位置情報や負荷状況などを収集し、同一のサービスを提供するグループ毎にフロントエンドの位置情報などを保持管理しており、或るクライアントが或るサービスを利用するのに好適なフロントエンドを検索する機能(ルックアップ機能)を有する。他方、サービス検索サービス装置107は、クライアントとロケータ106との間に介在し、サーバ100を含めて全てのサーバが提供するサービスカテゴリに関する情報やサービス提供者情報を管理し、またクライアントに代わってロケータ106へのルックアップ処理を代行する機能を有している。図18のクライアント101−1を例に、クライアントが所望のサービスを提供するフロントエンドへアクセスするまでの過程を以下説明する。
【0007】
クライアント101−1は、自身が利用したいサービスを特徴付けるキーワードを指定した検索要求をサービス検索サービス装置107へ送信する。サービス検索サービス装置107は、キーワードに適合するサービス名を検索し、検索結果をクライアント101−1に返却する。クライアント101−1は、検索結果の中から自身が利用したいサービス名を選択する。サービス検索サービス装置107は、選択されたサービス名を指定してロケータ106へ接続する。ロケータ106は、指定されたサービス名のサービスを提供するグループに属するフロントエンドの中から、クライアントのアクセスに有利なフロントエンド、例えばクライアント101−1に最も近いフロントエンド104−2を決定し、その位置情報をサービス検索サービス装置107へ返却する。サービス検索サービス装置107は、返却されたフロントエンドの位置情報をクライアント101−1に提供する。クライアント101−1は、この位置情報に従ってフロントエンド104−2にアクセスし、サービスの提供を受ける。
【0008】
上述した従来技術と類似する技術を記載した文献として、特開2000−172654号公報(文献3)がある。文献3中、複製オブジェクトがフロントエンドに相当し、ネーミングサービスプログラムを持つ管理コンピュータがサービス検索サービス装置107及びロケータ106に相当する。
【0009】
【発明が解決しようとする課題】
上述したようにフロントエンドを使って負荷分散を行うWebシステムでは、フロントエンドの配置が変化する可能性がある。従来は、ロケータ106及びサービス検索サービス装置107を用意することで、フロントエンドの配置が変化しても、クライアントが自身の利用したいサービスを提供するフロントエンドにアクセスできるようにしている。しかし、それはクライアントがサービス検索サービス装置107経由でサービスをアクセスする場合に限られ、過去にアクセスしたサービスをブックマークし、そのブックマークを利用した場合には、サービスへのアクセスを保証することができない。その理由は、ブックマークによるアクセスでは、フロントエンドが搭載されるノードが直接にアクセスされるが、ブックマーク以後、そのノード上からフロントエンドが削除されている可能性があるからである。
【0010】
本発明はこのような事情に鑑みて提案されたものであり、その目的は、フロントエンドを使って負荷分散を行うWebシステムにおいて、クライアントがブックマークを利用してフロントエンドの搭載されるノードを直接にアクセスした場合でも、サービスへのアクセスを保証することにある。
【0011】
【課題を解決するための手段】
本発明の第1のWebシステムは、サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたWebシステムにおいて、
サービス名を指定した問い合わせに対して、当該サービス名のサービスを提供するフロントエンドの位置情報を応答する代替フロントエンド検索部を備え、
前記ノードのそれぞれは、前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しない場合にサービス名を指定した問い合わせを前記代替フロントエンド検索部に行い、その応答として得られたフロントエンドの位置情報を、好ましくはHTTPプロトコルで規定されたリダイレクト機能によって前記クライアントに提供する問合せ部を備えている。
【0012】
本発明の第2のWebシステムは、サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたWebシステムにおいて、
前記ネットワーク中の前記フロントエンドの情報を定期的に収集し、この収集した情報を参照して、サービス名を指定した問い合わせに対して、当該サービス名のサービスを提供するフロントエンドの位置情報を応答するロケータと、
前記サーバが提供するサービスに関する情報を記憶し、この記憶した情報を参照して、前記クライアントからのキーワードを指定した問い合わせに対して該当するサービス名を決定し、且つ、決定したサービス名を指定した問い合わせを前記ロケータに送出することによって前記ロケータから得たフロントエンドの位置情報をHTTPプロトコルで規定されたリダイレクト機能によって前記クライアントに提供するサービス検索サービス装置とを備え、且つ、
前記ノードのそれぞれは、前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しない場合にサービス名を指定した問い合わせを前記ロケータに行い、その応答として得られたフロントエンドの位置情報をHTTPプロトコルで規定されたリダイレクト機能によって前記クライアントに提供する問合せ部を備えている。
【0013】
本発明の第3のWebシステムは、サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたWebシステムにおいて、
前記ネットワーク中の前記フロントエンドの情報を定期的に収集し、この収集した情報を参照して、サービス名を指定した問い合わせに対して当該サービス名のサービスを提供するフロントエンドの位置情報を応答するロケータを備え、且つ、 前記サーバは、前記クライアントからのアクセス時、前記クライアントがアクセスしたサービスの位置情報によって一意に決定されるサービス名を指定した問い合わせを前記ロケータに送出することによって前記ロケータから得たフロントエンドの位置情報をHTTPプロトコルで規定されたリダイレクト機能によって前記クライアントに提供するサーバ側問合せ部を備え、且つ、
前記ノードのそれぞれは、前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しない場合にサービス名を指定した問い合わせを前記ロケータに行い、その応答として得られた代替フロントエンドの位置情報をHTTPプロトコルで規定されたリダイレクト機能によって前記クライアントに提供するノード側問合せ部を備えている。
【0014】
本発明の第4のWebシステムは、第2及び第3のWebシステムにおいて、前記ロケータは、フロントエンドの位置情報を応答する前に当該フロントエンドが実際に動作しているか否かを検査する検査部を備えている。
【0015】
本発明の第5のWebシステムは、第2及び第3のWebシステムにおいて、前記ロケータは、利用可能なフロントエンドが1つも存在しなかった場合、エラー処理情報の位置情報を応答として返却する構成を有する。
【0016】
また本発明のノード装置は、サービスを提供するサーバと前記サービスの提供を受けるクライアントとを相互に接続するネットワーク中に存在し、前記サーバが提供するサービスの少なくとも一部を提供するフロントエンドが動的に生成、削除されるノード装置において、
前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在するか否かを確認する確認手段と、
前記フロントエンドが自ノード上に存在しない場合に、サービス名を指定した問い合わせに対して当該サービス名のサービスを提供するフロントエンドの位置情報を応答するロケータに対して、サービス名を指定した代替フロントエンドの問い合わせを行い、その応答として得られた代替フロントエンドの位置情報をHTTPプロトコルで規定されたリダイレクト機能によって前記クライアントに提供する問合せ部を備えている。
【0017】
また本発明のロケータ装置は、サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたWebシステムにおける前記ノードと相互に通信可能なロケータ装置であって、
前記ネットワーク中の前記フロントエンドの情報を定期的に収集して記憶する手段と、
収集した情報を参照して、前記クライアントからのアクセス時に自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しなかった前記ノードからのサービス名を指定した問い合わせに対して当該サービス名のサービスを提供するフロントエンドの位置情報を応答する手段とを備えている。
【0018】
【作用】
本発明にあっては、クライアントが過去にアクセスしたフロントエンドの位置情報をブックマークし、そのブックマークを利用してネットワーク上のノードを直接にアクセスした際、負荷状況によりそのノード上からフロントエンドが既に削除されてしまっていると、当該ノードからロケータに対して代替フロントエンドの位置情報が問い合わされ、得られたフロントエンドの位置情報がリダイレクト機能によってクライアントに提供される。
【0019】
【発明の実施の形態】
次に本発明の実施の形態の例について図面を参照して詳細に説明する。
【0020】
図1を参照すると、本発明の実施の形態にかかるWebシステムは、サービスを提供するサーバ1と、そのサービスの提供を受けるクライアント2と、それらを相互に接続するインターネット等のネットワーク3と、ネットワーク3のノード4−1、4−2上で動作するフロントエンド5−1、5−2と、代替フロントエンド検索部6とを含んで構成されている。
【0021】
フロントエンド5−1、5−2は、サーバ1が提供するサービスの少なくとも一部を提供するプログラムであり、負荷状況に応じて適宜にノード4−1、4−2上に生成され、また削除される。つまり、サーバ1は、クライアントの増加などによりサービス品質の劣化が確認された場合、フロントエンドの個数を増やすことでサービス品質を保証し、逆に、サービス品質が過剰になった場合には、フロントエンドの個数を減らすことでリソースを有効に活用する。
【0022】
代替フロントエンド検索部6は、同一のサービスを提供する複数のフロントエンド5−1、5−2を1つのグループとして管理し、ネットワーク3内のノード4−1、4−2からのサービス名を指定した代替フロントエンドの問い合わせに対して、同じサービス名のサービスを提供するフロントエンドの位置情報を応答する機能を持つ。同じサービスを提供するフロントエンドが複数存在する場合、どの1つのフロントエンドを選択するかは予め定められた選択基準に従う。選択基準としては、問い合わせ元のノードに接続しているクライアントに、より近い位置のフロントエンドを選択する、最も負荷の低いフロントエンドを選択する等がある。また、同じサービスを提供するフロントエンドが1つも存在しない場合、エラー処理情報への位置情報を返却する。エラー処理情報は、例えば他のサービスを紹介するHTMLページの位置情報(URL)や、サーバ1自身がサービスの提供を行う場合にはサーバ1の当該サービスの位置情報(URL)などである。
【0023】
ネットワーク3内に存在する、フロントエンドの動作を保証する実行環境を提供することの可能なノード4−1、4−2のそれぞれは、クライアント2からの接続時、クライアント2から要求されたサービスを提供するフロントエンド5−1、5−2が自ノード上に生成されているか否かを調べる。生成されていればそのフロントエンド5−1、5−2によってサービスをクライアント2に提供する。生成されていなれば、従来技術ではエラーとなり、クライアント2はサービスを一切受けることができなかった。しかし、本実施の形態では、生成されていないことが検出されると、当該ノード4−1、4−2は、クライアント2から要求されたサービスを提供可能な他のフロントエンドを代替フロントエンド検索部6に問い合わせ、その結果返される他のフロントエンドの位置情報をクライアント2に提示する機能を有している。
【0024】
特に、本実施の形態の場合、各ノード4−1、4−2は、HTTPプロトコルで規定されているリダイレクト機能を利用して、クライアント2に他のフロントエンドの位置情報を提供する。リダイレクト機能とは、HTTPプロトコルで規定された機能の1つであり、クライアント2側のブラウザへ指定されたURL(Universal Resource Locator)をリダイレクト命令と共に送信すると、クライアント2側のブラウザが指定されたURLへ自動的に移動する機能である。
【0025】
他方、代替フロントエンドがなく、代替フロントエンド検索部6からエラー処理情報への位置情報が返された場合、ノード4−1、4−2は、それをリダイレクト機能を利用してクライアント2に提供する。
【0026】
本実施の形態は上述した構成を有するため、クライアント2が過去にアクセスしたフロントエンド5−1をブックマークしており、そのブックマークを利用してノード4−1を直接にアクセスした際、ブックマーク時点以降の負荷状況の変化に応じてフロントエンド5−1がノード4−1から削除されていると、ノード4−1から代替フロントエンド検索部6に同じサービスを提供する他のフロントエンドの問い合わせが行われる。従って、若し、ノード4−2に生成されているフロントエンド5−2が代替フロントエンドとして選択されると、その位置情報が代替フロントエンド検索部6からノード4−1へ送信され、ノード4−1からリダイレクト機能によりクライアント2へ伝達される。これにより、クライアント2のブラウザは、アクセス先をノード4−2のフロントエンド5−2へ切り替え、サービスの提供を受けることができる。また、若し、他のフロントエンドが存在しない場合、ノード5−1を通じて代替フロントエンド検索部6から通知されるエラー処理情報へのアクセスに自動的に切り替わり、例えば他のサービスを紹介するHTMLページの参照や、サーバ1自身が提供するサービスを利用することが可能となる。
【0027】
【第1の実施例】
次に本発明の第1の実施例について図面を参照して詳細に説明する。
【0028】
図2に本発明の第1の実施例にかかるWebシステムの構成例を示す。この例のWebシステムは、Webサービスを提供するサーバ1、そのサービスを利用するクライアント2−i(i=1〜5)、両者を接続するインターネット等のネットワーク3、ネットワーク3中のノード4−j(j=1〜3)上に設けられたフロントエンド5−j、配置管理サービス装置7、ロケータ8及びサービス検索サービス装置9を含んで構成される。なお、クライアント2−iにWebサービスを提供するサーバは一般に複数存在するが、図2では一つのサーバ1だけを図示してある。
【0029】
フロントエンド5−jのそれぞれは、サーバ1が提供する機能の全部または一部をサーバ1に代わってクライアント2−iに提供するプログラムである。配置管理サービス装置7は、フロントエンドの動作を保証する実行環境を提供することの可能なノード4−jの集合を特定する機能、フロントエンドの動作ノードが特定された後、どのクライアントにも均一なサービス品質でサービスを提供することを可能とするフロントエンドの配置情報を提供する機能を有する。サーバ1は、このような配置管理サービス装置7の支援の下に、ネットワーク3中のノード4−j上に自サーバ1用のフロントエンド5−jを動的に生成し、また生成したフロントエンドを削除することによって、サービス品質の保証とリソースの有効活用を図っている。
【0030】
ロケータ8は、ネットワーク3に展開されているフロントエンド5−jの位置情報や負荷状況などを収集し、同一のサービスを提供するグループ毎にフロントエンド5−jの位置情報などを保持管理している。このロケータ8は、図18に示した従来のロケータ106と同様な機能に加えて、図1に示した代替フロントエンド検索部6の機能も兼ね備えている。サービス検索サービス装置9は、クライアント2−iとロケータ8との間に介在し、サーバ1を含めて全てのサーバが提供するサービスカテゴリに関する情報やサービス提供者情報を管理し、またクライアントに代わってロケータ8へのルックアップ処理を代行する機能を有している。
【0031】
図3を参照すると、サービス検索サービス装置9は、クライアント2−iとの間でHTTPによってデータの入力及び出力を行う入力部91及び出力部92と、クライアント2−iに対してサービスを提供するサーバ1の当該サービスに関する情報(サービス情報)を記憶するサービス情報記憶部93と、このサービス情報記憶部93へサーバ1から送信されてきたサービス情報を登録するサービス情報登録部94と、サーバ1が事前に用意したエラー処理情報を記憶するエラー処理情報記憶部95と、このエラー処理情報記憶部95へサーバ1から送信されてきたエラー処理情報を登録するエラー処理情報登録部96と、サービス情報記憶部93に記憶されたサービス情報を参照してクライアント2−iからのサービス検索要求を処理するサービス検索部97と、クライアント2−iが欲するサービスを提供可能なフロントエンド5−iの位置情報をロケータ8に問い合わせる問合せ部98とを含んで構成されている。
【0032】
図3に示す記録媒体M1は、CD−ROM、半導体メモリ、磁気ディスク等の機械読み取り可能な記録媒体であり、サービス検索サービス装置用プログラムを記録している。ここに記録されたプログラムは、サービス検索サービス装置9を構成するコンピュータ(CPU、メモリ及び通信ポートを備える)に読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータ上に、入力部91、出力部92、サービス情報登録部94、エラー処理情報登録部96、サービス検索部97及び問合せ部98といった機能部を実現する。
【0033】
図4にサービス検索サービス装置9の処理例を示す。サービス検索サービス装置9は、先ず、サービス情報登録部94によって、インターネットや専用回線等の通信路を通じて、サーバ1からサービス情報を受信し、サービス情報記憶部93へ登録する(ステップS1)。ここで登録されるサービス情報は、ルックアップを行うために必要となるサービス名と、このサービス名をクライアントからのサービス検索要求中のキーワードによって検索する際のキー情報とを含む。キー情報は、1つはサービスカテゴリに関する情報であり、他の1つはサービス提供者の情報である。前者のサービスカテゴリに関する情報とは、サービスの内容が属するサービスのジャンルといったサービス自身に関する情報のことであり、具体的には、「オンラインショッピング」、「携帯端末対応」、「家電製品」、「本屋」などのキーワードで表現される。後者のサービス提供者の情報とは、サービスを提供する企業、団体、個人の名称やメールアドレス、電話番号、住所などのことである。
【0034】
次にサービス検索サービス装置9は、エラー処理情報登録部96によって、インターネットや専用回線等の通信路を通じて、サーバ1からエラー処理情報を受信し、エラー処理情報記憶部95へ登録する(ステップS2)。ここで登録されるエラー処理情報は、例えば、他のサービスを紹介するHTMLページの位置情報(URL)や、サーバ1自身がサービスの提供を行う場合にはサーバ1の当該サービスの位置情報(URL)である。なお、このエラー処理情報の登録は必須ではない。
【0035】
以上のようなサービス情報及びエラー処理情報の登録後、サービス検索サービス装置9は、クライアント2−iに対するサービス検索サービスの提供を開始する。サービス検索サービスでは、以下のような処理が行われる。
【0036】
先ず、インターネット等の通信路を通じてクライアント2−iから送信されてくるサービス検索要求を入力部91で入力する(ステップS3)。クライアント2−iから送信されるサービス検索要求には、クライアントが利用したいサービスに関するキーワードと、クライアント自身に関する情報とが含まれる。サービスに関するキーワードは、利用したいサービスの属するジャンルに関する情報やそのサービスの提供者に関する名称、メールアドレス、電話番号、住所などである。クライアント自身に関する情報とは、クライアント自身の住所などの位置情報や、使用言語、使用している端末の種類、サービスを利用する時間などの情報である。
【0037】
入力部91で受信されたクライアント2−iからのサービス検索要求は、サービス検索部97に伝達され、サービス検索部97は、サービス検索要求中のクライアントが利用したいサービスに関するキーワードに適合するキー情報を持つサービス名をサービス情報記憶部93から検索することで、利用サービスを特定する(ステップS4)。例えば、クライアントが利用したいサービスに関するキーワードとして、「家電製品」、「オンラインショッピング」を指定している場合、「家電製品」、「オンラインショッピング」をキー情報に持つサービス名をサービス情報記憶部93から検索する。なお、クライアント自身の情報もキーワードに含めて検索するようにしても良い。例えば、クライアントが利用したいサービスに関するキーワードが「家電製品」、「オンラインショッピング」であり、クライアント自身に関する情報中に「携帯端末」が含まれていた場合、「家電製品」、「オンラインショッピング」、「携帯端末」をキー情報に持つサービス名をサービス情報記憶部93から検索する。
【0038】
なお、サービス検索部97は、キーワード検索によって検索したサービス名が1つでなく、複数存在した場合は、それら全てのサービス名を記載した一覧を出力部92を通じて検索要求元のクライアント2−iに提示し、クライアント2−iに1つのサービス名を選択させることにより、サービス名を1つに決定する処理をステップS4で実施する。
【0039】
サービス名が決定すると、サービス検索部97は、決定したサービス名とサービス検索要求中のクライアント自身に関する情報とを問合せ部98に伝達し、問合せ部98はそれらを含むルップアップ要求を通信路を通じてロケータ8へ送信する(ステップS5)。そして、ロケータ8からの応答データを受信すると、問合せ部98は、応答データで示されるフロントエンドの位置情報やエラー処理情報の位置情報を、HTTPプロトコルで規定されるリダイレクト機能を利用してクライアント2−iへ提供する(ステップS6)。
【0040】
図5を参照すると、ロケータ8は、ノード4−j及びサービス検索サービス装置9との間でデータの入力及び出力を行う入力部81及び出力部82と、ネットワーク3内のフロントエンドに関する情報及びネットワーク3に関する情報を定期的に収集する情報収集部83と、この情報収集部83で収集された情報を記憶する情報記憶部84と、ノード4−j上のフロントエンド5−jが正常に動作しているか否かを検査する検査部85と、情報記憶部84に記憶された情報及び検査部85を使用してノード4−jまたはサービス検索サービス装置9からの問い合わせに答えるルックアップ部86とを含んで構成されている。
【0041】
図5に示す記録媒体M2は、CD−ROM、半導体メモリ、磁気ディスク等の機械読み取り可能な記録媒体であり、ロケータ用プログラムを記録している。ここに記録されたプログラムは、ロケータ8を構成するコンピュータ(CPU、メモリ及び通信ポートを備える)に読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータ上に、入力部81、出力部82、情報収集部83、検査部85及びルックアップ部86といった機能部を実現する。
【0042】
情報収集部83が定期的に収集するフロントエンドに関する情報は、フロントエンド5−jの位置情報(URL)、フロントエンド5−jの提供するサービス名、フロントエンド5−jの負荷状況などである。また、情報収集部83が定期的に収集するネットワーク3に関する情報は、ネットワーク3内の障害情報や混雑状況などである。
【0043】
図6に、サービス検索サービス装置9からルックアップ要求にかかる問い合わせがあった際のロケータ8の処理例を示す。ロケータ8は、サービス検索サービス装置9からの問い合わせを入力部81を通じて入力すると、それをルックアップ部86に伝達する(ステップS11)。サービス検索サービス装置9からの問い合わせでは、ルップアップを行うサービス名と、クライアント自身に関する情報とが指定されている。ルックアップ部86では、以下のような処理が実行される。
【0044】
先ず、問い合わせで指定されたサービス名をキーにして情報記憶部84に記憶されているフロントエンドに関する情報を検索し、当該サービス名のサービスを提供している全てのフロントエンドを特定する(ステップS12)。次に、特定したフロントエンドが複数存在した場合には、所定の規則に従って、その内の1つを選択する(ステップS13)。このステップS13の処理の詳細については後述する。次に、選択したフロントエンドが実際に動作しているか否かを検査部85を通じて検査する(ステップS14)。この検査は、例えば、選択したフロントエンドが存在するノードに対して当該フロントエンドが提供するサービス名を通知し、該当するフロントエンドが動作しているか否かを調べることで行われる。次に、当該フロントエンドが実際に動作していた場合(ステップS15でYES)、当該フロントエンドの位置情報(URL)を出力部82を通じて問い合わせ元のサービス検索サービス装置9に通知する(ステップS16)。
【0045】
他方、当該フロントエンドが実際に動作していなかった場合(ステップS15でNO)、ステップS12で特定したフロントエンドが複数存在し、未だ候補にしていない他のフロントエンドがあれば(ステップS17でYES)、ステップS13に戻って、それらの他のフロントエンドから1つのフロントエンドを選択し、そのフロントエンドの動作確認を行う(ステップS14)。このステップS13からステップS17のループ処理は、正常に動作しているフロントエンドが発見されるか、候補とすべきフロントエンドがなくなるまで続けられる。
【0046】
ステップS12で特定した全てのフロントエンドが正常に動作していなかった場合(ステップS17でNO)、ルックアップ部86は、サービス検索サービス装置9のエラー処理情報記憶部95を参照し、そこにルップアップを行うサービス名のサービスを提供するサーバ1によって登録されたエラー処理情報が記憶されていれば(ステップS18でYES)、このエラー処理情報が示す位置情報(URL)を出力部82を通じて問い合わせ元のサービス検索サービス装置9に通知する(ステップS19)。他方、サーバ1によるエラー処理情報がエラー処理情報記憶部95に登録されていなければ(ステップS18でNO)、ルックアップ部86内に事前に登録されているエラー処理情報の位置情報(URL)を出力部82を通じて問い合わせ元のサービス検索サービス装置9に通知する(ステップS20)。
【0047】
図7に、ノード4−jからルックアップ要求にかかる問い合わせがあった際のロケータ8の処理例を示す。ロケータ8は、ノード4−jからの問い合わせを入力部81を通じて入力すると、それをルックアップ部86に伝達する(ステップS21)。ノード4−jからの問い合わせでは、ルップアップを行うサービス名と、クライアント自身に関する情報としてクライアントのIPアドレスとが指定されている。ルックアップ部86では、以下のような処理が実行される。
【0048】
先ず、問い合わせで指定されたサービス名をキーにして情報記憶部84に記憶されているフロントエンドに関する情報を検索し、当該サービス名のサービスを提供している全てのフロントエンドを特定する(ステップS22)。但し、問い合わせ元のノード4−j上のフロントエンドはたとえ検索されても除外する。次に、特定したフロントエンドが複数存在した場合には、所定の規則に従って、その内の1つを選択する(ステップS23)。このステップS23の処理の詳細については後述する。次に、選択したフロントエンドが実際に動作しているか否かを検査部85を通じて検査する(ステップS24)。この検査は、例えば、選択したフロントエンドが存在するノード4−k(k≠j)に対して当該フロントエンドが提供するサービス名を通知し、該当するフロントエンドが動作しているか否かを調べることで行われる。次に、当該フロントエンドが実際に動作していた場合(ステップS25でYES)、当該フロントエンドの位置情報(URL)を出力部82を通じて問い合わせ元のノード4−jに通知する(ステップS26)。
【0049】
他方、当該フロントエンドが実際に動作していなかった場合(ステップS25でNO)、ステップS22で特定したフロントエンドが複数存在し、未だ候補にしていない他のフロントエンドがあれば(ステップS27でYES)、ステップS23に戻って、それらの他のフロントエンドから1つのフロントエンドを選択し、そのフロントエンドの動作確認を行う(ステップS24)。このステップS23からステップS27のループ処理は、正常に動作しているフロントエンドが発見されるか、候補とすべきフロントエンドがなくなるまで続けられる。
【0050】
ステップS22で特定した全てのフロントエンドが正常に動作していなかった場合(ステップS27でNO)、ルックアップ部86は、サービス検索サービス装置9のエラー処理情報記憶部95を参照し、そこにルップアップを行うサービス名のサービスを提供するサーバ1によって登録されたエラー処理情報が記憶されていれば(ステップS28でYES)、このエラー処理情報が示す位置情報(URL)を出力部82を通じて問い合わせ元のノード4−jに通知する(ステップS29)。他方、サーバ1によるエラー処理情報がエラー処理情報記憶部95に登録されていなければ(ステップS28でNO)、ルックアップ部86内に事前に登録されているエラー処理情報の位置情報(URL)を出力部82を通じて問い合わせ元のノード4−jに通知する(ステップS20)。
【0051】
次に、図6のステップS13及び図7のステップS23におけるフロントエンドの選定方法について説明する。同じサービスを提供する複数のフロントエンドが存在した場合に、その何れのフロントエンドを選択すべきかについては、幾つかの基準が考えられる。その一つは、クライアントとフロントエンドとの距離的な近さを考慮し、クライアントに最も近い位置で動作するフロントエンドを選択する方法である。この選択方法を採用する場合、フロントエンドの位置とクライアントの位置とを求める必要がある。
【0052】
フロントエンドの位置は、例えば以下のような方法で求めることができる。先ず、情報収集部83は、ネットワーク3内で固定されているルータ(図示せず)に関する位置情報を事前に把握し保持しておく。次に、ネットワーク3内に存在するフロントエンドに対して、“traceroute”と呼ばれるコマンドを発行する。この“traceroute”と呼ばれるコマンドは、発信地点から目的とする地点へ到達するまでの経路情報を教えてくれるコマンドである。こうして情報収集部83は、フロントエンドに対して、tracerouteコマンドを発行し、フロントエンドへの経路情報を獲得する。そして、獲得した経路情報の中で、フロントエンドに到達する直線に経由したルータの情報を取得し、このルータの情報を予め保持しているルータの位置情報と比較することで、フロントエンドの位置を予測する。この処理をネットワーク3に存在するフロントエンド全てに対して行うことで、全てのフロントエンドの位置を予測する。予測した各フロントエンドの位置は情報記憶部84に記憶し、必要時に参照する。
【0053】
クライアントの位置は、そのクライアントのIPアドレスが分かっている場合には、フロントエンドの位置を求める上述したtracerouteコマンドによる方法と同じ方法で求めることができる。また、クライアントから自身の位置情報が入力されている場合には、この位置情報から直ちに判明する。
【0054】
さて、クライアントとフロントエンドとの距離的な近さを考慮してフロントエンドを選定する場合、図6のステップS13にあっては、ステップS12で特定されたフロントエンドのうち、ステップS11で入力した問い合わせ中で指定されたクライアント自身の位置情報が示す位置に最も近い位置に存在するフロントエンドが第1候補として選択される。また、ステップS17からステップS13に再度戻ってきた場合には、次に距離の近いフロントエンドが第2候補として選択される。以下、同様に第3候補、第4候補、…の選択が行われる。
【0055】
また、図7のステップ23にあっては、ステップS22で特定されたフロントエンドのうち、ステップS21で入力した問い合わせ中で指定されたクライアントのIPアドレスから求めたクライアントの位置に最も近い位置に存在するフロントエンドが第1候補として選択される。また、ステップS27からステップS23に再度戻ってきた場合には、次に距離の近いフロントエンドが第2候補として選択される。以下、同様に第3候補、第4候補、…の選択が行われる。
【0056】
図6のステップS13及び図7のステップS23におけるフロントエンドの選定方法の別の例は、フロントエンドの負荷状況を考慮し、より負荷の小さなフロントエンドを選択する方法である。この選択方法を採用する場合、情報収集部83が定期的に収集して情報記憶部84に記憶している各フロントエンドの負荷状況を参照してフロントエンドの選択が行われる。即ち、図6のステップS13及び図7のステップ23とも、ステップS12及びステップS22で特定されたフロントエンドのうち、情報記憶部84に記録されている負荷が最も小さいフロントエンドが第1候補として選択される。また、ステップS17及びステップS27からステップS13及びステップS23に再度戻ってきた場合には、次に負荷の小さいフロントエンドが第2候補として選択される。以下、同様に第3候補、第4候補、…の選択が行われる。
【0057】
図8を参照すると、ノード4−jは、クライアント2−iとの間でHTTPによってデータの入力及び出力を行う入力部41及び出力部42と、フロントエンド5−jの実行環境45と、所定のサービス名のサービスを提供するフロントエンド5−jが実行環境45上に存在しているか否かの確認を行う確認部43と、ロケータ8に対して代替フロントエンドのルップアップにかかる問い合わせを行う問合せ部44とを含んで構成されている。
【0058】
図8に示す記録媒体M3は、CD−ROM、半導体メモリ、磁気ディスク等の機械読み取り可能な記録媒体であり、ノード用プログラムを記録している。ここに記録されたプログラムは、ノード4−jを構成するコンピュータ(CPU、メモリ及び通信ポートを備える)に読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータ上に、入力部41、出力部42、確認部43、問合せ部44及び実行環境45といった機能部を実現する。
【0059】
図9にクライアント2−iからアクセスがあった際のノード4−jの処理例を示す。ノード4−jは、クライアント2−iからアクセスがあると、クライアント2−iがアクセスする位置情報(URL)とクライアント2−iのIPアドレスとを入力部41を通じて確認部43に入力する(ステップS31)。確認部43は、クライアント2−iがアクセスする位置情報(URL)を元に、当該位置情報に対応するサービス名のサービスを提供するフロントエンド5−jが自ノード4−jの実行環境45上に存在しているか否かを判定する(ステップS32)。該当するフロントエンド5−jが存在した場合(ステップS32でYES)、ノード4−jは当該フロントエンド5−jによってクライアント2−iに対してサービスを提供する(ステップS33)。提供されるサービスにかかるテキストや画像等は出力部42を通じてフロントエンド5−jからクライアント2−iに送られる。
【0060】
他方、該当するフロントエンド5−jが自ノード上に存在しなかった場合(ステップS32でNO)、確認部43は、位置情報(URL)から特定されるサービス名とクライアント2−iのIPアドレスとを問合せ部44に伝達し、問合せ部44はこれらを指定したルックアップ要求にかかる問い合わせをロケータ8に対して送信する(ステップS34)。そして、ロケータ8からの応答データを受信すると、問合せ部44は、応答データで示されるフロントエンドの位置情報やエラー処理情報の位置情報を、HTTPプロトコルで規定されるリダイレクト機能を利用してクライアント2−iへ提供する(ステップS35)。
【0061】
一方、ノード4−jの確認部43は、ロケータ8の図6のステップS14及び図7のステップS24で自ノードに対してサービス名を指定して該当するフロントエンドの動作状況の問い合わせがあった場合、該当するフロントエンド5−jが自ノード4−jの実行環境45上に存在しているか否かを調べ、その結果をロケータ8に応答する処理も行っている。
【0062】
次に図10の実行シーケンスを参照して、本実施例の動作を説明する。
【0063】
図10を参照すると、サーバ1はノード4−1〜4−3上にフロントエンド5−1〜5−3をそれぞれ生成し(ステップS41)、ロケータ8はフロントエンド5−1〜5−3の位置情報や各ノード4−1〜4−3の負荷状況などを定期的に収集している(ステップS42)。また、サーバ1はサービス情報及びエラー処理情報をサービス検索サービス装置9へ送信し、登録を行っている(ステップS43)。このような状況の下、クライアント2−1からサービス検索サービス装置9に対してサービス検索要求が送信されると(ステップS44)、サービス検索サービス装置9は、サービス検索要求中のキーワード等と自身が保有するサービス情報とからクライアント2−1が欲するサービス名を検索し、検索結果をクライアント2−1に提示し(ステップS45)、クライアント2−1はその検索結果の中から1つのサービス名を選択する(ステップS46)。
【0064】
次にサービス検索サービス装置9は、クライアント2−1が選択したサービス名及びクライアント2−1の位置などを指定したルックアップ要求をロケータ8へ送信する(ステップS47)。ロケータ8は、サービス名に基づいて当該サービスを提供可能な複数のフロントエンド5−1〜5−3を特定し、その中から例えばクライアント2−1に最も近い場所にあるフロントエンド5−2を選択する(ステップS48)。そして、フロントエンド5−2が動作していることを確認し(ステップS49)、フロントエンド5−2の位置情報(URL)をサービス検索サービス装置9へ通知する(ステップS50)。サービス検索サービス装置9は、フロントエンド5−2の位置情報をリダイレクト機能によりクライアント2−1に提供する(ステップS51)。これによりクライアント2−1は、ノード4−2上にあるフロントエンド5−2のサービスをアクセスし(ステップS52)、サービスの提供を受ける(ステップS53)。また、クライアント2−1は、後の利用に備えてフロントエンド5−2のサービスをブックマークする(ステップS54)。
【0065】
その後、フロントエンド5−2の利用率が低下したため、サーバ1はノード4−2上のフロントエンド5−2を削除している(ステップS55)。この削除後にクライアント2−1がブックマークを利用してフロントエンド5−2のサービスにアクセスすると(ステップS56)、ノード4−2上に該当するフロントエンド5−2が存在しないことが検出され(ステップS57)、ノード4−2からロケータ8に対して代替フロントエンドの問い合わせが行われる(ステップS58)。ロケータ8は、例えばフロントエンド5−3を代替フロントエンドに決定し(ステップS59)、その動作を確認後(ステップS60)、フロントエンド5−3の位置情報(URL)をノード4−2へ通知する(ステップS61)。ノード4−2は、フロントエンド5−2の位置情報(URL)をリダイレクト機能によりクライアント2−1に提供する(ステップS62)。これにより、クライアント2−1は、ノード4−3上にあるフロントエンド5−3のサービスをアクセスし(ステップS63)、そのサービスの提供を受ける(ステップS64)。このようにブックマーク後にフロントエンドが削除されてしまっていても、他のフロントエンドによってクライアントに対して同種のサービスを提供することが可能となる。
【0066】
なお、ノード4−3上のフロントエンド5−3及びノード4−1上のフロントエンド5−1が動作していない場合、クライアント2−1にサーバを提供するフロントエンドが1つも存在しないため、ロケータ8は、サービス検索サービス装置9に登録されたサーバ1用のエラー処理情報が示す位置情報(URL)をノード4−2に通知し、ノード4−2はそれをリダイレクト機能によりクライアント2−1に提供する。このため、全てのフロントエンド5−1〜5−3が使用できない場合でも、クライアント2−1はサーバ1自身が提供するサービスを利用することが可能となる。
【0067】
【第2の実施例】
次に本発明の第2の実施例について図面を参照して詳細に説明する。
【0068】
図11に本発明の第2の実施例にかかるWebシステムの構成例を示す。この例のWebシステムは、Webサービスを提供するサーバ1A、そのサービスを利用するクライアント2−i(i=1〜5)、両者を接続するインターネット等のネットワーク3、ネットワーク3中のノード4−j(j=1〜3)上に設けられたフロントエンド5−j、配置管理サービス装置7及びロケータ8Aを含んで構成され、図2に示した第1の実施例と異なりサービス検索サービス装置は存在しない。また、サーバ1Aとロケータ8Aとは相互に通信可能に接続されている。なお、クライアント2−iにWebサービスを提供するサーバは一般に複数存在するが、図11では一つのサーバ1Aだけを図示してある。
【0069】
フロントエンド5−jのそれぞれは、サーバ1Aが提供する機能の全部または一部をサーバ1Aに代わってクライアント2−iに提供するプログラムである。配置管理サービス装置7は第1の実施例におけるものと同じであり、サーバ1Aは配置管理サービス装置7の支援の下に、ネットワーク3中のノード4−j上に自サーバ1A用のフロントエンド5−jを動的に生成し、また生成したフロントエンド5−jを削除することによって、サービス品質の保証とリソースの有効活用を図っている。
【0070】
図12を参照すると、サーバ1Aは、クライアント2−iとの間でHTTPによってデータの入力及び出力を行う入力部11及び出力部12と、サーバ1A用の全てのフロントエンド5−jが使用できない場合にサーバ1A自身がクライアント2−iに対してサービスを提供するためのサービス提供部13と、サービス提供部13が提供するサービスの位置情報(URL)をエラー処理情報として記憶するエラー処理情報記憶部14と、クライアント2−iに対するサービスを提供可能なフロントエンド5−jの位置情報をロケータ8Aに問い合わせる問合せ部15とを含んで構成されている。ここで、サーバ1Aがフロントエンド5−jを通じてクライアント2−iに提供するサービスの位置情報(URL)と、サーバ1A自身がクライアント2−iに提供するサービスの位置情報(URL)とは相違している。前者を複製サービス用位置情報、後者をエラー時サービス用位置情報と呼んで区別する。
【0071】
図12に示す記録媒体M4は、CD−ROM、半導体メモリ、磁気ディスク等の機械読み取り可能な記録媒体であり、サーバ用プログラムを記録している。ここに記録されたプログラムは、サーバ1Aを構成するコンピュータ(CPU、メモリ及び通信ポートを備える)に読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータ上に、入力部11、出力部12、サービス提供部13及び問合せ部15といった機能部を実現する。
【0072】
図13にサーバ1Aの処理例を示す。サーバ1Aは、インターネット等の通信路を通じてクライアント2−iから自サーバ1Aがアクセスされると、クライアント2−iが接続してきたサービスの位置情報(URL)及びクライアント2−iのIPアドレス等のクライアント情報を入力部11を通じて入力する(ステップS101)。次に、サービスの位置情報(URL)が複製サービス用位置情報か、エラー時サービス用位置情報かを判別する(ステップS102)。複製サービス用位置情報であれば、複製サービス用位置情報からサービス名が一意に決定されるので、この決定されるサービス名とクライアント情報とを指定して問合せ部15を通じてロケータ8Aにルックアップ要求にかかる問い合わせを行う(ステップS103)。そして、ロケータ8Aからの応答データを受信すると、問合せ部15は、応答データで示されるフロントエンドの位置情報やエラー処理情報の位置情報を、HTTPプロトコルで規定されるリダイレクト機能を利用してクライアント2−iへ提供する(ステップS104)。他方、エラー時サービス用位置情報であれば(ステップS102でNO)、サービス提供部13によりクライアント2−iに対して出力部12を通じてサービスを提供する(ステップS105)。
【0073】
ロケータ8Aは、ネットワーク3に展開されているフロントエンド5−jの位置情報や負荷状況などを収集し、同一のサービスを提供するグループ毎にフロントエンド5−jの位置情報などを保持管理している。このロケータ8Aは、サーバ1Aからのルックアップ要求を処理する機能に加えて、図1に示した代替フロントエンド検索部6の機能も兼ね備えている。
【0074】
図14を参照すると、ロケータ8Aは、ノード4−j及びサーバ1Aとの間でデータの入力及び出力を行う入力部81及び出力部82と、ネットワーク3内のフロントエンドに関する情報及びネットワーク3に関する情報を定期的に収集する情報収集部83と、この情報収集部83で収集された情報を記憶する情報記憶部84と、ノード4−j上のフロントエンド5−jが正常に動作しているか否かを検査する検査部85と、情報記憶部84に記憶された情報及び検査部85を使用してノード4−jまたはサーバ1Aからの問い合わせに答えるルックアップ部86とを含んで構成されている。
【0075】
図14に示す記録媒体M5は、CD−ROM、半導体メモリ、磁気ディスク等の機械読み取り可能な記録媒体であり、ロケータ用プログラムを記録している。ここに記録されたプログラムは、ロケータ8Aを構成するコンピュータ(CPU、メモリ及び通信ポートを備える)に読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータ上に、入力部81、出力部82、情報収集部83、検査部85及びルックアップ部86といった機能部を実現する。
【0076】
情報収集部83が定期的に収集するフロントエンドに関する情報は、フロントエンド5−jの位置情報(URL)、フロントエンド5−jの提供するサービス名、フロントエンド5−jの負荷状況などである。また、情報収集部83が定期的に収集するネットワーク3に関する情報は、ネットワーク3内の障害情報や混雑状況などである。
【0077】
図15に、サーバ1Aからルックアップ要求にかかる問い合わせがあった際のロケータ8Aの処理例を示す。ロケータ8Aは、サーバ1Aからの問い合わせを入力部81を通じて入力すると、それをルックアップ部86に伝達する(ステップS11)。サーバ1Aからの問い合わせでは、ルップアップを行うサービス名と、クライアント自身に関する情報としてクライアントのIPアドレスが指定されている。ルックアップ部86では、以下のような処理が実行される。
【0078】
先ず、問い合わせで指定されたサービス名をキーにして情報記憶部84に記憶されているフロントエンドに関する情報を検索し、当該サービス名のサービスを提供している全てのフロントエンドを特定する(ステップS12)。次に、特定したフロントエンドが複数存在した場合には、第1の実施例と同様な規則に従って、その内の1つを選択する(ステップS13)。次に、選択したフロントエンドが実際に動作しているか否かを第1の実施例と同様に検査部85を通じて検査する(ステップS14)。次に、当該フロントエンドが実際に動作していた場合(ステップS15でYES)、当該フロントエンドの位置情報(URL)を出力部82を通じて問い合わせ元のサーバ1Aに通知する(ステップS16)。
【0079】
他方、当該フロントエンドが実際に動作していなかった場合(ステップS15でNO)、ステップS12で特定したフロントエンドが複数存在し、未だ候補にしていない他のフロントエンドがあれば(ステップS17でYES)、ステップS13に戻って、それらの他のフロントエンドから1つのフロントエンドを選択し、そのフロントエンドの動作確認を行う(ステップS14)。このステップS13からステップS17のループ処理は、正常に動作しているフロントエンドが発見されるか、候補とすべきフロントエンドがなくなるまで続けられる。
【0080】
ステップS12で特定した全てのフロントエンドが正常に動作していなかった場合(ステップS17でNO)、ルックアップ部86は、サーバ1Aのエラー処理情報記憶部14を参照し、エラー処理情報が記憶されていれば(ステップS18でYES)、このエラー処理情報が示す位置情報(URL)を出力部82を通じて問い合わせ元のサーバ1Aに通知する(ステップS19)。他方、エラー処理情報がエラー処理情報記憶部14に登録されていなければ(ステップS18でNO)、ルックアップ部86内に事前に登録されているエラー処理情報の位置情報(URL)を出力部82を通じて問い合わせ元のサーバ1Aに通知する(ステップS20)。
【0081】
図16に、ノード4−jからルックアップ要求にかかる問い合わせがあった際のロケータ8Aの処理例を示す。ロケータ8Aは、ノード4−jからの問い合わせを入力部81を通じて入力すると、それをルックアップ部86に伝達する(ステップS21)。ノード4−jからの問い合わせでは、ルップアップを行うサービス名と、クライアント自身に関する情報としてクライアントのIPアドレスが指定されている。ルックアップ部86では、以下のような処理が実行される。
【0082】
先ず、問い合わせで指定されたサービス名をキーにして情報記憶部84に記憶されているフロントエンドに関する情報を検索し、当該サービス名のサービスを提供している全てのフロントエンドを特定する(ステップS22)。但し、問い合わせ元のノード4−jのフロントエンド5−jはたとえ検索されても除外する。次に、特定したフロントエンドが複数存在した場合には、第1の実施例と同様に所定の規則に従って、その内の1つを選択する(ステップS23)。次に、選択したフロントエンドが実際に動作しているか否かを検査部85を通じて検査する(ステップS24)。次に、当該フロントエンドが実際に動作していた場合(ステップS25でYES)、当該フロントエンドの位置情報(URL)を出力部82を通じて問い合わせ元のノード4−jに通知する(ステップS26)。
【0083】
他方、当該フロントエンドが実際に動作していなかった場合(ステップS25でNO)、ステップS22で特定したフロントエンドが複数存在し、未だ候補にしていない他のフロントエンドがあれば(ステップS27でYES)、ステップS23に戻って、それらの他のフロントエンドから1つのフロントエンドを選択し、そのフロントエンドの動作確認を行う(ステップS24)。このステップS23からステップS27のループ処理は、正常に動作しているフロントエンドが発見されるか、候補とすべきフロントエンドがなくなるまで続けられる。
【0084】
ステップS22で特定した全てのフロントエンドが正常に動作していなかった場合(ステップS27でNO)、ルックアップ部86は、ルックアップを行うサービス名のサービスを提供するサーバ1Aのエラー処理情報記憶部14を参照し、エラー処理情報が記憶されていれば(ステップS28でYES)、このエラー処理情報が示す位置情報(URL)を出力部82を通じて問い合わせ元のノード4−jに通知する(ステップS29)。他方、サーバ1Aにエラー処理情報が登録されていなければ(ステップS28でNO)、ルックアップ部86内に事前に登録されているエラー処理情報の位置情報(URL)を出力部82を通じて問い合わせ元のノード4−jに通知する(ステップS30)。
【0085】
ノード4−jの構成と動作は、図8及び図9に示した第1の実施例におけるノードと同じである。
【0086】
次に図17の実行シーケンスを参照して、本実施例の動作を説明する。
【0087】
図17を参照すると、サーバ1Aはノード4−1〜4−3上にフロントエンド5−1〜5−3をそれぞれ生成し(ステップS111)、ロケータ8Aはフロントエンド5−1〜5−3の位置情報や各ノード4−1〜4−2の負荷状況などを定期的に収集している(ステップS112)。このような状況の下、クライアント2−1が複製サービス用位置情報(URL)を使ってサーバ1Aのサービスにアクセスすると(ステップS113)、サーバ1Aは、複製サービス用位置情報(URL)からサービス名を決定し、このサービス名とクライアント情報(IPアドレス)とを指定したルックアップ要求をロケータ8Aへ送信する(ステップS114)。ロケータ8Aは、サービス名に基づいて当該サービスを提供可能な複数のフロントエンド5−1〜5−3を特定し、その中から例えばクライアント2−1に最も近い場所にあるフロントエンド5−2を選択する(ステップS115)。そして、フロントエンド5−2が動作していることを確認し(ステップS116)、フロントエンド5−2の位置情報(URL)をサーバ1Aへ通知する(ステップS117)。サーバ1Aは、フロントエンド5−2の位置情報をリダイレクト機能によりクライアント2−1に提供する(ステップS118)。これによりクライアント2−1は、ノード4−2上にあるフロントエンド5−2のサービスをアクセスし(ステップS119)、サービスの提供を受ける(ステップS120)。また、クライアント2−1は、後の利用に備えてフロントエンド5−2のサービスをブックマークする(ステップS121)。
【0088】
その後、フロントエンド5−2の利用率が低下したため、サーバ1Aはノード4−2上のフロントエンド5−2を削除している(ステップS122)。この削除後にクライアント2−1がブックマークを利用してフロントエンド5−2のサービスにアクセスすると(ステップS123)、ノード4−2上に該当するフロントエンド5−2が存在しないことが検出され(ステップS124)、ノード4−2からロケータ8Aに対して代替フロントエンドの問い合わせが行われる(ステップS125)。ロケータ8Aは、例えばフロントエンド5−3を代替フロントエンドに決定し(ステップS126)、その動作を確認後(ステップS127)、フロントエンド5−3の位置情報(URL)をノード4−2へ通知する(ステップS128)。ノード4−2は、フロントエンド5−2の位置情報(URL)をリダイレクト機能によりクライアント2−1に提供する(ステップS129)。これにより、クライアント2−1は、ノード4−3上にあるフロントエンド5−3のサービスをアクセスし(ステップS130)、そのサービスの提供を受ける(ステップS131)。このようにブックマーク後にフロントエンドが削除されてしまっていても、他のフロントエンドによってクライアントに対して同種のサービスを提供することが可能となる。
【0089】
なお、ノード4−3上のフロントエンド5−3及びノード4−1上のフロントエンド5−1が動作していない場合、クライアント2−1にサーバを提供するフロントエンドが1つも存在しないため、ロケータ8Aは、サーバ1Aのエラー処理情報記憶部14に記憶されたエラー処理情報(エラー時サービス用位置情報)をノード4−2に通知し、ノード4−2はそれをリダイレクト機能によりクライアント2−1に提供する。このため、全てのフロントエンド5−1〜5−3が使用できない場合でも、クライアント2−1はサーバ1Aのサービス提供部13が提供するサービスを利用することが可能となる。
【0090】
【発明の効果】
以上説明したように本発明によれば、フロントエンドを使って負荷分散を行うWebシステムにおいて、クライアントがブックマークを利用してフロントエンドの搭載されるノードを直接にアクセスした場合でも、サービスへのアクセスを保証することができる。その理由は、当該ノード上のフロントエンドが既に削除されている場合、当該ノードからロケータ(代替フロントエンド検索部)に対して他のフロントエンドの位置情報の問い合わせが行われ、その位置情報がクライアントに提供されるからである。
【0091】
また、フロントエンドの位置情報をリダイレクト機能によってクライアントに提供することにより、サービスに接続するまでに要する時間を短縮でき、サービスへのシームレスな接続が可能となる。
【0092】
更に、ロケータはフロントエンドの位置情報を応答する前にそのフロントエンドが実際に動作していることを確認しているため、信頼性の高いサービスアクセスを実現することができる。
【図面の簡単な説明】
【図1】本発明の実施の形態にかかるWebシステムのブロック図である。
【図2】本発明の第1の実施例にかかるWebシステムのブロック図である。
【図3】本発明の第1の実施例にかかるWebシステムにおけるサービス検索サービス装置のブロック図である。
【図4】本発明の第1の実施例にかかるWebシステムにおけるサービス検索サービス装置の処理例を示すフローチャートである。
【図5】本発明の第1の実施例にかかるWebシステムにおけるロケータのブロック図である。
【図6】本発明の第1の実施例にかかるWebシステムにおけるロケータにおいて、サービス検索サービス装置からルックアップ要求にかかる問に合わせがあった際の処理例を示すフローチャートである。
【図7】本発明の第1の実施例にかかるWebシステムにおけるロケータにおいて、ノードからルックアップ要求にかかる問い合わせがあった際の処理例を示すフローチャートである。
【図8】本発明の第1の実施例にかかるWebシステムにおけるノードのブロック図である。
【図9】本発明の第1の実施例にかかるWebシステムにおけるノードにおいて、クライアントからアクセスがあった際の処理例を示すフローチャートである。
【図10】本発明の第1の実施例にかかるWebシステムの動作を説明するための実行シーケンス図である。
【図11】本発明の第2の実施例にかかるWebシステムのブロック図である。
【図12】
本発明の第2の実施例にかかるWebシステムのサーバのブロック図である。
【図13】
本発明の第2の実施例にかかるWebシステムのサーバの処理例を示すフローチャートである。
【図14】本発明の第2の実施例にかかるWebシステムのロケータのブロック図である。
【図15】本発明の第2の実施例にかかるWebシステムのロケータにおいて、サーバからルックアップ要求にかかる問い合わせがあった際の処理例を示すフローチャートである。
【図16】本発明の第2の実施例にかかるWebシステムのロケータにおいて、ノードからルックアップ要求にかかる問い合わせがあった際の処理例を示すフローチャートである。
【図17】本発明の第2の実施例にかかるWebシステムの動作を説明するための実行シーケンス図である。
【図18】フロントエンドを使って負荷分散を行ったWebシステムの従来構成例を示すブロック図である。
【符号の説明】
1、1A…サーバ
2、2−1〜2−5…クライアント
3…ネットワーク
4−1〜4−3…ノード
5−1〜5−3…フロントエンド
6…代替フロントエンド検索部
7…配置管理サービス(Allocation Management Servece;AMS)装置
8、8A…ロケータ
9…サービス検索サービス(Service Discovery Service;SDS)装置
Claims (10)
- サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたWebシステムにおいて、
サービス名を指定した問い合わせに対して、当該サービス名のサービスを提供するフロントエンドの位置情報を応答する代替フロントエンド検索部を備え、
前記ノードのそれぞれは、前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しない場合にサービス名を指定した問い合わせを前記代替フロントエンド検索部に行い、その応答として得られたフロントエンドの位置情報を前記クライアントに提供する問合せ部を備えることを特徴とするWebシステム。 - 前記問合せ部は、HTTPプロトコルで規定されたリダイレクト機能によって代替フロントエンドの位置情報を前記クライアントに提供する構成を有する請求項1記載のWebシステム。
- サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたWebシステムにおいて、
前記ネットワーク中の前記フロントエンドの情報を定期的に収集し、この収集した情報を参照して、サービス名を指定した問い合わせに対して、当該サービス名のサービスを提供するフロントエンドの位置情報を応答するロケータと、
前記サーバが提供するサービスに関する情報を記憶し、この記憶した情報を参照して、前記クライアントからのキーワードを指定した問い合わせに対して該当するサービス名を決定し、且つ、決定したサービス名を指定した問い合わせを前記ロケータに送出することによって前記ロケータから得たフロントエンドの位置情報をHTTPプロトコルで規定されたリダイレクト機能によって前記クライアントに提供するサービス検索サービス装置とを備え、且つ、
前記ノードのそれぞれは、前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しない場合にサービス名を指定した問い合わせを前記ロケータに行い、その応答として得られたフロントエンドの位置情報をHTTPプロトコルで規定されたリダイレクト機能によって前記クライアントに提供する問合せ部を備えることを特徴とするWebシステム。 - サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたWebシステムにおいて、
前記ネットワーク中の前記フロントエンドの情報を定期的に収集し、この収集した情報を参照して、サービス名を指定した問い合わせに対して当該サービス名のサービスを提供するフロントエンドの位置情報を応答するロケータを備え、且つ、 前記サーバは、前記クライアントからのアクセス時、前記クライアントがアクセスしたサービスの位置情報によって一意に決定されるサービス名を指定した問い合わせを前記ロケータに送出することによって前記ロケータから得たフロントエンドの位置情報をHTTPプロトコルで規定されたリダイレクト機能によって前記クライアントに提供するサーバ側問合せ部を備え、且つ、
前記ノードのそれぞれは、前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しない場合にサービス名を指定した問い合わせを前記ロケータに行い、その応答として得られた代替フロントエンドの位置情報をHTTPプロトコルで規定されたリダイレクト機能によって前記クライアントに提供するノード側問合せ部を備えることを特徴とするWebシステム。 - 前記ロケータは、フロントエンドの位置情報を応答する前に当該フロントエンドが実際に動作しているか否かを検査する検査部を備える請求項3または4記載のWebシステム。
- 前記ロケータは、利用可能なフロントエンドが1つも存在しなかった場合、エラー処理情報の位置情報を応答として返却する構成を有する請求項3または4記載のWebシステム。
- サービスを提供するサーバと前記サービスの提供を受けるクライアントとを相互に接続するネットワーク中に存在し、前記サーバが提供するサービスの少なくとも一部を提供するフロントエンドが動的に生成、削除されるノード装置において、
前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在するか否かを確認する確認手段と、
前記フロントエンドが自ノード上に存在しない場合に、サービス名を指定した問い合わせに対して当該サービス名のサービスを提供するフロントエンドの位置情報を応答するロケータに対して、サービス名を指定した代替フロントエンドの問い合わせを行い、その応答として得られた代替フロントエンドの位置情報をHTTPプロトコルで規定されたリダイレクト機能によって前記クライアントに提供する問合せ部を備えることを特徴とするノード装置。 - サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたWebシステムにおける前記ノードと相互に通信可能なロケータ装置であって、
前記ネットワーク中の前記フロントエンドの情報を定期的に収集して記憶する手段と、
収集した情報を参照して、前記クライアントからのアクセス時に自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しなかった前記ノードからのサービス名を指定した問い合わせに対して当該サービス名のサービスを提供するフロントエンドの位置情報を応答する手段とを備えたロケータ装置。 - サービスを提供するサーバと前記サービスの提供を受けるクライアントとを相互に接続するネットワーク中に存在し、前記サーバが提供するサービスの少なくとも一部を提供するフロントエンドが動的に生成、削除されるノード装置を構成するコンピュータを、
前記クライアントからのアクセス時、自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在するか否かを確認する確認手段、
前記フロントエンドが自ノード上に存在しない場合に、サービス名を指定した問い合わせに対して当該サービス名のサービスを提供するフロントエンドの位置情報を応答するロケータに対して、サービス名を指定した代替フロントエンドの問い合わせを行い、その応答として得られた代替フロントエンドの位置情報をHTTPプロトコルで規定されたリダイレクト機能によって前記クライアントに提供する問合せ手段、
として機能させるプログラム。 - サービスを提供するサーバと、前記サービスの提供を受けるクライアントと、それらを相互に接続するネットワーク中のノード上で動作し前記サーバが提供するサービスの少なくとも一部を前記クライアントに提供するフロントエンドとを含み、前記フロントエンドの配置場所及び個数を負荷状況に応じて変化させるようにしたWebシステムにおける前記ノードと相互に通信可能なロケータを構成するコンピュータを、
前記ネットワーク中の前記フロントエンドの情報を定期的に収集して記憶する手段、
前記収集した情報を参照して、前記クライアントからのアクセス時に自ノード上に前記クライアントに対してサービスを提供するフロントエンドが存在しなかった前記ノードからのサービス名を指定した問い合わせに対して当該サービス名のサービスを提供するフロントエンドの位置情報を応答する手段、
として機能させるプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001221088A JP3888093B2 (ja) | 2001-07-23 | 2001-07-23 | Webシステム、ノード装置、ロケータ装置及びプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001221088A JP3888093B2 (ja) | 2001-07-23 | 2001-07-23 | Webシステム、ノード装置、ロケータ装置及びプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2003036216A JP2003036216A (ja) | 2003-02-07 |
JP3888093B2 true JP3888093B2 (ja) | 2007-02-28 |
Family
ID=19054808
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001221088A Expired - Fee Related JP3888093B2 (ja) | 2001-07-23 | 2001-07-23 | Webシステム、ノード装置、ロケータ装置及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3888093B2 (ja) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7822722B2 (en) | 2003-09-29 | 2010-10-26 | Sony Corporation | Page title display method |
JP5212091B2 (ja) * | 2008-12-26 | 2013-06-19 | 日本電気株式会社 | オブジェクト保持装置、負荷分散アクセスシステム、オブジェクト保持方法、負荷分散アクセス方法、及びプログラム |
JP2013218670A (ja) * | 2012-02-28 | 2013-10-24 | Sap Ag | コンピュータ実装方法、コンピュータシステム、およびコンピュータ可読記録媒体 |
-
2001
- 2001-07-23 JP JP2001221088A patent/JP3888093B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2003036216A (ja) | 2003-02-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4732667B2 (ja) | 選択的ルーティング | |
CA2413943C (en) | Viewer object proxy | |
CA2410860C (en) | Reverse content harvester | |
JP2004511116A (ja) | ネットワークアドレス指定のためのシステム | |
JP2004513411A (ja) | コンテンツ交換装置 | |
JP2004509381A (ja) | 自己発行ネットワークディレクトリ | |
CA2410850A1 (en) | A qos based content distribution network | |
US20020143946A1 (en) | Software based internet protocol address selection method and system | |
JP2004514961A (ja) | コンテンツのトラッキング | |
JP2004507806A (ja) | クライアント側の全体的健康チェック | |
JP3888093B2 (ja) | Webシステム、ノード装置、ロケータ装置及びプログラム | |
JP2004511835A (ja) | コンテンツオブジェクトのためのアクティブディレクトリ | |
JP2004508614A (ja) | コンテンツマネージャ | |
JP2004511117A (ja) | クライアント側アドレスルーティング解析 | |
CA2410866C (en) | Client side deterministic routing and transparent redirection |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060427 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060718 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060908 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20061107 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061120 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091208 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101208 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101208 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111208 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111208 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121208 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121208 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131208 Year of fee payment: 7 |
|
LAPS | Cancellation because of no payment of annual fees |