(57)【要約】【課題】コンピューティング・サービス・グリッドを提供すること。【解決手段】グリッドは、１つまたは複数のコンピューティング・サービス・インスタンスと結合されるサービス・デスクを含む。各サービス・インスタンスは、グリッド内のすべてのサービス・インスタンスに共通のインターフェースに適合することができる。グリッド内には、ルーティング・コンポーネントを配置することができる。特に、ルーティング・コンポーネントはサービス要求の１つ１つをサービス・インスタンスの１つ１つにルーティングすることができる。インスタンス選択サービスは、サービスのリクエスタに関連付けられたＱｏＳ特性を満たすのに使用することができる。グリッドは、さらにサービス・インスタンス監視コンポーネントを含むことができる。監視コンポーネントは、サービス要求の１つ１つの処理を担当するサービス・インスタンスの１つ１つのパフォーマンスを監視することができる。フェイル・オーバー論理は、監視コンポーネントが選択されたサービス・インスタンスにおけるフェイル・オーバー状態を検出した場合に、選択されたサービス・インスタンスからのサービス要求をそれ以外のサービス・インスタンスへとルーティングし直すことができる。この点に関連して、フェイル・オーバー状態は、エラー状態および選択されたサービス・インスタンスのパフォーマンスが保証されたレベルのパフォーマンスに追いつけないパフォーマンス不全状態を含むことができる。
2005535949.tif 000002
【特許請求の範囲】
【請求項１】
共通のサービス・インターフェースに適合する複数のサービス・インスタンスと結合されるサービス・デスクと、
サービス・グリッド内に配置され、１つ１つのサービス要求を前記サービス・インスタンスの１つ１つにルーティングする、ルーティング・コンポーネントと
を含む、コンピューティング・サービス・グリッド。
【請求項２】
サービス・インスタンス監視コンポーネントと、
前記サービス・インスタンス監視コンポーネントが前記選択されたサービス・インスタンスにおけるフェイル・オーバー状態を検出した場合に、選択されたサービス・インスタンスからのサービス要求をそれ以外の前記サービス・インスタンスにルーティングし直すように構成される、フェイル・オーバー論理と
をさらに含む、請求項１に記載のコンピューティング・サービス・グリッド。
【請求項３】
前記フェイル・オーバー状態がエラー状態および保証されたパフォーマンスのレベルに追いつけないパフォーマンス不全状態の１つを含む、請求項２に記載のコンピューティング・サービス・グリッド。
【請求項４】
サービス要求を受け取るのに応答して前記サービス・インスタンスの１つ１つをインスタンス化するように構成されるサービス・インスタンス・ファクトリをさらに含む、請求項１または請求項２に記載のコンピューティング・サービス・グリッド。
【請求項５】
前記サービス・デスクが選択サービスを用いて、前記サービス・インスタンスの１つ１つを見つけ出しバインドしてサービス要求に応答するためのグリッド・サービス・インターフェースをさらに含む、請求項１ないし４のいずれかに記載のコンピューティング・サービス・グリッド。
【請求項６】
請求項１ないし５のいずれかに記載のサービス・グリッドにおいて、
サービス要求およびサービス品質（ＱｏＳ、quality of service）特性の指定を受け取るステップと、
前記ＱｏＳ特性の指定と両立するレベルで前記サービス要求を処理できる同等ないくつかのサービス・インスタンスのうちの特定の１つを選択するステップと、
前記サービス要求を処理するために前記選択されたサービス・インスタンスをバインドするステップと
を含む、サービス要求処理方法。
【請求項７】
前記バインドされたサービスのパフォーマンスを監視するステップと、
前記パフォーマンスにおけるフェイル・オーバー状態を検出するステップと、
フェイル・オーバー状態が検出された場合に、前記ＱｏＳ特性の指定と両立する前記レベルで前記サービス要求を処理できる前記同等ないくつかのサービス・インスタンスのうちの代わりとなる１つを選択し、前記サービス要求を処理するために前記代わりとなるサービス・インスタンスをバインドするステップと
を含む、請求項６に記載の方法。
【請求項８】
前記検出するステップが、前記選択されたサービスにおける例外を検出するステップを含む、請求項７に記載の方法。
【請求項９】
前記検出するステップが、前記選択されたサービスにおける前記ＱｏＳ特性の指定が達成できていないパフォーマンスのレベルを検出するステップを含む、請求項７に記載の方法。
【請求項１０】
請求項１ないし５のいずれかに記載のサービス・グリッドにおいて、サービス要求を処理するためのコンピュータ・プログラムを記憶した機械可読ストレージであって、前記コンピュータ・プログラムが、
サービス要求およびサービス品質（ＱｏＳ）特性の指定を受け取るステップと、
ＱｏＳ特性の指定と両立するレベルでサービス要求を処理できる、同等ないくつかのサービス・インスタンスのうちの特定の１つを選択するステップと、
前記サービス要求を処理するために前記選択されたサービス・インスタンスをバインドするステップとを機械に実行させる、定型化された（routine）１組の命令を含む、機械可読ストレージ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピューティング・サービス・グリッドに関する。
【背景技術】
【０００２】
Ｗｅｂサービスは、分散コンピューティングで熱狂的に流行してきており、ＷＷＷ（WorldWide Web）上のコンポーネント・ベースのアプリケーションの迅速な開発を支援するための真に普遍的なモデルを構築する基礎と見られている。Ｗｅｂサービスは、サービス指向でコンポーネント・ベースのアプリケーション・アーキテクチャを記述する、新たに出現した標準のスタックを含むものとして、当技術分野では知られている。具体的には、Ｗｅｂサービスは、離散的な機能を意味論的にカプセル化し、分散し、標準のインターネットのプロトコル群を介してプログラムに従ってアクセス可能な、緩やかに結合され、再利用の可能なソフトウェア・コンポーネントである。
【０００３】
概念としてみると、Ｗｅｂサービスは、ｅビジネスのプロセス内部の離散的なタスクが、バリュー・ネット（valuenet）の全体にわたって広く分散しているというモデルを表している。この業界の多くの専門家が、サービス指向のＷｅｂサービスのイニシアティブを、インターネットの次の革命的フェーズと考えていることは、注目すべきである。通常、ＷｅｂサービスはＷｅｂサービス定義言語（ＷＳＤＬ、WebServices Definition Language）などのインターフェースによって定義可能であり、このインターフェースに従って実装可能であるが、実装がＷｅｂサービス・インターフェースに適合している限り、実装の詳細はほとんど重要ではない。あるＷｅｂサービスが対応するインターフェースに従って実装されると、その実装は、当技術分野によく知られているように、ＵＤＤＩ（UniversalDescription, Discover and Integration）などのＷｅｂサービス・レジストリに登録することができる。登録されると、たとえばＳＯＡＰ（simpleobject access protocol）を含む、なんらかのサポート用メッセージング・プロトコルを使用することにより、そのＷｅｂサービスはサービス・リクエスタによってアクセスが可能である。
【０００４】
ｅユーティリティーズ（electronic utilities）は、このＷｅｂサービスの概念を、ＷＳＤＬ、ＳＯＡＰおよびＵＤＤＩの基本的な分散コンピューティング・インフラストラクチャを越えて拡張するものである。ｅユーティリティーズとは、分散コンピューティング・インフラストラクチャの全体にわたる（across）コンピューティング・サービスへの、従量制で（metered）、連続的な、オン・デマンドのアクセスを提供することを指している。過去のコンピューティング・サービスとは異なり、ｅユーティリティーズの異なるユーザが、交渉して決めたサービス・レベル・アグリーメント（ＳＬＡ、servicelevel agreement）という利用条件に従って、様々なレベルの顧客対応（responsiveness）を、選択したｅユーティリティーズから受けることができ、ｅユーティリティーズは、その限りにおいて、基礎となるインフラストラクチャと密接に絡み合うことになる。具体的には、ｅユーティリティーズに対するＳＬＡは、保証されるパフォーマンスを機能性、可用性、資源、および可用性によって記述できる。このように、サービス品質（ＱｏＳ、qualityof service）は、ｅユーティリティーズの展開（deployment）および流通において、依然として最重要の問題となっている。
【０００５】
Ｗｅｂサービスとｅユーティリティーズをともにサポートする、サービス指向のアプリケーション環境では、信頼できるサービスを見つけ出し、そうした信頼できるサービスを動的にリアル・タイムで統合してアプリケーションの目的を果たせるかどうかは、疑わしいことがはっきりしている。レジストリ、ディレクトリ、および発見（discovery）プロトコルはサービス検出およびサービス間相互接続の論理を実装するための基盤構造を提供するが、現在の構成では、見つけ出されたどのサービスをサービス・リクエスタにバインドする際にも、ＱｏＳおよびＳＬＡの問題が顧慮されない。ＯＧＳＡ（OpenGrid Services Architecture）によるグリッド機構の生理機能（physiology）により、分散システムの全体にわたるＷｅｂサービスおよびｅユーティリティーズの発見においても、またバインド（binding）においてもプロトコルが提供されることは注目すべきである。
【０００６】
それでもなお、知られているグリッド機構には、異種のビジネス・アプリケーション・システムを横断する自動的で動的な協働および統合を支援できる技術が欠けている。むしろ、イアン・フォスター（Ian Foster）、カール・ケッセルマン（Carl Kesselman）、ジェフリー・エム・ニック（JeffreyM. Nick）およびスティーブン・テュッキ（StevenTuecke）、「グリッドの生理学（ThePhysiology of the Grid）」<http;//globus.org/research/papers/ogsa.pdf>（2002年2月17日）に述べられているように、Ｗｅｂサービスおよびｅユーティリティーズの協働および統合は、せいぜい手作業のプロセスとしか見ることができない。
【０００７】
現在のところ、様々なプロバイダおよび消費者がそれぞれ提供し消費する、同等であるが必ずしも同一ではないＷｅｂサービスおよびｅユーティリティーズの共用が限られていることは注目すべきである。しかも、あるＷｅｂサービスまたはｅユーティリティーズのパフォーマンスを利用するサービス指向のアプリケーションは、信頼できないＷｅｂサービスまたはｅユーティリティーズがリアル・タイムで制御および管理できない状況では、パフォーマンスがＳＬＡの条件に従って指定されている場合でさえ、好ましくないリスクにさらされる可能性がある。
【非特許文献１】イアン・フォスター（Ian Foster）、カール・ケッセルマン（CarlKesselman）、ジェフリー・エム・ニック（Jeffrey M. Nick）およびスティーブン・テュッキ（StevenTuecke）、「グリッドの生理学（ThePhysiologyof the Grid）」<http;//globus.org/research/papers/ogsa.pdf>（2002年2月17日）
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明は、上記問題を解決することをその課題とする。
【課題を解決するための手段】
【０００９】
第１の態様によれば、本発明は、複数のサービス・インスタンスと結合されるサービス・デスクであって、前記サービス・インスタンスが共通のサービス・インターフェースに適合する、サービス・デスクと、サービス・グリッド内に配置され、１つ１つのサービス要求を前記サービス・インスタンスの１つ１つにルーティングする、ルーティング・コンポーネントとを含む、コンピューティング・サービス・グリッドを提供する。
【００１０】
好ましくは、グリッドは、サービス・インスタンス監視コンポーネントと、前記サービス・インスタンス監視コンポーネントが前記選択されたサービス・インスタンスにおけるフェイル・オーバー状態を検出した状況で、選択されたサービス・インスタンスからのサービス要求をそれ以外の前記サービス・インスタンスにルーティングし直すように構成される、フェイル・オーバー論理とを含む。好ましい一実施形態では、前記フェイル・オーバー状態がエラー状態および保証されたパフォーマンスのレベルに追いつけないパフォーマンス不全状態の１つを含む。
【００１１】
好ましい一実施形態では、グリッドは、サービス要求を受け取るのに応答して前記サービス・インスタンスの１つ１つをインスタンス化するように構成されるサービス・インスタンス・ファクトリをさらに含む。好ましくは、グリッドは、前記サービス・デスクが選択サービスを用いて、前記サービス・インスタンスの１つ１つを見つけ出しバインドしてサービス要求に応答するためのグリッド・サービス・インターフェースをさらに含む。
【００１２】
第２の態様によれば、本発明は、上に述べたサービス・グリッドにおいて、サービス要求およびサービス品質（ＱｏＳ、quality of service）特性の指定を受け取るステップと、前記ＱｏＳ特性の指定と両立するレベルで前記サービス要求を処理できる同等ないくつかのサービス・インスタンスのうちの特定の１つを選択するステップと、前記選択されたサービス・インスタンスをバインドして前記サービス要求を処理するステップとを含む、サービス要求処理方法を提供する。
【００１３】
好ましくは、この方法は、前記バインドされたサービスのパフォーマンスを監視するステップと、前記パフォーマンスにおけるフェイル・オーバー状態を検出するステップと、フェイル・オーバー状態が検出された状況で、前記ＱｏＳ特性の指定と両立する前記レベルで前記サービス要求を処理できる前記同等ないくつかのサービス・インスタンスのうちの代わりとなる１つを選択し、前記代わりとなるサービス・インスタンスをバインドして前記サービス要求を処理するステップとを含む。好ましい一実施形態では、前記検出するステップが、前記選択されたサービスにおける例外を検出するステップを含む。好ましい他の一実施形態では、前記検出するステップが、前記選択されたサービスにおける前記ＱｏＳ特性の指定が達成できていないパフォーマンスのレベルを検出するステップを含む。
【００１４】
第３の態様によれば、本発明は、上に述べたサービス・グリッドにおいて、サービス要求を処理するコンピュータ・プログラムを保存した機械可読ストレージであって、前記コンピュータ・プログラムが、サービス要求およびサービス品質（ＱｏＳ）特性の指定を受け取るステップと、ＱｏＳ特性の指定と両立するレベルでサービス要求を処理できる、同等ないくつかのサービス・インスタンスのうちの特定の１つを選択するステップと、選択されたサービス・インスタンスをバインドしてサービス要求を処理するステップとを機械に実行させる定型化された（routine）１組の命令とを含む、機械可読ストレージを提供する。
【００１５】
本発明はコンピューティング・サービス・グリッドである。本発明のコンピューティング・サービス・グリッドは、Ｗｅｂサービスやｅユーティリティーズなどのコンピューティング・サービスを、自動的に編成しルーティングし回復し切り替えることができる。コンピューティング・サービス・グリッドは、共通サービス・エントリ・ポイントによって同等なコンピューティング・サービス・インスタンスの一群を代表することができる。続いて、コンピューティング・サービス・グリッドは、サービス要求の受け取りに応答して、コンピューティング・サービス・インスタンスのうちの適したものを選択して、受け取ったサービス要求を処理することができる。
【００１６】
コンピューティング・サービス・グリッドが、選択されたコンピューティング・サービス・インスタンスの可用性だけでなく機能にも従って、サービス要求を選択されたコンピューティング・サービス・インスタンスにルーティングして、そのサービスのリクエスタに関連付けられたＱｏＳ特性を満たすことができることは、注目すべきである。さらに、コンピューティング・サービス・グリッドは、選択されたコンピューティング・サービス・インスタンスのパフォーマンスを監視でき、必要な状況ではフェイル・オーバー処理を実行できる。したがって、コンピューティング・サービス・グリッドは、これまで、従来のＷｅｂサービスのバインド（binding）の状況では得られなかった高いレベルのコンピューティング・サービスの相互運用性を提供するために、異種のコンピューティング・サービスを動的にクラスタ化し処理することができる。
【００１７】
本発明の一態様によれば、コンピューティング・サービス・グリッドは、１つまたは複数のコンピューティング・サービス・インスタンスと結合されるサービス・デスクを含む。コンピューティング・サービス・インスタンスのそれぞれは、コンピューティング・サービス・グリッド内のすべてのコンピューティング・サービス・インスタンスに共通なサービス・インターフェースに適合することができる。コンピューティング・サービス・グリッドには、１つのルーティング・コンポーネントを配置することができる。特に、ルーティング・コンポーネントは、１つ１つのサービス要求をコンピューティング・サービス・インスタンスの１つ１つにルーティングすることができる。
【００１８】
コンピューティング・サービス・グリッドは、さらに、サービス・インスタンス監視コンポーネントを含む。監視コンポーネントは、１つ１つのサービス要求の処理を担当する１つ１つのコンピューティング・サービス・インスタンスのパフォーマンスを監視することができる。フェイル・オーバー論理は、サービス・インスタンス監視コンポーネントが選択されたサービス・インスタンスにおけるフェイル・オーバー状態を検出した状況で、選択されたサービス・インスタンスからのサービス要求をそれ以外のサービス・インスタンスにルーティングし直すように構成することができる。この点に関連して、フェイル・オーバー状態には、エラー状態、および選択されたコンピューティング・サービス・インスタンスのパフォーマンスが保証されたレベルのパフォーマンスに追いつけないパフォーマンス不全状態が含まれ得る。
【００１９】
サービス・グリッドでは、サービス要求処理方法は、サービス要求およびサービス品質特性の指定を受け取ることを含むことができる。ＱｏＳ特性の指定と両立するレベルでサービス要求を処理できる、同等ないくつかのサービス・インスタンスのうちの特定の１つを選択することができる。続いて、選択されたサービス・インスタンスをバインドしてサービス要求を処理することができる。バインド後は、選択されたサービスのパフォーマンスを監視することができる。特に、フェイル・オーバー状態を、選択されたサービスのパフォーマンスにおいて検出することができる。フェイル・オーバー状態が検出された状況では、ＱｏＳ特性の指定と両立するレベルでサービス要求を処理できる、同等ないくつかのサービス・インスタンスのうちの代わりとなる１つを選択することができる。続いて、代わりとなるサービス・インスタンスをバインドしてサービス要求を処理することができる。
【００２０】
次に本発明を、例としてのみ、以下の図面に示すその好ましい実施形態を参照して、説明することとする。
【発明を実施するための最良の形態】
【００２１】
本発明は、Ｗｅｂサービスやｅユーティリティーズなどの１組の同等なコンピューティング・サービスに１つの共通なサービスとしてアクセスするためのサービス・グリッドである。特に、サービス・グリッドは、共通サービス・エントリ・ポイントによって同等なコンピューティング・サービスの一群を代表するように設定（establish）することができる。サービス・グリッドは、サービス・リクエスタから受け取ったサービスに対する要求に応答して、それが代表する１つ１つのサービス・インスタンスをそのサービス要求に対応付けることができる。対応付けられたサービス・インスタンスは、ビジネス・サービス・グリッドによって呼び出し、サービス・リクエスタにバインドすることができ、このビジネス・サービス・グリッドはサービス・リクエスタとバインドされたサービス・インスタンスの間の代理人（proxy）として働く。
【００２２】
本発明によれば、サービス・グリッドは、同等なコンピューティング・サービスを、自動的に編成しルーティングし回復し切り替えることができる。特に、本発明のサービス・グリッドは、抽象化すれば同一または同等になるが、それぞれのサービスが実装、プロバイダ、ホストおよびネットワーク・ドメインの点で異なる可能性のある、Ｗｅｂサービスやｅユーティリティーズなどの分散コンピューティング・サービスをグループ化するのに使用することができる。さらに、サービス・グリッドは、仮想ｅＢｕｓｉｎｅｓｓサービス・コンプレックス内のサービス・デスクを通じてサービスをブローカとして取り仕切る（broker）目的で、コンピューティング・サービスをグループ化することができる。
【００２３】
確立されたＳＬＡに指定された保証されるサービス・レベルに従って信頼性確保を行うだけでなく、障害を起こしている同等なサービス・インスタンスに対して障害検出および自己回復を実行するために、サービス・グリッド内にフェイル・オーバー論理を含めることができることは、重要である。その場合、サービス・グリッドは、すでにバインドされているものの、利用可能でない、パフォーマンスが満足でない、または完全な障害が生じたという理由で、もはやサービス・リクエスタにサービスを提供できないサービス・インスタンスを、同等なサービス・インスタンスで透過的に置き換えることができる。このようにして、サービス・グリッドは、万一例外が発生した場合には、代わりとなる同等なサービスへのフェイル・ソフト処理を実行することができる。
【００２４】
図１は、本発明の好ましい態様に従って構成されるサービス・グリッドの構成図である。サービス・グリッドは、サービス・デスク１００を含むことができる。サービス・デスク１００は、共通エントリ・ポイント１１０と１組の操作１２０をともに含むことができる。特に、共通エントリ・ポイント１１０は、ＷＳＤＬ（Web Services Definition Language、Ｗｅｂサービス定義言語）などの形式定義言語を用いて１つ１つのサービス抽象化から集約した抽象的サービスを定義することができる。この点に関連して、共通エントリ・ポイントは、サービス・デスク１００、利用可能な１組の操作１２０、１つまたは複数の有効なメッセージ・フォーマット、および１つまたは複数の有効なトランスポート・バインディング（transportbinding）に対する１つのＵＲＩ（uniform resource identifier、統一資源識別子）を指定することができる。
【００２５】
操作１２０は、１つまたは複数のサービス・インスタンス１５０を登録項目に追加または削除するなどの保守型の操作、参照照会（referral inquiry）、およびＳＬＡの条件またはＳＬＡ全体を設定または変更する操作を含むことができる。操作１２０はさらに、自由選択で、サービス要求をサービス・インスタンス１５０に提出する、サービス・インスタンス１５０からサービス要求に対する応答を取り出す、またサービス・インスタンス１５０のステータスを検査する操作を含むことができる。最後に、操作１２０は、イベント公開（eventpublishing）の操作も回復規則および例外ハンドラを設定する操作も含むことができる。要するに、共通エントリ・ポイント１１０は、サービス・グリッドの唯一の外部参照コンポーネントとして役立つことが可能である。
【００２６】
サービス・グリッド自体は、自由選択でＯＧＳＡに従って実装することができ、プライベートＵＤＤＩなどのプライベート・レジストリに由来するデータを項目とする、１つまたは複数の内部テーブル１３０を含むことができる。テーブル１３０は、サービス・グリッドに含まれる各サービス・インスタンス１５０ごとに、ハンドル、検索キー、および参照情報への対応するポインタを保持することが可能である。参照情報自体は、たとえば、ＷＳＤＬ、ＱｏＳマトリックス、補助ＱｏＳマトリックス、ステータスおよび例外記述子などの記述マーク・アップを含むことができる。いずれにせよ、テーブル１３０は、サービス・グリッドの操作をサポート可能なデータ構造を提供することができる。操作の点では、サービス・インスタンス１５０は、項目追加操作（add listing operation）を選択することによってサービス・グリッドに追加することができる。逆に、サービス・インスタンス１５０は、項目削除操作（removelisting operation）を選択することによってこのグリッドから削除することができる。サービス・インスタンス１５０をサービス・グリッドに追加する前に、サービス・デスク１００は、サービス・インスタンス１５０の信頼性を確認することができ、内部テーブル１３０に補助ＱｏＳマトリックスを追加することができる。さらに、同等なもののない（disparate）サービス・インスタンス１５０は、グリッドと非グリッドの両方のサービス・インスタンス１５０に対するこのサービス・グリッドの相互運用性を支障のないものとするために、統一グリッド・サービス・ラッパー（uniformgrid service wrapper）１６０の内部にカプセル化することができる。
【００２７】
サービス・インスタンス１５０は、操作可能になると、単にこのサービス・インスタンス１５０に対するステータス記述子を変更するだけで、修復またはアップグレードが可能になる。サービス・グリッド内のサービス要求を受け取ると、サービス・デスク１００は、グリッド・ルーティング・コンポーネント１４０を呼び出して、内部テーブルにリストされている適当なサービス・インスタンス１５０を識別する。具体的には、リアル・タイムのまたは予め選択されたＳＬＡレベル指定に基づいて、グリッド・ルーティング・コンポーネント１４０は適当なサービス・インスタンス１５０を選択して、関連付けられたＳＬＡの条件の要求する顧客対応および信頼性に従ってサービス要求を満たすことができる。サービス・インスタンス１５０があるトランザクションにバインドされると、サービス・インスタンス１５０の健康状態（the state of health）をグリッド・ルーティング・コンポーネント１４０が監視することができ、必要な場合には、操作１２０に一部として含まれる例外の処理および回復によってフェイル・オーバーを実行することができる。
【００２８】
図２は、図１のサービス・グリッドにおけるサービス・インスタンスをバインドするプロセスを示すタイミング図である。ステップ１で、サービス・リクエスタは、サービス・グリッドの共通サービス・エントリ・ポイントにサービス要求を転送することができる。たとえば、サービス要求は、サービス呼び出しメッセージを含むＳＯＡＰエンベロープにカプセル化することができる。ステップ２で、共通サービス・エントリ・ポイントは、ＯＧＳＡなどのサービス・グリッドに対するインターフェースを通して、適当な操作を呼び出すことができる。特に、共通サービス・エントリ・ポイントは、実際のサービス・インスタンスを開始する操作を呼び出すことが可能である。具体的には、要求されるＱｏＳ特性がグリッド・サービス・インターフェースに提供され、これにより、グリッド・サービス・インターフェースは、要求されるＱｏＳレベルを満たしながら、サービス要求に応答できる特定のサービス・インスタンスを選択するサービスを呼び出すことができるようになる。
【００２９】
ステップ３で、グリッド・サービス・インターフェースの発見サービスが内部テーブルを検索して、ファクトリ・サービスを見つけ出して、要求されたサービスのインスタンスを作成する。ファクトリ・サービスが見つかると、そのファクトリによってサービス・インスタンスを作成することができ、作成されたサービス・インスタンスへのハンドルを共通サービス・エントリ・ポイントに返すことができる。ステップ４で、共通サービス・エントリ・ポイントが、グリッド・サービス・インターフェースが共通サービス・エントリ・ポイントに提供したハンドルを用いて、作成されたサービス・インスタンスにサービス要求を転送することができる。サービス要求を作成されたサービス・インスタンスが受け取ると、作成されたサービス・インスタンスは、そのサービス要求を処理することができ、共通サービス・エントリ・ポイントに応答を返すことができる。最後に、ステップ５で、共通サービス・エントリ・ポイントはその応答をサービス・リクエスタに転送することができる。
【００３０】
コンピューティング・サービスをバインドしてサービス要求に応答する従来のプロセスとは異なり、本発明では、サービス・グリッドが、特定のサービス・インスタンスの顧客応答および信頼性、ならびにサービス・リクエスタに関連付けられたＳＬＡおよびＱｏＳの条件の要求する顧客応答および信頼性のレベルに従って、自動的に特定のサービス・インスタンスをバインドしてサービス要求に応答することができることは、重要である。この点に関連して、図３は、図１のサービス・グリッドにおける、同等なサービス・インスタンスをサービス要求に対応付けるプロセスを示す流れ図である。始めのブロック３００では、サービス要求をサービス・リクエスタから受け取ることができる。ブロック３１０で、このリクエスタに対してＳＬＡまたはＳＬＡ条件を識別することができる。ＳＬＡまたはＳＬＡ条件により、そのサービス・リクエスタに対して保証される顧客対応および信頼性の最小のレベルを指定することが可能である。
【００３１】
ブロック３２０で、識別されたＳＬＡまたはＳＬＡ条件および要求されたサービスに基づいて、サービス・グリッドは内部テーブルを調べて、サービス要求に応答できる同等なサービス・インスタンスの集合のうちからサービス・インスタンスを１つ選択することができる。判断ブロック３３０で、選択されたサービス・インスタンスのステータスを検査して、選択されたサービス・インスタンスが利用可能かどうか（availability）を判定することができる。選択されたサービス・インスタンスが利用可能でない場合、ブロック３４０で、ＳＬＡまたはＳＬＡ条件およびサービス要求を満たすことのできる次善のサービス・インスタンスを選択することができ、プロセスは繰り返すことが可能である。そうでない場合、プロセスはブロック３５０に続く。
【００３２】
ブロック３５０で、選択されたサービス・インスタンスを、サービス要求に応答するようにバインドすることができる。続いて、ブロック３６０で、サービス要求が、バインドされたサービス・インスタンスに転送される。ブロック３７０で、バインドされたサービス・インスタンスから応答を受け取ったかどうかが判定される。そうでない場合、プロセスはバインドされたサービス・インスタンスからのサービス要求に対する応答を待つことができる。応答を受け取っている場合は、ブロック３８０で、受け取った応答をサービス・リクエスタに転送することができる。バインドされたサービス・インスタンスの顧客対応および信頼性を、本発明のサービス・グリッドのパフォーマンス監視およびフェイル・オーバーのコンポーネントによって保証できることは、重要である。
【００３３】
この点に関連して、図４は、図１のサービス・グリッドにおける、サービス・インスタンスのフェイル・オーバーを実行するフェイル・ソフト・プロセスを示す流れ図である。始めのブロック４００で、バインドされたサービス・インスタンスと共通サービス・エントリ・ポイントの間の要求−応答セッションの進行を、パフォーマンスおよび信頼性に関して監視することが可能である。判断ブロック４１０で、バインドされたサービス・インスタンスをフェイル・オーバーに関してテストすることができる。特に、極端な場合として、バインドされたサービス・インスタンスがセッションを完了できないようなエラーがそのバインドされたサービス・インスタンス内で起きているかどうかを判定することができる。あるいは、セッションの品質を、ＱｏＳ条件またはＳＬＡの条件の保証する品質のレベルと比較することもできる。
【００３４】
セッションの品質が保証される品質のレベルを適切に満たすと判定された場合、ブロック４２０で、セッションが終了しているかどうかを判定することができる。そうである場合、ブロック４７０で、セッションは終了することができる。そうでない場合、セッションは続行することができ、ブロック４００でセッションの品質を続けて監視することができる。しかし、ブロック４１０で、セッションの品質が、そのセッションに対して保証される品質のレベルを達成していない場合、ブロック４３０で、サービス・グリッドの内部テーブルを調べて、保証される品質のレベルを満たすように構成されている次善のサービス・インスタンスを識別することができる。判断ブロック４４０で、識別されたサービス・インスタンスが利用可能でない場合、ブロック４３０でプロセスを繰り返すことができる。そうでない場合、ブロック４５０で次善のサービス・インスタンスを、サービス要求を満たすようにバインドすることができ、ブロック４６０で、サービス要求を新しくバインドされたサービス・インスタンスに転送することができる。
【００３５】
本発明によれば、サービス・グリッドは、Ｗｅｂサービスやｅユーティリティーズなどのコンピューティング・サービスを自動的に編成しルーティングし回復し切り替えることができる。特に、サービス・グリッドは、共通サービス・エントリ・ポイントを通して同等な一群のサービスを表すように設定することができる。続いて、そのサービス・グリッドは、入ってくるサービス要求の１つ１つを取り扱うために、サービス・インスタンスを自動的にバインドすることができる。さらに、そのサービス・グリッドは、例外またはパフォーマンス不全が検出された状況で、代わりとなる同等なサービス・インスタンスへのフェイル・オーバー処理を実行することができる。
【００３６】
ダイナミックなｅビジネスでは、Ｗｅｂサービスやｅユーティリティーズなど、出来合いで（ready-made）、すぐに使えて（off-the-shelf）、アトミックな、しかし異種の、多くのコンピューティング・サービスをリアル・タイムで共用し統合することが必要となる。従来のシステムでは、サービスを手作業でバインドすることが必要であり、サービス要求をコンピューティング・サービスに原始的なやり方でしかルーティングできなかった。本発明では、ＱｏＳ条件および既存のＳＬＡの条件の命じる最小のパフォーマンスおよび信頼性のレベルが保証されるように、従来のシステムの欠点が、条件プログラミング論理に従ってサービスを自動的にバインドおよびルーティングすることによって克服される。
【００３７】
本発明は、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせで実現可能である。本発明の方法およびシステムの実装は、１つのコンピュータ・システムにおいて集中方式で、または、いくつかの相互接続されたコンピュータ・システムにわたって異なる要素が広がる分散方式で実現可能である。どのような種類のコンピュータ・システム、または本明細書に記載された方法を実施するように適合された他の機器も、本明細書に記載された機能を実行するのに適している。
【００３８】
ハードウェアとソフトウェアの典型的な組み合わせは、ロードされ実行されると、本明細書に記載された方法を実行するようにコンピュータ・システムを制御する、コンピュータ・プログラムを有する汎用コンピュータ・システムとすることができる。本発明は、また、コンピュータ・プログラム製品に組み込むことができ、これは本明細書に記載された方法の実装を可能とするすべての特徴を含み、コンピュータ・システムにロードされると、これらの方法を実行することが可能である。
【００３９】
この文脈におけるコンピュータ・プログラムまたはアプリケーションとは、直接に、あるいは以下の一方または両方の後で、情報処理機能を有するシステムに特定の機能を実行させるための１組の命令の、任意の言語、コードまたは記法による任意の表現を意味する：ａ）他の言語、コードまたは記法への変換、ｂ）異なる素材形式による複製。本発明が、その本質的属性を逸脱することなく、他の特定の形式に組み込むことが可能であることは、非常に重要であり、したがって、本発明の範囲を知るには、上記の明細書よりもむしろ、以下の特許請求の範囲を参照されたい。
【図面の簡単な説明】
【００４０】
【図１】サービス・グリッドの構成図である。
【図２】図１のサービス・グリッドにおける、サービス・インスタンスをバインドするプロセスを示すタイミング図である。
【図３】図１のサービス・グリッドにおける、同等なサービス・インスタンスをサービス要求に対応付けるプロセスを示す流れ図である。
【図４】図１のサービス・グリッドにおける、サービス・インスタンスのフェイル・オーバーを実行するフェイル・ソフト・プロセスを示す流れ図である。
【図１】
2005535949.tif 000003
【図２】
2005535949.tif 000004
【図３】
2005535949.tif 000005
【図４】
2005535949.tif 000006
【手続補正書】
【提出日】平成16年5月22日(2004.5.22)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】０００９
【補正方法】変更
【補正の内容】
【０００９】
第１の態様によれば、本発明は、複数のサービス・インスタンスと結合されるサービス・デスクであって、前記サービス・インスタンスが共通のサービス・インターフェースに適合する、サービス・デスクと、サービス・グリッド内に配置され、１つ１つのサービス要求を前記サービス・インスタンスの１つ１つにルーティングする、ルーティング・コンポーネントと、サービス・インスタンス監視コンポーネントと、前記サービス・インスタンス監視コンポーネントが前記選択されたサービス・インスタンスにおけるフェイル・オーバー状態を検出した状況で、選択されたサービス・インスタンスからのサービス要求をそれ以外の前記サービス・インスタンスにルーティングし直すように構成される、フェイル・オーバー論理とを含む、コンピューティング・サービス・グリッドを提供する。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】変更
【補正の内容】
【００１０】
好ましい一実施形態では、前記フェイル・オーバー状態がエラー状態および保証されたパフォーマンスのレベルに追いつけないパフォーマンス不全状態の１つを含む。
【手続補正書】
【提出日】平成16年8月17日(2004.8.17)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
共通のサービス・インターフェースに適合する複数のサービス・インスタンスと結合されるサービス・デスクと、
サービス・グリッド内に配置され、１つ１つのサービス要求を前記サービス・インスタンスの１つ１つにルーティングする、ルーティング・コンポーネントと、
サービス・インスタンス監視コンポーネントと、
前記サービス・インスタンス監視コンポーネントが前記選択されたサービス・インスタンスにおけるフェイル・オーバー状態を検出した場合に、前記サービス要求を処理するために前記それ以外の前記サービス・インスタンスをバインドすることによって、選択されたサービス・インスタンスからのサービス要求をそれ以外の前記サービス・インスタンスにルーティングし直すように構成されるフェイル・オーバー論理と
を含む、コンピューティング・サービス・グリッド。
【請求項２】
前記フェイル・オーバー状態がエラー状態および保証されたパフォーマンスのレベルが達成できていないパフォーマンス不全状態の１つを含む、請求項１に記載のコンピューティング・サービス・グリッド。
【請求項３】
サービス要求を受け取るのに応答して前記サービス・インスタンスの１つ１つをインスタンス化するように構成されるサービス・インスタンス・ファクトリをさらに含む、請求項１または請求項２に記載のコンピューティング・サービス・グリッド。
【請求項４】
前記サービス・デスクが選択サービスを用いて、前記サービス・インスタンスの１つ１つを見つけ出しバインドしてサービス要求に応答するためのグリッド・サービス・インターフェースをさらに含む、請求項１ないし３のいずれか一項に記載のコンピューティング・サービス・グリッド。
【請求項５】
請求項１ないし４のいずれかに記載のサービス・グリッドにおいて、
サービス要求およびサービス品質（ＱｏＳ、quality of service）特性の指定を受け取るステップと、
前記ＱｏＳ特性の指定と両立するレベルで前記サービス要求を処理できる同等ないくつかのサービス・インスタンスのうちの特定の１つを選択するステップと、
前記選択されたサービス・インスタンスをバインドして前記サービス要求を処理するステップと
を含む、サービス要求処理方法。
【請求項６】
前記バインドされたサービスのパフォーマンスを監視するステップと、
前記パフォーマンスにおけるフェイル・オーバー状態を検出するステップと、
フェイル・オーバー状態が検出された状況で、前記ＱｏＳ特性の指定と両立する前記レベルで前記サービス要求を処理できる前記同等ないくつかのサービス・インスタンスのうちの代わりとなる１つを選択し、前記代わりとなるサービス・インスタンスをバインドして前記サービス要求を処理するステップと
を含む、請求項５に記載の方法。
【請求項７】
前記検出するステップが、前記選択されたサービスにおける例外を検出するステップを含む、請求項６に記載の方法。
【請求項８】
前記検出するステップが、前記選択されたサービスにおける前記ＱｏＳ特性の指定が達成できていないパフォーマンスのレベルを検出するステップを含む、請求項６に記載の方法。
【請求項９】
請求項１ないし４のいずれかに記載のサービス・グリッドにおいて、サービス要求を処理するためのコンピュータ・プログラムを記憶した機械可読ストレージであって、前記コンピュータ・プログラムが、
サービス要求およびサービス品質（ＱｏＳ）特性の指定を受け取るステップと、
ＱｏＳ特性の指定と両立するレベルでサービス要求を処理できる、同等ないくつかのサービス・インスタンスのうちの特定の１つを選択するステップと、
選択されたサービス・インスタンスをバインドしてサービス要求を処理するステップとを機械に実行させる、定型化された（routine）１組の命令を含む、機械可読ストレージ。
【国際調査報告】
2005535949.tif 000007
2005535949.tif 000008
2005535949.tif 000009