JP2014183587A - Ｅｐｐを介するインテリジェント多対多サービスのための方法およびシステム - Google Patents

Abstract

【課題】ネットワークを介してＥＰＰ要求をルーティングする方法およびシステムが提供される。
【解決手段】ルーティング・システムは、複数のフロントエンド・サービス・インターフェースと、１つまたは複数のゲートウェイと、管理サーバと、複数のアプリケーション・サービスを提供するバックエンド・サービス・プラットフォームとを含み、フロントエンド・サービス・インターフェースは、仮想ＩＰアドレス（「ＶＩＰ」）を使用してアドレス指定でき、要求側は、ターゲットとするサービス・インターフェースに関連するＶＩＰに対応するターゲットＩＰまたはドメイン名に要求を送ることにより、ＥＰＰを介してターゲットとするサービス・インターフェースに要求を送り、１つまたは複数のバックエンド・サービスにアクセスすることができる。
【選択図】図１

Description

（関連出願の相互参照）
本特許出願は、係属中の、本願と同一の実体に譲渡され、または譲渡の義務下にあり、参照によりその全体が本明細書に明確に組み込まれている、２０１２年１１月１９日に出願した「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｉｎｔｅｌｌｉｇｅｎｔ Ｒｏｕｔｉｎｇ ｏｆ Ｒｅｑｕｅｓｔｓ ｏｖｅｒ ＥＰＰ」という名称の米国特許出願第１３／６８１３３０号明細書の一部継続出願である。米国特許出願第１３／６８１３３０号明細書は、やはり本願と同一の実体に譲渡され、または譲渡の義務下にあり、参照によりその全体が本明細書に明確に組み込まれている、２００９年８月１８日に出願し、２０１２年１２月４日に米国特許第８３２７０１９号明細書として発行された米国特許出願第１２／５４３４６２号明細書の継続出願であり、その優先権を主張する。

本開示は、一般に、ネットワークを介して要求をルーティングすることに関する。

インターネットの使用が指数関数的に増大するにつれて、インターネット関連サービスの需要も急激に増大しつつある。インターネットの使用の増大の結果として、ドメイン名の需要も急激に増大しつつある。したがって、ドメイン関連サービスの需要も増大している。そのようなドメイン関連サービスは、ドメイン名作成、ドメイン名登録更新などを含むことができる。通常、ウェブサイトは、ドメイン名に関するオンライン存在を確立する主要な媒体として働く。ドメイン名関連サービスに対する、この常に増大し続ける需要を満たすために、こうしたサービスを提供するエンティティが、効率的でコスト効果の高い方式でそのように行うことが必要である。

ドメイン名システム（「ＤＮＳ」）は、人間が読取り可能なドメイン名を、インターネットを介してＴＣＰ／ＩＰ通信を確立するのに必要なインターネット・プロトコル（「ＩＰ」）番号に変換するインターネット・インフラストラクチャの部分である。ＤＮＳは、ウェブサイトに関連付けられ、インターネット上のコンピュータに割り当てられた数字のＩＰアドレス、例えば１２３．４．５６．７８ではなく、「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」などの記憶しやすいドメイン名を使用して、ユーザがウェブサイトおよび他のリソースを参照することを可能にする。各ドメイン名は、ドットで分離される一連の文字列（例えば、ラベル）から構成することができる。ドメイン名中の右端のラベルは、トップ・レベル・ドメイン（「ＴＬＤ」）と呼ばれる。周知のＴＬＤの例は、「ｃｏｍ」、「ｎｅｔ」、「ｏｒｇ」などである。各ＴＬＤは、ＴＬＤのすぐ左側にリストされる第２レベル・ドメイン、例えば「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」中の「ｅｘａｍｐｌｅ」レベルをサポートする。各第２レベル・ドメインは、第２レベル・ドメインのすぐ左側に配置されるいくつかの第３レベル・ドメイン、例えばｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ中の「ｗｗｗ」レベルを含むことができる。

ＴＬＤ内の第２レベル・ドメインのレジストリを維持することを含む、各ＴＬＤを運用する責任は、ドメイン名レジストリ（「レジストリ」）と呼ばれる特定の組織に委ねられる。レジストリは主に、ドメインに関連付けられるＩＰアドレスを求める照会に、通常は大規模データベース内にそのような情報を維持するＤＮＳサーバを通じて回答し（「解決」）、そのトップ・レベル・ドメインを運用する役割を果たす。

ほとんどのＴＬＤでは、ドメイン名を得るために、エンドユーザに代わってインターネット・ドメイン名を登録することを許可されたエンティティであるドメイン名レジストラを通じて、そのドメイン名をレジストリに登録しなければならない。あるいは、エンドユーザは、１つまたは複数の層の再販業者を通じて、間接的にドメイン名を登録することができる。レジストリは、数百のレジストラから登録を受けることがある。

レジストラは通常、ドメイン関連サービス、例えばドメイン名作成または更新にアクセスするために、レジストリとの専用サービス接続を有する。レジストラは通常、ドメイン名を登録または更新するために、Ｅｘｔｅｎｓｉｂｌｅ Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｐｒｏｔｏｃｏｌ（「ＥＰＰ」）を媒体として使用して、レジストリと通信する。ＥＰＰは、インターネットを介してレジストリ内のオブジェクトを割り振るために設計されたプロトコルである。ＥＰＰプロトコルは、構造化されたテキストベースのフォーマットである拡張マークアップ言語（「ＸＭＬ」）に基づく。基礎となるネットワーク・トランスポートは固定されないが、現在指定されている方法は、伝送制御プロトコル（「ＴＣＰ」）を介するものである。

本開示の実施形態は、ＥＰＰを介してサービス要求をルーティングするシステムおよび方法に関する。具体的には、様々な実施形態によるルーティング・システムは、複数のフロントエンド・サービス・インターフェースと、１つまたは複数のゲートウェイと、管理サーバと、複数のアプリケーション・サービスを提供するバックエンド・サービス・プラットフォームとを含む。フロントエンド・サービス・インターフェースは、仮想ＩＰアドレス（「ＶＩＰ」）を使用してアドレス指定可能であり、ゲートウェイによって提供することができる。ルーティング・システムは、フロントエンド・サービス・インターフェースと、バックエンド・サービス・プラットフォームによって提供されるバックエンド・サービスのセットとの間の多対多マッピングを定義する。要求側は、ターゲットとするサービス・インターフェースに関連するＶＩＰに対応するターゲットＩＰまたはドメイン名に要求を送ることにより、ＥＰＰを介してターゲットとするサービス・インターフェースに要求を送り、１つまたは複数のバックエンド・サービスにアクセスすることができる。多対多マッピングおよびターゲットとするサービス・インターフェースのＶＩＰを使用して、ルーティング・システムは、要求によって捜し求められるバックエンド・サービスを識別し、バックエンド・サービスへのアクセスを要求側に与えることができる。

様々な実施形態によるルーティング・システムは、多対多マッピングでバージョン番号および／またはバージョン番号に関連する動作状態を維持し、バージョン・テスティング、バージョン・アップグレード、およびバージョン・ダウングレードまたはロールバックをサポートすることができる。いくつかの実施形態では、ＶＩＰにわたって異なるスケジュールでバックエンド・サービスをアップグレードする必要がある場合、ＶＩＰと共にバージョニングを行うことができる。追加の実施形態では、ＶＩＰとは独立にバージョニングを行うことができる。各バックエンド・サービスに、固有のバージョン番号を、任意選択でサービスの各バージョンについて定義された動作状態と共に割り当てることができる。ゲートウェイに関する状態機械（ｓｔａｔｅ−ｍａｃｈｉｎｅ）を定義して、ＶＩＰを変数として使用して、または使用することなく、要求をルーティングするサービスがどれかを決定することができる。バックエンド・サービスに関する状態機械の実施形態は、例えば、非アクティブ、過去、現在、および次回などの動作状態を含むことができる。バックエンド・サービスの特定の動作状態に基づいてサービス要求をルーティングするように１つまたは複数のゲートウェイを構成することができる。

本開示の実施形態の追加の目的および利点を以下の説明で部分的に述べ、それは部分的には説明から明らかとなり、または実施形態の実施によって知ることができる。添付の特許請求の範囲で具体的に指摘される要素および組合せによって実施形態の目的および利点を実現および達成することができる。

上記の一般的説明と以下の詳細な説明のどちらも例示的で説明的なものに過ぎず、特許請求される実施形態を限定するものではないことを理解されたい。

本開示の実施形態に適合する、サービス要求のインテリジェント・ルーティングのための例示的システムのブロック図である。 本開示の実施形態に適合する例示的ゲートウェイを示すブロック図である。 本開示の実施形態に適合する例示的ルーティング・テーブルを示す図である。 本開示の実施形態に適合する、多対多マッピングを管理し、多対多マッピングに基づいてＥＰＰを介してサービス要求に応答するためにインテリジェント・ルーティング・システムによって実施される例示的プロセスの流れ図である。 本開示の実施形態に適合する、ＥＰＰを介してサービス要求に応答するためにインテリジェント・ルーティング・システムによって実施される例示的プロセスの流れ図である。 本開示に適合する、開示される実施形態を実施する例示的コンピュータ・システムである。

次に、添付の図面に示される例示的実施形態を詳細に参照する。適切なときは、同一または同様の部分を参照するために、図面全体を通して同一の参照番号を用いる。

単純および例示のために、本開示の原理を、主にその例示的実施形態を参照することによって説明する。しかし、同一の原理は、すべてのタイプの情報およびシステムに等しく適用可能であり、すべてのタイプの情報およびシステムで実装できること、および任意のそのような変形は、本開示の精神および範囲から逸脱しないことを当業者なら容易に理解されよう。さらに、以下の詳細な説明では、特定の例示的実施形態を示す添付の図を参照する。本開示の精神および範囲から逸脱することなく、例示的実施形態に対して電気的、機械的、論理的、および構造的変更を行うことができる。したがって、以下の詳細な説明を限定的な意味で理解すべきではなく、本開示の範囲は、添付の特許請求の範囲およびその均等物によって定義される。

本開示の様々な実施形態は、ＥＰＰを介する要求のインテリジェント・ルーティングのためのシステムおよび方法を含む。様々な実施形態によるインテリジェント・ルーティング・システムは、複数のフロントエンド・サービス・インターフェースと、１つまたは複数のゲートウェイと、管理サーバと、ドメイン名レジストリ・サービス、ドメイン名提案サービスなどの複数のアプリケーション・サービスを提供するバックエンド・サービス・プラットフォームとを含む。フロントエンド・サービス・インターフェースは、仮想ＩＰアドレス（「ＶＩＰ」）を使用してアドレス指定可能であり、ゲートウェイおよび／またはゲートウェイに通信可能に結合された構成要素（例えば、ネットワーク・サーバ）によって提供することができる。

インテリジェント・ルーティング・システムは、フロントエンド・サービス・インターフェースと、バックエンド・サービス・プラットフォームによって提供されるサービスのセットとの間の多対多マッピングを定義することができる。要求側は、ターゲットとするサービス・インターフェースに関連するＶＩＰに対応するターゲットＩＰまたはドメイン名に要求を送る、または向けることにより、ＥＰＰを介してフロントエンド・サービス・インターフェースのターゲットとするサービス・インターフェースに要求を送り、サービスのセット中の１つまたは複数のバックエンド・サービスにアクセスすることができる。インテリジェント・ルーティング・システムは、ターゲットとするサービス・インターフェースのＶＩＰに基づいてＥＰＰグリーティングを提供することにより、要求に応答することができる。多対多マッピングおよびターゲットとするサービス・インターフェースのＶＩＰを使用して、インテリジェント・ルーティング・システムは、要求によって捜し求められるバックエンド・サービスを識別し、バックエンド・サービスへのアクセスを要求側に与える（または拒否する）ことができる。

様々な実施形態では、多対多マッピングは、バックエンド・サービスに対する高レベル・ルーティング要素として、フロントエンド・サービス・インターフェースに関連するＶＩＰを含むことができ、管理サーバは、マスタ・ルーティング・テーブルに多対多マッピングを格納することができる。管理サーバは、マスタ・ルーティング・テーブル内の多対多マッピングをゲートウェイに伝播することができる。代替または追加として、ゲートウェイは、マスタ・ルーティング・テーブルから多対多マッピングを複製することができる。ゲートウェイのうちの任意の１つが、そのゲートウェイにローカルに格納されたルーティング・テーブル内の情報に基づいて、バックエンド・サービスに関連するステータス情報を決定することができる。ゲートウェイのうちの任意の１つは、また、サービス要求がターゲットとするフロントエンド・サービス・インターフェースのうちの１つまたは複数にアドレス指定されたサービス要求を受信することができ、ローカルに格納されたルーティング・テーブルおよび１つまたは複数のターゲットとするフロントエンド・サービス・インターフェースに関連するＶＩＰを使用することにより、そのゲートウェイは、要求によって捜し求められるバックエンド・サービスを識別し、それに応じて要求をルーティング（または拒否）することができる。

インテリジェント・ルーティング・システムは、集中型手法、非集中型手法、または混合手法（例えば、非集中型で、オーバーライドが集中型で管理される）で、ＶＩＰとバックエンド・サービスとの間の多対多マッピングを生成および／または更新することができる。集中型手法では、バックエンド・サービスは、管理サーバに登録することができ、管理サーバは、正式なルーティング情報を生成することができる。非集中型手法では、バックエンド・サービスは、包括的に管理サーバに登録することができ、管理者または外部ルーティング・マネージャ・アプリケーションによってルーティング・マッピングを構成することができる。混合手法では、バックエンド・サービスは、その所望のＶＩＰを発行することができ、管理サーバは、バックエンド・サービス・プリファレンスをオーバーライドすることができる。

フロントエンド・サービス・インターフェースに関連するＶＩＰに少なくとも部分的に基づいてサービス要求をルーティングすることにより、インテリジェント・ルーティング・システムは、ＶＩＰのそれぞれに異なるクライアント・ポリシー（例えば、接続、帯域幅、セキュリティ／暗号化、サービス品質など）を適用することができる。そのように行う際に、インテリジェント・ルーティング・システムは、サービス要求がターゲットとするフロントエンド・サービス・インターフェースのＶＩＰに基づいて、差別化されたレベルの機能を提供することができ、かつ／または固有のクライアントまたはアクセス・ポリシーを適用することができる。例えば、各ＶＩＰについて新しい接続要求または他のサービス要求に返されるＥＰＰグリーティングは、そのＶＩＰにとって利用可能なサービスのみを含むことができる。ログインまたは接続要求に応答するとき、インテリジェント・ルーティング・システムは、ログインまたは接続要求がターゲットとするフロントエンド・サービス・インターフェースのＶＩＰを考慮に入れることができる。要求側のＩＰアドレス、ログイン名、パスワード、およびデジタル証明書と共に、インテリジェント・ルーティング・システムは、ターゲットとするサービス・インターフェースのＶＩＰを、認証決定を行う際の要素として使用することができる。例えば、ゲートウェイは、ユーザのサービス特権に基づいてＶＩＰを通じて認証を許可または拒否することができる。ゲートウェイはまた、ルーティング・テーブルおよびユーザのサービス特権に基づいて、バックエンド・サービスのうちの１つまたは複数に要求をルーティングすることを許可または拒否することもできる。

インテリジェント・ルーティング・システムが、要求がターゲットとするフロントエンド・サービス・インターフェースのＶＩＰに基づいて、要求側からＥＰＰを介して要求をルーティングすることが有利なはずである。例えば、レジストラおよび他のクライアントは、ドメイン名を登録および更新し、他のドメイン名関連操作を実施するために、レジストリにＥＰＰを介してサービスを要求することができる。レジストリは、多くのタイプのＴＬＤ（例えば、Ｂｒａｎｄ ＴＬＤ、規制ＴＬＤ、非規制ＴＬＤなど）に関するドメイン名関連サービスを提供することができ、一方、各レジストラは、１つまたはいくつかのタイプのＴＬＤに関するドメイン名関連操作を要求することができる。レジストリまたは別のエンティティは、サービス要求を行うために各レジストラに１つまたは複数のＴＬＤタイプ特有のＶＩＰを提供することができる。レジストリまたは別のエンティティはまた、バッチ／自動プールなどの特定のタイプのサービス要求を行うレジストラを選択するために、１つまたは複数の特別なＶＩＰを提供することもできる。次いで、レジストラのうちの２つが、特定のタイプのＴＬＤまたはサービス要求のために設計されたＶＩＰにサービス要求を送るとき、インテリジェント・ルーティング・システムは、ＶＩＰに関連する特定のタイプのＴＬＤまたはサービス要求に対して適切な方式および／または所望の方式でサービス要求に応答することができる。

さらに、インテリジェント・ルーティング・システムは、サーバ・インフラストラクチャ・コストを低減することができる。ゲートウェイおよびバックエンド・サービス・プラットフォームの同一のセットを利用して複数のディスクリート・バックエンド・アプリケーション・サービスを提供することができるからである。インテリジェント・ルーティング・システムはまた、要求側および他のクライアントに関する複雑さのレベルをも低減することができる。インテリジェント・ルーティング・システムは、ドメイン名関連サービスを要求するのに必要な接続プールを単純化するからである。さらに、インテリジェント・ルーティング・システムは、サービスの追加のスタック（例えば、ゲートウェイ、バックエンド・サービス・プラットフォームなど）の作成を必要とすることなく、固有のクライアントまたはアクセス・ポリシーを自然に処理することができる。インテリジェント・ルーティング・システムはまた、新しいバックエンド・サービスの採用も向上させることができる。インテリジェント・ルーティング・システムは、要求側が新しいサービス・インターフェースに接続することを必要とせずに、要求側に新しいバックエンド・サービスを提供することができるからである。

様々な実施形態では、インテリジェント・ルーティング・システムは、バージョン・テスティング、バージョン・アップグレード、およびバージョン・ダウングレードまたはロールバックをサポートするために、多対多マッピングでバックエンド・サービスに関連するバージョン番号および／または動作状態を維持することができる。いくつかの実施形態では、インテリジェント・ルーティング・システムは、バックエンド・サービスに関連するＶＩＰを考慮に入れることなく、サービス要求をルーティングするとき、バックエンド・サービスに関連するバージョン番号および／または動作状態を考慮に入れることができる。追加の実施形態では、サービス要求をルーティングするとき、インテリジェント・ルーティング・システムは、ＶＩＰにわたって異なるスケジュールで１つまたは複数のバックエンド・サービスをアップグレードする必要がある場合、バックエンド・サービスに関連するＶＩＰと共に、バックエンド・サービスに関連するバージョン番号および／または動作状態を考慮に入れることができる。バックエンド・サービスの各バージョンに、固有バージョン番号を、任意選択で動作状態と共に割り当てることができる。ゲートウェイに関する状態機械を定義して、ＶＩＰを変数として使用して、または使用することなく、要求をルーティングするサービスがどれかを決定することができる。バックエンド・サービスに関する状態機械の実施形態は、例えば、非アクティブ、過去、現在、および次回などの動作状態を含むことができる。通常の生成ゲートウェイが「現」状態だけについて構成されるのに対して、「次の」状態をスニッフ・テストするようにゲートウェイのセットを構成することができるのと同様に、特定のバージョン番号または動作状態を有するサービスにサービス要求をルーティングするように１つまたは複数のゲートウェイを構成することができる。ロールバックする決定を行う前にサービスをトラブルシューティングする必要がある場合、「過去の」状態についてゲートウェイを構成することができる。「非アクティブ」状態は、サービスの非アクティブ・バージョンを配置解除する前にサービスの非アクティブ・バージョンに関する端末状態として働く。

インテリジェント・ルーティング・システムが、バックエンド・サービスに関連するバージョン番号および／または動作状態を維持し、要求によって捜し求められるバックエンド・サービスに関連するバージョン番号および／または動作状態に少なくとも部分的に基づいて、ＥＰＰを介して要求をルーティングすることが有利なはずである。バックエンド・サービスに関連するバージョン番号および／または動作状態を維持することにより、インテリジェント・ルーティング・システムは、バージョン・テスティング、バージョン・アップグレード、およびバージョン・ダウングレードまたはロールバックをサポートすることができ、新しいバックエンド・サービスの選択的公開を可能にすることができる。さらに、そのように行う際に、インテリジェント・ルーティング・システムは、要求側および他のクライアントに悪影響を及ぼすことなく、バックエンド・サービス・アップグレードをシームレスに処理することができる。要求側は、バックエンド・サービス・アップグレード中にフロントエンド・サービス・インターフェースおよびゲートウェイへの接続を維持することができるからである。サービスをバージョン・テストし、ダウン時間なしで、または最小のダウン時間でサービスをシームレスにアップグレードする能力を有することにより、バックエンド・サービス・プラットフォームが新しいサービスを開発および配置する原動力が得られ、それによって、要求側に提供されるサービスが向上し、バックエンド・サービス・プラットフォームの競争的利点が向上する。

図１に、本開示の実施形態に適合する、ＥＰＰを介して１つまたは複数のサービスに受信されるサービス要求のインテリジェント・ルーティングのための例示的システムを示す。その一例が図１に示される様々な実施形態では、システム１００が、フロントエンド・サービス・インターフェース１１０ａ〜ｎおよびゲートウェイ１２０ａ〜ｎを有する。サービス・インターフェース１１０ａ〜ｎは、ＶＩＰを使用してアドレス指定可能であり、システム１００へのサービス・エントリ・ポイントとして機能することができる。要求側は、ターゲットとするサービス・インターフェースに関連するＶＩＰに対応するターゲットＩＰまたはドメイン名に要求を送る、または向けることにより、ターゲットとするサービス・インターフェース（例えば、サービス・インターフェース１１０ａ〜ｎのうちの１つ）に、ＥＰＰを介してサービス要求を送ることができる。

ゲートウェイ１２０ａ〜ｎは、１つまたは複数の要求側からサービス・インターフェース１１０ａ〜ｎで受信されるサービス要求をルーティングすることができる。ゲートウェイ１２０ａ〜ｎおよび／またはゲートウェイ１２０ａ〜ｎに通信可能に結合された構成要素（例えば、ネットワーク・サーバ）が、サービス・インターフェース１１０ａ〜ｎを設けることができる。各ゲートウェイ１２０ａ〜ｎにローカルに格納されたルーティング・テーブル１２５ａ〜ｎはそれぞれ、サービス・インターフェース１１０ａ〜ｎと、バックエンド・サービス・プラットフォーム１５０によって提供されるサービス１５５ａ〜ｎのセットとの間の多対多マッピングである。ルーティング・テーブル１２５ａ〜ｎは、サービス１５５ａ〜ｎのセットに対する高レベル・ルーティング要素として、サービス・インターフェース１１０ａ〜ｎに関連するＶＩＰを含むことができる。ゲートウェイ１２０ａ〜ｎは、ルーティング・テーブル１２５ａ〜ｎに格納された情報を使用して、サービス１５５ａ〜ｎのセットに関連する状態またはステータス情報を決定することができる。例えば、ゲートウェイ１２０ａ〜ｎは、サービス・インターフェース１１０ａ〜ｎを介して接続要求を受信し、要求がターゲットとするサービス・インターフェース１１０ａ〜ｎのＶＩＰに少なくとも部分的に基づいて、ＥＰＰグリーティングを与えることができる。ログインおよび／または接続要求に応答するとき、ゲートウェイ１２０ａ〜ｎは、ログインまたは接続要求がターゲットとするサービス・インターフェース１１０ａ〜ｎのＶＩＰを考慮に入れることができる。要求側のＩＰアドレス、ログイン名、パスワード、およびデジタル証明書と共に、ゲートウェイ１２０ａ〜ｎは、ターゲットとするサービス・インターフェースのＶＩＰを、許可または認証決定を行う際の要素として使用することができる。例えば、要求がターゲットとするサービス・インターフェースのＶＩＰが、１つまたは複数のバックエンド・サービスにアクセスすることが許可されているものとしてそのルーティング・テーブル内にリストされるとき、ゲートウェイ１２０ａ〜ｎは、サービス１５５ａ〜ｎの１つまたは複数のバックエンド・サービスにアクセスする要求を許可することができる。

ゲートウェイ１２０ａ〜ｎは、ルーティング・テーブル１２５ａ〜ｎを使用して、サービス要求がターゲットとするサービス・インターフェース１１０ａ〜ｎに関連するＶＩＰに少なくとも部分的に基づいて、サービス要求によって捜し求められるサービス１５５ａ〜ｎを識別する。捜し求められるサービス１５５ａ〜ｎを識別した後、ゲートウェイ１２０ａ〜ｎは、識別したサービス（複数可）１５５ａ〜ｎにサービス要求をルーティングする。ゲートウェイ１２０ａ〜ｎは、ＥＰＰを介してサービス要求を送信することのできる外部システムおよびネットワークと通信することができる。前述のように、ＥＰＰに関するデフォルト・トランスポートはＴＣＰである。しかし、ハイパーテキスト転送プロトコル（「ＨＴＴＰ」）、ＨＴＴＰ Ｓｅｃｕｒｅ（「ＨＴＴＰＳ」）、または他のネットワーク・プロトコルを介してＥＰＰメッセージを受信および送信するようにゲートウェイ１２０ａ〜ｎを構成することができる。ゲートウェイ１２０ａ〜ｎのそれぞれは、例えば、図２に示し、以下でより詳細に説明するゲートウェイ２００などの必須機能を有する任意のゲートウェイでよい。

様々な実施形態では、ルーティング・テーブル１２５ａ〜ｎは、多対多マッピングでのサービス１５５ａ〜ｎのうちの１つまたは複数に関連するバージョン番号および／または動作状態を格納することができる。格納されるバージョン番号および／または動作状態は、バージョン・テスティング、バージョン・アップグレード、およびバージョン・ダウングレードまたはロールバックをサポートすることができる。ＶＩＰにわたって異なるスケジュールでバックエンド・サービス１５５ａ〜ｎをアップグレードする必要がある場合、ゲートウェイ１２０ａ〜ｎは、ＶＩＰと共にバージョン依存ルーティングを実施することができる。あるいは、ゲートウェイ１２０ａ〜ｎは、ＶＩＰとは無関係にバージョン依存ルーティングを実施することができる。サービスのバージョン（例えば、サービス１５５ａ〜ｎのうちの１つ）をそれぞれ、固有バージョン番号、任意選択で動作状態に割り当てることができる。ゲートウェイ１２０ａ〜ｎに関する状態機械を定義して、ＶＩＰを変数として使用して、または使用することなく、要求をルーティングするサービスのバージョンがどれかを決定することができる。サービスに関する状態機械の実施形態は、例えば、非アクティブ、過去、現在、および次回などの動作状態を含むことができる。

図１に示すように、システム１００は、管理サーバ１３０およびバックエンド・サービス・プラットフォーム１５０をさらに含むことができる。ネットワーク１４５を介して、管理サーバ１３０、バックエンド・サービス・プラットフォーム１５０、およびゲートウェイ１２０ａ〜ｎを通信可能に結合することができる。ネットワーク１４５は、ローカル・エリア・ネットワーク、近距離場通信リンクまたはネットワーク、広域ネットワーク、セルラ・ネットワーク、インターネット、クラウド・ベースのネットワークなど、またはそれらの任意の組合せなどの１つまたは複数のワイヤードまたはワイヤレス通信ネットワークの任意の組合せを含むことができる。管理サーバ１３０は、サービス・インターフェース１１０ａ〜ｎに関連するＶＩＰと、バックエンド・サービス・プラットフォーム１５０によって提供されるサービス１５５ａ〜ｎとの間の多対多マッピングを含むマスタ・ルーティング・テーブル１３５を維持することができる。管理サーバ１３０は、マスタ・ルーティング・テーブル１３５内の多対多マッピングをゲートウェイ１２０ａ〜ｎに伝播することにより、ゲートウェイ１２０ａ〜ｎに格納されたルーティング・テーブル１２５ａ〜ｎを管理することができる。追加および／または代替として、管理サーバ１３０は、ゲートウェイ１２０ａ〜ｎがマスタ・ルーティング・テーブル１３５内の多対多マッピングを複製することを可能にすることにより、ゲートウェイ１２０ａ〜ｎに格納されたルーティング・テーブル１２５ａ〜ｎを管理することができる。

管理サーバ１３０は、集中型手法、非集中型手法、または混合手法（例えば、非集中型で、オーバーライドが集中型で管理される）でＶＩＰとバックエンド・サービスとの間の多対多マッピングを生成および／または更新することができる。集中型手法では、サービス１５５ａ〜ｎは、管理サーバ１３０に登録することができ、管理サーバ１３０は、サービス１５５ａ〜ｎに関する正式なルーティング情報を生成することができる。非集中型手法では、サービス１５５ａ〜ｎは、包括的に管理サーバ１３０に登録することができ、外部ルーティング・マネージャ・アプリケーションにより、またはサービス１５５ａ〜ｎによって提供されるプリファレンスに基づいて、ルーティング・マッピングを構成することができる。混合手法では、サービス１５５ａ〜ｎは、その所望のＶＩＰを発行することができ、管理サーバ１３０は、サービス１５５ａ〜ｎによって提供されるプリファレンスをオーバーライドすることができる。

様々な実施形態では、管理サーバ１３０は、サービス１５５ａ〜ｎを管理し、サービス１５５ａ〜ｎの一部またはすべてに関する情報を格納または提供することができる。サービス１５５ａ〜ｎのそれぞれは、その固有情報を管理サーバ１３０に通信することができる。管理サーバ１３０は、サービス１５５ａ〜ｎに関する情報のリポジトリでよい。サービス１５５ａ〜ｎのそれぞれによって提供される情報は、その名前、許可されたＶＩＰおよび／または好ましいＶＩＰ（複数可）、バージョン番号、動作状態、接続性情報などを含むことができる。サービス１５５ａ〜ｎのそれぞれについての追加のサービス関連情報は、そのＥＰＰハンドラ、ＥＰＰ Ｐｏｌｌハンドラ、およびＥＰＰ拡張についての情報を含むことができる。システム管理者は、管理サーバ１３０上の管理ユーザ・インターフェース（ＵＩ）またはアプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して、サービス１５５ａ〜ｎのいずれか１つに対する更新を行うことができる。システム管理者がサービス１５５に対する変更を行った後、管理サーバ１３０は、サービス１５５に行った変更をゲートウェイ１２０ａ〜ｎに自動的に通信することができる。管理サーバ１３０は、この情報をゲートウェイ１２０ａ〜ｎにプッシュすることができる。代替または追加として、ゲートウェイ１２０ａ〜ｎは、管理サーバ１３０にポーリングして、サービス１５５ａ〜ｎについての情報を収集することができる。ゲートウェイ１２０ａ〜ｎのそれぞれは、この情報を、対応するルーティング・テーブル１２５ａ〜ｎにローカルに格納することができる。

管理サーバ１３０は、サービス１５５ａ〜ｎのそれぞれに対する、イネーブル、ディスエーブル、追加、削除、修正などの様々な操作を実施することができる。管理サーバ１３０はまた、関連サービスをサービス・グループに編成することもできる。例えば、ｃＴＬＤは、サービス・グループの部分として含まれるｄｏｔＴＬＤ１、ｄｏｔＴＬＤ２、およびｄｏｔＴＬＤ３のそれぞれに関連する個々のサービスを有するサービス・グループでよい。システム管理者は、サービス・グループを単一のエンティティとして制御し、全体としてのサービス・グループに対するイネーブル、ディスエーブル、アップグレードなどの操作を実施する能力を有することができる。管理サーバ１３０は、図６に示し、以下で詳細に説明するコンピュータ・システム６００などの必須機能を有する任意のコンピュータ・システムでよい。

バックエンド・サービス・プラットフォーム１５０は、１つまたは複数のサービス１５５ａ〜ｎを提供するスケーラブルなフォールト・トレラント・プラットフォームでよい。バックエンド・サービス・プラットフォーム１５０は、１つまたは複数のプロトコルを使用して、ネットワーク１４５を介してゲートウェイ１２０ａ〜ｎおよび管理サーバ１３０と通信することができ、複数のサービス１５５ａ〜ｎをホストするように構成することができる。図示していないが、バックエンド・サービス・プラットフォーム１５０は、サービス１５５ａ〜ｎに関連する情報を格納するための１つまたは複数のデータベースと、ユーザが管理サーバ１３０への入力を与えて、保守、アップグレードなどの活動を制御および／または管理することを可能にするユーザ・インターフェースとを含むことができる。サービス１５５ａ〜ｎは、レジストリによって提供される個々のサービス（例えば、ドメイン名レジストリ・サービス、ドメイン名提案サービスなど）、または個々のサービスが各カテゴリ内に含まれるサービス・カテゴリのどちらかでよい。サービス１５５ａ〜ｎのそれぞれは、管理サーバ１３０およびゲートウェイ１２０ａ〜ｎのうちの少なくとも１つのゲートウェイと通信することができる。サービス１５５ａ〜ｎのそれぞれは、その名前、許可されたＶＩＰおよび／または好ましいＶＩＰ（複数可）、バージョン番号、動作状態、接続性情報、ＥＰＰハンドラ、ＥＰＰ Ｐｏｌｌハンドラ、ＥＰＰ拡張などの、それに関連する固有情報を有することができる。新しいサービス１５５を配置することができ、バックエンド・サービス・プラットフォーム１５０または他のサービス１５５の通常の機能に影響を及ぼすことなく、既存のサービス１５５を修正または配置解除することができる。バックエンド・サービス・プラットフォーム１５０は、図６に示し、以下でより詳細に説明するコンピュータ・システム６００などの必須機能を有する１つまたは複数の汎用サーバを使用して実装することができる。バックエンド・サービス・プラットフォーム１５０は、各サービス・クラスタ・サーバが複数のサービスまたはサービス・カテゴリを含むクラスタ構成で実装することができる。例えば、Ｊ２ＥＥクラスタリングを使用してサービス１５５ａ〜ｎを編成することができる。そのような場合、サービス・クラスタ・サーバＵＲＬは、所望のサービスを含むサービス・クラスタ・サーバを指し示すことができ、サービス・オブジェクト識別子を使用して、サーバによってホストされる特定のサービスを識別することができる。

さらに、本明細書では特定のブロックを参照しながらシステム１００を説明するが、これらのブロックは説明の便宜上定義されるものであり、構成部分の特定の物理的構成を示唆することを意図するものではないことを理解されたい。さらに、システム１００は、本明細書では具体的には説明していない他の機能を有することができる。本明細書に記載のシステム構成および構成要素は例示的なものであり、変形および修正が可能であることを理解されよう。サービス・インターフェース１１０ａ〜ｎ、ゲートウェイ１２０ａ〜ｎ、管理サーバ１３０、ネットワーク１４５、およびサービス・プラットフォーム１５０は、本明細書では具体的に説明しない他の機能を有することができる。

図２に、本開示の原理に適合する、１つまたは複数のサービスへの、ＥＰＰを介して受信されるサービス要求のインテリジェント・ルーティングのための例示的ゲートウェイ２００を示す。その一例が図２に示される様々な実施形態では、ゲートウェイ２００がネットワーク・インターフェース・モジュール（「ＮＩＭ」）２０１を含むことができる。ＮＩＭ２０１は、従来型ワイヤードまたはワイヤレス媒体のいずれか１つを使用して外部システムおよびネットワークと通信するように構成することができる。ＮＩＭ２０１は、ＶＩＰを使用してアドレス指定可能であるフロントエンド・サービス・インターフェースを提供することができる。さらに、ＮＩＭ２０１は、例えばＴＣＰ／ＩＰ、ＨＴＴＰ、ＨＴＴＰＳなどのインターネット・プロトコル・スイート中の任意のプロトコルを介して、ＥＰＰを介して配信される外部システムからの着信要求を受諾することができる。ＮＩＭ２０１は、受信モジュール２０２に通信可能に結合することができ、受信モジュール２０２に着信ＥＰＰ要求を送信するように構成することができる。

受信モジュール２０２は、要求の構造を求め、求めた要求の構造を標準または周知のＥＰＰ構造と比較することにより、着信要求がＥＰＰ要求であることを検証することができる。受信モジュール２０２は、受信モジュール２０２から着信要求を受信し、要求を解析することのできる解析モジュール２０３に通信可能に結合することができる。様々な実施形態では、受信モジュール２０２および／または解析モジュール２０３は、要求が初めに向けられるターゲットとするサービス・インターフェース（例えば、サービス・インターフェース１１０ａ〜ｎのうちの１つ）のＶＩＰを決定することができる。要求側は、ターゲットとするサービス・インターフェース１１０に関連するＶＩＰに対応するＩＰアドレスまたはドメイン名に要求を送ることにより、ターゲットとするサービス・インターフェースに要求を向けることができる。

要求はまた、ＸＭＬ名前空間情報を含むＸＭＬコードをも含むことができる。ＸＭＬ名前空間は、ＸＭＬ文書で使用される要素名および属性名を、ユニフォーム・リソース識別子（「ＵＲＩ」）参照で識別される名前空間と関連付けることによって修飾する単純な方法を提供することができる。ＸＭＬインスタンスで一意に命名された要素および属性を提供するためにＸＭＬ名前空間を使用することができる。要求によって捜し求められるサービスの名前を要素および／または属性情報の部分として含めることができる。解析モジュール２０３は、ＸＭＬコードを解析して、ＸＭＬ名前空間情報を抽出し、名前空間情報に基づいて、特定の要求によって捜し求められている少なくとも１つのサービスを識別することができる。例えば、名前空間情報を名前提案サービスに関連付けることができる。そのような例では、要求に含まれるＸＭＬコードの解析は、要求が名前提案サービスに対して意図されることを示す。ＸＭＬコードは、ＸＭＬ名前空間情報に加えてＥＰＰ副製品情報（ｓｕｂ−ｐｒｏｄｕｃｔ ｉｎｆｏｒｍａｔｉｏｎ）を含むことができる。そのような場合、ＸＭＬ名前空間情報は、サービス・カテゴリ、例えばドメイン・ネーム・サービスに対応することができ、副製品情報は、サービス・カテゴリ内の特定のサービス、例えばｄｏｔＴＬＤドメイン・サービスまたは名前提案サービスを指定することができる。要求に含まれるＸＭＬコードを解析して、名前空間情報およびＥＰＰ拡張副製品要素を決定するように解析モジュール２０３を構成することもできる。

ルーティング・モジュール２０４は、受信モジュール２０２または解析モジュール２０３からターゲットとするサービス・インターフェース１１０のＶＩＰを受信し、ターゲットとするサービス・インターフェース１１０のＶＩＰに少なくとも部分的に基づいて、要求によって捜し求められるサービス１５５を識別することができる。代替または追加として、特定のバージョン番号または動作状態を有するサービス１５５のみの中から、要求によって捜し求められるサービス１５５を識別するようにルーティング・モジュール２０４を構成することができる。いくつかの実施形態では、ルーティング・モジュール２０４は、ルーティング・テーブル２０５を調べて、ターゲットとするサービス・インターフェース１１０のＶＩＰおよび／または要求されたサービス１５５のバージョン番号もしくは動作状態に基づいて、要求されたサービスが要求側にとって利用可能であるか否かを判定することができる。ルーティング・モジュール２０４は、要求によって捜し求められるサービスの表示を含む、解析モジュール２０３から解析されたＸＭＬを受信することができる。１つの例示的実施形態では、ゲートウェイ１２０またはＶＩＰのモードまたは状態設定に基づいて、ターゲットとするサービス１５５を決定することができる。動作状態「過去」、「アクティブ」、および「次回」を有する複数のエントリをテーブル内に有するサービスがある場合、選択されたサービス１５５は、そのゲートウェイ１２０またはＶＩＰについて定義された動作状態に基づくことができ、動作状態は、サポートされる動作状態のうちのいずれか１つに設定することができる。例えば、動作状態「次回」を有するサービス１５５のみにルーティングするようにゲートウェイ１２０を構成することができ、またはすべての動作状態をサポートするようにゲートウェイ１２０を構成することができる。しかし、いずれの場合でも、各ＶＩＰを動作状態と共に定義することができる。さらに、いくつかの実施形態では、あるＶＩＰを、動作状態「次回」を有するサービスにルーティングするように構成することができ、別のＶＩＰを、動作状態「アクティブ」を有するサービスにルーティングするように構成することができる。ルーティング・モジュール２０４は、以下でより詳細に説明するルーティング・テーブル２０５を参照することにより、要求によって捜し求められるサービスを識別することができる。ルーティング・テーブル２０５は、ルーティング・モジュール２０４の内部または外部に設けることができる。ステータス情報に加えて、ルーティング・モジュール２０４は、要求を適切にルーティングするために、サービスについての他の情報、例えば接続性情報、サービス名なども確認することができる。ルーティング・モジュール２０４はまた、捜し求められているサービスの識別時に要求をルーティングするように構成することもできる。いくつかの実施形態では、ゲートウェイ状態および／またはＶＩＰ状態が、ルーティング・テーブル２０５の外部で定義される。

ディスク、フラッシュ・メモリなどの任意の非一時的コンピュータ記憶媒体を使用してストレージ２０６が実現される。ストレージ２０６は、ルーティング・テーブル２０５を格納することができ、フロントエンド・サービス・インターフェースを提供し、着信サービス要求を解析し、サービス要求がターゲットとするサービス・インターフェースに関連するＶＩＰを求め、ＸＭＬコード解析を実施し、サービス要求をルーティングするなどのためのプログラム命令などの他の情報も格納することができる。１つまたは複数の集積回路（例えば、従来型マイクロプロセッサまたはマイクロコントローラ）として実装することのできるＣＰＵ２０７が、ゲートウェイ２００の動作を制御することができる。ＣＰＵ２０７は、ストレージ２０６に格納された１つまたは複数のプログラム命令を取り出し、１つまたは複数のプログラムを実行して、解析モジュール２０３および／またはルーティング・モジュール２０４が一定の機能を実行するように命令し、および／または一定の機能を実現させることができる。

さらに、本明細書では特定のブロックを参照しながらゲートウェイ２００を説明するが、これらのブロックは説明の便宜上定義されるものであり、構成部分の特定の物理的構成を示唆することを意図するものではないことを理解されたい。さらに、ブロックは、物理的に別個の構成要素に対応する必要はない。例えば、プロセッサをプログラミングし、または適切な制御回路を設けることによって様々な操作を実施するようにブロックを構成することができ、様々なブロックは、どのように初期構成が得られるかに応じて、再構成可能であることがあり、またはそうでないことがある。本開示の実施形態は、回路とソフトウェアの任意の組合せを使用して実装された電子装置を含む様々な装置で実現することができる。

図３に、本開示の実施形態に適合する、１つまたは複数のサービスへの、ＥＰＰを介して受信されるサービス要求のインテリジェント・ルーティングを実現するためにシステム１００によって使用されるルーティング・テーブル３００を示す。その一例が図３に示される様々な実施形態では、ルーティング・テーブル３００は、利用可能なサービス（例えば、サービス１５５ａ〜ｎ）に関連する情報を含むことができる。ルーティング・テーブル３００は、サービスに関するサービスＩＤ３０１を含むことができ、これは、サービス要求に含まれるＸＭＬ名前空間情報に対応することができる。ルーティング・テーブル３００はまた、サービスに関する副製品情報３０２をも含むことができる。上記で論じたように、副製品情報３０２は、サービスのグループ内の個々のサービス、またはサービス・グループ内のカテゴリでよい。例えば、図３に示すように、副製品ｄｏｔＴＬＤは、「ｃＴＬＤ」サービス・グループの部分である。いくつかの実施形態では、ＸＭＬ名前空間および／またはＶＩＰ自体が、ターゲットとするサービスを一意に識別するのに十分ではないとき、副製品情報３０２が必要となることがある。この情報は、サービス要求をサービス・グループ内の特定のサービスまたはカテゴリに向けるのに役立てることができる。グループに属するサービスは、関連する副製品情報３０２を有することができる。ルーティング・テーブル３００は、サービス名３０３、例えば「Ｂｒａｎｄ ｃＴＬＤ Ｄｍａｉｎ Ｃｒｅａｔｅ」、「Ｎａｍｅ Ｓｕｇｇｅｓｔｉｏｎ」なども含むことができる。

ルーティング・テーブル３００は、サービス１５５のそれぞれについてバージョン番号３０５を含むことができ、それは、特定のサービスの複数のバージョンが同時に動作している場合に必要となる可能性がある。そのような場合、バージョン番号３０５は、特定のサービスの適切なバージョンにサービス要求を向ける際に役立てることができる。ルーティング・テーブル３００は接続性情報３０６を含むことができ、接続性情報３０６は、前述のように、サービスまたはサービス・クラスタ・サーバに関連するＵＲＬまたはアドレスを含むことができる。ゲートウェイ（例えば、ゲートウェイ１２０ａ〜ｎのうちの１つ）は、ＵＲＬまたはアドレス情報を使用して、着信サービス要求をルーティングすることができる。さらに、接続性情報３０６は、サービスを求める要求が送られるべきサービス内のオブジェクトに関する情報をルーティングすることを含むことができる。

ルーティング・テーブル３００は、サービスの動作状態３０７を含むことができる。動作状態の例は、非アクティブ、過去、現在、および次回を含むことができる。動作状態の追加の例は、ディスエーブル、オフライン、一時的に利用不能などを含むことができる。サービスを求める要求は、例えば、サービスのバージョン番号および／または動作状態に基づいてルーティングすることができる。さらに、いくつかの実施形態では、サービスのバージョン番号３０５および／または動作状態３０７に基づいて要求をルーティングするようにゲートウェイ２００を構成することができる。例えば、特定のサービスの新しいバージョンをスニッフ・テストするようにゲートウェイのセットをセットアップすることができ、したがってそのゲートウェイのセットは、現バージョンよりも大きい（すなわち、新しい）バージョン番号３０５を有するルーティング・テーブル３００内のマッピングに基づいて、特定のサービスを求める要求をルーティングすることができる。そのような例では、ゲートウェイ２００は、「次回」に設定される動作状態３０７を有することができる。追加および／または代替として、各ＶＩＰは、任意の状態のために構成された単一のゲートウェイがルーティング決定を駆動することを可能にする定義済みの動作状態を有することができる。一方、現バージョンに合致するバージョン番号３０５および／または「現在」に設定された動作状態３０７を有するルーティング・テーブル３００内のマッピングに基づいて、その特定のサービスを求める要求をルーティングすることを続行するように、通常の生成ゲートウェイをセットアップすることができる。ロールバックする決定を行う前にサービスをトラブルシューティングする必要がある場合、現バージョンよりも小さい（すなわち、古い）バージョン番号３０５および／または「過去」に設定された動作状態３０７を有するルーティング・テーブル３００内のマッピングに基づいて、その特定のサービスを求める要求をルーティングするようにゲートウェイ２００をセットアップすることができる。

サービスまたはサービス・グループまたはカテゴリに変更が行われるごとに、ルーティング・テーブル３００を動的に更新することができる。あるいは、ルーティング・テーブル３００を周期的に更新することができる。ルーティング・テーブル３００内に含まれる情報は、中央管理サーバ（例えば、管理サーバ１３０）によって供給することができる。代替または追加として、ルーティング・テーブル３００は、中央管理サーバ、サービス・プラットフォーム（例えば、バックエンド・サービス・プラットフォーム１５０）、外部ルーティング・マネージャ・アプリケーションなどの様々なソースから情報を得ることができる。いくつかの例では、ルーティング・テーブル３００内に含まれる１つまたは複数のサービスおよび／またはサービス・カテゴリに関する情報を固定することができ、かつ／または手動で更新することができる。ルーティング・テーブル３００をいくつかの情報を参照しながら説明したが、図示する情報は例示的なものに過ぎないことを理解されよう。図３に示す情報の代わりに、またはそれに加えて、ルーティング・テーブル３００が他の情報を有することができることを当業者なら理解されよう。

図４は、本開示の実施形態による、多対多マッピングを定義または更新し、多対多マッピングに基づいてＥＰＰを介してサービス要求に応答するためにインテリジェント・ルーティング・システム（例えば、図１に示すシステム１００）によって実施されるプロセス４００の流れ図である。ブロック４１０で、インテリジェント・ルーティング・システムは、フロントエンド・サービス・インターフェースとバックエンド・サービスとの間の多対多マッピングを定義または更新することができる。代替または追加として、インテリジェント・ルーティング・システムは、バックエンド・サービスの一部またはすべてにバージョン番号を割り当て、異なるバージョンのバックエンド・サービスとその動作状態との間の多対多マッピングを定義または更新することができる。インテリジェント・ルーティング・システムの管理サーバは、マスタ・ルーティング・テーブルに多対多マッピングを格納することができる。管理サーバは、マスタ・ルーティング・テーブル内の多対多マッピングを、インテリジェント・ルーティング・システム内のゲートウェイ（例えば、ゲートウェイ１２０ａ〜ｎ）に伝播することができる。代替または追加として、ゲートウェイは、マスタ・ルーティング・テーブルから多対多マッピングを複製することができる。次に、ブロック４２０で、インテリジェント・ルーティング・システムは、多対多マッピングに少なくとも部分的に基づいて、ＥＰＰを介してバックエンド・サービスへのアクセスを求める要求に応答することができる。以下で図５を参照しながらブロック４２０をより詳細に説明する。

図５は、本開示の実施形態による、ＥＰＰを介してサービス要求に応答するためにインテリジェント・ルーティング・システム１００によって実施されるプロセス５００の流れ図である。図１に示すゲートウェイ１２０ａ〜ｎのうちの１つなどのゲートウェイによってプロセス５００を実施することができる。ブロック５１０で、ゲートウェイは、要求側から要求を受信して、レジストリなどのバックエンド・サービス・プラットフォームによって提供される１つまたは複数のバックエンド・サービスにアクセスすることができる。要求側は、ターゲットとするサービス・インターフェースに関連するＶＩＰに対応するターゲットＩＰまたはドメイン名に要求を送る、または向けることにより、フロントエンド・サービス・インターフェースのターゲットとするサービス・インターフェースにＥＰＰを介して要求を送ることができる。次いで、ブロック５２０で、ゲートウェイは要求を解析することができる。例えば、ゲートウェイは、要求を受信したターゲットとするサービス・インターフェースに関連するＶＩＰを決定することができる。ゲートウェイはまた、要求の構造を求め、要求の構造を標準ＥＰＰ構造と比較することにより、要求がＥＰＰ要求であることも検証することができる。

ブロック５３０で、ゲートウェイは、要求によって捜し求められる少なくとも１つのサービスを識別することができる。例えば、ゲートウェイは、ターゲットとするサービス・インターフェースに関連するＶＩＰに少なくとも部分的に基づいて、要求によって捜し求められるサービスを識別することができる。代替または追加として、ゲートウェイは、サービス、ゲートウェイ、およびＶＩＰに関連するバージョン番号および／または動作状態に基づいて、要求によって捜し求められるサービスを識別することができる。例えば、ゲートウェイが、新しいサービスまたは既存のサービスの新しいバージョンをスニッフ・テストするように構成される場合、ゲートウェイは、バージョン番号が現バージョンよりも大きく（すなわち、新しく）、かつ／または動作状態セットが「次回」に対するものである多対多マッピングで、要求によって捜し求められるサービスを探すことができる。ゲートウェイが生成ゲートウェイとして構成される場合、ゲートウェイは、バージョン番号が現バージョンに合致し、かつ／または動作状態セットが「現在」に対するものである多対多マッピングで、要求によって捜し求められるサービスを探すことができる。ロールバックする決定を行う前にサービスをトラブルシューティングする必要がある場合、ゲートウェイは、バージョン番号が現バージョンよりも小さく（すなわち、古く）、かつ／または動作状態セットが「過去」に対するものである多対多マッピングで、要求によって捜し求められるサービスを探すことができる。さらに、要求されるサービスがログインまたは接続である場合、ゲートウェイは、要求に対するＥＰＰグリーティングを提供することができ、ＥＰＰグリーティングは、ターゲットとするサービス・インターフェースに関連するＶＩＰにとって利用可能なサービスのみを含むことができる。ゲートウェイがＶＩＰ動作状態に合致するターゲット・サービスを動的に選択することを可能にする動作状態と共に、ＶＩＰを定義することができる。

ゲートウェイが要求によって捜し求められるサービスを識別した後、ブロック５４０で、ゲートウェイは、識別したサービスが要求側にとって利用可能であるか否かを判定することができる。例えば、サービスがオフラインである場合、ブロック５５０で、ゲートウェイは、サービスの利用不能性を示すメッセージを送ることができる。使用不能性メッセージは、サービスがオフラインとなる時刻、予想されるサービス再活動化時刻などの、システム管理者が要求側に伝達したい追加の情報を含むことができる。ブロック５４０で、サービスが利用可能であるとゲートウェイが判定する場合、ブロック５６０で、ゲートウェイは識別したサービスに要求をルーティングすることができる。ブロック５７０で、ゲートウェイは、要求に応答して、識別したサービスから応答を受信することができる。例えば、応答は、要求が処理されたことを示す要求完了メッセージでよい。最後に、ブロック５８０で、要求側に完了メッセージを通信することができる。例えば、識別したサービスは、ゲートウェイに完了メッセージを送ることができ、ゲートウェイは、要求側に完了メッセージを転送する。完了メッセージは、要求についての追加の情報、例えば要求の実行時間を指定するメタデータなどの、要求側に通信されない追加の情報を含むことができる。そのような情報は、サービス・プロバイダによってネゴシエートされるＳｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ（「ＳＬＡ」）の部分として必要とされることがある。メタデータ情報を使用して、約束されたＳＬＡ基準、例えば要求の実行時間がサービス・プロバイダによって満たされることを検証することができる。ゲートウェイはまた、将来の使用のためにメタデータ情報を記録することができ、要求側に完了メッセージを転送するだけでよい。

本明細書に記載のプロセス５００は例示的なものであり、変形および修正が可能であることを理解されよう。順次であるとして説明した動作を並列に実行することができ、動作の順序を変更することができ、動作を修正し、または組み合わせることができる。例えば、ステップ４０５を省略することができ、サービスの現ステータスを検証することなく、要求をサービスに送ることができる。いくつかの実施形態では、ブロック５２０および５３０を組み合わせて、同時に要求を解析し、要求によって捜し求められるサービスを識別することができる。

特定の実施形態を参照して本開示を説明したが、多数の修正が可能であることを実施形態は理解されよう。例えば、ゲートウェイおよび管理サーバは、本明細書で述べていない追加の機能を有することができる。さらに、専用構成要素および／またはプログラマブル・プロセッサおよび／または他のプログラマブル装置の任意の組合せを使用して、本開示の実施形態を実現することができる。上述の実施形態は特定のハードウェア構成要素およびソフトウェア構成要素に対して参照を行うことがあるが、ハードウェア構成要素および／またはソフトウェア構成要素の異なる組合せも使用することができ、ハードウェアで実現されているものとして説明した特定の操作をソフトウェアで実現することもでき、逆も同様であることを当業者は理解されよう。

図６に、本開示の実施形態に適合するコンピュータ・システム６００を示す。一般には、インテリジェント・ルーティング・システム内の管理サーバ（例えば、管理サーバ１３０）またはゲートウェイ（例えば、ゲートウェイ１２０ａ〜ｎのうちの１つ）の実施形態は、パーソナル・コンピュータ、サーバ、ワークステーション、組込みシステム、多機能装置、またはそれらの組合せなどの様々なコンピュータ・システムで実現することができる。プリンタ・ドライバのいくつかの実施形態をコンピュータ・プログラムとして組み込むことができる。コンピュータ・プログラムは、アクティブと非アクティブの両方の様々な形態で存在することができる。例えば、コンピュータ・プログラムは、ソース・コード、オブジェクト・コード、実行可能コード、または他のフォーマットのプログラム命令からなるソフトウェア・プログラム（複数可）、ファームウェア・プログラム（複数可）、あるいはハードウェア記述言語（ＨＤＬ）ファイルとして存在することができる。上記のいずれかを、記憶装置および圧縮または非圧縮形式の信号を含むコンピュータ可読媒体上で実施することができる。しかし、説明の都合上、システム６００を、当業者には周知である汎用コンピュータとして示す。次に、システム６００に含めることのできる構成要素の例を説明する。

図示するように、システム６００は、少なくとも１つのプロセッサ６０２、キーボード６１７、ポインティング・デバイス６１８（例えば、マウス、タッチパッドなど）、ディスプレイ６１６、メインメモリ６１０、入出力コントローラ６１５、および記憶装置６１４を含むことができる。記憶装置６１４は、例えば、ＲＡＭ、ＲＯＭ、フラッシュ・メモリ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、または他の光ディスク・ストレージ、磁気ディスク・ストレージまたは他の磁気記憶装置、あるいは命令またはデータ構造の形態の所望のプログラム・コードを搬送または格納するのに使用することができ、コンピュータでアクセスすることのできる任意の他の媒体を含むことができる。プリンタ・ドライバのコンピュータ・プログラム実施形態のコピーを、例えば記憶装置６１４上に格納することができる。システム６００はまた、プリンタ（図示せず）などの追加の入出力装置をも備えることができる。システム６００の様々な構成要素は、システム・バス６１２または類似のアーキテクチャを通じて通信する。さらに、システム６００は、動作中にメモリ６１０内に常駐するオペレーティング・システム（ＯＳ）６２０を含むことができる。システム６００が複数のプロセッサ６０２を含むことができることを当業者は理解されよう。例えば、システム６００は、同一のプロセッサの複数のコピーを含むことができる。あるいは、システム６００は、様々なタイプのプロセッサの異種混合を含むことができる。例えば、システム６００は、１つのプロセッサを１次プロセッサとして使用し、他のプロセッサをコプロセッサとして使用することができる。別の例では、システム６００は、１つまたは複数のマルチコア・プロセッサおよび１つまたは複数の単一コア・プロセッサを含むことができる。したがって、システム６００は、プロセッサ（例えば、プロセッサ６０２）のセットにわたって任意の数の実行コアを含むことができる。キーボード６１７、ポインティング・デバイス６１８、およびディスプレイ６１６に関して、これらの構成要素を、当業者に周知の構成要素を使用して実現することができる。他の構成要素および周辺機器をシステム６００に含めることができることも当業者は理解されよう。

メインメモリ６１０は、システム６００の１次記憶エリアとして働き、プロセッサ６０２上で動作中の、バーコード印刷システム内のプリンタ・ドライバなどのアプリケーションによってアクティブに使用されるデータを保持する。アプリケーションは、実行時の間に特定のタスクのセットを実施するようにシステム６００に命令するコンピュータ命令のセットをそれぞれ含むソフトウェア・プログラムであること、および「アプリケーション」という用語を、本教示の実施形態によるアプリケーション・ソフトウェア、アプリケーション・プログラム、デバイス・ドライバ、および／またはプログラムと互換的に使用できることを当業者は理解されよう。メモリ６１０は、以下で説明するように、当業者に周知であるランダム・アクセス・メモリまたは他の形態のメモリとして実現することができる。

ＯＳ６２０は、システム６００内のハードウェアの直接制御および管理、ならびにシステム動作の役目を果たすルーチンおよび命令の一体化された集合である。さらに、ＯＳ６２０は、アプリケーション・ソフトウェアおよびデバイス・ドライバを実行する基盤を提供する。例えば、ＯＳ６２０は、リソース割振り、スケジューリング、入出力制御、メモリ管理などのサービスを実施することができる。ＯＳ６２０は、大部分はソフトウェアでよいが、部分的または完全なハードウェア実装およびファームウェアをも含むことができる。本教示の原理に適合するオペレーティング・システムの周知の例は、ＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）（例えば、ＷＩＮＤＯＷＳ ＣＥ、ＷＩＮＤＯＷＳ ＮＴ、ＷＩＮＤＯＷＳ ２０００、ＷＩＮＤＯＷＳ ＸＰ、およびＷＩＮＤＯＷＳ ＶＩＳＴＡ）、ＭＡＣ ＯＳ、ＬＩＮＵＸ（登録商標）、ＵＮＩＸ（登録商標）、ＯＲＡＣＬＥ ＳＯＬＡＲＩＳ、ＯＰＥＮ ＶＭＳ、およびＩＢＭ ＡＩＸを含む。

上記の説明は例示的なものであり、構成および実装の変形形態を当業者は思い浮かぶことができる。例えば、本明細書で開示する実施形態と共に説明する様々な例示的論理、論理ブロック、モジュール、および回路は、汎用プロセッサ（例えば、プロセッサ４０２）、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または他のプログラマブル論理装置、ディスクリート・ゲートまたはトランジスタ・ロジック、ディスクリート・ハードウェア構成要素、あるいは本明細書に記載の機能を実施するように設計されたそれらの任意の組合せと共に実現または実施することができる。汎用プロセッサはマイクロプロセッサでよいが、代替では、プロセッサは、任意の従来型プロセッサ、コントローラ、マイクロコントローラ、または状態機械でよい。プロセッサは、コンピューティング装置の組合せ、例えばＤＳＰとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、ＤＳＰコアに関連する１つまたは複数のマイクロプロセッサ、または任意の他のそのような構成として実現することができる。

１つまたは複数の例示的実施形態では、記載の機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実現することができる。ソフトウェアによる実現では、本明細書に記載の技法は、本明細書に記載の機能を実施するモジュール（例えば、手続き、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェア・パッケージ、クラスなど）を利用して実現することができる。情報、データ、引数、パラメータ、またはメモリ内容を渡す、および／または受け取ることにより、モジュールを別のモジュールまたはハードウェア回路に結合することができる。メモリ共有、メッセージ・パッシング、トークン・パッシング、ネットワーク伝送などを含む任意の適切な手段を使用して、情報、引数、パラメータ、データなどを渡し、転送し、または送信することができる。メモリ・ユニットにソフトウェア・コードを格納し、プロセッサで実行することができる。メモリ・ユニットをプロセッサ内で、またはプロセッサの外部で実現することができ、プロセッサの外部で実現する場合、当技術分野で周知の様々な手段を介して、メモリ・ユニットをプロセッサに通信可能に結合することができる。

ソフトウェアで実現した場合、機能を、１つまたは複数の命令またはコードとしてコンピュータ可読媒体上に格納し、あるいはコンピュータ可読媒体を介して送信することができる。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータ・プログラムの転送を容易にする任意の媒体を含む、有形の非一時的コンピュータ記憶媒体と通信媒体のどちらも含む。記憶媒体は、コンピュータでアクセスすることのできる任意の入手可能な有形の非一時的媒体でよい。限定ではなく、例として、そのような有形の非一時的コンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、フラッシュ・メモリ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、または他の光ディスク・ストレージ、磁気ディスク・ストレージまたは他の磁気記憶装置、あるいは命令またはデータ構造の形態の所望のプログラム・コードを搬送または格納するのに使用することができ、コンピュータでアクセスすることのできる任意の他の媒体を含むことができる。本明細書では、ディスクおよびｄｉｓｃは、ＣＤ、レーザｄｉｓｃ、光ｄｉｓｃ、ＤＶＤ、フロッピィ・ディスク、およびＢｌｕｅ−ｒａｙ ｄｉｓｃを含み、ディスクは通常、データを磁気的に再現し、ｄｉｓｃは、レーザで光学的にデータを再現する。さらに、任意の接続が、コンピュータ可読媒体と適切に呼ばれる。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、撚線対、デジタル加入者線（ＤＳＬ）、または赤外線、無線、マイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモート・ソースから送信される場合、同軸ケーブル、光ファイバケーブル、撚線対、ＤＳＬ、または赤外線、無線、マイクロ波などのワイヤレス技術は、媒体の定義に含まれる。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。

単数または一体化されたものとして説明されるリソースは、一実施形態では、複数または分散したものでよく、複数または分散されたものとして説明されるリソースを、実施形態では組み合わせることができる。それに応じて、本教示の範囲は、以下の特許請求の範囲だけによって限定されないものとする。特定の実施形態に関して本発明を説明したが、本発明は以下の特許請求の範囲内のすべての修正形態および均等物を包含するものとすることを理解されよう。

Claims (30)

1. Ｅｘｔｅｎｓｉｂｌｅ Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｐｒｏｔｏｃｏｌ（ＥＰＰ）を使用して受信した要求を複数のサービスにルーティングする、コンピュータにより実現される方法であって、
   要求側から、ＥＰＰを介して、前記複数のサービスの中のサービスにアクセスする要求を受信するステップであって、前記要求が、前記ターゲット・サービス・インターフェースに関連するアドレスを介して、複数のサービス・インターフェースのうちのターゲット・サービス・インターフェースに向けられるステップと、
   前記要求を解析して、前記ターゲット・サービス・インターフェースの前記アドレスを決定するステップと、
   前記ターゲット・サービス・インターフェースの前記アドレスに基づいて、前記要求によって捜し求められる前記サービスを識別するステップと、
   前記サービスに前記要求をルーティングし、それによって前記サービスへのアクセスを前記要求側に与えるステップと
   を含む方法。
2. 前記要求によって捜し求められる前記サービスを識別するステップが、
   前記ターゲット・サービス・インターフェースの前記アドレスに関連するルーティング・テーブル内の情報に基づいて、前記要求によって捜し求められる前記サービスを識別するステップであって、前記ルーティング・テーブルが、前記複数のサービス・インターフェースと前記複数のサービスとの間の多対多マッピングを含むステップ
   をさらに含む請求項１に記載の方法。
3. 前記ルーティング・テーブル内の前記情報に基づいて、前記サービスの現バージョンを決定するステップと、
   前記サービスの前記現バージョンに前記要求をルーティングするステップと
   をさらに含む請求項２に記載の方法。
4. 前記ルーティング・テーブル内の前記情報に基づいて、前記サービスの現バージョンを決定するステップと、
   前記サービスの異なるバージョンに前記要求をルーティングするステップと
   をさらに含む請求項２に記載の方法。
5. 前記ルーティング・テーブル内の前記情報に基づいて、前記サービスの動作状態を決定するステップと、
   前記サービスの前記動作状態に基づいて、前記サービスに前記要求をルーティングするステップと
   をさらに含む請求項２に記載の方法。
6. 前記ルーティング・テーブル内の前記情報に基づいて、前記サービスの動作状態を決定するステップと、
   前記ターゲット・サービス・インターフェースの前記動作状態および前記サービスの動作状態に基づいて、前記サービスに前記要求をルーティングするステップと
   をさらに含む請求項２に記載の方法。
7. 前記サービスを識別するステップが、
   前記ターゲット・サービス・インターフェースの前記アドレスに基づいて、前記要求側にＥＰＰグリーティングを提供するステップをさらに含む請求項１に記載の方法。
8. 前記サービスを識別するステップが、
   前記ターゲット・サービス・インターフェースの前記アドレスに基づいて、前記要求によって捜し求められる前記サービスにアクセスするための前記要求側の権限を判定するステップをさらに含む請求項１に記載の方法。
9. 前記サービスを識別するステップが、
   前記ターゲット・サービス・インターフェースの前記アドレスに基づいてアクセス・ポリシーを決定するステップと、
   前記アクセス・ポリシーに基づいて、前記要求によって捜し求められる前記サービスにアクセスするための前記要求側の権限を決定するステップと
   をさらに含む請求項１に記載の方法。
10. 前記複数のサービス・インターフェースと前記複数のサービスとの間の多対多マッピングを定義するステップであって、前記複数のサービス・インターフェースがそれぞれ固有のアドレスを有するステップをさらに含む請求項１に記載の方法。
11. 前記多対多マッピングでルーティング・テーブルを更新するステップをさらに含む請求項１０に記載の方法。
12. Ｅｘｔｅｎｓｉｂｌｅ Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｐｒｏｔｏｃｏｌ（ＥＰＰ）を使用して受信した要求を複数のサービスにルーティングするシステムであって、
    プロセッサと、
    前記プロセッサに通信可能に結合されたメモリと
    を備え、
    前記プロセッサが、
    要求側から、ＥＰＰを介して、前記複数のサービスの中のサービスにアクセスする要求を受信するステップであって、前記要求が、前記ターゲット・サービス・インターフェースに関連するアドレスを介して、複数のサービス・インターフェースのうちのターゲット・サービス・インターフェースに向けられるステップと、
    前記要求を解析して、前記ターゲット・サービス・インターフェースの前記アドレスを決定するステップと、
    前記ターゲット・サービス・インターフェースの前記アドレスに基づいて、前記要求によって捜し求められる前記サービスを識別するステップと、
    前記サービスに前記要求をルーティングし、それによって前記サービスへのアクセスを前記要求側に与えるステップと
    を実行するように構成されるシステム。
13. 前記プロセッサが、
    前記ターゲット・サービス・インターフェースの前記アドレスに関連する前記ルーティング・テーブル内の情報に基づいて、前記要求によって捜し求められる前記サービスを識別するステップであって、前記ルーティング・テーブルが前記メモリに格納され、前記複数のサービス・インターフェースと前記複数のサービスとの間の多対多マッピングを含むステップを実行するようにさらに構成される請求項１２に記載のシステム。
14. 前記プロセッサが、
    前記ルーティング・テーブル内の前記情報に基づいて、前記サービスの現バージョンを決定するステップと、
    前記サービスの前記現バージョンに前記要求をルーティングするステップと
    を実行するようにさらに構成される請求項１３に記載のシステム。
15. 前記プロセッサが、
    前記ルーティング・テーブル内の前記情報に基づいて、前記サービスの現バージョンを決定するステップと、
    前記サービスの異なるバージョンに前記要求をルーティングするステップと
    を実行するようにさらに構成される請求項１３に記載のシステム。
16. 前記プロセッサが、
    前記ルーティング・テーブル内の前記情報に基づいて、前記サービスの動作状態を決定するステップと、
    前記サービスの前記動作状態に基づいて、前記サービスに前記要求をルーティングするステップと
    を実行するようにさらに構成される請求項１３に記載のシステム。
17. 前記プロセッサが、
    前記ルーティング・テーブル内の前記情報に基づいて、前記サービスの動作状態を決定するステップと、
    前記ターゲット・サービス・インターフェースの前記動作状態および前記サービスの動作状態に基づいて、前記サービスに前記要求をルーティングするステップと
    を実行するようにさらに構成される請求項１３に記載のシステム。
18. 前記プロセッサが、
    前記ターゲット・サービス・インターフェースの前記アドレスに基づいて、前記要求側にＥＰＰグリーティングを提供するステップ
    を実行するようにさらに構成される請求項１２に記載のシステム。
19. 前記プロセッサが、
    前記ターゲット・サービス・インターフェースの前記アドレスに基づいて、前記要求によって捜し求められる前記サービスにアクセスするための前記要求側の権限を判定するステップ
    を実行するようにさらに構成される請求項１２に記載のシステム。
20. 装置内のプロセッサによって実行されたとき、Ｅｘｔｅｎｓｉｂｌｅ Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｐｒｏｔｏｃｏｌ（ＥＰＰ）を使用して受信した要求を複数のサービスにルーティングする方法をプロセッサに実行させる命令を含む非一時的コンピュータ可読記憶媒体であって、前記方法が、
    要求側から、ＥＰＰを介して、前記複数のサービスの中のサービスにアクセスする要求を受信するステップであって、前記要求が、前記ターゲット・サービス・インターフェースに関連するアドレスを介して、複数のサービス・インターフェースのうちのターゲット・サービス・インターフェースに向けられるステップと、
    前記要求を解析して、前記ターゲット・サービス・インターフェースの前記アドレスを決定するステップと、
    前記ターゲット・サービス・インターフェースの前記アドレスに基づいて、前記要求によって捜し求められる前記サービスを識別するステップと、
    前記サービスに前記要求をルーティングし、それによって前記サービスへのアクセスを前記要求側に与えるステップと
    を含む非一時的コンピュータ可読記憶媒体。
21. 前記方法が、
    前記ターゲット・サービス・インターフェースの前記アドレスに関連するルーティング・テーブル内の情報に基づいて、前記要求によって捜し求められる前記サービスを識別するステップであって、前記ルーティング・テーブルが、前記複数のサービス・インターフェースと前記複数のサービスとの間の多対多マッピングを含むステップ
    をさらに含む請求項２０に記載の非一時的コンピュータ可読記憶媒体。
22. 前記方法が、
    前記ルーティング・テーブル内の前記情報に基づいて前記サービスの現バージョンを決定するステップと、
    前記サービスの異なるバージョンに前記要求をルーティングするステップと
    をさらに含む請求項２１に記載の非一時的コンピュータ可読記憶媒体。
23. 前記方法が、
    前記ルーティング・テーブル内の前記情報に基づいて前記サービスの現バージョンを決定するステップと、
    前記サービスの異なるバージョンに前記要求をルーティングするステップと
    をさらに含む請求項２２に記載の非一時的コンピュータ可読記憶媒体。
24. 前記方法が、
    前記ルーティング・テーブル内の前記情報に基づいて前記サービスの動作状態を決定するステップと、
    前記サービスの前記動作状態に基づいて、前記サービスに前記要求をルーティングするステップと
    をさらに含む請求項２２に記載の非一時的コンピュータ可読記憶媒体。
25. 前記方法が、
    前記ルーティング・テーブル内の前記情報に基づいて前記サービスの動作状態を決定するステップと、
    前記ターゲット・サービス・インターフェースの前記動作状態および前記サービスの動作状態に基づいて、前記サービスに前記要求をルーティングするステップと
    をさらに含む請求項２２に記載の非一時的コンピュータ可読記憶媒体。
26. 前記サービスを識別するステップが、
    前記ターゲット・サービス・インターフェースの前記アドレスに基づいて、前記要求側にＥＰＰグリーティングを提供するステップ
    をさらに含む請求項２１に記載の非一時的コンピュータ可読記憶媒体。
27. 前記サービスを識別するステップが、
    前記ターゲット・サービス・インターフェースの前記アドレスに基づいて、前記要求によって捜し求められる前記サービスにアクセスするための前記要求側の権限を判定するステップ
    をさらに含む請求項２１に記載の非一時的コンピュータ可読記憶媒体。
28. 前記サービスを識別するステップが、
    前記ターゲット・サービス・インターフェースの前記アドレスに基づいてアクセス・ポリシーを決定するステップと、
    前記アクセス・ポリシーに基づいて、前記要求によって捜し求められる前記サービスにアクセスするための前記要求側の権限を判定するステップと
    をさらに含む請求項２１に記載の非一時的コンピュータ可読記憶媒体。
29. 前記方法が、
    前記複数のサービス・インターフェースと前記複数のサービスとの間の多対多マッピングを定義するステップであって、前記複数のサービス・インターフェースがそれぞれ固有のアドレスを有するステップ
    をさらに含む請求項２１に記載の非一時的コンピュータ可読記憶媒体。
30. Ｅｘｔｅｎｓｉｂｌｅ Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｐｒｏｔｏｃｏｌ（ＥＰＰ）を使用して受信した要求を複数のサービスにルーティングする、コンピュータにより実現される方法であって、
    要求側から、ＥＰＰを介して、前記複数のサービスの中のサービスにアクセスする要求を受信するステップであって、前記要求が、前記ターゲット・サービス・インターフェースに関連するアドレスを介して、複数のサービス・インターフェースのうちのターゲット・サービス・インターフェースに向けられるステップと、
    前記要求を解析して、前記ターゲット・サービス・インターフェースの前記アドレスを決定するステップと、
    前記ターゲット・サービス・インターフェースに関連する前記アドレスに関連するルーティング・テーブル内の情報に基づいて、前記要求によって捜し求められる前記サービスを識別するステップであって、前記ルーティング・テーブルが、前記複数のサービス・インターフェースと前記複数のサービスとの間の多対多マッピングを含むステップと、
    前記ルーティング・テーブル内の前記情報に基づいて、前記サービスの動作状態を決定するステップと、
    前記ターゲット・サービス・インターフェースの前記動作状態および前記サービスの動作状態に基づいて、前記サービスに前記要求をルーティングし、それによって前記サービスへのアクセスを前記要求側に与えるステップと
    を含む方法。
    

Images