JP2021505989A - エラー・ハンドリングのための方法、コンピュータ・プログラム、データ処理システム、およびエラー・ハンドリング・コンポーネント - Google Patents

Abstract

【課題】方法、コンピュータ・プログラム製品、およびエラー・コンポーネントを提供する。【解決手段】方法、コンピュータ・プログラム製品、およびエラー・コンポーネントは、プロバイダのサービスのためのリクエストをリクエスタから受信することと、リクエストの要件を決定することと、プロセッサによって、リクエストの要件およびサービス・プロバイダの特質に基づいて、エラーをハンドリングするためのハンドリング・アルゴリズムを識別することと、を含み得る。【選択図】図４

Description

本発明は、エラー・ハンドリングに関し、より詳細には、リクエスタ（requester）とプロバイダ（provider）との間のエラー・ハンドリングに関する。

現在、多くのビジネス・プロセスは、サービス指向アーキテクチャ（service-oriented architecture、ＳＯＡ）などの、分散処理アーキテクチャに頼っている。これらのアーキテクチャは、インターネットなどのネットワークを通じたコンポーネント、システム、またはコンピュータ、あるいはその組み合わせの協働を、合意された通信規格、例えば、このようなコンピュータの間の通信のためのメッセージ・フォーマットを必要とせずに促進する。

エラー・ハンドリングの方法、システム、プログラムを提供する。

リクエスタとプロバイダとの間のエラー・ハンドリングのための方法、コンピュータ・プログラム製品、およびエラー・コンポーネントが提供される。コンピューティング・システムのプロセッサがプロバイダのサービスのためのリクエストをリクエスタから受信する。リクエストの要件が決定される。リクエストの要件およびサービス・プロバイダの特質（characteristic）に基づいて、エラーをハンドリングするためのハンドリング・アルゴリズムが識別される。

次に、添付の図面を参照して本発明の実施形態を例としてのみ説明する。

本発明の実施形態に係る、例示の実施形態の態様が実施され得る例示的な分散システムの図的表現である。 本発明の実施形態に係る、例示の実施形態の態様が実施され得る例示的なデータ処理システムのブロック図である。 本発明の実施形態に係る、エラー・ハンドリング・コンポーネントの例示的な一実装形態の簡略ブロック図である。 本発明の実施形態に係るハンドリング・アルゴリズムのフロー図である。 本発明の実施形態に係る、コンピュータ実施方法のフロー図である。 本発明の実施形態に係る、寄与スコアを生成するように構成されたシステムを示す図である。

システムの間の対話の実施は、対話が成功する場合には、比較的容易である。しかし、可能なエラー条件の全ての順列に応じることは、再試行、冪等性、ヘルス・チェック、トランザクション境界（transactional boundary）、一意性競合（uniqueness conflict）、移送信頼性、待ち時間、タイムアウト、およびその他などの課題を理解することを必要とする。コンポーネント、システム、またはコンピュータ、あるいはその組み合わせの間の統合の複雑な側面は、エラー・ハンドリングに関連する。

通例、エラー・ハンドリング・アルゴリズムは、実施される対話ごとに、固有のメッセージ・フロー、またはコネクタ内の専用コードなどの、固有のコードまたは命令を必要とする。したがって、エラー・ハンドリングの実装形態は、通例、固有のものであり、リクエスタのランタイムのプログラミング言語／モデルで書かれている。それゆえ、このような実装形態は、書いて維持することが複雑になり得、それらは再使用も難しくなり得る。

コンポーネント、システム、またはコンピュータ、あるいはその組み合わせの間の共通性が見いだされる場合、それは、通例、Ｊａｖａ（Ｒ）（ＴＭ）コネクタ・アーキテクチャなどの、コード・フレームワーク内に組み込まれるのみであるが、これは言語特定的なアプローチのままであり、対話の個々の機微を解決するためには、相当な追加または固有あるいはその両方の実施作業を依然として必要とする。

新たなコネクタを最小限の労力で書くことができるよう標準化されたコネクタ・フレームワークをしばしば有する、システムの間の統合を可能にするための多くの製品が存在する。コネクタ・フレームワークのうちのいくつかは、新たなコネクタを作成するために必要とされる作業量を低減するために、このような例の１つをＪａｖａ（Ｒ）（ＴＭ）コネクタ・アーキテクチャとして、標準化されている。しかし、これらのコネクタは、通例、プログラミング言語またはランタイムあるいはその両方に特定的であり、それゆえ、１つのプラットフォームのための作成／構成は、別のプラットフォームへの単純な移行／可搬性の要求に応じないことを意味する。また、このようなコネクタは、通例、全アルゴリズムが選定されることを可能にするであろう対話の論理特質に対処するのではなく、再試行回数、またはタイムアウト値などの、エラー・ハンドリングの低レベル特性の要求に応じるのみである。したがって、全体的な対話要件に応じるために、通例、追加のコードまたはフロー論理がリクエスタによって実施されなければならない。

さらに、プロトコルのために標準化されたコネクタを作成する試みは、多くの場合、システムが規格を厳格に順守しないことがしばしばあるという事実を無視しており、これにより、エラー・ハンドリングは対話ごとにコードまたは統合フロー内に戻される。

本発明の実施形態は、（例えば、特注統合コードまたはフロー論理の必要性を無くすことによって）統合実装形態の大幅な単純化をもたらし得る、リクエスタとプロバイダとの間のエラー・ハンドリングのための方法を提供し得る。本発明の実施形態は、データ処理システムのプロセッサ上で実行されたときに本方法を実施するためのコンピュータ・プログラム・コードを含むコンピュータ・プログラム製品をさらに提供し得る。本発明の実施形態は、このコンピュータ・プログラム・コードを実行するように構成されたデータ処理システムをなおさらに提供し得る。本発明の実施形態はまた、リクエスタとプロバイダとの間のエラー・ハンドリングのためのエラー・ハンドリング・コンポーネントを提供し得る。

本発明の一実施形態によれば、リクエスタとプロバイダとの間のエラー・ハンドリングのためのコンピュータ実施方法が提供され得る。本方法は、リクエスタから、プロバイダのサービスのためのリクエストを受信することを含み得る。本方法はまた、リクエストの要件を決定することを含み得る。リクエストの決定された要件およびサービス・プロバイダの特質に基づいて、エラーをハンドリングするためのハンドリング・アルゴリズムを識別することができる。

本発明の実施形態はリクエストの要件およびプロバイダの特質を識別し、その後、識別された要件および特質を用いて、エラーをハンドリングするためのアルゴリズムを決定し得る。リクエスト要件の評価によって、例えば、リクエストがプロバイダにおいてどのように呼び出されるべきであるのかについて決定され得る。

したがって、実施形態は、技術に依存しない仕方による共通／包括的エラー・ハンドリング論理／アルゴリズム／シナリオ／セマンティクスの構成および実施を可能にするためのドメイン固有ポリシー言語（domain-specific policy language）を提供し得、かくして、統合実施コードを低減し、プラットフォームにわたる可搬性をもたらす。このようなポリシー言語は、例えば、広範囲の、様々な、網羅的な、記述的な、特定的な、または要件関連の、あるいはその組み合わせの用語を含む用語集を利用することによって、向上した（例えば、より大きな）リッチネス（richness）をもたらし得る。実施形態によってもたらされるポリシー言語のリッチネスの改善は、改善された、動的な、またはあつらえの、あるいはその組み合わせの論理を有するポリシー・アルゴリズムの提供を可能にし得る。

本発明の例示的な実施形態は、所与の統合上のリクエストを傍受する宣言的エラー・ハンドリング方法を提供し得る。ここで、統合は、リクエスタ要件およびプロバイダ特質のセットによって定義される。これらの要件および特質に基づいて、本方法は、発生し得るエラーを管理するためのアルゴリズムを識別し得る。例えば、アルゴリズムは、欠落した挙動を提供し、標準的でないエラー・レスポンスの再分類を可能にし得る。したがって、例示的な一実施形態は以下の特性を有し得る：
（ｉ） プラットフォーム非依存性 − 実施形態は、特質およびアルゴリズムが包括的であるため、プラットフォーム／言語にわたって用いられ得る、ならびに
（ｉｉ） コードの最小化／除去 − 実施形態は、インターフェース内におけるエラー・ハンドリングのためのカスタム・コードの必要性を低減し得、多くの場合、カスタム・コードの必要性を完全に除去し得、それゆえ、インターフェースを準備するために必要とされるスキルセットを変更する。

インターフェースの特質によってインターフェースを類別することによって、およびクライアント（例えば、リクエスタ）要件のセットを所与として、例示的な実施形態はエラー・ハンドリング・アルゴリズムを識別し、そのアルゴリズムをプロセス・フロー内に投入し得る。投入されたエラー・ハンドリング・アルゴリズムはまた、プロバイダの任意の欠落した特質も提供するように構成され得る。

例示的な一実施形態では、クライアント（例えば、リクエスタ）が「作成」リクエストを行いたいと欲し、信頼できない媒体を用いても構わないが、重複を欲しないという事例を考え得る（例えば、これは、典型的なハイパーテキスト転送プロトコル（Hypertext Transfer Protocol、ＨＴＴＰ）ベースのＲＥＳＴリクエストであり得るであろう）。このような例のために、冪等であるＨＴＴＰインターフェースに適合したプロバイダが存在すると考え得る。投入されたエラー・ハンドラ・アルゴリズムは、再試行が必要とされる場合には、インターフェースを複数回コールし得る。しかし、上述のサービスが冪等でなかった場合には、エラー・ハンドラ・アルゴリズムは、重複を作成するであろう、再試行の代わりに、延期された読み込み（deferred read）を実行し、欠落した「重複なし」のクライアント要件を提供することができるであろう。同様に、信頼できる媒体が必要とされる場合には、コールは、ウェブ・サーバ・リクエストを介するのではなく、メッセージングを通じて橋渡しすることができ、この場合も先と同様に、投入されたエラー・ハンドラは、欠落したインターフェース特質を作り出す。

本発明の例示的な実施形態は、構成可能なオーバーライド・ポリシーがプロトコルの標準的でない実施を再整列させることを可能にするように構成され得る。

例示的な実施形態は、以前は、対話ごとに特定的にコード化されるか、または構成されるか、あるいはその両方を行われなければならなかったであろう、広範なエラー回復シナリオを表現し得る、エラー回復セマンティクスの表現のためのドメイン固有ポリシー言語を提供し得る。それゆえ、複数の技術にわたって、エラー・ハンドリング要件が論理的に一度定義され、その後、純粋に構成によって実施されることを可能にし得る、技術に依存しない仕方で対話の特質を記述するドメイン固有ポリシー言語に基づいて、エラー・ハンドリング論理（例えば、ポリシー・アルゴリズム）が選定され、実施されることを可能にするコンポーネントが提供され得る。

したがって、例示的な実施形態によってもたらされる恩恵は以下のものを含み得る：
（ｉ） 統合実装形態の大幅な単純化 − 実施形態は、さもなければ、通例、プロトコルごとに書かれ、サービス動作ごとにさらにカスタマイズされるであろう特注統合コードまたはフロー論理を解消し得る、
（ｉｉ） コネクタの発展の加速、
（ｉｉｉ） 共通構成を介した、実施された統合の、異なる言語のランタイムへの単純な移行、ならびに
（ｉｖ） アルゴリズムの標準化。これにより、エラー・ハンドリング挙動が決定論的になり、深く理解され得る − 統合回帰試験の準備および実行を大幅に単純化する。

したがって、上述された恩恵は、エラー・ハンドリングの抜本的な単純化によって現況技術の改善をもたらし得る。

例示的な実施形態によれば、技術に依存しない仕方によるエラー・ハンドリング・アルゴリズムの構成および実施を可能にするコンポーネントを用いるドメイン固有ポリシー言語が提供され得、これにより、統合実施コードが低減されるか、プラットフォームにわたる可搬性の改善がもたらされるか、あるいはその両方がなされ得る。

エラー・ハンドリング・アルゴリズムは、対話に関する論理特質の主要なセットによって統御され得る。例としては、プロバイダ・インターフェースを、重複を生じさせることなく安全に再試行することができるかどうか（例えば、冪等性）、リクエスタが即座のレスポンスを期待するかどうか（例えば、ブロッキング）、および対話が完了しなければならない時間フレームがどれであるのかを挙げることができる。これらの特質は技術に依存せず、リクエスタの要件、プロバイダの能力、およびアルゴリズムを実施するコンポーネントの能力にのみ関連し得る。これらの特質に基づいて、エラー・ハンドリングを遂行する仕方のための特定のポリシー・アルゴリズムを選定することができる。アルゴリズムは技術に非依存的であり得、これにより、アルゴリズムは、任意のプログラミング言語によって実施のための論理レベルで記述することができる。

例示的な一実施形態では、リクエストの要件は、重複の容認性（acceptability of duplicates）、リクエスタによって必要とされる確認、レスポンス・タイム、スループット、およびトランザクション参加（transaction participation）のうちの少なくとも１つに関連し得る。したがって、このような実施形態は、実施すべきエラー・ハンドリング・アルゴリズムを決定するために、リクエストに関連する限定因子または考慮事項を考慮し得る。他の異なる要件が本発明の実施形態によって決定されるか、または対応されるか、あるいはその両方を行われてもよく、これらは、単独で、または組み合わせて考慮され得る。

例示的な一実施形態では、プロバイダの特質は、プロバイダのインターフェース、プロバイダの通信プロトコル、チェック試験の利用可能性、レスポンス・タイム、スループット、プロバイダの対話方法、プロバイダの冪等能力（idempotent capability）、プロバイダの同期または非同期性、１つまたは複数のエラー種別、トランザクション支援、およびプロバイダの挙動特徴（behavioral trait）のうちの少なくとも１つに関連し得る。したがって、実施形態は、実施すべきエラー・ハンドリング・アルゴリズムを決定するために、プロバイダに関連する限定因子または考慮事項を考慮し得る。他の異なる特質が本発明の実施形態によって決定されるか、または対応されるか、あるいはその両方を行われてもよく、これらは、単独で、または組み合わせて考慮され得る。

したがって、本発明の実施形態は、最も適切なエラー・ハンドリング・アルゴリズムを決定するために、リクエスタとプロバイダとの間の対話の要件および特質を分析するというコンセプトを利用し得る。このように、例示的な実施形態は、プログラミングまたは実施あるいはその両方の複雑さを低減しつつ、エラーが低減されるか、ハンドリングされるか、処理されるか、または管理されるか、あるいはその組み合わせを行われることを確実にするために適切なエラー・ハンドリング論理またはプロセス・ステップを決定するように設計され得る。

例示的な一実施形態では、ハンドリング・アルゴリズムを識別するステップは、リクエストの決定された要件およびプロバイダの決定された特質に基づいて、複数のアルゴリズムからハンドリング・アルゴリズムを選択することを含み得る。したがって、潜在的なハンドリング・アルゴリズムの集中または共有リソースが実施形態によって活用され得る。また、ハンドリング・アルゴリズムを選択することは、リクエストの決定された要件またはプロバイダの決定された特質が所定の通信プロトコルに関連するかどうかに基づいて、ハンドリング・アルゴリズムを選択することを含み得、これは、特定の通信プロトコルのための、以前の、または確立されたエラー・ハンドリング知識が役立てられ、用いられることを可能にし得、それゆえ、さもなければ、ハンドリング・アルゴリズムを実施するために必要とされるであろう専門家または特注プログラミングあるいはその両方の量を潜在的に低減する。

例示的な一実施形態では、ハンドリング・アルゴリズムを識別するステップは、例えば、最良適合評価に従ってハンドリング・アルゴリズムを選択することを含み得る。このように、対話の決定された詳細（例えば、要件および特質）のための最も適切なハンドリング・アルゴリズムの評価が行われ得、その後、結果が、用いるべきハンドリング・アルゴリズムを識別するために用いられ得る。

ハンドリング・アルゴリズムは、プロバイダへのリクエストの送達を保証するように構成され得る。例えば、ハンドリング・アルゴリズムは、プロバイダへのリクエストの送達を保証するために、再試行手順、延期手順、比較、および併合手順のうちの少なくとも１つを実施するように構成され得る。したがって、実施形態によって利用されるアルゴリズムは、リクエストを正しく呼び出すことができるか、またはエラー・レスポンスを正しく処理することができるか、あるいはその両方をできることを確実にするために、欠落した、または必要とされるプロセスを提供し得る。

いくつかの実施形態は、プロバイダの特質を決定するステップを含み得る。例示的な実施形態は、プロバイダの１つまたは複数の特質に関連する情報をデータ・リポジトリから得るステップを含み得る。例えば、プロバイダの特質が設計段階の間に（例えば、設計時に）決定され得、その後、以前に決定された特質に関する情報が実行時に参照され得、それゆえ、実行時のリソース要件を最小限に抑える。

本発明の別の例示的な実施形態によれば、リクエスタとプロバイダとの間のエラー・ハンドリングのためのコンピュータ・プログラム製品であって、コンピュータ・プログラム製品が、プログラム命令が具現化されたコンピュータ可読記憶媒体を含み、プログラム命令が、データ処理システムの少なくとも１つのプロセッサ上で実行されたときに、処理ユニットに、１つまたは複数の例示的な実施形態に係る方法を遂行させるように処理ユニットによって実行可能である、コンピュータ・プログラム製品が提供される。

さらに別の例示的な実施形態によれば、データ処理システムであって、少なくとも１つのプロセッサと、１つまたは複数の実施形態に係るコンピュータ・プログラム製品とを備え、少なくとも１つのプロセッサが、コンピュータ・プログラム製品のコンピュータ・プログラム・コードを実行するように構成されている、データ処理システムが提供される。データ処理システムは、メッセージ・プロデューサとメッセージ・コンシューマとの間のメッセージ・ブローカの役割を果たすように構成され得る。さらに、データ処理システムは、サービス指向アーキテクチャの一部を実施するように構成され得る。

したがって、実施形態は、インターネットなどのネットワークを通じたサービスの提供のためにサービス指向アーキテクチャ（ＳＯＡ）内で利用され得る。この目的を達成するために、ＳＯＡは、通例、必要とされるメッセージ（例えば、リクエスト）変換またはデータ抽出を実施するソフトウェア・モジュールである、メッセージ・ブローカを含む。メッセージ・ブローカは、メッセージ内の各データ・フィールドが包含することができる内容の構造および形式を定義する、いわゆるメッセージ・スキーマへのアクセスを有し得る。

さらに別の例示的な実施形態によれば、リクエスタとプロバイダとの間のエラー・ハンドリングのためのエラー・ハンドリング・コンポーネントが提供される。コンポーネントは、リクエスタから、プロバイダのサービスのためのリクエストを受信するように構成された入力インターフェースを備える。コンポーネントはまた、リクエストの要件を決定するように構成された分析コンポーネントを含み得る。さらに、コンポーネントは、リクエストの決定された要件およびサービス・プロバイダの特質に基づいて、エラーをハンドリングするためのハンドリング・アルゴリズムを決定するように構成されたアルゴリズム・コンポーネントを備える。

例示的な実施形態は、所与の統合上のリクエストを傍受するように構成された、技術に依存しない宣言的エラー・ハンドリング・コンポーネントを提供し得る。ここで、統合は、リクエスタ要件およびプロバイダ特質のセットによって定義され得る。プロバイダの能力などの、リクエスタの要件およびプロバイダの特質に基づいて、コンポーネントはエラー・ハンドリング・アルゴリズムを選択して実施し、欠落した挙動を提供し、標準的でないエラー・レスポンスの再分類を可能にするなど、発生し得るエラーを管理し得る。

それゆえ、コンポーネントは、任意の対話に対するインターセプタとして構成され得、さもなければ、発生し得るであろうエラーの複数の順列を管理するために必要とされ得る固有／カスタム・コード化の必要性を軽減する。コンポーネントの実施形態は、技術に依存しない特質を用い、いかなる言語、プロトコル、または移送にも特定的でない論理アルゴリズムを実施し得る。その後、このような論理アルゴリズムは複数の言語ランタイムにわたって実施され得、これにより、一旦、所与の対話のための特質が合意されれば、複数の言語にわたってコネクタを提供することは、単に、構成をコピーするだけの問題になり得る。

また、本出願の文脈において、データ処理システムは、本発明の方法の１つまたは複数の実施形態を実行するように構成された単一のデバイス、または分散デバイスの集合であり得る。例えば、システムは、パーソナル・コンピュータ（personal computer、ＰＣ）、サーバ、あるいは本発明の方法の少なくとも１つの実施形態を協働して実行するためにローカル・エリア・ネットワーク、インターネット等などのネットワークを介して接続されたＰＣまたはサーバあるいはその両方の集合であり得る。

本発明の実施形態は、リクエスタとプロバイダとの間のエラー・ハンドリングに関する。リクエストの１つまたは複数の要件およびプロバイダの１つまたは複数の特質の評価によって、エラーをハンドリングするためのアルゴリズムが決定され得る。したがって、例示的な実施形態は、技術に依存しない仕方による共通／包括的エラー・ハンドリング論理／アルゴリズム／シナリオ／セマンティクスの構成および実施を可能にし得、かくして、統合実施コードを低減し、プラットフォームにわたる可搬性をもたらす。

例えば、本発明の実施形態は、所与の統合上のリクエストを傍受する宣言的エラー・ハンドリング・コンセプトを提供し得る。ここで、統合は、リクエスタ要件およびプロバイダ特質のセットによって定義される。これらの要件および特質に基づいて、エラーを管理するためのアルゴリズムが識別され、その後、利用され得る。インターフェースの特質によってインターフェースを類別することによって、およびクライアント（例えば、リクエスタ）要件のセットを所与として、例示的な実施形態はエラー・ハンドリング・アルゴリズムを識別し、そのアルゴリズムをプロセス・フロー内に投入し得る。投入されたエラー・ハンドリング・アルゴリズムはまた、例えば、プロバイダの任意の欠落した特質も提供するように構成され得る。

したがって、例示的な実施形態は、統合要件または特質あるいはその両方を分析し、最も適切なエラー・ハンドリング・プロセスを決定し得る。したがって、動的なエラー・ハンドリングの最適化が本提案の実施形態によってもたらされ得る。

下流の呼び出しは規格を順守するように見える場合があるが、呼び出しは、その規格の「スタイル」を厳格に実施しない場合がある。例えば、呼び出しは、ＨＴＴＰレスポンス・コードを正しく用いない場合があるか、または真にＲＥＳＴｆｕｌでない場合があるか、またはＳＯＡＰフォルトを正しく用いない場合がある。これらの小さな機微は、実際にはエラーでないエラーを管理するため、または実はエラー・レスポンスであった、一見したところ成功のレスポンスの提供のため、あるいはその両方のためのコードなどの、過剰な量のレスポンス・ハンドリング・コードの必要性を生じさせ得る。本発明の実施形態は、既知のスタイルを誤用しているターゲットを、より適合したレスポンスに再形成することができるよう、レスポンス・オーバーライドを構成し得る。これにより、エラー・ハンドリング・アルゴリズムが個々のインターフェースの機微に応じる必要がなくなるため、エラー・ハンドリング・アルゴリズムの再利用可能性が大幅に改善され得る。

例示的な実施形態は、統合要件の進展に応じるために新たな特質およびアルゴリズムを追加することができるよう、拡張可能であり得る。例えば、分散処理の分野における近年の発展は、大部分の統合が、信頼性の高い制御された移送およびトランザクション性の高いプロトコルに基づくことから、トランザクション性がなく、信頼できない媒体を通じて遂行されるウェブ・サービスおよびＲＥＳＴｆｕｌなインターフェースに移った。このような発展は新たな特質およびアルゴリズムを導入するが、宣言的エラー・ハンドリング・コンポーネントの核心的意図は同じままとなるであろう。

システムの間の対話のための方法またはコンポーネントの例示的な実施形態は、要件、または対話の特質、あるいはその両方に関するいくつかの高レベルの問いに対処し得る。例が以下において詳述されているが、他の実施形態が、本明細書において提案されるコンセプトを用いて実施され得ることを理解されたい。

また、本提案のコンセプトの価値および効用を高め得る、従来のエラー・ハンドリング・コンセプトに対する変更および追加のステップも提案され得る。

例示的な実施形態は多くの異なる種類の処理環境において利用され得る。例示的な実施形態の要素および機能性の説明のための文脈を提供するために、図１および図２が、以下において、例示的な実施形態の態様が実施され得る例示的な環境として提供される。図１および図２は単なる例にすぎず、本発明の実施形態の態様が実施され得る環境に関するいかなる限定を主張または示唆することも意図されていない。図示の環境に対する多くの変更が、本発明の思想および範囲から逸脱することなくなされ得る。

図１は、本発明の実施形態に係る、例示の実施形態の態様が実施され得る例示的な分散システムの図的表現を示す。分散システム１００は、例示的な実施形態の態様が実施され得るコンピュータのネットワークを含み得る。分散システム１００は、分散データ処理システム１００内で互いに接続された様々なデバイスおよびコンピュータの間の通信リンクを提供するために用いられる媒体である、少なくとも１つのネットワーク１０２を包含する。ネットワーク１０２は、有線、無線通信リンク、または光ファイバ・ケーブルなどの、接続を含み得る。

図示の例では、第１のサーバ１０４および第２のサーバ１０６が記憶ユニット１０８と共にネットワーク１０２に接続されている。加えて、クライアント１１０、１１２、および１１４もネットワーク１０２に接続されている。クライアント１１０、１１２、および１１４は、例えば、パーソナル・コンピュータ、ネットワーク・コンピュータ、または同様のものであり得る。図示の例では、第１のサーバ１０４は、ブート・ファイル、オペレーティング・システム・イメージ、およびアプリケーションなどのデータをクライアント１１０、１１２、および１１４に提供する。クライアント１１０、１１２、および１１４は、図示の例では、第１のサーバ１０４に対するクライアントである。分散処理システム１００は、図示されていない追加のサーバ、クライアント、および他のデバイスを含み得る。

図示の例では、分散システム１００はインターネットであり、ネットワーク１０２は、互いに通信するためのプロトコルの伝送制御プロトコル／インターネット・プロトコル（Transmission Control Protocol/Internet Protocol、ＴＣＰ／ＩＰ）群を用いるネットワークおよびゲートウェイの世界的規模の集合を表す。インターネットの中核には、データおよびメッセージを経路制御する、数千もの民営、官営、教育、および他のコンピュータ・システムから成る、大ノードまたはホスト・コンピュータの間の高速データ通信線のバックボーンがある。無論、分散システム１００はまた、例えば、イントラネット、ローカル・エリア・ネットワーク（local area network、ＬＡＮ）、ワイド・エリア・ネットワーク（wide area network、ＷＡＮ）、または同様のものなどの、いくつかの異なる種類のネットワークを含むように実施されてもよい。上述されたように、図１は一例として意図されており、本発明の異なる実施形態のためのアーキテクチャ上の限定として意図されておらず、したがって、図１に示される特定の要素は、本発明の例示的な実施形態が実施され得る環境に関する限定と考えられるべきでない。

図２は、本発明の実施形態に係る、例示の実施形態の態様が実施され得る例示的なシステム２００のブロック図を示す。システム２００は、本発明の例示の実施形態のためのプロセスを実施するコンピュータ使用可能コードまたは命令が配置され得る、図１におけるクライアント１１０などの、コンピュータの一例である。

図示の例では、システム２００は、ノース・ブリッジおよびメモリ・コントローラ・ハブ（north bridge and memory controller hub、ＮＢ／ＭＣＨ）２０２、ならびにサウス・ブリッジおよび入力／出力（Ｉ／Ｏ）コントローラ・ハブ（south bridge and input/output controller hub、ＳＢ／ＩＣＨ）２０４を含むハブ・アーキテクチャを利用し得る。処理ユニット２０６、主メモリ２０８、およびグラフィック・プロセッサ２１０がＮＢ／ＭＣＨ２０２に接続されている。グラフィック・プロセッサ２１０は、アクセラレイティッド・グラフィックス・ポート（accelerated graphics port、ＡＧＰ）を通じてＮＢ／ＭＣＨ２０２に接続されていてもよい。

図示の例では、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ２１２がＳＢ／ＩＣＨ２０４に接続している。オーディオ・アダプタ２１６、キーボードおよびマウス・アダプタ２２０、モデム２２２、リード・オンリー・メモリ（read only memory、ＲＯＭ）２２４、ハード・ディスク・ドライブ（hard disk drive、ＨＤＤ）２２６、ＣＤ−ＲＯＭドライブ２３０、ユニバーサル・シリアル・バス（universal serial bus、ＵＳＢ）ポートおよび他の通信ポート２３２、ならびにＰＣＩ／ＰＣＩｅデバイス２３４が、第１のバス２３８および第２のバス２４０を通じてＳＢ／ＩＣＨ２０４に接続している。ＰＣＩ／ＰＣＩｅデバイスは、例えば、イーサネット（Ｒ）アダプタ、アドイン・カード、およびノートブック・コンピュータのためのＰＣカードを含み得る。ＰＣＩはカード・バス・コントローラを用い、その一方で、ＰＣＩｅは用いない。ＲＯＭ２２４は、例えば、フラッシュ基本入力／出力システム（basic input/output system、ＢＩＯＳ）であり得る。

ＨＤＤ２２６およびＣＤ−ＲＯＭドライブ２３０は第２のバス２４０を通じてＳＢ／ＩＣＨ２０４に接続している。ＨＤＤ２２６およびＣＤ−ＲＯＭドライブ２３０は、例えば、インテグレーティッド・ドライブ・エレクトロニクス（integrated drive electronics、ＩＤＥ）またはシリアル・アドバンスド・テクノロジー・アタッチメント（serial advanced technology attachment、ＳＡＴＡ）インターフェースを用い得る。スーパーＩ／Ｏ（Super I/O、ＳＩＯ）デバイス２３６がＳＢ／ＩＣＨ２０４に接続され得る。

オペレーティング・システムが処理ユニット２０６上で実行する。オペレーティング・システムは図２におけるシステム２００内の様々なコンポーネントを協調させ、これらを制御する。クライアントとして、オペレーティング・システムは市販のオペレーティング・システムであり得る。Ｊａｖａ（Ｒ）（ＴＭ）プログラミング・システムなどの、オブジェクト指向プログラミング・システムがオペレーティング・システムと連係して実行でき、システム２００上で実行するＪａｖａ（Ｒ）（ＴＭ）プログラムまたはアプリケーションからオペレーティング・システムにコールを提供する。

サーバとして、システム２００は、例えば、新型対話型エクゼクティブ（Advanced Interactive Executive、ＡＩＸ（Ｒ））オペレーティング・システムまたはＬＩＮＵＸ（Ｒ）オペレーティング・システムを実行する、ＩＢＭ（Ｒ）ｅＳｅｒｖｅｒ（ＴＭ）Ｓｙｓｔｅｍ ｐ（Ｒ）コンピュータ・システムであり得る。システム２００は、処理ユニット２０６内に複数のプロセッサを含む対称型マルチプロセッサ（symmetric multiprocessor、ＳＭＰ）システムであり得る。代替的に、単一プロセッサ・システムが利用されてもよい。

オペレーティング・システム、プログラミング・システムのための命令、ならびにアプリケーションまたはプログラムは、ＨＤＤ２２６などの、記憶デバイス上に配置されており、処理ユニット２０６による実行のために主メモリ２０８内にロードされ得る。同様に、一実施形態に係る１つまたは複数のメッセージ処理プログラムが、記憶デバイスまたは主メモリ２０８あるいはその両方によって記憶されるように構成され得る。

本発明の例示的な実施形態のためのプロセスは、処理ユニット２０６によって、例えば、主メモリ２０８、ＲＯＭ２２４などの、メモリ内、または１つもしくは複数の周辺デバイス２２６および２３０内に配置され得る、コンピュータ使用可能プログラム・コードを用いて遂行され得る。

図２に示されるとおりの第１のバス２３８または第２のバス２４０などの、バス・システムは１つまたは複数のバスを含み得る。無論、バス・システムは、ファブリックまたはアーキテクチャに取り付けられた異なるコンポーネントまたはデバイスの間のデータの転送を提供する任意の種類の通信ファブリックまたはアーキテクチャを用いて実施され得る。図２のモデム２２２またはネットワーク・アダプタ２１２などの、通信ユニットは、データを送信および受信するために用いられる１つまたは複数のデバイスを含み得る。メモリは、例えば、主メモリ２０８、ＲＯＭ２２４、または図２におけるＮＢ／ＭＣＨ２０２において見いだされるものなどのキャッシュであり得る。

図１および図２におけるハードウェアは実装形態に依存して異なり得る。フラッシュ・メモリ、同等の不揮発性メモリ、または光ディスク・ドライブ、および同様のものなどの、他の内部ハードウェアまたは周辺デバイスが、図１および図２に示されるハードウェアに加えて、またはその代わりに用いられてもよい。また、例示的な実施形態のプロセスは、本発明の思想および範囲から逸脱することなく、上述されたシステム以外の、マルチプロセッサ・データ処理システムにも適用され得る。

さらに、システム２００は、クライアント・コンピューティング・デバイス、サーバ・コンピューティング・デバイス、タブレット・コンピュータ、ラップトップ・コンピュータ、電話もしくは他の通信デバイス、パーソナル・デジタル・アシスタント（personal digital assistant、ＰＤＡ）、または同様のものを含むいくつかの異なるデータ処理システムのうちの任意のものの形態を取り得る。例示の例によっては、システム２００は、フラッシュ・メモリを用いて、例えば、オペレーティング・システム・ファイルまたはユーザ生成データあるいはその両方を記憶するための不揮発性メモリを提供するように構成されたポータブル・コンピューティング・デバイスであり得る。それゆえ、システム２００は、アーキテクチャ上の制限なく、本質的に、任意の公知の、または将来開発されるデータ処理システムであり得る。

次に図３を参照して、これより、一実施形態に係るエラー・ハンドリング・コンポーネント３００の例示的な一実装形態が説明される。図３は、本発明の実施形態に係る、エラー・ハンドリング・コンポーネント３００の例示的な一実装形態の簡略ブロック図を示す。エラー・ハンドリング・コンポーネント３００は、サービスをリクエストするネットワーク・ノードなどの、リクエスタ３１０と、受信されたリクエストに応答して１つまたは複数のサービスを提供するように構成されたネットワーク・ノードなどの、プロバイダ３２０との間のエラー・ハンドリングのためのものであり得る。

エラー・ハンドリング・コンポーネント３００は、リクエスタ３１０から、プロバイダ３２０のサービスのためのリクエスト３０５を受信するように構成された入力インターフェース３３０を備え得る。

入力インターフェース３３０は、受信されたリクエスト３０５をエラー・ハンドリング・コンポーネント３００の分析コンポーネント３４０に渡すように構成され得る。

分析コンポーネント３４０は、リクエスト３０５の要件を決定するように構成され得る。例示的な一実施形態では、分析コンポーネント３４０は、エラー・ハンドリング・コンポーネント３００の一部としてプロビジョニングされたデータベース３４５にアクセスするように構成され得、データベース３４５は、リクエスト、リクエスタ、またはプロバイダあるいはその組み合わせの要件もしくは特質またはその両方に関連する情報を記憶するように構成され得る。このような情報は、例えば、リクエスト特性、リクエスタ要件、リクエスタ特質、プロバイダ特質、ノード能力、インターフェース能力、ならびに同様のものに関する情報を含み得る。データベース３４５からのこのような情報をリクエスト３０５と組み合わせて用いて、分析コンポーネントは、リクエストの１つまたは複数の要件を決定するように構成され得る。決定された要件は、例えば、重複の容認性、リクエスタによって必要とされる確認、レスポンス・タイム、スループット、またはトランザクション参加、あるいはその組み合わせに関連し得る。

分析コンポーネント３４０はまた、プロバイダの特質を識別するように構成され得る。例えば、分析コンポーネント３４０は、データベース３４５にアクセスし、データベース３４５からの情報をリクエスト３０５と組み合わせて用いて、プロバイダ３２０の１つまたは複数の特質を決定するように構成され得る。このように、データベース３４５は、設計または作成段階において決定されたプロバイダ３２０の特質に関する情報を記憶し得、その後、情報は、単に実行時に分析コンポーネント３４０によって参照されるのみであり得る。決定される特質は、例えば、プロバイダのインターフェース、プロバイダの通信プロトコル、チェック試験の利用可能性、レスポンス・タイム、スループット、プロバイダの対話方法、プロバイダの冪等能力、プロバイダの同期または非同期性、１つまたは複数のエラー種別、トランザクション支援、およびプロバイダの挙動特徴に関連し得る。

分析コンポーネント３４０は、リクエストの決定された要件およびプロバイダの決定された特質に関する情報をエラー・ハンドリング・コンポーネント３００のアルゴリズム・コンポーネント３５０に渡すように構成され得る。リクエストの決定された要件およびプロバイダの決定された特質に関する情報に基づいて、アルゴリズム・コンポーネント３５０は、エラーをハンドリングするためのハンドリング・アルゴリズムを決定するように構成され得る。この目的のために、アルゴリズム・コンポーネント３５０は、エラー・ハンドリング・コンポーネント３００の一部としてプロビジョニングされた第２のデータベース３５５の情報にアクセスするように構成され得る。第２のデータベース３５５は、例えば、例として、利用可能なアルゴリズムまたはアルゴリズム選択規則あるいはその両方のセットなどの、ハンドリング・アルゴリズムの決定のために有用な情報を記憶し得る。

例示的な一実施形態では、アルゴリズム・コンポーネント３５０は、リクエストの決定された要件およびプロバイダの決定された特質に基づいて、複数のアルゴリズムからハンドリング・アルゴリズムを選択し得る。例えば、アルゴリズム・コンポーネント３５０は、リクエストの決定された要件またはプロバイダの決定された特質あるいはその両方が所定の通信プロトコルに関連するかどうかに基づいて、ハンドリング・アルゴリズムを選択し得る。例えば、アルゴリズム・コンポーネント３５０は、共通プロトコル（例えばＳＯＡＰ／ＨＴＴＰ）、または実際には、共通システムのためのアルゴリズム選択規則を利用し、その後、アルゴリズムを再使用するか、またはアルゴリズムを同様の終点のための始点として用い得る。

代替的に、または追加的に、アルゴリズム・コンポーネント３５０は最良適合評価に従ってハンドリング・アルゴリズムを選定してもよい。

アルゴリズム・コンポーネント３５０は、選択されたハンドリング・アルゴリズムをエラー・ハンドリング・コンポーネント３００の実行コンポーネント３６０に渡し得、実行コンポーネント３６０は、ハンドリング・アルゴリズムに従ってプロバイダ３２０においてリクエストを呼び出すように構成され得る。実行コンポーネント３６０は、リアル・タイムに（例えば、実行時に）行われ得る、リクエスト呼び出しまたはエラー管理あるいはその両方のハンドリングを促進するために、ハンドリング・アルゴリズムのランタイム実行を企て得る。

図３のエラー・ハンドリング・コンポーネント３００の一実装形態を実際に示すために、ハンドリング・アルゴリズムは、プロバイダ３２０へのリクエスト３０５の送達を保証するように構成され得、この目的のために、ハンドリング・アルゴリズムは、プロバイダへのリクエストの送達を保証するために、再試行手順、延期手順、比較、および併合手順のうちの少なくとも１つを実施し得る。

例示的な一実施形態に係るエラー・ハンドリング・コンポーネント３００の上述の説明から、リクエスタ３１０とプロバイダ３２０との中間に位置し得る宣言的エラー・ハンドラ・コンポーネント３００が提供され得る。

コンポーネント３００の実施形態は、リクエスタ・ランタイム内、ブローカもしくはコネクタなどの、中間のミドルウェア内、またはプロバイダ内でプロビジョニングされ得る。実施形態は、リクエスタ要件およびプロバイダ特質を選択規則のセットと組み合わせて用いて、適切なエラー・ハンドリング・アルゴリズムを選択し得る。これは設計時に（例えば、性能の理由のために）行われてもよく、または選択は、例えば、実行時に行われ、キャッシュされてもよい。

エラー・ハンドリング・アルゴリズムを決定するための考慮事項は、（ｉ）プロバイダ・インターフェース特質、（ｉｉ）リクエスタ要件、および（ｉｉｉ）コンポーネント能力などの、いくつかの異なるカテゴリに分割され得る。

（Ｉ）プロバイダ・インターフェース特質
プロバイダ・インターフェース特質は、プロバイダ・インターフェースについての特質を含み得る。例としては、移送媒体が対話の確実性をもたらすかどうか（例えば、未確定（in-doubt）リクエストが可能か）、プロバイダがリクエストを受け付けるかどうかを調べるためのヘルス・チェック試験が利用可能かどうか、どのようなレスポンス・タイムが達成可能であるか、どのようなスループットが達成可能であるか、どのようなセッション／接続が効率性のために別個の対話にわたって保持される必要があるか、ならびにインターフェースのために提供されたクライアントが、ブロッキングを生じさせるのか、コール・バックを生じさせるのか、それともポーリング・スタイルの対話を生じさせるのかを挙げることができる。

上述のもののうちのいくつかを含む、これらの特質の多くは、プロバイダ・インターフェース上の異なる動作のために異なり得ることに留意されたい。多くの場合、動作固有である特質の例としては、対話がデータの「読み込み」のみを遂行するのか、それとも「データの変更」をもたらすのか − 「変更」は、作成、更新、抹消等にさらに分けることができるであろう − 、インターフェースが冪等であるかどうか（重複リクエストをハンドリングするかどうか）、プロバイダがアクションを即座に遂行するのかどうか、またはリクエストが肯定応答をもって応答された後に完了が非同期的に行われるのかどうか、アクションが予想よりも長くかかった場合には、プロバイダがどのように、いつ挙動することになるのか − 例えば、タイムアウトおよびロールバック、または受信の肯定応答をもって応答し、非同期的に継続するか、または未確定ステータスをもって応答する − 、を挙げることができる。

無論、上述のものの多くは、別のインターフェースが本システムに実装された場合には、既知であり得る。プロバイダが、ウェブ・サービス、またはＲＥＳＴ、またはＪａｖａ（Ｒ）（ＴＭ）データベース・コネクティビティ（Java Database Connectivity、ＪＤＢＣ）などの、プロトコルおよび移送のためのよく知られた規格を用いている場合には、特質のうちのいくつかは容易に導き出され得る。

（ＩＩ）リクエスタ要件
リクエスタ要件は、プロバイダとの対話に関するリクエスタの必要／期待に関連する要件を含み得る。例としては、重複が容認可能であろうかどうか、リクエスタが、アクションがバックエンド・システム内で即座に行われたことの確認を（すなわち、それが継続することができる前に）必要とするかどうか、または延期された確認で十分であろうかどうか、または実際には、確認が必要ないかどうか、どのようなレスポンス・タイムが必要であるのか、およびどのようなスループットが必要であるのかを挙げることができる。

（ＩＩＩ）コンポーネント能力
コンポーネント能力は、宣言的エラー・ハンドラ（Declarative Error Handler、ＤＥＨ）コンポーネントが利用可能な能力を含み得る。例としては、例えば、リクエストのためのレスポンス・タイム予想の差を管理するための、レスポンス・キャッシング、記憶転送（例えば、イベント記憶）、および例えば、処理されたトランザクションのユニーク・キー記憶を挙げることができる。

例示的なポリシー用語集
上述のことに基づき、ポリシー・アルゴリズムの論理を作り上げるための用語集は以下のようになり得る：
− リクエスタ要件。これは、受信するリクエストによってオーバライドされ得る：重複が問題となる、ブロッキング、ＳＬＡ、およびトランザクション参加。
− リクエスタ特質：重複が可能。
− プロバイダ特質：動作動詞、動作種別、現在の状態が読み込み可能か？、冪等／再試行可能、保証された完了時間（assured completion time）、プロトコル同期／非同期、エラー種別、動作状態、トランザクション支援。
− アルゴリズム：保証された送達
− サブアルゴリズム：再試行、比較、併合。
− コンポーネント能力：サービス品質保証（Service-Level Agreement、ＳＬＡ）測定。

例示的な一実施形態において、次に、ＨＴＴＰベースのＳＯＡＰリクエストを含む一例が考察される。このような例のために、特定のプロバイダは、「冪等である」、「信頼できない媒体」を通じた「作成」動作のインターフェース特質を有し得、リクエスタ要件は、「重複なし」であることであり得るであろう。本発明の実施形態は、リクエスタ要件およびインターフェース特質を識別し、「信頼できない媒体を通じた作成」アルゴリズムなどのハンドリング・アルゴリズムを識別（例えば、選択）し得る。その後、リクエストは、リクエスタ要件「重複なし」、および「冪等でない」のインターフェース特質を用いてアルゴリズムに従ってプロバイダ上で呼び出され得る。

図４に、このようなアルゴリズムの一例がフロー図として示されている。図４は、本発明の実施形態に係るハンドリング・アルゴリズムのフロー図を示す。このようなアルゴリズムのために、同期トランスポート・プロトコル（例えば、ＨＴＴＰ）が利用されること、および信頼できない通信媒体（例えば、インターネット）が利用されることが仮定されている。

アルゴリズムはステップ４１０において開始し、作成動作を実施するステップ４１５に進む。作成動作が成功した場合には、本方法は、成功を報告するステップ４２０に進む。しかし、ステップ４１５の作成動作のゆえに永久エラーが生じた場合には、本方法は、失敗を報告するステップ４２５に進む。ステップ４１５の作成動作のゆえに、一時エラーが生じた場合には、本方法は、重複が問題となるか否かを判定するステップ４３０に進む。

重複が実際に問題となる場合には、本方法は、作成動作を再試行するステップ４３５に進む。逆に、重複が問題とならない場合には、本方法は、インターフェースが冪等であるか否かを判定するステップ４４０に進む。インターフェースが冪等である場合には、本方法はステップ４３５に進む。

ステップ４３５の作成動作の再試行のゆえに、一時エラーが生じた場合には、本方法は、一時エラーを報告するステップ４４０に進む。ステップ４３５における作成動作の再試行が成功した場合には、本方法は、成功を報告するステップ４４５に進む。しかし、ステップ４３５における作成動作の再試行のゆえに永久エラーが生じた場合には、本方法は、エラーを報告するステップ４５０に進む。

インターフェースが冪等であるか否かを判定する、ステップ４４０の考察に戻ると、インターフェースが冪等でない場合には、本方法はステップ４６０に進む。ステップ４６０において、読み込み動作が利用可能であるか否かを判定する。読み込み動作が利用可能でないと判定された場合には、本方法は、未確定の指示を提供するステップ４６５に進む。逆に、ステップ４６０において、読み込み動作が利用可能であると判定された場合には、本方法は、作成動作のための保証された完了時間が存在するかどうかを判定するステップ４７０に進む。

ステップ４７０において、作成動作のための保証された完了時間が存在すると判定された場合には、本方法は、延期された読み込み動作を企てるステップ４７５に進む。ステップ４７５における延期された読み込みが存在を指示する場合には、本方法は、成功を報告するステップ４８０に進む。逆に、ステップ４７５における延期された読み込みが不存在を指示する場合には、本方法は本方法の開始４１０に戻る。

しかし、ステップ４７０において、作成動作のための保証された完了時間が存在しないと判定された場合には、本方法は、読み込み動作を企てるステップ４８５に進む。ステップ４８５における読み込みの再試行が存在を指示する場合には、本方法は、成功を報告するステップ４９０に進む。逆に、ステップ４８５における読み込みの再試行が不存在を指示する場合には、本方法は、未確定の指示を提供するステップ４９５に進む。

図４に示される例示的なアルゴリズムは、冪等なプロバイダのゆえに重複が作成されることがないため安心な一時エラーの自動再試行を生じさせる。

ターゲットは、「永久」エラーと「一時」エラーとの相違の正しい表現を有しない場合がある。プラグ可能な「レスポンス・インタープリタ（response interpreter）」は、関連情報をプロトコルから選び出し（unpick）、アルゴリズムによって用いられ得る依存性のないレスポンスに入れることができる。例えば、一見したところ成功のレスポンスＳＯＡＰメッセージが、実際には、或る形態の一時エラーを表現するために用いられている場合には、これを捕らえ、アルゴリズムのために正しい一時エラー結果に翻訳することができる。

したがって、要約すれば、インターフェースのエラー・ハンドリング論理は純粋にドメイン固有ポリシー言語によって実施され、標準ポリシー・アルゴリズムを利用してきた。また、図４のフロー図によって示されるアルゴリズムは実行可能言語に変換され、例えば、ビジネス・プロセス実行言語（business process execution language、ＢＰＥＬ）エンジンのために、実行可能エンジンが動作するのと同じ仕方で、処理エンジンによって実行され得ることも理解されるであろう。

図５を参照すると、同図は、本発明の実施形態に係る、コンピュータ実施方法５００のフロー図を示す。本方法は、プロバイダのサービスのためのリクエストを（例えば、発信元のリクエスタから）受信する、ステップ５１０において開始する。次に、ステップ５２０において、リクエストの要件を決定し、ステップ５３０において、プロバイダの特質を決定する。ここで、ステップ５２０および５３０は、別個に、および任意の好適な順序で完了され得る。例えば、ステップ５３０は、ステップ５２０の前に企てられてもよく、あるいはステップ５２０および５３０は並列に企てられてもよい。

次に、ステップ５４０において、リクエストの決定された要件およびサービス・プロバイダの決定された特質に基づいて、エラーをハンドリングするためのハンドリング・アルゴリズムを識別する。このような識別は、例えば、利用可能なアルゴリズムのセットからアルゴリズムを選択することによって達成され得る。

最後に、ステップ５５０において、ハンドリング・アルゴリズムに従ってプロバイダにおいてリクエストを呼び出す。

以上において図１〜図５を参照して提示されたものなどの実施形態は、リクエスタ要件およびプロバイダ特質のセットによって定義されるリクエスタとプロバイダとの間の統合をもたらし得ることは理解されるであろう。リクエスタ要件およびプロバイダ特質に基づいて、一実施形態は、発生し得るエラーを管理するために、エラー・ハンドリング・アルゴリズムをプロセス・フロー内に投入し得る。投入されたアルゴリズムは、例えば、欠落した、または必要とされる挙動を提供するか、標準的でないエラー・レスポンスの再分類を可能にするか、あるいはその両方をなし得る。このように、さもなければエラーとして識別されなかった可能性のある肯定レスポンスが検出され、処理され得る。

実施形態によっては、図１〜図５を参照して上述された任意の方法を実施するように構成された処理機構を備えるシステムが提供され得る。

図６は、本発明の実施形態に係る、寄与スコアを生成するように構成されたシステムを示す。例として、図６に示されるように、実施形態は、ネットワーク化システムの一部を形成し得る、コンピュータ・システム７０を備え得る。コンピュータ・システム／サーバ７０のコンポーネントは、限定するものではないが、例えば、プロセッサもしくは処理ユニット７１を含む、１つまたは複数の処理機構、システム・メモリ７４、およびシステム・メモリ７４を含む様々なシステム・コンポーネントを処理ユニット７１に結合するバス９０を含み得る。

バス９０は、メモリ・バスまたはメモリ・コントローラ、周辺バス、アクセラレイティッド・グラフィックス・ポート、ならびに種々のバス・アーキテクチャのうちの任意のものを用いるプロセッサまたはローカル・バスを含む、いくつかの種類のバス構造のうちの任意のもののうちの１つまたは複数を表す。限定ではなく、例として、このようなアーキテクチャとしては、業界標準アーキテクチャ（Industry Standard Architecture、ＩＳＡ）・バス、マイクロ・チャネル・アーキテクチャ（Micro Channel Architecture、ＭＣＡ）・バス、拡張ＩＳＡ（Enhanced ISA、ＥＩＳＡ）バス、ビデオ・エレクトロニクス規格協会（Video Electronics Standards Association、ＶＥＳＡ）ローカル・バス、および周辺装置相互接続（Peripheral Component Interconnect、ＰＣＩ）バスが挙げられる。

コンピュータ・システム／サーバ７０は通例、種々のコンピュータ・システム可読媒体を含む。このようなコンピュータ・システム可読媒体は、コンピュータ・システム／サーバ７０によってアクセス可能である任意の利用可能な媒体であり得、コンピュータ・システム可読媒体は、揮発性および不揮発性媒体、取り外し可能および非取り外し可能な媒体の両方を含む。

システム・メモリ７４は、ランダム・アクセス・メモリ（random accessmemory、ＲＡＭ）７５またはキャッシュ・メモリ７６あるいはその両方などの、揮発性メモリの形態のコンピュータ・システム可読媒体を含むことができる。コンピュータ・システム／サーバ７０は、他の取り外し可能／非取り外し可能な、揮発性／不揮発性コンピュータ・システム記憶媒体をさらに含み得る。単なる例として、記憶システム７４は、非取り外し可能な不揮発性磁気媒体（図示されておらず、通例、「ハード・ドライブ」と呼ばれる）からの読み取り、およびそれへの書き込みのために設けることができる。図示されていないが、取り外し可能な不揮発性磁気ディスク（例えば、「フロッピー（Ｒ）・ディスク」）からの読み取り、およびそれへの書き込みのための磁気ディスク・ドライブ、ならびにＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、または他の光媒体などの取り外し可能な不揮発性光ディスクからの読み取り、またはそれへの書き込みのための光ディスク・ドライブを設けることができる。このような場合には、１つまたは複数のデータ媒体インターフェースによって各々をバス９０に接続することができる。以下においてさらに図示され、説明されるように、メモリ７４は、本発明の実施形態の機能を実施するように構成されたプログラム・モジュールのセット（例えば、少なくとも１つ）を有する少なくとも１つのプログラム製品を含み得る。

プログラム・モジュール７９のセット（例えば、少なくとも１つ）を有するプログラム／ユーティリティ７８が、限定ではなく、例として、オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データと同様に、メモリ７４内に記憶されてもよい。オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データ、あるいはこれらの何らかの組み合わせの各々は、ネットワーキング環境の一実装形態を含み得る。プログラム・モジュール７９は、本明細書において説明されるとおりの本発明の実施形態の機能または方法論あるいはその両方を一般的に実施する。

コンピュータ・システム／サーバ７０はまた、キーボード、ポインティング・デバイス、ディスプレイ８５等などの１つまたは複数の外部デバイス８０、ユーザがコンピュータ・システム／サーバ７０と対話することを可能にする１つもしくは複数のデバイス、またはコンピュータ・システム／サーバ７０が１つまたは複数の他のコンピューティング・デバイスと通信することを可能にする任意のデバイス（例えば、ネットワーク・カード、モデム等）、あるいはその組み合わせと通信し得る。このような通信は入力／出力（Ｉ／Ｏ）インターフェース７２を介して行うことができる。それでもなお、コンピュータ・システム／サーバ７０は、ネットワーク・アダプタ７３を介して、ローカル・エリア・ネットワーク（ＬＡＮ）、一般のワイド・エリア・ネットワーク（ＷＡＮ）、または公衆ネットワーク（例えば、インターネット）、あるいはこの組み合わせなどの１つまたは複数のネットワークと通信することができる。図示のように、ネットワーク・アダプタ７３はバス９０を介してコンピュータ・システム／サーバ７０の他のコンポーネントと通信する。図示されていないが、他のハードウェアまたはソフトウェア・コンポーネントあるいはその両方をコンピュータ・システム／サーバ７０と併せて用いることができるであろう。例としては、限定するものではないが、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部ディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、およびデータ・アーカイブ記憶システム等が挙げられる。

本出願の文脈において、本発明の実施形態が方法を構成する場合には、このような方法は、コンピュータによる実行のためのプロセス、すなわち、コンピュータ実施可能方法であることを理解されたい。したがって、本方法の様々なステップは、コンピュータ・プログラムの様々な部分、例えば、１つまたは複数のアルゴリズムの様々な部分を反映する。

本発明は、システム、方法、またはコンピュータ・プログラム製品、あるいはその組み合わせであり得る。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実施させるためのコンピュータ可読プログラム命令を有するコンピュータ可読記憶媒体（または媒体群）を含み得る。

コンピュータ可読記憶媒体は、命令実行デバイスによる使用のための命令を保持および記憶することができる有形のデバイスであることができる。コンピュータ可読記憶媒体は、例えば、限定するものではないが、電子記憶デバイス、磁気記憶デバイス、光記憶デバイス、電磁記憶デバイス、半導体記憶デバイス、または上述のものの任意の好適な組み合わせであり得る。コンピュータ可読記憶媒体のより具体的な例の非網羅的なリストは、以下のもの：ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリー・メモリ（ＲＯＭ）、消去可能プログラマブル・リード・オンリー・メモリ（ＥＰＲＯＭもしくはフラッシュ・メモリ）、ストレージ・クラス・メモリ（storage class memory、ＳＣＭ）、スタティック・ランダム・アクセス・メモリ（static random access memory、ＳＲＡＭ）、ポータブル・コンパクト・ディスク・リード・オンリー・メモリ（compact disc read-only memory、ＣＤ−ＲＯＭ）、デジタル多用途ディスク（digital versatile disk、ＤＶＤ）、メモリ・スティック、フロッピー（Ｒ）・ディスク、穿孔カード、または命令が記録された溝内の隆起構造などの、機械的に符号化されたデバイス、ならびに上述のものの任意の好適な組み合わせを含む。コンピュータ可読記憶媒体は、本明細書で使用するとき、電波もしくは他の自由伝搬する電磁波、導波路もしくは他の伝送媒体を通って伝搬する電磁波（例えば、光ファイバ・ケーブルを通過する光パルス）、または電線を通して伝送される電気信号などの、一過性信号自体であると解釈されるべきでない。

本明細書において説明されるコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピューティング／処理デバイスに、あるいはネットワーク、例えば、インターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、または無線ネットワーク、あるいはその組み合わせを経由して外部コンピュータまたは外部記憶デバイスにダウンロードすることができる。ネットワークは、銅伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはその組み合わせを含み得る。各コンピューティング／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インターフェースがネットワークからコンピュータ可読プログラム命令を受信し、コンピュータ可読プログラム命令をそれぞれのコンピューティング／処理デバイス内のコンピュータ可読記憶媒体における記憶のために転送する。

本発明の動作を実施するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（instruction-set-architecture、ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、またはＳｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋、もしくは同様のものなどの、オブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語もしくは同様のプログラミング言語などの、従来の手続き型プログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組み合わせで書かれた、ソース・コードまたはオブジェクト・コードのいずれかであり得る。コンピュータ可読プログラム命令は完全にユーザのコンピュータ上で実行するか、一部ユーザのコンピュータ上で実行するか、独立型ソフトウェア・パッケージとして実行するか、一部ユーザのコンピュータ上で、且つ一部リモート・コンピュータ上で実行するか、または完全にリモート・コンピュータもしくはサーバ上で実行し得る。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネットワーク（ＷＡＮ）を含む、任意の種類のネットワークを通じてユーザのコンピュータに接続され得るか、あるいは外部コンピュータへの接続が（例えば、インターネット・サービス・プロバイダを利用してインターネットを通じて）行われてもよい。実施形態によっては、例えば、プログラマブル論理回路機構、フィールド・プログラマブル・ゲート・アレイ（field-programmable gate array、ＦＰＧＡ）、またはプログラマブル論理アレイ（programmable logic array、ＰＬＡ）を含む電子回路機構が、本発明の態様を遂行するために、コンピュータ可読プログラム命令の状態情報を利用して電子回路機構を個別化することによって、コンピュータ可読プログラム命令を実行し得る。

本発明の態様は、本明細書において、本発明の実施形態に係る方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図またはブロック図あるいはその両方を参照して説明されている。フローチャート図またはブロック図あるいはその両方の各ブロック、およびフローチャート図またはブロック図あるいはその両方内のブロックの組み合わせは、コンピュータ可読プログラム命令によって実施され得ることが理解されるであろう。

これらのコンピュータ可読プログラム命令は、コンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行する命令が、フローチャートまたはブロック図あるいはその両方のブロックまたはブロック群において指定された機能／行為を実施するための手段を生み出すように、汎用コンピュータ、専用コンピュータ、または他のプログラム可能データ処理装置のプロセッサに提供されてマシンを作り出すものであってよい。これらのコンピュータ可読プログラム命令はまた、内部に記憶された命令を有するコンピュータ可読記憶媒体が、フローチャートまたはブロック図あるいはその両方のブロックもしくはブロック群内で指定された機能／行為の態様を実施する命令を含む製造品を含むように、コンピュータ可読記憶媒体内に記憶され、コンピュータ、プログラム可能データ処理装置、または他のデバイスあるいはその組み合わせを特定の仕方で機能するように指示することができるものであってもよい。

コンピュータ可読プログラム命令はまた、コンピュータ、他のプログラム可能装置、または他のデバイス上で実行する命令が、フローチャートまたはブロック図あるいはその両方のブロックまたはブロック群において指定された機能／行為を実施するように、コンピュータ実施プロセスを作り出すために、コンピュータ、他のプログラム可能データ処理装置、または他のデバイス上にロードされ、コンピュータ、他のプログラム可能装置、または他のデバイス上で一連の動作ステップを遂行させるものであってもよい。

図面におけるフローチャートおよびブロック図は、本発明の様々な実施形態に係るシステム、方法、およびコンピュータ・プログラム製品の可能な実装形態のアーキテクチャ、機能性、および動作を示す。この点に関して、フローチャートまたはブロック図における各ブロックは、指定された論理機能を実施するための１つまたは複数の実行可能命令を含む、命令のモジュール、セグメント、または部分を表し得る。いくつかの代替的実装形態では、ブロック内に記された機能は、図面に記された順序に従わずに生じてもよい。例えば、連続して示された２つのブロックは、実際には、実質的に同時に実行されてもよく、またはブロックは、時として、含まれる機能性に依存して、逆の順序で実行されてもよい。また、ブロック図またはフローチャート図あるいはその両方の各ブロック、ならびにブロック図またはフローチャート図あるいはその両方におけるブロックの組み合わせは、指定された機能もしくは行為を遂行するか、または専用ハードウェアおよびコンピュータ命令の組み合わせを実行する専用ハードウェア・ベースのシステムによって実施され得ることにも留意されたい。

一実施形態では、本発明のシステムは、コンピュータ、ポータブル・デバイス等などのハードウェア・デバイスであるか、またはこれらを含み得る。一実施形態では、ハードウェア・デバイスは、本発明の方法のみを実行するために（独立して、または組み合わせて）特定化されるための、特殊な非包括的ハードウェアおよび回路機構（すなわち、特殊な個別の非包括的アナログ、デジタル、および論理ベースの回路機構）を備える専用デバイス（例えば、コンピュータ、機械、ポータブル・デバイス）であるか、またはそれを含む。特殊な個別の非包括的アナログ、デジタル、および論理ベースの回路機構は、専有の特別に設計されたコンポーネント（例えば、例として、本発明の方法を実施するためにのみ設計された、特定用途向け集積回路（Application Specific Integrated Circuit、ＡＳＩＣ）などの、特殊集積回路）を含み得る。

別の実施形態では、本提案の発明は、結果として得られるグラフが検索エンジン技術を改善し得るため、コンピュータ技術に必然的に根差す技術的問題を解決する。これは、ユーザが、さらなるウェブサイトへナビゲートするのを回避すること、または情報のさらなる検索を遂行することを可能にする位置において関連情報を提供することによって、コンピュータ・リソースを節約する。

本発明のコンピュータ・プログラム製品は、内部に記憶されたコンピュータ可読プログラム・コードを有する１つまたは複数のコンピュータ可読ハードウェア記憶デバイスを含み得、前記プログラム・コードは、コンピューティング・システム（またはコンピュータ・システム）の１つまたは複数のプロセッサによって、本発明の方法を実施するように実行可能な命令を包含する。

本発明のコンピュータ・システムは、１つまたは複数のプロセッサと、１つまたは複数のメモリと、１つまたは複数のコンピュータ可読ハードウェア記憶デバイスとを含み得、前記１つまたは複数のハードウェア記憶デバイスは、１つまたは複数のメモリを介して１つまたは複数のプロセッサによって、本発明の方法を実施するよう実行可能なプログラム・コードを包含する。

本発明の様々な実施形態の説明が例示の目的のために提示されたが、網羅的であること、または開示された実施形態に限定されることを意図されてはいない。当業者には、説明された実施形態の範囲および思想から逸脱することなく、多くの変更および変形が明らかであろう。本明細書において使用される用語は、実施形態の原理、実際の適用、もしくは市場において見いだされる技術に対する技術的改善を最もよく説明するため、または他の当業者が、本明細書において開示される実施形態を理解することを可能にするために選定された。

Claims (22)

1. リクエスタとプロバイダとの間のエラー・ハンドリングのための方法であって、
   コンピューティング・システムのプロセッサによって、前記プロバイダのサービスのためのリクエストを前記リクエスタから受信することと、
   前記プロセッサによって、前記リクエストの要件を決定することと、
   前記プロセッサによって、前記リクエストの前記要件および前記サービス・プロバイダの特質に基づいて、エラーをハンドリングするためのハンドリング・アルゴリズムを識別することと、
   を含む方法。
2. 前記プロセッサによって、前記ハンドリング・アルゴリズムに従って前記プロバイダにおいて前記リクエストを呼び出すことをさらに含む、請求項１に記載の方法。
3. 前記リクエストの前記要件が、
   重複の容認性、
   前記リクエスタによって必要とされる確認、
   レスポンス・タイム、
   スループット、および
   トランザクション参加、
   のうちの少なくとも１つに関連する、請求項１に記載の方法。
4. 前記プロバイダの前記特質が、
   前記プロバイダのインターフェース、
   前記プロバイダの通信プロトコル、
   チェック試験の利用可能性、
   レスポンス・タイム、
   スループット、
   前記プロバイダの対話方法、
   前記プロバイダの冪等能力、
   前記プロバイダの同期または非同期性、
   １つまたは複数のエラー種別、
   トランザクション支援、および
   前記プロバイダの挙動特徴、
   のうちの少なくとも１つに関連する、請求項１に記載の方法。
5. 識別することが、前記プロセッサによって、前記リクエストの前記要件および前記プロバイダの前記特質に基づいて、複数のアルゴリズムから前記ハンドリング・アルゴリズムを選択することを含む、請求項１に記載の方法。
6. 前記ハンドリング・アルゴリズムを選択することが、前記リクエストの前記要件または前記プロバイダの前記特質が所定の通信プロトコルに関連するかどうかに基づいて、前記ハンドリング・アルゴリズムを選択することを含む、請求項５に記載の方法。
7. ハンドリング・アルゴリズムを識別することが、最良適合評価に従って前記ハンドリング・アルゴリズムを選択することを含む、請求項５に記載の方法。
8. 前記ハンドリング・アルゴリズムが、前記プロバイダへの前記リクエストの送達を保証するように構成されており、前記ハンドリング・アルゴリズムが、前記プロバイダへの前記リクエストの送達を保証するために、再試行手順、延期手順、比較、および併合手順のうちの少なくとも１つを実施するように構成されている、請求項１に記載の方法。
9. 前記プロセッサによって、前記プロバイダの特質を決定することをさらに含み、前記プロバイダの前記特質を決定することが、前記プロバイダの１つまたは複数の特質に関連する情報をデータ・リポジトリから得ることを含む、請求項１に記載の方法。
10. リクエスタとプロバイダとの間のエラー・ハンドリングのためのコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品が、プログラム命令が具現化されたコンピュータ可読記憶媒体を含み、前記プログラム命令が、処理ユニットに、
    コンピューティング・システムのプロセッサによって、前記プロバイダのサービスのためのリクエストを前記リクエスタから受信することと、
    前記プロセッサによって、前記リクエストの要件を決定することと、
    前記プロセッサによって、前記リクエストの前記要件および前記サービス・プロバイダの特質に基づいて、エラーをハンドリングするためのハンドリング・アルゴリズムを識別することと、
    を含む方法を遂行させるように前記処理ユニットによって実行可能である、コンピュータ・プログラム製品。
11. データ処理システムであって、少なくとも１つのプロセッサと、請求項１０に記載のコンピュータ・プログラム製品とを備え、前記少なくとも１つのプロセッサが、前記コンピュータ・プログラム製品のコンピュータ・プログラム・コードを実行するように構成されている、データ処理システム。
12. 前記データ処理システムが、メッセージ・プロデューサとメッセージ・コンシューマとの間のメッセージ・ブローカの役割を果たすように構成されている、請求項１１に記載のデータ処理システム。
13. 前記データ処理システムが、サービス指向アーキテクチャの一部を実施するように構成されている、請求項１１に記載のデータ処理システム。
14. リクエスタとプロバイダとの間のエラー・ハンドリングのためのエラー・ハンドリング・コンポーネントであって、前記コンポーネントが、
    前記リクエスタから、前記プロバイダのサービスのためのリクエストを受信するように構成された入力インターフェースと、
    前記リクエストの要件を決定するように構成された分析コンポーネントと、
    前記リクエストの前記要件および前記プロバイダの特質に基づいて、エラーをハンドリングするためのハンドリング・アルゴリズムを決定するように構成されたアルゴリズム・コンポーネントと、
    を備える、エラー・ハンドリング・コンポーネント。
15. 前記ハンドリング・アルゴリズムに従って前記プロバイダにおいて前記リクエストを呼び出すように構成された実行コンポーネントをさらに備える、請求項１４に記載のエラー・ハンドリング・コンポーネント。
16. 前記リクエストの前記要件が、
    重複の容認性、
    前記リクエスタによって必要とされる確認、
    レスポンス・タイム、
    スループット、および
    トランザクション参加、
    のうちの少なくとも１つに関連する、請求項１４に記載のエラー・ハンドリング・コンポーネント。
17. 前記プロバイダの前記特質が、
    前記プロバイダのインターフェース、
    前記プロバイダの通信プロトコル、
    チェック試験の利用可能性、
    レスポンス・タイム、
    スループット、
    前記プロバイダの対話方法、
    前記プロバイダの冪等能力、
    前記プロバイダの同期または非同期性、
    １つまたは複数のエラー種別、
    トランザクション支援、および
    前記プロバイダの挙動特徴、
    のうちの少なくとも１つに関連する、請求項１４に記載のエラー・ハンドリング・コンポーネント。
18. 前記アルゴリズム・コンポーネントが、前記リクエストの前記要件および前記プロバイダの前記特質に基づいて、複数のアルゴリズムから前記ハンドリング・アルゴリズムを選択するように構成されている、請求項１４に記載のエラー・ハンドリング・コンポーネント。
19. 前記アルゴリズム・コンポーネントが、前記リクエストの前記要件または前記プロバイダの前記特質が所定の通信プロトコルに関連するかどうかに基づいて、前記ハンドリング・アルゴリズムを選択するように構成されている、請求項１８に記載のエラー・ハンドリング・コンポーネント。
20. 前記アルゴリズム・コンポーネントが、最良適合評価に従って前記ハンドリング・アルゴリズムを選択するように構成されている、請求項１８に記載のエラー・ハンドリング・コンポーネント。
21. 前記分析コンポーネントが、前記プロバイダの特質を決定するように構成されており、前記分析コンポーネントが、前記プロバイダの１つまたは複数の特質に関連する情報をデータ・リポジトリから得るように構成されている、請求項１４に記載のエラー・ハンドリング・コンポーネント。
22. 前記ハンドリング・アルゴリズムが、前記プロバイダへの前記リクエストの送達を保証するように構成されており、前記ハンドリング・アルゴリズムが、前記プロバイダへの前記リクエストの送達を保証するために、再試行手順、延期手順、比較、および併合手順のうちの少なくとも１つを実施するように構成されている、請求項１４に記載のエラー・ハンドリング・コンポーネント。