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

Abstract

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

Description

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

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

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

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

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

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

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

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

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

前記中継ノードおよび前記最終受信ノードを指定する方法としては、前記サービス・プロバイダ・サーバ５から送信するSOAPメッセージのヘッダで指定する方法がある（たとえば、非特許文献３を参照。）。この方法では、たとえば、図１４に示すように、SOAPメッセージを送信するSOAP送信端末（サービス・リクエスタ・サーバ）９０１から前記SOAPメッセージを送信するときに、SOAPヘッダに前記SOAPメッセージの中継ノード９０２，９０３および最終受信ノード９０４を指定して送信する。このとき、中継ノードは、図１４に示したように、複数でもよい。前記SOAP送信端末９０１から送信（発信）された前記SOAPメッセージは、SOAPヘッダに設定された最初の中継ノード９０２で受信される。前記SOAPメッセージを受信した中継ノード９０２はSOAPヘッダを読み、記述されたメッセージの中継ノードまたは最終受信ノードが自分自身であるか否かを判断する。自分自身宛てであると判断した場合、中継ノード９０２は前記SOAPヘッダに記述された処理を行なう。この処理が終了したら、前記中継ノード９０２は、前記SOAPヘッダを参照して次の端末（中継ノード９０３）に前記SOAPメッセージを送信する。そして、このような処理を繰り返し、前記SOAPメッセージを最終受信ノード９０４まで巡回させ、一連のサービスを提供する。
"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サービス技術では、前記サービス・リクエスタ・サーバ５はWebサービス検索時において性能要件を考慮した検索を行うことができない。そのため、前記UDDIサーバ８はWebサービスの検索情報のみを前記サービス・リクエスタ・サーバ５に対して送信するに留まっていた。また、エンドユーザが利用するWebサービスおよびサービス・プロバイダ・サーバ２が決定した後も、サービス・リクエスタ・サーバ５における性能、特に複数サービス利用時に一連のサービス完了時間を最適化する手段は無かった。また、前記サービス・リクエスタ・サーバ５は、サービス検索時および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リディレクション技術では、図１５に示すように、インターネット１上に分散配置された各Webサーバ２０１，２０２，２０３にネットワーク状況をモニタリングするエージェント１００１，１００２，１００３が設置されるとともに、リディレクションをつかさどる装置であるリディレクター１１が設置されている。このとき、前記リディレクター１１は前記各Webサーバ２０１，２０２，２０３のホストとして設定され、分散配置された各Webサーバ２０１，２０２，２０３はリディレクター１１のサブドメインとして設定されている。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図１および図２は、本発明による実施例１のWebサービス提供システムの概略構成を示す模式図であり、図１はシステム全体の構成例を示す図、図２はルックアップサーバおよびモニタリングエージェントの構成例を示す図である。
図１において、１はインターネット、２０１，２０２，２０３，２０４はサービス・プロバイダ・サーバ（ＳＰサーバ）、３はルックアップサーバ、４はユーザ端末、５はサービス・リクエスタ・サーバ、６０１，６０２，６０３，６０４はモニタリングエージェントである。また、図２において、３０１はサービス情報登録手段（UDDIレジストリ）、３０２はサービス情報検索手段、３０３はメトリック情報収集手段、３０４は最適サーバ算出手段、３０５はリクエスト送信手段、３０６は処理制御手段、６０１Ａはメトリック測定手段、６０１Ｂは処理制御手段である。

本実施例１のWebサービス提供システムは、図１に示すように、インターネット１上に分散した複数のサービス・プロバイダ・サーバ（ＳＰサーバ）２０１，２０２，２０３，２０４と、UDDIレジストリを備えるルックアップサーバ３と、ユーザ端末４からの要求に応じて前記ルックアップサーバ３を介してWebサービスの提供を受けるサービス・リクエスタ・サーバ５と、前記各ＳＰサーバ２０１，２０２，２０３，２０４と接続されたモニタリングエージェント６０１，６０２，６０３，６０４とを備える。また、前記ＳＰサーバ２０１，２０２，２０３，２０４は、各種サービスを提供するサービス・プロバイダが設置したサーバであり、一般に、１つのサービスに対して複数のサービス・プロバイダ・サーバが地理的に異なる場所に分散している。本実施例１では、説明を簡単にするために、図１に示すように、サービスＡを提供する２つのＳＰサーバ２０１，２０２と、他のサービスＢを提供する２つのＳＰサーバ２０３，２０４が設置されているとする。

また、前記ルックアップサーバ３は、図２に示すように、前記各ＳＰサーバのサービス情報が登録されたUDDIレジストリ３０１と、前記UDDIレジストリ３０１を検索するサービス情報検索手段３０２と、前記各ＳＰサーバ２０１，２０２，２０３，２０４に接続されたモニタリングエージェント６０１，６０２，６０３、６０４にメトリック要求を発行し必要なネットワーク区間とＳＰサーバのメトリック情報を収集するメトリック情報収集手段３０３と、前記メトリック情報収集手段３０３で収集したメトリック情報にもとづき前記サービス・リクエスタ・サーバ５から指定されたワークフローに対する最適なＳＰサーバを算出する最適サーバ算出手段３０４と、算出した最適なＳＰサーバを指定して前記サービス・リクエスタ・サーバ５からのリクエストを前記ＳＰサーバに送信するリクエスト送信手段３０５と、前記各手段３０１，３０２，３０３，３０４，３０５で行う処理の制御を行う処理制御手段３０６とを備える。

また、前記ＳＰサーバ２０１に接続された前記モニタリングエージェント６０１は、図２に示すように、前記ルックアップサーバ３からのメトリック要求を受信したときに、必要なネットワーク区間とＳＰサーバ２０１のメトリック測定を行うメトリック測定手段６０１Ａと、処理制御手段６０１Ｂとを備える。また、図示は省略するが、他のＳＰサーバ２０２，２０３，２０４に接続された各モニタリングエージェント６０２，６０３，６０４も、前記モニタリングエージェント６０１と同様に、前記メトリック測定手段を備えている。

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

本実施例１のWebサービス提供システムでは、まず、たとえば、図３に示すように、前記サービスＡおよびサービスＢを提供する各ＳＰサーバ２０１，２０２，２０３，２０４のサービス情報を前記ルックアップサーバ３のUDDIレジストリ３０１に登録する。このとき、前記UDDIレジストリ３０１には、たとえば、前記各ＳＰサーバ２０１，２０２，２０３，２０４のサービス情報とあわせて、各ＳＰサーバ２０１，２０２，２０３，２０４を設置しているサービスプロバイダ（事業者）の情報も登録する。またこのとき、前記各ＳＰサーバ２０１，２０２，２０３，２０４のサービス情報が、たとえば、すでにパブリックUDDIへの登録が完了している場合には、その旨と登録通知をルックアップサーバ３へ送信してもよい。

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

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

前記ルックアップサーバ３は、前記サービス・リクエスタ・サーバ５からのアクセス要求およびワークフローを受信したら、たとえば、前記処理制御手段３０６から前記メトリック情報収集手段３０３に前記ワークフローを渡す。前記メトリック情報収集手段３０３では、渡されたワークフローにもとづいて、該当するサービス・プロバイダが設置した全てのＳＰサーバに接続されたモニタリングエージェントで行うメトリック情報の測定項目を指定する。そして、前記処理制御手段を介して前記各モニタリングエージェントにメトリック測定要求を発行する。本実施例１では、前記ワークフローに、サービスＡを実行した後サービスＢを実行すると指定されている。そのため、前記メトリック情報収集手段３０３では、前記サービスＡを提供する全ＳＰサーバ２０１，２０２および前記サービスＢを提供する全ＳＰサーバ２０３，２０４に接続されたモニタリングエージェント６０１，６０２，６０３、６０４に対して前記メトリック要求を発行する。またこのとき、前記Webサービスの提供経路としては、前記ルックアップサーバ３、前記サービスＡを提供する第１ＳＰサーバ２０１、前記サービスＢを提供する第１ＳＰサーバ２０３、サービス・リクエスタ・サーバ５という経路、前記ルックアップサーバ３、前記サービスＡを提供する第１ＳＰサーバ２０１、前記サービスＢを提供する第２ＳＰサーバ２０４、サービス・リクエスタ・サーバ５という経路、前記ルックアップサーバ３、前記サービスＡを提供する第２ＳＰサーバ２０２、前記サービスＢを提供する第１ＳＰサーバ２０１、サービス・リクエスタ・サーバ５という経路、前記ルックアップサーバ３、前記サービスＡを提供する第２ＳＰサーバ２０２、前記サービスＢを提供する第２ＳＰサーバ２０４、サービス・リクエスタ・サーバ５という経路の４通りがある。そのため、前記メトリック情報収集手段３０３は、たとえば、前記サービスＡの第１ＳＰサーバ２０１に接続されたモニタリングエージェント６０１に対して、前記第１ＳＰサーバ２０１とルックアップサーバ３との間のRTT、前記第１ＳＰサーバ２０１と前記サービスＢの第１ＳＰサーバ２０３との間のRTT、前記第１ＳＰサーバ２０１と前記サービスＢの第２ＳＰサーバ２０４との間のRTT、前記第１ＳＰサーバ２０１のサーバ状況を測定するように指定する。同様に、前記サービスＡの第２ＳＰサーバ２０２に接続されたモニタリングエージェント６０２に対しては、前記第２ＳＰサーバ２０２とルックアップサーバ３との間のRTT、前記第２ＳＰサーバ２０２と前記サービスＢの第１ＳＰサーバ２０３との間のRTT、前記第２ＳＰサーバ２０２と前記サービスＢの第２ＳＰサーバ２０４との間のRTT、前記第２ＳＰサーバ２０２のサーバ状況を測定するように指定する。また、前記サービスＢの第１ＳＰサーバ２０３に接続されたモニタリングエージェント６０３に対しては、前記第１ＳＰサーバ２０３とサービス・リクエスタ・サーバ５との間のRTT、前記第１ＳＰサーバ２０３のサーバ状況を測定するように指定する。同様に、前記サービスＢの第２ＳＰサーバ２０４に接続されたモニタリングエージェント６０４に対しては、前記第２ＳＰサーバ２０４とサービス・リクエスタ・サーバ５との間のRTT、前記第２ＳＰサーバ２０４のサーバ状況を測定するように指定する。そして、これらの測定項目の指定をしたら、各モニタリングエージェント６０１，６０２，６０３，６０４に対してメトリック要求を送信する。

前記ルックアップサーバ３からのメトリック要求を受信した各モニタリングエージェント６０１，６０２，６０３，６０４は、指定された各測定項目のメトリック測定を行う。そして、指定された全項目のメトリック測定が終了したら、それらのメトリック情報（測定結果）をまとめて前記ルックアップサーバ３へ送信する。

前記ルックアップサーバ３は、前記各モニタリングエージェント６０１，６０２，６０３，６０４から送信されたメトリック情報を受信すると、そのメトリック情報を前記処理制御手段３０６から前記メトリック情報収集手段３０３に渡す。前記メトリック情報収集手段３０３は、要求した全てモニタリングエージェントからのメトリック情報がそろったら、それらのメトリック情報を前記最適サーバ算出手段３０４に渡す。前記最適サーバ算出手段３０４では、前記メトリック情報にもとづいて前記サービス・リクエスタ・サーバ５が指定したワークフローにおけるサービス完了時間の観点から、最適なＳＰサーバの組み合わせを算出し決定する。このときの、前記最適なサーバの算出方法についての詳細な説明は省略するが、本実施例１では、前記サービスＡに関しては第１ＳＰサーバ２０１が最適なサーバとして算出され、前記サービスＢに関しては第２ＳＰサーバ２０４が最適なサーバとして算出されたとする。

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

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

前記ルックアップサーバ３は、前記サービス・リクエスタ・サーバ５からのリクエスト（SOAPメッセージ）を受信したら、前記リクエスト送信手段３０５のSOAPプロキシを利用して、前記リクエストのSOAPヘッダに前記最適サーバ算出手段３０４で決定した各サービスの最適なＳＰサーバを中継ノードおよび最終受信ノードとして記入して指定する。本実施例１では、サービスＡのＳＰサーバ２０１が中継ノードとして指定され、サービスＢのＳＰサーバ２０４が最終受信ノードとして指定される。そして、前記中継ノードおよび最終受信ノードの指定が終了したら、前記SOAPプロキシは、前記リクエスト（SOAPメッセージ）を最初の中継ノード（ＳＰサーバ）に送信する。本実施例１では、前記サービスＡの第１ＳＰサーバ２０１に送信される。

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

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

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

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

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

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

前記メトリック情報を保持する場合、前記ルックアップサーバ３は、図４に示すように、前記実施例１で説明した各手段３０１，３０２，３０３，３０４，３０５，３０６に加えて、あるWebサービスを提供したときに前記最適サーバ算出手段３０４で算出した最適サーバの情報を最適サーバ提供情報として一時的に保持（キャッシュ）する提供情報保持手段３０７を備える。

また、前記モニタリングエージェント６０１は、図４に示すように、前記実施例１で説明した各手段６０１Ａ，６０１Ｂに加えて、前記モニタリングエージェント６０１が接続（設置）されたＳＰサーバ２０１にかかっている負荷の度合いやネットワークの通信状態を定期的に測定し、前記ＳＰサーバ２０１が通信可能か否かの判定をする通信状態測定手段６０１Ｃを備える。このとき、前記通信状態測定手段６０１ｃは、たとえば、前記ＳＰサーバ２０１にかかる負荷がある閾値を越えて通信不能な状態と判定した場合、前記ルックアップサーバ３に対して通信不能通知を送信する。また、前記通信状態測定手段６０１ｃは、たとえば、前記ＳＰサーバ２０１が通信不能な状態になった後、前記ＳＰサーバ２０１にかかる負荷が軽減して通信可能な状態になった場合、前記ルックアップサーバ３に対して通信可能通知を送信する。

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

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

本実施例２のWebサービス提供システムを適用した場合も、前記各ＳＰサーバ２０１，２０２，２０３，２０４のサービス情報をルックアップサーバ３のUDDIレジストリ３０１に登録する処理や、前記ルックアップサーバ３のUDDIレジストリ３０１（Webサービス）の検索手順については、前記実施例１の場合と同じであるため、その詳細な説明は省略する。

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

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

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

そこで、本実施例２のような手順でWebサービスを提供する場合、たとえば、前記モニタリングエージェント６０１は、前記通信状態測定手段６０１Ｃを用いて定期的に、前記ＳＰサーバ２０１にかかる負荷やネットワークの状態を測定し、前記ＳＰサーバ２０１が十分な性能でサービスを提供できる状態（通信可能状態）であるか否かの判定をする。そして、たとえば、図６に示すように、あるWebサービスが完了した後、前記通信状態測定手段６０１Ｃにおいて前記ＳＰサーバ２０１が十分な性能でサービスを提供できない状態（通信不能状態）であると判定されたら、前記モニタリングエージェント６０１からルックアップサーバ３に対して受信不能通知が送信される。同様に、他のモニタリングエージェント６０２，６０３，６０４が備える通信状態測定手段（図示しない）において前記各ＳＰサーバ２０２，２０３，２０４が通信不能状態であると判定した場合、前記ルックアップサーバ３に対して受信不能通知を送信する。前記ルックアップサーバ３は、前記受信不能通知を受信したら、その通知を、たとえば、前記提供情報保持手段３０７で保持する。ここでは、前記サービスＡを提供する第１ＳＰサーバ２０１へのアクセスが集中し、受信不能通知が送信されたとする。

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

そこで、前記ルックアップサーバ３は、前記キャッシュを検出した後、図６に示すように、前記キャッシュで指定されているＳＰサーバが受信可能な状態か否かを判定する。そして、受信可能な場合は、前述のような手順でWebサービスを提供する。また、受信可能な状態でない場合は、キャッシュにある次善の経路を検索し、指定する。いまの場合、前記ルックアップサーバ３は、前記サービスＡの第１ＳＰサーバ２０１から受信不能通知を受信しているので、前記サービスＡの第１ＳＰサーバ２０１を利用できない。そのため、前記ルックアップサーバ３は、次善の経路を検索する。そして、たとえば、前記サービスＡの第２ＳＰサーバ２０２、前記サービスＢの第２サーバ２０４、前記サービス・リクエスタ・サーバ５という経路の提供情報（キャッシュ）を検出したとする。この場合、その経路を最適サーバ情報として前記リクエスト送信手段３０５に渡し、Webサービスを提供する。また、次善の経路を検出できなかった場合は、前記実施例１で説明したようにメトリック情報を収集し、現時点での最適サーバを算出する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また、前記Webサービスの利用料に関しては、前記ＳＰサーバ２０１に課金手段２０１Ａを設ける代わりに、図９（ｂ）に示すように、前記ルックアップサーバ３にサービス利用料決済代行手段３０９を設けてもよい。この場合、前記ルックアップサーバ３は、前記サービス・リクエスタ・サーバ５が前記ルックアップサーバ３を介してWebサービスを利用したときに、前記ルックアップサーバ３からの最適サーバ提供料と前記Webサービスの利用料をそれぞれ、前記サーバ利用料課金手段３０８とサービス利用料決済代行手段３０９に蓄積する。そして、前記ルックアップサーバ３を設置した事業者は、あらかじめ定められた方法で、前記サービス・リクエスタ・サーバ５を設置した事業者から最適サーバ提供料と前記Webサービスの利用料を徴収する。その後、前記ルックアップサーバ３を設置した事業者は、前記サービス・リクエスタ・サーバ５を設置した事業者から徴収した前記Webサービスの利用料を前記ＳＰサーバ２０１を設置した事業者に対して支払う。

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

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

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

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

本実施例５では、インターネット１上に、図１０に示すように、銀行サービス（サービスＡ）を提供するサービス・プロバイダのＳＰサーバ２０１，２０２、信託運用サービス（サービスＢ）を提供するサービス・プロバイダのＳＰサーバ２０３，２０４、経済情報配信サービス（サービスＣ）を提供するサービス・プロバイダのＳＰサーバ２０５，２０６が設置されているとする。また、図示は省略するが、前記インターネット１上には、これらのＳＰサーバの他に、たとえば、経済情報閲覧サービスを提供するサービス・プロバイダのＳＰサーバ等が設置されていてもよい。またこのとき、各WebサービスのＳＰサーバは、サービス情報をすでに前記ルックアップサーバ３に登録しているとする。

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

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

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

このとき、前記ルックアップサーバ３は、リクエストされた各Webサービスの全てのサービス・プロバイダ・サーバ２０１，２０２，２０３，２０４，２０５，２０６に接続されたモニタリングエージェント６０１，６０２，６０３，６０４，６０５，６０６に対しメトリック要求を発行し、メトリック情報を収集する。前記メトリック情報は、前記実施例１から実施例３で説明したような方法で収集すればよいので、詳細な説明は省略する。

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

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

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

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

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

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

前記実施例１から実施例５では、前記Webサービス提供システムを構成するサービス・リクエスタ・サーバ５、前記ルックアップサーバ３、前記ＳＰサーバ２０１，２０２，２０３，２０４およびモニタリングエージェント６０１，６０２，６０３，６０４は、たとえば、図１に示したように、全てインターネット１上に設置されているが、たとえば、図１２に示すように、ルックアップサーバ運営事業者がネットワーク７を所有する場合には、前記提供システムを利用してサービスを提供するサービス・プロバイダからの要求にもとづき、前記ルックアップサーバ運営事業者のネットワーク７上に、前記ＳＰサーバ２０１，２０２，２０３，２０４およびモニタリングエージェント６０１，６０２，６０３，６０４を設置することもできる。

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

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

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

符号の説明

１…インターネット
２…Webサーバ
２０１，２０２，２０３，２０４，２０５，２０６…サービス・プロバイダ・サーバ（ＳＰサーバ）
３…ルックアップサーバ
３０１…サービス情報登録手段（UDDIレジストリ）
３０２…サービス情報検索手段
３０３…メトリック情報収集手段
３０４…最適サーバ算出手段
３０５…リクエスト送信手段
３０６…処理制御手段
３０７…提供情報保持手段
３０８…サーバ利用料課金手段
３０９…サービス利用料決済代行手段
４…ユーザ端末
５…サービス・リクエスタ・サーバ
６０１，６０２，６０３，６０４，６０５，６０６…モニタリングエージェント
７…ルックアップサーバ運営事業者のネットワーク

Claims (10)

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

Images