JP2008505405A - 分散型通信プラットフォームにおけるロードバランシング - Google Patents

Abstract

処理は、分散型通信内で、２つのレベル、すなわち、コンポーネントレベル及びプロセスレベルに割り振られる。該コンポーネントレベルにおいては、サービス要求を、該サービス要求を処理するように構成されているコンポーネントからなる群のうちの１つへルーティングするのに、仮想スイッチが用いられる。その決定は、該仮想スイッチにより自立的に、または、全体的に、該コンポーネントにより提供される情報に基づいて、あるいは、両者の組合せによって、行うことができる。該プロセスレベルにおいては、各コンポーネント資産は、該供給サービスの複数のインスタンスを探り、１つのインスタンスを選択して、該サービス要求を処理する。該コンポーネントは、該プロセスのインスタンスの処理負荷を監視し、パフォーマンスの低下が予想される場合には、該コンポーネントは、該供給サービスの代替のインスタンスを選択して、後の要求に対処する。
【選択図】図１

Description

関連出願の相互参照
［０００１］
この出願は、２００５年３月１５日に出願された「通信システムのための分散型ＩＰアーキテクチャ（“ＤＩＳＴＲＩＢＵＴＥＤ ＩＰ ＡＲＣＨＩＴＥＣＴＵＲＥ ＦＯＲ ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＳＹＳＴＥＭ”）」というタイトルの米国特許出願第１１／０８０，７４４号の一部継続出願である。

発明の背景
［０００２］
本発明は、分散型ＩＰシステム及び通信システムに関し、および、より具体的には、分散型ＩＰアーキテクチャを通じて情報をやりとりする、地理的に分散可能なコンポーネントを伴う多機能通信システムに関する。

［０００３］
この数十年の間に、音声メールは、規模を拡大し続け、ほとんどのビジネスの成功する経営における重要な要素として定着した。典型的な音声メールシステムは、今日、ビジネス電話システムに接続されているパーソナルコンピュータ内で作動することができるコンピュータカード、または、該ビジネス電話システムに直接的に一体化されているコンピュータカードまたはコンポーネント、あるいは、通信会社により提供されるサービスを含む様々な形態をとることができる。

［０００４］
今日、利用可能な音声メールシステムの各々のための共通の要素は、該音声メールシステムを構成するコンポーネントが、互いに通信しなければならず、そのため、同一場所に配設しなければならないということである。これは、地理的に分散した営業所を有する会社にとってはかなり不都合となりうる。

［０００５］
今日の世界経済においては、小さなビジネスでさえも、顧客に応えるために、ベンダーと関係を持つために、または、様々な他の理由のために複数のオフィスに対する必要性を有する可能性がある。インターネット、電子メール及びビデオ会議の出現は、そのような分散した経営がシームレスになる可能性を助ける。しかし、分散したオフィスになお存在する重大な問題は、単一の、同一場所に配設されたシステムとして機能するが、様々なオフィスの要求に応える共通の電話システムを有することである。一般に、それぞれのオフィスは、各オフィスの電話システム間の何らかの直接的インタフェースを伴わない、および何らかの中央制御を伴わない、それぞれの電話システムを購入して、維持する。このことは、重複する可能性のあるハードウェアを購入して、それぞれの場所において維持しなければならないという点で、コストのかかる努力になる可能性がある。加えて、着信転送、音声メール検索等のオフィス間通信のロジスティクスが複雑になる可能性がある。従って、当技術分野においては、遠く離れて配置されたオフィスのためのシームレス・インテグレーションを可能にする通信システムに対する要求がある。

［０００６］
ほとんどの分散型システムにおいては、発生し、また、対処しなければならない共通の問題は、様々なコンポーネント間の処理の分散である。分散型システムにおいては、該コンポーネントからなるサブセットは、処理タスクによって過度の負担がかかる可能性があり、一方、他のコンポーネントは、アイドル状態にあるか、または、使用中である。そのような状態は、該システムの効率及びスループットの著しくかつ不必要な低下をもたらす可能性がある。例えば、負荷を、過負荷のコンポーネントから使用中のコンポーネントに分散させることができる場合、該システムは、処理要件をより効率的に処理することができる。該処理要件を分散型システムにおいてバランスさせる目的で、既に提案され、かつ実施されている多くのそのような方法がある。しかし、そのような方法は、本願明細書に記載した分散型通信プラットフォームにおける要求を満たすのに適していない。例えば、１つ以上のコンポーネントが、例えば、動的音声ＸＭＬページを生成する際に、Ｊ２ＥＥ（ＪＡＶＡ(登録商標)２ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ）環境及びＪＳＰ（ＪＡＶＡ(登録商標) Ｓｅｒｖｅｒ Ｐａｇｅｓ）を利用する場合、さらなる問題が生じる可能性がある。そのようなコンポーネントにおいて、ＪＡＶＡ(登録商標)エンジンは、メモリを割当て、またメモリの割当てを解除すると共に、いわゆるガベージコレクションを実行する。このことは、もはや参照されない、動的に割当てられたメモリを解放することについて処理する、ＪＡＶＡ(登録商標)の重要な特徴である。ヒープは、ガベージコレクト（ｇａｒｂａｇｅ−ｃｏｌｌｅｃｔｅｄ）されるため、ＪＡＶＡ(登録商標)のプログラマは、割当てメモリを積極的に解放する必要はない。しかし、ガベージコレクションプロセスを開始する場合、該システムのパフォーマンスに直接影響を及ぼす多大な処理時間を要する可能性がある。従って、当技術分野においては、ＪＡＶＡ(登録商標)ガベージコレクションプロセス及び他の処理要件の影響を回避するか、または軽減する方法で、リソースの再割当てを可能にする分散型システムに対する要求がある。

発明の概要
［０００７］
この発明は、分散型通信システム内で、処理負荷をバランスさせる方法を提供する。一般に、処理は、２つのレベル、すなわち、コンポーネントレベルとプロセスレベルとに分散される。コンポーネントレベルにおいては、サービス要求を処理するように構成されているコンポーネントからなる群のうちの１つに該サービス要求をルーティングするために、仮想スイッチが用いられる。決定は、該仮想スイッチにより、または、全体的に、該コンポーネントにより与えられる情報に基づいて、あるいは、これら両方の組合せにより、自立的に行うことができる。プロセスレベルにおいては、各コンポーネントは、供給するプロセスの多数のインスタンスを確立し、その後、該サービス要求を処理するために、１つのインスタンスを選択する。該コンポーネントが、該プロセスの該インスタンスの処理負荷を監視し、パフォーマンスの低下が予想される場合には、該コンポーネントは、該供給プロセスの代替のインスタンスを選択して、後の要求に対処する。

［０００８］
本発明の例示的な実施形態において、上記仮想スイッチは、通信サービス要求を処理するアプリケーションサーバの群から選択するのに用いられる。該アプリケーションサーバは、ガベージコレクションプロセスを含むＪ２ＥＥプラットフォームを用いる。該供給プロセスの単一のインスタンスを用いる場合、最終的には、該ガベージコレクションプロセスは、高い実行優先度を要することになり、そのような場合に、該通信システムのユーザは、パフォーマンスの低下を被るであろう。複数のインスタンスは、該ガベージコレクションプロセスを、該ユーザが経験するパフォーマンスに影響を及ぼすことなく、オフラインを機能できるようにする。

発明の詳細な説明
［００１２］
図１は、本発明の様々な態様及び特徴を用いることができる例示的な次世代通信プラットフォームの構成要素及び接続性を示すシステム図である。図示のシステムは、特に、音声メール、自動転送及び他の通信機能等の通信サービスを提供することができる分散型ＩＰベースのアーキテクチャを含む。図示した実施形態において、次世代通信プラットフォーム１００は、分散型ＩＰアーキテクチャを有し、公衆交換電話網（ＰＳＴＮ）１１０に接続されている。通信プラットフォーム１００は、シグナリングゲートウェイ機能（ＳＧＦ）１２０と、１つ以上のメディアサーバ（ＭＳ）１３０と、１つ以上のシステム管理ユニット（ＳＭＵ）１４０と、１つ以上のアプリケーションサーバ（ＡＳ）１５０と、１つ以上の中央データ及びメッセージストア（ＣＤＭＳ）１６０とを含むように示されている。図面に示されかつ記述され、それ自体の中に新規な態様を有する機能の分散が、唯一の容認可能な構成ではなく、また、本発明の態様を、より少ないまたはより多いコンポーネントと、該コンポーネント間の機能の異なる構成とを含むシステムに組み込むことができることを理解すべきである。

［００１３］
一般に、ＳＧＦ１２０は、ＰＳＴＮ１１０とのＳＳ７インタフェースとして機能し、また、１つ以上のコンポーネントまたはサブシステムが、同じポイントコードを共有し（それにより、宛先ポイントコード（ＤＰＣ）の必要性を低減し）、および呼制御のための信号リンクを共有することを可能にする。このことは、該電話システムを、該ネットワーク内の単一のトランク群として見せる。メディアサーバ１３０は、マルチインタフェースデザインを介して、ＰＳＴＮからのＩＰおよび／または回線交換トラフィックを終了させ、また、トランキング（ｔｒａｎｋｉｎｇ）及び呼制御に関与する。アプリケーションサーバモジュール１５０は、様々なアプリケーションのためのダイナミック音声ＸＭＬページを生成し、該ページをメディアサーバ１３０を介して与え、ウェブ・アプリケーションサーバ・コンフィギュレーションを介して外部インタフェースを提供する。ＳＭＵ１４０は、サービスプロバイダが加入者アカウントを提供して維持し、集中型ウェブインタフェースからのネットワーク要素を管理することを可能にする管理ポータルである。ＣＤＭＳ１６０は、音声メッセージ、加入者レコードを格納し、通知を含む特定のアプリケーション機能を管理する。以下に、これらの各サブシステムをより詳細に説明する。

［００１４］
上記次世代通信プラットフォーム内のコンポーネントの各々は、単独で拡張可能であり、また、ＩＰネットワーク上に個別に相互接続される。従って、該コンポーネントは、地理的に分散させることができるが、それでもなお、該ＩＰネットワークを通じて互いに通信することができる限り、単一の通信プラットフォームとして機能することができる。このことは、最先端の通信システムでは利用できない、本発明の重要な利点である。

シグナリングゲートウェイ機能（ＳＧＦ）
［００１５］
ＳＧＦ１２０は、次世代通信プラットフォームのための単一の仮想ＳＳ７信号ポイントを生成する統合信号インタフェースを提供する。ＳＳ７は、大きいか小さいかにかかわらず、ネットワークが必要とする余分な馬力を提供する。多機能メディアサーバ１３０とのＳＩＧＴＲＡＮインタフェース（ＩＰを介したＩＥＴＦ ＳＳ７回線制御）ならびにＩＰプロキシ機能は、ＳＧＦ１２０を介してサポートされる。該次世代通信プラットフォームの単一のコンポーネント（この場合、ＳＧＦ１２０）にＳＳ７を統合することは、低減されたポイントコード、他のコンポーネントのデザインにおける費用効果、および容易なメンテナンスという利点を与える。

［００１６］
ＳＳ７ネットワークにおける各信号ポイントは、数字のポイントコードによって固有に識別される。ポイントコードは、各メッセージのソース及び宛先を識別するために、信号ポイント間で交換されたメッセージをシグナリングする際に伝えられる。各信号ポイントは、ルーティングテーブルを用いて、各メッセージのための適切な信号経路を選択する。

［００１７］
ＳＳ７ネットワークには、３種類の信号ポイント、すなわち、ＳＳＰ（サービス交換ポイント）、ＳＴＰ（サービス転送ポイント）及びＳＣＰ（サービス制御ポイント）がある。ＳＳＰは、呼を発し、終了させ、または連結する。ＳＳＰは、呼を完了させるのに必要な音声回線を設定し、管理しおよび開放するために、信号メッセージを他のＳＳＰに送信する。また、ＳＳＰは、呼（例えば、北米における、フリーダイヤル１−８００／８８８の呼）をどのようにルーティングするかを決めるために、問合せメッセージを集中型データベース（ＳＣＰ）へ送信することもできる。ＳＣＰは、かけた番号に関連するルーティング番号を含む応答を、発信元ＳＳＰに送信する。最初の番号がビジーの場合、または、その呼が特定の時間内に返答がない場合には、代替のルーティング番号を該ＳＳＰが用いることができる。実際の呼の機能は、ネットワークごとに、およびサービスごとに変わる。

［００１８］
信号ポイント間のネットワークトラフィックは、サービス転送ポイント（ＳＴＰ）と呼ばれるパケットスイッチを介してルーティングすることができる。ＳＴＰは、ＳＳ７メッセージに含まれるルーティング情報に基づいて、それぞれの入ってくるメッセージを発信信号リンクへルーティングする。該ＳＴＰは、ネットワークハブとして機能するため、該ＳＴＰは、信号ポイント間の直接リンクの必要性をなくすことにより、ＳＳ７ネットワークの改良された利用を実現できる。ＳＴＰは、グローバル名称翻訳、宛先信号ポイントがそれによって、信号メッセージ内に存在する数字(例えば、ダイヤルされたフリーダイヤル番号、コーリングカード番号、または、携帯電話加入者識別番号)から決まる処理手順を実行することができる。

［００１９］
また、ＳＴＰは、他のネットワークと交換されたＳＳ７メッセージを選別する「ファイアウォール」としても機能することができる。ＳＳ７ネットワークは、呼の処理に不可欠であるため、ＳＣＰ及びＳＴＰは、孤立した障害の場合に、ネットワーク全体のサービスを保証するために、通常、別々の物理的位置に、適合したペア構成で配置される。また、信号ポイント間のリンクもペアで設けられる。トラフィックは、そのリンクセット内の全てのリンクで共有される。該リンクのうちの１つが故障すると、該信号トラフィックは、該リンクセット内の別のリンクを通じて再ルーティングされる。ＳＳ７プロトコルは、誤り訂正能力及び再送信能力の両方を提供して、信号ポイントまたはリンクの故障時に、継続したサービスを可能にする。

［００２０］
ポイントコードの使用性は、典型的に限定される。信号リンクの統合は、それらのリソースに対する圧力を軽減し、または、追加的なポイントコードの必要性を全くなくす。従って、ＳＧＦ１２０内の統合信号インタフェースは、迅速なネットワークの簡素化及びコストの節約をもたらす。ＳＧＦ１２０は、メッセージングネットワークの単一の「仮想」ポイントコードを介したＳＳ７ネットワークへの単一の一致の出現を提示し、透過的な方法でメッセージを認識して処理する。ＳＧＦ１２０は、必要なポイントコードの最大数を、場合によっては、５０からたったの４まで潜在的に低減することができる。

［００２１］
ネットワーキングの観点から見ると、ＳＧＦ１２０は、仮想ポイントコードの利用によって、上記次世代通信プラットフォームの様々なコンポーネントにアクセスする、該ネットワークの残りの部分に対するＳＴＰのように見える。本発明の分散型態様によれば、複数のＳＧＦを該システムに組込むことができる。この構成においては、該次世代通信プラットフォームの様々なコンポーネントへの複数の経路が利用可能である。

［００２２］
各ＳＧＦ１２０は、上記通信プラットフォーム内の様々なコンポーネントにアクセスするのに用いられる仮想ポイントコードを含む。通信プラットフォーム全体には、単一の宛先ポイントコードが必要である。該ＳＧＦは、互いに通信して、上記メディアサーバ、及び該通信プラットフォームに一体化された他のコンポーネントのために該仮想ポイントコードを同期させる。従って、１つのＳＧＦが故障した場合、該通信プラットフォームへのアクセスは、別のＳＧＦによって実行できる。

［００２３］
このことは、同期されたＳＳ７スタックのように見える上記次世代通信プラットフォーム内のコンポーネントの各々に関して、著しい違いであり、かつ利点である。

［００２４］
例示的な実施形態において、ＳＧＦ１２０サーバは、冗長構成及び負荷分散構成によって、Ｎ＋１の故障をサポートし、また、インターネット上に構築される。増加した使用性の場合、負荷分散及び冗長のためには、最低２つのＳＧＦが推奨される。全てのプラットフォーム・コンポーネントに対して同様に、ＳＮＭＰアラーム、ロギング及び取引情報記録が生成される。該ＳＧＦの特徴、効果及び利点は、
［００２５］
複数のメディアサーバが、信号リンク及びポイントコードを共有できるようにして、著しいコストの節約を実現できること、
［００２６］
集中型ＳＳ７信号リンクを実現できること、
［００２７］
複数の多機能メディアサーバにわたる１つのトランク群を実現できること、
［００２８］
ＳＧＦ１２０が、より少ないＳＳ７リンクを要し、その結果として、低減された月間の接続料金をもたらすこと、および
［００２９］
ＳＧＦ１２０が、上記通信プラットフォームのためのＩＰ分散型アーキテクチャを実施する能力において、重要な構成要素であることを含む。

メディアサーバ（ＭＳ）
［００３０］
ＭＳ１３０は、ＳＧＦ１２０からのＩＰトラフィック及びＰＳＴＮ１１０からの回線交換トラフィックを終了させる。ＭＳ１３０は、上記プラットフォームアーキテクチャ内での呼の設定及び制御に関与する。ＭＳ１３０は、ユーザからの入力を、音声、ＤＴＭＦフォーマットまたは他の信号方式で処理する（例えば、ウェブクライアントは、ユーザからのキーボード及びマウスクリック入力を収集する）。そして、ＭＳ１３０は、（ＰＣクライアント上の該ユーザへ戻して表示されるグラフィック及びテキストと原理的に同様に）その内容を該ユーザへ音声で戻して提示する。このクライアント／サーバの方法論は、新たなアプリケーションの迅速な形成、およびワールド・ワイド・ウェブ上で使用可能なコンテンツの即時利用を可能にするという点で、該プラットフォームアーキテクチャにおいて重要である。

［００３１］
ＭＳ１３０は、好ましくはＨＴＴＰを用いて、ＡＳ１５０への要求によって、着呼処理をする。ロードバランサは、好ましくは、多機能ＭＳ１３０に到達するトラフィックを、複数のＡＳ１５０のうちの１つへ向ける。この機能は、トラフィックが、アクティブなサーバ間に一様に配分されることを実現する。多機能ＭＳ１３０は、Ｎｅｔｓｃａｐｅのようなクライアントが、ＰＣ上のＨＴＭＬユーザの代わりに機能するのと同様に、エンドユーザに代わって、音声ＸＭＬクライアントとして機能する。多機能メディアサーバに備わっている音声ＸＭＬまたは呼制御ＸＭＬ（ＣＣＸＭＬ）ブラウザは、ユーザへの提示のために、音声ＸＭＬドキュメントを解釈実行する。

［００３２］
音声ＸＭＬは、音声使用可能なソフトウェアアプリケーションを開発するための規格ベースのスクリプト言語である。このことは、開発者が、音声ベースの電話のアプリケーションを開発する際に、ウェブベースの（ＨＴＭＬ）開発技術を用いて活用することを意味する。

アプリケーションサーバ（ＡＳ）
［００３３］
上記次世代通信プラットフォームのモジュラー式デザインは、音声ダイヤル及び音声ナビゲーション、統合された通信ソリューション、マルチメディアメッセージングサービス、およびプレゼンス及び使用性の管理アプリケーション等の高度なサービスを展開することが容易であるという追加的な利点を有する。該プラットフォームにアプリケーションを追加することは、該共通プラットフォームへの標準アプリケーションサーバ１５０の追加によって遂行される。

［００３４］
各アプリケーションサーバ１５０は、内部イーサネット(登録商標)網を介したメディアサーバ１３０からの要求に応えて、アプリケーションドキュメント（音声ＸＭＬページ）を生成する。アプリケーションサーバ１５０は、ウェブアプリケーションインフラストラクチャを利用して、バックエンドデータストア（メッセージストア、ユーザプロファイルデータベース、コンテンツサーバ）とインタフェースをとり、音声ＸＭＬベースのドキュメントを生成する。

［００３５］
ウェブアプリケーションインフラストラクチャ全体は、より拡張可能なアプリケーションアーキテクチャを形成するために、コアサービス論理（すなわち、ビジネスロジックを実行すること）と提示詳細（音声ＸＭＬ、ＣＣＸＭＬ、ＳＡＬＴ、ＸＨＴＭＬ、ＷＭＬ）とを区別する。アプリケーションサーバ１５０は、Ｊａｖａ(登録商標)２ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ（Ｊ２ＥＥ）環境及びＪＳＰ（Ｊａｖａ(登録商標) Ｓｅｒｖｅｒ Ｐａｇｅｓ）を用いて、該多機能メディアサーバのためのダイナミック音声ＸＭＬページを生成する。これらの技術を組合わせることは、ＷＡＰ、ＨＴＭＬ、ＸＨＴＭＬ及び音声等のアプリケーション間の相互運用性（マルチモーダル）を実行できるＳＡＬＴ（Ｓｐｅｅｃｈ Ａｐｐｌｉｃａｔｉｏｎ Ｌａｎｇｕａｇｅ Ｔａｇｓ）の素早い組込みを可能にし、エンドユーザが、音声コマンドによってデータを同時に入力し、ＷＡＰまたはＨＴＭＬによってプレゼンテーションを受取ることを可能にする。

［００３６］
簡単なアプリケーション展開のための環境を形成するために、アプリケーションサーバ１５０は、好ましくは、Ｔｅｍｐｌａｔｅ＋ＪＳＰをサポートする。アプリケーションは、メッセージング機能へのアクセスのためのＡＰＩを用いてＪＳＰに実装される。それらのＪＳＰは、容易に修正可能であり、アプリケーションの動作の変更、および新たなアプリケーションの生成を非常に簡単にする。

［００３７］
メディアサーバ１３０とアプリケーションサーバ１５０の連携は、特定の機能のカストマイズを、特定の加入者に提供できるようにする。例えば、ある会社が、西海岸に１つのオフィスを所有し、東海岸に別のオフィスを所有している場合、電話システム、特に、各オフィスの場合のメディアサーバ１３０及びアプリケーションサーバ１５０の動作は、全く異なる可能性がある。例えば、音声メールシステム及び自動案内は、東海岸のオフィスでは東部時間午後６時に、また、西海岸のオフィスでは西部時間午後６時に、夜間モードになる。加えて、様々なオフィスによって形成されるメニュー構造及びプロンプトは、かなり異なる可能性がある。例えば、氏名録によるダイヤルは、異なる従業員を含むであろう。本発明の場合、独立したメディアサーバは、それらの２つのオフィスに配置することができ、また、メディアサーバ１３０は、異なる通信サービスを提供することができる。該異なる通信サービスは、メディアサーバ１３０と同一場所に配置された、異なるアプリケーションサーバ１５０から、または、メディアサーバ１３０の位置またはＩＤに基づいて、通信サービスアプリケーションを提供することができる共通アプリケーションサーバを介して提供することができる。

［００３８］
また、遠く離れて配置されたメディアサーバ１３０は、様々な加入者及び発呼者に対して共通の機能を実行することができ、また、加入者及びユーザの両者の視点から、該電話システムのシームレスインテグレーションを実行できる。会社は、該会社の全てのオフィスにシームレスでサービスを提供する音声メール及び自動案内インタフェースを提供したい可能性がある。本発明は、そのような機能性を実現するのに用いることができる。アプリケーションサーバ１５０は、まず、発呼者があるオフィスを選択できるように、次に、アプリケーションサーバ１５０および／またはメディアサーバ１３０が、特定の機能を呼び出して、当該オフィスのためのネームサービスによるダイヤルを実行できるネームまたはメニュー選択機能による段階的ダイヤルを提供することができる。別法として、アプリケーションサーバ１５０は、該会社の全てのオフィスの全ての加入者情報を含む、単一のＣＤＭＳ１６０または複数のＣＤＭＳ１６０へのアクセスを維持してもよい。その結果、アプリケーションサーバ１５０は、氏名録による全社的なダイヤルのための単一レベルのメニュー構造を形成することができる。

共通データベース及びメッセージストア（ＣＤＭＳ）
［００３９］
上記次世代通信プラットフォームは、ＣＤＭＳ１６０を用いて、音声／オーディオメッセージ、加入者記録を蓄積し、通知スケジュール等の特定のアプリケーション機能を管理する。ＣＤＭＳ１６０は、好ましくは、冗長なコンポーネントでデザインされ、リフレクティブメモリ、および耐故障性、フェイルオーバー及びリカバリのためのＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｉｓｋｓ）技術を利用する。これは、厳しい環境においてもシステムが利用可能であるという高いレベルの確実性を保証する。必要不可欠なディスクドライブ及びＲＡＩＤコントローラコンポーネントは、好ましくは、ホットスワップ可能であり、交換時に該システムを電源オフにする必要性をなくす。ＣＤＭＳ１６０の場合、パフォーマンスは、音声メッセージングの固有の特性に対して最適化され、パフォーマンスの劣化、すなわち、電子メールストアの検索及び分類を備える不必要な電子メール中心のデータベース機能をなくす。

［００４０］
ＣＤＭＳ１６０は、シェルフ電子メール保存システムの規格を利用することができる。該メッセージストアは、該メッセージストアの選択を、アプリケーションに対して透過的にするＪａｖａ(登録商標)ミドルウェアの使用によって抽象化され、各メッセージが、最も効率的なストアに格納できるようにする。

システム管理ユニット（ＳＭＵ）
［００４１］
ＳＭＵ１４０は、全てのネットワーク要素を管理する、サービスプロバイダのための集中型ポイントを形成し、リモートアクセス、メンテナンス及びバックアップ機能を実行できる。ＳＭＵ１４０は、プロビジョニング、アラーム、リポート及び加入者移行のための単一のインタフェースを形成する。ＳＭＵ１４０は、システムと新たな構成要素及びアプリケーションとを統合して、カスタマイズし、急速に成長するネットワーク及び急増するトラフィック量に曝されているキャリアのために、運用支援及びネットワーク管理機能を実行できる。該ＳＭＵコンポーネントのコア機能は、以下の機能を含む。

［００４２］
構成要素自動リカバリ：サービスプロバイダが新たなネットワーク要素を追加した場合、上記ＳＭＵは、該要素を自動的に認識し、該新たな要素を、グラフィカルネットワークマップ内に含める。

［００４３］
グラフィカルネットワークマップ：ネットワーク／クラスタマップ及びマップエディタは、ネットワークまたはクラスタ全体のスナップショットを実行でき、また、迅速な問題識別及び解決を容易にする。

［００４４］
時刻同期：中央時刻ソースは、全てのネットワーク要素が、メッセージングネットワーク全域にわたって、均一な時間基準を維持することを実現し、このことは、どんな分散型アーキテクチャにとっても重要である。

［００４５］
集中型ネットワークロギング：メッセージングネットワーク全体のロギングは、ＳＭＵ１４０に集中管理される。

［００４６］
ＳＭＵ１４０は、デュアルプロセッサコンピュータを用い、ＳＭＵ１４０サーバへの、ならびに、テルネットを介した上記システム内の全ての他のサーバへのアクセスのためのリモートダイヤルインを可能にする。システムコンフィギュレーション及び他の重要なデータのバックアップも、該ＳＭＵによって遂行することができる。

［００４７］
有利には、上述した次世代通信プラットフォームは、単一のアーキテクチャソースからの全ての様々なアプリケーションの迅速かつ費用効果的な展開を可能にする。オープンソースの利用、すなわち、Ｊａｖａ(登録商標)ベースのアプリケーション形成環境は、この高度なフレキシビリティを可能にする。該通信プラットフォーム用いて、オペレータは、基本的な呼応答から、マルチメディアメッセージング及びプレゼンス使用可能ソリューションのような先進的なアプリケーションに及ぶクラス最高のメッセージング及び通信サービスの強力な塊を創り出すことができる。ユーザの経験をさらに容易にするために、該次世代通信プラットフォームは、「セルフサービス」を基盤とする優先度及び機能を追加しおよび修正する、加入者用ウェブインタフェースを備えてもよい。この性能は、消費者による使用を増加させ、カスタマーロイヤルティを向上させ、また、より少ない日常的な修理依頼によって、サービスプロバイダの運用コストも低減される。

［００４８］
上記通信プラットフォームの別の利点は、様々なアプリケーションを含みかつ組込む能力である。該アプリケーションが、元々、該プラットフォーム用に作られたか、あるいは、サードパーティベンダーから供給されたものであるかにかかわらず、該アプリケーションは、該通信プラットフォームを、様々なカスタマー要求及び製品差別化に対してカスタマイズできるようになっている。該通信プラットフォームに容易に組込むことができる該アプリケーションのうちの一部は、以下のものを含む。

［００４９］
音声メール：加入者に、音声メッセージの録音及び記憶、転送、リモート検索等を含む音声メッセージ内容の交換を中心としてデザインされた様々な機能を与える。

［００５０］
不在着信通知：これは、発信者番号通知サービスの内線であり、無線電話または携帯電話の領域で頻繁に利用される。発信者番号通知サービスは、該無線電話が作動中であり、かつ該ネットワークのサービスエリア内にある場合に、着信呼出し番号を単に表示する。しかし、不在着信通知は、ユーザが該携帯電話から離れている間、または、該携帯電話がオフになっている間、該携帯電話の番号に対して行われた呼のリストを加入者に与える、継続的なネットワークベースのサービスを提供する。従って、不在着信通知サービスは、該携帯電話が作動して記録するまで、着呼情報を捕捉して蓄積することになる。そのとき、全ての不在着信のリストを含むＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）メッセージが加入者へ送られ、該加入者の都合の良い時に、折り返し電話をすることができるようにする。

［００５１］
マルチメディアメッセージングサービス：ＭＭＳは、写真や音楽等の最新のマルチメディアコンテンツとの通信を独自のものにし、従来の通信の限界を破るメッセージングを生成できるようにする。このアプリケーションは、“Ｍｅｓｓａｇｅ Ｃｏｍｐｏｓｅｒ”、“Ｐｈｏｔｏ Ａｌｂｕｍ”及び“Ｇｒｅｅｔｉｎｇ Ｃａｒｄｓ”のような機能を用いることにより能力が高められ、加入者が、ＭＭＳが可能な携帯電話、ＰＤＡ及びＰＣ上で、動的なマルチメディアコンテンツを送受信することができるようにする。また、加入者は、インターネットを介して、非ＭＭＳ加入者へマルチメディアコンテンツを送信することもでき、オペレータのウェブサイトへのトラフィックを駆動し、それによって、加入者の使用性を向上させる。

［００５２］
統合された通信：音声、ファックス及び電子メールメッセージング、全てのメッセージタイプのための単一のメールボックス、総合住所録、および特別なオンラインマネジメント及びパーソナライズツールを含む、加入者の要求に対してカスタマイズされたサービスの完璧なパッケージ。

［００５３］
マルチパーティー・パーソナル・コンファレンスサービス：このアプリケーションは、友人／家族との即時の会議を始める能力を加入者に与える。

［００５４］
音声が使用可能なメッセージングサービス：このアプリケーションは、有力な音声が制御する電話サービス。加入者は、自身の個人的コンタクト番号、および自然な言語認識及び任意のテキスト／音声変換能力を特徴とする使い勝手のよい音声インタフェースを介して一連のサービスを利用することができる。音声が使用可能なメッセージングのパッケージソフトに共通する特徴は、音声ＸＭＬ及びＳＡＬＴ等の業界標準に準拠したＩＰベースのアーキテクチャ上に供給された、音声指示を介した音声メールのナビゲーション、音声ダイヤル及び音声が制御する住所録を含む。

［００５５］
音声ＭＭＳ：このアプリケーションは、新たに投函された音声メールメッセージを、オーディオクリップの形で、ＭＭＳが可能なハンドセットまたはＥメールボックスに配信できるようにすることにより、加入者の通信チャネルを通じて、加入者が大量にアクセスし、かつ制御することを可能にする。また、加入者は、電子メールによって音声メッセージを共有することができ、また、音声メッセージを、該音声メールシステムの外部の宛先に転送することができる。

［００５６］
本発明の別の態様は、制御及びデータの配信のためのトランザクション媒体である。上述したような同じＳＧＦ１２０コンポーネントを用いると、ＳＳ７プロトコルのＴＣＡＰコンポーネントを中心とするトランザクション媒体を実現できる。より具体的には、ＳＳ７プロトコルのＴＣＡＰコンポーネントを用いて、ショート・メッセージング・サービスを上記次世代通信プラットフォームの分散型アーキテクチャ内に設けることができる。ショート・メッセージの送信者は、上記ＩＰネットワークを通じて、メディアサーバ１３０との通信を確立する。該送信者は、メディアサーバ１３０に、ＳＧＦ１２０に該ショート・メッセージの配信のためのＳＳ７ ＴＣＡＰメッセージを送信するように要求させる。この技術は、トランザクション処理への呼処理のためのＳＧＦ用ＳＴＰインタフェースのための、上述したような単一のポイント・アクセス・ノードをもたらす。

［００５７］
従って、上記例示的な通信プラットフォームのための分散型アーキテクチャは、地理的に分散されても、シームレスに統合されたシステムとして機能する通信プラットフォームの様々な機能を可能にする。このような分散型システムにおいて生じる問題は、該システム内でのリソースの共有である。複数のコンポーネントが、サービス要求によって、他のコンポーネントを過負荷にする多くの状況が生じる可能性がある。また、特定のコンポーネントが、あるときに、処理要求に対してより弾力的であり、他のときに、より弾力的でない可能性がある。そのような状況の実例は、１つ以上のコンポーネントが、Ｊ２ＥＥ環境を含み、未利用のメモリを取り戻すガベージコレクションの使用を用いる場合に生じる。

ＪＡＶＡ(登録商標)ガベージコレクション
［００５８］
既に述べたように、アプリケーションサーバ１５０は、Ｊ２ＥＥ環境及びＪＳＰを利用して、多機能メディアサーバのための動的音声ＸＭＬページを生成する。Ｊａｖａ(登録商標)の重要な機能は、そのガベージコレクトされたヒープであり、これは、もはや参照されない動的に割当てられたメモリを解放することを管理する。該ヒープは、ガベージコレクトされるため、Ｊａｖａ(登録商標)のプログラマは、割当てメモリを積極的に解放する必要はない。一般に、該ガベージコレクションプロセスが始まると、アプリケーションサーバ１５０は、他の何らかのプロセスによる使用に対して利用不可になり、あるいは、少なくともその使用性は低下する。アプリケーションサーバ１５０が、音声メールまたは電話システム等の待ち時間に敏感な環境で用いられる場合、アプリケーションサーバ１５０のガベージコレクションプロセスへの入口は、待ち時間問題を課す可能性がある。すなわち、発呼において、その関係者は、該ガベージコレクションプロセスの間、沈黙に耳を傾けることになるであろう。

［００５９］
より具体的には、Ｊ２ＥＥサーバ／ウェブコンテナは、クライアントからの要求をサポートするサーバアプリケーションをサポートするのに用いられるソフトウェアコンポーネントである。いくつかのＪ２ＥＥサーバ／ウェブコンテナアプリケーションは、主要なガベージコレクション等のＪａｖａ(登録商標)仮想マシン（ＪＶＭ）のガベージコレクションアクティビティにより課されるパフォーマンスオーバヘッドを招くことに対して余裕がないサービス要件を有する。それらのアプリケーションの場合、ガベージコレクションアクティビティに影響を及ぼすサービスが発生するまで、パフォーマンスは許容範囲内にある。

［００６０］
ＪＶＭのヒープは、実行中のＪａｖａ(登録商標)プログラムによって生成された全てのオブジェクトを蓄積する。オブジェクトは、Ｊａｖａ(登録商標)プロセスによって生成され、新たなオブジェクトのためのメモリは、ランタイム時に該ヒープ上に割当てられる。ガベージコレクションは、該プログラムによって、もはや参照されないオブジェクトを自動的に解放するプロセスである。「ガベージコレクション」という用語は、該プログラムによって、もはや必要とされないオブジェクトが「不要なデータ」であり、捨てることができることを意味する。オブジェクトが、プログラムによって、もはや参照されない場合、該オブジェクトが専有するヒープスペースは、後の新たなオブジェクトのために利用できるように、再利用しなければならない。ガベージコレクタは、何とかして、どのオブジェクトが、該プログラムによって、もはや参照されないかを判断して、そのような参照されないオブジェクトによって専有されたヒープスペースを使用可能にしなければならない。

［００６１］
参照されないオブジェクトを解放することに加えて、ガベージコレクタは、ヒープの断片化に対抗することもできる。ヒープの断片化は、通常プログラムの実行の過程の間に発生する。新たなオブジェクトが割当てられ、参照されないオブジェクトが解放され、その結果、ヒープメモリのフリーブロックが、生オブジェクトにより専有されたブロック間に残される。新たなオブジェクトを割当てる要求は、現存するヒープの総未利用スペースが十分にあっても、該ヒープのサイズを拡大することによって満たさなければならない可能性がある。このことは、新たなオブジェクトが収まることになる、使用可能な、連続的なフリーヒープスペースが十分にない場合に起きる。仮想メモリシステム上で、増え続けるヒープを供給するのに必要な余計なページングは、実行中のプログラムのパフォーマンスを低下させる可能性がある。

［００６２］
Ｊａｖａ(登録商標)プラットフォームに対しては、アプリケーション及びプログラミング方法により、いくつかのガベージコレクション方法を用いることができる。用いる方法に関わらず、該プロセスに付随する待ち時間問題は、たいてい実現する。歴史的に、当業者は、該ガベージコレクションメカニズムにヒントを与えることはできるが、そのことは、該プロセスを調整することを困難にし、その結果、発明者等のリサイクラーソリューションを求めることになる。

［００６３］
ガベージコレクションアルゴリズムは、２つの基本的なことを行う必要がある。第一に、該アルゴリズムは、ガベージオブジェクトを検知しなければならない。第二に、該アルゴリズムは、該ガベージオブジェクトによって使用されるヒープスペースを再要求し、それをプログラムに対して使用可能にしなければならない。ガベージの検知は、通常、ルートのセットを定義し、該ルートから到達可能性を判断することによって、実現される。オブジェクトは、実行プログラムが、それによって該オブジェクトにアクセスすることができる該ルートからの参照のパスがいくつかある場合に到達可能である。該ルートは、常に、該プログラムにアクセス可能である。該ルートから到達可能などのようなオブジェクトも、生であると考えられる。到達可能でないオブジェクトは、プログラム実行の成り行きにもはや影響を及ぼすことができないため、ガベージであると考えられる。

［００６４］
本発明の一つの態様は、Ｊ２ＥＥサーバまたはウェブコンテナ（例えば、Ｒｅｓｉｎ、Ａｐａｃｈｅ Ｔｏｍｃａｔ、ＢＥＡ ＷｅｂＬｏｇｉｃ、ＩＢＭ ＷｅｂＳｐｈｅｒｅ）が、ガベージコレクションアクティビティに影響を及ぼすサービスが発生する前に、設定可能な期間、要求を単に処理できるようにすることである。全体的な設計手法は、生であると考えられ、新たなセッション要求を処理する該コンテナ／サーバのうちのたった一つを備えるホスト上のウェブコンテナ／サーバのインスタンスが１つ以上あるということである。設定可能な期間の後、およびガベージコレクションアクティビティに影響を及ぼすサービスを避けるために、該アクティブなコンテナ／サーバは、新たなセッション要求を、新たに推進されるアクティブコンテナ／サーバへ向けた状態で、静止され、待機状態にされる。最初の新たなセッション要求を受取る負荷分散コンポーネントは、該要求を、現在アクティブなコンテナ／サーバへ分散させる。コンテナ／サーバが、アクティブな状態から待機状態へ促された後、該負荷分散コンポーネントは、新たなセッション要求を、新たに推進されたコンテナ／サーバへ送る。このプロセスは、該ホストがアクティブである限り続けられる。

［００６５］
上記のメカニズムは、２つ以上のコンテナ／サーバを一度にサポートしようとするものであるが、考察のために、２つのコンテナ／サーバが単一のホスト上に存在するものと仮定する。常に、該コンテナ／サーバのうちの一方のみが作動モードになっており（新たなクライアントからの要求を受け）、他方は待機状態になっている。アクティブなコンテナ／サーバのみが、新たなクライアントからの要求を受け容れることができる（新たなセッションが生成される）。（経験上のデータに基づいて得られる、あるいは、初期値または予測値に対してプログラミングすることができる）設定可能な期間の後、該待機状態のコンテナ／サーバは促されて、新たなセッション要求を受取り始め、一方、これまでアクティブだったコンテナ／サーバは、新たなセッション要求を受取らないが、既存のセッションの要求を処理し続けた後、設定可能な期間の後、静止される。静止されたコンテナ／サーバは、停止されて、設定可能な期間の後、再び、作動モードに促されるまで、待機モードに保持され、再始動される（これにより、どのようなガベージも一掃されて、「白紙状態」が生成される）。このプロセスは、上記ホストが、要求を受け容れるように構成されている限り、繰り返される。その結果、新たな要求が、同じホスト上のアクティブなウェブコンテナ／サーバへ向けられ、その結果、透過的に、および障害を伴うことなく、当該ウェブへのウェブ要求は、ＪＶＭガベージコレクションに影響を及ぼすサービスのオーバヘッドを招くことなく、処理される。同様のメカニズムが、２つ以上のコンテナ／サーバをサポートするのに用いられる。

［００６６］
図２は、本発明によるロードバランシングを実現できる一つの可能な構成を示すブロック図である。図示の構成は、４つのメディアサーバ１３０と、２つのアプリケーションサーバ１５０とを含む。メディアサーバ１３０の各々は、２つの仮想スイッチ２１０のうちの一方を介して、該アプリケーションサーバのいずれかにアクセスすることができる。該仮想スイッチの一つの実施形態は、レイヤ４のロードバランサーからなる冗長なペアとすることができる。仮想スイッチ２１０は、複数のリクエスタから複数の受信者へサービス要求をリダイレクトするように作動する様々なコンポーネントのうちのいずれかとすることができる。一つのそのようなコンポーネントは、ＬＶＳ（Ｌｉｎｕｘ Ｖｉｒｔｕａｌ Ｓｅｒｖｅｒ）とすることができる。ＬＶＳは、ロードバランサーをＬｉｎｕｘオペレーティングシステム上で作動させる、実際のサーバのクラスタ上に構築された高度にスケーラブルかつ高度に使用可能なサーバである。

［００６７］
メディアサーバ１３０から、要求が仮想スイッチ２１０に到達すると、仮想スイッチ２１０は、仮想スイッチ２１０により情報が提供されるアプリケーションサーバ１５０の現在の負荷及び使用性に基づいて、該要求をアプリケーションサーバ１５０へルーティングする。その結果、メディアサーバ１３０は、メッセージを仮想スイッチ２１０へ送る。該仮想スイッチは、どのアプリケーションサーバ１５０が、該要求に応答するのに用いられるかを判断し、アプリケーションサーバ１５０へ通知する。そして、アプリケーションサーバ１５０は、要求してきたメディアサーバ１３０に対して返答する。

［００６８］
アプリケーションサーバ１５０の各々は、ポートを含む。仮想スイッチ２１０は、要求を適切なポートへ送ることにより、該要求をアプリケーションサーバ１５０へルーティングする。仮想スイッチ２１０は、少なくとも２つの方法で、ロードバランシングを実行できる。一つの事例において、仮想スイッチ２１０は、特定のアプリケーションサーバ１５０へルーティングされている要求の数を監視し、仮想スイッチ２１０が、アプリケーションサーバ１５０が過度に利用されていると判断した場合には、該要求を別のアプリケーションサーバ１５０へリダイレクトすることができる。仮想スイッチ２１０は、重み付けプロセスを用いて、この判断を行うことができる。重みは、各ホスト、および該ホストへの接続の現在の数に対して割当てられる。アルゴリズムは、加重最小接続が、この判断を行うための基本として用いられているため、公知である。例えば、仮想スイッチ２１０は、トラフィックの１％を第１のアプリケーションサーバ１５０へルーティングし、残りの９９％のトラフィックを１つ以上の他のアプリケーションサーバ１５０へルーティングすることができる。別の事例において、アプリケーションサーバ１５０は、異なるアプリケーションサーバ１５０を利用するように、仮想スイッチ２１０に積極的に指示することができる。例えば、第１のアプリケーションサーバが過度に使用中である場合、アプリケーションサーバ１５０は、仮想スイッチ２１０に別の要求を異なるアプリケーションサーバへルーティングするように指示することができる。このことは、不明確な基準で（すなわち、アプリケーションサーバ１５０が、仮想スイッチ２１０に、再び使用可能であることを知らせるまで）行うことができ、あるいは、一時的な基準で（すなわち、一定期間、または、一定量のトラフィックに対して）行うことができる。このようにして、仮想スイッチ２１０は、上記通信プラットフォーム内でロードバランシングを実行するように作動する。

［００６９］
上記ＬＶＳは、アプリケーションサーバホスト１５０上のフィードバックメカニズムによって提供される個々のコンポーネントの負荷情報に基づいて、バランスさせることができる。例えば、該アプリケーションサーバ内のアプリケーションサーバコンテナは、「使用可能です」または「使用不能です」等のステータスを知らせる能力も有する。また、該アプリケーションサーバは、「何％ビジーです」等のパーセンテージビジーステータスを報知することもできる。そのため、このステータス情報は、該ＬＶＳにより実行される要求スケジューリングの決定に対する入力として用いることができる。

［００７０］
ロードバランシングは、別の方法で、すなわち、ガベージコレクションで、アプリケーションサーバレベルにも設けられている。ガベージコレクションのパフォーマンスのための本発明の一つの態様は、要求を実行する仮想マシンの２つのインスタンスを生成することである。該仮想マシンの各インスタンスは、それ自体のガベージコレクションプロセスを含む。一般に、仮想スイッチ２１０は、一定期間、アプリケーションサーバ１５０内の第１の仮想マシンへ要求をルーティングし、その後、別の要求は、第２の仮想マシンへルーティングされ、該第１の仮想マシンは、ガベージコレクションを実行する。該仮想マシンを切替える決定は、様々な要素に基づかせることができ、本発明は、特定のスキームに限定されない。例えば、一つの実施形態において、その切替えは、定期的に（すなわち、３０分毎に）実行することができる。他の実施形態においては、該切替えは、該仮想マシンに送られている要求の数、該仮想マシンに対して使用可能なメモリの量、および該仮想マシンによって処理されているスレッドの数等に基づいて実行することができる。

［００７１］
各仮想マシン内で、該ガベージコレクションプロセスは、一般に、最も低く、または、非常に低い優先度のタスクである。そのため、アプリケーションサーバ１５０が利用される場合、ガベージコレクション要件は、時間をかけて蓄積する。ある時点で、典型的には、使用可能なメモリが作動していないときに、該ガベージコレクションは、より高い優先度へ移さなければならない。該ガベージコレクションプロセスが始まり、アクティブプロセスがアプリケーションサーバ１５０によって提供されると、該システムのユーザは、不動作時間または待ち時間に遭遇することになる。

［００７２］
本発明は、この重大な岐路に直面する前に、上記仮想マシンを切替えるように作動する。そのため、一方の仮想マシンのガベージヒープがひどくなって、上記ガベージコレクションプロセスをより高い優先度へ移さなければならなくなり、それによって、システムパフォーマンスが低下する前に、サービスのための別の要求は、他方の仮想マシンへルーティングされる。有利には、このことは、上記第１の仮想マシンが、現在アクティブなプロセスを処理し続けることを可能にし、該ガベージコレクションプロセスは、メモリを必要とする可能性がある新たなプロセスの導入により、より高い優先度が与えられないことになる。要求が、一旦、他方の仮想マシンへルーティングされると、該ガベージは、２つの方法のうちの一方で一掃することができる。該ガベージコレクションプロセスを自動的に呼び出す仮想エンジンを再始動させることができる。しかし、現在、実行されているプロセスは、終了されることになる。そのため、より従順な方法は、現時点でアクティブなプロセスを継続できるようにすることであり、また、処理リソースが利用可能になったときに、あるいは、最後のプロセスが終了した後に、該ガベージコレクションプロセスを実施できるようにすることである。新たな要求は、他方の仮想マシンへルーティングされるため、これは、該ガベージコレクションプロセスを呼び出すことができる前の単純に時間の問題である。該ガベージコレクションプロセスが、一旦、呼び出されると、該第１の仮想マシンは、将来の要求に対処するために、使用可能になることができる。加えて、ＪＶＭプロセスが専有する全てのヒープメモリを解放することにつながるＪＶＭプロセスを再始動することができ、それにより、該ガベージコレクションプロセスを完全に避けることができる。

［００７３］
本発明の態様は、２つの仮想マシンを含むものとして記載されているが、どのような数の仮想マシンも用いることができ、また、該仮想マシンへの要求のルーティングを、ラウンドロビン方式で、または他の方法で実施できることを理解すべきである。

［００７４］
従って、本発明は、少なくとも２つの方法で、ロードバランシングを実行できるように作動する。一方のレベルにおいて、上記仮想スイッチは、アプリケーションサーバ１５０に向けられた負荷をバランスさせる。他方のレベルにおいて、アプリケーションサーバ１５０は、ガベージコレクションによる待ち時間問題を避けるように、２つ以上の仮想マシン間に、要求の処理を割り振る。

［００７５］
図３は、本発明の様々な態様を示すフロー図である。該フロー図は、仮想スイッチ２１０を介して１つ以上のアプリケーションサーバ１５０と通信するメディアサーバ１３０を示す。単一のメディアサーバ１３０と、単一の仮想スイッチ２１０と、２つのアプリケーションサーバ１５０のみが示されているが、本発明の様々な態様が、これらの構成に限定されないことを理解すべきである。これまで述べたように、本発明は、少なくとも２つの方法で、すなわち、アプリケーションサーバ間で負荷をバランスさせること、およびアプリケーションサーバ内で負荷をバランスさせることで、分散型通信プラットフォームにおけるロードバランシングを実行できる。まず、サービス要求３１０が、メディアサーバ１３０により仮想スイッチ２１０へ供給される。この時点で、仮想スイッチ２１０は、どのアプリケーションサーバが、サービス要求３１０を処理するのに適しているかに関しての判断を行う３１５。この判断は、該仮想スイッチによって自動的に実行する、該アプリケーションサーバに従属する仮想スイッチによって実行する、または、これら２つの両極端の手段の組合せによるもの等の様々な方法で実行することができる。例えば、該仮想スイッチは、要求の数、該要求のための処理要件、および追加的な要求を受け容れて処理する該アプリケーションサーバの能力に関する判断を行うための該アプリケーションサーバの容量を監視してもよい。別法として、該アプリケーションサーバは、現在の処理負荷、および追加的な要求を受け容れて処理する能力を知らせるために、ステータス情報を該仮想スイッチへ送ってもよい。その結果、該仮想スイッチ２１０は、負荷分散の決定を、（１）自立的に、（２）該アプリケーションサーバからの制御／ステータス情報に基づいて、または、（３）該仮想スイッチにより、該アプリケーションサーバから受取った情報と共に収集された情報に基づいて、実行することができる。

［００７６］
所望のアプリケーションサーバ１５０が、一旦、選択されると、仮想スイッチ２１０は、該サービス要求を、選択したアプリケーションサーバ１５０へ転送する３２０。最後に、アプリケーションサーバ１５０は、仮想スイッチ２１０を介して、または、メディアサーバ１３０と直接的に、該サービス要求に応答することになる。しかし、アプリケーションサーバ１５０は、アプリケーションサーバ１５０の処理割当てに関する追加的なステップを実施することもできる。一つのそのようなプロセスは、入ってくるサービス要求に対処するために用いられる処理プロセスの様々なインスタンスを生成することを含む。これまで述べたように、本発明は、上記ガベージコレクションプロセス中に、パフォーマンスの低下を伴わない、Ｊ２ＥＥ環境の実施を有利に可能にする。そのため、サービス要求を受ける前または後に、アプリケーションサーバ１５０は、該処理プロセスの複数のインスタンスを生成した後、特定のインスタンスを識別して現在のサービス要求に対処するように作動することができる３２５。作動中、アプリケーションサーバ１５０は、該処理プロセスの異なるインスタンスを用いることにより、処理負荷を分散させることができる。このことは、本願明細書に一部が記載されている様々な方法、ならびに、本発明が先行している、開示されていない他の方法で実現することができる。選択したそれらの方法に関わらず、アプリケーションサーバ１５０は、処理プロセスのインスタンスが過負荷であるか３３０を判断し、過負荷である場合には、該過負荷のインスタンスを回復させることができるように作動する３３５。例えば、一実施形態において、本発明は、該ガベージコレクションプロセスを、より高い優先度へ移す必要が生じる最適点を判断して、追加的なサービス要求を代替のインスタンスへ向け、該ガベージコレクションプロセスによるパフォーマンスの低下を避けるように作動する。

［００７７］
また、アプリケーションサーバ１５０は、アプリケーションサーバの選択の制御を制御またはサポートするために、情報を集めて分析し、該情報を仮想サーバ２１０へ戻して報告してもよい。このことは、アプリケーションサーバ１５０により定期的に行われ、それ自体のステータス３４０を判断し、その後、この情報を仮想スイッチ２１０へ報告する３４５。その結果、該仮想スイッチはスキャンして、どのアプリケーションサーバ１５０に、追加的なサービス要求をルーティングさせるべきかを判断する際に、この情報を用いる。

［００７８］
本発明を、例証として示し、また、本発明の範囲を限定することを意図していない、本発明の実施形態の詳細な説明を用いて説明してきた。記載した実施形態は、異なる特徴を備え、それらの全てが、本発明の全ての実施形態に必要なわけではない。本発明のいくつかの実施形態は、それらの特徴のうちの一部のみ、または、それらの特徴の可能性がある組合せを用いる。記載されている本発明の実施形態の変形例、および記載された実施形態において述べられた特徴からなる異なる組合せを備える本発明の実施形態が、当業者には思い浮かぶであろう。本発明の範囲は、以下の特許請求の範囲によってのみ限定される。

［０００９］
本発明の様々な態様及び特徴を用いることができる例示的な次世代通信プラットフォームの構成要素及び接続性を示すシステム図である。

［００１０］
本発明による、ロードバランシングを実現できる一つの可能な構成を示すブロック図である。

［００１１］
本発明の様々な態様を示すフロー図である。

Claims (20)

1. 複数の第１のクラスのコンポーネントが、複数の第２のクラスのコンポーネントのリソースを共有しなければならず、前記第１のクラスのコンポーネントが、１つ以上の切替えシステムを介して、前記第２のクラスのコンポーネントとインタフェースをとる分散型システムにおいて、２つのレベルのロードバランシングを可能にする方法であって、
   前記切替えシステムのうちの１つにおいて、前記複数の第１のクラスのコンポーネントのうちの１つからサービス要求を受取るステップと、
   前記切替えシステムが、前記要求を処理するために、複数の第２のクラスのコンポーネントのうちの１つを識別するステップと、
   前記要求を、前記識別した第２のクラスのコンポーネントへ転送するステップであって、前記識別された第２のクラスのコンポーネントが、前記要求に対処する実行プロセスの少なくとも２つのインスタンスを確立するように作動する、ステップと、
   前記識別された第２のクラスのコンポーネントにおいて、前記要求を受取るステップと、
   前記要求に対処するサービスプロセスの少なくとも２つのインスタンスのうちの一方に前記要求を割当てるステップであって、該割当てが、前記プロセスの少なくとも２つのインスタンスの現在の処理要件の少なくとも一部に基づいている、ステップと、
   を備える、方法。
2. 前記識別された第２のクラスのコンポーネントにおける前記実行プロセスの各インスタンスが、使用されていないメモリを解放するためのガベージコレクションプロセスを含み、前記サービスプロセスの少なくとも２つのインスタンスのうちの一方に前記要求を割当てるステップがさらに、前記サービスプロセスのインスタンス内で機能する前記ガベージコレクションプロセスのステータスに基づいている、請求項１に記載の方法。
3. 前記識別された第２のクラスのコンポーネントにおける前記実行プロセスの各インスタンスが、使用されていないメモリを解放するためのガベージコレクションプロセスを含み、前記サービスプロセスの少なくとも２つのインスタンスのうちの一方に前記要求を割当てるステップがさらに、前記サービスプロセスのインスタンス内の前記ガベージコレクションプロセスの機能に優先順位を付ける必要性に基づいている、請求項１に記載の方法。
4. 前記識別された第２のクラスのコンポーネントにおける前記実行プロセスの各インスタンスがガベージコレクションプロセスを含み、前記ガベージコレクションプロセスが、使用されていないメモリを解放する低優先度のバックグラウンドタスクとして機能し、前記サービスプロセスの少なくとも２つのインスタンスのうちの一方に前記要求を割当てるステップが、第１のインスタンスのための前記ガベージコレクションプロセスの優先度を上げることが必要になるまで、前記サービスプロセスの前記第１のインスタンスに前記要求を割当て、その後、後の要求を、前記サービスプロセスの別のインスタンスに割当てることによって実行される、請求項１に記載の方法。
5. 前記識別された第２のクラスのコンポーネントにおける前記実行プロセスの各インスタンスがガベージコレクションプロセスを含み、前記ガベージコレクションプロセスが、使用されていないメモリを解放する低優先度のバックグラウンドタスクとして機能し、前記サービスプロセスの少なくとも２つのインスタンスのうちの一方に前記要求を割当てるステップが、特定の期間、前記サービスプロセスの第１のインスタンスに前記要求を割当て、その後、後の要求を、前記サービスプロセスの別のインスタンスに割当てることによって実行され、前記特定の期間が、前記第１のインスタンスの過負荷を防ぐのに十分である、請求項１に記載の方法。
6. 前記識別された第２のクラスのコンポーネントにおける前記実行プロセスの各インスタンスがガベージコレクションプロセスを含み、前記ガベージコレクションプロセスが、使用されていないメモリを解放する低優先度のバックグラウンドタスクとして機能し、前記サービスプロセスの少なくとも２つのインスタンスのうちの一方に前記要求を割当てるステップが、第１のしきいメモリ使用度に達するまで、前記サービスプロセスの第１のインスタンスに前記要求を割当て、その後、後の要求を、前記サービスプロセスの別のインスタンスに割当てることによって実行される、請求項１に記載の方法。
7. 前記サービスプロセスの第１のインスタンスにおける前記メモリ使用度が、一旦、第２のしきい値以下に低下すると、前記サービス要求の割当てが、前記サービスプロセスの第１のインスタンスへ戻される、請求項１に記載の方法。
8. 前記識別された第２のクラスのコンポーネントにおける前記実行プロセスの各インスタンスがガベージコレクションプロセスを含み、前記ガベージコレクションプロセスが、使用されていないメモリを解放する低優先度のバックグラウンドタスクとして機能し、前記サービスプロセスの少なくとも２つのインスタンスのうちの一方に前記要求を割当てるステップが、第１のしきい数のサービス要求が、第１のインスタンスへ送られるまで、前記サービスプロセスの前記第１のインスタンスに前記要求を割当て、その後、後の要求を、前記サービスプロセスの別のインスタンスに割当てることによって実行される、請求項１に記載の方法。
9. 前記要求を処理する複数の第２のクラスのコンポーネントのうちの１つを識別する前記切替えシステムのステップがさらに、前記要求の第１の割合を処理する第１のコンポーネントを識別するステップと、前記要求の残りの割合を処理する第２のコンポーネントを識別するステップとを備える、請求項１に記載の方法。
10. 前記要求を処理する複数の第２のクラスのコンポーネントのうちの１つを識別する前記切替えシステムのステップがさらに、前記要求の第１の割合を処理する第１のコンポーネントを識別するステップと、前記要求の残りの割合を処理する第２のコンポーネントを識別するステップとを備える、請求項１に記載の方法。
11. 前記要求を処理する複数の第２のクラスのコンポーネントのうちの１つを識別する前記切替えシステムのステップがさらに、前記要求の第１のしきい数を処理する第１のコンポーネントを識別するステップを備える、請求項１に記載の方法。
12. 前記要求を処理する複数の第２のクラスのコンポーネントのうちの１つを識別する前記切替えシステムのステップがさらに、
    前記コンポーネントの現在の負荷を確認する前記複数の第２のクラスのコンポーネントの各々から指示を受取るステップと、
    前記コンポーネントの現在の負荷に少なくとも部分的に基づいて、前記複数の第２のクラスのコンポーネントのうちの１つを選択するステップと、
    を備える、請求項１に記載の方法。
13. サービス要求の処理のためのロードバランシングを可能にする分散型通信システムであって、
    通信サービスを提供する電話システムとインタフェースをとるメディアサーバと、
    １つ以上のスイッチと、
    前記１つ以上のスイッチを介して、前記メディアサーバとインタフェースがとられる２つ以上のアプリケーションサーバとを備え、
    前記アプリケーションサーバの各々が、
    実行プロセスの複数のインスタンスを生成し、
    第１のインスタンスが、しきい負荷に達するまで、前記実行プロセスの前記第１のインスタンスを用いて、全てのサービス要求を処理し、
    前記実行プロセスの別のインスタンスに切替えて、後のサービス要求に対処することにより、
    前記メディアサーバから受取った要求を実行するように作動する、分散型通信システム。
14. 前記アプリケーションサーバの各々は、前記実行プロセスの各インスタンスが、使用されていないメモリを解放するガベージコレクションプロセスを含む状態で、ＪＡＶＡ(登録商標)２ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ環境を用い、前記アプリケーションサーバの各々は、前記実行プロセスの第１のインスタンスのガベージコレクションプロセスがより高い優先度を必要とする場合に、前記実行プロセスの別のインスタンスに切り替わるように作動する、請求項１３に記載の分散型通信システム。
15. 前記アプリケーションサーバの各々が、前記実行プロセスの各インスタンスが、使用されていないメモリを解放するガベージコレクションプロセスを含む状態で、ＪＡＶＡ(登録商標)２ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ環境を用い、前記しきい負荷レベルは、前記第１のインスタンスが、サービス要求を処理するのに用いられている時間の量によって決まる、請求項１３に記載の分散型通信システム。
16. 前記１つ以上のスイッチの各々は、前記メディアサーバからの要求がルーティングされる前記２つ以上のアプリケーションサーバのうちの１つのアプリケーションサーバを選択して、それにより、前記分散型通信システムのためのロードバランシングを実行するように作動する、請求項１３に記載の分散型通信システム。
17. 前記１つ以上のスイッチの各々は、前記アプリケーションサーバによって処理されている要求の数に基づいて、アプリケーションサーバを選択するように作動する、請求項１６に記載の分散型通信システム。
18. 前記１つ以上のスイッチの各々は、前記２つ以上のアプリケーションサーバから受取ったステータス情報に基づいて、アプリケーションサーバを選択するように作動する、請求項１６に記載の分散型通信システム。
19. 前記アプリケーションサーバの各々は、前記実行プロセスの各インスタンスが、使用されていないメモリを解放するガベージコレクションプロセスを含む状態で、ＪＡＶＡ(登録商標)２ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ環境を用い、前記アプリケーションサーバの各々は、前記実行プロセスの第１のインスタンスのガベージコレクションプロセスがより高い優先度を必要とする場合に、前記実行プロセスの別のインスタンスに切り替わるように作動し、前記１つ以上のスイッチの各々は、前記アプリケーションサーバによって処理されている要求の数に基づいて、アプリケーションサーバを選択するように作動する、請求項１３に記載の分散型通信システム。
20. 前記アプリケーションサーバの各々は、前記実行プロセスの各インスタンスが、使用されていないメモリを解放するガベージコレクションプロセスを含む状態で、ＪＡＶＡ(登録商標)２ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ環境を用い、前記アプリケーションサーバの各々は、前記実行プロセスの第１のインスタンスのガベージコレクションプロセスがより高い優先度を必要とする場合に、前記実行プロセスの別のインスタンスに切り替わるように作動し、前記１つ以上のスイッチの各々は、前記１つ以上のアプリケーションサーバから受取ったステータス情報に基づいて、アプリケーションサーバを選択するように作動する、請求項１３に記載の分散型通信システム。

Images