JP2005301787A - Webサービス提供方法およびWebサービス提供システム - Google Patents

Webサービス提供方法およびWebサービス提供システム Download PDF

Info

Publication number
JP2005301787A
JP2005301787A JP2004118780A JP2004118780A JP2005301787A JP 2005301787 A JP2005301787 A JP 2005301787A JP 2004118780 A JP2004118780 A JP 2004118780A JP 2004118780 A JP2004118780 A JP 2004118780A JP 2005301787 A JP2005301787 A JP 2005301787A
Authority
JP
Japan
Prior art keywords
server
service
web service
lookup
providing
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.)
Pending
Application number
JP2004118780A
Other languages
English (en)
Inventor
Yasumasa Honda
泰理 本多
Original Assignee
Nippon Telegr & Teleph Corp <Ntt>
日本電信電話株式会社
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Nippon Telegr & Teleph Corp <Ntt>, 日本電信電話株式会社 filed Critical Nippon Telegr & Teleph Corp <Ntt>
Priority to JP2004118780A priority Critical patent/JP2005301787A/ja
Publication of JP2005301787A publication Critical patent/JP2005301787A/ja
Pending legal-status Critical Current

Links

Images

Abstract

【課題】複数の異なるウェブサービスの提供において、サービス完了時間を最適化する。
【解決手段】 サービス・リクエスタ・サーバからルックアップサーバに対して、Webサービスへのアクセス要求または検索要求と共にワークフローを送信し、各モニタリングエージェントに対し全ての必要なネットワーク区間およびサービス・プロバイダ・サーバの状況メトリック情報の測定項目を決定し、各エージェントに測定要求を送信し、各エージェントにおいて、メトリック測定を行い、測定結果をまとめてルックアップサーバに送信する。そして、受信した測定結果を入力とし、ワークフローに沿ってWebサービスのサービス完了時間の観点から最適なサービス・プロバイダ・サーバの提供方法を算出し、算出した最適なサービス・プロバイダ・サーバを指定し、サービス・リクエスタ・サーバからのリクエストをサービス・プロバイダ・サーバに送信する。
【選択図】 図3

Description

本発明は、Webサービス提供方法およびWebサービス提供システムに関し、特に、ワークフローのサービス完了時間の観点において最適なWebサービスの提供方法に適用して有効な技術に関するものである。

従来、インターネット上でエンドユーザにサービスを提供する方法として、前記インターネット上に分散している複数のオブジェクト同士またはシステム同士を、実装環境によらず動的に連携させるWebサービスと呼ばれるサービス提供方法がある(たとえば、非特許文献1を参照。)。前記Webサービスは、たとえば、SOA(Service Oriented Architecture)を実現するために非常に有効なインタフェース実装技術である。

前記Webサービスを実現するWebサービス提供システムは、たとえば、図13に示すように、Webサービスの提供を行うサービス・プロバイダ・サーバ2と、前記UDDI(Universal Description, Discovery, and Integration)レジストリを有するUDDIサーバ8と、Webブラウザ等を用いてWebサービスを利用するエンドユーザの端末(ユーザ端末)4からの要求により前記UDDIサーバ8へWebサービスの照会を行い、前記サービス・プロバイダ・サーバ2からWebサービスの提供を受けるサービス・リクエスタ・サーバ5とを備える。前記サービス・プロバイダ・サーバ2は、各種サービスを提供するサービス・プロバイダが設置したサーバであり、一般には、1つのサービスに対して複数のサービス・プロバイダ・サーバが地理的に異なる場所に分散している。

また、前記UDDIサーバ8は、XML(eXtensible Mark-up Language)を応用した前記インターネット1上に存在するWebサービスの検索・照会を行うサーバである(たとえば非特許文献2を参照。)。このとき、前記UDDIサーバ8のUDDIレジストリには、前記Webサービスにおいて前記サービス・プロバイダ・サーバ2が提供するサービスに関する情報が登録されている。

図13に示したようなWebサービス提供システムを利用してWebサービスを提供するときには、前記各サービス・プロバイダ・サーバ2が提供するサービス情報を、あらかじめ前記UDDIサーバ8のUDDIレジストリに登録しておく。

次に、前記Webサービスを利用するユーザが、前記ユーザ端末4を用いて前記サービス・リクエスタ・サーバ5にアクセスし、要求するWebサービスの条件を通知(リクエスト)する。前記ユーザ端末4からのリクエストを受信した前記サービス・リクエスタ・サーバ5は、インターネット1上で前記リクエストの条件を満たすWebサービスを前記UDDIサーバ8に照会する。

前記UDDIサーバ8はWebサービスのブローカサーバの役割を果たすものであり、Webサービス情報をインターネット1上に公開し、前記サービス・リクエスタ・サーバ5からのリクエストに対してWebサービス検索情報を提供するものである。このとき、前記サービス・リクエスタ・サーバ5とUDDIサーバ8との間でのメッセージのやり取りは、XMLベースのSOAP(Simple Object Access Protocol)と呼ばれるプロトコル上で行われる。前記SOAPは、分散環境における情報交換のためのXMLベースのプロトコルである。

前記サービス・リクエスタ・サーバ5は、前記UDDIサーバ8から提供された前記Webサービス検索情報にもとづき最適なWebサービスを決定し、適切な場所からインタフェース定義であるWSDL(Web Services Definitions Language)を入手する。そして、入手した前記WSDLにもとづきインタフェースであるSOAPプロキシを生成する。その後、前記サービス・プロバイダ・サーバ2ヘアクセスし、前記サービス・プロバイダ・サーバ2からWebサービスの提供を受ける。このときも、前記サービス・リクエスタ・サーバ5と前記サービス・プロバイダ・サーバ2との間でのメッセージのやり取りは、一般的に前記SOAP上で行われる。

また、前記Webサービスでは、たとえば、インターネット1上に分散した複数のサービス・プロバイダ・サーバ2を連携させて、複数種類のサービスを一括して提供することも可能である。このとき、前記サービス・リクエスタ・サーバ5は、前記Webサービスの提供を受ける際に、前記各サービス・プロバイダ・サーバ2へどのような順序でアクセスするか、すなわち中継ノードと最終受信ノードを指定する必要がある。

前記中継ノードおよび前記最終受信ノードを指定する方法としては、前記サービス・プロバイダ・サーバ5から送信するSOAPメッセージのヘッダで指定する方法がある(たとえば、非特許文献3を参照。)。この方法では、たとえば、図14に示すように、SOAPメッセージを送信するSOAP送信端末(サービス・リクエスタ・サーバ)901から前記SOAPメッセージを送信するときに、SOAPヘッダに前記SOAPメッセージの中継ノード902,903および最終受信ノード904を指定して送信する。このとき、中継ノードは、図14に示したように、複数でもよい。前記SOAP送信端末901から送信(発信)された前記SOAPメッセージは、SOAPヘッダに設定された最初の中継ノード902で受信される。前記SOAPメッセージを受信した中継ノード902はSOAPヘッダを読み、記述されたメッセージの中継ノードまたは最終受信ノードが自分自身であるか否かを判断する。自分自身宛てであると判断した場合、中継ノード902は前記SOAPヘッダに記述された処理を行なう。この処理が終了したら、前記中継ノード902は、前記SOAPヘッダを参照して次の端末(中継ノード903)に前記SOAPメッセージを送信する。そして、このような処理を繰り返し、前記SOAPメッセージを最終受信ノード904まで巡回させ、一連のサービスを提供する。
"W3C", [online], [平成16年2月16日検索], インターネット<URL: http://www.w3.org/2002/Ws > "UDDI標準仕様", [online], [平成16年2月16日検索], インターネット<URL: http://www.uddi.org > "Web Services Routing Protocol(WS-Routing)", [online], [平成16年2月16日検索], インターネット<URL: http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglobspec/html/ws-routing.asp >

しかしながら、前記従来のWebサービス技術では、前記サービス・リクエスタ・サーバ5はWebサービス検索時において性能要件を考慮した検索を行うことができない。そのため、前記UDDIサーバ8はWebサービスの検索情報のみを前記サービス・リクエスタ・サーバ5に対して送信するに留まっていた。また、エンドユーザが利用するWebサービスおよびサービス・プロバイダ・サーバ2が決定した後も、サービス・リクエスタ・サーバ5における性能、特に複数サービス利用時に一連のサービス完了時間を最適化する手段は無かった。また、前記サービス・リクエスタ・サーバ5は、サービス検索時およびWebサービスヘのリクエスト送信時にワークフローの指定を行うことができなかった。これらのことから、従来のWebサービスでは、特定のネットワークやサービス・プロバイダ・サーバにおける輻輳や障害が、一連のサービスが完了するまでの時間(サービス完了時間)の劣化を招く可能性が高いという問題があった。

従来、Webサイト利用時におけるエンドユーザにおけるレスポンス時間(サービス完了時間)を最適化するための技術として、HTTPリディレクション技術がある(たとえば、"Cisco Distributed Director", [online], [平成16年2月16日検索], インターネット <URL:http://www.cisco.com/japanese/warp/public/3/jp/product/product/scale/distr/tech/dd_wp.html >を参照。)。前記HTTPリディレクション技術は、エンドユーザからのリクエストをエンドユーザに対し透過的に最適のWebサーバに再送信する技術である。前記HTTPリディレクション技術では、図15に示すように、インターネット1上に分散配置された各Webサーバ201,202,203にネットワーク状況をモニタリングするエージェント1001,1002,1003が設置されるとともに、リディレクションをつかさどる装置であるリディレクター11が設置されている。このとき、前記リディレクター11は前記各Webサーバ201,202,203のホストとして設定され、分散配置された各Webサーバ201,202,203はリディレクター11のサブドメインとして設定されている。

前記HTTPリディレクション技術を適用した場合、たとえば、図15に示すように、前記ユーザ端末4からある1つのサービスを提供する前記Webサーバ201,202,203へのアクセス要求(HTTPリクエスト)を送信すると、そのHTTPリクエストは、前記リディレクター11に送信される。前記リディレクター11は、前記HTTPリクエストを受信すると、前記サービスを提供する各Webサーバ201,202,203に設置されているエージェント1001,1002,1003に対してメトリック要求を発行する。前記メトリック要求を受信した各エージェント1001,1002,1003は、メトリック情報として前記ユーザ端末4と自身が設置されているWebサーバ201,202,203との間のRTT(Round-Trip Time)を測定し、測定結果をリディレクター11へ送信する。前記リディレクター11は、収集したRTT情報から、最もRTT値の小さいWebサーバを最適なサーバに決定する。そして、前記リディレクター11は、前記最適なWebサーバに対する新たなURLを作成し、前記ユーザ端末4にHTTPステータスコード(302"Moved Temporarily")と共に送信する。前記ユーザ端末4は、前記リディレクター11からの新たなURLおよびHTTPステータスコードを受信すると、自動的に新たなURLに前記リクエストをリダイレクトし、最適なサーバ203に接続する。

しかしながら、前記従来のHTTPリディレクション技術では、個々のユーザ端末4とWebサーバ201,202,203の間におけるネットワークのRTTやサーバ状況を測定し最適なサーバを決定することは可能であったが、複数サーバ間のネットワークのRTT情報収集やそれにもとづく最適サーバの算出は困難であった。そのため、ある1つのサービスを提供するサービス・プロバイダ・サーバの中から最適なサーバを決定し、その最適サーバの情報を提供することは可能であったが、複数の異なるサービスを提供するサーバ間での連携や、ワークフローの観点からのサービス完了時間の最適化のためのサービス・プロバイダ・サーバ情報の提供はできなかった。さらに、従来のHTTPリディレクション技術においては、単一のサービスを提供するWebサーバヘのトラフィックのリディレクションを行うことは可能であったが、前記Webサービスのように、前記ユーザ端末からのリクエストが最終目的ノードまでに経由する複数の中継ノードを、リディレクション実行時に指定することは困難であった。

本発明の目的は、複数の異なるサービスを提供するサーバを連携させたWebサービスの提供方法において、サービス完了時間を最適化することが可能な技術を提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述及び添付図面によって明らかになるであろう。

本願において開示される発明の概略を説明すれば、以下の通りである。

(1) ネットワーク上に設置されたサービス・リクエスタ・サーバと、Webサービスを提供するサービス・プロバイダ・サーバと、前記サービス・プロバイダ・サーバのサービス情報が登録されたルックアップサーバと、前記各サービス・プロバイダ・サーバ上もしくは同一設備内に設置されたモニタリングエージェントとを備えるシステム上で、前記サービス・リクエスタ・サーバが指定したワークフローにもとづいてWebサービスを提供するWebサービス提供方法であって、前記サービス・リクエスタ・サーバから前記ルックアップサーバに対して、前記Webサービスへのアクセス要求または前記Webサービスの検索要求とともに前記ワークフローを送信するステップ1と、前記ルックアップサーバにおいて、前記ワークフローにしたがい前記各モニタリングエージェントに対し全ての必要なネットワーク区間およびサービス・プロバイダ・サーバの状況のメトリック情報の測定項目を決定し、前記各モニタリングエージェントに測定要求を送信するステップ2と、前記各モニタリングエージェントにおいて、前記測定要求にしたがったメトリック測定を行い、測定結果(メトリック情報)をまとめて前記ルックアップサーバに送信するステップ3と、前記ルックアップサーバにおいて、前記各モニタリングエージェントから受信したメトリック情報を入力値とし、前記ワークフローに沿ってWebサービスを提供する際のサービス完了時間の観点から最適なサービス・プロバイダ・サーバの提供方法を算出するステップ4と、前記ルックアップサーバにおいて、前記算出した最適なサービス・プロバイダ・サーバを指定し、前記サービス・リクエスタ・サーバからのリクエストを前記サービス・プロバイダ・サーバに送信し、Webサービスを提供するステップ5とを有するWebサービス提供方法である。

(2) ネットワーク上に設置されたサービス・リクエスタ・サーバと、Webサービスを提供するサービス・プロバイダ・サーバと、前記サービス・プロバイダ・サーバのサービス情報が登録されたルックアップサーバと、前記各サービス・プロバイダ・サーバ上もしくは同一設備内に設置されたモニタリングエージェントとを備え、前記サービス・リクエスタ・サーバが指定したワークフローにもとづいてWebサービスを提供するWebサービス提供システムであって、前記ルックアップサーバは、前記サービス・プロバイダ・サーバのサービス情報を登録するサービス情報登録手段と、前記サービス・リクエスタ・サーバからの前記Webサービスの検索要求にもとづいて前記サービス情報登録手段を検索するサービス情報検索手段と、前記サービス・リクエスタ・サーバから指定されたワークフローにもとづいて前記各モニタリングエージェントに対し全ての必要なネットワーク区間およびサービス・プロバイダ・サーバの状況のメトリック情報の測定項目を決定し、前記各モニタリングエージェントからメトリック情報を収集するメトリック情報収集手段と、前記各モニタリングエージェントから収集したメトリック情報を入力値とし、前記ワークフローに沿ってWebサービスを提供する際のサービス完了時間の観点から最適なサービス・プロバイダ・サーバの提供方法を算出する最適サーバ算出手段と、前記算出した最適なサービス・プロバイダ・サーバを指定し、前記サービス・リクエスタ・サーバからのリクエストを前記サービス・プロバイダ・サーバに送信するリクエスト送信手段とを備え、前記モニタリングエージェントは、前記ルックアップサーバからの前記測定項目にしたがいメトリック測定を行うメトリック測定手段を備えるWebサービス提供システムである。

本発明のWebサービス提供方法は、前記(1)に記載したように、前記ルックアップサーバにおいて、前記ワークフローに沿ったWebサービスを提供するときに考えられる経路についてのメトリック情報を収集し、そのメトリック情報に基づいて最適なサービス・プロバイダ・サーバの提供方法を算出する。そのため、複数のサービス・プロバイダ・サーバを巡回してサービスを提供する場合でも、サービス完了時間の観点から最適なサーバを利用したサービスを容易に提供することができる。

また、前記ステップ4の後、前記提供方法をあらかじめ定められた期間、前記ルックアップサーバで保持するステップ6と、前記ステップ1の後、前記ステップ6で保持している前記最適なサービス・プロバイダ・サーバの提供方法を検索し、前記ワークフローと一致する提供方法が保持されているか調べるステップ7とを有し、前記ワークフローと一致する提供方法が保持されている場合は、前記ステップ2およびステップ3、ならびにステップ4を省略することで、利用頻度の高いWebサービスについては、サービスを開始するまでの時間を短縮することができる。

また、前記ステップ1から前記ステップ7の各ステップに加え、前記モニタリングエージェントにおいて前記サービス・プロバイダ・サーバあるいはネットワークの障害を検出したときに、前記モニタリングエージェントから前記ルックアップサーバに受信不能通知を送信するステップ8と、前記モニタリングエージェントにおいて前記サービス・プロバイダ・サーバあるいはネットワークが障害から復旧したときに、前記モニタリングエージェントから前記ルックアップサーバに受信可能通知を送信するステップ9と、前記ステップ7の後、前記ワークフローと一致する提供方法に含まれるサービス・プロバイダ・サーバが通信可能であることを確認するステップ10と、前記ステップ10で、前記ワークフローと一致する提供方法に含まれるサービス・プロバイダ・サーバが通信不能である場合、次善の提供方法を検索するステップ11があれば、前記サービス・プロバイダ・サーバあるいはネットワークの障害によるサービス完了時間の遅延を防ぐことができる。

また、前記ステップ3は、前記メトリック情報の測定の開始時から、あらかじめ定められた時間内に得られた測定結果のみをまとめて前記ルックアップサーバに送信することで、前記Webサービスの提供を開始するまでの時間を短縮することができる。同様に、前記ステップ4は、前記ステップ2における前記メトリック情報の測定要求の送信時から、あらかじめ定められた時間内に受信したメトリック情報のみを用いて最適なサービス・プロバイダ・サーバの提供方法を算出することで、前記Webサービスの提供を開始するまでの時間を短縮することができる。

また、前記(1)に記載した提供方法を実現するには、たとえば、前記(2)に記載したようなWebサービス提供システムを適用すればよい。このとき、前記(2)に記載したWebサービス提供システムにおいて、前記ルックアップサーバは、前記各手段に加え、前記最適サーバ算出手段で算出した前記最適なサービス・プロバイダ・サーバの提供方法をあらかじめ定められた期間保持する提供情報保持手段を備えていてもよい。このようにすると、利用頻度の高いWebサービスに関しては、アクセス要求を受信するたびにメトリック情報を収集する必要がなくなりWebサービスの提供を開始するまでの時間を短縮できる。

また、前記モニタリングエージェントは、前記メトリック測定手段に加え、前記サービス・プロバイダ・サーバおよびネットワークの状況を監視し、前記サービス・プロバイダ・サーバまたはネットワークの障害を検出したときに前記ルックアップサーバに対して受信不能通知を送信するとともに、前記障害から復旧したときに前記ルックアップサーバに対して受信可能通知を送信する通信状態測定手段を備えていてもよい。このようにすると、前記提供情報保持手段で保持している最適なサービス・プロバイダ・サーバの提供方法を利用するときに、現時点でも前記最適なサービス・プロバイダ・サーバが最適か否かの判定が可能となる。そのため、保持している最適なサービス・プロバイダ・サーバが通信不能状態の場合は、次善の提供情報を利用するなどして、サービス完了時間の遅延を低減することができる。

また、前記ルックアップサーバの前記メトリック情報収集手段は、前記メトリック情報の収集を終了するまでの制限時間をセットするタイマーを備えていてもよい。また、前記モニタリングエージェントのメトリック測定手段は、前記メトリック情報の測定を終了するまでの制限時間をセットするタイマーを備えていてもよい。このようにすると、たとえば、障害が発生してメトリック測定に時間がかかっているサービス・プロバイダ・サーバやネットワーク区間を無視して最適なサービス・プロバイダ・サーバを算出できるので、Webサービスの提供を開始するまでの時間をさらに短縮することができる。

また、前記ルックアップサーバおよび前記サービス・プロバイダ・サーバは、前記各サーバで提供するサービスの利用料を課金する手段を備えていてもよい。

以下、本発明について、図面を参照して実施の形態(実施例)とともに詳細に説明する。
なお、実施例を説明するための全図において、同一機能を有するものは、同一符号を付け、その繰り返しの説明は省略する。

本発明のWebサービス提供方法は、サービスを提供する複数のサービス・プロバイダ・サーバのサービス情報を蓄積するサービス・プロバイダ情報蓄積手段を備えるルックアップサーバにおいてサービス・リクエスタ・サーバからのリクエスト条件を満たすWebサービスの検索情報を前記サービス・リクエスタ・サーバに提供するステップと、前記サービス・リクエスタ・サーバにおいて前記ルックアップサーバに対してアクセス要求を送信するときにワークフローを指定して送信するステップと、前記ルックアップサーバにおいて前記アクセス要求とともに受信したワークフローにしたがい前記各サービス・プロバイダ・サーバに設置されたモニタリングエージェントにメトリック要求を発行し、必要なネットワーク区間とサービス・プロバイダ・サーバのメトリック情報を収集するステップと、前記ルックアップサーバにおいて収集したメトリック情報にもとづき前記ワークフローに対する最適なサービス・プロバイダ・サーバを算出するステップと、前記ルックアップサーバにおいて算出した最適なサービス・プロバイダ・サーバを指定して前記サービス・プロバイダ・サーバからのリクエストを送信するステップとを有する。このようにすることで、分散した複数のサービス・プロバイダ・サーバを連携させてWebサービスを提供するときに、指定されたワークフローにおけるサービスが完了するまでの時間の観点から最適なサーバの組み合わせを決定する。

図1および図2は、本発明による実施例1のWebサービス提供システムの概略構成を示す模式図であり、図1はシステム全体の構成例を示す図、図2はルックアップサーバおよびモニタリングエージェントの構成例を示す図である。
図1において、1はインターネット、201,202,203,204はサービス・プロバイダ・サーバ(SPサーバ)、3はルックアップサーバ、4はユーザ端末、5はサービス・リクエスタ・サーバ、601,602,603,604はモニタリングエージェントである。また、図2において、301はサービス情報登録手段(UDDIレジストリ)、302はサービス情報検索手段、303はメトリック情報収集手段、304は最適サーバ算出手段、305はリクエスト送信手段、306は処理制御手段、601Aはメトリック測定手段、601Bは処理制御手段である。

本実施例1のWebサービス提供システムは、図1に示すように、インターネット1上に分散した複数のサービス・プロバイダ・サーバ(SPサーバ)201,202,203,204と、UDDIレジストリを備えるルックアップサーバ3と、ユーザ端末4からの要求に応じて前記ルックアップサーバ3を介してWebサービスの提供を受けるサービス・リクエスタ・サーバ5と、前記各SPサーバ201,202,203,204と接続されたモニタリングエージェント601,602,603,604とを備える。また、前記SPサーバ201,202,203,204は、各種サービスを提供するサービス・プロバイダが設置したサーバであり、一般に、1つのサービスに対して複数のサービス・プロバイダ・サーバが地理的に異なる場所に分散している。本実施例1では、説明を簡単にするために、図1に示すように、サービスAを提供する2つのSPサーバ201,202と、他のサービスBを提供する2つのSPサーバ203,204が設置されているとする。

また、前記ルックアップサーバ3は、図2に示すように、前記各SPサーバのサービス情報が登録されたUDDIレジストリ301と、前記UDDIレジストリ301を検索するサービス情報検索手段302と、前記各SPサーバ201,202,203,204に接続されたモニタリングエージェント601,602,603、604にメトリック要求を発行し必要なネットワーク区間とSPサーバのメトリック情報を収集するメトリック情報収集手段303と、前記メトリック情報収集手段303で収集したメトリック情報にもとづき前記サービス・リクエスタ・サーバ5から指定されたワークフローに対する最適なSPサーバを算出する最適サーバ算出手段304と、算出した最適なSPサーバを指定して前記サービス・リクエスタ・サーバ5からのリクエストを前記SPサーバに送信するリクエスト送信手段305と、前記各手段301,302,303,304,305で行う処理の制御を行う処理制御手段306とを備える。

また、前記SPサーバ201に接続された前記モニタリングエージェント601は、図2に示すように、前記ルックアップサーバ3からのメトリック要求を受信したときに、必要なネットワーク区間とSPサーバ201のメトリック測定を行うメトリック測定手段601Aと、処理制御手段601Bとを備える。また、図示は省略するが、他のSPサーバ202,203,204に接続された各モニタリングエージェント602,603,604も、前記モニタリングエージェント601と同様に、前記メトリック測定手段を備えている。

図3は、本実施例1のWebサービス提供システムを用いたWebサービス提供方法を説明するための模式図であり、前記Webサービス提供システムの動作を説明するシーケンス図である。

本実施例1のWebサービス提供システムでは、まず、たとえば、図3に示すように、前記サービスAおよびサービスBを提供する各SPサーバ201,202,203,204のサービス情報を前記ルックアップサーバ3のUDDIレジストリ301に登録する。このとき、前記UDDIレジストリ301には、たとえば、前記各SPサーバ201,202,203,204のサービス情報とあわせて、各SPサーバ201,202,203,204を設置しているサービスプロバイダ(事業者)の情報も登録する。またこのとき、前記各SPサーバ201,202,203,204のサービス情報が、たとえば、すでにパブリックUDDIへの登録が完了している場合には、その旨と登録通知をルックアップサーバ3へ送信してもよい。

そして、エンドユーザがユーザ端末4を用いて前記Webサービスの提供を受けるときには、まず、前記ユーザ端末4のWebブラウザ等を用いて前記サービス・リクエスタ・サーバ5にアクセスし、要求するWebサービスの条件を送信する。このとき、前記サービス・リクエスタ・サーバ5は、前記ルックアップサーバ3に対して、前記ユーザ端末4から送信された条件に合ったWebサービスの検索を要求する。前記ルックアップサーバ3は、検索要求を受信したら、前記処理制御手段306から前記サービス情報検索手段302に対して検索命令を送り、前記UDDIレジストリ301を検索させる。前記サービス情報検索手段302は、前記UDDIレジストリ301を検索して前記サービス・リクエスタ・サーバ5からの検索要求(条件)に合致するWebサービスを発見した場合、前記処理制御手段306を介してそのWebサービス検索情報を前記サービス・リクエスタ・サーバ5に返信する。また、前記サービス情報検索手段302は、条件に合致するWebサービスを発見できなかった場合、前記処理制御手段306を介してその旨を伝えるエラーメッセージを前記サービス・リクエスタ・サーバ5に返信する。またこのとき、前記サービス・リクエスタ・サーバ5と前記ルックアップサーバ3の間で行われるWebサービスの検索手順については、従来のサービス・リクエスタ・サーバ5とUDDIサーバ8の間で行われる手順と同様であるため、詳細な説明は省略する。

前記サービス・リクエスタ・サーバ5は、前記ルックアップサーバ3から前記Webサービス検索情報を受信したら、提示されたWebサービス検索情報の中から、最も要求に合致したWebサービスを選択し、その情報をアクセス要求としてルックアップサーバ3へ送信する。このとき、前記サービス・リクエスタ・サーバ5は、ワークフロー、すなわちサービスの実行手順や、各サービスを同時に実行するのか順次実行するのかといった実行形態等の情報を指定することができ、必要に応じて前記アクセス要求とあわせて送信することができる。本実施例1では、前記サービスAを実行した後、前記サービスBを実行するというワークフローを指定し、前記アクセス要求とともに送信したとする。

前記ルックアップサーバ3は、前記サービス・リクエスタ・サーバ5からのアクセス要求およびワークフローを受信したら、たとえば、前記処理制御手段306から前記メトリック情報収集手段303に前記ワークフローを渡す。前記メトリック情報収集手段303では、渡されたワークフローにもとづいて、該当するサービス・プロバイダが設置した全てのSPサーバに接続されたモニタリングエージェントで行うメトリック情報の測定項目を指定する。そして、前記処理制御手段を介して前記各モニタリングエージェントにメトリック測定要求を発行する。本実施例1では、前記ワークフローに、サービスAを実行した後サービスBを実行すると指定されている。そのため、前記メトリック情報収集手段303では、前記サービスAを提供する全SPサーバ201,202および前記サービスBを提供する全SPサーバ203,204に接続されたモニタリングエージェント601,602,603、604に対して前記メトリック要求を発行する。またこのとき、前記Webサービスの提供経路としては、前記ルックアップサーバ3、前記サービスAを提供する第1SPサーバ201、前記サービスBを提供する第1SPサーバ203、サービス・リクエスタ・サーバ5という経路、前記ルックアップサーバ3、前記サービスAを提供する第1SPサーバ201、前記サービスBを提供する第2SPサーバ204、サービス・リクエスタ・サーバ5という経路、前記ルックアップサーバ3、前記サービスAを提供する第2SPサーバ202、前記サービスBを提供する第1SPサーバ201、サービス・リクエスタ・サーバ5という経路、前記ルックアップサーバ3、前記サービスAを提供する第2SPサーバ202、前記サービスBを提供する第2SPサーバ204、サービス・リクエスタ・サーバ5という経路の4通りがある。そのため、前記メトリック情報収集手段303は、たとえば、前記サービスAの第1SPサーバ201に接続されたモニタリングエージェント601に対して、前記第1SPサーバ201とルックアップサーバ3との間のRTT、前記第1SPサーバ201と前記サービスBの第1SPサーバ203との間のRTT、前記第1SPサーバ201と前記サービスBの第2SPサーバ204との間のRTT、前記第1SPサーバ201のサーバ状況を測定するように指定する。同様に、前記サービスAの第2SPサーバ202に接続されたモニタリングエージェント602に対しては、前記第2SPサーバ202とルックアップサーバ3との間のRTT、前記第2SPサーバ202と前記サービスBの第1SPサーバ203との間のRTT、前記第2SPサーバ202と前記サービスBの第2SPサーバ204との間のRTT、前記第2SPサーバ202のサーバ状況を測定するように指定する。また、前記サービスBの第1SPサーバ203に接続されたモニタリングエージェント603に対しては、前記第1SPサーバ203とサービス・リクエスタ・サーバ5との間のRTT、前記第1SPサーバ203のサーバ状況を測定するように指定する。同様に、前記サービスBの第2SPサーバ204に接続されたモニタリングエージェント604に対しては、前記第2SPサーバ204とサービス・リクエスタ・サーバ5との間のRTT、前記第2SPサーバ204のサーバ状況を測定するように指定する。そして、これらの測定項目の指定をしたら、各モニタリングエージェント601,602,603,604に対してメトリック要求を送信する。

前記ルックアップサーバ3からのメトリック要求を受信した各モニタリングエージェント601,602,603,604は、指定された各測定項目のメトリック測定を行う。そして、指定された全項目のメトリック測定が終了したら、それらのメトリック情報(測定結果)をまとめて前記ルックアップサーバ3へ送信する。

前記ルックアップサーバ3は、前記各モニタリングエージェント601,602,603,604から送信されたメトリック情報を受信すると、そのメトリック情報を前記処理制御手段306から前記メトリック情報収集手段303に渡す。前記メトリック情報収集手段303は、要求した全てモニタリングエージェントからのメトリック情報がそろったら、それらのメトリック情報を前記最適サーバ算出手段304に渡す。前記最適サーバ算出手段304では、前記メトリック情報にもとづいて前記サービス・リクエスタ・サーバ5が指定したワークフローにおけるサービス完了時間の観点から、最適なSPサーバの組み合わせを算出し決定する。このときの、前記最適なサーバの算出方法についての詳細な説明は省略するが、本実施例1では、前記サービスAに関しては第1SPサーバ201が最適なサーバとして算出され、前記サービスBに関しては第2SPサーバ204が最適なサーバとして算出されたとする。

前記ルックアップサーバ3は、前記最適なサーバを決定したら、前記リクエスト送信手段305において、前記指定されたワークフローにおいて最初に実行されるWebサービスのSPサーバのうち、前記最適サーバ算出手段304で算出された最適なSPサーバからWSDLを入手してSOAPプロキシを生成する。そして、前記サービス・リクエスタ・サーバ5に対して前記Webサービスへの入力に必要な情報を提供する。本実施例1では、前記ワークフローにおいて、最初に実行するはサービスAと指定されているので、前記リクエスト送信手段305は、前記サービスAの第1SPサーバ201からWSDLを入手し、SOAPプロキシを生成する。またこのとき、前記ワークフローにおいて、複数のサービスを同時に実行すると指定されている場合は、その各サービスの最適なSPサーバからWSDLを入手し、SOAPプロキシを生成する。

前記サービス・リクエスタ・サーバ5は、前記ルックアップサーバ3から前記Webサービスへの入力に必要な情報を提供されたら、前記ルックアップサーバ3に対してWebサービスへのリクエスト情報を送信する。本実施例1では、前記サービスAおよびサービスBへのリクエスト情報を送信する。このとき、前記リクエストは、SOAPメッセージとして送信する。

前記ルックアップサーバ3は、前記サービス・リクエスタ・サーバ5からのリクエスト(SOAPメッセージ)を受信したら、前記リクエスト送信手段305のSOAPプロキシを利用して、前記リクエストのSOAPヘッダに前記最適サーバ算出手段304で決定した各サービスの最適なSPサーバを中継ノードおよび最終受信ノードとして記入して指定する。本実施例1では、サービスAのSPサーバ201が中継ノードとして指定され、サービスBのSPサーバ204が最終受信ノードとして指定される。そして、前記中継ノードおよび最終受信ノードの指定が終了したら、前記SOAPプロキシは、前記リクエスト(SOAPメッセージ)を最初の中継ノード(SPサーバ)に送信する。本実施例1では、前記サービスAの第1SPサーバ201に送信される。

その後、前記リクエスト(SOAPメッセージ)は、前記SOAPヘッダの指定にしたがい、各SPサーバであらかじめ定められた処理を実行しながら、各WebサービスのSPサーバを巡回する。そして、最終受信ノード(SPサーバ204)での処理が終了し、前記サービス・リクエスタ・サーバ5が前記SPサーバ204から最終的なレスポンスを受信すると、要求したWebサービスが完了する。このとき、前記サービス・リクエスタ・サーバ5は、前記ルックアップサーバ3に対してワークフローの完了を通知することが望ましい。

以上説明したように、本実施例1のWebサービス提供システムを用いたWebサービス提供方法によれば、前記サービス・リクエスタ・サーバ5から前記ルックアップサーバ3に対して、前記アクセス要求とともにワークフローを送信することで、前記ルックアップサーバ3は、各SPサーバ201,202,203,204に接続されたモニタリングエージェント601,602,603,604に対して、メトリック測定が必要なネットワーク区間を特定することができ、測定項目を指定したメトリック要求を発行することができる。そのため、前記ルックアップサーバ3は、前記各モニタリングエージェント601,602,603,604で測定したメトリック情報にもとづいて、前記ワークフローにおけるサービス完了時間の観点から最適なSPサーバを算出することができる。その結果、前記複数のSPサーバを巡回してWebサービスを提供する場合でも、ワークフローの観点から最適なWebサービスを提供することができる。

また、Webサービスを利用するエンドユーザおよびサービス・リクエスタ・サーバ5にとっては、ワークフローにおける一連のサービス完了時間の向上や、性能を最優先とするWebサービスの選択が可能となる。特に、インターネット上においてリアルタイム性が要求される処理を複数のサービスの組み合わせ(連携)によって行う場合に、本実施例1のWebサービス提供方法を適用することにより大きな効果が得られると期待される。

また、インターネット上で行われるという前記Webサービスの性質上、局所的なネットワークやサーバ性能の劣化に起因するワークフロー全体の性能劣化は、解決しなければならない問題である。本実施例1のWebサービス提供方法においては、ワークフローの観点から、全体としてのサービス完了時間を最適化するネットワーク及びサーバの最適な選択および提供方法を実現することができる。

図4は、本発明による実施例2のWebサービス提供システムの概略構成を示す模式図であり、ルックアップサーバおよびモニタリングエージェントの構成例を示す図である。

前記実施例1のWebサービス提供システムでは、前記ルックアップサーバ3は、前記サービス・リクエスタ・サーバ5からアクセス要求およびワークフローを受信する毎に、前記メトリック情報収集手段303においてメトリック要求を発行し、各モニタリングエージェント601,602,603,604においてメトリック測定を実行する。すなわち、あるWebサービスを提供した後、短期間の間に再び同じWebサービスを提供することになった場合に、再びメトリック測定を実行するので効率が悪い。そこで、本実施例2では、あるWebサービスを提供するときに収集したメトリック情報を前記ルックアップサーバ3で保持しておき、再び同じWebサービスを提供するときに保持しているメトリック情報を利用して、処理の効率を向上させる方法について説明する。

前記メトリック情報を保持する場合、前記ルックアップサーバ3は、図4に示すように、前記実施例1で説明した各手段301,302,303,304,305,306に加えて、あるWebサービスを提供したときに前記最適サーバ算出手段304で算出した最適サーバの情報を最適サーバ提供情報として一時的に保持(キャッシュ)する提供情報保持手段307を備える。

また、前記モニタリングエージェント601は、図4に示すように、前記実施例1で説明した各手段601A,601Bに加えて、前記モニタリングエージェント601が接続(設置)されたSPサーバ201にかかっている負荷の度合いやネットワークの通信状態を定期的に測定し、前記SPサーバ201が通信可能か否かの判定をする通信状態測定手段601Cを備える。このとき、前記通信状態測定手段601cは、たとえば、前記SPサーバ201にかかる負荷がある閾値を越えて通信不能な状態と判定した場合、前記ルックアップサーバ3に対して通信不能通知を送信する。また、前記通信状態測定手段601cは、たとえば、前記SPサーバ201が通信不能な状態になった後、前記SPサーバ201にかかる負荷が軽減して通信可能な状態になった場合、前記ルックアップサーバ3に対して通信可能通知を送信する。

また、図示は省略するが、他のSPサーバ202,203,204に接続された各モニタリングエージェント602,603,604も、前記モニタリングエージェント601と同様に、前記通信状態測定手段を備えている。そして、各SPサーバ202,203,204にかかっている負荷の度合いやネットワークの通信状態を定期的に測定し、前記ルックアップサーバ3に対して通信不能通知や通信可能通知を送信する。

図5および図6は、本実施例2のWebサービス提供システムを用いたWebサービス提供方法を説明するための模式図であり、それぞれ本実施例2における前記Webサービス提供システムの動作を説明するシーケンス図である。

本実施例2のWebサービス提供システムを適用した場合も、前記各SPサーバ201,202,203,204のサービス情報をルックアップサーバ3のUDDIレジストリ301に登録する処理や、前記ルックアップサーバ3のUDDIレジストリ301(Webサービス)の検索手順については、前記実施例1の場合と同じであるため、その詳細な説明は省略する。

本実施例2のWebサービス提供システムを適用した場合、前記サービス・リクエスタ・サーバ5が前記ルックアップサーバ3に対してアクセス要求およびワークフローを送信すると、前記ルックアップサーバ3は、図5に示すように、前記ワークフローに該当する最適サーバ提供情報のキャッシュが保持されているか前記提供情報保持手段307を検索する。前記提供情報保持手段307がキャッシュを保持していない場合、前記ルックアップサーバ3は、前記実施例1で説明したような手順で、前記メトリック情報を収集し、最適サーバを算出する。そして、最適サーバを算出したら、たとえば、その結果を前記提供情報保持手段307に保持させる。

一方、前記提供情報保持手段307がキャッシュを保持している場合は、キャッシュしている最適サーバ提供情報を前記リクエスト送信手段305に渡す。そして、前記実施例1で説明したように、ワークフローにもとづいてサービスを提供するサーバのWSDLを入手してSOAPプロキシを生成し、該Webサービスの入力に必要な情報をサービス・リクエスタ・サーバ5へ送信する。

しかしながら、前記実施例1で説明したような手順で算出された最適サーバの性能は、たとえば、次のアクセス要求を受信するまでの間に劣化する可能性がある。そして、前記最適サーバとしてキャッシュされているSPサーバの性能が劣化した状態でWebサービスを提供するとサービス完了時間が遅延する。

そこで、本実施例2のような手順でWebサービスを提供する場合、たとえば、前記モニタリングエージェント601は、前記通信状態測定手段601Cを用いて定期的に、前記SPサーバ201にかかる負荷やネットワークの状態を測定し、前記SPサーバ201が十分な性能でサービスを提供できる状態(通信可能状態)であるか否かの判定をする。そして、たとえば、図6に示すように、あるWebサービスが完了した後、前記通信状態測定手段601Cにおいて前記SPサーバ201が十分な性能でサービスを提供できない状態(通信不能状態)であると判定されたら、前記モニタリングエージェント601からルックアップサーバ3に対して受信不能通知が送信される。同様に、他のモニタリングエージェント602,603,604が備える通信状態測定手段(図示しない)において前記各SPサーバ202,203,204が通信不能状態であると判定した場合、前記ルックアップサーバ3に対して受信不能通知を送信する。前記ルックアップサーバ3は、前記受信不能通知を受信したら、その通知を、たとえば、前記提供情報保持手段307で保持する。ここでは、前記サービスAを提供する第1SPサーバ201へのアクセスが集中し、受信不能通知が送信されたとする。

このような状態においても、前記ルックアップサーバ3は、サービス・リクエスタ・サーバ5から再度同一のワークフローを指定したアクセス要求を受信すると、前記提供情報保持手段307を検索し、キャッシュを検出する。このとき、前記キャッシュには、前記サービスAを提供する最適サーバは第1SPサーバ201、前記サービスBを提供する最適サーバは第2SPサーバ204が指定されているとする。本実施例2のWebサービス提供方法では、前記キャッシュにもとづいて前記サービスAを提供する最適サーバに第1SPサーバ201、前記サービスBを提供する最適サーバに第2SPサーバ204を指定するが、現時点で前記サービスAの第1SPサーバ201は受信不能状態であるため、このままではサービス完了時間が遅延する。

そこで、前記ルックアップサーバ3は、前記キャッシュを検出した後、図6に示すように、前記キャッシュで指定されているSPサーバが受信可能な状態か否かを判定する。そして、受信可能な場合は、前述のような手順でWebサービスを提供する。また、受信可能な状態でない場合は、キャッシュにある次善の経路を検索し、指定する。いまの場合、前記ルックアップサーバ3は、前記サービスAの第1SPサーバ201から受信不能通知を受信しているので、前記サービスAの第1SPサーバ201を利用できない。そのため、前記ルックアップサーバ3は、次善の経路を検索する。そして、たとえば、前記サービスAの第2SPサーバ202、前記サービスBの第2サーバ204、前記サービス・リクエスタ・サーバ5という経路の提供情報(キャッシュ)を検出したとする。この場合、その経路を最適サーバ情報として前記リクエスト送信手段305に渡し、Webサービスを提供する。また、次善の経路を検出できなかった場合は、前記実施例1で説明したようにメトリック情報を収集し、現時点での最適サーバを算出する。

このようにすると、キャッシュしている最適サーバ提供情報に含まれる最適サーバが受信不能の状態になっている場合、次善の経路に切り替えることができるので、最適サーバの障害等によるサービス完了時間の遅延を低減することができる。

また、詳細な説明は省略するが、前記モニタリングエージェント601,602,603,604は、前記受信不能通知を送信した後、たとえば、障害から復旧して再び受信可能な状態になった場合、前記ルックアップサーバ3に受信可能通知を送信する。このようにすれば、キャッシュされている最適サーバが受信可能な状態になった時点で、次善の経路から、最適な経路に切り替えることができる。

その後は、前記実施例1で説明したように、前記サービス・リクエスタ・サーバ5から前記ルックアップサーバ3へと前記Webサービスへのリクエスト情報を送信すると、前記ルックアップサーバ3は、キャッシュ情報にもとづき前記リクエストのSOAPヘッダに、最適なSPサーバを中継ノードおよび最終受信ノードとして記入して指定する。そして、最初に提供するサービスのSPサーバに前記リクエストを送信し、前記Webサービスを提供する各SPサーバを巡回してワークフローを実行する。

以上説明したように、本実施例2のWebサービス提供システムを用いたWebサービス提供方法によれば、利用頻度の高いWebサービスに関しては、前記サービス・リクエスタ・サーバ5からのアクセス要求受信するたびに、メトリック測定を行う必要はない。そのため、前記要求されたWebサービスの提供を開始するまでの時間を短縮することができ、効率よく前記Webサービスを提供することができる。

また、前記各モニタリングエージェント601,602,603,604に設けた通信状態測定手段おいて、前記各SPサーバ201,202,203,204にかかっている負荷や障害の有無、ネットワークの状態等を定期的に測定して通信可能状態か通信不能状態かを判定し、前記ルックアップサーバ3に通知することで、前記ルックアップサーバ3は、キャッシュしている最適サーバが通信可能か否かの判定ができる。そして、前記キャッシュしている最適サーバが通信不能状態である場合は、次善のサーバを選択するかメトリック測定を行い現時点での最適サーバを算出することで、サービス完了時間の遅延を最小限にすることができる。

また、本実施例2では、前記各モニタリングエージェントに前記通信状態測定手段を設け、前記各SPサーバが通信可能状態か否かの測定を定期的に行い、前記ルックアップサーバに通知したが、たとえば、前記ルックアップサーバ3でキャッシュを保持している時間が短く、前記SPサーバが通信可能状態か否かの影響を受けにくいような場合は、前記最適サーバが受信可能か否かの判定を省略し、検出したキャッシュをそのまま前記リクエスト送信手段305に渡し、Webサービスを提供してもよい。

図7および図8は、本発明による実施例3のWebサービス提供方法を説明するための模式図であり、図7はルックアップサーバにおけるメトリック情報の収集方法を説明するためのシーケンス図、図8はモニタリングエージェントにおけるメトリック情報の測定方法を説明するためのシーケンス図である。

前記実施例1では、前記ルックアップサーバ3および前記モニタリングエージェント601,602,603,604を用いて、前記ワークフローに沿ったWebサービスを提供するときに最適なSPサーバを算出し、サービス完了時間を最適化する方法を説明した。また、前記実施例2では、前記サービス完了時間の最適化に加え、前記Webサービスの提供を開始するまでの時間を短縮する方法について説明した。しかしながら、これらの方法では、前記メトリック情報を収集するときに、メトリック測定を行うSPサーバやSPサーバ間のネットワークに障害がありメトリック測定にかかる時間が長くなり、Webサービスの提供を開始するまでの時間が長くなる可能性がある。そこで、本実施例3では、メトリック測定にかかる時間を短縮する方法について説明する。

前記メトリック測定にかかる時間を短縮する方法としては、たとえば、前記モニタリングエージェント601,602,603,604がメトリック測定を行うときに、制限時間を設ける方法がある。この方法では、たとえば、図7に示すように、前記モニタリングエージェント601が前記ルックアップサーバ3からのメトリック要求を受信し、メトリック測定を開始するときにタイマーをセットする。このとき、図示は省略するが、セットした制限時間内に全測定項目の測定結果が得られれば、その時点でタイマーを解除し、得られた測定結果をまとめて前記ルックアップサーバ3に送信する。

一方、たとえば、ネットワーク障害により、図7に示すように、セットした制限時間内に全測定項目の測定結果が得られずにタイムアウトした場合、前記モニタリングエージェント601は、再びタイマーをセットし、測定結果が得られなかった項目について再度メトリック測定を行う。そして、セットした制限時間内に測定結果が得られれば、その時点でタイマーを解除し、最初に得られた測定結果と、再測定で得られた測定結果をまとめて前記ルックアップサーバ3に送信する。また、再測定においても測定結果が得られずにタイムアウトした場合、測定結果が得られなかった項目は無効とし、得られた測定結果のみをまとめて前記ルックアップサーバ3に送信する。

再測定においても測定結果が得られなかった項目は、制限時間内に測定ができなかった項目であるため、その項目に該当するネットワーク区間あるいはサーバに障害があると推測される。つまり、測定結果が得られなかったということは、サービス完了時間の観点から最適サーバとして算出されることはない。そのため、測定結果が得られなかった項目を無効としても問題はない。また、障害などにより測定に時間がかかっている項目の測定結果が得られるのを待っていれば、それだけWebサービスの提供を開始するまでの時間が長くなる。そのため、適当な制限時間をセットすることで、Webサービスの提供を開始するまでの時間を短縮することができる。

また、前記メトリック測定にかかる時間を短縮する方法は、前記モニタリングエージェント601,602,603,604でタイマーをセットする方法の他に、たとえば、前記ルックアップサーバ3がメトリック要求を発行するときに制限時間を設ける方法がある。この方法では、たとえば、図8に示すように、前記ルックアップサーバ3が前記モニタリングエージェント601,602,603,604に対してメトリック要求を発行するときにタイマーをセットする。そして、前記ルックアップサーバ3は、セットした制限時間内に、メトリック要求を発行した全てのモニタリングエージェント601,602,603,604からメトリック情報を受信すれば、その時点でタイマーを解除し、受信したメトリック情報にもとづいて最適サーバを算出する。

一方、たとえば、ネットワーク障害により、図8に示すように、セットした制限時間内に全てのモニタリングエージェント601,602,603,604からのメトリック情報を受信する前にタイムアウトした場合、前記ルックアップサーバ3は、再びタイマーをセットし、メトリック情報を受信できなかったモニタリングエージェント603に対して、再度メトリック要求を発行する。そして、セットした制限時間内にメトリック情報を受信したら、その時点でタイマーを解除し、最初に受信したメトリック情報と、再要求で受信したメトリック情報にもとづいて最適サーバを算出する。また、再要求においてもメトリック情報を受信する前にタイムアウトした場合、受信できなかったメトリック情報は無効とし、受信したメトリック情報のみをまとめて前記最適サーバを算出する。またこのとき、特定のWebサービスの全てのSPサーバのモニタリングエージェント、たとえば、サービスBを提供する全てのモニタリングエージェント603,604からメトリック情報を得られなかった場合には、前記Webサービスのワークフローは利用できないものとしてサービス・リクエスタ・サーバ5ヘエラー通知を送信する。このようにすることで、メトリック情報の収集にかかる時間を短縮し、Webサービスの提供を開始するまでの時間を短縮することができる。

インターネット上で行われるというWebサービスの性質上、局所的なネットワークやサーバ性能の劣化に起因するワークフロー全体の性能劣化は解決が必要な問題である。そこで、本実施例3のような方法で、ワークフローの観点から、全体としてのサービス完了時間を最適化するネットワーク及びサーバの最適な選択および提供方法を実現することができる。

また、本実施例3のような方法でWebサービスを提供することにより、前記サービス・プロバイダ・サーバを提供する事業者にとっては、Webサービスの信頼性およびパフォーマンスの向上を提供することができ、顧客満足度の増大とそれに伴う収益基盤の拡大を期待することができる。またサービス・プロバイダ・サーバやネットワークの障害、性能劣化によるビジネスチャンスの損失を抑制することができる。

図9は、本発明による実施例4のWebサービス提供方法を説明するための模式図であり、図9(a)および図9(b)はそれぞれ、前記ルックアップサーバおよび前記Webサービスの利用料に対する課金方法を説明する図である。

前記実施例1から実施例3までで説明したような方法でWebサービスを提供する場合には、たとえば、前記Webサービスの利用料、前記ルックアップサーバ3の利用料等を支払わなければならない場合がある。そのような場合、たとえば、図9(a)に示すように、前記SPサーバ201にはサービス利用料課金手段201Aを設け、前記ルックアップサーバ3にはサーバ利用料課金手段308を設ける。このとき、前記ルックアップサーバ3のサーバ利用料課金手段308は、たとえば、前記SPサーバ201を設置したサービス・プロバイダが前記SPサーバ201のサービス情報を前記ルックアップサーバ3に登録したときの登録料や、前記サービス・リクエスタ・サーバ5が最適サーバ情報の提供を要求したときの最適サーバ提供料をサービス・プロバイダ運営事業者、サービス・リクエスタ・サーバ設置事業者毎に蓄積する。そして、前記ルックアップサーバ3を設置した事業者は、あらかじめ定められた方法で、前記登録料や最適サーバ提供料を徴収する。

また、前記SPサーバ201のサービス利用料課金手段201Aは、前記サービス・リクエスタ・サーバ5が前記ルックアップサーバ3を介してWebサービスを利用したときに、その利用料を、たとえば、サービス・リクエスタ・サーバ設置事業者毎に蓄積する。そして、前記SPサーバ201を設置した事業者は、あらかじめ定められた方法で、前記Webサービス利用料を徴収する。

また、前記Webサービスの利用料に関しては、前記SPサーバ201に課金手段201Aを設ける代わりに、図9(b)に示すように、前記ルックアップサーバ3にサービス利用料決済代行手段309を設けてもよい。この場合、前記ルックアップサーバ3は、前記サービス・リクエスタ・サーバ5が前記ルックアップサーバ3を介してWebサービスを利用したときに、前記ルックアップサーバ3からの最適サーバ提供料と前記Webサービスの利用料をそれぞれ、前記サーバ利用料課金手段308とサービス利用料決済代行手段309に蓄積する。そして、前記ルックアップサーバ3を設置した事業者は、あらかじめ定められた方法で、前記サービス・リクエスタ・サーバ5を設置した事業者から最適サーバ提供料と前記Webサービスの利用料を徴収する。その後、前記ルックアップサーバ3を設置した事業者は、前記サービス・リクエスタ・サーバ5を設置した事業者から徴収した前記Webサービスの利用料を前記SPサーバ201を設置した事業者に対して支払う。

前記ルックアップサーバ運営事業者にとっては、前記実施例1から実施例3で説明したような方法をとることで、サービス・プロバイダ・サーバの登録数の増加、ならびにサービス・リクエスタ・サーバによるWebサービス利用の増加が期待される。そのため、このような課金手段を設けることで、Webサービス利用の増加にともう登録料による収益の拡大を期待することができる。さらに、サービス・プロバイダ・サーバの登録時に何らかの基準を設定することにより、登録されているWebサービスヘの信頼性を高める効果が得られることも考えられる。

また、サービス・リクエスタ・サーバの提供者やエンドユーザにとっては、前記実施例1から実施例3で説明したようなWebサービスの利用により最適な性能で複数Webサービスの提供を受けることができると同時に、サービス・プロバイダ・サーバやネットワークの障害等により損失を被る可能性を抑制することができる。また複数Webサービス利用時においてもルックアップサーバの決済代行機能を利用することが可能であり、決済の簡易性も大きな利点である。

図10および図11は、本発明による実施例5のWebサービス提供方法を説明するための模式図であり、図10はWebサービス提供システムの具体的な適用例の1つを示す図、図11は図10に示した適用例におけるシステムの動作を説明するシーケンス図である。

本発明によるWebサービス提供システムおよび提供方法は、あらゆるWebサービスの提供に対して適用することができる。本実施例5では、それらの適用例の1つとして、個人又は機関投資家のサービス・リクエスタ・サーバが、銀行サービス、信託サービスを順次利用するWebサービスの提供を受ける場合を例に挙げて、具体的なサービス提供方法について説明する。

本実施例5では、インターネット1上に、図10に示すように、銀行サービス(サービスA)を提供するサービス・プロバイダのSPサーバ201,202、信託運用サービス(サービスB)を提供するサービス・プロバイダのSPサーバ203,204、経済情報配信サービス(サービスC)を提供するサービス・プロバイダのSPサーバ205,206が設置されているとする。また、図示は省略するが、前記インターネット1上には、これらのSPサーバの他に、たとえば、経済情報閲覧サービスを提供するサービス・プロバイダのSPサーバ等が設置されていてもよい。またこのとき、各WebサービスのSPサーバは、サービス情報をすでに前記ルックアップサーバ3に登録しているとする。

このとき、たとえば、エンドユーザが前記ユーザ端末4を用いて、前記サービス・リクエスタ・サーバ5に対して、購入予定である投資信託商品の販売を行っているネット銀行および運用を行っている投資信託会社のWebサービスへのアクセスをリクエストしたとする。そうすると、前記サービス・リクエスタ・サーバ5は、そのリクエストにもとづいて、前記ルックアップサーバ3に対してWebサービスの照会をする。前記ルックアップサーバ3は、前記リクエストの条件を満たすWebサービス情報を検出したら、検索情報を前記サービス・リクエスタ・サーバ5に対して送信する。

前記サービス・リクエスタ・サーバ5は前記検索情報の中から最も要求に合致したサービスを選択し、図11に示すように、前記ルックアップサーバ3に対してアクセス要求を送信する。このとき、前記サービス・リクエスタ・サーバ5は、銀行サービス(サービスA)、信託サービス(サービスB)、経済情報配信サービス(サービスC)を選択し、そのアクセス要求を前記ルックアップサーバ3に送信したとする。またこのとき、前記サービス・リクエスタ・サーバ5は、同時にワークフローの指定を行い、前記銀行サービスでの投資信託購入、前記信託サービスBへの契約要求、前記経済情報配信サービスでの額面情報の配信申し込みの手順で処理を行うことを要求したとする。

前記アクセス要求を受信した前記ルックアップサーバ3は、前記指定されたワークフローに対する最適サーバ提供情報のキャッシュの有無を確認する。ここではキャッシュが存在しないものとする。

このとき、前記ルックアップサーバ3は、リクエストされた各Webサービスの全てのサービス・プロバイダ・サーバ201,202,203,204,205,206に接続されたモニタリングエージェント601,602,603,604,605,606に対しメトリック要求を発行し、メトリック情報を収集する。前記メトリック情報は、前記実施例1から実施例3で説明したような方法で収集すればよいので、詳細な説明は省略する。

前記ルックアップサーバ3は、前記メトリック情報を収集したら、そのメトリック情報に基き各Webサービスからそれぞれ最適なSPサーバを算出する。本実施例5では、銀行サービスに関しては第2SPサーバ202、信託サービスに関しては第1SPサーバ203、経済情報配信サービスに関しては第2SPサーバ206が最適であると算出したとする。そして、続けて、前記サービス・リクエスタ・サーバ5の指定したワークフローにおいて最初に実行すると指定されている銀行サービスについて、算出した最適なSPサーバ201からWSDLを入手してSOAPプロキシを生成し、サービス・リクエスタ・サーバ5に対して前記Webサービス画面情報を送信する。この銀行サービスの画面において、信託サービスやメール配信サービスヘの要求も入力することができるようになっている。

前記サービス・リクエスタ・サーバ5は、前記ルックアップサーバ3から提供された情報にもとづき一連のリクエストを入力し、ルックアップサーバ3に対して送信する。

前記ルックアップサーバ3は、銀行サービスに対する前記リクエストのSOAPヘッダに、算出した最適サーバを中継ノードおよび最終目的ノードとして記入し、指定する。その後、前記リクエストは前記ルックアップサーバ3(SOAPプロキシ)の指定に従い、まず、前記銀行サービスの第2SPサーバ202に送信される。そして、前記銀行サービスの第2SPサーバ202での処理が終了したら、前記リクエストは前記信託サービスの第1SPサーバ203ヘ送信される。また、前記リクエストを受信した前記信託サービスの第1SPサーバ203での処理が終了したら、前記リクエストは前記経済情報配信サービスの第2SPサーバ206に送られる。

このようにして、前記経済情報配信サービスの第2SPサーバ206が前記リクエストを受信し、処理が終了すると、指定されたワークフローの一連の処理結果がサービス・リクエスタ・サーバ5に送信され、サービスが完了する。このとき、前記サービス・リクエスタ・サーバ5は、サービスの完了をルックアップサーバ3ヘ通知するとともに、エンドユーザのユーザ端末4に処理結果を送信する。

以上、本発明を、前記実施例に基づき具体的に説明したが、本発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において、種々変更可能であることはもちろんである。

図12は、本発明によるWebサービス提供システムの変形例を示す模式図であり、システムの概略構成を示す図である。

前記実施例1から実施例5では、前記Webサービス提供システムを構成するサービス・リクエスタ・サーバ5、前記ルックアップサーバ3、前記SPサーバ201,202,203,204およびモニタリングエージェント601,602,603,604は、たとえば、図1に示したように、全てインターネット1上に設置されているが、たとえば、図12に示すように、ルックアップサーバ運営事業者がネットワーク7を所有する場合には、前記提供システムを利用してサービスを提供するサービス・プロバイダからの要求にもとづき、前記ルックアップサーバ運営事業者のネットワーク7上に、前記SPサーバ201,202,203,204およびモニタリングエージェント601,602,603,604を設置することもできる。

また、前記実施例1から実施例5では、前記サービス・リクエスタ・サーバ5から前記ルックアップサーバ3に対してWebサービスの検索要求をして検索情報を得た後、アクセス要求とともにワークフローを送信していたが、これに限らず、前記Webサービスの検索要求を送信するときに前記ワークフローをあわせて送信してもよい。その場合、前記ルックアップサーバ3は、前記検索要求を受信してWebサービス情報を検索した後、ただちに前記ワークフローにもとづいてメトリック要求を発行することができる。そのため、前記Webサービスの提供を開始するまでの時間をさらに短縮することができる。

また、前記実施例1から実施例5では、複数のサービスをワークフローにしたがって巡回する場合の最適サーバの算出およびWebサービスの提供方法について説明したが、本発明のWebサービス提供システムおよび提供方法は、これに限らず、複数のサービスを同時に利用したい場合、あるいは1つのサービスのみを利用したい場合にも対応できる。

本発明による実施例1のWebサービス提供システムの概略構成を示す模式図であり、システム全体の構成例を示す図である。 本発明による実施例1のWebサービス提供システムの概略構成を示す模式図であり、ルックアップサーバおよびモニタリングエージェントの構成例を示す図である。 本実施例1のWebサービス提供システムを用いたWebサービス提供方法を説明するための模式図であり、前記Webサービス提供システムの動作を説明するシーケンス図である。 本発明による実施例2のWebサービス提供システムの概略構成を示す模式図であり、ルックアップサーバおよびモニタリングエージェントの構成例を示す図である。 本実施例2のWebサービス提供システムを用いたWebサービス提供方法を説明するための模式図であり、前記Webサービス提供システムの動作を説明するシーケンス図である。 本実施例2のWebサービス提供システムを用いたWebサービス提供方法を説明するための模式図であり、前記Webサービス提供システムの動作を説明するシーケンス図である。 本発明による実施例3のWebサービス提供方法を説明するための模式図であり、ルックアップサーバにおけるメトリック情報の収集方法を説明するためのシーケンス図である。 本発明による実施例3のWebサービス提供方法を説明するための模式図であり、モニタリングエージェントにおけるメトリック情報の測定方法を説明するためのシーケンス図である。 本発明による実施例4のWebサービス提供方法を説明するための模式図であり、図9(a)および図9(b)はそれぞれ、前記ルックアップサーバおよび前記Webサービスの利用料に対する課金方法を説明する図である。 本発明による実施例5のWebサービス提供方法を説明するための模式図であり、Webサービス提供システムの具体的な適用例の1つを示す図である。 本発明による実施例5のWebサービス提供方法を説明するための模式図であり、図11は図10に示した適用例におけるシステムの動作を説明するシーケンス図である。 本発明によるWebサービス提供システムの変形例を示す模式図であり、システムの概略構成を示す図である。 従来のWebサービス提供システムの概略構成を示す模式図である。 中継ノードおよび最終受信ノードの指定方法を説明するための模式図である。 HTTPリディレクション技術を説明するための模式図である。

符号の説明

1…インターネット
2…Webサーバ
201,202,203,204,205,206…サービス・プロバイダ・サーバ(SPサーバ)
3…ルックアップサーバ
301…サービス情報登録手段(UDDIレジストリ)
302…サービス情報検索手段
303…メトリック情報収集手段
304…最適サーバ算出手段
305…リクエスト送信手段
306…処理制御手段
307…提供情報保持手段
308…サーバ利用料課金手段
309…サービス利用料決済代行手段
4…ユーザ端末
5…サービス・リクエスタ・サーバ
601,602,603,604,605,606…モニタリングエージェント
7…ルックアップサーバ運営事業者のネットワーク

Claims (10)

  1. ネットワーク上に設置されたサービス・リクエスタ・サーバと、Webサービスを提供するサービス・プロバイダ・サーバと、前記サービス・プロバイダ・サーバのサービス情報が登録されたルックアップサーバと、前記各サービス・プロバイダ・サーバ上もしくは同一設備内に設置されたモニタリングエージェントとを備えるシステム上で、前記サービス・リクエスタ・サーバが指定したワークフローにもとづいてWebサービスを提供するWebサービス提供方法であって、
    前記サービス・リクエスタ・サーバから前記ルックアップサーバに対して、前記Webサービスへのアクセス要求または前記Webサービスの検索要求とともに前記ワークフローを送信するステップ1と、
    前記ルックアップサーバにおいて、前記ワークフローにしたがい前記各モニタリングエージェントに対し全ての必要なネットワーク区間およびサービス・プロバイダ・サーバの状況のメトリック情報の測定項目を決定し、前記各モニタリングエージェントに測定要求を送信するステップ2と、
    前記各モニタリングエージェントにおいて、前記測定要求にしたがったメトリック測定を行い、測定結果(メトリック情報)をまとめて前記ルックアップサーバに送信するステップ3と、
    前記ルックアップサーバにおいて、前記各モニタリングエージェントから受信したメトリック情報を入力値とし、前記ワークフローに沿ってWebサービスを提供する際のサービス完了時間の観点から最適なサービス・プロバイダ・サーバの提供方法を算出するステップ4と、
    前記ルックアップサーバにおいて、前記算出した最適なサービス・プロバイダ・サーバを指定し、前記サービス・リクエスタ・サーバからのリクエストを前記サービス・プロバイダ・サーバに送信し、Webサービスを提供するステップ5とを有することを特徴とするWebサービス提供方法。
  2. 前記ステップ4の後、前記提供方法をあらかじめ定められた期間、前記ルックアップサーバで保持するステップ6と、
    前記ステップ1の後、前記ステップ6で保持している前記最適なサービス・プロバイダ・サーバの提供方法を検索し、前記ワークフローと一致する提供方法が保持されているか調べるステップ7とを有し、
    前記ワークフローと一致する提供方法が保持されている場合は、前記ステップ2およびステップ3、ならびにステップ4を省略することを特徴とする請求項1に記載のWebサービス提供方法。
  3. 前記ステップ1から前記ステップ7の各ステップに加え、前記モニタリングエージェントにおいて前記サービス・プロバイダ・サーバあるいはネットワークの障害を検出したときに、前記モニタリングエージェントから前記ルックアップサーバに受信不能通知を送信するステップ8と、
    前記モニタリングエージェントにおいて前記サービス・プロバイダ・サーバあるいはネットワークが障害から復旧したときに、前記モニタリングエージェントから前記ルックアップサーバに受信可能通知を送信するステップ9と、
    前記ステップ7の後、前記ワークフローと一致する提供方法に含まれるサービス・プロバイダ・サーバが通信可能であることを確認するステップ10と、
    前記ステップ10で、前記ワークフローと一致する提供方法に含まれるサービス・プロバイダ・サーバが通信不能である場合、次善の提供方法を検索するステップ11とを有することを特徴とする請求項1または請求項2に記載のWebサービス提供方法。
  4. 前記ステップ3は、前記メトリック情報の測定の開始時から、あらかじめ定められた時間内に得られた測定結果のみをまとめて前記ルックアップサーバに送信することを特徴とする請求項1乃至請求項3のいずれか1項に記載のWebサービス提供方法。
  5. 前記ステップ4は、前記ステップ2における前記メトリック情報の測定要求の送信時から、あらかじめ定められた時間内に受信したメトリック情報のみを用いて最適なサービス・プロバイダ・サーバの提供方法を算出することを特徴とする請求項1乃至請求項4のいずれか1項に記載のWebサービス提供方法。
  6. ネットワーク上に設置されたサービス・リクエスタ・サーバと、Webサービスを提供するサービス・プロバイダ・サーバと、前記サービス・プロバイダ・サーバのサービス情報が登録されたルックアップサーバと、前記各サービス・プロバイダ・サーバ上もしくは同一設備内に設置されたモニタリングエージェントとを備え、前記サービス・リクエスタ・サーバが指定したワークフローにもとづいてWebサービスを提供するWebサービス提供システムであって、
    前記ルックアップサーバは、前記サービス・プロバイダ・サーバのサービス情報を登録するサービス情報登録手段と、前記サービス・リクエスタ・サーバからの前記Webサービスの検索要求にもとづいて前記サービス情報登録手段を検索するサービス情報検索手段と、前記サービス・リクエスタ・サーバから指定されたワークフローにもとづいて前記各モニタリングエージェントに対し全ての必要なネットワーク区間およびサービス・プロバイダ・サーバの状況のメトリック情報の測定項目を決定し、前記各モニタリングエージェントからメトリック情報を収集するメトリック情報収集手段と、前記各モニタリングエージェントから収集したメトリック情報を入力値とし、前記ワークフローに沿ってWebサービスを提供する際のサービス完了時間の観点から最適なサービス・プロバイダ・サーバの提供方法を算出する最適サーバ算出手段と、前記算出した最適なサービス・プロバイダ・サーバを指定し、前記サービス・リクエスタ・サーバからのリクエストを前記サービス・プロバイダ・サーバに送信するリクエスト送信手段とを備え、
    前記モニタリングエージェントは、前記ルックアップサーバからの前記測定項目にしたがいメトリック測定を行うメトリック測定手段を備えることを特徴とするWebサービス提供システム。
  7. 前記ルックアップサーバは、前記各手段に加え、前記最適サーバ算出手段で算出した前記最適なサービス・プロバイダ・サーバの提供方法をあらかじめ定められた期間保持する提供情報保持手段を備えることを特徴とする請求項6に記載のWebサービス提供システム。
  8. 前記モニタリングエージェントは、前記メトリック測定手段に加え、前記サービス・プロバイダ・サーバおよびネットワークの状況を監視し、前記サービス・プロバイダ・サーバまたはネットワークの障害を検出したときに前記ルックアップサーバに対して受信不能通知を送信するとともに、前記障害から復旧したときに前記ルックアップサーバに対して受信可能通知を送信する通信状態測定手段を備えることを特徴とする請求項6または請求項7に記載のWebサービス提供システム。
  9. 前記ルックアップサーバの前記メトリック情報収集手段は、前記メトリック情報の収集を終了するまでの制限時間をセットするタイマーを備えることを特徴とする請求項6乃至請求項8のいずれか1項に記載のWebサービス提供システム。
  10. 前記モニタリングエージェントのメトリック測定手段は、前記メトリック情報の測定を終了するまでの制限時間をセットするタイマーを備えることを特徴とする請求項6乃至請求項9のいずれか1項に記載のWebサービス提供システム。
JP2004118780A 2004-04-14 2004-04-14 Webサービス提供方法およびWebサービス提供システム Pending JP2005301787A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2004118780A JP2005301787A (ja) 2004-04-14 2004-04-14 Webサービス提供方法およびWebサービス提供システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004118780A JP2005301787A (ja) 2004-04-14 2004-04-14 Webサービス提供方法およびWebサービス提供システム

Publications (1)

Publication Number Publication Date
JP2005301787A true JP2005301787A (ja) 2005-10-27

Family

ID=35333223

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004118780A Pending JP2005301787A (ja) 2004-04-14 2004-04-14 Webサービス提供方法およびWebサービス提供システム

Country Status (1)

Country Link
JP (1) JP2005301787A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007193591A (ja) * 2006-01-19 2007-08-02 Casio Comput Co Ltd Web検索サーバ及びWeb検索方法
KR20200029794A (ko) * 2018-09-11 2020-03-19 아토리서치(주) 실시간 다중 메트릭 모니터링 방법 및 시스템

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007193591A (ja) * 2006-01-19 2007-08-02 Casio Comput Co Ltd Web検索サーバ及びWeb検索方法
KR20200029794A (ko) * 2018-09-11 2020-03-19 아토리서치(주) 실시간 다중 메트릭 모니터링 방법 및 시스템
KR102092093B1 (ko) 2018-09-11 2020-03-23 아토리서치(주) 실시간 다중 메트릭 모니터링 방법 및 시스템

Similar Documents

Publication Publication Date Title
US20190297137A1 (en) Point of presence management in request routing
US20180097814A1 (en) Method and Apparatus for Prioritization of Data Requests
US20180212880A1 (en) Managing network computing components utilizing request routing
US20190044787A1 (en) Point of presence management in request routing
US10797995B2 (en) Request routing based on class
US10015237B2 (en) Point of presence management in request routing
US9608957B2 (en) Request routing using network computing components
US9736258B2 (en) Assessment of content delivery services using performance measurements from within an end user client application
KR101573182B1 (ko) 네트워크 관리 방법 및 서비스 QoS 제공 방법
US9160703B2 (en) Request routing management based on network components
US10284446B2 (en) Optimizing content management
US10027564B2 (en) Unobtrusive methods and systems for collecting information transmitted over a network
US8423667B2 (en) Updating routing information based on client location
US9871722B2 (en) Content delivery network routing method, system and user terminal
US9106701B2 (en) Request routing management based on network components
US8539079B2 (en) Edge-based resource spin-up for cloud computing
US20150244563A1 (en) Differentiated service-based graceful degradation error
US8549531B2 (en) Optimizing resource configurations
CN102291447B (zh) 内容分发网络负载调度方法和系统
US8112471B2 (en) System and method for website performance optimization and internet traffic processing
US10728133B2 (en) Routing mode and point-of-presence selection service
EP2997487B1 (en) Selecting a content providing server in a content delivery network
JP3966598B2 (ja) サーバ選択システム
US8423672B2 (en) Domain name resolution using a distributed DNS network
CN101124565B (zh) 基于应用层消息的数据流量负载平衡