(57)【特許請求の範囲】
【請求項１】
複数のユーザ装置と通信し、そしてアプリケーション・プログラミング・インタフェース・コマンドを送受信するように構成された複数のオープンＡＰＩサーバと、
前記複数のオープンＡＰＩサーバから前記アプリケーション・プログラミング・インタフェース・コマンドを受信し、前記複数のオープンＡＰＩサーバから受信されたアプリケーション・プログラミング・インタフェース・コマンドを、アプリケーションに送信し、アプリケーションから応答を受信し、そして前記複数のオープンＡＰＩサーバに前記受信された応答を送信するように構成されたプロキシとを備え、
前記プロキシは、前記オープンＡＰＩサーバの各々に対するローカル・サービス契約実装パラメータを決定するために、サービス契約条件を処理し、前記オープンＡＰＩサーバのそれぞれに前記ローカル・サービス契約実装パラメータを送信し、
前記オープンＡＰＩサーバに送信された前記ローカル・サービス契約実装パラメータは、ローカル・サービス契約条件を実施するように、前記オープンＡＰＩサーバへ指示するものであり、そして、
前記オープンＡＰＩサーバの各々は、前記オープンＡＰＩサーバへ送信されたそれぞれのローカル・サービス契約実装パラメータに基づいて、アプリケーション・プログラミング・インタフェース・コマンドの送信を制御する、ことを特徴とする装置。
【請求項２】
前記サービス契約条件および前記ローカル・サービス契約実装パラメータはサービス契約に関連することを特徴とする請求項１に記載の装置。
【請求項３】
制御パラメータを受信する登録／発見装置をさらに含むことを特徴とする請求項１に記載の装置。
【請求項４】
前記プロキシを少なくとも一部制御するプログラム情報を格納して、前記ローカル・サービス契約実装パラメータを生成するコンピュータ読取可能媒体をさらに含むことを特徴とする請求項１に記載の装置。
【請求項５】
サービス使用状況に基づいて、前記オープンＡＰＩサーバの少なくとも１つは、サービス契約実装パラメータの変更を要求することを特徴とする請求項１に記載の装置。
【請求項６】
プロセッサにより実行される際、コンピュータに、プロキシと通信する複数のオープンＡＰＩサービスを含む電気通信ネットワークを操作する方法を実行させる命令を記憶するコンピュータ可読記憶媒体であって、
前記方法は、
前記プロキシにおいて、サービス契約条件を取得するステップと、
前記プロキシにおいて、複数のオープンＡＰＩサーバの各々に対するローカル・サービス契約実装パラメータを決定するために、前記サービス契約条件を処理するステップと、
前記プロキシからのローカル・サービス契約実装パラメータを、前記オープンＡＰＩサーバのそれぞれへ送信するステップであって、前記それぞれのオープンＡＰＩサーバへ送信されるローカル・サービス契約実装パラメータは、ローカル・サービス契約条件を実施するように、前記オープンＡＰＩサーバへ指示するものである、ステップと、
前記プロキシにおいて、前記オープンＡＰＩサーバからアプリケーション・プログラミング・インタフェース・コマンドを受信するステップであって、前記オープンＡＰＩサーバの各々は、前記オープンＡＰＩサーバへ送信されたそれぞれのローカル・サービス契約実装パラメータに基づき、前記アプリケーション・プログラミング・インタフェース・コマンドを送信する、ステップと、
前記プロキシから、前記受信されたアプリケーション・プログラミング・インタフェース・コマンドを少なくとも１つのアプリケーションへ送信するステップと含むことを特徴とするコンピュータ可読記憶媒体。
【請求項７】
前記プロキシは、システムへの変更に基づいて、その選択を変更することを特徴とする請求項６に記載のコンピュータ可読記憶媒体。
【請求項８】
前記プロキシが通信ボトルネックになることを防ぐために、少なくとも１つの前記オープンＡＰＩサーバは、前記プロキシを迂回し、アプリケーション・プログラミング・インタフェース・コマンドをアプリケーションに直接に送信することを特徴とする請求項６に記載のコンピュータ可読記憶媒体。
【請求項９】
前記プロキシは、所定のアプリケーション・プログラミング・インタフェース・コマンドを阻止することを特徴とする請求項８に記載のコンピュータ可読記憶媒体。
【請求項１０】
プロキシと通信する複数のオープンＡＰＩサーバを含む通信ネットワークを操作する方法であって、
前記方法は、
前記プロキシにおいて、サービス契約条件を取得する工程と、
前記プロキシにおいて、サービス契約条件を処理して、前記複数のオープンＡＰＩサーバの各々に対するローカル・サービス契約実装パラメータを決定する工程と、
前記プロキシから、前記それぞれのオープンＡＰＩサーバに、前記ローカル・サービス契約実装パラメータを送信する工程であって、前記オープンＡＰＩサーバに送信されたそれぞれのローカル・サービス契約実装パラメータは、前記オープンＡＰＩサーバに、ローカル・サービス契約条件を実施するように指示するものである、工程と、
前記プロキシにおいて、前記オープンＡＰＩサーバからアプリケーション・プログラミング・インタフェース・コマンドを受信する工程であって、各オープンＡＰＩサーバは、前記オープンＡＰＩサーバに送信されるローカル・サービス契約実装パラメータのそれぞれに基づき、前記アプリケーション・プログラミング・インタフェース・コマンドを送信する、工程と、
前記プロキシから、前記受信されたアプリケーション・プログラミング・インタフェース・コマンドを、少なくとも１つのアプリケーションに送信する工程とを備えることを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は通信ネットワークに関する。より詳細には、本発明の実施形態は、オープンＡＰＩリソースをサポートする通信ネットワークに関する。
【背景技術】
【０００２】
通信ネットワーク事業者はしばしば、通信ベースのアプリケーションを提供する新しい企業に、そのネットワークを開放したがらない。特に、価格がその事業者のアプリケーションと、新しい企業によって提供されるアプリケーションとの間の主な違いになる場合には、ネットワーク事業者が自身のアプリケーションを減少させる危険を冒すという点で、その抵抗心はいくらか正当化される。実際、通信ネットワーク事業者が、間接コストが低い新しい企業によって提供されるアプリケーションと競合することができない場合は、通信ネットワーク事業者は、単なる「ビットの運び屋」になる恐れがある。
【０００３】
さらに、通信ネットワーク事業者が、新しいアプリケーションおよび企業に、そのネットワークを開放する場合には、サービス・プロバイダやソフトウェア・ベンダなどの第三者によって作成され維持されるアプリケーションによって駆り立てられるネットワーク需要をサポートしなければならないことにより、ネットワーク事業者は、そのネットワークを制御できなくなる可能性が高い。
【０００４】
ネットワークを開放したがらないことは正当化されるが、通信ネットワーク事業者がそうしない場合は、新しい企業およびアプリケーションが生み出す可能性のある潤沢な市場を失う恐れがある。非常に新しい企業は、従来の電気通信ネットワークの境界外で事業を営んでいるので、新しいアプリケーションによって、通常はネットワークを使用しない顧客を導き入れる、完全に新しいサービスが創造され得る。さらに、電気通信市場の競争を増やそうとする政府の指示（government mandated force）によって、ネットワーク事業者は、そのネットワークを開放するように強いられ得る。
【０００５】
あるシナリオでは、ネットワークとアプリケーションの間のトランザクションは、アプリケーション・プログラミング・インターフェース（ＡＰＩ：Application Programming Interface）を形成する、１組のインターフェースおよびデータ型に基づくことが有益である。そのＡＰＩが標準化され、広く使用可能である場合、こうしたＡＰＩは、オープンＡＰＩと称される。オープンＡＰＩは一般に、ＡＰＩを入念に定義し、その使用を広めるソフトウェア団体によって確立される。たとえばＰａｒｌａｙ団体内で最初に定義され、また３ＧＰＰおよびＥＴＳＩのコンテキストで標準化されたＰａｒｌａｙ／ＯＳＡ  ＡＰＩなど、オープンＡＰＩの多数のセットが存在する。Ｐａｒｌａｙ／ＯＳＡ  ＡＰＩ（ＯＳＡは、オープン・サービス・アーキテクチュア（Open Service Architecture）を表す）は、９個の直交するサービス機能関数（ＳＣＦ：Service Capability Function）のセットを形成し、このＳＦＣはそれぞれ、異なる電気通信領域、すなわち呼制御、ユーザ・インタラクション、移動性、ターミナル機能、データ・セッション制御、汎用メッセージング、接続性管理、プレゼンス／可用性および課金に対処する。
【０００６】
したがって、従来技術のＡＰＩベースのシステムは、１組のオープンＡＰＩと、サーバを介して情報を送受信する１組のユーザと、情報を運ぶ通信ネットワークと、オープンＡＰＩを介して情報を受信し、そのＡＰＩに基づいてアプリケーションを実行し、またオープンＡＰＩを介してネットワークに応答情報を返送する第三者所有のアプリケーションとを含む。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
従来技術のＡＰＩベースのシステムは、有用であるが、大きな制限を受ける。まず、従来技術のＡＰＩベース・システムでは、オープンＡＰＩサーバとアプリケーションの間に、１対１の関係がある。この制限を克服するために、従来技術のＡＰＩベース・システムは、オープンＡＰＩサーバによって名乗るために使用され、またどのＡＰＩが使用可能であるか発見するためにアプリケーションによって使用される、登録／発見エンティティ（Registration and Discovery entity）を含んでいる。複数の登録／発見エンティティが存在する場合の根本的な問題は、どの登録／発見エンティティを、オープンＡＰＩサーバが使用すべきであるかということである。その問題を回避するために、オープンＡＰＩサーバは、すべての使用可能な登録／発見エンティティに名乗ることができる。しかし、これによって問題が生じる。というのは、オープンＡＰＩサーバを複数の登録／発見エンティティに割り当てるためには、システム全体の構成が知られている必要があり、またそれを判断するのは難しいからである。
【０００８】
従来技術のＡＰＩベース・システムの別の問題は、アプリケーションがそのサービスのためにどのオープンＡＰＩサーバを使用すべきか発見した後には、その関係が静的であることである。最初のオープンＡＰＩサーバは、ある瞬間に有益であったかもしれないが、たとえばオープンＡＰＩサーバの障害など、その後の出来事によって、非常に大きな問題がもたらされ得る。その場合、そのアプリケーションによって開始された回復セッション無しでは、特定のサービスを提供するそのアプリケーションを、もはや使用することができない。従来技術のオープンＡＰＩベース・システムのさらに別の問題は、サービス・レベル・アグリーメントの実施の難しさである。
【０００９】
上記（および他の）制限に鑑みて、新しいオープンＡＰＩベースのシステムが提案されてきた。そのシステムは、オープン・アプリケーションおよびオープンＡＰＩサーバを含むが、通信ネットワークは、オープン・アプリケーションとオープンＡＰＩサーバの間に、プロキシ装置を挿入する。そのプロキシ装置は、起動を処理して、重複を回避し、どのオープンＡＰＩサーバが特定のＡＰＩイベントまたはメソッド呼出しを処理するかを判断し、様々なオープン・アプリケーションとオープンＡＰＩサーバの間で通信負荷のバランスを取り、またオープン・アプリケーションとオープンＡＰＩサーバの間でイベントを処理（dispatch）することができる。
【００１０】
プロキシは、将来性があるオープンＡＰＩへの追加であるが、提案されているプロキシは、システムが成功するのに予測可能な他の問題に対処できていない。したがって、オープンＡＰＩベース・システムの他の問題に対処するプロキシは、有益である。オープンＡＰＩベース・システムの他の問題に対処するプロキシを含む通信ネットワークも同様に、有用である。さらに、オープンＡＰＩベース・システムの他の問題に対処するプロキシを操作する方法もやはり、有用である。オープンＡＰＩベース・システムの他の問題に対処するプロキシを操作する、コンピュータ・プログラムを格納するコンピュータ可読媒体もまた、有用である。
【課題を解決するための手段】
【００１１】
従来技術にこれまで関連していた欠点は、オープンＡＰＩベース・システムの制限に対処するように、通信ネットワークを操作するための新規な方法によって対処される。
【００１２】
従来技術にこれまで関連していた欠点は、新規なプロキシ、およびオープンＡＰＩベース・システムの制限に対処する、こうしたプロキシを含む通信ネットワークによって対処される。
【００１３】
従来技術にこれまで関連していた欠点は、オープンＡＰＩベース・システムの制限が対処されるように、プロキシを、したがって通信ネットワークを操作するコンピュータ・プログラムを格納する、コンピュータ可読媒体によって対処される。
本発明の教示は、以下の詳細な説明を、添付の図面と併せて考慮することによって、容易に理解されよう。
【発明を実施するための最良の形態】
【００１４】
理解し易いように、可能である場合は、同じ参照番号を使用して、諸図面に共通する同一の要素を示す。
【００１５】
本発明は、アプリケーションとオープンＡＰＩサーバの間にプロキシを組み込む、新規なオープンＡＰＩベースの方法、装置、コンピュータ可読媒体およびシステムを対象とする。本発明によるオープンＡＰＩシステムは、２つのタイプの情報フロー、すなわちネットワーク内で発生し、アプリケーションに転送される情報フローと、アプリケーションからネットワークに流れる情報フローとを処理することができる。両方のフローは、ＡＰＩを介して伝達されるが、以下では、第１のタイプはイベント（event）と称され、第２のタイプはメソッド呼出し（method invocation）と称される。
【００１６】
図１に、本発明の原理によるオープンＡＰＩベースのシステム１００を示す。このシステム１００は、オープン・アプリケーション・プログラミング・インターフェースを介して情報を渡す、アプリケーション１０２およびオープンＡＰＩサーバ１０４を含む。アプリケーション１０２は、プログラム、エンタープライズ・アプリケーション・タイプのシステム、またはＡＰＩアクセス・ネットワーク・リソースを使用して動作する他のリソースであり得る。オープンＡＰＩサーバ１０４は、コンピュータ１０６、送受話器１０８、または電話システム１１０などの幅広いユーザ装置のいずれかに接続された通信ノードである。したがって、ユーザ装置は、アプリケーション１０２を実行しようとする任意の装置であると理解されたい。ユーザ装置の１つがオープンＡＰＩサーバ１０４に接触し、次いで、次に述べるようなやり方で、このオープンＡＰＩサーバがアプリケーション１０２に情報を渡すときに、アプリケーション１０２によって提供されるサービスが実施される。
【００１７】
図示するように、オープンＡＰＩサーバ１０４とアプリケーション１０２の間に、プロキシ７００がある。オープンＡＰＩサーバ１０４およびプロキシ７００は、一般に所有されるネットワーク１０３の一部であり得る。さらに、アプリケーション１０２は、アプリケーション・レベルで示されているが、１つまたは複数のアプリケーション１０２もまた、ネットワーク１０３の所有者によって所有され運営されることが可能である。次により詳細に述べるように、プロキシ７００は、オープンＡＰＩサーバ１０４とアプリケーション１０２の間の通信を、透過的に処理する。そのために、アプリケーション１０２は最初に、プロキシ７００に、認証し、次いで、そのプレゼンスを登録し、それは、アプリケーション１０２が、登録／発見装置１１４に接触することによって達成される。この登録／発見装置は、アプリケーション１０２を識別し、受け付け、使用するために、プロキシ７００によって必要とされる登録情報（ＩＰアドレス、開始状態、地理的位置、許容可能なＡＰＩなど）を受信し、または認証機構からそれを判断し得る。
【００１８】
アプリケーション１０２の登録は主として、アプリケーション１０２がその開始状態を告げるときに行われる。アプリケーション１０２は、認証されると、オープンＡＰＩサーバ１０４によって提供されるサービスを使用して、発見し、選択し、開始することができる。登録によって、プロキシ７００は、すべてのオープンＡＰＩサーバ１０４の機能を判断し、次いで、その機能を組み合わせて、機能の上位セットを形成する。次いで、プロキシ７００は、登録／発見装置１１４に上位セット機能を登録して、登録／発見装置１１４が、サービスを発見中の認証済みアプリケーション１０２に、より汎用的なサービス・セットを通知することを可能にする。これによって、オープンＡＰＩサーバ１０４に、単一の位置だけで登録する能力も提供され、次により詳細に述べる、オープンＡＰＩネットワークを監視し維持するための中心地も提供される。
【００１９】
図２に、プロキシ７００の一実施形態のハイレベル・ブロック図を示す。プロキシ７００は、プロセッサ７１０、ならびに制御プログラム７２５およびデータ構造体７２７を格納するためのコンピュータ・メモリ７２０を含む。プロセッサ７１０は、たとえば電力供給、クロック回路、キャッシュ・メモリなど、およびメモリ７２０内に格納されたソフトウェア・ルーチンを実行する助けとなる回路などの従来のサポート回路７３０と連携する。したがって、本明細書で、ソフトウェア・プロセスとして論じるプロセス工程の一部は、ハードウェア内で、たとえば様々な工程を実施するためにプロセッサ７１０と連携する回路として実装し得ることが企図されている。プロキシ７００は、通信ネットワーク全体、アプリケーション１０２およびオープンＡＰＩサーバ１０４とのインターフェースを形成する、入出力回路７４０をも含む。
【００２０】
プロキシ７００は、本発明による様々な制御機能を実施するようにプログラムされた汎用コンピュータとして示されているが、本発明は、ハードウェア内で、たとえば特定用途向け集積回路（ＡＳＩＣ）として実装し得る。したがって、本明細書で述べるプロセス工程は、ソフトウェア、ハードウェア、またはその組合せによって同等に実施されるものと広く解釈されることが意図されている。さらに、ソフトウェアまたはファームウェアで実装される場合、プロキシ７００は、プロセッサ７１０によって実行および／またはアクセスし得る情報を格納する、コンピュータ可読媒体７５０を含む。ハードウェアで実装されようが、ソフトウェアで実装されようが、またハードウェア／ソフトウェアの組合せで実装されようが、プロキシ７００は、以下で述べる機能を遂行するように動作する。
【００２１】
プロキシ７００によって実施される第１の機能は、複数のオープンＡＰＩサーバ１０４、ユーザ、アプリケーション１０２および通信ネットワーク事業者の間でサービス契約を実施することにある。サービス契約の一部であり得るパラメータの例には、オープンＡＰＩサーバ１０４によって許容されるリソースの使用状況（usage）、たとえば呼出しの最大数、呼出し単位に許容される呼出しのレグの最大数、開かれるメールボックスの最大数、請求、時間制限など、および許容されるＡＰＩが含まれる。実施形態によっては、プロキシ７００は、オープンＡＰＩサーバ１０４に、サービス契約を動的に配布する。
【００２２】
図３Ａに、プロキシ７００を介してサービス契約制御を実施するためのシステム２００を示し、図３Ｂに、システム２００の操作のフローチャートを示す。以下では、これらの図の両方を参照する。システム２００は、企業オペレータ（enterprise operator）２０２、およびデータベース２０４を介してプロキシ７００に動作可能に接続する、登録／発見装置１１４を含む。しかし、データベース２０４は、任意選択であり、一部の実施形態では、データベース２０４を組み込まないことを理解されたい。次に図３Ｂを参照すると、サービス契約制御の方法２４５が、工程２４７で開始し、続いて、工程２４８で、サービス契約制御情報を取得し登録する。そのために、企業オペレータ２０２は、１組の制御パラメータとして、登録／発見装置１１４にサービス契約条件を提供し、工程２５０で、この発見装置１１４は、データベース２０４内に制御パラメータを格納する。次いで、工程２５１で、プロキシ７００は、制御パラメータを取り出し、工程２５２で、ローカル契約として、グローバル契約情報を、関連するオープンＡＰＩサーバ１０４（サービス契約条件の影響を受けるもの）に、どのように割り当てるかを計算する。次いで、工程２５３で、プロキシ７００によって、ローカル契約が、オープンＡＰＩサーバ１０４に送信されて、工程２５４で、個々のオープンＡＰＩサーバ１０４に、その実装パラメータが送信される。
【００２３】
オープンＡＰＩサーバ１０４がその実装パラメータを有した後に、工程２５５で、トリガによって、ローカル・オープンＡＰＩサーバ１０４は、そのローカル・サービス契約が不十分であると判断する。たとえば、ローカル・オープンＡＰＩサーバ１０４が、１０回の呼出しに制限されている場合、それが８呼出しを処理しているときに、そのローカル・オープンＡＰＩサーバ１０４は、１０回の呼出しより多くを処理するには許可が必要であり得ることを示すトリガを設定することができる。その場合、工程２５６で、ローカル・オープンＡＰＩサーバ１０４は、そのサービス契約の変更を求める要求を、プロキシ７００に送信する。一方、工程２５７で、プロキシ７００は、こうした要求を識別するために、オープンＡＰＩサーバ１０４を監視している。工程２５８で、変更要求が受信された後に、工程２５８で、プロキシ７００は、関連するオープンＡＰＩサーバに、その現在のローカル使用状況について問い合わせる。その使用状況について判断されると、関連するオープンＡＰＩサーバのローカル契約の再計算のために、ループが工程２５２に戻される。したがって、プロキシ７００は、サービス契約内にとどまるが、現在の使用状況に基づいたリソースを割り当てることができる。
【００２４】
各エンティティは、それぞれ異なるやり方で、サービス契約条件に対処し得ることを理解されたい。たとえば、オープンＡＰＩサーバ１０４ｃのサービス契約は、オープンＡＰＩサーバ１０４ｃに、またはそこから渡される、スピードが重視される情報がないことを指定し得る。したがって、プロキシ７００は、他のオープンＡＰＩサーバ１０４ａおよび１０４ｂのＡＰＩに、より高い優先度を与えることができる。
【００２５】
エンティティに実装パラメータが提供された後に、工程２５５で、様々なエンティティが、その契約条件の一部を実施する。オープンＡＰＩサーバ１０４が、特定のアプリケーション・セットについて、そのローカル・サービス契約に更新が必要であると判断すると、このオープンＡＰＩサーバ１０４は、プロキシに問い合わせ、工程２５６で、契約の更新を要求し得る。アプリケーション・セットのサービス契約が停止すると、次いで、この方法は、工程２５７に止まる。たとえば、ユーザがオープンＡＰＩサーバ１０４に接触したときに、そのサーバは、そのサービス契約パラメータを探索し、ユーザ２０６から求められる特定の呼出しまたはサービスを扱うことができるかどうかを判断する。たとえば、オープンＡＰＩサーバ１０４ａが最大呼出し数を有する場合は、その数を超えるすべての呼出しが拒否され、または別のオープンＡＰＩサーバ１０４に向けられ得る。
【００２６】
オープンＡＰＩモデルがますます普及するにつれて、オープンＡＰＩエンティティの数は増加する。これは、そのモデルに、管理および統合の問題をもたらす。オープンＡＰＩシステムは、非常に多岐に渡る地理的位置に常駐する様々なエンティティからなる可能性があるため、これによって、特定の問題が提示される。システム規模の遵守を確保するために、オープンＡＰＩエンティティの振舞いを監視しなければならず、また必要であれば、適切な修正措置が取られなければならないので、地理的位置が様々であることによって、問題が提示される。大規模なネットワーク上のシステム規模の変更は、極めて難しく、時間がかかり、大きな費用がかかることなので、修正措置は、大きな懸念である。プロキシ７００は、こうした問題に、有効な解決策を提供する。さらに、プロキシ７００は、透過的なやり方で、それを行うことができる。
【００２７】
図４Ａに、様々なオープンＡＰＩサーバ１０４が大陸全体に渡って分散される、ヨーロッパの地理地図を示す。そのオープンＡＰＩサーバはすべて、同じプロキシ７００によって管理される。プロキシ７００は、単一のエンティティである必要はなく、プロキシ７００を協調的に形成する、相互接続された装置、システムおよびネットワークのネットワークで構成され得る。プロキシ７００によって、システム規模の変更が広められ得るので、そのプロキシ７００を集中管理することによって、こうした変更が簡略化される。
【００２８】
図４Ｂに、プロキシ７００がどのようにして中央エンティティになるかについて示す。工程５０５で、プロキシ７００は、オープンＡＰＩサーバ１０４から、登録および再登録を受け付ける。工程５０７で、プロキシ７００は、すべてのオープンＡＰＩサーバ１０４のサービス機能を判断し、次いで、その機能の上位セットを判断する。次いで、プロキシ７００は、すべての知られている登録／発見装置１１４に、この上位セットを登録する。中央登録ポイントとして働くことによって、プロキシは、すべてのオープンＡＰＩサーバ１０４、登録／発見装置１１４、およびオープンＡＰＩネットワーク内のアプリケーションの状況について知るようになる。これによって、プロキシ７００は、システム全体のマネージャおよびインテグレータの働きをすることができる。
【００２９】
図４Ｃに、プロキシ７００がどのようにシステムを管理し統合し得るかの一方法３０１を示す。図示するように、方法３０１は、工程３０３で開始し、続いて、工程３１５で、全オープンＡＰＩシステムの動作を監視する。工程３１７で、オープンＡＰＩシステム２００が正常に機能していると判断される場合、方法は、工程３１５に戻り、したがって、動作全体を監視し続ける。しかし、工程３１７で、異常が検出される場合、プロキシ７００は、工程３１９に進み、適切な修正措置が取られる。適切な措置には、登録／発見装置１１４を再開し、アプリケーション１０２に、ネットワーク内で検出された問題について通知すること、および／またはオープンＡＰＩサーバ１０４が再びアクティブになったとき、オープンＡＰＩサーバ１０４に開始状態を再度割り当てることが含まれる可能性がある。プロキシが代替のオープンＡＰＩサーバ１０４を見つけて、オープンＡＰＩシステム２００の保全性が保証される場合には、アプリケーション１０２への異常についての通知が、遅延され、または実行されないことがあることに留意されたい。
【００３０】
プロキシが取り得るある重要な修正装置は、不適切なまたは危険なＡＰＩが、オープンＡＰＩシステム中に広まるのを防ぐためのファイアウォールとして働くことである。これは、局所的なまたはシステム規模の故障を引き起こし得るＡＰＩを開発することが可能な第三者のためにネットワーク・リソースを開放したいと望む外部ネットワーク事業者のドメイン内で、登録／発見装置１１４が動作する場合、特に有効になる。プロキシ７００に、こうしたＡＰＩを阻止するフィルタの働きをさせることは、特に有益である。
【００３１】
上記で論じたように、プロキシ７００は、他のオープンＡＰＩシステム・エンティティを認識しており、特定のアプリケーション１０２に特定のオープンＡＰＩサーバ１０４を、最初だけでなく、動的にも直接に割り当てることができる。割当ては、アプリケーション１０２およびオープンＡＰＩサーバ１０４の追加など、ネットワークの状態を反映するように変更されることも、またシステム障害の結果として変更されることもある。この動的な割当て機能によって、ネットワークの可用性が大幅に高まる。
【００３２】
上記内容は、アプリケーション１０２とオープンＡＰＩサーバ１０４の間のすべての通信が、プロキシ７００を通過することを示唆し得るが、これは、必須ではない。図５に、特定のＡＰＩ呼出しが、プロキシ７００を迂回し、オープンＡＰＩサーバ１０４ｂとアプリケーション１０２ｂの間で直接に実行されるオープンＡＰＩシステム４００を示す。図示するように、ＩｐＣａｌｌと称される特定の呼出しは、回線４０１上で直接に伝達される。しかし、他のＡＰＩ呼出しは、プロキシ７００によって処理される。直接ルーティングによって、プロキシ７００がパフォーマンス・ボトルネックとなることを防ぐことができる。
【００３３】
図５に、プロキシ７００によって実施されるソフトウェア（またはハードウェア）プロセスも示す。これは、上述のサービス契約を処理するサービス契約ソフトウェア４０２、オープンＡＰＩサーバ１０４と様々なアプリケーション１０２の間の通信負荷のバランスを取るロード・バランス・ソフトウェア４０４、上述のオープンＡＰＩエンティティを管理する管理ソフトウェア４０６、ならびにオープンＡＰＩサーバ１０４とアプリケーションの間の様々なＡＰＩ呼出しの処理（dispatch）を制御するイベント処理装置（event dispatcher）４０８を含む。完全にするために、図５に、登録／発見装置１１４およびデータベース２０４をも示す。
【００３４】
適切に構成された場合、プロキシ７００は、透過的である。すなわち、オープンＡＰＩサーバ１０４は、プロキシ７００を介して通信していることを知っている必要はなく、またアプリケーション１０２は、おそらくは最初の登録時を除いて、プロキシ７００を介して通信していることを知っている必要はない。プロキシ７００は、適切な起動条件を提供し、複数のアプリケーションが使用可能である場合には、どの競合アプリケーションがイベントを受信するか判断し（交通警官として働き）、潜在的な問題を回避するためにイベント転送に遅延を導入し、中央管理機能を提供し、サービス契約を実施し、ネットワークを隠し、他のリソースに、未処理のまたは新しい要求を中継することを選択し（したがって、ネットワークの可用性を高め）、システムの保全性を維持するためにファイアウォールとして働き、複数のリソースから情報を収集し、必要に応じてかつ／または適切なときに、情報を配布し、システム規模の変更およびその統合を容易にし、またアプリケーション１０２およびオープンＡＰＩサーバ１０４を集中監視することができる。
【００３５】
上記内容は、本発明の実施形態を対象としているが、本発明の他のおよびさらなる実施形態を、その基本的な範囲から逸脱せずに、考案することができ、またその範囲は、特許請求の範囲によって定められる。
【図面の簡単な説明】
【００３６】
【図１】本発明の原理によるＡＰＩベースのシステムの概要を示す図である。
【図２】プロキシの一般的な概念を示す図である。
【図３Ａ】サービス接触制御を実施するためのシステムを示す図である。
【図３Ｂ】サービス接触制御を実施するフローチャートを示す図である。
【図４Ａ】地理的に分散されたオープンＡＰＩベースのシステムを示す図である。
【図４Ｂ】オープンＡＰＩエンティティの登録を示す図である。
【図４Ｃ】オープンＡＰＩシステムを監視するプロキシを示す図である。
【図５】本発明の原理による代替ＡＰＩベースのシステムの図である。
【図１】
0004822713.tif 000002
【図２】
0004822713.tif 000003
【図３Ａ】
0004822713.tif 000004
【図３Ｂ】
0004822713.tif 000005
【図４Ａ】
0004822713.tif 000006
【図４Ｂ】
0004822713.tif 000007
【図４Ｃ】
0004822713.tif 000008
【図５】
0004822713.tif 000009