"通信網を動作する方法であって、前記通信網は少くとも一つのサービスノードと、前記少くとも一つのサービスノードへのサービスアプリケーションによるアクセスを制御するように構成された登録サーバと、一つ以上の通信サービスを実行している、前記登録プラットホームから離れているプラットホームと、を含み、前記方法は、a前記通信網に接続された前記又は各サービスノード上で利用可能なサービス資源を識別するデータを配信する段階と、b前記段階aで識別された前記サービス資源の少くとも一部に対する、前記プラットホームによるアクセスの要求を、登録サーバに通信する段階と、c前記登録サーバにおいて、前記段階bの前記要求に応答して、前記要求されたサービス資源を提供している少くとも一つのサービスノードへの前記サービスアプリケーションによるアクセスを許すサービス合意を実行する段階と、dその後で、前記サービスアプリケーションを前記少くとも一つのサービスノードにバインドさせる段階と、を含み、前記段階cにおいて、前記サービス合意が、前記サービスアプリケーションの複数のインスタンス、及び/又は複数のサービスノードを特定し、前記段階dにおいて、i前記サービスアプリケーションの複数のインスタンスを前記少くとも一つのサービスノードにバインドさせる段階と、ii前記サービスアプリケーションの少くとも一つのインスタンスを複数のサービスノードにバインドさせる段階と、のうちの少くとも一方を含むことを特徴とする、方法。前記段階dは、サービスアプリケーションの複数のインスタンスを前記少くとも一つのサービスノードにバインドさせる段階を含み、前記方法は、一連の初期事象の通知を前記サービスアプリケーションの前記複数のインスタンスに配信する段階を含む、請求項1に記載の方法。複数のサービスノードをサービスアプリケーションの前記少くとも一つのインスタンスに登録する段階を含み、前記方法は、一連の初期セッション要求を前記複数のサービスノードに配信する段階を含む、請求項1又は2に記載の方法。前記登録サーバによって、前記登録サーバに登録された複数のサービスノードを繰返しポーリングして、前記サービスノードの利用可能性における何らかの変化を示しているデータを前記又は各サービスアプリケーションに通信する段階を、更に含む、請求項1乃至3の何れか1項に記載の方法。前記登録サーバに登録された複数のサービスアプリケーションのインスタンスの各々を繰返しポーリングする段階と、前記サービスアプリケーションのインスタンスの利用可能性における何らかの変化を示しているデータを、前記又は各サービスノードに通信する段階と、を更に含む、請求項1乃至4の何れか1項に記載の方法。請求項1乃至5の何れか1項に記載の方法に従って動作するように構成されている、通信網。請求項6に記載の通信網で使用するように構成された、登録サーバ。この発明を実施するシステムについて添付の図面を参照して詳細に記述して行く。通信網はアクセス網1とコア網2とを備えている。顧客端末3a,3bがアクセス網1に接続されている。サービスプロバイダプラットホーム4a,4bもまたアクセス網1に接続されている。登録サーバ5は網に接続され、以下に記述するようにAPIアプリケーションプログラマーズインターフェースを網資源に対して実現するのに使用される。これらの網資源は多数のサービスノード6a,6b,6cを含み、その各々はそれぞれのゲートウェイGW1,GW2,GW3を含んでいる。サービスノードはハードウェアとソフトウェアとを含んでいて、それが例えば番号ナンバ変換アプリケーション、対話形音声認識及びメッセージングサービスを実行する。上述のように、用語サービスノードはここでは広義に使用されていて、サービスアプリケーションを実行するのに使用されるノードを指していて、網の縁の位置にあるノードに限定されていない。図2はサービス資源ノードの一つの構造をさらに詳細に示している。この例では、サービスノードは網インテリジェンスプラットホームNIPとして知られているプラットホームである。そこには多数の通信サーバCSを含んでいて、CSは網シグナリングを終端し、この例ではシグナリングシステムナンバ7SS7共通チャンネルシグナリングとなっている。グローバルデータサーバGDSはシグナリングレートを監視して、呼の統計を集めている。トランザクションサーバTSは基本的なサービス制御機能であってサービスノードにより求められているものを実施する。オーバーロード制御サーバOCSは過負荷制御保護をサービスノードについてと、サービスノードから下流の部品についてとの両方に対して実施する。例えば、OSCは過負荷状態が検出されるときにはコールギャッピング呼の間隔をとるを始動させる。オーバーロード制御サーバとトランザクションサーバとは共通高速バスに接続されている。ゲートウェイGWはサービスマネージャオブジェクトの多数のインスタンスを支持していて、このオブジェクトは特定のサービスアプリケーションに対して、サービスノード内部の異なる部品の資源を割当てる。サービスノードを作り上げている異なるサーバはそれぞれが各UNIX登録商標ワークステーション上で実施される。異なるサーバは高速光ファイバFDDIローカルエリア網LANS21,22を介して通信する。図3に模式的に示したように、通信網は、アプリケーションプログラマーズインターフェースAPIを、網の縁でいわゆるエンタープライズ事業ドメインで実行しているアプリケーションと網オペレータドメインでサービスを実施するのに使用される網部品との間で実現する。この例では、インターフェースはParlayAPI仕様書に規定されている。図4はParlayパーレイインターフェースを実施している網の部品間のインターフェースをもっと詳細に示している。このインターフェースはオブジェクト指向のもので、インターフェースの二つのカテゴリィを用いて実施される。第一はサービスインターフェースであり、第二はフレームワークインターフェースである。アプリケーションのサービスインターフェースは網のもつ能力機能にアクセスする。フレームワークインターフェースはサービスインターフェースについて環境を用意する。フレームワークインターフェースは認証、ディスカバリィ及び登録というプロセスを実現する。フレームワークオブジェクトで網ドメインにあるものは、クライアントFWフレームワークオブジェクトでユーザドメインにあるものと通信をする。加えて、クライアントアプリケーションとParlayサービスとの間に直接インターフェース4.2が存在する。しかし、こういった直接インターフェース4.2は通常はあるアプリケーションがフレームワークインターフェース4.1を介してサインオン計算機へのアクセス、すなわちログオンと同義した後に限ってアクセスされる。この例では、フレームワークFWを実現するオブジェクトが登録サーバ5の上に置かれている。クライアントアプリケーションとクライアントFWとはサービスプロバイダプラットホーム4a,4b上で実行する。Parlayサービスでゲートウェイを含むものがサービスノード6a,6b,6cで実施される。クライアントアプリケーションの一つが初期化されるときには、まず登録サーバを経由してParlayAPIにサインオンされる。Parlay認証オブジェクトは登録サーバ上でインスタンス化されて、認証インターフェースを用意し、これが登録サーバとクライアントアプリケーションとの相互認証を可能とする。認証プロセスでは、アプリケーションは識別用コードを登録サーバに戻す。登録サーバは認識されたアプリケーションについてのデータベースを含んでいる。登録サーバはアプリケーションID上でルックアップ一覧を実行しまたアプリケーションに特有の暗号キーを検索することもできる。ディスカバリィ相フェーズでは、アプリケーションは登録サーバから、プロパティ名とプロパティ値とによって識別されたサービス特徴のディスカバリィを要求する。ParlayAPI仕様書はプロパティ名の組を定義する。Parlayサービスは適当な名前を用いて登録サーバに登録する。ディスカバリィ要求に応答して、登録サーバはサービスIDを戻すが、このIDは要求された網サービスを識別する。後に、アプリケーションはサービスを選ぶ。これをするためにアプリケーションはサーバに対して、ディスカバリィ問合せに応答して受取ったサービスIDを戻す。登録サーバはそこでサービストークンを戻すが、このトークンはサービスのインスタンスをユニークに識別する。その結果、アプリケーションがサービスを使用できる前に、アプリケーションは登録サーバとの合意をディジタル的にサインする。ディジタルシグネチャ署名はアプリケーションIDとサービストークンとを含んでいるデータとともに記憶される。ディジタル合意アグリーメントは、例えば、後に網オペレータによる課金を網サービスの使用について行うときの基礎として使用される。合意がサインされてしまうと、登録サーバはアプリケーションに対して要求された網サービスマネージャインターフェースを実施するオブジェクトについての参照基準レファレンスを戻す。Parlayインターフェースの上述した実施はさらにParlayAPI仕様書1.2に詳述されている。しかし、この発明の実施には各インターフェースに対して若干の修正が求められている。従来実施されているように、各単一のサービス合意でParlayインターフェースを用いて作られるものは、単一のゲートウェイを単一のクライアントアプリケーションにリンクするようにしている。この発明を実施する現在の網では、インターフェースは修正されて、複数のゲートウェイを複数のクライアントアプリケーションに、単一のサービス合意の下で、リンクするようにしている。このやり方でParlayサポートのエンドユーザサービスにとってゲートウェイかクライアントアプリケーションかの故障に対して弾力的で回復力のあるものとすることが可能である。各サービスマネージャでゲートウェイ内に置かれているものは初期事象の通知を送ることが可能とされていて、例えば、到来呼の通知を、配信アルゴリズムを用いて利用可能なクライアントアプリケーションに向けて送ることができて、このアルゴリズムは例えばラウンドロビンアルゴリズムである。同じように、クライアント側では、クライアントアプリケーションサポートレイヤは初期セッション要求をインボーク呼出すことができる。例えば、呼を発する要求は配信アルゴリズムを用いて多数の利用可能なゲートウェイの一つに向けてすることができる。こういった特徴に加えて、フレームワークFWは今ではポーリング機構を含んでいて、登録したサービスをサポートするゲートウェイの現在の状態を検出するのにあてる。故障したゲートウェイの検出は警報をトリガするために使用できる。クライアントアプリケーションに仕えているゲートウェイの各々についての利用可能性はクライアントフレームワークに向けて送られる。機能停止の後で回復されたゲートウェイが検出されるときには、フレームワークは新しいサービスマネージャのインスタンシエーションを求め、新しいサービスマネージャについてのレファレンス参照基準をクライアントFWに向けて送る。クライアントFWはポーリング機構を実現し、これがクライアントアプリケーションの現在の状態を検出する。故障したクライアントアプリケーションの検出は警報をトリガするのに使用されてよい。クライアントアプリケーションの各々についての利用可能性はフレームワークFWに向けて報告される。回復されたクライアントアプリケーションが機能停止の後で検出されるときには、クライアントFWは新しいクライアントアプリケーションに向けてサービスマネージャに対するレファレンスの全リストを通信する。ParlayAPIについての修正は図4に示した特殊インターフェースの各々との関係でここで記述することとする。これらのインターフェースの一つは、クライアントフレームワークとクライアントアプリケーションとの間でParlayAPI仕様書の一部を形成していないが、ここでは全体としてシステムの記述に対する支援として定義されている。FW-サービスインターフェースParlayサービス登録1.ParlayサービスはFWで登録される。Parlayサービスが複数のゲートウェイをまたいで支持されることができるためには、Parlayサービスの登録は、そのサービスを支持している個々のゲートウェイの登録からは異なっている。図5のメッセージシーケンスチャートに示すように、サービスノードは先ずFWでの登録を要求し、後にサービスを支持しているゲートウェイ全部の登録をインボークする実施する。別個の実施呼び出しインボケーションが各ゲートウェイに送られる。開始スタートアップ1.図6に示すように、FWは、Parlayサービスを支持しているすべてのゲートウェイ内でParlayサービスゲートウェイマネージャを作ることを要求する。新しいサービスゲートウェイマネージャについてのレファレンスはゲートウェイによって戻される。2.一度、バインドが完了すると、FWはグローバル事象通知情報をサービスゲートウェイマネージャに向けて送る。例えば、情報はアプリケーションが所有している番号範囲を含んでいてもよい。この情報はデータベース内に記憶される。ゲートウェイの故障と回復1.図7に示すように、FWはゲートウェイの故障を検出して、適当な警報を生じさせる。2.FWはゲートウェイの回復を検出して、サインされた各サービス合意について新しいParlayサービスゲートウェイマネージャのインスタンシエーションを求める。これはサービスの開始からの振舞いを再使用する。クライアントアプリケーションの故障1.図8に示すように、クライアントアプリケーションの故障についての通知があると、FWはこれを各ゲートウェイに報告する。2.各ゲートウェイは、有効なクライアントアプリケーションについてのゲートウェイのリストから古く、失効した、レファレンスを除去する。FW-クライアントFWインターフェース開始図61.クライアントFWは認証ハンドシェークをFWと実行する。2.クライアントFWはディスカバリィインターフェースを用いて、エンドユーザサービスを実行するのに必要な、Parlayサービスを見付ける。3.クライアントFWはParlayサービスを選び、回復目的で必要とされているゲートウェイの数nを特定する。またParlayサービスゲートウェイにバインドすることになるクライアントアプリケーションの最大数mを特定する。これはサービスレベル合意の一部として特定される。4.クライアントFWがサービス合意にサインをするときには、FWはサービスゲートウェイマネージャのリストに対するレファレンスをクライアントFWに向けて戻す。5.クライアントFWはFWを介してグローバル事象通知情報を送る。例えば、これはアプリケーション自体の番号範囲であり、この情報はデータベース内に記憶される。ゲートウェイの故障と回復図71.ゲートウェイの故障を検出すると、FWはこれをクライアントFWに報告する。2.ゲートウェイの回復を検出し、新しいサービスゲートウェイマネージャのインスタンシエーションを要求すると、FWはクライアントFWに対して報告を送り、サービスゲートウェイマネージャのレファレンスをパラメータとして送る。クライアントアプリケーションの故障と回復図81.クライアントアプリケーションの故障を検出すると、クライアントFWはこれをFWに報告する。クライアントアプリケーション-サービスインターフェースバインド図6と7開始後、あるいはクライアントアプリケーションの回復後に、サービスゲートウェイマネージャのレファレンスをクライアントアプリケーションに向けて送ること1.クライアントアプリケーションはサービスゲートウェイマネージャの各々に対して順々にバインドする。各サービスゲートウェイマネージャはmのクライアントアプリケーションを越えてそこへのバインドを許さない。2.サービスゲートウェイマネージャは適当な配信アルゴリズムを用いて事象をクライアントアプリケーションに分散させる。ゲートウェイの故障と回復図71.ゲートウェイの故障は次によりクライアントアプリケーションに向けて通知される。aクライアントFWが故障を報告するか、bクライアントアプリケーションが故障を直接検出するか実施の際か、プロトコル固有の故障のとき、既存のアプリケーションセッションを時間切れタイムアウトとするか例えばアプリケーション呼出しセッションのときによる。2.APIインボケーション実施のための呼出しであって既存のサービスセッションに関するものは他のゲートウェイには転送されない。3.新しいサービスセッションについてのAPIインボケーションが代りのゲートウェイに向けて転送される。これは適当な配信アルゴリズムを用いて行なわれて、残っているゲートウェイの間でインボケーションが分散される。4.ゲートウェイ回復では、クライアントFWは新しいサービスマネージャに対するレファレンスをクライアントアプリケーションに送り、このアプリケーションが新しいサービスマネージャにバインドする。クライアントアプリケーションの故障と回復図8を見よ1.クライアントアプリケーションの故障は次によりゲートウェイに通知される。aFWが故障を報告するbゲートウェイが故障を直接に検出する実施の場合か、プロトコル固有の故障のときか、既存のサービスセッション例えば、呼出しセッションをタイムアウトとする。2.既存のアプリケーションセッションについてのAPIインボケーションは他のクライアントアプリケーションに向けて転送されない。3.新しいアプリケーションセッションについてのインボケーション初期事象通知が代りのクライアントアプリケーションに向けて転送される。これは適当な配信アルゴリズムを用いて行なわれて、残っているクライアントアプリケーション間でインボケーションが分散される。4.回復されたクライアントアプリケーションは、サービスゲートウェイマネージャの各々とバインドする。クライアントFW-クライアントアプリケーションインターフェース開始図61.クライアントFWはサービスゲートウェイマネージャレファレンスのリストをクライアントアプリケーションのすべてに向けて送る。ゲートウェイの故障と回復図71.ゲートウェイの故障についてFWから報告を受取ると、クライアントFWはこの情報をクライアントアプリケーションに向けて送る。2.各クライアントアプリケーションは有効なゲートウェイのリストから古い、失効した基準レファレンスを除去する。3.ゲートウェイの回復があると、クライアントFWは新しいサービスゲートウェイマネージャのレファレンスをクライアントアプリケーションのすべてに向けて送ってバインドさせる。クライアントアプリケーションの故障と回復図81.クライアントFWは故障を検出し、適当な警報を生じさせて、故障をFWに向けて報告する。2.クライアントFWはクライアントアプリケーションの回復を検出する。3.クライアントFWはサービスゲートウェイマネージャレファレンスのリストを回復したクライアントアプリケーションに向けて送って、バインドさせる。"