ネットワークにおけるプロセス構成
１つのサービスに対するサーチが、前のサービスを提供するノードで開始されるような段階的なサーチによってネットワークのノードの間で分散されているサービスを利用するプロセスを提供するように、ネットワークを構成するための方法及び、構成可能なネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はコンピュータネットワーク内でプロセスを構築するための方法、及び特にプロセスを提供する位置決め及びサービスの選択のための方法に関する。本発明は適切なネットワークにも及ぶ。
【背景技術】
【０００２】
ウェブサービスとは、ネットワーク上でサービスを公開（exposed）することができ、使用することができる方法を記述するために使用される語句である。ウェブサービスは、ソフトウェアが通信する方法に関する。ソフトウェアはパソコン上の単純なスクリプトからネットワークサーバ上のアプリケーション、メインフレームコンピュータで実行される大型の動作サポートシステムに至るまで多くの形で提供できる。これらのスクリプト、アプリケーション、及びソフトウェアシステムはソフトウェアコンポーネントの例である。ウェブサービスは、他のソフトウェアコンポーネントがウェブサービス自体を使用できるようにするソフトウェアコンポーネントに基づいている。
【発明の開示】
【０００３】
ソフトウェアコンポーネントがウェブサービスを提供できるようにするように配備するための多くの技術が成熟し、標準化されており、これらにはシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）、ウェブサービス記述言語（ＷＳＤＬ）、ユニバーサルディスクリプション、ディスカバリー＆インテグレーション（ＵＤＤＩ）が含まれる。
【０００４】
ウェブサービスはＷＳＤＬを使用して記述でき、ウェブサービスはＵＤＤＩを使用して位置を突き止めることができ、ウェブサービスの機能性をＳＯＡＰを使用して呼び出すことができる。これらの３つの技術は共通データ記述規格の拡張マークアップ言語（ＸＭＬ）の上に構築される。ＸＭＬはコンピュータメッセージの内容を定義するための標準的な仕様であり、あるソフトウェアコンポーネントと別のソフトウェアコンポーネントの間で送信されるメッセージの内容を表すための共通の方法を提供する。ソフトウェアアプリケーションがＸＭＬで該ソフトウェアアプリケーションの出力を書き込む場合、ＸＭＬを解釈できる別のアプリケーションが該出力を読み取り、該出力に対して作用できる。
【０００５】
ＳＯＡＰは、あるソフトウェアコンポーネントが別のソフトウェアコンポーネントの機能を、該２つのソフトウェアコンポーネント間のメッセージパッシングを呼び出しの手段として使用して呼び出すことができる手段を提供する。ＳＯＡＰの仕様はＷ３Ｃによって管理されている世界的な規格であり、現在は２００４年６月にＷ３Ｃによって発行されたバージョン１．２であり、http://www.w3.org/TR/SOAPまたはhttp://www.w3.org/TR/2003/REC-soap12-part0-20030624でアーカイブとして入手できる。ＳＯＡＰは要求−応答機構を使用し、該機構では、あるソフトウェアコンポーネントが別のソフトウェアコンポーネントに対して要求を行うと、該別のコンポーネントが応答する。要求と応答の両方ともＸＭＬドキュメントの形で送信される。
【０００６】
ＸＭＬ及びＳＯＡＰは、ＨＴＴＰとともに、あるソフトウェアコンポーネントがインターネット上で別のソフトウェアコンポーネントの機能を呼び出すための手段を提供する。これらの技術は、ＨＴＴＰをサポートする任意のネットワーク上でソフトウェアコンポーネントを統合するために使用できる。この統合を実施するためには、以下の情報も必要とされる。
【０００７】
・すべての使用可能な機能に関する、該機能の呼び出しパラメータを含む情報
・値指定を含む、すべてのＸＭＬメッセージについてのデータタイプ情報
・使用される特定の送信プロトコルについてのバインディング情報
・指定されたサービスの位置を突き止めるためのアドレス情報
ＷＳＤＬファイルは、ソフトウェアコンポーネントについて上記に一覧表示した情報を提供するＸＭＬドキュメントである。ソフトウェアコンポーネントは、ＷＳＤＬを使用してウェブサービスの使用可能な機能のいずれとも統合され得る。ＷＳＤＬを認知するツールを用いると、このプロセスを完全に自動化することができ、アプリケーションは、ほとんどまたはまったく手動コードを使わずに新しいサービスと容易に統合され得る。ＷＳＤＬはhttp://www.w3.org/TR/wsdlで、またはhttp://www.w3.org/TR/2001/NOTE-wsdl-20010315でアーカイブとして定義されている。
【０００８】
ウェブサービスは、通信機能、及びサービスアプリケーションとビジネスアプリケーションの提供を含む広範囲に適用される。アプリケーションを作成するときには、種々の供給元、例えば異なる会社によって供給される多くのソフトウェアコンポーネントの長所を評価することが望ましい場合がある。ＵＤＤＩはウェブサービスのレジストリを作成するための手段を利用可能にすることによって基本的なウェブサービス技術にこの拡張を提供する。これにより、ウェブサービスはインターネット上で互いと取引を行う会社の領域に入る。ＵＤＤＩの仕様は、会社が迅速に、容易に、且つ動的に互いを検出し、互いと取引を行うことを可能にする。ＵＤＤＩは、会社が以下を行うことができるようにする。
【０００９】
・会社のサービスを説明する
・サービスを提供する他の会社を発見する
・これらの他のサービスと統合する
ＵＤＤＩレジストリは、所望される機能を検出するために使用できる。レジストリに対する要求は特定の機能に対するものであり、費用制限、セキュリティニーズ、性能基準等の他の要件を含んでもよい。次に、レジストリはこのような機能を提供する１つまたは複数の会社を提案し、供給業者の選択を可能にする。ＵＤＤＩの仕様は、例えば、企業及び該企業が提供するサービスについての情報を含むレジストリの作成及び使用を可能にする。ＵＤＤＩの仕様は、構造化情報標準促進団体（ＯＡＳＩＳ）により管理されており、http://uddi.orgで入手できる。
【００１０】
ＵＤＤＩレジストリに加えて、公に利用可能なウェブサービスのリストがある。
【００１１】
ウェブサービスは通信ネットワーク内にアプリケーションも有する、つまりネットワーク機能をソフトウェアサービスとして公開する。通信サービスプロバイダは、ウェブサービスを使用して、ソフトウェア技術とネットワーク技術の組み合わせの利点を活用することができる。例えば、ビデオオンデマンドのウェブサービスは（ビデオストリーム自体をウェブサービスとして提示してもよい）該ビデオストリームを配信する通信サービスを活用することができる。
【００１２】
グリッドコンピューティングは、通常は、より低い価格／性能比でではあるが、単一の大型メインフレームまたはスーパーコンピュータに一般的に関連付けられたサービスの質を提供するために、複数のシステム全体でのリソースのプーリング(pooling)、及び要求に応じた該リソースの割り当てを可能にする。グリッドコンピューティングは、アプリケーションがリソースの割り当てを要求できるリソースアクセスのフレームワークを作成することにより機能する。これらのリソースは、要求するアプリケーションによって使用され、後に解放される。グリッド環境は本質的に分散されており、外部組織のシステムを含んでもよい。
【００１３】
グリッド実現例は、通常、米国政府により後援され、グローバス（Globus）として知られ、ソースコードが公開され、http://www.globus.org/で入手可能なツールキットを使用して構築される。該ツールキットのウェブサービスへの適合性は、分散リソースから作成されるサービスを作成、終了、管理及び呼び出すためのウェブサービスの集合を定義するオープングリッドサービスアーキテクチャ（ＯＧＳＡ）として知られている提案規格であって、http://www.globus.org/ogsa/で入手可能なものにより強化される。
【００１４】
ＯＧＳＡの使用により、任意のウェブサービスに基づいたプラットホームが、電話会議の構築からデータの大規模操作に至るであろう特定の機能を実現するための一時的なサービスを作成することが可能になる。これらのサービス自体が、アクセスを容易にするために可能にされたウェブサービスであろう。
【００１５】
ここでは、ユーザアクセスサービスは、サービス指向アーキテクチャ（ＳＯＡ）を通して提供される。これらのサービスは、実際には、アプリケーションサーバカーネル上に構築されるアプリケーションによって実現されるが、該アプリケーションサーバカーネルは、そのリソースの使用を共有するためにグリッドプロトコルを活用する。使用可能なあらゆる余分なリソースは、やはりＳＯＡを通してアクセス可能なＯＧＳＡ呼び出しを通してオンデマンドサービスを作成するためにまとめることができる。したがって、実際のカスタマの経験はＳＯＡを通して制御される恒久的なサービスと一時的なサービスの集合体から作られる。
【００１６】
ビジネスプロセスの管理を可能にする技術解決策には、領域の専門家による多大な関心がある。重要な目標は、ビジネス要求を、支援するＩＴシステムを指定するために使用できる用語に変換する必要性を排除することである。このような変換は、一般的には多大な時間を必要とし、信頼できない。関連する業界の成果には、サービス指向アーキテクチャ（ＳＯＡ）が含まれ、該ＳＯＡではグラフィック開発環境におけるサービスコンポーネントから、アプリケーションが組み合わされて、ビジネスプロセスの機能仕様が作成される。該ＳＯＡの実施例として、オラクル社によって最近のリリースされたビジネスプロセス実行言語（ＢＰＥＬ）デザイナーアプリケーションプロトタイプが挙げられ、ここでは、アプリケーションの構造を記述するためにウェブサービス向けビジネスプロセス実行言語（ＢＰＥＬ４ＷＳ）が使用される。これは、ビジネスプロセスを記述、指定するための標準化されたシンタックス及びセマンティクスの例である。その結果、ソフトウェアツールはビジネスプロセス管理をサポートするための仕様を使用できる。
【００１７】
このような抽象的なプロセス記述を与えられている場合の主要な技術的な問題は、所望されるレベルの性能の具体的な実現例をどのようにして構築するかである。プロセスがウェブサービスの集合から構成されていると仮定すると、１つの手法はビジネスプロセスで必要とされるサービスのインスタンスを見つけるために（例えば、ＵＤＤＩ-ユニバーサルディスクリプション、ディスカバリ＆インテグレーションプロトコルを使用して）ディレクトリの集合を照会することであろう。該ディレクトリは、プロセス仕様により必要とされるすべてのサービスのインスタンスを見つけるために照会されるであろう。グリッドサービスが使用されている場合には、該ディレクトリは必要とされるサービスのインスタンスを生成する適切なノードに照会することもできるであろう。
【００１８】
この手法は独立したサービスからなるビジネスプロセスにとっては妥当である。この場合、各サービスインスタンスは、該サービスインスタンスの個々の性能特性に基づいて別々に選択できる。さらに複雑な状況では、プロセスは、１以上のサービスの結果であって、別のサービスに対する入力として提供されるべきものであり、したがって該別のサービスは、先行するサービスが完了するまで先に進むことができないものを要求する。プロセスの提供は、より低速の「ボトルネック」サービスを含むことにより効率が悪化する場合がある。加えて、サービス間で相当量のデータを転送しなければならない場合、サービスインスタンス間のネットワーク接続性の特徴が、所望されるプロセスの性能に悪影響を及ぼすこともある。
【００１９】
残念なことにウェブサービスディレクトリで使用できる情報は、典型的には、いずれのサービスについても相対的な位置や現在の性能を含んでいない。複雑なプロセスの場合、あるいは一般的に入手可能なサービスのインスタンスの幅広い選択肢がある場合には、考えられる構成が多数ある。これらのどれが所望されるサービスの質を満たすことができるのかを決定するには、はるかに多くの情報の収集及び複雑な最適化が必要になる。つまり通常は多大な作業が必要になる。
【００２０】
本発明は請求項１に述べられているような方法を提供することによって前述の問題を回避する。本発明は請求項２０に述べられているようなネットワークも提供する。
【００２１】
本発明の実施形態は、ここで例証として図面を参照して説明される。
【発明を実施するための最良の形態】
【００２２】
本発明の第１の実施形態はここでウェブサービスをサポートするネットワークにアクセスするユーザに関して一例として説明される。ユーザは、ネットワークのリソースを使用してプロセスを構築することを希望している。
【００２３】
図１は、クレジットアプリケーションに関する単純なプロセスの一部のフローチャート表現を示し、該クレジットアプリケーションは、ここでボックスにより表現されている一連のサービスを使用することを必要とする一連の段階で実行される。該プロセスは、ローンを求めている申請者を有するユーザからのローンのための見積もりに対する要求を受け取ることで開始する。第１のステップは、申請者によって供給される識別情報に基づいてローン申請者の社会保険番号（ＳＳＮ）を取得することであり、このタスクサービスのためにＲｅｔｒｉｅｖｅ ＳＳＮ（ＳＳＮ検索）が選択される。社会保険番号がいったん取得されると、申請者のＳＳＮで特定されるローン申請者のクレジット格付けが、Ｇｅｔ Ｃｒｅｄｉｔ Ｒａｔｉｎｇ（クレジット格付け取得）サービスを使用して取得される。いったんクレジット格付けが取得されると、Ｃｏｌｌｅｃｔ Ｏｆｆｅｒｓ（オファー収集）サービスを使用してクレジットのオファーが捜し出される。受信されたクレジットのオファーから好ましいオファーが選択され、該オファーが、Ｃｏｎｆｉｒｍａｔｉｏｎ Ｍａｎａｇｅｒ（確認マネージャ）サービスからユーザに対する応答の基本になる。
【００２４】
図２は、ウェブサービスをサポートできるネットワークを示している。図２の該ネットワークは、参照番号１０から３６で示される複数のノードからなる。ノードは部分的なメッシュで互いと相互接続されている。つまり、必ずしもあらゆるノードが他のすべてのノードとの直接的な接続を有するわけではない。この例の目的のために関心のあるネットワークの領域では、ノード１０が接続４０、４１、４２、４３及び４４を介して、それぞれノード１２、１４、１６、１８及び２０に接続されている。ノード２０は、さらにノード２６に接続され、該ノード２６自身はさらにノード２４に接続されている。ノード１８は、さらにそれぞれノード２２と２４に対する接続４５と４６を有する。ノード２４は、さらにノード３０に対する追加の接続４７を有する。次にノード３０は、同様に接続４８を介してノード２８に接続され、さらにノード２８と３２に接続されている。ノード２８は、さらにノード３４に接続されている。
【００２５】
本発明の第１の実施形態はここで、ノード１０を介してネットワークに接続できる前述のユーザに関して一例として説明される。ユーザはネットワークのリソースを使用してプロセスを構築することを希望している。ユーザは、ローカルノード１０に十分なリソースが存在しているかどうかを知らないため、ユーザは、多様なノード上のリソースの位置を突き止め、所望されるプロセスを提供するために適宜に結合できるようにするためにウェブサービスを呼び出す。これを行うために、ユーザは必要なサービスの位置を突き止めるために、ユーザのローカルノード１０においてサーチプロセスを呼び出す。典型的なサービスは、例えば、ソフトウェア、データまたはコンピュータハードウェアの形であってもよい。ここでウェブサービスを使用することは１つの可能性にすぎない。代替実施形態では、ユーザは、サーチプロセスを開始するために、典型的にはＪＡＶＡ（登録商標）等の言語で作成されているローカルアプリケーションインタフェースにアクセスする場合もあり、サーチプロセスはその後ピアツーピア機構を通して先に進められる可能性がある。さらなる代替実施形態では、ユーザはウェブポータルにアクセスし、サーチを開始するためにサーチポートレットを使用する場合もある。
【００２６】
第１の実施形態によると、ネットワーク内の各ノードは周知のポート上でリスン（listen）し、照会に応答するプロセスを実行する。また、このプロセスは該ノード上で現在使用可能なすべてのサービスのリストを維持する、あるいは取得することができる。これは、該ノード上で実行されている（つまりアクティブである）ソフトウェアサービス、及び実行されていない（つまりイナクティブである）が、所望される場合には該ノード上で起動できるソフトウェアサービスを含む。これは、該ノードには存在していないが、アクセスすることができ、該ノード上にインストールされ得るデータまたはソフトウェアも含んでもよい。
【００２７】
さらなる実施形態によれば、コンピュータネットワークの場合、スケジューリングプロセスがノード機能説明にアクセスできる。この１例は、グリッドサービススケジューリングプロセスである。このプロセスはまた、各ノードのネットワーク近傍も認識し、該近傍に対してメッセージを送信できる。該プロセスは、後述されるようにエコーディスカバリーに関与する。
【００２８】
プロセスは、頂点がコンポーネントサービスであり、コンポーネントサービスを接続する孤が依存関係または相互関係を反映する（例えば、図５を参照）グラフとして考えられ、表現されることができる。例えば、順番に実行されなければならず、一のサービスの出力が次のサービスの入力になることによりおそらく制約されている一連のサービスを考えてみる（並列実行や選択肢等の他の構造も見つけられ得る）。スケジューラは性能及び費用の制限事項を満たすためにプロセス定義から実行可能なプロセスのインスタンスを生成することに関与する。スケジューラは、ユーザが該ユーザのローカルノード内のローカルサーチプロセスに対して、所望されているプロセスの定義を供給するときに、該ユーザによって起動される。該プロセスのインスタンスを生成するために、スケジューラはシーケンスの１番めのサービスに対するサーチを開始する。これは、ノード１０を中心とする拡大する円５０により、図３に描かれている。これらの円は、１番めのサービスを提供する能力を備えた十分なノードの位置が突き止められるまで、ノード１０から、より遠くのノードまで広がるサーチを表している。それぞれの１番めのサービスは「第１の」ノードに位置している。図３に示されているように、第１のノードの２つの候補１４と２４はサーチの第１の段階の結果として位置を突き止められる。ノード１４は接続４１を介してノード１０に直接的に接続されている。ノード２４はノード１８及び接続４３と４６を介してノード１０に接続されている。
【００２９】
さらなる好ましい実施形態によれば、このサーチには有界エコー（bounded echo）が使用される。有界エコーは、最初に制限された領域の中のネットワークノードをサーチし、該領域は、定められた数の適切なサービスが発見されるまで拡大する。
【００３０】
発見されたノードの特徴及びこれらのノードに対する接続性（つまり、ノード１４に対する接続４１、及びノード１８を介し、ノード２４に対する接続４３と４６）に関する情報は、ユーザのノード１０にあるスケジューラに返される。次にスケジューラはユーザによって供給される基準に基づいて、１番めのサービスを提供する可能性を有する１番めのサービスのインスタンスを提供する幾つかの（ショートリスト）のノードを選択する。シーケンスの２番めのサービスに対するサーチは、次に１番めのサービスのインスタンスを提供する選択された第１のノード１４と２４から遠隔で開始される。これは、選択された第１のノード２４を中心とする、拡大する円５２によって図３の中で表されている。多くの選択された「第１のノード」から複数のサーチが並列で発生する可能性があるが、ここでは明確にするためにただ１つの第２の段階のサーチだけが描かれている。２番めのサービスを提供できる複数の「第２のノード」の位置が突き止められる（明確にするために図３では１つの第２のノード３０だけしか示されていない）。発見された「第２の」ノード、つまりシーケンスの２番めのサービスを提供する可能性を有するノードの特徴がスケジューラに返される。１番めのサービスを提供できるノードと、２番めのサービスを提供できるノード間の接続性に関する情報もスケジューラにも返され、スケジューラは次に第２のノードのショートリストを選択する。３番めのサービスに対するサーチも同様に、つまり２番めのサービスのインスタンスを提供する選択されたノードから開始される。これは、選択された第２のノード３０を中心とする、拡大する円５４により図３に表されている。この段階で、並列に発生していることがある他のサーチは明確にするために示されていない。図３の例では、３番めのサービスを提供できる複数の「第３のノード」の位置が突き止められる（明確にするために１つの第３のノード３６しか示されていない）。同様に、所望される４番めのサービス、５番めのサービス等を提供できる多くの第４のノード、第５のノード等の位置が、必要に応じて以後の段階で突き止められる（不図示）。このプロセスは、シーケンスの中の各サービスのインスタンスを提供する十分な数のノードが検出されるまで繰り返される。
【００３１】
図４は、図３のネットワークの一部を示し、図３のサーチをさらに明確に描くためにサーチの結果として選択されたノードだけが示されている。図４では、矢印４９がユーザノード１０と選択された第１のノード２４との間のリンクを表す。
【００３２】
本発明のさらなる好ましい実施形態によると、スケジューラは、図５に示されているように、頂点（１０）からの反対の先端（例えば８２）までの各経路がプロセスを実行可能なインスタンスを表すグラフを構築できる。性能及び負担に関するデータは、グラフの各頂点（サービス６０から８４）及び孤（ネットワーク接続１００から１２６）と関連付けられている。ユーザノード１０は、ネットワーク接続１００、１０２によって１番めのサービス６０、６２に接続されている。１番めのサービス６０は、それぞれネットワーク接続１１０、１１２、及び１１４によって２番めのサービス７０、７２、７４に接続されている。１番めのサービス６２はそれぞれネットワーク接続１１６と１１８によって２番めのサービス７４、７６に接続されている。２番めのサービス７０は、ネットワーク接続１２０によって３番めのサービス８０に接続されている。２番めのサービス７２は、ネットワーク接続１２２によって３番めのサービス８２に接続されている。第３段階のサーチの結果として、２番めのサービス７４と７６が、ともに同じ単一の３番めのサービス８４の位置を突き止めた。したがって、２番めのサービス７４と７６は、それぞれネットワーク接続１２４と１２６によって３番めのサービス８４に接続されている。通常、決定グラフは、すべての必要とされるサービス及び該サービスの相互接続のインスタンスがグラフに表されるまで、さらなるネットワーク接続を介して接続されるさらなるサービスインスタンスに拡張されるであろう。決定グラフを図３及び図４の例に関連づけるために、孤１００、１１０及び１２０がそれぞれリンク４９、４７及び４８に関連づけられ、サービス６０、７０及び８０がそれぞれノード２４、３０および３６に関連づけられるであろう。
【００３３】
スケジューラは、次に、各経路の頂点と孤に関連付けられた性能及び負担のデータに基づいて各経路の質を計算し、エンドユーザの制限事項を満足させるために最も適切な経路を選択する。さらなる好ましい実施形態によると、スケジューラは、発見の各段階において成功の見込みのない経路を取り除くことができる。例えば、１つの制限事項が、３つのサービスのシーケンスからなるプロセスが１０秒以内に実行できなければならず、ある経路に沿って１番めのサービスインスタンスを実行すると、２番めのサービスインスタンスまで伝搬し、２番めのサービスインスタンスを実行するのに１１秒を要する場合、該経路に沿って３番めのサービスのインスタンスのサーチを続行しても意味がない。
【００３４】
決定グラフ（ひいては、プロセスを実現するためのサービスインスタンス及び接続の構成）を通る経路を選ぶ上で考慮に入れられる可能性がある負担は、接続帯域幅、サービスインスタンスの近接性、サービス間でデータを転送するネットワーク負担、リソースを使用する財務費用、リソースの可用性、リソースの所有権、セキュリティ、及び処理される情報に対する未許可のアクセスを防止したいという願望を含むが、これらに限定されない。
【００３５】
いったん最適構成が選択されると、さらなる好ましい実施形態によると、該構成は、ユーザを要求されるサービスにリンクし、これらのサービス間の関係性を確立し、その間にデータの流れを構築するするオーバレイネットワークによって、実現される。
【００３６】
本発明のさらなる実施形態によると、適切な品質測定基準を有するサービスのシーケンスに対する要求が生成される。必要とされるサービスの１つを提供する各ノードが発見されると、該ノードはスケジューラに戻ることなくシーケンスの中で次のサービスに対する有界エコーサーチを開始する。エコーアルゴリズムは次に結果を集約し、サービスインスタンスの順序付きリストを、各測定基準に対するリストの性能とともにスケジューラに返す。集約は各ノードに存在するエコーデーモンによって実行される。エコーデーモンは、該エコーデーモンが伝搬させたすべてのアクティブなサーチを記録に残し、返された結果を集約する。エコーデーモンは、エコーパターンに含まれるすべての通信に関与する。システム内のあらゆるノードは、エコーデーモンの一部として実行されるソフトウェアプロセスを有し、該ソフトウェアプロセスは標準的な通信ポートでエコーメッセージをリッスン(listen)する。該デーモンは、メッセージがサーチであるのか、あるいはエコーであるのかを認識する。該メッセージがサーチである場合、該デーモンは必要とされるサービスがないか局所的にチェックし、必要であれば、メッセージ発信元を除く該ノードの近傍に該サーチメッセージを渡す。該サーチメッセージを渡す前に、デーモンは、該サーチのさらなる伝搬が許されるかどうかを確かめるためにホップカウントをチェックする。ホップカウントは、サーチが伝搬されるたびに増分される単純な数値カウントであり、サーチ領域の範囲を制限するために、つまり有界サーチを提供するために使用される。ホップカウントはゼロで開始する。ノードがサーチメッセージを転送するたびに、ホップカウントは増分される。ノードは、ホップカウントが所定の制限未満である場合にだけサーチメッセージを転送する。ホップカウントが該制限に等しい場合、アルゴリズムの拡大段階は終了し、ノードは要求元ノードにサーチに関する情報を返す。
【００３７】
エコーデーモンはその近傍のリストを維持し、周期的に該リストを更新する。サーチに対する応答が返されると、デーモンは集約プロセスを管理し、収集された応答をサーチ発信元に返す。カスタマがサーチを開始するとき、カスタマがサーチを設定し、ローカルノード上のエコーデーモンから発行される第1のサーチメッセージを生成できるようにするグラフィックインタフェースにカスタマがアクセスできることが好ましい。
【００３８】
この実施形態は特に、（例えば、選択肢、並列実行等を含む）さらに複雑な同期を有する構造よりむしろシーケンスをみつけるのに適している。これらの、さらなる２つの実施形態は、さらに複雑な状況においてはスケジューラがサーチを明示的に指示し、他の状況ではエコーデーモンによる集約に依存する実施形態において結合され得る。
【００３９】
好ましい実施形態によると、初期のプロセス設計は、図１に描かれているように、プロセスのグラフィック表現を可能にする統合開発ツールを使用して実施される。ＷＤＳＬに基づいた該表現はオラクル（Oracle）のＢＰＥＬデザイナーまたは他の市販されているツールを使用して生成されることができ、一例として前述されたローン申請について示されている。同じ情報は、例えばＸＭＬベースのファイルで入手でき、ＸＭＬベースのファイルにおいてはパートナー・リンクと、オーケストレーションロジックが、コンポーネントサービスの識別情報とフローにおける順序付けを記述する。
【数１】
【００４０】
要求者から入力を受け取る−これがこのフローを開始するものである。私たちはローン申請ビジネス文書を渡される。
【数２】
【００４１】
同期ｃｒｅｄｉｔＲａｔｉｎｇＳｅｒｖｉｃｅを呼び出す。ｃｒｅｄｉｔＲａｔｉｎｇＳｅｒｖｉｃｅからの障害を処理する範囲を明確にし、私たちがクレジット格付けを受け取ると、ローン申請ビジネス文書にクレジット格付けを設定する。ＮｅｇａｔｉｖｅＣｒｅｄｉｔの例外の場合には、格付けを−１０００に設定する。
【数３】
【００４２】
これは、サービス発見プロセスに対する入力として使用される構造化されたサーチ文字列を提供する。クライアントノードは、必要とされる１番めのサービス、前述の例の中ではユーザのローン申請者の社会保険番号（ＳＳＮ）の取り出しを可能にするサービスに対する有界エコーサーチを開始する。サーチにより返されるインスタンスの数は設定可能であり、返される数を少なくするほど、サーチ及びスケジューリングは高速化し、容易になるが、より有利な解決策が見失われる可能性がある。いったん１番めのサービスが特定されると、社会保険番号を供給するノードから第２の一連の有界エコースキャンが始まり、このサーチはクレジット格付け取得サービスを探す。
【００４３】
有利なことにサービス発見に対するこの手法は、それぞれがプロセスの実行可能なインスタンス化である一連のトレースの出力を生じさせる。これは再び、図５に示されているような決定グラフに類似する形式で表すことができる。図５では、グラフを通る各経路が、プロセスのインスタンスを生成するために必要なサービスに対して確立された接続性及び近接性を表し、それにより最も適切な組み合わせまたは経路を選択可能にするために必要とされる情報の量を削減する。
【００４４】
さらなる好ましい実施形態によると、グラフの中のノード及びネットワークリンクに識別情報及び負担情報を追加することを含むさらなる改良が導入され、これにより、グラフを通過する最低負担の経路を検出するかなり簡略な方法で、最善の組み合わせを特定できる。グラフにラベルを付けるために使用される負担測定基準は、例えば使用可能なコンピューティングリソース、サービスがすでに存在している場合にはサービスの性能、開始されなければならないサービスのロードに要する時間（time-to-load）、及びネットワークリンクの接続性能に関するものであり得る。ラベルをグラフに付加すると、グラフ構築時に、グラフから余分なものを取り除くプロセスが容易になり、さらにスケジューリングプロセスが簡略化する。
【００４５】
前述された発見及びスケジューリングのプロセスの一部に対するシーケンス図が図６に示されている。図６は統一モデリング言語（ＵＭＬ）―オブジェクトマネージメントグループ社（Object Management Group, Inc.）の登録商標―を使用する。
【００４６】
図６は、発見プロセスの重要な特長のいくつかを強調する簡略化されたＵＭＬシーケンス図を示している。時間は左上角で開始し、図の下方に進み、上部に沿ったボックスのそれぞれ（：Ａｐｐｌｉｃａｔｉｏｎ Ｓｃｈｅｄｕｌｅ、：ｌｏｃａｌ ｅｃｈｏｄ、：ｒｅｍｏｔｅ ｅｃｈｏｄ、：ｒｅｍｏｔｅ ｅｃｈｏｄ２、：ｒｍｏｔｅ ｅｃｈｏｄ３）が関数を表している。エコーサーチのケースではこれらの関数のそれぞれが別々のノードで実行されている。エコーサーチ関数（：ｌｏｃａｌ ｅｃｈｏｄ、：ｒｅｍｏｔｅ ｅｃｈｏｄ、：ｒｅｍｏｔｅ ｅｃｈｏｄ２；：ｒｅｏｔｅ ｅｃｈｏｄ３）はサーチ要求を処理する、つまりサーチ要求メッセージを受け入れ、該サーチ要求メッセージに従ってローカルノードを照会し、該サーチ要求を以後のノードに渡し、及び要求元スケジューラに結果を返すコードの部分である。各エコーサーチ関数は、該関数が存在するノードに対するすべてのローカル接続の詳細、及びすべての有効なサーチ要求の要求元を有する。
【００４７】
カスタマが実行してほしいプロセスのためのタスクシーケンス、及び関連するサービスの質の測定基準をカスタマが供給するための１つの方法は、ワークフローを提供することである。ワークフローはタスク、プロシージャステップ、関与している組織または人、必要とされる入出力情報、及びビジネスプロセスの各ステップに必要とされるツールを記述するために使用される用語である。ワークフローはこのようなプロセスを管理、監視するために電子システムを使用するＩＴ技術である。ワークフローは、例えばネットワーク内コンピュータ間でのデータの転送として実現されるような、個人及び／または部門の間での作業の流れを定義し、追跡できるようにする。
【００４８】
図６に描かれているシーケンスは以下の通りである。
【００４９】
潜在的なカスタマが必要とされるワークフローを供給すると、スケジューリングタスク（関数：Ａｐｐｌｉｃａｔｉｏｎ Ｓｃｈｅｄｕｌｅ）を処理するためにアプリケーションスケジューラが作成される。スケジューラは、ユーザが該ユーザのローカルノードでローカルサーチ関数にワークフロー定義を供給するときに、該ユーザによって起動される。プロセスを分析、管理するためのワークフロー手法は、文書及びデータに注目する傾向があるオブジェクト指向プログラミング手法と結合することができる。一般的には、ワークフロー管理は文書よりむしろプロセスに注目する。市販されているワークフロー自動化製品によって、組織がワークフローモデルとオンライン書式等のコンポーネントを作成すると、一貫した作業の処理を管理し、実行するための方法として該製品を使用できるようになる。
【００５０】
アプリケーションスケジューラは、ローカルエコーサーチ関数を照会すること（メッセージ「サーチを開始」）によってローカルノード上のワークフローの第１のコンポーネントを探す（関数：ｌｏｃａｌ ｅｃｈｏｄ）。ローカルエコーサーチ関数はローカルノードを試験し（関数：ｌｏｃａｌ ｅｃｈｏｄの下の矢印「ローカルチェック」を参照すること）、必要とされるコンポーネントが存在していない場合には、ローカルエコーサーチ関数は該サーチを該関数の存在するノードの近傍のエコーサーチ関数（つまり、関数：ｒｅｍｏｔｅ ｅｃｈｏｄ１）に転送する（メッセージ「サーチを伝搬」を参照すること）。各近傍のエコーサーチ関数は次に該関数のローカルノードをサーチする（関数：ｒｅｍｏｔｅ ｅｃｈｏｄ１の下の矢印「ローカルチェック」を参照すること）。所望されるサービスがローカルノードで検出されない場合、該サーチは該近傍の近傍のエコーサーチ関数に転送される（ｒｅｍｏｔｅ ｅｃｈｏｄ１関数からｒｅｍｏｔｅ ｅｃｈｏｄ２関数に送信されるメッセージ「サーチを伝搬」）。本実施の形態では、ｒｅｍｏｔｅ ｅｃｈｏｄ２サーチ関数は該関数のローカルノード上で１番めのサービス（つまりワークフローコンポーネント）の位置を突き止め、アプリケーションスケジューラに正の応答（不図示）を返す。該正の応答はエコーチェーンを通して送り返されてもよいし、あるいは発信側アプリケーションスケジューラに直接的に渡されてもよい。
【００５１】
アプリケーションスケジューラは１番めのサービスの位置を示す正の応答を受け取ると、該アプリケーションスケジューラは、サーチに成功したサーチ関数（：ｒｅｍｏｔｅ ｅｃｈｏｄ２）に、サーチされたワークフローコンポーネントの負担について問い合わせるステータスチェック要求（メッセージ「現在ステータスを要求」）を送信する。該成功した関数はこの値を、スケジューリング決定グラフが構築されているアプリケーションスケジューラに返す（：ｒｅｍｏｔｅ ｅｃｈｏｄ２から：Ａｐｐｌｉｃａｔｉｏｎ Ｓｃｈｅｄｕｌｅｒへのメッセージ「ステータスをスケジューラに返す」）。次にアプリケーションスケジューラは１番めのサービスのインスタンスのある、すべてのサーチが成功した位置から次のサービスに対するサーチを開始する（：Ａｐｐｌｉｃａｔｉｏｎ Ｓｃｈｅｄｕｌｅｒから：ｒｅｍｏｔｅ ｅｃｈｏｄ２へのメッセージ「サーチを開始」）。このプロセスは、すべての必要とされるサービスの位置が無事に突き止められ、該サービスのステータスが判断されるまで続行する。さらなる好ましい実施形態では、スケジューリング決定グラフが構築されると、アプリケーションスケジューラはサイトの潜在的な重複がないか周期的にチェックし、これによりスケジューリング決定グラフをから余分なものを取り除く。すべてのコンポーネントの位置が突き止められると、アプリケーションスケジューラはスケジューリング決定グラフを処理し、接続されているサービスの最適配置をユーザに返す。
【００５２】
さらなる実施形態によると、本発明は並列処理プロセスの構築に対応する。並列手法の使用は種々の方法で適応され得る。例えば、グリッドのためのスケジューラは、並列処理を含む要求を受け入れ、次に分散を処理するグリッドサービスインタフェースを公開してもよい。あるいは、並列実行は、あるサービスの出力が複数の同一のサービスの入力に送信されるワークフロー記述に含まれることもできる。
【００５３】
グリッドコンピューティングは、特に科学研究における並列処理に広範囲に使用される。しかしながら、グリッドコンピューティングは、科学的なアプリケーションほど多くの並列性を必要としないビジネスアプリケーションにも適用できる。本発明は、ウェブサービスまたはグリッドサービス使用されるものであればどの分野にでも適用され得る。本発明のさらなる優位点は、本発明によってスケジューラが二段階サーチを実施できるという点である。従来のウェブサービスは既存のサービスしか使用しない。有利なことに、本発明によれば、スケジューラはプロセス要件を満たすために適切なノードでサービスを開始することも検討できる。これは、ノード上に存在するが、実行されていないサービスを開始することと、インストールできる適切なサービスコードダウンロードし、実行することの両方を含む。オンデマンドでインストールを可能にする適切なソフトウェアプロビジョニングシステムには、グリッドコンピューティング及びＣＯＲＢＡ（共通オブジェクトブローカーアーキテクチャ）が含まれる。新たな範囲の仮想化及びサーバ自動化ソフトウェアは、本発明とともに使用するのに適して、同様にオンデマンドでのインスタンス生成を可能にすることが期待される。
【００５４】
本発明は、集中ディレクトリをベースにした解決策よりさらに頑健な解決策を提供し、ネットワーク障害に直面しても、有利なことに動作を継続することができる。レジストリを使用するＵＤＤＩ等の従来の手法は、ディレクトリを含むネットワークの一部に到達できなくなると失敗する。本発明のサーチはユーザによって開始され、開始点に現在接続されているネットワークのすべての部分に到達するよう放射状に広がり、したがって、部分的なネットワーク障害があっても、完全なまたは部分的な進行を維持できるようにする。必要とされるサービスの位置と負担がスケジューラによって取得された後に、ネットワークの部分が故障すると、ネットワークの故障した領域内にあるいかなるサービスにも到達できなくなり、該サービスの使用は拒絶される。本発明のサーチプロセスは局所的な知識を使用するため、ネットワークに関する問題の結果としてアクセスが拒絶されるあらゆるサービスの代わりのインスタンスの位置を突き止めるために、第２のサーチがただちに開始され得る。有利なことに、第２のサーチは、本質的に、依然として要求元ノードに接続されているノードからデータを収集するにすぎない。
【００５５】
さらなる好ましい実施形態によると、元のサーチの間に見つけられたが、使用のために選択されなかった代替サービスの位置が、このようなネットワーク問題が発生するのに備えて記憶される。これにより、部分的なネットワーク障害の場合には、ネットワークは使用可能な可動サービスに迅速に切り替わることができる。最上位レベルに中心的なサービスがないことにより回復力がさらに強化され得る。スケジューリングプロセスが集中化されると、一つのプロセスの障害が致命的となるであろう。好ましい実施形態に従って、各スケジューラは、依然として動作できる他のすべてに悪影響を及ぼさずに、失敗する可能性のある１つのプロセスだけに関与する。したがって、該システムは複数のレベルで回復力があり、最高レベルに集中サービスがないことが障害の影響を制限し、複数の適切なサービスの位置を、例えば選択グラフの一部として記憶すれば、万一障害が発生した場合に迅速な回復に役立つ。必要な場合には、潜在的に古いディレクトリルックアップに依存するのでなく動的な発見を使用して、最新の情報が収集される。発見された情報は、発見プロセスの間にフィルタリングされることができ、これにより、考慮され得る検討の対象の構成の範囲が、受け入れられる可能が高い最も構成に制限される。また、発見された情報は、サービス性能に関する情報を関連するネットワーク性能に暗に結合する。これは、低速ネットワークリンクを介して多くのデータ量を通信する必要がある高性能ウェブサービスと、同等であるが、ローカルコンピュータで使用可能なより低速のプロセスを用いる高性能ウェブサービス（つまり低速ネットワークリンクを回避する）のような２つの高性能ウェブサービスを比較する際に有効であり得る。本発明はこのような問題に対処する、単純で分散された方法を提供する。
【００５６】
さらなる実施形態によると、ビデオオンデマンドプロセスを構成され得る。ビデオオンデマンドサービスは、カスタマがビデオの名前及び配信先アドレスを指定する（これはユーザとのやり取りなしにバックグラウンドで自動的に取得されてもよい）ことにより自ら開始する、単純な２段階ワークフローとして表されることができるビデオサービスと配信サービスからなることができる。エコーパターンの第１の段階は、要求されたビデオを供給できるビデオサーバを検出するように始まる。次にエコーサーチの第２の段階は適切な配信サービスを検出するように始まる。スケジューラはビデオに必要とされる質のレベルで、ビデオオンデマンドサービスを共に提供できるビデオ配信元とビデオ配信サービスとを選ぶ。
【００５７】
さらなる実施形態によると、本発明は以下をサポートするネットワークの構成に適用され得る。
【００５８】
・サードパーティ呼制御
サードパーティ呼制御は、アプリケーションによって開始される呼を作成、管理するために使用される。アプリケーション開発者はサードパーティ呼ウェブサービスを使用し、２つの終点のアドレス（または電話番号）を提供することにより呼処理機能を呼び出すことができる。適切なアプリケーションは、ビジーまたは、使用できない加入者のＰＳＴＮ回線への接続のどちらかで呼び出されるものである。これがどのように動作するのかを示す一例は、ユーザがＰＳＴＮ接続を利用してインターネットにダイアルアップしたときである。アプリケーションはこの信号を取り上げ、着呼者ユーザに、呼をボイスメールに送信するのか、呼を別の番号に転送するのか、あるいは呼を拒絶するのかの選択を与える。該ユーザによってなされる応答はネットワーク内で処理される。サーバは、特定の番号がダイアルされると必ずアプリケーションをトリガしてもよい。これは多くの既存のインテリジェントネットワークサービスの提供のために実行可能であろう。このようなサービスの使用の１つの例は、特定の株価を監視し、価格が閾値に達すると、クライアントアプリケーションは一人または複数のブローカーと該ブローカーに対応するカスタマの間でサードパーティ呼を呼び出し、これにより講じられる処置が決定される。
【００５９】
・ＳＭＳ
（ボイスメール、トラフィック、天候または他の情報レポート、あるいはｅ−メールメッセージ等の）外部刺激によってトリガされる（サードパーティプラットホームまたは社内アプリケーションプラットホームに常駐する）クライアントアプリケーション等のアプリケーションからＳＭＳメッセージを送信する方法。アプリケーションはＳＭＳウェブサービスを呼び出す。アプリケーションはメッセージ（テキストの文字列）及び着呼者ユーザの詳細を提供する。次に、ウェブサービスはモバイルＳＭＳ−Ｃにメッセージを着呼者ユーザに送信させるメッセージを呼び出すことができる。
【００６０】
・ＭＭＳ
マルチメディアメッセージがユーザに送信され、アプリケーションによってネットワークから取り出されるのを可能にする。アプリケーションはモバイルネットワークによって提供されるＭＭＳ機能を利用する。
【００６１】
本発明は、ネットワーク全体に渡って未知の方法で拡散される多様なサービスから、所望されるプロセスを効率的に構築できるようにする。サービスは、実行中であるか、インストールされているがイナクティブであるか、あるいはインストールを必要とするかのいずれかのソフトウェアと、インストールされているか、インストールを必要とするかいずれかのデータと、コンピュータ、ＰＤＡ及び携帯電話等のデバイスによって提供されて得る処理電力または記憶装置とを含むが、これらに限定されない多様なタイプであり得る。好ましい実施形態によれば、これは、最も適切なサービスインスタンス及び接続として高速決定を行うことを可能にする決定グラフの構築によって達成される。ユーザから広がるサーチ計画を利用することにより、本発明は本質的に、接続負担を最小限に抑える一方で速度を最適化する傾向がある。
【００６２】
本発明は、設定された順序で実行されなければならない一連のサービスを備えるプロセスに限定されるのではなく、並列実行及び、選択肢や決定を含むシーケンス等の他の構造にも等しく適用され得る。本発明は、ネットワークの特定の形式またはトポロジに限定されるのではなく、リング、ツリー、部分メッシュと完全メッシュ、及び電気的、光学的、または他の電磁的な媒体で実現される他のトポロジにも適用される。本発明は複数のネットワークを横切って分散されるサービスにも、その本質的な性格を変更することなく適用され得る。本発明は特定のタイプのサービスに限定されるのではなく、他の応用例の中でビジネスアプリケーション、通信サービス、製造システムに及ぶ。
【００６３】
略語
ＢＰＥＬ ビジネスプロセス実行言語
ＢＰＥＬ４ＷＳ ウェブサービス向けビジネスプロセス実行言語
ＨＴＴＰ ハイパーテキスト転送プロトコル
ＭＭＳ マルチメディアメッセージサービス
ＭＭＳ マルチメディアメッセージングサービス
ＯＡＳＩＳ 構造化情報標準促進団体
ＯＧＳＡ オープングリッドサービスアーキテクチャ
ＰＳＴＮ 公衆交換電話網
ＳＭＳ ショートメッセージングサービス
ＳＭＳ ショートメッセージサービス
ＳＯＡ サービス指向アーキテクチャ
ＳＯＡＰ シンプルオブジェクトアクセスプロトコル
ＳＳＮ 社会保険番号
ＵＤＤＩ ユニバーサルディスクリプション、ディスカバリー＆インテグレーション
ＵＭＬ 統一モデリング言語
ＷＳＤＬ ウェブサービス記述言語
ＸＭＬ 拡張マークアップ言語
【図面の簡単な説明】
【００６４】
【図１】フローチャート形式でプロセスを示す。
【図２】本発明を実現するためのネットワークを示す。
【図３】本発明の図４のネットワークにおける一連のサーチを描く。
【図４】本発明の図４のネットワークにおける一連のサーチを描く。
【図５】図３及び図４のサーチから導出される決定グラフを示す。
【図６】ＵＭＬ図として図３及び図４のサーチを示す。
【技術分野】
【０００１】
本発明はコンピュータネットワーク内でプロセスを構築するための方法、及び特にプロセスを提供する位置決め及びサービスの選択のための方法に関する。本発明は適切なネットワークにも及ぶ。
【背景技術】
【０００２】
ウェブサービスとは、ネットワーク上でサービスを公開（exposed）することができ、使用することができる方法を記述するために使用される語句である。ウェブサービスは、ソフトウェアが通信する方法に関する。ソフトウェアはパソコン上の単純なスクリプトからネットワークサーバ上のアプリケーション、メインフレームコンピュータで実行される大型の動作サポートシステムに至るまで多くの形で提供できる。これらのスクリプト、アプリケーション、及びソフトウェアシステムはソフトウェアコンポーネントの例である。ウェブサービスは、他のソフトウェアコンポーネントがウェブサービス自体を使用できるようにするソフトウェアコンポーネントに基づいている。
【発明の開示】
【０００３】
ソフトウェアコンポーネントがウェブサービスを提供できるようにするように配備するための多くの技術が成熟し、標準化されており、これらにはシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）、ウェブサービス記述言語（ＷＳＤＬ）、ユニバーサルディスクリプション、ディスカバリー＆インテグレーション（ＵＤＤＩ）が含まれる。
【０００４】
ウェブサービスはＷＳＤＬを使用して記述でき、ウェブサービスはＵＤＤＩを使用して位置を突き止めることができ、ウェブサービスの機能性をＳＯＡＰを使用して呼び出すことができる。これらの３つの技術は共通データ記述規格の拡張マークアップ言語（ＸＭＬ）の上に構築される。ＸＭＬはコンピュータメッセージの内容を定義するための標準的な仕様であり、あるソフトウェアコンポーネントと別のソフトウェアコンポーネントの間で送信されるメッセージの内容を表すための共通の方法を提供する。ソフトウェアアプリケーションがＸＭＬで該ソフトウェアアプリケーションの出力を書き込む場合、ＸＭＬを解釈できる別のアプリケーションが該出力を読み取り、該出力に対して作用できる。
【０００５】
ＳＯＡＰは、あるソフトウェアコンポーネントが別のソフトウェアコンポーネントの機能を、該２つのソフトウェアコンポーネント間のメッセージパッシングを呼び出しの手段として使用して呼び出すことができる手段を提供する。ＳＯＡＰの仕様はＷ３Ｃによって管理されている世界的な規格であり、現在は２００４年６月にＷ３Ｃによって発行されたバージョン１．２であり、http://www.w3.org/TR/SOAPまたはhttp://www.w3.org/TR/2003/REC-soap12-part0-20030624でアーカイブとして入手できる。ＳＯＡＰは要求−応答機構を使用し、該機構では、あるソフトウェアコンポーネントが別のソフトウェアコンポーネントに対して要求を行うと、該別のコンポーネントが応答する。要求と応答の両方ともＸＭＬドキュメントの形で送信される。
【０００６】
ＸＭＬ及びＳＯＡＰは、ＨＴＴＰとともに、あるソフトウェアコンポーネントがインターネット上で別のソフトウェアコンポーネントの機能を呼び出すための手段を提供する。これらの技術は、ＨＴＴＰをサポートする任意のネットワーク上でソフトウェアコンポーネントを統合するために使用できる。この統合を実施するためには、以下の情報も必要とされる。
【０００７】
・すべての使用可能な機能に関する、該機能の呼び出しパラメータを含む情報
・値指定を含む、すべてのＸＭＬメッセージについてのデータタイプ情報
・使用される特定の送信プロトコルについてのバインディング情報
・指定されたサービスの位置を突き止めるためのアドレス情報
ＷＳＤＬファイルは、ソフトウェアコンポーネントについて上記に一覧表示した情報を提供するＸＭＬドキュメントである。ソフトウェアコンポーネントは、ＷＳＤＬを使用してウェブサービスの使用可能な機能のいずれとも統合され得る。ＷＳＤＬを認知するツールを用いると、このプロセスを完全に自動化することができ、アプリケーションは、ほとんどまたはまったく手動コードを使わずに新しいサービスと容易に統合され得る。ＷＳＤＬはhttp://www.w3.org/TR/wsdlで、またはhttp://www.w3.org/TR/2001/NOTE-wsdl-20010315でアーカイブとして定義されている。
【０００８】
ウェブサービスは、通信機能、及びサービスアプリケーションとビジネスアプリケーションの提供を含む広範囲に適用される。アプリケーションを作成するときには、種々の供給元、例えば異なる会社によって供給される多くのソフトウェアコンポーネントの長所を評価することが望ましい場合がある。ＵＤＤＩはウェブサービスのレジストリを作成するための手段を利用可能にすることによって基本的なウェブサービス技術にこの拡張を提供する。これにより、ウェブサービスはインターネット上で互いと取引を行う会社の領域に入る。ＵＤＤＩの仕様は、会社が迅速に、容易に、且つ動的に互いを検出し、互いと取引を行うことを可能にする。ＵＤＤＩは、会社が以下を行うことができるようにする。
【０００９】
・会社のサービスを説明する
・サービスを提供する他の会社を発見する
・これらの他のサービスと統合する
ＵＤＤＩレジストリは、所望される機能を検出するために使用できる。レジストリに対する要求は特定の機能に対するものであり、費用制限、セキュリティニーズ、性能基準等の他の要件を含んでもよい。次に、レジストリはこのような機能を提供する１つまたは複数の会社を提案し、供給業者の選択を可能にする。ＵＤＤＩの仕様は、例えば、企業及び該企業が提供するサービスについての情報を含むレジストリの作成及び使用を可能にする。ＵＤＤＩの仕様は、構造化情報標準促進団体（ＯＡＳＩＳ）により管理されており、http://uddi.orgで入手できる。
【００１０】
ＵＤＤＩレジストリに加えて、公に利用可能なウェブサービスのリストがある。
【００１１】
ウェブサービスは通信ネットワーク内にアプリケーションも有する、つまりネットワーク機能をソフトウェアサービスとして公開する。通信サービスプロバイダは、ウェブサービスを使用して、ソフトウェア技術とネットワーク技術の組み合わせの利点を活用することができる。例えば、ビデオオンデマンドのウェブサービスは（ビデオストリーム自体をウェブサービスとして提示してもよい）該ビデオストリームを配信する通信サービスを活用することができる。
【００１２】
グリッドコンピューティングは、通常は、より低い価格／性能比でではあるが、単一の大型メインフレームまたはスーパーコンピュータに一般的に関連付けられたサービスの質を提供するために、複数のシステム全体でのリソースのプーリング(pooling)、及び要求に応じた該リソースの割り当てを可能にする。グリッドコンピューティングは、アプリケーションがリソースの割り当てを要求できるリソースアクセスのフレームワークを作成することにより機能する。これらのリソースは、要求するアプリケーションによって使用され、後に解放される。グリッド環境は本質的に分散されており、外部組織のシステムを含んでもよい。
【００１３】
グリッド実現例は、通常、米国政府により後援され、グローバス（Globus）として知られ、ソースコードが公開され、http://www.globus.org/で入手可能なツールキットを使用して構築される。該ツールキットのウェブサービスへの適合性は、分散リソースから作成されるサービスを作成、終了、管理及び呼び出すためのウェブサービスの集合を定義するオープングリッドサービスアーキテクチャ（ＯＧＳＡ）として知られている提案規格であって、http://www.globus.org/ogsa/で入手可能なものにより強化される。
【００１４】
ＯＧＳＡの使用により、任意のウェブサービスに基づいたプラットホームが、電話会議の構築からデータの大規模操作に至るであろう特定の機能を実現するための一時的なサービスを作成することが可能になる。これらのサービス自体が、アクセスを容易にするために可能にされたウェブサービスであろう。
【００１５】
ここでは、ユーザアクセスサービスは、サービス指向アーキテクチャ（ＳＯＡ）を通して提供される。これらのサービスは、実際には、アプリケーションサーバカーネル上に構築されるアプリケーションによって実現されるが、該アプリケーションサーバカーネルは、そのリソースの使用を共有するためにグリッドプロトコルを活用する。使用可能なあらゆる余分なリソースは、やはりＳＯＡを通してアクセス可能なＯＧＳＡ呼び出しを通してオンデマンドサービスを作成するためにまとめることができる。したがって、実際のカスタマの経験はＳＯＡを通して制御される恒久的なサービスと一時的なサービスの集合体から作られる。
【００１６】
ビジネスプロセスの管理を可能にする技術解決策には、領域の専門家による多大な関心がある。重要な目標は、ビジネス要求を、支援するＩＴシステムを指定するために使用できる用語に変換する必要性を排除することである。このような変換は、一般的には多大な時間を必要とし、信頼できない。関連する業界の成果には、サービス指向アーキテクチャ（ＳＯＡ）が含まれ、該ＳＯＡではグラフィック開発環境におけるサービスコンポーネントから、アプリケーションが組み合わされて、ビジネスプロセスの機能仕様が作成される。該ＳＯＡの実施例として、オラクル社によって最近のリリースされたビジネスプロセス実行言語（ＢＰＥＬ）デザイナーアプリケーションプロトタイプが挙げられ、ここでは、アプリケーションの構造を記述するためにウェブサービス向けビジネスプロセス実行言語（ＢＰＥＬ４ＷＳ）が使用される。これは、ビジネスプロセスを記述、指定するための標準化されたシンタックス及びセマンティクスの例である。その結果、ソフトウェアツールはビジネスプロセス管理をサポートするための仕様を使用できる。
【００１７】
このような抽象的なプロセス記述を与えられている場合の主要な技術的な問題は、所望されるレベルの性能の具体的な実現例をどのようにして構築するかである。プロセスがウェブサービスの集合から構成されていると仮定すると、１つの手法はビジネスプロセスで必要とされるサービスのインスタンスを見つけるために（例えば、ＵＤＤＩ-ユニバーサルディスクリプション、ディスカバリ＆インテグレーションプロトコルを使用して）ディレクトリの集合を照会することであろう。該ディレクトリは、プロセス仕様により必要とされるすべてのサービスのインスタンスを見つけるために照会されるであろう。グリッドサービスが使用されている場合には、該ディレクトリは必要とされるサービスのインスタンスを生成する適切なノードに照会することもできるであろう。
【００１８】
この手法は独立したサービスからなるビジネスプロセスにとっては妥当である。この場合、各サービスインスタンスは、該サービスインスタンスの個々の性能特性に基づいて別々に選択できる。さらに複雑な状況では、プロセスは、１以上のサービスの結果であって、別のサービスに対する入力として提供されるべきものであり、したがって該別のサービスは、先行するサービスが完了するまで先に進むことができないものを要求する。プロセスの提供は、より低速の「ボトルネック」サービスを含むことにより効率が悪化する場合がある。加えて、サービス間で相当量のデータを転送しなければならない場合、サービスインスタンス間のネットワーク接続性の特徴が、所望されるプロセスの性能に悪影響を及ぼすこともある。
【００１９】
残念なことにウェブサービスディレクトリで使用できる情報は、典型的には、いずれのサービスについても相対的な位置や現在の性能を含んでいない。複雑なプロセスの場合、あるいは一般的に入手可能なサービスのインスタンスの幅広い選択肢がある場合には、考えられる構成が多数ある。これらのどれが所望されるサービスの質を満たすことができるのかを決定するには、はるかに多くの情報の収集及び複雑な最適化が必要になる。つまり通常は多大な作業が必要になる。
【００２０】
本発明は請求項１に述べられているような方法を提供することによって前述の問題を回避する。本発明は請求項２０に述べられているようなネットワークも提供する。
【００２１】
本発明の実施形態は、ここで例証として図面を参照して説明される。
【発明を実施するための最良の形態】
【００２２】
本発明の第１の実施形態はここでウェブサービスをサポートするネットワークにアクセスするユーザに関して一例として説明される。ユーザは、ネットワークのリソースを使用してプロセスを構築することを希望している。
【００２３】
図１は、クレジットアプリケーションに関する単純なプロセスの一部のフローチャート表現を示し、該クレジットアプリケーションは、ここでボックスにより表現されている一連のサービスを使用することを必要とする一連の段階で実行される。該プロセスは、ローンを求めている申請者を有するユーザからのローンのための見積もりに対する要求を受け取ることで開始する。第１のステップは、申請者によって供給される識別情報に基づいてローン申請者の社会保険番号（ＳＳＮ）を取得することであり、このタスクサービスのためにＲｅｔｒｉｅｖｅ ＳＳＮ（ＳＳＮ検索）が選択される。社会保険番号がいったん取得されると、申請者のＳＳＮで特定されるローン申請者のクレジット格付けが、Ｇｅｔ Ｃｒｅｄｉｔ Ｒａｔｉｎｇ（クレジット格付け取得）サービスを使用して取得される。いったんクレジット格付けが取得されると、Ｃｏｌｌｅｃｔ Ｏｆｆｅｒｓ（オファー収集）サービスを使用してクレジットのオファーが捜し出される。受信されたクレジットのオファーから好ましいオファーが選択され、該オファーが、Ｃｏｎｆｉｒｍａｔｉｏｎ Ｍａｎａｇｅｒ（確認マネージャ）サービスからユーザに対する応答の基本になる。
【００２４】
図２は、ウェブサービスをサポートできるネットワークを示している。図２の該ネットワークは、参照番号１０から３６で示される複数のノードからなる。ノードは部分的なメッシュで互いと相互接続されている。つまり、必ずしもあらゆるノードが他のすべてのノードとの直接的な接続を有するわけではない。この例の目的のために関心のあるネットワークの領域では、ノード１０が接続４０、４１、４２、４３及び４４を介して、それぞれノード１２、１４、１６、１８及び２０に接続されている。ノード２０は、さらにノード２６に接続され、該ノード２６自身はさらにノード２４に接続されている。ノード１８は、さらにそれぞれノード２２と２４に対する接続４５と４６を有する。ノード２４は、さらにノード３０に対する追加の接続４７を有する。次にノード３０は、同様に接続４８を介してノード２８に接続され、さらにノード２８と３２に接続されている。ノード２８は、さらにノード３４に接続されている。
【００２５】
本発明の第１の実施形態はここで、ノード１０を介してネットワークに接続できる前述のユーザに関して一例として説明される。ユーザはネットワークのリソースを使用してプロセスを構築することを希望している。ユーザは、ローカルノード１０に十分なリソースが存在しているかどうかを知らないため、ユーザは、多様なノード上のリソースの位置を突き止め、所望されるプロセスを提供するために適宜に結合できるようにするためにウェブサービスを呼び出す。これを行うために、ユーザは必要なサービスの位置を突き止めるために、ユーザのローカルノード１０においてサーチプロセスを呼び出す。典型的なサービスは、例えば、ソフトウェア、データまたはコンピュータハードウェアの形であってもよい。ここでウェブサービスを使用することは１つの可能性にすぎない。代替実施形態では、ユーザは、サーチプロセスを開始するために、典型的にはＪＡＶＡ（登録商標）等の言語で作成されているローカルアプリケーションインタフェースにアクセスする場合もあり、サーチプロセスはその後ピアツーピア機構を通して先に進められる可能性がある。さらなる代替実施形態では、ユーザはウェブポータルにアクセスし、サーチを開始するためにサーチポートレットを使用する場合もある。
【００２６】
第１の実施形態によると、ネットワーク内の各ノードは周知のポート上でリスン（listen）し、照会に応答するプロセスを実行する。また、このプロセスは該ノード上で現在使用可能なすべてのサービスのリストを維持する、あるいは取得することができる。これは、該ノード上で実行されている（つまりアクティブである）ソフトウェアサービス、及び実行されていない（つまりイナクティブである）が、所望される場合には該ノード上で起動できるソフトウェアサービスを含む。これは、該ノードには存在していないが、アクセスすることができ、該ノード上にインストールされ得るデータまたはソフトウェアも含んでもよい。
【００２７】
さらなる実施形態によれば、コンピュータネットワークの場合、スケジューリングプロセスがノード機能説明にアクセスできる。この１例は、グリッドサービススケジューリングプロセスである。このプロセスはまた、各ノードのネットワーク近傍も認識し、該近傍に対してメッセージを送信できる。該プロセスは、後述されるようにエコーディスカバリーに関与する。
【００２８】
プロセスは、頂点がコンポーネントサービスであり、コンポーネントサービスを接続する孤が依存関係または相互関係を反映する（例えば、図５を参照）グラフとして考えられ、表現されることができる。例えば、順番に実行されなければならず、一のサービスの出力が次のサービスの入力になることによりおそらく制約されている一連のサービスを考えてみる（並列実行や選択肢等の他の構造も見つけられ得る）。スケジューラは性能及び費用の制限事項を満たすためにプロセス定義から実行可能なプロセスのインスタンスを生成することに関与する。スケジューラは、ユーザが該ユーザのローカルノード内のローカルサーチプロセスに対して、所望されているプロセスの定義を供給するときに、該ユーザによって起動される。該プロセスのインスタンスを生成するために、スケジューラはシーケンスの１番めのサービスに対するサーチを開始する。これは、ノード１０を中心とする拡大する円５０により、図３に描かれている。これらの円は、１番めのサービスを提供する能力を備えた十分なノードの位置が突き止められるまで、ノード１０から、より遠くのノードまで広がるサーチを表している。それぞれの１番めのサービスは「第１の」ノードに位置している。図３に示されているように、第１のノードの２つの候補１４と２４はサーチの第１の段階の結果として位置を突き止められる。ノード１４は接続４１を介してノード１０に直接的に接続されている。ノード２４はノード１８及び接続４３と４６を介してノード１０に接続されている。
【００２９】
さらなる好ましい実施形態によれば、このサーチには有界エコー（bounded echo）が使用される。有界エコーは、最初に制限された領域の中のネットワークノードをサーチし、該領域は、定められた数の適切なサービスが発見されるまで拡大する。
【００３０】
発見されたノードの特徴及びこれらのノードに対する接続性（つまり、ノード１４に対する接続４１、及びノード１８を介し、ノード２４に対する接続４３と４６）に関する情報は、ユーザのノード１０にあるスケジューラに返される。次にスケジューラはユーザによって供給される基準に基づいて、１番めのサービスを提供する可能性を有する１番めのサービスのインスタンスを提供する幾つかの（ショートリスト）のノードを選択する。シーケンスの２番めのサービスに対するサーチは、次に１番めのサービスのインスタンスを提供する選択された第１のノード１４と２４から遠隔で開始される。これは、選択された第１のノード２４を中心とする、拡大する円５２によって図３の中で表されている。多くの選択された「第１のノード」から複数のサーチが並列で発生する可能性があるが、ここでは明確にするためにただ１つの第２の段階のサーチだけが描かれている。２番めのサービスを提供できる複数の「第２のノード」の位置が突き止められる（明確にするために図３では１つの第２のノード３０だけしか示されていない）。発見された「第２の」ノード、つまりシーケンスの２番めのサービスを提供する可能性を有するノードの特徴がスケジューラに返される。１番めのサービスを提供できるノードと、２番めのサービスを提供できるノード間の接続性に関する情報もスケジューラにも返され、スケジューラは次に第２のノードのショートリストを選択する。３番めのサービスに対するサーチも同様に、つまり２番めのサービスのインスタンスを提供する選択されたノードから開始される。これは、選択された第２のノード３０を中心とする、拡大する円５４により図３に表されている。この段階で、並列に発生していることがある他のサーチは明確にするために示されていない。図３の例では、３番めのサービスを提供できる複数の「第３のノード」の位置が突き止められる（明確にするために１つの第３のノード３６しか示されていない）。同様に、所望される４番めのサービス、５番めのサービス等を提供できる多くの第４のノード、第５のノード等の位置が、必要に応じて以後の段階で突き止められる（不図示）。このプロセスは、シーケンスの中の各サービスのインスタンスを提供する十分な数のノードが検出されるまで繰り返される。
【００３１】
図４は、図３のネットワークの一部を示し、図３のサーチをさらに明確に描くためにサーチの結果として選択されたノードだけが示されている。図４では、矢印４９がユーザノード１０と選択された第１のノード２４との間のリンクを表す。
【００３２】
本発明のさらなる好ましい実施形態によると、スケジューラは、図５に示されているように、頂点（１０）からの反対の先端（例えば８２）までの各経路がプロセスを実行可能なインスタンスを表すグラフを構築できる。性能及び負担に関するデータは、グラフの各頂点（サービス６０から８４）及び孤（ネットワーク接続１００から１２６）と関連付けられている。ユーザノード１０は、ネットワーク接続１００、１０２によって１番めのサービス６０、６２に接続されている。１番めのサービス６０は、それぞれネットワーク接続１１０、１１２、及び１１４によって２番めのサービス７０、７２、７４に接続されている。１番めのサービス６２はそれぞれネットワーク接続１１６と１１８によって２番めのサービス７４、７６に接続されている。２番めのサービス７０は、ネットワーク接続１２０によって３番めのサービス８０に接続されている。２番めのサービス７２は、ネットワーク接続１２２によって３番めのサービス８２に接続されている。第３段階のサーチの結果として、２番めのサービス７４と７６が、ともに同じ単一の３番めのサービス８４の位置を突き止めた。したがって、２番めのサービス７４と７６は、それぞれネットワーク接続１２４と１２６によって３番めのサービス８４に接続されている。通常、決定グラフは、すべての必要とされるサービス及び該サービスの相互接続のインスタンスがグラフに表されるまで、さらなるネットワーク接続を介して接続されるさらなるサービスインスタンスに拡張されるであろう。決定グラフを図３及び図４の例に関連づけるために、孤１００、１１０及び１２０がそれぞれリンク４９、４７及び４８に関連づけられ、サービス６０、７０及び８０がそれぞれノード２４、３０および３６に関連づけられるであろう。
【００３３】
スケジューラは、次に、各経路の頂点と孤に関連付けられた性能及び負担のデータに基づいて各経路の質を計算し、エンドユーザの制限事項を満足させるために最も適切な経路を選択する。さらなる好ましい実施形態によると、スケジューラは、発見の各段階において成功の見込みのない経路を取り除くことができる。例えば、１つの制限事項が、３つのサービスのシーケンスからなるプロセスが１０秒以内に実行できなければならず、ある経路に沿って１番めのサービスインスタンスを実行すると、２番めのサービスインスタンスまで伝搬し、２番めのサービスインスタンスを実行するのに１１秒を要する場合、該経路に沿って３番めのサービスのインスタンスのサーチを続行しても意味がない。
【００３４】
決定グラフ（ひいては、プロセスを実現するためのサービスインスタンス及び接続の構成）を通る経路を選ぶ上で考慮に入れられる可能性がある負担は、接続帯域幅、サービスインスタンスの近接性、サービス間でデータを転送するネットワーク負担、リソースを使用する財務費用、リソースの可用性、リソースの所有権、セキュリティ、及び処理される情報に対する未許可のアクセスを防止したいという願望を含むが、これらに限定されない。
【００３５】
いったん最適構成が選択されると、さらなる好ましい実施形態によると、該構成は、ユーザを要求されるサービスにリンクし、これらのサービス間の関係性を確立し、その間にデータの流れを構築するするオーバレイネットワークによって、実現される。
【００３６】
本発明のさらなる実施形態によると、適切な品質測定基準を有するサービスのシーケンスに対する要求が生成される。必要とされるサービスの１つを提供する各ノードが発見されると、該ノードはスケジューラに戻ることなくシーケンスの中で次のサービスに対する有界エコーサーチを開始する。エコーアルゴリズムは次に結果を集約し、サービスインスタンスの順序付きリストを、各測定基準に対するリストの性能とともにスケジューラに返す。集約は各ノードに存在するエコーデーモンによって実行される。エコーデーモンは、該エコーデーモンが伝搬させたすべてのアクティブなサーチを記録に残し、返された結果を集約する。エコーデーモンは、エコーパターンに含まれるすべての通信に関与する。システム内のあらゆるノードは、エコーデーモンの一部として実行されるソフトウェアプロセスを有し、該ソフトウェアプロセスは標準的な通信ポートでエコーメッセージをリッスン(listen)する。該デーモンは、メッセージがサーチであるのか、あるいはエコーであるのかを認識する。該メッセージがサーチである場合、該デーモンは必要とされるサービスがないか局所的にチェックし、必要であれば、メッセージ発信元を除く該ノードの近傍に該サーチメッセージを渡す。該サーチメッセージを渡す前に、デーモンは、該サーチのさらなる伝搬が許されるかどうかを確かめるためにホップカウントをチェックする。ホップカウントは、サーチが伝搬されるたびに増分される単純な数値カウントであり、サーチ領域の範囲を制限するために、つまり有界サーチを提供するために使用される。ホップカウントはゼロで開始する。ノードがサーチメッセージを転送するたびに、ホップカウントは増分される。ノードは、ホップカウントが所定の制限未満である場合にだけサーチメッセージを転送する。ホップカウントが該制限に等しい場合、アルゴリズムの拡大段階は終了し、ノードは要求元ノードにサーチに関する情報を返す。
【００３７】
エコーデーモンはその近傍のリストを維持し、周期的に該リストを更新する。サーチに対する応答が返されると、デーモンは集約プロセスを管理し、収集された応答をサーチ発信元に返す。カスタマがサーチを開始するとき、カスタマがサーチを設定し、ローカルノード上のエコーデーモンから発行される第1のサーチメッセージを生成できるようにするグラフィックインタフェースにカスタマがアクセスできることが好ましい。
【００３８】
この実施形態は特に、（例えば、選択肢、並列実行等を含む）さらに複雑な同期を有する構造よりむしろシーケンスをみつけるのに適している。これらの、さらなる２つの実施形態は、さらに複雑な状況においてはスケジューラがサーチを明示的に指示し、他の状況ではエコーデーモンによる集約に依存する実施形態において結合され得る。
【００３９】
好ましい実施形態によると、初期のプロセス設計は、図１に描かれているように、プロセスのグラフィック表現を可能にする統合開発ツールを使用して実施される。ＷＤＳＬに基づいた該表現はオラクル（Oracle）のＢＰＥＬデザイナーまたは他の市販されているツールを使用して生成されることができ、一例として前述されたローン申請について示されている。同じ情報は、例えばＸＭＬベースのファイルで入手でき、ＸＭＬベースのファイルにおいてはパートナー・リンクと、オーケストレーションロジックが、コンポーネントサービスの識別情報とフローにおける順序付けを記述する。
【数１】
【００４０】
要求者から入力を受け取る−これがこのフローを開始するものである。私たちはローン申請ビジネス文書を渡される。
【数２】
【００４１】
同期ｃｒｅｄｉｔＲａｔｉｎｇＳｅｒｖｉｃｅを呼び出す。ｃｒｅｄｉｔＲａｔｉｎｇＳｅｒｖｉｃｅからの障害を処理する範囲を明確にし、私たちがクレジット格付けを受け取ると、ローン申請ビジネス文書にクレジット格付けを設定する。ＮｅｇａｔｉｖｅＣｒｅｄｉｔの例外の場合には、格付けを−１０００に設定する。
【数３】
【００４２】
これは、サービス発見プロセスに対する入力として使用される構造化されたサーチ文字列を提供する。クライアントノードは、必要とされる１番めのサービス、前述の例の中ではユーザのローン申請者の社会保険番号（ＳＳＮ）の取り出しを可能にするサービスに対する有界エコーサーチを開始する。サーチにより返されるインスタンスの数は設定可能であり、返される数を少なくするほど、サーチ及びスケジューリングは高速化し、容易になるが、より有利な解決策が見失われる可能性がある。いったん１番めのサービスが特定されると、社会保険番号を供給するノードから第２の一連の有界エコースキャンが始まり、このサーチはクレジット格付け取得サービスを探す。
【００４３】
有利なことにサービス発見に対するこの手法は、それぞれがプロセスの実行可能なインスタンス化である一連のトレースの出力を生じさせる。これは再び、図５に示されているような決定グラフに類似する形式で表すことができる。図５では、グラフを通る各経路が、プロセスのインスタンスを生成するために必要なサービスに対して確立された接続性及び近接性を表し、それにより最も適切な組み合わせまたは経路を選択可能にするために必要とされる情報の量を削減する。
【００４４】
さらなる好ましい実施形態によると、グラフの中のノード及びネットワークリンクに識別情報及び負担情報を追加することを含むさらなる改良が導入され、これにより、グラフを通過する最低負担の経路を検出するかなり簡略な方法で、最善の組み合わせを特定できる。グラフにラベルを付けるために使用される負担測定基準は、例えば使用可能なコンピューティングリソース、サービスがすでに存在している場合にはサービスの性能、開始されなければならないサービスのロードに要する時間（time-to-load）、及びネットワークリンクの接続性能に関するものであり得る。ラベルをグラフに付加すると、グラフ構築時に、グラフから余分なものを取り除くプロセスが容易になり、さらにスケジューリングプロセスが簡略化する。
【００４５】
前述された発見及びスケジューリングのプロセスの一部に対するシーケンス図が図６に示されている。図６は統一モデリング言語（ＵＭＬ）―オブジェクトマネージメントグループ社（Object Management Group, Inc.）の登録商標―を使用する。
【００４６】
図６は、発見プロセスの重要な特長のいくつかを強調する簡略化されたＵＭＬシーケンス図を示している。時間は左上角で開始し、図の下方に進み、上部に沿ったボックスのそれぞれ（：Ａｐｐｌｉｃａｔｉｏｎ Ｓｃｈｅｄｕｌｅ、：ｌｏｃａｌ ｅｃｈｏｄ、：ｒｅｍｏｔｅ ｅｃｈｏｄ、：ｒｅｍｏｔｅ ｅｃｈｏｄ２、：ｒｍｏｔｅ ｅｃｈｏｄ３）が関数を表している。エコーサーチのケースではこれらの関数のそれぞれが別々のノードで実行されている。エコーサーチ関数（：ｌｏｃａｌ ｅｃｈｏｄ、：ｒｅｍｏｔｅ ｅｃｈｏｄ、：ｒｅｍｏｔｅ ｅｃｈｏｄ２；：ｒｅｏｔｅ ｅｃｈｏｄ３）はサーチ要求を処理する、つまりサーチ要求メッセージを受け入れ、該サーチ要求メッセージに従ってローカルノードを照会し、該サーチ要求を以後のノードに渡し、及び要求元スケジューラに結果を返すコードの部分である。各エコーサーチ関数は、該関数が存在するノードに対するすべてのローカル接続の詳細、及びすべての有効なサーチ要求の要求元を有する。
【００４７】
カスタマが実行してほしいプロセスのためのタスクシーケンス、及び関連するサービスの質の測定基準をカスタマが供給するための１つの方法は、ワークフローを提供することである。ワークフローはタスク、プロシージャステップ、関与している組織または人、必要とされる入出力情報、及びビジネスプロセスの各ステップに必要とされるツールを記述するために使用される用語である。ワークフローはこのようなプロセスを管理、監視するために電子システムを使用するＩＴ技術である。ワークフローは、例えばネットワーク内コンピュータ間でのデータの転送として実現されるような、個人及び／または部門の間での作業の流れを定義し、追跡できるようにする。
【００４８】
図６に描かれているシーケンスは以下の通りである。
【００４９】
潜在的なカスタマが必要とされるワークフローを供給すると、スケジューリングタスク（関数：Ａｐｐｌｉｃａｔｉｏｎ Ｓｃｈｅｄｕｌｅ）を処理するためにアプリケーションスケジューラが作成される。スケジューラは、ユーザが該ユーザのローカルノードでローカルサーチ関数にワークフロー定義を供給するときに、該ユーザによって起動される。プロセスを分析、管理するためのワークフロー手法は、文書及びデータに注目する傾向があるオブジェクト指向プログラミング手法と結合することができる。一般的には、ワークフロー管理は文書よりむしろプロセスに注目する。市販されているワークフロー自動化製品によって、組織がワークフローモデルとオンライン書式等のコンポーネントを作成すると、一貫した作業の処理を管理し、実行するための方法として該製品を使用できるようになる。
【００５０】
アプリケーションスケジューラは、ローカルエコーサーチ関数を照会すること（メッセージ「サーチを開始」）によってローカルノード上のワークフローの第１のコンポーネントを探す（関数：ｌｏｃａｌ ｅｃｈｏｄ）。ローカルエコーサーチ関数はローカルノードを試験し（関数：ｌｏｃａｌ ｅｃｈｏｄの下の矢印「ローカルチェック」を参照すること）、必要とされるコンポーネントが存在していない場合には、ローカルエコーサーチ関数は該サーチを該関数の存在するノードの近傍のエコーサーチ関数（つまり、関数：ｒｅｍｏｔｅ ｅｃｈｏｄ１）に転送する（メッセージ「サーチを伝搬」を参照すること）。各近傍のエコーサーチ関数は次に該関数のローカルノードをサーチする（関数：ｒｅｍｏｔｅ ｅｃｈｏｄ１の下の矢印「ローカルチェック」を参照すること）。所望されるサービスがローカルノードで検出されない場合、該サーチは該近傍の近傍のエコーサーチ関数に転送される（ｒｅｍｏｔｅ ｅｃｈｏｄ１関数からｒｅｍｏｔｅ ｅｃｈｏｄ２関数に送信されるメッセージ「サーチを伝搬」）。本実施の形態では、ｒｅｍｏｔｅ ｅｃｈｏｄ２サーチ関数は該関数のローカルノード上で１番めのサービス（つまりワークフローコンポーネント）の位置を突き止め、アプリケーションスケジューラに正の応答（不図示）を返す。該正の応答はエコーチェーンを通して送り返されてもよいし、あるいは発信側アプリケーションスケジューラに直接的に渡されてもよい。
【００５１】
アプリケーションスケジューラは１番めのサービスの位置を示す正の応答を受け取ると、該アプリケーションスケジューラは、サーチに成功したサーチ関数（：ｒｅｍｏｔｅ ｅｃｈｏｄ２）に、サーチされたワークフローコンポーネントの負担について問い合わせるステータスチェック要求（メッセージ「現在ステータスを要求」）を送信する。該成功した関数はこの値を、スケジューリング決定グラフが構築されているアプリケーションスケジューラに返す（：ｒｅｍｏｔｅ ｅｃｈｏｄ２から：Ａｐｐｌｉｃａｔｉｏｎ Ｓｃｈｅｄｕｌｅｒへのメッセージ「ステータスをスケジューラに返す」）。次にアプリケーションスケジューラは１番めのサービスのインスタンスのある、すべてのサーチが成功した位置から次のサービスに対するサーチを開始する（：Ａｐｐｌｉｃａｔｉｏｎ Ｓｃｈｅｄｕｌｅｒから：ｒｅｍｏｔｅ ｅｃｈｏｄ２へのメッセージ「サーチを開始」）。このプロセスは、すべての必要とされるサービスの位置が無事に突き止められ、該サービスのステータスが判断されるまで続行する。さらなる好ましい実施形態では、スケジューリング決定グラフが構築されると、アプリケーションスケジューラはサイトの潜在的な重複がないか周期的にチェックし、これによりスケジューリング決定グラフをから余分なものを取り除く。すべてのコンポーネントの位置が突き止められると、アプリケーションスケジューラはスケジューリング決定グラフを処理し、接続されているサービスの最適配置をユーザに返す。
【００５２】
さらなる実施形態によると、本発明は並列処理プロセスの構築に対応する。並列手法の使用は種々の方法で適応され得る。例えば、グリッドのためのスケジューラは、並列処理を含む要求を受け入れ、次に分散を処理するグリッドサービスインタフェースを公開してもよい。あるいは、並列実行は、あるサービスの出力が複数の同一のサービスの入力に送信されるワークフロー記述に含まれることもできる。
【００５３】
グリッドコンピューティングは、特に科学研究における並列処理に広範囲に使用される。しかしながら、グリッドコンピューティングは、科学的なアプリケーションほど多くの並列性を必要としないビジネスアプリケーションにも適用できる。本発明は、ウェブサービスまたはグリッドサービス使用されるものであればどの分野にでも適用され得る。本発明のさらなる優位点は、本発明によってスケジューラが二段階サーチを実施できるという点である。従来のウェブサービスは既存のサービスしか使用しない。有利なことに、本発明によれば、スケジューラはプロセス要件を満たすために適切なノードでサービスを開始することも検討できる。これは、ノード上に存在するが、実行されていないサービスを開始することと、インストールできる適切なサービスコードダウンロードし、実行することの両方を含む。オンデマンドでインストールを可能にする適切なソフトウェアプロビジョニングシステムには、グリッドコンピューティング及びＣＯＲＢＡ（共通オブジェクトブローカーアーキテクチャ）が含まれる。新たな範囲の仮想化及びサーバ自動化ソフトウェアは、本発明とともに使用するのに適して、同様にオンデマンドでのインスタンス生成を可能にすることが期待される。
【００５４】
本発明は、集中ディレクトリをベースにした解決策よりさらに頑健な解決策を提供し、ネットワーク障害に直面しても、有利なことに動作を継続することができる。レジストリを使用するＵＤＤＩ等の従来の手法は、ディレクトリを含むネットワークの一部に到達できなくなると失敗する。本発明のサーチはユーザによって開始され、開始点に現在接続されているネットワークのすべての部分に到達するよう放射状に広がり、したがって、部分的なネットワーク障害があっても、完全なまたは部分的な進行を維持できるようにする。必要とされるサービスの位置と負担がスケジューラによって取得された後に、ネットワークの部分が故障すると、ネットワークの故障した領域内にあるいかなるサービスにも到達できなくなり、該サービスの使用は拒絶される。本発明のサーチプロセスは局所的な知識を使用するため、ネットワークに関する問題の結果としてアクセスが拒絶されるあらゆるサービスの代わりのインスタンスの位置を突き止めるために、第２のサーチがただちに開始され得る。有利なことに、第２のサーチは、本質的に、依然として要求元ノードに接続されているノードからデータを収集するにすぎない。
【００５５】
さらなる好ましい実施形態によると、元のサーチの間に見つけられたが、使用のために選択されなかった代替サービスの位置が、このようなネットワーク問題が発生するのに備えて記憶される。これにより、部分的なネットワーク障害の場合には、ネットワークは使用可能な可動サービスに迅速に切り替わることができる。最上位レベルに中心的なサービスがないことにより回復力がさらに強化され得る。スケジューリングプロセスが集中化されると、一つのプロセスの障害が致命的となるであろう。好ましい実施形態に従って、各スケジューラは、依然として動作できる他のすべてに悪影響を及ぼさずに、失敗する可能性のある１つのプロセスだけに関与する。したがって、該システムは複数のレベルで回復力があり、最高レベルに集中サービスがないことが障害の影響を制限し、複数の適切なサービスの位置を、例えば選択グラフの一部として記憶すれば、万一障害が発生した場合に迅速な回復に役立つ。必要な場合には、潜在的に古いディレクトリルックアップに依存するのでなく動的な発見を使用して、最新の情報が収集される。発見された情報は、発見プロセスの間にフィルタリングされることができ、これにより、考慮され得る検討の対象の構成の範囲が、受け入れられる可能が高い最も構成に制限される。また、発見された情報は、サービス性能に関する情報を関連するネットワーク性能に暗に結合する。これは、低速ネットワークリンクを介して多くのデータ量を通信する必要がある高性能ウェブサービスと、同等であるが、ローカルコンピュータで使用可能なより低速のプロセスを用いる高性能ウェブサービス（つまり低速ネットワークリンクを回避する）のような２つの高性能ウェブサービスを比較する際に有効であり得る。本発明はこのような問題に対処する、単純で分散された方法を提供する。
【００５６】
さらなる実施形態によると、ビデオオンデマンドプロセスを構成され得る。ビデオオンデマンドサービスは、カスタマがビデオの名前及び配信先アドレスを指定する（これはユーザとのやり取りなしにバックグラウンドで自動的に取得されてもよい）ことにより自ら開始する、単純な２段階ワークフローとして表されることができるビデオサービスと配信サービスからなることができる。エコーパターンの第１の段階は、要求されたビデオを供給できるビデオサーバを検出するように始まる。次にエコーサーチの第２の段階は適切な配信サービスを検出するように始まる。スケジューラはビデオに必要とされる質のレベルで、ビデオオンデマンドサービスを共に提供できるビデオ配信元とビデオ配信サービスとを選ぶ。
【００５７】
さらなる実施形態によると、本発明は以下をサポートするネットワークの構成に適用され得る。
【００５８】
・サードパーティ呼制御
サードパーティ呼制御は、アプリケーションによって開始される呼を作成、管理するために使用される。アプリケーション開発者はサードパーティ呼ウェブサービスを使用し、２つの終点のアドレス（または電話番号）を提供することにより呼処理機能を呼び出すことができる。適切なアプリケーションは、ビジーまたは、使用できない加入者のＰＳＴＮ回線への接続のどちらかで呼び出されるものである。これがどのように動作するのかを示す一例は、ユーザがＰＳＴＮ接続を利用してインターネットにダイアルアップしたときである。アプリケーションはこの信号を取り上げ、着呼者ユーザに、呼をボイスメールに送信するのか、呼を別の番号に転送するのか、あるいは呼を拒絶するのかの選択を与える。該ユーザによってなされる応答はネットワーク内で処理される。サーバは、特定の番号がダイアルされると必ずアプリケーションをトリガしてもよい。これは多くの既存のインテリジェントネットワークサービスの提供のために実行可能であろう。このようなサービスの使用の１つの例は、特定の株価を監視し、価格が閾値に達すると、クライアントアプリケーションは一人または複数のブローカーと該ブローカーに対応するカスタマの間でサードパーティ呼を呼び出し、これにより講じられる処置が決定される。
【００５９】
・ＳＭＳ
（ボイスメール、トラフィック、天候または他の情報レポート、あるいはｅ−メールメッセージ等の）外部刺激によってトリガされる（サードパーティプラットホームまたは社内アプリケーションプラットホームに常駐する）クライアントアプリケーション等のアプリケーションからＳＭＳメッセージを送信する方法。アプリケーションはＳＭＳウェブサービスを呼び出す。アプリケーションはメッセージ（テキストの文字列）及び着呼者ユーザの詳細を提供する。次に、ウェブサービスはモバイルＳＭＳ−Ｃにメッセージを着呼者ユーザに送信させるメッセージを呼び出すことができる。
【００６０】
・ＭＭＳ
マルチメディアメッセージがユーザに送信され、アプリケーションによってネットワークから取り出されるのを可能にする。アプリケーションはモバイルネットワークによって提供されるＭＭＳ機能を利用する。
【００６１】
本発明は、ネットワーク全体に渡って未知の方法で拡散される多様なサービスから、所望されるプロセスを効率的に構築できるようにする。サービスは、実行中であるか、インストールされているがイナクティブであるか、あるいはインストールを必要とするかのいずれかのソフトウェアと、インストールされているか、インストールを必要とするかいずれかのデータと、コンピュータ、ＰＤＡ及び携帯電話等のデバイスによって提供されて得る処理電力または記憶装置とを含むが、これらに限定されない多様なタイプであり得る。好ましい実施形態によれば、これは、最も適切なサービスインスタンス及び接続として高速決定を行うことを可能にする決定グラフの構築によって達成される。ユーザから広がるサーチ計画を利用することにより、本発明は本質的に、接続負担を最小限に抑える一方で速度を最適化する傾向がある。
【００６２】
本発明は、設定された順序で実行されなければならない一連のサービスを備えるプロセスに限定されるのではなく、並列実行及び、選択肢や決定を含むシーケンス等の他の構造にも等しく適用され得る。本発明は、ネットワークの特定の形式またはトポロジに限定されるのではなく、リング、ツリー、部分メッシュと完全メッシュ、及び電気的、光学的、または他の電磁的な媒体で実現される他のトポロジにも適用される。本発明は複数のネットワークを横切って分散されるサービスにも、その本質的な性格を変更することなく適用され得る。本発明は特定のタイプのサービスに限定されるのではなく、他の応用例の中でビジネスアプリケーション、通信サービス、製造システムに及ぶ。
【００６３】
略語
ＢＰＥＬ ビジネスプロセス実行言語
ＢＰＥＬ４ＷＳ ウェブサービス向けビジネスプロセス実行言語
ＨＴＴＰ ハイパーテキスト転送プロトコル
ＭＭＳ マルチメディアメッセージサービス
ＭＭＳ マルチメディアメッセージングサービス
ＯＡＳＩＳ 構造化情報標準促進団体
ＯＧＳＡ オープングリッドサービスアーキテクチャ
ＰＳＴＮ 公衆交換電話網
ＳＭＳ ショートメッセージングサービス
ＳＭＳ ショートメッセージサービス
ＳＯＡ サービス指向アーキテクチャ
ＳＯＡＰ シンプルオブジェクトアクセスプロトコル
ＳＳＮ 社会保険番号
ＵＤＤＩ ユニバーサルディスクリプション、ディスカバリー＆インテグレーション
ＵＭＬ 統一モデリング言語
ＷＳＤＬ ウェブサービス記述言語
ＸＭＬ 拡張マークアップ言語
【図面の簡単な説明】
【００６４】
【図１】フローチャート形式でプロセスを示す。
【図２】本発明を実現するためのネットワークを示す。
【図３】本発明の図４のネットワークにおける一連のサーチを描く。
【図４】本発明の図４のネットワークにおける一連のサーチを描く。
【図５】図３及び図４のサーチから導出される決定グラフを示す。
【図６】ＵＭＬ図として図３及び図４のサーチを示す。
【特許請求の範囲】
【請求項１】
プロセスのためにネットワークを構成する方法であって、該ネットワークがサービスを提供するための複数のノードを備え、該プロセスが複数の前記サービスを備え、
第１のノードから開始し、必要とされるサービスの１番めのサービスを提供する適切なノードがないか前記ネットワークをサーチするステップと、
前記１番めのサービスを提供するために適切として前記サーチの結果として特定された前記１つ以上のノードから開始し、前記必要とされるサービスの２番めのサービスを提供するために適切なノードをサーチするステップと、
すべての前記必要とされるサービスに適切なノードの位置が突き止められるまで、残りの必要とされている各サービスについて、前記必要とされるサービスの前のものを提供するために適切な前記特定された１つ以上のノードから毎回開始して前記サーチを繰り返すステップと、を含む方法。
【請求項２】
前記サーチの結果、前記１番めのサービスを提供するために適切としてとして特定されたノードに関する情報を取得することと、
前記ノード情報に基づいて、前記１番めのサービスを提供するために適切な少なくとも１つのノードを選択することとを含む、請求項１に記載の方法。
【請求項３】
前記第１のノードと、前記サーチの結果、前記１番めのサービスを提供するために適切として特定された前記ノードとの間の接続に関する情報を取得することと、
前記ノード情報及び前記接続情報に基づいて、前記１番めのサービスを提供するために適した少なくとも１つのノードを選択することとを含む、請求項２に記載の方法。
【請求項４】
前記２番めのサービスを提供するために適切なノードに対する前記サーチは、前記１番めのサービスを提供するために適切な前記１つ以上のノードのそれぞれから開始される、請求項２または請求項３に記載の方法。
【請求項５】
前記サーチの結果、前記必要とされるサービスのそれぞれを提供するために適切として特定された前記ノードに関する情報を取得することと、
前記ノード情報に基づいて、前記必要とされるサービスのそれぞれを提供するために適切な少なくとも１つのノードを選択することとを含む、請求項１乃至請求項４のいずれか１項に記載の方法。
【請求項６】
前記サーチの結果、前記必要とされるサービスの１つを提供するために適切として特定された前記１以上の選択されたノードのそれぞれと、前記サーチの結果、前記必要とされるサービスの次のノードを提供するために適切として特定された前記ノードとの間の接続に関する情報を取得することと、
前記ノード情報及び接続情報に基づいて、前記次に必要とされるサービスを提供するために適切な少なくとも１つのノードを選択することとを含む、請求項５に記載の方法。
【請求項７】
前記必要とされるサービスの前記次のサービスを提供するために適切なノードに対する前記サーチは、前記前のサービスを提供するために適切な選択された前記１つ以上のノードのそれぞれから開始される、請求項５または請求項６に記載の方法。
【請求項８】
前記ネットワークを通る複数の経路であって、各経路が前記必要とされるサービスの少なくともいくつかを提供するために適切なノードと、前記ノード間の接続と備えるものを特定することと、
前記経路のそれぞれにおける前記ノード及び接続を評価することと、
前記評価に基づいて前記プロセスを提供するための１つ以上の経路を選択することとを含む、請求項１乃至請求項７のいずれか１項に記載の方法。
【請求項９】
前記サーチの結果、前記必要とされるサービスを提供するために適切として特定され、１つの選択された経路内に備えられた前記ノードのすべてが別の選択された経路内に備えられないように、重複した経路を選択解除することを含む、請求項８に記載の方法。
【請求項１０】
請求項８または請求項９で規定された前記方法ステップは、前記サーチの中間段階で実行される、請求項８または請求項９に記載の方法。
【請求項１１】
選択解除された経路に関する情報を維持することと、
選択された経路において障害があった場合に、前記経路を適切な選択解除された経路で置換することとを含む、請求項８乃至請求項１０のいずれか１項に記載の方法。
【請求項１２】
前記必要とされるサービスを提供するために適切な前記特定されたノードであって、選択するための前記手段により選択されていないノードに関する情報を維持することと、
選択されたノードにおいて障害があった場合に、前記ノードを、ノードの障害が該ノードへの接続の障害を含む適切な選択されていないノードで置換することとを含む、請求項２乃至請求項１１のいずれか１項に記載の方法。
【請求項１３】
サービスがノード上でアクティブである場合に、該ノードは前記サービスを提供するために適している、請求項１乃至請求項１２のいずれか１項に記載の方法。
【請求項１４】
サービスがノード上でアクティブでないが、該ノード上でアクティブにできる場合に、該ノードは前記サービスを提供するために適している、請求項１乃至請求項１３のいずれか１項に記載の方法。
【請求項１５】
サービスがノード上に存在していないが、該ノードにダウンロードされることができ、前記ノード上でアクティブにできる場合に、該ノードは前記サービスを提供するために適している、請求項１乃至請求項１４のいずれか１項に記載の方法。
【請求項１６】
前記ノードはコンピューティンググリッドの一部を形成する、請求項１乃至請求項１５のいずれか１項に記載の方法。
【請求項１７】
有界エコーアルゴリズムを使用することにより前記ネットワークをサーチすることを含む請求項１乃至請求項１６のいずれか１項に記載の方法。
【請求項１８】
前記必要とされるサービスの少なくとも１つに対する前記サーチを、該サービスを提供するために適切な設定数のノードを検出したときに停止することを含む、請求項１乃至請求項１７のいずれか１項に記載の方法。
【請求項１９】
前記情報を処理するために前記有界エコーアルゴリズムを使用することと、
選択されたノードの順序付きリストを前記第１のノードに返すこととを含む、請求項１乃至請求項１８のいずれか１項に記載の方法。
【請求項２０】
複数の前記サービスを必要とするプロセスを提供するためのネットワークであって、該ネットワークがサービスを提供するための複数のノードを備え、
前記システムが、
第１のノードから開始して、必要とされるサービスの１番めのサービスを提供する適切なノードがないか、前記ネットワークをサーチするための手段と、
前記１番めのサービスを提供するために適切として前記サーチの結果として特定された１つ以上のノードから開始して、前記必要とされるサービスの２番めのサービスを提供する適切なノードがないか、前記ネットワークをサーチするための手段と、
前記サーチの結果、必要とされるサービスの前のものを提供するために適切と特定された前記１つ以上のノードから毎回開始して、それぞれの残りの必要とされるサービスがないか前記ネットワークをサーチするための手段と、を備える、
ネットワーク。
【請求項２１】
前記１番めのサービスを提供するために適切であると特定されたノードに関する情報を取得するための手段と、
前記ノード情報に基づいて前記１番めのサービスを提供するために適切な少なくとも１つのノードを前記特定されたノードから選択するための手段とを備える、請求項２０に記載のネットワーク。
【請求項２２】
前記第１のノードと、必要とされる前記１番目のサービスを提供する前記ノードとの間の前記接続に関する情報を取得するための手段と、
前記ノード情報及び前記接続情報に基づいて前記１番めのサービスを提供するために適切な少なくとも１つのノードを選択するための手段を備える、請求項２０または請求項２１に記載のネットワーク。
【請求項２３】
前記２番めのサービスを提供するために適切なノードに対する前記サーチは、前記１番めのサービスを提供するために適切な前記１つ以上の選択されたノードのそれぞれから開始される、請求項２０または請求項２２に記載のネットワーク。
【請求項２４】
前記必要とされるサービスを提供するために適切であると前記特定されたノードに関する情報を取得するための手段と、
前記ノード情報に基づいて前記必要とされるサービスのそれぞれを提供するために適切な少なくとも１つのノードを選択するための手段とを備える、請求項２０乃至請求項２３のいずれか１項に記載のネットワーク。
【請求項２５】
前記必要とされるサービスの１つを提供するために適切な前記１つ以上の選択されたノードのそれぞれと、前記サーチの結果、次に必要とされるサービスを提供するために適切として特定された１以上のノードのそれぞれとの間の前記接続に関する情報を取得するための手段を備え、選択するための前記手段は、前記ノード情報及び該ノードについて取得された接続情報に基づいて次に必要とされるサービスを提供するために適切な少なくとも１つのノードを選択するように構成された、請求項２０乃至請求項２４のいずれか１項に記載のネットワーク。
【請求項２６】
前記必要とされるサービスの次のサービスを提供するために適切なノードをサーチするための前記手段は、前記前の必要とされるサービスを提供するために適切な前記１つ以上の選択されたノードから開始するように構成された、請求項２０乃至請求項２５のいずれか１項に記載のネットワーク。
【請求項２７】
前記ネットワークを通る複数の経路であって、各経路が前記必要とされるサービスの少なくともいくつかを提供するために適切なノードと、前記ノード間の接続とを備えるものを特定し、前記経路のそれぞれにおける前記ノード及び接続を評価し、及び前記評価に基づいて前記プロセスを提供するために１つ以上の経路を選択する選択手段を含む、請求項２０または請求項２６に記載のネットワーク。
【請求項２８】
前記選択手段は、前記サーチの結果、前記必要とされるサービスを提供するために適切として特定され、１つの選択された経路内に備えられた前記ノードのすべてが別の選択された経路内に備えられないように、重複した経路を選択解除するように構成された請求項２７に記載のネットワーク。
【請求項２９】
前記選択手段は、前記サーチの中間段階で前記選択及び選択解除の少なくとも１つを実行するように構成された、請求項２７または請求項２８に記載のネットワーク。
【請求項３０】
前記選択手段は、選択解除された経路に関する情報を維持し、及び選択された経路における障害の場合には、適切な選択解除された経路で前記経路を置換するように構成された、請求項２７乃至請求項２９のいずれか１項に記載のネットワーク。
【請求項３１】
前記選択手段は、前記必要とされるサービスを提供するために適切であると前記特定されたノードであって、選択のための前記手段によって選択されていないノードに関する情報を維持し、選択されたノードにおいて障害があった場合には、前記ノードを、ノードの障害が該ノードへの接続の障害を含む適切な選択されていないノードで置換するように構成された、請求項２７乃至請求項２９のいずれか１項に記載のネットワーク。
【請求項３２】
サービスがノード上でアクティブである場合に、該ノードは前記サービスを提供するために適している、請求項２０乃至請求項２６のいずれか１項に記載のネットワーク。
【請求項３３】
サービスがアクティブではないが、ノード上でアクティブにできる場合に該ノードは、前記サービスを提供するために適している、請求項２０乃至請求項３２のいずれか１項に記載のネットワーク。
【請求項３４】
サービスがノードに存在していないが、該ノードにダウンロードされ、該ノードでアクティブにできる場合に、該ノードは前記サービスを提供するために適している、請求項２０乃至請求項３３のいずれか１項に記載のネットワーク。
【請求項３５】
前記ノードはコンピューティンググリッドの一部を形成する、請求項２０乃至請求項３４のいずれか１項に記載のネットワーク。
【請求項３６】
有界エコーアルゴリズムを使用することによって前記ネットワークをサーチするための手段を備える、請求項２０乃至請求項３５のいずれか１項に記載のネットワーク。
【請求項３７】
サーチするための前記手段は、前記必要とされるサービスの少なくとも１つに対する前記サーチを、該サービスを提供するために適切な設定数のノードを検出したときに停止するように構成された、請求項２０乃至請求項３６のいずれか１項に記載のネットワーク。
【請求項３８】
選択するための前記手段は、前記情報を処理するために前記エコーアルゴリズムを使用し、選択されたノードの順序付きリストを前記第１のノードに返すように構成された、請求項２１乃至請求項３８のいずれか１項に記載のネットワーク。
【請求項３９】
コンピュータで実行されるときに、前記コンピュータを請求項１乃至請求項１９のいずれか１項に記載の前記方法ステップに従って動作させる命令を備えるコンピュータプログラム。
【請求項４０】
請求項３９に記載のコンピュータプログラムを記憶するコンピュータ読み取り可能記憶媒体。
【請求項１】
プロセスのためにネットワークを構成する方法であって、該ネットワークがサービスを提供するための複数のノードを備え、該プロセスが複数の前記サービスを備え、
第１のノードから開始し、必要とされるサービスの１番めのサービスを提供する適切なノードがないか前記ネットワークをサーチするステップと、
前記１番めのサービスを提供するために適切として前記サーチの結果として特定された前記１つ以上のノードから開始し、前記必要とされるサービスの２番めのサービスを提供するために適切なノードをサーチするステップと、
すべての前記必要とされるサービスに適切なノードの位置が突き止められるまで、残りの必要とされている各サービスについて、前記必要とされるサービスの前のものを提供するために適切な前記特定された１つ以上のノードから毎回開始して前記サーチを繰り返すステップと、を含む方法。
【請求項２】
前記サーチの結果、前記１番めのサービスを提供するために適切としてとして特定されたノードに関する情報を取得することと、
前記ノード情報に基づいて、前記１番めのサービスを提供するために適切な少なくとも１つのノードを選択することとを含む、請求項１に記載の方法。
【請求項３】
前記第１のノードと、前記サーチの結果、前記１番めのサービスを提供するために適切として特定された前記ノードとの間の接続に関する情報を取得することと、
前記ノード情報及び前記接続情報に基づいて、前記１番めのサービスを提供するために適した少なくとも１つのノードを選択することとを含む、請求項２に記載の方法。
【請求項４】
前記２番めのサービスを提供するために適切なノードに対する前記サーチは、前記１番めのサービスを提供するために適切な前記１つ以上のノードのそれぞれから開始される、請求項２または請求項３に記載の方法。
【請求項５】
前記サーチの結果、前記必要とされるサービスのそれぞれを提供するために適切として特定された前記ノードに関する情報を取得することと、
前記ノード情報に基づいて、前記必要とされるサービスのそれぞれを提供するために適切な少なくとも１つのノードを選択することとを含む、請求項１乃至請求項４のいずれか１項に記載の方法。
【請求項６】
前記サーチの結果、前記必要とされるサービスの１つを提供するために適切として特定された前記１以上の選択されたノードのそれぞれと、前記サーチの結果、前記必要とされるサービスの次のノードを提供するために適切として特定された前記ノードとの間の接続に関する情報を取得することと、
前記ノード情報及び接続情報に基づいて、前記次に必要とされるサービスを提供するために適切な少なくとも１つのノードを選択することとを含む、請求項５に記載の方法。
【請求項７】
前記必要とされるサービスの前記次のサービスを提供するために適切なノードに対する前記サーチは、前記前のサービスを提供するために適切な選択された前記１つ以上のノードのそれぞれから開始される、請求項５または請求項６に記載の方法。
【請求項８】
前記ネットワークを通る複数の経路であって、各経路が前記必要とされるサービスの少なくともいくつかを提供するために適切なノードと、前記ノード間の接続と備えるものを特定することと、
前記経路のそれぞれにおける前記ノード及び接続を評価することと、
前記評価に基づいて前記プロセスを提供するための１つ以上の経路を選択することとを含む、請求項１乃至請求項７のいずれか１項に記載の方法。
【請求項９】
前記サーチの結果、前記必要とされるサービスを提供するために適切として特定され、１つの選択された経路内に備えられた前記ノードのすべてが別の選択された経路内に備えられないように、重複した経路を選択解除することを含む、請求項８に記載の方法。
【請求項１０】
請求項８または請求項９で規定された前記方法ステップは、前記サーチの中間段階で実行される、請求項８または請求項９に記載の方法。
【請求項１１】
選択解除された経路に関する情報を維持することと、
選択された経路において障害があった場合に、前記経路を適切な選択解除された経路で置換することとを含む、請求項８乃至請求項１０のいずれか１項に記載の方法。
【請求項１２】
前記必要とされるサービスを提供するために適切な前記特定されたノードであって、選択するための前記手段により選択されていないノードに関する情報を維持することと、
選択されたノードにおいて障害があった場合に、前記ノードを、ノードの障害が該ノードへの接続の障害を含む適切な選択されていないノードで置換することとを含む、請求項２乃至請求項１１のいずれか１項に記載の方法。
【請求項１３】
サービスがノード上でアクティブである場合に、該ノードは前記サービスを提供するために適している、請求項１乃至請求項１２のいずれか１項に記載の方法。
【請求項１４】
サービスがノード上でアクティブでないが、該ノード上でアクティブにできる場合に、該ノードは前記サービスを提供するために適している、請求項１乃至請求項１３のいずれか１項に記載の方法。
【請求項１５】
サービスがノード上に存在していないが、該ノードにダウンロードされることができ、前記ノード上でアクティブにできる場合に、該ノードは前記サービスを提供するために適している、請求項１乃至請求項１４のいずれか１項に記載の方法。
【請求項１６】
前記ノードはコンピューティンググリッドの一部を形成する、請求項１乃至請求項１５のいずれか１項に記載の方法。
【請求項１７】
有界エコーアルゴリズムを使用することにより前記ネットワークをサーチすることを含む請求項１乃至請求項１６のいずれか１項に記載の方法。
【請求項１８】
前記必要とされるサービスの少なくとも１つに対する前記サーチを、該サービスを提供するために適切な設定数のノードを検出したときに停止することを含む、請求項１乃至請求項１７のいずれか１項に記載の方法。
【請求項１９】
前記情報を処理するために前記有界エコーアルゴリズムを使用することと、
選択されたノードの順序付きリストを前記第１のノードに返すこととを含む、請求項１乃至請求項１８のいずれか１項に記載の方法。
【請求項２０】
複数の前記サービスを必要とするプロセスを提供するためのネットワークであって、該ネットワークがサービスを提供するための複数のノードを備え、
前記システムが、
第１のノードから開始して、必要とされるサービスの１番めのサービスを提供する適切なノードがないか、前記ネットワークをサーチするための手段と、
前記１番めのサービスを提供するために適切として前記サーチの結果として特定された１つ以上のノードから開始して、前記必要とされるサービスの２番めのサービスを提供する適切なノードがないか、前記ネットワークをサーチするための手段と、
前記サーチの結果、必要とされるサービスの前のものを提供するために適切と特定された前記１つ以上のノードから毎回開始して、それぞれの残りの必要とされるサービスがないか前記ネットワークをサーチするための手段と、を備える、
ネットワーク。
【請求項２１】
前記１番めのサービスを提供するために適切であると特定されたノードに関する情報を取得するための手段と、
前記ノード情報に基づいて前記１番めのサービスを提供するために適切な少なくとも１つのノードを前記特定されたノードから選択するための手段とを備える、請求項２０に記載のネットワーク。
【請求項２２】
前記第１のノードと、必要とされる前記１番目のサービスを提供する前記ノードとの間の前記接続に関する情報を取得するための手段と、
前記ノード情報及び前記接続情報に基づいて前記１番めのサービスを提供するために適切な少なくとも１つのノードを選択するための手段を備える、請求項２０または請求項２１に記載のネットワーク。
【請求項２３】
前記２番めのサービスを提供するために適切なノードに対する前記サーチは、前記１番めのサービスを提供するために適切な前記１つ以上の選択されたノードのそれぞれから開始される、請求項２０または請求項２２に記載のネットワーク。
【請求項２４】
前記必要とされるサービスを提供するために適切であると前記特定されたノードに関する情報を取得するための手段と、
前記ノード情報に基づいて前記必要とされるサービスのそれぞれを提供するために適切な少なくとも１つのノードを選択するための手段とを備える、請求項２０乃至請求項２３のいずれか１項に記載のネットワーク。
【請求項２５】
前記必要とされるサービスの１つを提供するために適切な前記１つ以上の選択されたノードのそれぞれと、前記サーチの結果、次に必要とされるサービスを提供するために適切として特定された１以上のノードのそれぞれとの間の前記接続に関する情報を取得するための手段を備え、選択するための前記手段は、前記ノード情報及び該ノードについて取得された接続情報に基づいて次に必要とされるサービスを提供するために適切な少なくとも１つのノードを選択するように構成された、請求項２０乃至請求項２４のいずれか１項に記載のネットワーク。
【請求項２６】
前記必要とされるサービスの次のサービスを提供するために適切なノードをサーチするための前記手段は、前記前の必要とされるサービスを提供するために適切な前記１つ以上の選択されたノードから開始するように構成された、請求項２０乃至請求項２５のいずれか１項に記載のネットワーク。
【請求項２７】
前記ネットワークを通る複数の経路であって、各経路が前記必要とされるサービスの少なくともいくつかを提供するために適切なノードと、前記ノード間の接続とを備えるものを特定し、前記経路のそれぞれにおける前記ノード及び接続を評価し、及び前記評価に基づいて前記プロセスを提供するために１つ以上の経路を選択する選択手段を含む、請求項２０または請求項２６に記載のネットワーク。
【請求項２８】
前記選択手段は、前記サーチの結果、前記必要とされるサービスを提供するために適切として特定され、１つの選択された経路内に備えられた前記ノードのすべてが別の選択された経路内に備えられないように、重複した経路を選択解除するように構成された請求項２７に記載のネットワーク。
【請求項２９】
前記選択手段は、前記サーチの中間段階で前記選択及び選択解除の少なくとも１つを実行するように構成された、請求項２７または請求項２８に記載のネットワーク。
【請求項３０】
前記選択手段は、選択解除された経路に関する情報を維持し、及び選択された経路における障害の場合には、適切な選択解除された経路で前記経路を置換するように構成された、請求項２７乃至請求項２９のいずれか１項に記載のネットワーク。
【請求項３１】
前記選択手段は、前記必要とされるサービスを提供するために適切であると前記特定されたノードであって、選択のための前記手段によって選択されていないノードに関する情報を維持し、選択されたノードにおいて障害があった場合には、前記ノードを、ノードの障害が該ノードへの接続の障害を含む適切な選択されていないノードで置換するように構成された、請求項２７乃至請求項２９のいずれか１項に記載のネットワーク。
【請求項３２】
サービスがノード上でアクティブである場合に、該ノードは前記サービスを提供するために適している、請求項２０乃至請求項２６のいずれか１項に記載のネットワーク。
【請求項３３】
サービスがアクティブではないが、ノード上でアクティブにできる場合に該ノードは、前記サービスを提供するために適している、請求項２０乃至請求項３２のいずれか１項に記載のネットワーク。
【請求項３４】
サービスがノードに存在していないが、該ノードにダウンロードされ、該ノードでアクティブにできる場合に、該ノードは前記サービスを提供するために適している、請求項２０乃至請求項３３のいずれか１項に記載のネットワーク。
【請求項３５】
前記ノードはコンピューティンググリッドの一部を形成する、請求項２０乃至請求項３４のいずれか１項に記載のネットワーク。
【請求項３６】
有界エコーアルゴリズムを使用することによって前記ネットワークをサーチするための手段を備える、請求項２０乃至請求項３５のいずれか１項に記載のネットワーク。
【請求項３７】
サーチするための前記手段は、前記必要とされるサービスの少なくとも１つに対する前記サーチを、該サービスを提供するために適切な設定数のノードを検出したときに停止するように構成された、請求項２０乃至請求項３６のいずれか１項に記載のネットワーク。
【請求項３８】
選択するための前記手段は、前記情報を処理するために前記エコーアルゴリズムを使用し、選択されたノードの順序付きリストを前記第１のノードに返すように構成された、請求項２１乃至請求項３８のいずれか１項に記載のネットワーク。
【請求項３９】
コンピュータで実行されるときに、前記コンピュータを請求項１乃至請求項１９のいずれか１項に記載の前記方法ステップに従って動作させる命令を備えるコンピュータプログラム。
【請求項４０】
請求項３９に記載のコンピュータプログラムを記憶するコンピュータ読み取り可能記憶媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公表番号】特表２００８−５３０６７４（Ｐ２００８−５３０６７４Ａ）
【公表日】平成２０年８月７日（２００８．８．７）
【国際特許分類】
【出願番号】特願２００７−５５４６２９（Ｐ２００７−５５４６２９）
【出願日】平成１８年２月６日（２００６．２．６）
【国際出願番号】ＰＣＴ／ＧＢ２００６／０００４０７
【国際公開番号】ＷＯ２００６／０８７５１８
【国際公開日】平成１８年８月２４日（２００６．８．２４）
【出願人】（３９００２８５８７）ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー (104)
【氏名又は名称原語表記】ＢＲＩＴＩＳＨ ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＰＵＢＬＩＣ ＬＩＭＩＴＥＤ ＣＯＭＰＡＮＹ
【公表日】平成２０年８月７日（２００８．８．７）
【国際特許分類】
【出願日】平成１８年２月６日（２００６．２．６）
【国際出願番号】ＰＣＴ／ＧＢ２００６／０００４０７
【国際公開番号】ＷＯ２００６／０８７５１８
【国際公開日】平成１８年８月２４日（２００６．８．２４）
【出願人】（３９００２８５８７）ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー (104)
【氏名又は名称原語表記】ＢＲＩＴＩＳＨ ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＰＵＢＬＩＣ ＬＩＭＩＴＥＤ ＣＯＭＰＡＮＹ
[ Back to top ]