JP4507620B2 - 分散サービスの実行をホストするためのリソースを提供するサービス提供インフラストラクチャのサービス・インスタンスにサービス要求をルーティングするためのシステム、並びにその方法及びコンピュータ・プログラム - Google Patents

Description

本発明は、Ｗｅｂサービスおよびグリッド・サービスを含む分散コンピューティングの分野に関し、より詳細には、サービス要求をサービス提供インフラストラクチャ内のサービス・インスタンスにルーティングすることに関する。

Ｗｅｂサービスは分散コンピューティングの最先端であり、ワールド・ワイド・ウェブを介した構成要素ベース・アプリケーションの急速な開発をサポートするために真のユニバーサル・モデルを開発するための基礎とみなされている。Ｗｅｂサービスは、当分野では、サービス指向の構成要素ベース・アプリケーション・アーキテクチャを記した数多くの新標準を含むものとして知られている。特に、Ｗｅｂサービスは緩やかに結合された、語義的には個別の機能をカプセル化した再使用可能なソフトウェア構成要素であり、分散されて、標準的なインターネット・プロトコルを介してプログラムに従ってアクセスすることができる。

概念的に言えば、Ｗｅｂサービスとは、プロセス内の離散タスクが価値ネット全体にわたって広く分散されたモデルを表現する。とりわけ、多くの業界エキスパート達は、サービス指向のＷｅｂサービスがインターネットの次の発展段階においてイニシアティブを握るものと考えている。通常、ＷｅｂサービスはＷｅｂサービス定義言語（ＷＳＤＬ）などのインターフェースによって定義付けることが可能であり、インターフェースに従って実施可能であるが、実施がＷｅｂサービス・インターフェースに準拠している限り、その細部は問題ではない。Ｗｅｂサービスが対応するインターフェースに従って実施されると、その実施は、当分野でよく知られたUniversal Description, Discover and Integration（ＵＤＤＩ）などのＷｅｂサービス・レジストリに登録することができる。登録すると、サービスの要求者は、たとえば、Simple Object Access Protocol（ＳＯＡＰ）を含む、任意のサポーティング・メッセージング・プロトコルを使用することで、Ｗｅｂサービスにアクセスすることができる。

Ｗｅｂサービスをサポートするサービス指向アプリケーション環境では、信頼できるサービスを見つけ、それら信頼できるサービスをアプリケーションの目的に合わせてリアルタイムで動的に統合することには問題があることがわかっている。レジストリ、ディレクトリ、およびディスカバリ・プロトコルは、サービスの検出およびサービス対サービスの相互接続論理を実施するための基本構造を提供するものであり、レジストリ、ディレクトリ、およびディスカバリ・プロトコル単独では、分散相互運用性には適さない。むしろ、統一アプリケーションの形成においてＷｅｂサービスの分散を容易にするためには、より構造化され、形式化されたメカニズムが必要である。

とりわけ、Open Grid Services Architecture（ＯＧＳＡ）を介したグリッド・メカニズムの生理機能は、さもなければレジストリ、ディレクトリおよびディスカバリ・プロトコルの排他的使用では不可能な方法で、以下では「グリッド・サービス」と呼ぶ分散されたシステムにまたがるＷｅｂサービスの発見と結合の両方において、プロトコルを提供することができる。Ian Foster, Carl Kesselman, およびSteven Tueckeによる”The Anatomy of the Grid”, Intl J. Supercomputer Applications、２００１年、およびIan Foster, CarlKesselman, Jeffrey M. NickおよびSteven Tueckeによる”The Physiology of the Grid”, Globus.org、２００２年６月２２日の両方に記載されるように、グリッド・メカニズムは、分散コンピューティング・インフラストラクチャを提供することができ、それを介して要求側クライアントがグリッド・サービス・インスタンスを作成、命名、および発見できる。

グリッド・サービスは、拡張リソースの共用およびスケジューリングのサポート、高度な分散アプリケーションに共通して必要な長寿命状態のサポート、ならびに企業間コラボレーションのサポートを提供することにより、単なるＷｅｂサービスを延長するものである。さらに、Ｗｅｂサービスは永続的なサービスの発見および呼出しに対処するだけのものである一方、グリッド・サービスは、動的に作成および破壊が可能な一時的サービス・インスタンスをサポートするものである。グリッド・サービスを使用する著しい利点には、コンピューティング・リソースのより効率的な使用による情報技術の所有コストの削減、および様々なコンピューティング構成要素の統合の容易性の向上が含まれる。したがって、グリッド・メカニズム、詳細には、ＯＧＳＡに準拠したグリッド・メカニズムは、サービス指向アーキテクチャを実装することが可能であり、それによって、たとえ組織の領域をまたがる場合であっても分散システム統合の基礎を提供することができる。

コンピューティング・グリッド内では、サービス提供インフラストラクチャは、グリッド・サービスなどの分散サービスの実行をホストするための処理リソースを提供することができる。サービス提供インフラストラクチャは、サーバ・コンピューティング・デバイスと、直接接続ストレージ、ネットワーク接続ストレージ、およびストレージ・エリア・ネットワークを含むストレージ・システムと、および通信の帯域幅などを含む、リソース・セットを含むことができる。サービス提供インフラストラクチャ内で処理される個々のトランザクションは、これらリソースの様々な混合を消費することができる。

グリッド・サービスのコンテキストでは、指定されたサービス提供インフラストラクチャ内でホストされる特定のサービス・インスタンスに、特定サービス・インスタンスの待ち行列長さに従って、要求をルーティングすることが知られている。待ち行列長さに基づいた特定のサービス・インスタンスの論理選択は、サービス処理の要求を可能な最短の待ち行列に配置することによって、応答時間を最小にするための試みを表す。同様に、ホスティングサービス提供インフラストラクチャの処理機能を、特定のサービス・インスタンスを選択する際に考慮に入れることができる。

より詳細には、他のサービス・インスタンスの２倍の速さで要求を処理できる特定サービス・インスタンスは、特定サービス・インスタンスが他のサービス・インスタンスの待ち行列の２倍の待ち行列を有する場合、他のサービス・インスタンスと同じ処理スループットを有することができる。さらに、待ち行列長さ選択ストラテジは細分性が粗すぎる可能性があり、要求されたサービスのリソース要件をサービス提供インフラストラクチャの使用可能なリソースと突き合わせるものではない。特に、従来の環境では、単なるスカラ・ベンチマークだけをサービス提供インフラストラクチャ全体に関連付けることができる。したがって、サービス提供インフラストラクチャの細分性の高い構成要素を、考慮に入れることは決してない。
Ian Foster, Carl Kesselman, Steven Tuecke, "The Anatomy of the Grid", Intl J. Supercomputer Applications (2001) Ian Foster, Carl Kesselman, Jeffrey M. Nick,Steven Tuecke, "The Physiology of the Grid", Globus. Org (June 22, 2002) "An Open Grid Services Architecture", Globus Tutorial, Argonne National Lavatory, (January 29, 2002)

本発明の目的は、サービス要求をルーティングするためのシステム、並びにその方法及びコンピュータ・プログラムを提供することである。

本発明によれば、個々のサービス要求は、選択されたサービス・ホスト内のサービス・インスタンスにルーティングされることができ、該選択されたサービス・ホストは、サービス要求のリソース要件および消費パターンに最も適合したリソース構成要素を有する。このようにして、単なるスカラ・ベンチマークだけをサービス提供インフラストラクチャ全体に関連付けることのできる従来の環境とは異なり、サービス要求をサービス・インスタンスにルーティングするときに、グリッド・ホストのサービス提供インフラストラクチャの細分性の高い構成要素を考慮に入れることができる。

サービス要求をルーティングするためのシステムは、リソース・モデルを格納するモデル・テーブルを含む。モニタは、モデル・テーブルに結合されており、サービス要求の処理をモニタし、当該処理中に消費される個々のリソース構成要素を識別して、当該識別された個々のリソース構成要素に基づいて前記リソース・モデルを生成する。ルータが、モデル・テーブルに結合されており、分散サービスの実行のために、少なくとも２つのサービス・ホストについてリソース・ベクトルを計算し、当該モデル・テーブルからリソース・モデルを検索し、当該計算されたリソース・ベクトルで表されるリソース構成要素それぞれと当該検索されたリソース・モデルとの突き合せに基づいて選択されたサービス・インスタンスに前記サービス要求をルーティングする。

重要なことに、ルーティングは、サービス提供インフラストラクチャのリソース構成要素とサービス要求のリソース・モデルとの突き合わせに基づくことができる。最終的に、リソース構成要素は、サービス提供インフラストラクチャに対応するリソース・ベクトルで表される。この点に関して、サーバのリソース構成要素はサーバ・タイプを含み、当該ストレージ・システムのリソース構成要素はストレージ・システム・タイプを含み、当該ネットワークのリソース構成要素は帯域幅を含む。

サービス要求をサービス提供インフラストラクチャのサービス・インスタンスにルーティングする方法は、サービス要求を受け取ること、および少なくとも２つのサービス・ホストについてリソース・ベクトルを計算することを含むことができる。各サービス・ホストは、対応するサービス提供インフラストラクチャを有することができる。サービス要求について、リソース・モデルを検索することができる。したがって、最適のリソース・ベクトルを識別するために、検索されたリソース・モデルをリソース・ベクトルのそれぞれと突き合せることができる。

最終的に、サービス要求を、識別された最適のリソース・ベクトルに関連付けられた選択されたサービス・ホストにルーティングすることができる。

リソース・モデルを生成するために、受け取ったサービス要求の処理をモニタすることが可能であり、処理中に消費されるサービス・ホスト内の個々のリソース構成要素を識別することができる。その結果、サービス・ホスト内の識別された個々のリソース構成要素に基づいて、サービス要求についてのリソース・モデルを生成することができる。

現在の好ましい実施形態が図面に示されているが、本発明は、図示された精密な配置構成および手段に限定されるものでないことを理解されたい。

本発明は、分散サービスの実行のために、分散サービスの実行のために、少なくとも２つのサービス・ホストについてリソース・ベクトルを計算し、当該モデル・テーブルからリソース・モデルを検索し、当該計算されたリソース・ベクトルで表されるリソース構成要素それぞれと当該検索されたリソース・モデルとの突き合せができる。最適の突合せに基づいて、サービス処理の要求を、適合したサービス提供インフラストラクチャ内でホストされるサービス・インスタンスに割り当てることができる。このようにして、サービス提供インフラストラクチャの細分性の粗いスカラ評価に基づいた、サービス要求の単なるルーティングを回避することができる。

図１は、本発明に従い、サービス提供インフラストラクチャ内でホストされるサービス・インスタンスに、サービス要求をルーティングするように構成されたサービス・グリッドのブロック図であり、サービス提供インフラストラクチャは、要求されたサービスのリソース要件に最も適したリソースを有する。当業者であれば明らかなように、サービス・グリッドは、コンピュータ通信ネットワーク１１０、たとえばインターネットを横切って、グリッド様式で相互に通信可能なようにリンクされた１つまたは複数のグリッド・ホスト１２０で構成されたＷｅｂサービス・グリッドとすることができる。個々の要求側クライアント１９０は、１つまたは複数のグリッド・ホスト１２０にＷｅｂサービスへのアクセスを要求することができる。特に、当分野で周知であるように、要求側クライアント１９０とグリッド・ホスト１２０との間で、ＳＯＡＰ符号化メッセージを交換することができる。メッセージは、特定のＷｅｂサービスの位置を発見するための要求、ならびに要求されたＷｅｂサービスのネットワーク位置が明示された要求に対する応答を含むことができる。

グリッド・ホスト１２０は、中央集中方式で１つのサーバ・コンピューティング・デバイス内に配置されるか、または分散方式で複数のサーバ・コンピューティング・デバイスにまたがって配置されることができる。どちらの場合も、マークアップ文書などのコンテンツに関するネットワーク要求に応答するように構成可能なＷｅｂサーバ１４０を提供することができる。当業者であれば理解されるように、Ｗｅｂサーバ１４０は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）メッセージを処理するために、およびハイパーテキスト・マークアップ言語（ＨＴＭＬ）形式文書、拡張可能マークアップ言語（ＸＭＬ）形式文書などのマークアップを配布するように構成されることができる。

Ｗｅｂサーバ１４０は、グリッド・ホスト１２０内でアプリケーション・サーバ１５０と通信可能なようにリンクされることができる。アプリケーション・サーバは当分野で周知であり、通常は、インタープリタ方式またはネイティブ形式のいずれかでマシン・コードを処理するように構成される。従来のアプリケーション・サーバは、スクリプトおよびサーブレットなどのサーバ側論理を処理するものである。いかなる場合でも、アプリケーション・サーバ１５０は、Ｗｅｂサービス・エンジン１６０とリンクされることができ、Ｗｅｂサービス・エンジンは、グリッド・ホスト１２０内の１つまたは複数のＷｅｂサービス・コンテナにある個々のＷｅｂサービスをインスタンス化するように構成される。このＷｅｂサービス・インスタンスは、グリッド・ホスト１２０のリソース１３０にアクセスすることができる。当業者であれば、リソース１３０の集合をサービス提供インフラストラクチャの基礎とみなすことができることを理解されよう。そのため、リソース１３０は、サーバ・コンピューティングのデバイスおよびプロセス、ストレージ・システム、ならびに通信およびコンピューティングの帯域幅を含むことができる。

重要なことには、グリッド・サービス・メカニズム１７０は、各グリッド・ホスト１２０内に配置されることができる。グリッド・サービス・メカニズム１７０は、ＯＧＳＡによって定義され、たとえばグローバス・プロジェクトのグローバス・ツールキット機能（非特許文献３を参照）に従って指定されたような、グリッド・サービス・インターフェースを実施することができる。当分野で周知であるように、ＯＧＳＡに準拠したグリッド・サービス・インターフェースは、以下のインターフェースおよび挙動を含むことができる。
１．Ｗｅｂサービスの作成（ファクトリ）
２．グローバル・ネーミング（グリッド・サービス処理）および参照（グリッド・サービス参照）
３．寿命管理
４．登録および発見
５．認証
６．通知
７．並行処理
８．管理の容易性
この点に関して、グリッド・サービス・メカニズム１７０はファクトリ・インターフェースを含むことができ、該ファクトリ・インターフェースは、「ファクトリ作成サービス」を使用して、選択されたＷｅｂサービスのインスタンスのクローンを、新しいまたは既存のアプリケーション・コンテナ内に作成できる。

重要なことに、グリッド・サービス・メカニズム１７０は、要求されたＷｅｂサービスのクローン・インスタンスを、１つまたは複数のリモート・グリッド・ホスト１２０にまたがってインスタンス化することができる。特に、グリッド・アーキテクチャの目的と矛盾することなく、個々のリモート・グリッド・ホスト１２０により経験する処理負荷が受入れ可能な容量または事前に指定された容量を超える場合、選択されたＷｅｂサービスの新しいインスタンスをホストするために、他の個々のリモート・グリッド・ホスト１２０を選択することができる。いかなる場合でも、ルーティング・プロセス２００Ｂは、指定されたＷｅｂサービス内で処理するサービス要求の受取りに応答して、指定されたＷｅｂサービスの特定のインスタンスとは関係なく、サービス要求を処理するためにグリッド・ホスト１２０内の特定のサービス・インスタンスを選択することができる。

重要なことに、特定のサービス・インスタンスを選択する場合、特定のサービス・インスタンスのグリッド・ホスト１２０のサービス提供インフラストラクチャに関連付けられたリソース１３０を考慮の対象とすることができる。突合せに着手するために、モニタ・プロセス２００Ａは、グリッド・ホスト１２０内で処理される各トランザクションについて、グリッド・ホスト１２０内でのリソース１３０の使用をモニタすることが可能であり、それによってトランザクションのリソース要件および消費モデルを確立することができる。各トランザクションについて確立されたモデルは、モデル・テーブル２００Ｃにストアすることができる。

その後、ルータは、ルーティング・プロセス時に考慮中の各グリッド・ホスト１２０について、リソース・ベクトルを確立することができる。リソース・ベクトルは、グリッド・ホスト１２０のサービス提供インフラストラクチャの基礎を形成する、個々のリソース１３０のスカラ値を含むことができる。その例には、使用可能な処理帯域幅、使用可能な通信帯域幅、ストレージ・タイプ、容量、および応答性、サーバ・タイプなどを含むことができる。グリッド・ホストのサービス提供インフラストラクチャについて確立された各リソース・ベクトルは、ベクトル・テーブル２００Ｄにストアすることができる。さらに、ベクトルについてのコスト要素を計算することが可能であり、その結果、ベクトル・テーブル２００Ｄ内の個々のベクトルをスカラ様式で互いに比較することができる。

ルーティング・プロセス２００Ｂでサービス要求が受け取られると、ルーティング・プロセス２００Ｂは、サービス要求に関連付けられたトランザクション・タイプを識別することができる。このトランザクション・タイプに基づいて、モデル・テーブル２００Ｃからトランザクション・タイプのモデルを検索し、受け取ったサービス要求を処理できる使用可能なサービス・インスタンス、または受け取ったサービス要求を処理できるサービス・インスタンスをインスタンス化するための機能のいずれかを有するグリッド・ホスト１２０に関連付けられた、ベクトル・テーブル２００Ｄ内のリソース・ベクトルと突き合せることができる。この点に関して、要求を処理するために適切なグリッド・ホスト１２０を選択するように、最適アルゴリズムを適用することができる。

図２は、図１のグリッド内で、要求されたサービスのリソース要件に最も適したリソースを有するサービス提供インフラストラクチャ内のサービス・ホストに、サービス要求をルーティングするためのプロセスを示す流れ図である。始めに、ブロック２１０でグリッド・サービス要求を受け取ることができる。ブロック２２０では、サービス・タイプを識別することができる。ブロック２３０では、それぞれのリソース・ベクトルを確立するために、要求されたサービス・タイプのサービス・インスタンスをホストするように構成された使用可能なグリッド・ホストのリソースを照会することができる。さらに、意思決定ブロック２４０では、サービス・タイプについてのモデルが計算されたかどうかを判定することができる。

意思決定ブロック２４０で、識別されたサービス・タイプについてのモデルが見つからない場合、ブロック２８０で、待ち行列長さまたはスカラ・パフォーマンスに関して最高の可用性を示す、要求されたサービス・タイプのサービス・インスタンスをホストするように構成されたグリッド・ホストを選択することができる。そうでない場合は、ブロック２５０で、サービス・タイプについてのリソース・モデルを検索し、ブロック２６０で、要求されたサービス・タイプのサービス・インスタンスをホストすることができるグリッド・ホスト・セットのモデルおよびリソース・ベクトルに、最適分析を適用することができる。ブロック２６０の最適分析に基づいて、ブロック２７０では、サービス要求を特定のグリッド・ホスト内にあるサービス・インスタンスにルーティングすることができる。

本発明は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せにおいて実現可能である。本発明の方法およびシステムの実施は、１つのコンピュータ・システム内での中央集中方式で、あるいは様々な要素がいくつかの相互接続されたコンピュータ・システムにまたがって拡散された分散方式で、実現可能である。本明細書に記載された方法を実施するように適合されたどのような種類のコンピュータ・システムまたは他の装置も、本明細書に記載された機能の実行に好適である。

ハードウェアおよびソフトウェアの典型的な組合せは、ロードされ実行されると、本明細書に記載された方法を実行するようにコンピュータ・システムを制御する、コンピュータ・プログラムを備えた汎用コンピュータ・システムであってよい。本発明は、本明細書に記載された方法の実施を可能にするすべての機能を含み、コンピュータ・システムにロードされるとこれらの方法を実行できる、コンピュータ・プログラム製品に組み込むことも可能である。

本コンテキストでのコンピュータ・プログラムまたはアプリケーションとは、情報処理機能を有するシステムに、直接あるいは、ａ）他の言語、コード、または表記法への変換およびｂ）異なる材料形式での再生成のいずれかまたは両方を行った後、のどちらかに、特定の機能を実行させるように意図された、任意の言語、コード、または表記法での命令セットの任意の表現を意味するものである。重要なことに、本発明は、その精神または不可欠な属性を逸脱することなく他の特有の形式で具体化することが可能であり、したがって、本発明の範囲を示すものとして、前述の明細書ではなく、添付の特許請求の範囲を参照されたい。

本発明に従い、要求されたサービスのリソース要件に最も適したリソースを有するサービス提供インフラストラクチャ内のサービス・ホストに、サービス要求をルーティングするように構成されたサービス・グリッドのブロック図である。 図１のグリッド内で、要求されたサービスのリソース要件に最も適したリソースを有するサービス提供インフラストラクチャ内のサービス・ホストに、サービス要求をルーティングするためのプロセスを示す流れ図である。

Claims (4)

1. 分散サービスの実行をホストするためのリソースを提供するサービス提供インフラストラクチャのサービス・インスタンスにサービス要求をルーティングするためのシステムであって、
   前記サービス提供インフラストラクチャは、サーバ、ストレージ・システム、及びネットワークの各リソースを含み、当該サーバのリソース構成要素はサーバ・タイプを含み、当該ストレージ・システムのリソース構成要素はストレージ・システム・タイプを含み、当該ネットワークのリソース構成要素は帯域幅を含み、
   前記ルーティングするためのシステムは、
   前記サービス要求についてのリソース・モデルを格納するモデル・テーブルと、
   前記モデル・テーブルに結合されたモニタと、
   前記モデル・テーブルに結合されたルータと
   を含み、
   前記分散サービスの実行のために、前記ルータは、少なくとも２つのサービス・ホストについてリソース・ベクトルを計算し、サービス要求を受け取った時点の当該サービス要求に対応するリソース・モデルを前記モデル・テーブルから検索し、前記サービス要求に対応するリソース・モデルが前記モデル・テーブルに見つかった場合に、前記ルータは、前記計算されたリソース・ベクトルで表されるリソース構成要素それぞれと前記検索されたリソース・モデルとの突き合せに基づいて選択されたサービス・インスタンスに前記サービス要求をルーティングし、前記サービス要求に対応するリソース・モデルが前記モデル・テーブルに見つからなかった場合に、前記ルータは、前記サービス要求を受け取った時点で処理能力の最も高いホストに当該サービス要求の処理を割り当て、そして、前記モニタは、当該サービス要求の処理をモニタして、当該サービスの要求の処理中に消費される個々のリソース構成要素を識別し、当該識別された個々のリソース構成要素に基づいてリソース・モデルを生成し、そして、前記モデル・テーブルは当該生成されたリソース・モデルを格納する、前記システム。
2. 前記リソース構成要素が、前記サービス提供インフラストラクチャに対応するリソース・ベクトルで表される、請求項１に記載のシステム。
3. 分散サービスの実行をホストするためのリソースを提供するサービス提供インフラストラクチャのサービス・インスタンスにサービス要求をルーティングするための方法であって、
   前記サービス提供インフラストラクチャは、サーバ、ストレージ・システム、及びネットワークの各リソースを含み、当該サーバのリソース構成要素はサーバ・タイプであり、当該ストレージ・システムのリソース構成要素はストレージ・システム・タイプであり、当該ネットワークのリソース構成要素は帯域幅であり、
   前記方法は、
   サービス要求を受け取るステップと、
   少なくとも２つのサービス・ホストについて、リソース・ベクトルを計算するステップと、
   前記サービス要求を受け取った時点の当該サービス要求に対応するリソース・モデルをモデル・テーブルから検索するステップと、
   前記サービス要求に対応するリソース・モデルが前記モデル・テーブルに見つかった場合に、
   最適のリソース・ベクトルを識別するために、前記計算されたリソース・ベクトルで表されるリソース構成要素それぞれと前記検索されたリソース・モデルとを突き合せるステップと、
   前記突き合わせに基づいて選択されたサービス・インスタンスに前記サービス要求をルーティングするステップと
   前記サービス要求に対応するリソース・モデルが前記モデル・テーブルに見つからなかった場合に、
   前記サービス要求を受け取った時点で処理能力の最も高いホストに当該サービス要求の処理を割り当て、そして当該サービス要求の処理をモニタして、当該サービスの要求の処理中に消費される個々のリソース構成要素を識別して、当該識別された個々のリソース構成要素に基づいてリソース・モデルを生成し、そして当該生成されたリソース・モデルを前記モデル・テーブルに格納するステップと
   を含む、前記方法。
4. 分散サービスの実行をホストするためのリソースを提供するサービス提供インフラストラクチャのサービス・インスタンスにサービス要求をルーティングするためのコンピュータ・プログラムであって、ルーティング・システムに、請求項３に記載の方法の各ステップを実行させるコンピュータ・プログラム。

Images