(57)【要約】      （修正有）【課題】ウェブサービス集合体におけるＱｏＳ指向のプランニングのデータ処理システム用の方法の提供。【解決手段】システムは、レジストリにあるアクセス可能なウェブサービスを識別し、コンピュータ通信ネットワークで通信結合されたクライアントから受け取る要求に応答して、呼び出しのためにウェブサービスの集合体を配列するように構成されるウェブサービス集約調整ロジックを含む。ウェブサービス集約調整ロジックに結合されるＱｏＳプランニングロジックを含む。ＱｏＳプランニングロジックは、ウェブサービスの集合体内のウェブサービスの個々のパフォーマンスと、ウェブサービスの集合体の累積パフォーマンスの両方を計測できる。ＱｏＳプランニングロジックは、ウェブサービスの集合体内のウェブサービスの個々のパフォーマンスと、ウェブサービスの集合体の累積パフォーマンスの両方の計測に応答して、ウェブサービスの集合体を修正できる。【選択図】図１
2007095078.tif 000002
【特許請求の範囲】
【請求項１】
ウェブサービス集合体におけるサービス品質指向のプランニングのコンピュータ実装方法が、
ウェブサービスの集合体内のウェブサービスの個々のパフォーマンスと、ウェブサービスの集合体の累積のパフォーマンスとの両方を計測するステップと、
ウェブサービスの集合体内のウェブサービスの個々のパフォーマンスと、ウェブサービスの集合体の累積のパフォーマンスとの両方の計測に応答して、ウェブサービスの集合体を修正するステップとを有する方法。
【請求項２】
ウェブサービスの集合体内のウェブサービスの個々のパフォーマンスと、ウェブサービスの集合体の累積のパフォーマンスの両方を計測するステップが、
ウェブサービスの集合体に関しパフォーマンス目標を取得するステップと、
ウェブサービスの集合体の累積したパフォーマンスと取得したパフォーマンス目標とを比較して、ウェブサービスの集合体を修正するかどうかを判別するステップとを有する請求項１に記載の方法。
【請求項３】
ウェブサービスの集合体を修正するステップが、ウェブサービスの集合体内のウェブサービスの呼び出しの順序を、集合体内のウェブサービスの１つに関し計測したパフォーマンス不足を収容するように変更するステップを有する請求項１に記載の方法。
【請求項４】
ウェブサービスの集合体を修正するステップが、ウェブサービスの集合体内のウェブサービスの呼び出しの順序を、集合体に関し計測した累積超過パフォーマンスを利用するように変更するステップを有する請求項１に記載の方法。
【請求項５】
ウェブサービスの集合体を修正するステップが、
ウェブサービスの集合体内のウェブサービスの呼び出しの順序を、集合体内のウェブサービスの１つに関し計測したパフォーマンス不足を収容するように第１変更するステップと、
ウェブサービスの集合体内のウェブサービスの呼び出しの順序を、集合体に関し計測した累積のパフォーマンス不足を収容するように第２変更するステップとを有する請求項１に記載の方法。
【請求項６】
ウェブサービス集合体におけるサービス品質指向のプランニングのデータ処理システムが、
レジストリにあるアクセス可能なウェブサービスを識別し、コンピュータ通信ネットワークで通信結合されたクライアントから受け取る要求に応答して呼び出すためにウェブサービスの集合体を配列するように構成されたウェブサービス集約調整ロジックと、
ウェブサービス集約調整ロジックに結合され、ウェブサービスの集合体内のウェブサービスの個々のパフォーマンスと、ウェブサービスの集合体の累積のパフォーマンスとの両方を計測し、ウェブサービスの集合体内のウェブサービスの個々のパフォーマンスと、ウェブサービスの集合体の累積のパフォーマンスとの両方の計測に応答してウェブサービスの集合体を修正できるようになされたＱｏＳプランニングロジックとを有するデータ処理システム。
【請求項７】
実行されることでコンピュータをウェブサービス集合体におけるサービス品質指向のプランニング用コンピュータとして機能させるコンピュータプログラムであり、
当該コンピュータに
ウェブサービスの集合体内のウェブサービスの個々のパフォーマンスと、ウェブサービスの集合体の累積のパフォーマンスとの両方を計測させる機能と、
ウェブサービスの集合体内のウェブサービスの個々のパフォーマンスと、ウェブサービスの集合体の累積のパフォーマンスとの両方の計測に応答して、ウェブサービスの集合体を修正させる機能と
を実現させるコンピュータプログラム。
【請求項８】
ウェブサービスの集合体内のウェブサービスの個々のパフォーマンスと、ウェブサービスの集合体の累積のパフォーマンスの両方を計測させる機能が、
ウェブサービスの集合体に関するパフォーマンス目標を取得させる機能と、
ウェブサービスの集合体の累積したパフォーマンスを取得したパフォーマンス目標と比較して、ウェブサービスの集合体を修正するかどうかを判別させる機能とを有する請求項７に記載のコンピュータプログラム。
【請求項９】
ウェブサービスの集合体を修正させる機能が、ウェブサービスの集合体内のウェブサービスの呼び出しの順序を、集合体内のウェブサービスの１つに関し計測したパフォーマンス不足を収容するように変更させる機能を有する請求項７に記載のコンピュータプログラム。
【請求項１０】
ウェブサービスの集合体を修正させる機能が、ウェブサービスの集合体内のウェブサービスの呼び出しの順序を、集合体に関し計測した累積超過パフォーマンスを利用するように変更させる機能を有する請求項７に記載のコンピュータプログラム。
【請求項１１】
ウェブサービスの集合体を修正させる機能が、
ウェブサービスの集合体内のウェブサービスの呼び出しの順序を、集合体内のウェブサービスの１つに関し計測したパフォーマンス不足を収容するように第１変更させる機能と、
ウェブサービスの集合体内のウェブサービスの呼び出しの順序を、集合体に関し計測した累積のパフォーマンス不足を収容するように第２変更させる機能とを有する請求項７に記載のコンピュータプログラム。
【請求項１２】
通信手段と記憶手段と制御手段とを備えるコンピュータに適用される方法であり、
当該コンピュータは当該通信手段を介してネットワークに接続され、当該ネットワークに接続される単一又は複数のクライアント、複数のウェブサービスサーバ、当該ウェブサービスサーバに対応するウェブサービスレジストリサーバとそれぞれ通信可能であり、
当該コンピュータは当該記憶手段に、集約サービス要求を満足する一組のウェブサービス群を組み合わせる集約調整ロジックと、当該集約サービス要求のパフォーマンスの目標値を表すパフォーマンスポリシーと、当該一組のウェブサービス群の組み合わせ配列を修正する必要があるか否かの判断基準とを記憶し、
当該方法は当該制御手段により、
当該通信手段を介して当該クライアントから集約サービス要求を受信することに応答して、当該集約ロジックに基づいて当該集約サービス要求を満足する一組のウェブサービス群を組み合わせるステップと、
当該ウェブサービス群を構成する個々のウェブサービスのパフォーマンスと、当該ウェブサービス群の累積のパフォーマンスとの両方を計測するステップと、
ウェブサービス群を構成する個々のウェブサービスのパフォーマンスと、ウェブサービス群の累積のパフォーマンスとの両方の計測結果に応答して、ウェブサービス群を修正するステップと
を有する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は分散型コンピューティング、より具体的にはウェブサービスの分野に関係する。
【背景技術】
【０００２】
ウェブサービスは分散型コンピューティングの最先端を表し、ワールド・ワイド・ウェブでコンポーネントベースのアプリケーションの急速な開発を支える真に普遍的なモデルの開発の礎と考えられている。サービス指向、コンポーネントベースのアプリケーションアーキテクチャを記述する多数の新興規格を含むウェブサービスが技術上周知である。具体的には、ウェブサービスは個別機能を意味上カプセル化する緩やかに連結された、再使用可能なソフトウェアコンポーネントであり、標準のインターネットプロトコルに分散され、プログラムに基づいてアクセスすることができる。
【０００３】
概念的には、ウェブサービスはプロセス内の個別タスクをバリューネット全体に幅広く分散するモデルを意味する。注目すべきことに、業界の専門家の多くがサービス指向のウェブサービス構想をインターネットの次の進化の段階だと考えている。典型的には、ウェブサービスはウェブサービス定義言語（ＷＳＤＬ）などのインターフェースで定義でき、そのインターフェースに従って実装できる。ただし、実装がウェブサービスインターフェースに準拠している限り実装の詳細は大した問題ではない。ウェブサービスが対応するインターフェースに従って実装されたら、実装は技術上よく知られるユニバーサル・ディスクリプション・ディスカバー・アンド・インテグレーション（ＵＤＤＩ）などのウェブサービスレジストリに登録できる。登録に際し、ウェブサービスは、例えば、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）などの何らかのサポート用メッセージ交換プロトコルを使ってサービス要求者からアクセスできる。
【０００４】
一般的に、分散型環境では、ウェブサービスプロセスの大部分は無差別に要求を出す。すなわち、エンドユーザとは関係なく、各要求を同じ優先順位で処理する傾向がある。しかし、インターネットでのウェブサービスの要求が急増していることから、一部のウェブサービスは「ポリシーベースサービス差別化モデル」と呼ばれる基準に基づいて様々に異なる応答性レベルを提供する。ポリシーベースサービス差別化モデルでは、ウェブサービスは管理者が定義したポリシーに依存して、応答性とパフォーマンスのレベルを数多く提供する。その点に関して、サービスレベル契約（ＳＬＡ）でのサービス品質（ＱｏＳ）条件が、特定の要求者に最低限義務を負う応答性のレベルを規定する。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ウェブサービスが斬新な技術コンセプトから、分散したロジックを宣伝およびアクセスするための一般に認められた方法になるにつれ、アプリケーションの構築者や開発者はアプリケーションをウェブサービスの集合体として制作し始めるようになった。今のところ、ウェブサービスは各個々の機能に対してサービス品質（ＱｏＳ）保証を約束しているが、あるアプリケーションでウェブサービスを使う場合のアプリケーションＱｏＳ全体の問題は適用範囲外になっている
【課題を解決するための手段】
【０００６】
本発明の実施例はウェブサービス集合体に関し技術上の欠陥を解決し、ウェブサービス集合体におけるＱｏＳ指向のプランニングの新規で非自明の方法、システム、およびコンピュータプログラム製品を提供する。ある実施例では、ウェブサービス集合体のＱｏＳ指向のプランニングのコンピュータ実装方法は、ウェブサービスの集合体内のウェブサービスの個々のパフォーマンスと、ウェブサービスの集合体の累積のパフォーマンスの両方を計測するステップを含むことができる。方法はさらに、ウェブサービスの集合体内のウェブサービスの個々のパフォーマンスと、ウェブサービスの集合体の累積のパフォーマンスの両方の計測に応答して、ウェブサービスの集合体を修正するステップを含むことができる。
【０００７】
ウェブサービスの集合体内のウェブサービスの個々のパフォーマンスと、ウェブサービスの集合体の累積のパフォーマンスの両方を計測するステップは、ウェブサービスの集合体のパフォーマンス目標を取得するステップと、ウェブサービスの集合体の累積したパフォーマンスと取得したパフォーマンス目標とを比較して、ウェブサービスの集合体を修正するかどうかを判別するステップを含むことができる。実施例のある側面では、ウェブサービスの集合体の修正は、ウェブサービスの集合体におけるウェブサービスの呼び出しの順序を変えて、集合体内のウェブサービスの１つに関し計測したパフォーマンスの不足を収容するステップを含むことができる。実施例の別の側面では、ウェブサービスの集合体の修正は、ウェブサービスの集合体内のウェブサービスの呼び出し順序を変えて、計測した集合体の累積超過パフォーマンスを利用するステップを含むことができる。
【０００８】
発明の別の実施例では、ウェブサービス集合体におけるＱｏＳ指向のプランニングのデータ処理システムが、レジストリにあるアクセス可能なウェブサービスを識別し、コンピュータ通信ネットワークで通信接続されたクライアントから受け取る要求に応答して呼び出し用のウェブサービスの集合体を配列するよう構成されるウェブサービス集約調整ロジックを含むことができる。システムはさらに、ウェブサービス集約調整ロジックに結合されたＱｏＳプランニングロジックを含むことができる。ＱｏＳプランニングロジックは、ウェブサービスの集合体内のウェブサービスの個々のパフォーマンスと、ウェブサービスの集合体の累積のパフォーマンスの両方を計測できるようになされる。最終的に、ＱｏＳプランニングロジックは、ウェブサービスの集合体内のウェブサービスの個々のパフォーマンスと、ウェブサービスの集合体の累積のパフォーマンスの両方を計測したことに応答して、ウェブサービスの集合体を修正できるようになされる。
【０００９】
発明の追加の側面は以下の説明に一部記載し、また一部は説明から明らかになり、又は発明の実施により知ることができるであろう。発明の様々な側面は、添付の請求項に具体的に指摘する要素および組合せによって実施され、達成されるであろう。前述の一般的な説明と以下の詳細な説明はともに単なる例示と説明のためのものであり、請求される本発明を制限するものではないことは理解されるべきである。
【発明を実施するための最良の形態】
【００１０】
本発明の実施例は、ウェブサービス集合体におけるＱｏＳ指向のプランニングの方法、システム、およびコンピュータプログラム製品を提供する。本発明の実施例に従い、集合体が実行時環境でアクティブにアクセス可能なウェブサービスであるか、又は開発環境で将来アクセス可能なウェブサービスであるかに関係なく、ウェブサービスの集合体に関してパフォーマンスの目標を識別できる。その後、集合体内の個々のウェブサービスのパフォーマンスを計測して、識別したパフォーマンスの目標と比較できる。その結果、その集合体に関して識別したパフォーマンスの目標を満たすように、集合体内の個々のウェブサービスの選択を調整できる。
【００１１】
具体的な例として、図１はウェブサービス集合体におけるＱｏＳ指向のプランニングのために構成されたデータ処理システムの概略図である。図１に示すように、データ処理システムは、コンピュータ通信ネットワーク１２０で一又は複数のクライアントコンピューティングデバイス１１０に結合するように構成されるサーバコンピューティングデバイス１３０を含むことができる。サーバコンピューティングデバイス１３０はさらに、コンピュータ通信ネットワーク１２０でレジストリ１５０に問い合わせて一又は複数のウェブサービス１４０にアクセスするように構成できる。
【００１２】
注目すべきことに、サーバコンピューティングデバイス１３０はウェブサービス集約調整ロジック１６０を含むことができる。ウェブサービス集約調整ロジック１６０は、集合体内の１組のウェブサービス１４０をアセンブルして、コンピュータ通信ネットワーク１２０でクライアントコンピューティングデバイス１１０から受け取る集約コンピューティングサービスの要求を満たすようになされたプログラムコードを含むことができる。ウェブサービス集約調整ロジックは技術上よく知られており、ダイナミックウェブサービス集約統合と言われることも多い。
【００１３】
本発明に従い、ＱｏＳプランニングロジック２００は、ウェブサービス集約調整ロジック１６０に結合できる。ＱｏＳプランニングロジック２００は、パフォーマンスポリシー１８０が規定するパフォーマンスの目標を満たすために、集合体内のウェブサービス１４０の配列を修正できるようになされたプログラムコードを含むことができる。この点に関し、ＱｏＳプランニングロジック２００のプログラムコードは、集合体内のウェブサービス１４０に関するパフォーマンスメトリック１７０を計測し捕捉できるようになされる。パフォーマンスメトリック１７０はパフォーマンスポリシー１８０の一又は複数のパフォーマンスの目標と比較して、集合体内のウェブサービス１４０の配列を修正する必要があるかどうかを判別する。
【００１４】
さらに具体的な例として、図２はウェブサービス集合体におけるＱｏＳ指向のプランニングの方法を図示するフローチャートである。図２に示すように、ブロック２１０で、ウェブサービスのある集合体を含意する、入ってくるサービス要求を受け取ることができる。ブロック２２０で、ウェブサービスの集合体のパフォーマンス目標を取得できる。また、ブロック２３０で、集合体に含まれる個々のウェブサービスをサービス要求から推定できる。この点に関し、集約したときサービス要求を満たすことのできるように十分に選択したアクセス可能なウェブサービスを識別できる。
【００１５】
ブロック２４０で、推定したウェブサービスをパフォーマンス目標に従って順序付けできる。具体的には、集合体内の推定したウェブサービスの各々について予想される応答性を判別でき、呼出すとウェブサービスの応答性の逐次モニタリングができるように、ウェブサービスを順序付けできる。ウェブサービスの応答性の逐次モニタリングは、ウェブサービスの呼び出しの順序を、予期しないパフォーマンスの不足を満たすように、又は集合体のパフォーマンスが期待を超える場合に調整する能力を提供できる。
【００１６】
この点に関し、ブロック２５０で、順序の第１ウェブサービスを呼び出して、ブロック２６０で、呼び出したウェブサービスのパフォーマンスを計測できる。判断ブロック２７０で、呼び出したウェブサービスのパフォーマンスが満足いくものかどうかを判別できる。満足いかなければ、ブロック２８０でウェブサービスの順序付けを調整して、呼び出したウェブサービスのパフォーマンスの不足を明細に報告でき、ブロック２９０で、新たな順序付けの第１ウェブサービスを呼び出せる。その後、新たに呼び出したウェブサービスについてブロック２６０から２７０のプロセスを繰り返すことができる。そうでなければ、プロセスは判断ブロック３００に進める。
【００１７】
判断ブロック３００で、ウェブサービスの集合体がパフォーマンス目標に対して期待を累積で上回っているかどうかを判別できる。上回っていなければ、順序の次のウェブサービスを呼び出せる。しかし、ウェブサービスの集合体がパフォーマンス目標に対して期待を累積で上回っていれば、呼び出したウェブサービスのパフォーマンスが満足いくものかどうかを判別する。満足いくものでなければ、ブロック２８０でウェブサービスの順序を調整して集合体の予期しないパフォーマンスを詳細に報告し、ブロック２９０で、新たな順序の第１ウェブサービスを呼び出せる。その後、新たに呼び出したウェブサービスについてブロック２６０から３００のプロセスを繰り返すことができる。
【００１８】
このように、本発明に従い、集合体内のウェブサービスを呼び出す順序は、集合体内の各個々のウェブサービスの計測したパフォーマンスだけに基づくのではなく、集合体のパフォーマンスにも基づいてダイナミックに調整できる。さらに、個々のウェブサービスがパフォーマンス期待を満たしていない場合、また集合体がパフォーマンス期待を超えている場合にも、順序の調整を行える。後者の場合、ダイナミックに計測したパフォーマンスの利点は、順序付けに関連して生じる調整を必要とすることなく、その後のパフォーマンスの不足に対応するように活用できることである。
【００１９】
発明の実施例は全体がハードウェアの実施例、全体がソフトウェアの実施例、又はハードウェアとソフトウェアの両要素を含む実施例の形態をとることができる。好適な実施例では、発明はソフトウェアに実装され、これにはファームウェア、常駐ソフトウェア、マイクロコードなどを含むが、それだけに限定されない。さらに、発明は、コンピュータ又はあらゆる命令実行システムが使う、もしくはそれと一緒に使うプログラムコードを備えるコンピュータ利用可能媒体又はコンピュータ読取可能媒体からアクセス可能なコンピュータプログラム製品の形態をとることができる。
【００２０】
本説明の目的上、コンピュータ利用可能媒体又はコンピュータ読取可能媒体は、命令実行システム、装置、あるいはデバイスが使う、もしくはそれと一緒に使うプログラムを内蔵、格納、通信、伝播、又は移送できるあらゆる装置でよい。この媒体は電子、磁気、光学、電磁、赤外線、又は半導体システム（あるいは装置又はデバイス）、もしくは伝播媒体でよい。コンピュータ読取可能媒体の例は、半導体又は固体メモリ、磁気テープ、取り外し可能コンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、リジッド磁気ディスク、光学ディスクを含む。現在ある光学ディスクの例は、コンパクトディスク―読取専用メモリ（ＣＤ−ＲＯＭ）、コンパクトディスク―書換型（ＣＤ−Ｒ／Ｗ）、ＤＶＤが含まれる。
【００２１】
プログラムコードを格納および実行するもしくは格納又は実行するのに適したデータ処理システムは、システムバスからメモリ素子に直接又は間接的に結合される少なくとも１つのプロセッサを含むであろう。メモリ素子は、プログラムコードを実際に実行する間に使うローカルメモリ、大容量記憶装置、および実行中に大容量記憶装置からコードを検索しなければならない回数を減らすために少なくとも一部のプログラムコードの一時的な記憶装置となるキャッシュメモリを含むことができる。入出力デバイス又はＩ／Ｏデバイス（キーボード、ディスプレイ、ポインティングディバイスなど）を直接又は介在するＩ／Ｏコントローラからシステムに結合できる。データ処理システムを介在するプライベートネットワークもしくは公衆ネットワークから他のデータ処理システム又はリモートプリンターあるいは記憶装置に結合できるように、ネットワークアダプタもシステムに結合してもよい。モデム、ケーブルモデム、イーサネットカードは、現在利用できるネットワークアダプタの種類のほんの数例である。
【図面の簡単な説明】
【００２２】
添付の図面は、本明細書に組み込まれてその一部を成すが、これは発明の実施例を例証するものであり、説明と合わせて、発明の原理を説明するのに役立つ。これに例証する実施例は現在好適なものであるが、発明は示したそのままの構成や手段に制限されないことは理解される。
【図１】ウェブサービス集合体におけるＱｏＳ指向のプランニングのために構成したデータ処理システムの概略図である。
【図２】ウェブサービス集合体におけるＱｏＳ指向のプランニングの方法を図示するフローチャートである。
【図１】
2007095078.tif 000003
【図２】
2007095078.tif 000004