JP2007529067A6 - 自己修復複合ウェブ・サービスのための方法及び装置 - Google Patents

Abstract

【課題】 自己修復複合ウェブ・サービスのための方法及び装置を提供すること。
【解決手段】 少なくとも１つの基本ウェブ・サービスを呼び出す複合ウェブ・サービス・プロセスを処理するための自己修復方法が開示される。基本ウェブ・サービスには、前述の基本ウェブ・サービスから独立しており、対応する基本ウェブ・サービスの機能と同じ機能を実施する少なくとも１つの代替ウェブ・サービスが設けられる。前述の複合ウェブ・サービス・プロセスのモデル定義を解析して、この基本ウェブ・サービスの呼び出しを起動するステップを識別する。（前述の複合ウェブ・サービス・プロセスのモデル定義により識別された）基本ウェブ・サービスの呼び出しを起動する前述のステップの後に、修復論理が挿入される。前述の複合ウェブ・サービス・プロセスの実行中に、以前の呼び出しステップにおいて基本ウェブ・サービスの呼び出しが失敗したかどうかを前述の修復論理が検出し、呼び出しの失敗が検出された場合には、呼び出しが成功しなかった基本ウェブ・サービスに対応して、前述の修復論理が前述の代替ウェブ・サービスを呼び出すようにする。

Description

本発明は、修復複合ウェブ・サービスのための方法及び装置に関し、具体的には、複合ウェブ・サービスに自己修復能力を与えるための方法及び装置、自己修復能力を有する複合ウェブ・サービスを実行するための方法及び装置、並びに、自己修復能力を有する複合ウェブ・サービスの処理方法に関する。

インターネット技術の成長は、組織がパートナー及び顧客と対話する方法に対して極めて大きな影響を及ぼす革新の波を引き起こしてきた。具体的には、複合ウェブ・サービス技術が、企業間コラボレーションを効率的に自動化するための有望な技術として出現している。

ウェブ・サービスは、ウェブ内において公開され、検出され、呼び出しされ得る、自己完結型で自己記述型のモジュラー・アプリケーションとして定義することができる。ウェブ・サービスは新しいサービスを形成するように構成することができる。以下では、複数のウェブ・サービスで構成される新しいウェブ・サービス・プロセスを、複合ウェブ・サービス・プロセスと呼ぶ。個々のウェブ・サービスからの複合ウェブ・サービス・プロセスの生成は、ウェブ・サービス複合と呼ばれるものであり、これは即ち、既存のサービス（即ち基本構成要素）を組み合わせて、新しいサービスを形成するものである。複合ウェブ・サービスは、所定のサービス・フローのモデルに応じて対話する、複数のパートナー・ウェブ・サービス（基本ウェブ・サービス）の複合である。上述のパートナー・ウェブ・サービスは、基本ウェブ・サービス又は複合ウェブ・サービス自体とすることができる。パートナーのウェブ・サービスを統合することにより、複合ウェブ・サービスは、顧客に複合ウェブ・サービスを提供し、顧客の複雑な要求を満たす。一般に、複合ウェブ・サービスは、ウェブ・サービス・プロセスのモデルによって定義される。例えば、複合ウェブ・サービスの旅行業者は、ウェブ・サービス・プロセスのモデルに応じて、連続して又は同時に実行される、航空便予約、旅行保険、宿泊予約、レンタカー、行程計画、その他といった複数のウェブ・サービスを集約することができる。図１は、例示的な複合ウェブ・サービスの旅行業者サービスを示す。顧客が旅行業者サービスに要求を発し、これに基づいて、旅行業者サービスが、航空業者サービス、ホテル・サービス、及びレンタカー・サービスを呼び出し、上述のサービスを実行するためには、「銀行サービス」が呼び出されるべきである。

次に、ウェブ・サービス・プロセスに関する標準をまず説明する。ＩＢＭ社のＷＳＦＬ（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｆｌｏｗ Ｌａｎｇｕａｇｅ）と、マイクロソフト社のＸＬＡＮＧ（ｅＸｔｅｎｓｉｂｌｅ ｌａｎｇｕａｇｅ）は、ウェブ・サービス複合の標準を定義する、最も初期の言語の２つである。ＷＳＦＬは、特定のプロセスについて、活動の特定の順番及びデータ交換を定義する。これは、特有の動作への流れにおける各ステップの実行順序及びマッピングの両方を定義するものである。ＷＳＦＬは例外の取り扱いをサポートするが、トランザクションに対して直接のサポートはしない。ＸＬＡＮＧは、ビジネス・プロセスの生成及びウェブ・サービス・プロバイダ間の対話を主たる対象とするものである。これは、長期間にわたるトランザクションの実行を補償によりサポートすることができる堅固な例外取り扱い機能を含む。

ＷＳＦＬ及びＸＬＡＮＧに概説されるウェブ・サービスのワークフロー仕様は、ＩＢＭ社、マイクロソフト社、及びＢＥＡからの新しい仕様、即ちＢＰＥＬ４ＷＳ（Ｂｕｓｉｎｅｓｓ Ｐｒｏｃｅｓｓ Ｅｘｅｃｕｔｉｏｎ Ｌａｎｇｕａｇｅ ｆｏｒ Ｗｅｂ Ｓｅｒｖｉｃｅｓ）で置き換えられた。ＢＰＥＬ４ＷＳは、ビジネス・プロセス対話におけるウェブ・サービスの動作をモデル化する。この仕様は、ビジネス・フローに関与するウェブ・サービスを調整するのに必要な制御論理及びデータ交換について記述するＸＭＬベースの文法を提供する。ウェブ・サービスは、次いで、例えば、ウェブ・サービス・プロセスのインスタンスを実行するＢＰＷＳ４Ｊといったウェブ・サービス・プロセス・エンジンによって、解釈し、実行することができる。実行中、ウェブ・サービス・プロセスは、多くのパートナーのウェブ・サービスを呼び出すことができる。図２は、ＢＰＥＬ４ＷＳプロセスの概略図を示す。図２では、ＢＰＥＬ４ＷＳプロセスは複数のステップを含み、そのいくつかは、外部のウェブ・サービスを呼び出す。顧客はＷＳＤＬ（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｂｉｎｇ Ｌａｎｇｕａｇｅ）を介してＢＰＥＬ４ＷＳプロセスに要求を発し、応答を得る。このプロセスは、役割及びパートナーを区別する例外の取り扱い上及びトランザクション上の特性、持続性及び順応性といった特性を有する。

顧客、並びに、ビジネス・パートナーを引き付け、保持するためには、複合ウェブ・サービスは一貫した信頼できる方法で実行される必要がある。具体的には、パートナーに障害が生じた場合でさえ、顧客にコミットしたサービス目標を果たすことが、ウェブ・サービス・プロセスには非常に重要である。上述の旅行業者サービスを例として挙げ、中国南方航空からの航空券が予約されたと仮定する。所定のビジネス・プロセスに応じて、車は、ニュー・コンセプト・カー・レンタル・カンパニーから借りるはずだが、例えば、通信障害、システムのシャットダウンといった何らかのシステム・エラーがそのレンタル会社のウェブ・サービスに発生する。旅行業者のウェブ・サービス・プロセスがこの障害から回復できない場合には、旅行業者サービスは、顧客に、車を借りられないことに対する「おわび」を戻さなくてはならない。顧客の観点からは、この旅行業者の質は低く、信頼できないものとなる。しかし、旅行業者が障害から回復できた場合には、最終的に顧客の要求は満たされることになる。信頼できるサービスの質が、顧客を引き付け、彼らを保持するであろう。

米国特許番号第６，３３０，６８９号Ｂ１ 米国特許公表番号第２００２／０００７４６８号Ａ１ 米国特許公表番号第２００３／０１４４８９４号Ａ１

従って、複合ウェブ・サービスのパートナーのウェブ・サービスに障害が発生した場合に、自己修復を実現できることが望まれる。自己修復とは、パートナーのウェブ・サービスに障害が生じた場合でも、ウェブ・サービス・プロセスがその元のサービス目標を実行し続けてこれを果たす能力を有することを意味する。ＩＢＭ社により提案される１つの自動コンピューティング解決法によれば、自己修復とは、システムが、中断を発見し、診断し、これに対処できることを意味する。システムは、まず、障害が生じたコンポーネントを検出し、次いで、これを修正又は隔離するためにオフラインにし、最後に、何らの明白なアプリケーションの中断を生じることなしで、修正されたコンポーネント又は交換用コンポーネントを再導入することにより、コンポーネントの障害からの回復が可能である。システムは起こりうる問題を予測し、その障害がアプリケーションに影響を与えることを阻止するように処置する。

しかしながら現在のところ、複合ウェブ・サービスを自己修復型にする他の明白な解決策はない。可能な解決策は、以下のものを含む。

（１）特殊サービス・プラットフォームを用いて、信頼性を保証すること。パートナーのサービスが全て信頼できるものであれば、複合ウェブ・サービス・プロセスは信頼できる品質で実行できることが明白である。現在のところ、ＩＢＭ社のＳｅｒｖｉｃｅ Ｄｏｍａｉｎといったいくつかの特殊サービス・プラットフォームが信頼できる基本ウェブ・サービスを提供することができ、サービス・プロバイダはコラボレーションのために信頼できるウェブ・サービスを提供できる。しかしながら、この解決策の欠点は、ウェブ・サービス・プロセスによって構築された複合ウェブ・サービスのプロバイダが、彼らの全てのパートナーに対して、パートナーのウェブ・サービスの信頼性を保証するのに必要な、特殊な専用サービス・プラットフォームを購入し、採用するように要求することは困難であるということである。

（２）ウェブ・サービス・プロセス・エンジンを用いて、複合ウェブ・サービスの信頼性を保証するための修復機構を提供すること。しかしながら、このエンジンで実施することができるこうした修復機構は、固定的なものであり、可視的ではなく、おそらく構成機能の数は少ないものである。プロバイダ及び管理者といった複合ウェブ・サービス・プロセスの利害関係者は、これらの修復機構をカスタマイズ又は制御することができない。

特許文献１は、プロセス外の障害が生じたアプリケーションを検出し、回復させるシステム・アーキテクチャを開示しており、ここでは、検出はログを記録して検討することにより実行され、回復はクラッシュしたアプリケーションを再始動することにより実行される。しかしながら、特許文献１に説明される解決策は、リアルタイムの回復を実現することはできない。

特許文献２は、ネットワーク・コンピュータ・システムの高可用性を実現するための方法及びシステムを開示する。全体的な高可用性は、各コンポーネントに高可用性を与えることにより実現される。しかしながら複合ウェブ・サービスでは、全てのパートナーのウェブ・サービスが高可用性をもつことは実際的ではない。

特許文献３は、ウェブを介して提供される永続サービスを生成し、管理するためのシステム及び方法を開示し、これは、個別サービスの自己修復に関するものである。特許文献３に述べられる解決法は、障害が生じた個別サービスを検出して再構築し、リアルタイムで再構築サービスを探索し、そのサービスを再び呼び出すために管理エージェント・モードを用いる。この特許は、サービスの信頼性を実現するために、各サービスが、該サービスにより定義された管理エージェント・モードに従うことを必要とする。

本発明の第１の実施形態は、複合ウェブ・サービス・プロセスのパートナー・ウェブ・サービスに障害が生じた場合に、この複合ウェブ・サービス・プロセスを回復可能にして、パートナーの障害のために、複合ウェブ・サービス・プロセスが割り込まれる又は異常終了することを防ぐようにする。

本発明のさらに別の実施形態は、自己修復ウェブ・サービス・プロセスのための、融通性があり、プラットフォームから独立した方法を提供する。これは、自己監視及び自己回復を行って、ウェブ・サービスが低費用で存続することができ、ウェブ・サービスのパートナーに障害が生じた場合でも、ウェブ・サービスの顧客は依然として必要なサービスを受けることができることを保証する。

本発明は、少なくとも１つの基本ウェブ・サービスを呼び出す複合ウェブ・サービス・プロセスを処理するための自己修復方法を提供する。この方法は、基本ウェブ・サービスに、前述の基本ウェブ・サービスから独立しており、対応する基本ウェブ・サービスの機能と同じ機能を実施する少なくとも１つの代替ウェブ・サービスを設けるステップと、前述の複合ウェブ・サービス・プロセスのモデル定義を解析して、基本ウェブ・サービスの呼び出しを起動するステップを探索するステップと、前述の複合ウェブ・サービス・プロセスのモデル定義により探索された、基本ウェブ・サービスの呼び出しを起動する前述のステップの後に、修復論理を挿入するステップと、を含む。そして、前述の複合ウェブ・サービス・プロセスの実行手順中に、基本ウェブ・サービスの以前の呼び出しが失敗したか否かを前述の修復論理が検出し、呼び出しの失敗が検出された場合には、呼び出しが失敗した基本ウェブ・サービスに対応して、前述の修復論理が前述の代替ウェブ・サービスを呼び出すようにする。

本発明は、さらに、少なくとも１つの基本ウェブ・サービスを呼び出す複合ウェブ・サービス・プロセスを処理するための自己修復装置を提供する。この装置は、基本ウェブ・サービスに、前述の基本ウェブ・サービスから独立しており、対応する基本ウェブ・サービスの機能と同じ機能を実施する少なくとも１つの代替ウェブ・サービスを設けるための代替ウェブ・サービス・リポジトリと、前述の複合ウェブ・サービス・プロセスのモデル定義を解析して、基本ウェブ・サービスの呼び出しを起動するステップを識別するためのモデル解析手段と、前述の複合ウェブ・サービス・プロセスのモデル定義により識別された、基本ウェブ・サービスの呼び出しを起動する前述のステップの後に、修復論理を挿入するための修復論理挿入手段と、を含む。そして、前述の複合ウェブ・サービス・プロセスの実行手順中に、基本ウェブ・サービスの以前の呼び出しが失敗したか否かを前述の修復論理が検出し、呼び出しの失敗が検出された場合には、呼び出しが失敗した基本ウェブ・サービスに対応して、前述の修復論理が代替ウェブ・サービス・リポジトリから前述の代替ウェブ・サービスを呼び出すようにする。

本発明は、さらに、少なくとも１つの基本ウェブ・サービスを呼び出す複合ウェブ・サービス・プロセスを実行するための装置を提供する。この装置は、基本ウェブ・サービスに、前述の基本ウェブ・サービスから独立しており、対応する基本ウェブ・サービスの機能と同じ機能を実行する少なくとも１つの代替ウェブ・サービスを設ける代替ウェブ・サービス・リポジトリと併せて用いられる。この装置は、前述の装置が複合ウェブ・サービス・プロセスに応じて、基本ウェブ・サービスの呼び出しを実行した後に、呼び出しが成功したかどうかを判断するための自己修復コンポーネントを含む。呼び出しの失敗が発生したと判断された場合には、呼び出しが成功しなかった基本ウェブ・サービスに対応して、代替ウェブ・サービス・リポジトリから代替ウェブ・サービスを呼び出すようにする。

本発明は、さらに、少なくとも１つの基本ウェブ・サービスを呼び出す複合ウェブ・サービス・プロセスを実行するための方法を含む。この方法は、基本ウェブ・サービスの呼び出しを実行した後に、呼び出しが成功したかどうかを判断するステップと、呼び出しの失敗が発生したと判断された場合には、呼び出しが成功しなかった基本ウェブ・サービスに対応して、代替ウェブ・サービス・リポジトリから代替ウェブ・サービスを呼び出すステップとを含む。前述の代替ウェブ・サービス・リポジトリには、基本ウェブ・サービスに、前述の基本ウェブ・サービスから独立しており、対応する基本ウェブ・サービスの機能と同じ機能を実施する少なくとも１つの代替ウェブ・サービスが設けられる。

本発明の利点は以下の通りである。

（１）本発明は、特定のサービス・プラットフォームを採用するよりも、実現可能である。本発明は、プラットフォームから独立しており、複合ウェブ・サービス・プロセス・レベルの信頼性を保証し、かつ、パートナーのウェブ・サービスを提供するサービス・プラットフォームに対してどのような特別な必要条件もない。即ち、本発明は、高可用性を実現するために、各パートナーのウェブ・サービスを必要としない。疎結合ウェブ・サービスの時代においては、より実現可能である。

（２）要望に応じて変更することができる（利害関係者志向）。本発明は、複合ウェブ・サービスの利害関係者が、修復機構をカスタマイズすることを可能にし、これらの修復機構は、要望に応じて複合ウェブ・サービス・プロセスに容易に統合することができる。

（３）低費用である。パートナーに障害が生じない場合には、サービス・プロセスは全く影響を受けない。パートナーに障害が生じた場合には、サービス・プロセスは別の呼び出しを実行するだけでよい。別のサービスの呼び出しは若干のパフォーマンス費用をもたらすが、プロセス全体の信頼性を保証する。以下のシナリオを考察する。複合ウェブ・サービス・プロセスが、１００のパートナー・サービスを呼び出す必要があり、最初の９９の呼び出しは成功するが、最後の１つは失敗する。ここに開示する方法なしでは、プロセス全体のインスタンスが失敗になり、最初の９９のパートナーの労力も無効になる。しかし、本発明の方法により、サービス・プロセスは実行され続け、即ち、障害が生じたパートナーのウェブ・サービスのための１つの候補となるウェブ・サービスが呼び出されて、結果が戻される。従って、最初の９９のパートナーの労力は維持され、複合ウェブ・サービスの費用は削減される。

添付図面に関連する本発明の例示的な実施形態の説明により、本発明の上述の及び他の態様及び利点がより明白になるであろう。

プロセス設計者からサービス・プロバイダに供給されるウェブ・サービスは、従来の読み取り不能のバイナリ・コードの代わりに、ＸＭＬ文書といった宣言形態で提供される。本発明は、自動的にビジネス・プロセスを分析し、次いで、修復論理をビジネス・プロセス論理内の適切な場所に挿入する。これらの修復論理は、パートナーのウェブ・サービスに障害が生じた場合に、ＸＭＬ文書に記述される元のビジネス・プロセスに影響を与えることなく、ウェブ・サービス・プロセスが、ユーザの元の要求を満たし続けることを保証する。同時に修復論理は、自己完結的な実施を遂行するため文法及び意味の定義に従ってビジネス・プロセス、例えばＢＰＥＬ４ＷＳ又はＷＳＦＬといったビジネス・プロセスの仕様に適合するようになっている。修復論理を含むウェブ・サービス・プロセスは、自己修復ウェブ・サービス・プロセスと呼ぶことができる。自己修復ウェブ・サービス・プロセスは、仕様に適合するプロセスを実行するプラットフォーム（プロセス・エンジン）のいずれにおいても展開及び実行することができる。自己修復ウェブ・サービス・プロセスがプロセス・エンジン上で実行されるときには、パートナーのウェブ・サービスに障害が生じると、修復論理は、まず、障害が生じたパートナー・ウェブ・サービスを検出して記録し、何らの明白な中断を生じることなしで、代替ウェブ・サービスを呼び出す修復ツールをビジネス・プロセスに導入する。パートナー・サービス及びその代替サービスは、パートナー・サービス・レジスタにおいてあらかじめ定義される。パートナー・サービスに障害が生じた後、単にレジスタに照会することにより、代替サービスを呼び出すことができる。ビジネス・プロセスは、元の要求を満たし続ける。

複合ウェブ・サービス・プロセスに、本発明による自己修復能力を与えるための方法及び関連装置を、図３乃至図５を参照して詳細に説明する。

図３は、複合ウェブ・サービス・プロセスに、本発明による自己修復能力を与えるための関連装置を概略的に示す。この装置は、パートナー・ウェブ・サービス・リポジトリ、修復ジェネレータ、及び修復ツール生成装置を含む。図４は、複合ウェブ・サービス・プロセスに、本発明による自己修復能力を与えるための方法のフローチャートを示す。

例として、図３に示す複合ウェブ・サービス・プロセスのモデルにおいて、まずステップ１が実行され、次いでステップ２Ａ及びステップ２Ｂが同時に実行され、最後にステップ３が実行されて、ステップ２Ａ及びステップ２Ｂは、ウェブ・サービス「ＷＳ２Ａ」及び「ＷＳ２Ｂ」をそれぞれ呼び出す。

パートナー・ウェブ・サービス・リポジトリは、代替ウェブ・サービスのコンテナであり、ここでは、複合ウェブ・サービス・プロセスにおいて呼び出されるべきウェブ・サービスＷＳ２Ａ及びＷＳ２Ｂには、それぞれ、ＷＳ２Ａ＿ａｌｔｅｒｎａｔｉｖｅ＿１からＷＳ２Ａ＿ａｌｔｅｒｎａｔｉｖｅ＿ｎまで、及びＷＳ２Ｂ＿ａｌｔｅｒｎａｔｉｖｅ＿１からＷＳ２Ｂ＿ａｌｔｅｒｎａｔｉｖｅ＿ｎまでの複数の代替ウェブ・サービスが設けられている。代替ウェブ・サービスは同じ機能を提供するが、異なるサービス・プロバイダによって与えられる。例えば、中国東方航空の航空便予約サービスは、中国南方航空の航空便予約サービスの代替サービスである。実際のプロバイダは、関心のあるパートナー・サービス・ウェブ・リポジトリに登録して、望ましいサービスを与えることができる。複合ウェブ・サービス・プロセス内の１つのパートナー・ウェブ・サービスが使用不可である場合には、パートナー・ウェブ・サービス・リポジトリが用いられる。使用不可のパートナー・ウェブ・サービスの代わりに、対応するリポジトリにおける代替ウェブ・サービスが選択され、呼び出される。例えば、複合ウェブ・サービス・プロセスの旅行業者において、中国南方航空の航空便予約サービスに障害が生じた場合には、中国東方航空の航空便予約サービスが呼び出されて、航空便の予約を委任される。

パートナー・ウェブ・サービス・リポジトリ内においては、代替ウェブ・サービスは、代替ウェブ・サービス選択ポリシーに応じて、異なる呼び出しレベルを割り当てられることができる。選択ポリシーは、サービスの可用性といったパラメータを含むランキング・アルゴリズムのいずれかに基づいて構成することができ、自己修復プロセスが、ランクに応じて、代替ウェブ・サービスを呼び出すことができるようにする。

修復ジェネレータは、モデル解析装置、修復論理生成装置、及び修復論理挿入装置を含み、これらは既存の複合ウェブ・サービス・プロセスのモデル定義をさらに処理するのに使用される。図４のステップＳ４１０で、モデル解析装置は、複合ウェブ・サービス・プロセスのモデル定義におけるステップを解析して、例えば、図３のステップ２Ａ及び２Ｂといったパートナー・ウェブ・サービスの呼び出しを起動するステップを探索し、ステップＳ４２０で、モデル定義におけるこのステップが、パートナー・ウェブ・サービスを呼び出すかどうかが判断される。ステップＳ４２０で、パートナー・ウェブ・サービスが呼び出されないと判断された場合には、流れは以下に説明するステップＳ４６０に進む。ステップＳ４２０で、パートナー・ウェブ・サービスが呼び出されると判断された場合には、ステップＳ４３０で修復論理生成装置が修復論理を生成し、ステップＳ４４０で、修復論理挿入装置が、ステップ（２Ａ、２Ｂ）の後に生成された修復論理を挿入し、この修復論理が、図３の自己修復プロセス・モデルにおけるステップ２Ａ−Ｈ、２Ｂ−Ｈといった、複合ウェブ・サービス・プロセスのモデル定義により探索されたパートナー・ウェブ・サービスの呼び出しを起動し、これらのステップが、先行するステップ２Ａ及び２Ｂにおいてパートナー・ウェブ・サービスの呼び出しが成功したかどうかを検出するために用いられる。修復論理は、パートナーの応答が取得されたかどうかに応じて、パートナー・ウェブ・サービスの呼び出しが成功したかどうかを判断することができる。

ステップＳ４５０では、修復ツール生成装置が、図３のＷＳ２Ａ−Ｈｅａｌｅｒ及びＷＳ２Ｂ−Ｈｅａｌｅｒといった修復論理に対応する修復ツールを生成する。以下に、修復ツールについて詳細に説明する。

ステップＳ４６０で、ウェブ・サービスのモデルが終了するかどうかが判断される。終了すると判断された場合には、本発明の方法は終了する。終了ではないと判断された場合には、プロセスはステップＳ４１０に戻り、モデル定義における次のステップが解析される。

以下に、修復ツールについて詳細に説明する。修復ツール自体はウェブ・サービスであり、パートナー・ウェブ・サービスが使用不可である場合に、パートナー・ウェブ・サービス・リポジトリからパートナー・ウェブ・サービスの代替ウェブ・サービスを呼び出して、望ましいサービスを得ることができる。例えば、パートナー・ウェブ・サービスＷＳ２Ａが使用不可である場合には、ステップ２Ａの出力は、システム・レベル例外である。システム・レベル例外とは、システム障害、ネットワーク障害、及びアプリケーション欠陥が原因で発生した例外を意味する。この場合、修復論理２Ａ−Ｈは、修復ツールＷＳ２Ａ−Ｈｅａｌｅｒを呼び出す。図５は、修復ツールの基本プロセスのフローチャートを示す。ステップＳ５１０で、修復ツールＷＳ２Ａ−Ｈｅａｌｅｒは、例えば、ＷＳ２Ａ＿ａｌｔｅｒｎａｔｉｖｅ＿１といった、前述の代替ウェブ・サービス選択ポリシーに応じて、呼び出されるべき代替ウェブ・サービスを選択し、ステップＳ５２０で代替ウェブ・サービスを呼び出す。修復ツールは、さらに、いつ及びどのパートナー・ウェブ・サービスが使用不可であるかについて、パートナー・ウェブ・サービス・プロバイダとのコラボレーションのログとして記録することができる。修復ツールはまた、パートナー・ウェブ・サービス・リポジトリと通信して、代替ウェブ・サービスの呼び出しレベルの評価に参加することができる。

上述のプロセスを通して、既存の複合ウェブ・サービス・プロセスは、ウェブ・サービス・プロセス・エンジン上で実行される自己修復機能を有する自己修復複合ウェブ・サービス・プロセスとなる。複合ウェブ・サービス・プロセスの自己修復プロセスは、図６を参照して以下に説明する。ステップＳ６１０で、複合ウェブ・サービス・プロセスのそれぞれのステップは、複合ウェブ・サービス・プロセスのモデル定義に応じて実行される。ステップＳ６２０で、パートナー・ウェブ・サービスは、複合ウェブ・サービス・プロセスの要求に応じて呼び出される。そして、ステップＳ６３０で、呼び出しが成功かどうかが判断される。呼び出しが成功したと判断された場合には、プロセスはステップＳ６５０に進む。呼び出しが失敗したと判断された場合には、修復ツール・ウェブ・サービスがステップＳ６４０で呼び出される。代替ウェブ・サービスが修復ツール・ウェブ・サービスによって呼び出される。ステップＳ６５０で、複合ウェブ・サービス・プロセスが、このステップで終了するかどうかが判断される。終了しない場合には、プロセスはステップＳ６１０に戻り、複合ウェブ・サービス・プロセスを実行し続ける。終了する場合には、自己修復プロセスは終了する。

本発明に開示される方法によるＢＰＥＬ４ＷＳに基づく実施形態を、図７乃至図８を参照して以下に説明する。図７は、顧客がローンの要求を送信し、その要求が処理されて、顧客がローンの要求が承認されたかどうかについて調べる、ＢＰＥＬ４ＷＳプロセスの例を示す。このプロセスにおいて、動作は、メッセージを得ること、金融機関のウェブ・サービスを呼び出すこと、最後に顧客に応答することで構成される。これら３つの動作は、＜受信＞＜呼び出し＞、及び＜応答＞の活動を用いて、ＢＰＥＬにおいて定義される。構築された活動を用いることにより定義されるこうした活動間の関係は、これらの活動をいかに稼動させるかについての制限を定義する。この例では、順番付けは、活動が次々に稼動されるようにする＜順序＞活動を用いて実現される。図８は、この例の自己修復ＢＰＥＬ４ＷＳプロセスを示す。＜呼び出し＞の出力結果が例外である場合に、プロセスが、代替パートナー・サービスを呼び出す修復ツール・ウェブ・サービスを呼び出して、ＢＰＥＬ４ＷＳプロセスの信頼性を保証するようにする点が異なる。

この例の実施ステップは、以下の通りである。

（１）まず、ウェブ・サービス・プロセス文書、ｌｏａｎａｐｐｒｏｖａｌ．ｂｐｅｌを解析して、パートナー・ウェブ・サービス（金融サービス）を呼び出す活動（＜呼び出し＞金融サービス）を探索し、パートナー・ウェブ・サービスの情報を得る。

（２）パートナー・ウェブ・サービスの代替ウェブ・サービスを呼び出す修復ツール・ウェブ・サービスを生成する。代替ウェブ・サービスの名称及びアドレスといった、呼び出しに必要な情報を、パートナー・ウェブ・サービス・リポジトリ、及び、対応するサービスＷＳＤＬから得ることができる。

（３）パートナー・ウェブ・サービスを呼び出すステップの後、＜切り換え＞活動及び＜呼び出し＞活動を挿入して、前に呼び出されたパートナー・ウェブ・サービスに障害が生じた場合に、修復ツール・ウェブ・サービスを呼び出せるようにする。

（４）プロセス、関連パートナー・ウェブ・サービス、及び修復ツール・ウェブ・サービスを展開する。

（５）プロセス・エンジン上で自己修復複合ウェブ・サービス・プロセスを実行する。

上述の方法及び装置は、修復論理を複合ウェブ・サービス・プロセスに加え、次いで、ウェブ・サービス・プロセスがプロセス・エンジン上で実行されて、複合ウェブ・サービス・プロセスの信頼性を保証するようにする。本発明による方法は、さらに、ウェブ・サービス・プロセス実行エンジンによって採用されるように変更することができる。即ち、複合ウェブ・サービス・プロセス自体は変更されないが、その代わりに、修復プロセスがウェブ・サービス・プロセスによって実行される。以下では、「ウェブ・サービス・プロセス実行エンジン」は、簡単に「プロセス・エンジン」と呼ばれる。

まず、プロセス・エンジンについて簡単に説明する。複合ウェブ・サービス・プロセス仕様と共に、少数のツールが仕様に与えられている。例えば、ＩＢＭ社は、複合ウェブ・サービス・プロセスを実行することができる、ＢＰＷＳ４Ｊと呼ばれるプロセス・エンジンを提供している。複合ウェブ・サービス・プロセス・エンジンは、実行されるべきビジネス・プロセスを記述する複合ウェブ・サービス・プロセス定義文書、パートナー・ウェブ・サービスを記述するＷＳＤＬ文書、及び結果として生じた顧客に対するビジネス・プロセスのインターフェースを記述するＷＤＳＬ文書を取り込む。この入力から、プロセス・エンジンは、ＳＯＡＰ（サービス志向アーキテクチャ及びプログラミング）インターフェースをもつウェブ・サービスとして使用可能になるプロセスを生成する。プロセスのインターフェースを記述するＷＤＳＬファイルは、ランタイムに検索することができる。エンジンもまた、プロセス内からウェブ・サービスの呼び出しをサポートする。図９は、プロセス・エンジンが、活動の実施において、どのようにしてパートナー・ウェブ・サービスを呼び出すかを示す。定義後、プロセスのモデルは、サービス・リクエスタを介してプロセス・エンジンに入力される。プロセス・エンジンは、対応するプロセスを実行し、ＳＯＡＰメッセージをウェブ・サービス・プロバイダのＳＯＡＰハンドラに送信するサービス呼び出しユティリティと通信し、そのサービス・コンテナ内のサービスを呼び出して、ＳＯＡＰメッセージをサービス呼び出しユティリティに戻す。

図１０は、本発明による自己修復プロセス・エンジンを示す。複合ウェブ・サービス・プロセス・エンジンは、修復コンポーネントを複合ウェブ・サービス・プロセス・エンジンに挿入することにより、パートナー・ウェブ・サービスの障害に対処することができる。前述の修復論理と同様に、修復コンポーネントは、過去の呼び出しが失敗したかどうかを検出する。失敗の場合には、サービス呼び出しユティリティを通じて、障害が生じたパートナー・ウェブ・サービスの代替ウェブ・サービスを呼び出す。このワークフローは、上で開示された自己修復プロセスと同様であり、唯一の違いは、自己修復プロセスが、プロセス自体ではなく、プロセス・エンジンにおいて取り扱われることである。本発明をプロセス・エンジンで実行する利点は、プロセスのモデル自体が変更されないことである。プロセス・エンジンは、稼動中の複合ウェブ・サービス・プロセスの信頼性に責任を負う。欠点は、修復コンポーネントが固定的であり、稼動するプロセスの利害関係者にとって可視的でないことである。

本発明は、本発明の好ましい実施形態を参照して詳細に述べられ、示されているが、当業者であれば、添付の特許請求の範囲により定義される本発明の精神及び範囲から離れることなく、形態及び詳細に対して種々の修正を行うことができることを理解すべきである。

複合ウェブ・サービスの例を示す。 ＢＰＥＬ４ＷＳプロセスの概略図を示す。 複合ウェブ・サービス・プロセスに、本発明による自己修復能力を与えるための関連装置を概略的に示す。 複合ウェブ・サービス・プロセスに、本発明による自己修復能力を与えるための方法のフローチャートを示す。 修復ツールの基本プロセスのフローチャートを示す。 複合ウェブ・サービス・プロセスの自己修復のフローチャートを示す。 ＢＰＥＬ４ＷＳプロセスの例を示す。 図７に示す例の自己修復ＢＰＥＬ４ＷＳプロセスを示す。 プロセス・エンジンが、活動の実施において、どのようにしてパートナーのウェブ・サービスを呼び出すかを示す。 本発明による自己修復プロセス・エンジンを示す。

Claims (18)

1. 少なくとも１つの基本ウェブ・サービスを呼び出す複合ウェブ・サービス・プロセスを処理するための自己修復方法であって、前記基本ウェブ・サービスに、前記基本ウェブ・サービスから独立しており、対応する基本ウェブ・サービスの少なくとも１つの機能を実施する少なくとも１つの代替ウェブ・サービスを設けるステップと、前記複合ウェブ・サービス・プロセスのモデル定義を解析して、前記基本ウェブ・サービスの呼び出しを起動するステップを識別するステップと、前記複合ウェブ・サービス・プロセスの前記モデル定義により識別された、前記基本ウェブ・サービスの呼び出しを起動する前記ステップの後に、修復論理を挿入するステップと、前記複合ウェブ・サービス・プロセスの実行中に、前記基本ウェブ・サービスの以前の呼び出しが失敗したかどうかを前記修復論理が検出し、呼び出しの失敗が検出された場合には、呼び出しが失敗した前記基本ウェブ・サービスに対応して、前記修復論理が前記代替ウェブ・サービスを呼び出すようにするステップと、
   を含む方法。
2. 前記修復論理を挿入する前に、前記修復論理を生成するステップをさらに含む、請求項１に記載の方法。
3. 前記修復論理が、前記基本ウェブ・サービスから応答が取得されたか否かに応じて、前記基本ウェブ・サービスの呼び出しが失敗したかどうかを判断することを特徴とする、請求項１に記載の方法。
4. 代替ウェブ・サービス・リポジトリと通信し、前記代替ウェブ・サービス・リポジトリ内の前記代替ウェブ・サービスを呼び出す修復ツールを生成するステップをさらに含み、前記修復論理が、前記修復ツールを呼び出すことにより前記代替ウェブ・サービスを呼び出す、請求項１に記載の方法。
5. 前記修復ツールがウェブ・サービス自体であることを特徴とする、請求項４に記載の方法。
6. 前記修復ツールが、前記呼び出しが失敗した基本ウェブ・サービス及び前記呼び出しが失敗した時間を記録するステップをさらに含む、請求項４に記載の方法。
7. 前記少なくとも１つの代替ウェブ・サービスが、複数の呼び出しレベルに分割され、これに基づいて、前記修復論理が前記代替ウェブ・サービスを呼び出すことを特徴とする、請求項１に記載の方法。
8. 少なくとも１つの基本ウェブ・サービスを呼び出す複合ウェブ・サービス・プロセスを処理するための自己修復装置であって、前記基本ウェブ・サービスに、前記基本ウェブ・サービスから独立しており、対応する基本ウェブ・サービスの少なくとも１つの機能を実施する少なくとも１つの代替ウェブ・サービスを設けるための代替ウェブ・サービス・リポジトリと、前記複合ウェブ・サービス・プロセスのモデル定義を解析して、前記基本ウェブ・サービスの呼び出しを起動するステップを識別するためのモデル解析手段と、前記複合ウェブ・サービス・プロセスの前記モデル定義により識別された、前記基本ウェブ・サービスの呼び出しを起動する前記ステップの後に、修復論理を挿入する修復論理挿入手段と、を含み、前記複合ウェブ・サービス・プロセスの実行中に、前記基本ウェブ・サービスの以前の呼び出しが失敗したかどうかを前記修復論理が検出し、呼び出しの失敗が検出された場合には、呼び出しが失敗した前記基本ウェブ・サービスに対応して、前記修復論理が前記代替ウェブ・サービス・リポジトリから前記代替ウェブ・サービスを呼び出すようにした、装置。
9. 前記修復論理を生成するための修復論理生成手段をさらに含む、請求項８に記載の装置。
10. 前記修復論理が、前記基本ウェブ・サービスから応答が取得されたか否かに応じて、前記基本ウェブ・サービスの呼び出しが失敗したかどうかを判断することを特徴とする、請求項８に記載の装置。
11. 前記代替ウェブ・サービス・リポジトリと通信し、前記代替ウェブ・サービス・リポジトリ内の前記代替ウェブ・サービスを呼び出す修復ツールを生成するための修復ツール生成手段をさらに含み、前記修復論理が、前記修復ツールを呼び出すことにより前記代替ウェブ・サービスを呼び出す、請求項８に記載の装置。
12. 前記修復ツール生成手段は、前記生成された修復ツールがウェブ・サービス自体になるようにする構成であることを特徴とする、請求項１１に記載の装置。
13. 前記代替ウェブ・サービス・リポジトリ内に設けられた前記代替ウェブ・サービスが、複数の呼び出しレベルに分割され、これに基づいて、前記修復論理が前記代替ウェブ・サービスを呼び出すことを特徴とする、請求項８に記載の装置。
14. 少なくとも１つの基本ウェブ・サービスを呼び出す複合ウェブ・サービス・プロセスを実行するための装置であって、前記装置が、前記基本ウェブ・サービスに、前記基本ウェブ・サービスから独立しており、対応する基本ウェブ・サービスの少なくとも１つの機能を実行する少なくとも１つの代替ウェブ・サービスを設ける代替ウェブ・サービス・リポジトリと併せて用いられて、前記装置が、前記複合ウェブ・サービス・プロセスに応じて、前記基本ウェブ・サービスの呼び出しを実行した後に、前記呼び出しが成功したかどうかを判断し、呼び出しが失敗であると判断された場合には、呼び出しが成功しなかった前記基本ウェブ・サービスに対応して、前記代替ウェブ・サービス・リポジトリから代替ウェブ・サービスを呼び出す自己修復コンポーネントを含む、ことを特徴とする装置。
15. 少なくとも１つの基本ウェブ・サービスを呼び出す複合ウェブ・サービス・プロセスを実行するための方法であって、前記基本ウェブ・サービスの呼び出しを実行した後に、前記呼び出しが成功したかどうかを判断するステップと、呼び出しが失敗であると判断された場合には、呼び出しが成功しなかった前記基本ウェブ・サービスに対応して、代替ウェブ・サービス・リポジトリから代替ウェブ・サービスを呼び出すステップと、を含み、前記代替ウェブ・サービス・リポジトリには、前記基本ウェブ・サービスに、前記基本ウェブ・サービスから独立しており、対応する基本ウェブ・サービスの少なくとも１つの機能を実施する少なくとも１つの代替ウェブ・サービスが設けられる、ことを特徴とする方法。
16. 前記代替ウェブ・サービス・リポジトリ内に設けられた前記代替ウェブ・サービスが、複数の呼び出しレベルに分割され、これに基づいて、前記代替ウェブ・サービスが呼び出されることを特徴とする、請求項１５に記載の方法。
17. 前記方法が、前記複合ウェブ・サービス・プロセスを実行するプロセス・エンジンにより自動的に実行されることを特徴とする、請求項１５に記載の方法。
18. 前記方法が、前記複合ウェブ・サービス・プロセスの一部であることを特徴とする、請求項１５に記載の方法。

Images