JP2009540717A - 自己管理型分散メディエーションネットワーク - Google Patents

Abstract

自己管理型分散メディエーションネットワーク
複数の異なるタイプのネットワークモジュールを有する、分散メディエーションネットワーク及びこれを用いる方法を提供する。各モジュールは、各モジュールを通過するネットワークトラフィックの非相互的なパスを有し、ネットワーク全体にかかるネットワークトラフィックを分散する処理は、自律的コントロールプレインによって管理される。
【選択図】図６

Description

序
本発明は、メッセージ散在型のピアツーピア通信の要件を備えると共に、そのような散在しているメッセージ全体に対する情報収集をある程度まで制御することができる自己管理型分散メディエーションネットワークに関する。

発明の背景
ピアツーピア（Ｐ２Ｐ）通信システムでは、計算主体（ピア）はソフトウェア的な接続（仮想チャンネル）を相互に確立することができる。そのため、Ｐ２Ｐ通信システムでは、ピアは、互いに通信することができ、計算タスク及び計算リソースを共有することができる一方で、集中的制御を行う必要がない。Ｐ２Ｐ通信システムは、１つ以上のサーバを備える汎用ネットワーク上において動作する。そして、ピアは、ネットワーク上の少なくとも１つのサービスに対して情報を提供（「発行」）し、ネットワーク上のサービスに登録（「購読」）することで、他のピアが発行した情報を取得する。

集中的制御の機能を備えることによる利点を有するメッセージ通信システムも、広く知られている。このシステムでは、全てのメッセージは、メッセージに対する計算処理（メディエーション）が実行される中心点を経由して、発行ピアから購読ピアへ送られる。入力メッセージから生成された新しいメッセージ（ダイジェストなど）は、適切な購読ピアへ送信される。

従来技術の集中メディエーションシステムでは、全てのメッセージトラフィックは、メディエーションサービスを行うネットワーク中心点を経由して伝送される。論理的な要素を考慮すれば、このシステムは、星型構造をしたモデルとして構築され、メディエーションタスクが実行される制御中心点を備える。このモデルの概念図を図１Ａに示す。図１Ａにおいて、各々の情報発信体（発行ピア）及び情報受信体（購読ピア）は、中央メディエーションハブと通信回線を介して接続されている。ほとんどの場合、情報発信体及び情報受信体は異なるモードで動作する同一の実体を表し、それらは構造的には互いに区別することができない。

そのような構造に起因する問題点は、広く知られている。星型構造を有する集中メディエーションシステムでは、メディエーションが行われる制御中心点において、回線容量が不足する事態に陥りやすい。論理的な星型モデルを高密度に接続された物理ネットワーク上で実現する場合でも、基本的に全ての情報は制御中心点を経由して伝送されるため、制御中心点とネットワークを結ぶ利用可能な回線容量の状況次第では、特有のスループット障害が発生する（図１Ｂを参照）。ネットワーク技術の進歩により、利用可能な回線容量は次第に向上しているが、回線容量の増加は特有の経済的負担をもたらす。また、状況によっては、システム全体のスループットが実際に制限される場合がある。この制限の具体例として、ユーザ数の制限や、各ユーザが情報を送受信する際の回線速度の制限がある。

Ｐ２Ｐ構造も集中メディエーション構造も完全には要求を満たさないシステムの例が、現実には数多く存在する。多くの場合、メッセージ通信システム全体に送信されたメッセージ全体に対する処理を行うための論理プロセスが要求される。上述したどちらの構造も完全には適切でないシステムの例として、以下のものが挙げられる。第一に、潜在的な買い手と売り手が相互に通知する商取引システムで、取引において互いの要求が合致したことを保証する目的でメディエーションが必要である。第二に、情報が分散される前に、中心的権限の保有者が情報の編集管理を行う仲介型（ｍｅｄｉａｔｅｄ）ニュース及び出版システムである。第三に、積極的には制御されないが、セントラル・レポジトリで保管される情報フローに関する順序付きログが要求されるシステムである。第四に、直近の会話の背景（コンテキスト）を現在進行中の会話に参加しているユーザに提示することができる会話サービスである。第五に、暗号鍵の配布（いわゆる鍵配布問題）である。第六に、分散ネットワーク上のデータ（状態）及びサービスを検索するシステムである。第七に、モバイル機器ユーザの場所を特定して、他のモバイル機器ユーザと通信を行うためのシステムである。

上記の例は全て、ピアツーピア通信の要件と、通信を全体的に見渡したときの情報フローの集中メディエーションの要件との両方を有している。

参照によって本明細書に援用される、出願人の係属中米国特許出願１０／９０３，１５６号は、上述した欠点の多くを克服する分散メディエーションネットワークに関する記載がある。このタイプの分散メディエーションネットワークは、論理的に分離した多数の実体間にサービスを分散することによって、一つのサーバでメディエーションサービスを提供する際に発生する問題を回避する。そのためには、メディエーションアプリケーションは、複数の分離したメディエーションアプリケーションコンポーネントに論理的に分割可能でなければならない。これにより、メディエーションサービスは、サーバのリソースプール全体に分散された１セットのメディエーションセグメントサービスに分割可能となる。各サーバはメディエーションサービスを、１つ以上のメディエーションセグメントサービスとして提供する。以下では、この手法を「分散メディエーション」と呼ぶ。

全てのメディエーションポイントで回線容量の問題を適切に回避するためには、利用可能なリソースプール全体にメディエーションサービスを均等にロードバランシング（負荷の均衡を保つ処理）できなければならない。時間の経過と共に要求量が変動するシステムにおいては、リソースプール全体で負荷の均衡が動的に保たれなければならない。そのため、アプリケーションの分割態様は動的に変更可能でなければならない。従って、メディエーションセグメントサービスを一のサーバから他のサーバへ移動できることが必要である。また、メディエーションセグメントサービスが移動する際には、外部から観測される因果関係が保存されなければならない。すなわち、各メディエーションセグメントサービスが相互に作用する順序は、メディエーションセグメントサービスの実行形式の変化に関わらず保存されなければならない。そのような相互作用の順序が乱れた場合に深刻な結果を引き起こす多数のシステム（例えば、金融システム）において、この要件は極めて重要である。

分散メディエーションネットワークにおいて、情報はコンテンツによる分類がなされ、メディエーションの要求は、そのコンテンツに基づいた分類に応じて、異なるプロセスで別々に満たされる。メディエーションの要求量が分類に応じて時間変化すると、対応するメディエーションアプリケーションコンポーネントは、システム全体に対するネットワーク負荷及び計算負荷の両方の均衡を保つように物理的に移動される。そのようなロードバランシングにより、メディエーションを行う利用可能なサーバが有する計算リソース、入出力リソース及びメモリリソースの総量に影響される閾値まで、メディエーションの要求量が満たされることになる。この閾値を超えると、利用可能なリソースが負荷を処理できないために、サービスの品質は低下することになる。この問題に対処するために、分散メディエーションネットワークは、計算リソースをシステムへ追加するための機構を提供することが好ましい。同様に、メディエーションのために分割されたアプリケーションに対して過剰な計算リソースが利用可能な場合には、分散された計算能力（計算リソース）を除去できることが好ましい。

「自律的な（ａｕｔｏｎｏｍｉｃ）」という文言は、歴史的には、呼吸速度や心臓の鼓動の制御など身体を制御するために意識下で作用する神経システムの観点から使用されてきた。最近では、類似の自己制御が可能なコンピュータネットワークを意味する用語として用いられている。数あるシステムの中でも、自律的システムは、外部入力を必要とすることなく自己修復、自己構築、自己監視及び自己最適化をすることができる。実際のところ、自律的システムの実例において、ユーザが自律的に生じる変化を検知することは事実上不可能である。

自律的計算システムは、自律的要素から構成される。これらの自律的要素は、システムをいくつかの観点から監視する論理的構成物であり、システムの出力を分析し、特定の動作を行うことでシステムを調整する。これにより、システム全体は、「サービスレベル合意（ｓｅｒｖｉｃｅ ｌｅｖｅｌ ａｇｒｅｅｍｅｎｔｓ（ＳＬＡｓ））」と表現される特定の要求に適合することができる。ＳＬＡによって、業種によって必要とされる情報技術リソース及びリソースが維持する特定のアプリケーションが決定される。

自律的要素は、自己組織化しており、相互に相手を発見し、独立して動作し、必要に応じて交渉あるいは協力し、自分自身を組織化することができる。これにより、リソースのボトムアップ要求量と、リソースのトップダウンのビジネス向けアプリケーションとの両方を考慮してシステム全体を突発的かつ階層的に管理することで、特定の目標を達成する。

本発明の目的は、分散メディエーションネットワークに自律的機能を提供することにある。

本明細書において、「物理ノード」の文言は、物理的機械を意味する。「ノード」及び「論理ノード」の文言は、互いに区別なく使用され、状態特性（ｓｔａｔｅ ｐｒｏｐｅｒｔｉｅｓ）を有する箇所を意味する。メディエーションネットワークの論理的トポロジーの観点からは、「モジュール」は関連する論理ノードの機能を提供する。

さらに、「高水位線（ｈｉｇｈ ｗａｔｅｒｍａｒｋ）」の文言は、ネットワーク内の一の要素あるいはノードが処理することができるトラフィックの最大閾値を表す用語として用いられる。また、「低水位線（ｌｏｗ ｗａｔｅｒｍａｒｋ）」の文言は、そのトラフィックの最小閾値を表し、各要素は、高水位線と低水位線との間の範囲におけるトラフィックレベルを処理するように構成されている。

発明の要約
本発明の第１実施形態に係る分散メディエーションネットワークは、
メディエーションネットワークとクライアントプログラムとの間で、ネットワークトラフィックを送受信するローカルポイント・オブ・プレゼンス（ＬＰＰ）モジュールと、
メディエーションタスクを担当するメディエータ（Ｍ）モジュールと、
入力メッセージのコンテンツを解析するメディエータルータ（ＭＲ）モジュールであって、各ＭＲモジュールは、前記コンテンツに基づいて予め決定されたメディエーションタスクへ入力メッセージをルーティング（経路制御）するＭＲモジュールと、
メッセージを前記ＬＰＰモジュールのうちの少なくとも１つへ転送する伝送プロキシ（ＴＰ）モジュールと、
から成る複数のタイプのネットワークモジュールであって、ＭＲモジュール、Ｍモジュール及びＴＰモジュールのそれぞれは、それらを通過するネットワークトラフィックの全てのパス（経路）が非相互的になるように適合されているネットワークモジュールと、
モジュール間でのネットワークトラフィックの分散を管理する自律的コントロールプレインと、
を備える。

好ましくは、ネットワークは一方向メディエーションサイクルに従ってネットワークトラフィックを接続する。すなわち、一方向メディエーションサイクルにおいて、ＬＰＰモジュールはＭＲモジュールを指定し、次にＭＲモジュールはＭモジュールを指定し、次にＭモジュールはＴＰモジュールを指定し、そして次にＴＰモジュールはＬＰＰモジュールを指定する。

本発明の第２実施形態に係る、コンピュータネットワークにおけるネットワークトラフィックのフロー（流れ）をメディエート（仲介）する方法では、コンピュータネットワークはメディエーションネットワークを有しており、メディエーションネットワークは、
メディエーションネットワークとクライアントプログラムとの間で、ネットワークトラフィックを送受信するローカルポイント・オブ・プレゼンス（ＬＰＰ）モジュールと、
メディエーションタスクを担当するメディエータ（Ｍ）モジュールと、
入力メッセージのコンテンツを解析するメディエータルータ（ＭＲ）モジュールであって、各ＭＲモジュールは、前記コンテンツに基づいて予め決定されたメディエーションタスクへ入力メッセージをルーティングするＭＲモジュールと、
メッセージを前記ＬＰＰモジュールのうちの少なくとも１つへ転送する伝送プロキシ（ＴＰ）モジュールと、
から成る複数のタイプのネットワークモジュールであって、ＭＲモジュール、Ｍモジュール及びＴＰモジュールのそれぞれは、それらを通過するネットワークトラフィックの全てのパスが非相互的になるように適合されているネットワークモジュールと、
モジュール間でのネットワークトラフィックの分散を管理する自律的コントロールプレインと、
を備える。

この方法において、入力メッセージはメディエーションサイクルに従って伝達され、前記メディエーションサイクルは、
ＬＰＰモジュールが、少なくとも１つのＭＲモジュールの１つへ入力メッセージをそれぞれ転送するステップと、
前記転送されたＭＲモジュールが、入力メッセージのコンテンツを解析し、解析されたコンテンツに基づいて予め決定されたＭモジュールへ前記入力メッセージをルーティングするステップと、
前記予め決定されたＭモジュールが、前記解析されたメッセージに対してメディエーションタスクを実行し、メディエートされたメッセージを前記ＴＰモジュールの１つへそれぞれ送信するステップと、
前記メディエートされたメッセージを受信したＴＰモジュールが、前記メディエートされたメッセージを前記ＬＰＰモジュールの少なくとも１つへ転送するステップと、
から構成される。

本発明は、各々のノード、すなわちモジュールにかかるトラフィックの負荷を自律的に管理する分散メディエーションネットワークを提供する。自律的コントロールプレインは、ネットワークが検出した自身のネットワークの状況に応じて、モジュール（ノード）間のネットワークトラフィックの分散を調整する。

モジュールを通過するネットワークトラフィックのパスは非相互的である。すなわち、モジュール間のネットワーク上のパスは一方通行であるが、モジュールはネットワークトラフィックを複数のモジュールとの間で送受信することができる。例えば、ＭＲモジュールは、ネットワークトラフィックを複数のＬＰＰモジュールから受信することができ、ネットワークトラフィックを複数のＭモジュールへ送信することができる。しかし、ＭＲモジュールは、ネットワークトラフィックをＬＰＰモジュールへ送信することや、ネットワークトラフィックをＭモジュールから受信することはできない。その結果、ネットワークトラフィックがＬＰＰモジュールからＭＲモジュール、Ｍモジュール及びＴＰモジュールを経てＬＰＰモジュールへと通過する循環ネットワークができる。

ネットワークトラフィック、すなわちメッセージと同様に、自律的コントロールプレインによって発行されたコマンドを実行するために、制御メッセージ及び制御信号がネットワーク上を通過する。制御メッセージは、モジュール間を連結する非相互的なパスを、ネットワークメッセージのように必ずしも一方通行的にたどる必要はない。それにもかかわらず、いくつかの実施形態においては、ネットワークトラフィックがたどるノード間の一方通行のパスに逆行して、制御メッセージが流れることはできない。すなわち、そのような実施形態においては、ネットワークトラフィックがたどるサイクル（循環路）に逆らう方向へ制御メッセージを転送することができない。例えば、制御メッセージは、ＭモジュールからＭＲモジュールへ、あるいはＬＰＰモジュールからＴＰモジュールへと通過することができない。

好ましい実施形態においては、自律的コントロールプレインは、分散ネットワーク内のノードのステータス（状態）に関する情報を、分散ネットワークに組み込みのセンサインターフェースから受信する。そして、エフェクタインターフェースを介してノードに対してアクション（動作）を命令する。

好ましい実施形態においては、自律的コントロールプレインは、多数のリソースにわたって分散されている。これにより、１つ以上のリソースが正常に機能しない場合でも、自律的コントロールプレインは動作を継続することができる。さらに、自律的機能に基づく計算負荷の分散を任意の時に最適化して実行することができる。例えば、一のリソースが自律的制御に無関係なタスクを処理するという負荷の高い要求を担当している場合に、他のリソースは自律的制御の負担を引き受けることができる。

従って、自律的コントロールプレインは、ネットワーク全体の状況を監視し、利用可能なリソースの使用を最適化するためにネットワーク構造の形状を調整することができる。特に、メディエーションタスクは提供されたメディエーションサービスのセグメント（断片）であり、利用可能なＭモジュールにわたってメディエーションサービス全体を分散させる目的で、自律的コントロールプレインは効果的である。これにより、どのＭモジュールにも負荷が過剰にかかることはない。また、自律的コントロールプレインは、Ｍモジュール及びＬＰＰモジュールから送信されるトラフィックの送信先を変更することで、ＭＲモジュール及びＴＰモジュールにそれぞれかかるトラフィックレベルを管理することもできる。

また、自律的コントロールプレインは、システムが十分な処理能力を有することを保証するために、少なくともクロスストリームモジュール（Ｍモジュール及びＭＲモジュール）の数を、そして好ましくはＴＰモジュール及びＬＰＰモジュールの数を、増減することができる。好ましくは、自律的コントロールプレインは、どのモジュールも過大な負荷がかからないことを保証する方法で、トラフィックをＬＰＰモジュール、ＭＲモジュール及びＴＰモジュールに通過させる。上述した通り、トラフィックは、要求されるメディエーションセグメントサービスに応じたＭモジュールを通過する。

好ましくは、自律的コントロールプレインは、各種類のネットワークモジュールに対する単一の自律的マネージャであるクラウドマネージャ（ｃｌｏｕｄ ｍａｎａｇｅｒｓ）と、各クラウドマネージャに対する自律的マネージャとして動作する全体的な分散メディエーションネットワークマネージャと、を有する階層構造を備える。いくつかの例において、クラウドマネージャは、例えばネットワーク上の地理的領域に基づいて分割された区域を含むことができる。そのような構造が有する利点の１つは、Ｍモジュールの使用を最適化するクラウドマネージャは、独立して他種類のネットワークモジュールのように振舞うこともできるということにある。例えば、ＬＰＰモジュールを担当している第１のビジネスエンティティ（ｂｕｓｉｎｅｓｓ ｅｎｔｉｔｙ）が、メディエーションサービスを提供するために、Ｍモジュールを担当している第２のビジネスエンティティを使用する場合、これら２つのビジネスエンティティは、セキュリティ上の理由で互いのリソースへのアクセスを許可することに対して難色を示す。自律的コントロールプレインの好ましい階層構造は、これら２つのタスクを確実に分離するために十分である。

分散メディエーションネットワークマネージャは、リソースをクラウドマネージャへ割り当てることを担当するが、これらのリソースが意図している目的を認識している必要はない。

本発明の分散メディエーション構造は、多数のサーバにわたってメディエーションサービスを自律的にロードバランシングすることができ、これにより、仲介型アプリケーションによって消費されるリソースを動的に調整することができる。前記ロードバランシングは、仲介型アプリケーションへ転送されたメッセージ及び仲介型アプリケーションから転送されたメッセージの因果的配信則（ｃａｕｓａｌ ｄｅｌｉｖｅｒｙ）を遵守しつつ、サービス使用中に中断されることなく達成される。

先の記述から、本発明の主要な利点を以下に列挙する。
− サービスが場所に依存しない。
− ノードがシステムに関する全体的な知識を必要としないという点において、構造が拡張可能である。
− 構造が動的である。すなわち、サービスを再配置することができ、また、必要に応じて新しいノードを透過的に追加あるいは削除できる。
− 構造が自律的である。すなわち、リソースプールのサイズ、分散メディエーションネットワークトポロジー及びサービスの分散を自動的に最適化するための運用指針を有する。

図面の簡単な説明
次に、本発明に係る実施例について、添付した図面を参照しながら詳細に説明する。

図１Ａは、星型の論理的構造を有する従来技術の仲介型情報フローシステムを表すノード図である。

図１Ｂは、図１Ａにおけるシステムの物理的構造を概略的に表すノード図である。

図２Ａは、集中ネットワーク論理的構造を有する従来技術の仲介型情報フローシステムを表すノード図である。

図２Ｂは、図２Ａにおけるシステムの物理的構造を概略的に表すノード図である。

図３は、全ての有効な分散メディエーションネットワークノードの一部である基本サイクル（ＬＰＰノード−＞ＭＲノード−＞Ｍノード−＞ＴＰノード−＞ＬＰＰノード）を示す最小限の構成を表すノード図である。

図４は、本発明に係るキュービックな（ｃｕｂｉｃ）分散メディエーションモデルを表すノード図である。

図５は、本発明に係る自律的コントロールプレインが担当すべき機能を例示する。

図６は、本発明の好ましい実施形態の自律的コントロールプレインの階層構造を例示する。

図７Ａ乃至７Ｆは、キュービックな分散メディエーション構造において、送信Ｍモジュールｍ２から受信Ｍノード（モジュール）ｍ１へメディエーションタスクを譲渡する処理の各ステップを示す。

図８は、図４におけるキュービックな分散メディエーションモデルへのＭノードの追加を例示する。

図９は、図４におけるキュービックな分散メディエーションモデルとトポロジー的に等価なノード図である。このいわゆる円筒状の（ｃｙｌｉｎｄｒｉｃａｌ）レイアウトを用いることで、任意の分散メディエーションネットワークへの変化について簡潔に説明することができる。

図１０Ａ乃至１０Ｅは、少なくとも２つのＬＰＰノードが１つの共通のＭＲノードに接続されている開始状態から、一のＬＰＰノードが別の新しいＭＲノードに関連付けられている状態に変更する処理の各ステップを示す。

図１１Ａ乃至１１Ｄは、同様に、Ｍノードが新しいＴＰノードに関連付けられている状態に変更する処理の各ステップを示す。

図１２Ａ乃至１２Ｄは、ＭＲノード及びＴＰノードを追加する処理について例示する。

発明の詳細な説明
最初に、本発明の背景として、Ｐ２Ｐモデル及び集中仲介型メッセージモデルに関して説明する。以下の説明において、「ソース」という文言は、新しいメッセージを生成してネットワークサービスへ送信するクライアントを意味し、「シンク」という文言は、ネットワークサービスからのメッセージを受信するクライアントを意味する。ネットワークサービスにおける各クライアントは、ソース、シンクあるいはその両者の機能を有する。別の専門用語を用いると、情報のソースは「発行者（ｐｕｂｌｉｓｈｅｒｓ）」と呼ばれ、情報に対するシンクは「購読者（ｓｕｂｓｃｒｉｂｅｒｓ）」と呼ばれる。

Ｐ２Ｐモデルにおけるコンテンツベースのルーティングを行う際には、適切なソースと適切なシンクとの間で仮想チャンネルを確立することで、ソースからシンクへのメッセージの効率的な伝送が可能になるように、ネットワークが構成される。伝送効率を向上させるためには、一般的には、完全結合グラフ（ｆｕｌｌｙ ｃｏｎｎｅｃｔｅｄ ｇｒａｐｈ）から不必要なエッジ（ノード間を接続している通信線のこと）を検出して削除する。その結果生じた最適化されたグラフは、利用可能なネットワークインフラに適合している。Ｐ２Ｐ仮想チャンネルを確立するためには、一のピアによる「関心の表明」（ｅｘｐｒｅｓｓｉｏｎ ｏｆ ｉｎｔｅｒｅｓｔ）と、別のピアによる「関心の承諾」（ａｃｃｅｐｔａｎｃｅ ｏｆ ｔｈａｔ ｉｎｔｅｒｅｓｔ）と、が要求される。

一方、集中仲介型メッセージモデルにおいては、全てのメッセージは集中メディエーションノードを介して伝送される（図１Ａ及び図１Ｂを参照）。メディエーションネットワークに関する専門用語において、「メディエーションサービス」は、全ての入力メッセージへ適用されるある種の計算処理を意味する一般的な用語である。また、「仲介型構造における特定のインスタンスに対するメディエーション要求」は、提供される全てのメディエーションサービスの照合を意味する。また、「メディエーション権限」は、メディエーションサービスを提供する人を意味する。また、「メディエーションネットワーク」は、メディエーション権限の制御下にある物理的な計算主体（機械）から成るネットワークを意味する。また、「メディエーションサーバ」は、１つ以上のメディエーションサービスを提供する物理的機械を意味する。

一般的な仲介型情報フローシステムを単純化したモデルにおいては、メディエーション権限へ送信されたメッセージは、以下の複数のタイプのうちの１つへ当てはめることができる。そのタイプとは、情報のソースとして動作するプロセスが生成した新しい情報と、メディエーション権限が有する状態に関する、迅速な応答を要求する問い合わせ（クエリー）と、メディエーション権限によって新しい関連情報が受信される度に、進行中の応答を要求する本質的かつ永続的な問い合わせ（クエリー）である関心の表明と、である。

完全仲介型モデルにおいてさえ、各仮想チャンネルにかかる回線容量の要求量を低減して、ネットワークサービスをシンクへ転送する際に、関心の表明が重要であるということは、注目に値する。

上記の定義に照らすと、「仲介型情報フローシステム」は、中央のメディエーション権限へ送信されると共に、中央のメディエーション権限から送信される情報を含むメッセージから構成されるシステムである。この権限によって実行される動作（アクション）には、時系列に沿った受信メッセージに関するログの記録と、ある時点までに受信されたメッセージ全体に対する演算処理と、メッセージの内容に基づいてある種の計算処理を実行した後に行われる他のクライアント間における入力メッセージの分散と、がある。

本発明は、コンテンツベースの非集中型Ｐ２Ｐモデルと、単純な集中型かつ仲介型のネットワークモデルと、の複合モデルに関する。この複合モデルでは、集中メディエーションノードが１つだけ備えられる代わりに、多数の独立した機能コンポーネントを備えるメディエーションネットワーク内に、種々のメディエーションサービスが分散して配置される。このような複合モデルにおいて、関心の表明は、ソースノードとＭノードとの間で仮想チャンネルを開く目的で用いられる。また、関心の表明は、Ｍノードとシンクノードとの間で仮想チャンネルを開く目的でも用いられる。従って、シンクノードが受信したメッセージは、メディエーションサービスに登録された関心の表明によって所轄される。ソースノードとシンクノードとの間には２つ以上の論理的な飛び（ｌｏｇｉｃａｌ ｈｏｐｓ）が存在するために、ソースノードとシンクノードとの間で発生する待ち時間は、単純なコンテンツベースのルーティングに要する時間に比べて必然的に長くなる。状況によっては、より静的な情報が利用可能になるに従って、各々の論理的な飛びにおける待ち時間を順次低減することができる。単純な仲介型モデルと比べて、この複合モデルでは、メディエーションタスクが多数のノードにわたって分散されているために、より複雑な構造を有する（図２Ａを参照）。しかしながら、集中型かつ仲介型のモデルに固有の集中メディエーションノードで発生する障害は除去されるので、結果として生じる構造は拡張可能である。

図３は、「静止している（ｑｕｉｅｓｃｅｎｔ）」あるいは「定常状態（ｓｔｅａｄｙ ｓｔａｔｅ）にある」、すなわち論理的トポロジーの変化がない状態にある（複合）分散メディエーションモデルが備える機能コンポーネントを表す最小限のトポロジーを示す。図３は、データがシステム内部において種々のコンポーネントノード間をどのように流れるかを示している。

無限の規模を有する分散メディエーションネットワークにおいても、必要なコンポーネントノードは全て、この最小限のトポロジーに含まれており、ソースと、シンクと、ローカルポイント・オブ・プレゼンスと、メディエータルータと、メディエータと、伝送プロキシとが備えられている。以下、これらの用語及び他の用語について定義する。

ローカルポイント・オブ・プレゼンス（ＬＰＰ）は、クライアント（ソース及びシンク）と分散メディエーションネットワークの他のネットワークノードとの間の仲介者（ｉｎｔｅｒｍｅｄｉａｒｙ）として作用する。ローカルポイント・オブ・プレゼンスは、ネットワーク上の特定の地理的領域に対するメディエーションサービスを代理するネットワークノードである。メディエーションサービスの各クライアントは、一のローカルポイント・オブ・プレゼンスのみと通信して、メディエーション構造内の他のノードとは通信しない。システムは任意の数のＬＰＰを備えることができ、各ＬＰＰはそれぞれのクライアントにサービスを提供する。

メディエーションルータ（ＭＲ）は、入力メッセージのコンテンツを分析して多数のクロスストリーム上のＭノードの内の１つへ入力メッセージを送信するメディエーションルータモジュールを内部に組み込んでいるネットワークノードである。各メディエーションルータは、アップストリームネットワークの先頭に位置し、多数のＬＰＰからメッセージを受信する。また、メディエーションルータは、例えば、担当する地理的領域内のローカルなサービスを使用可能にするために、入力メッセージに関するログを記録する。

メディエータ（Ｍ）は、メディエータモジュールを内部に組み込んでいるネットワークノードであり、メディエーション要求のサービスを提供する。各メディエータは、関連するダウンストリームに対してメッセージを分散する機能を有し、該当するメッセージをＬＰＰ、そして最終的にシンクへと転送させるために用いられる。それぞれのメディエータモジュールは、１つ以上のメディエーションタスクを実行する。それぞれのタスクは、特定のタイプのメッセージセグメントへ適用される一つのメディエーションセグメントサービスを表している。メディエータモジュールは、受信する全ての入力メッセージをログに記録して、これらの入力メッセージを関連するダウンストリームの伝送ネットワークへ転送するように、構成することもできる。この場合、メディエーションタスクは、このように生成された入力メッセージを記録したログに関する問い合わせ（クエリー）のサービスを提供する。

伝送プロキシ（ＴＰ）は、伝送プロキシモジュールを内部に組み込んでいるネットワークノードである。伝送プロキシモジュールは、１つ以上のＭノードから出力されたメッセージを分析し、登録された関心の表明に基づいて、どのシンクへ送信メッセージを転送するかを決定し、各メディエータに関連付けられるダウンストリームネットワーク上のメッセージを転送する。

後で詳細に説明する通り、本発明の好ましい実施形態は、ネットワークモジュール（ノード）に加えて、自律的コントロールプレインを備える。自律的コントロールプレインにより、システムの自律的な制御が可能となる。

アップストリームネットワーク（ソースからメディエータルータまで）は、メディエーションの機能を有するが、コンテンツベースではない。メディエータルータとメディエータとの間におけるルーティングは、いわゆるクロスストリームネットワークにあり、コンテンツベースである。ダウンストリームネットワークもコンテンツベースのルーティングを要求する。実際のところ、メディエータルータとＬＰＰとの間におけるルーティングは、それ自体複合的なコンテンツベースのメッセージ転送機構と見なすことができる。この複合モデルの一部分としてメッセージ空間を分割することで、拡張可能でない集中メディエーションノードにおける障害を発生させることなく、発行・購読モデルに対してミッドストリーム（ｍｉｄ−ｓｔｒｅａｍ）メディエーションサービスを導入することができる。

「静止している」あるいは「定常状態にある」システムに対しては、分散メディエーションネットワークに関する以下の記述は常に成立する。これらの記述は、分散メディエーション構造が有する「全体的な不変条件」と考えられる。

・全てのノードは、「ＬＰＰ−＞ＭＲ−＞Ｍ−＞ＴＰ−＞ＬＰＰ」サイクルの一部分である。
・全てのＬＰＰは、一のＭＲを常に指定する。
・全てのＭＲは、任意の数のＭを指定することができる。
・全てのＭは、一のＴＲを常に指定する。
・全てのＴＰは、任意の数のＬＰＰを指定することができる。
ここで、記号「−＞」は、一方向への接続（方向付きエッジ）を表す。

上記の「全体的な不変条件」を検討することで、なぜ、図３に例示したネットワークが最小限の分散メディエーショントポロジーであるかは自明である。このネットワークは、メディエーションが分散される２つのＭと、１つのＬＰＰと、１つのＭＲと、１つのＴＰとから構成される。また、「ＬＰＰ−＞ＭＲ−＞Ｍ−＞ＴＰ−＞ＬＰＰ」のようにノードが一方向に沿って接続された単純なサイクルとして、全ノードが構成されている。

より現実的かつ複雑な分散メディエーションネットワークを、図４に示す。以降「キュービックな（ｃｕｂｉｃ）」ネットワークとして知られるこのネットワーク構成には、４種類のノードが２つずつ含まれる。キュービックなネットワークは、一般的な分散メディエーションネットワークの特性をより詳細に例示する。

循環（ｃｙｃｌｉｃ）ネットワークにおいて、接続されたノード間のメッセージフローは一方通行である。キュービックなネットワークにおける全てのノードは、少なくとも１つのサイクル「ＬＰＰ−＞ＭＲ−＞Ｍ−＞ＴＰ−＞ＬＰＰ」を構成するコンポーネントである。キュービックなネットワークは、「ファンイン／ファンアウト（ｆａｎ ｉｎ／ｆａｎ ｏｕｔ）」トポロジーを示す。すなわち、「ファンイン（ｆａｎ−ｉｎ）」トポロジーにおいては、全てのＬＰＰは、メッセージを唯一のＭＲへ送信すると共に、各ＭＲは複数のＬＰＰ（図４においては、２つのＬＰＰが存在する。）からメッセージが送信される。また、「ファンアウト（ｆａｎ−ｏｕｔ）」トポロジーにおいては、全てのＭＲは、メッセージを任意のＭへ送信する。また、「ファンイン（ｆａｎ−ｉｎ）」トポロジーにおいては、全てのＭは、受信した任意のメッセージを唯一のＴＰへ送信すると共に、各ＴＰは、複数のＭからメッセージが転送される。最後に、「ファンアウト（ｆａｎ−ｏｕｔ）」トポロジーにおいては、全てのＴＰは、メッセージを任意のＬＰＰへ送信する。

また、最小限の循環ネットワーク及びキュービックなネットワークのような分散メディエーションネットワークは、他にも重要な特性を示す。ネットワーク内の全てのノードから他のノードへは方向付き経路が存在している。グラフ理論の用語を用いると、全てのノードから他の全てのノードへの推移閉包が常に存在すると言える。この特性が循環ネットワークに当てはまることは自明である。しかしながら、この特性は、「全体的な不変条件」が持つ特性の帰結として、より複雑な分散メディエーションネットワークにも当てはまる。方向付き経路は、方向付き循環グラフと常に見なすことができる。このように、一般化された分散メディエーションネットワーク内の任意の２つのノードＡ及びノードＢに対して、ノードＡからノードＢを経由してノードＡへ至るサイクルが常に存在する。ここで、キュービックな（単一のレベルの）ネットワークにおいて、そのようなサイクルの最大経路長は４ではなく８であることに留意するべきである。

さらに、各ノードは、全体への依存性も、当該ノードの直近の領域を除くネットワーク全体に関する詳細な知識も有していない。各ノードは、自身が直接指定するノードに関する情報のみを記憶する。また、ノードは、ネットワーク内の各ノードを指定するノード全体に関する情報を記憶する。この情報は、ノード自身における参照カウント値として記憶されるか、当該ノードを直接指定する全てのノードにおけるクレジットバランス（ｃｒｅｄｉｔ ｂａｌａｎｃｅ）値として記憶されることもできる。いずれの場合も、他ノードの指定を行うノードに関する情報は記憶される必要はない。実際のところ、全てのノードは、残りのシステム全体に関するあらゆる追加情報も記憶する必要がない。

本発明に係る分散メディエーションネットワークのさらに重要な特性は、動作が決定論的であり、各ノード内における動作の順序が確定していることにある。すなわち、メッセージＡの後に到着するメッセージＢは、メッセージＡの後に転送されることが保証される。同様に、複数のメッセージは、ノード間の直接的なリンク上で互いに追い越すことはない。従って、任意の２つのノードＮ１及びノードＮ２に対して、Ｎ２がＮ１によって指定される場合、メッセージＡがＮ１からＮ２へ送信され、続いてメッセージＢがＮ１からＮ２へ送信されると、Ｎ２はメッセージＢを受信する前に常にメッセージＡを受信することになる。

分散メディエーションネットワークアプリケーション
アプリケーションＡは、メッセージ指向パラダイム（ｍｅｓｓａｇｅ ｏｒｉｅｎｔｅｄ ｐａｒａｄｉｇｍ）に基づいて構成されている。Ａは、セットＭから抽出される、部分的に配列された一連のメッセージｍ１，ｍ２，ｍ３，…を受信し、追加メッセージを生成することで応答する。アプリケーションＡの観測可能な動作（以下、ｏｂｓ（Ａ）によって表す。）は、特定の入力シーケンスから生成された全ての可能な出力シーケンスのセットとして、定義される。

そのようなアプリケーションが、分散メディエーションネットワークによって提供される利点を享受するためには、以下の原則に従わなければならない。
− アプリケーションは、１セットの、各々が独立して動作するアプリケーションコンポーネント｛Ａ_i｝として並行して存在しなければならないが、結果として生じる出力メッセージの全てを任意にインターリーブ（ｉｎｔｅｒｌｅａｖｅｄ）することで、｛Ａ_i｝の観測可能な動作がＡの観測可能な動作と等しくなる。

− 全ての入力メッセージのセットＭは、ｓｅｇｍｅｎｔ関数（Ｍ−＞Ｓ）に従って、１セットのメッセージセグメント｛Ｓ_j｝に分割されなければならない。
− ｍｅｄｉａｔｅｓ関数（Ｓ−＞Ａ）が、メッセージセグメントとアプリケーションコンポーネントとの間に存在する。すなわち、各メッセージセグメントは、正確に１つのアプリケーションコンポーネントへ対応する、
− 一連のメッセージｍ１、ｍ２、ｍ３、…に対する応答である、全てのアプリケーションコンポーネントの総体ΣＡ_iの観測可能な動作（ここで、それぞれのコンポーネントＡ_iには、ｍｅｄｉａｔｅｓ関数及びｓｅｇｍｅｎｔ関数に従って、入力ストリームからフィルターにかけられたメッセージのみが通過する。）は、入力ストリーム全体を受信した際のＡの観測可能な動作と正確に同一である。

さらに、上記の制約条件が存在する場合には、分散メディエーションネットワークによって提供されたロードバランシング機能を登録するために、以下の２つの副次的メソッド（ｓｉｄｅ−ｅｆｆｅｃｔｉｎｇ ｍｅｔｈｏｄｓ）がアプリケーションコンポーネントＡ_iのインスタンスに追加される必要である。

− ｇａｉｎＳｅｇｍｅｎｔ（ｓｅｇＤｅｓｃｒｉｐｔｏｒ，ｄａｔａ）関数
− ｌｏｓｅＳｅｇｍｅｎｔ（ｓｅｇＤｅｓｃｒｉｐｔｏｒ−＞ｄａｔａ）関数
任意の２つのアプリケーションコンポーネントＡ₁、Ａ₂及び任意のセグメントｓに対して、ｍｅｄｉａｔｅｓ（ｓ）＝Ａ₂の条件下におけるｏｂｓ（Ａ₁＋Ａ₂）は、ｍｅｄｉａｔｅｓ（ｓ）＝Ａ₁の条件下におけるｏｂｓ（Ａ₁．ｇａｉｎＳｅｇｍｅｎｔ（ｓ，ｄ）＋Ａ₂．ｌｏｓｅＳｅｇｍｅｎｔ（ｓ））と同等である。ここで、ｄはＡ₂．ｌｏｓｅＳｅｇｍｅｎｔ（ｓ）の結果を表す。

自律的コントロールプレイン
本発明に係る分散メディエーション構造は、自律的に機能するように設計されている。すなわち、本システムは、最適化に関するユーザ入力やユーザが有する知識を必要としないで、自身を現時点での要求に従って最適化する。特に、自律的システムは、利用可能なコンポーネントにかかる負荷が効果的に分散されることを保証し、これにより、システムにおけるデータの取り扱いにおける不必要な障害を回避する措置を取る。

本発明において、自律的機能は、自律的コントロールプレインによって提供される。図５に示す通り、自律的コントロールプレインは、メディエーションサービス、分散メディエーションネットワーク及び基礎的なリソース（仮想のリソースあるいは現実のリソースのいずれか）を管理する。各ネットワークノードは、自律的コントロールプレインに対して管理された要素として自分自身を表す。管理された要素は、センサインターフェース及びエフェクタインターフェースの両方をサポートする。センサインターフェースは、指定された測定基準（ｍｅｔｒｉｃｓ）を発信し、これにより、自律的マネージャは、管理された要素の属性を監視することができる。エフェクタインターフェースは、自律的マネージャから、管理された要素の動作を変更するための指定された処理方法を受信する。そのため、各センサインターフェース及び各エフェクタインターフェースは、センサインターフェースでは管理された要素から自律的マネージャへ、エフェクタインターフェースでは自律的マネージャから管理された要素へ情報が一方向に流れることを可能にする。好ましい実施形態においては、図６に示す通り、自律的コントロールプレインは、１つの階層的なセットの自律的マネージャから成る。

図６に示す例では、それぞれのタイプのネットワークノード（ＬＰＰ、ＭＲ、ＭおよびＴＰ）に対して一つの自律的マネージャが存在する。この階層的レベルにおけるマネージャは、クラウドマネージャと呼ばれる。それぞれのクラウドマネージャは、特定のロードバランシング機能を担当する。好ましい実施形態において、それぞれのクラウドマネージャは、それ自身がピアツーピアネットワークにわたって分散されており、それぞれのクラウドマネージャが担当するタイプのそれぞれのネットワークモジュールからセンサイベントを受信する。

次の階層レベルにおいては、全体的な分散メディエーションネットワーク（ＤＭＮ）マネージャ６２０が、クラウドマネージャの制御を担当し、これにより、クラウドマネージャが一貫した単位（ｃｏｈｅｒｅｎｔ ｕｎｉｔ）として動作することを保証している。そのため、クラウドマネージャは、ＤＭＮマネージャ６２０の管理された要素と言える。ＤＭＮマネージャ６２０は、各クラウドマネージャが利用可能なリソースは、関連するロードバランシングの処理（タスク）を実行するために十分であることを保証する義務がある。一方、クラウドマネージャは、クラウドマネージャが現在要求していないあらゆるリソースの制御を解放する義務がある。ＤＭＮマネージャ６２０は、クラウドマネージャ間のあらゆるリソースの衝突を解決する。

図６に示す例において、ＭＲクラウド自律的マネージャ６１２は、ＭＲがネットワークトラフィックによって過負荷とならないことを保証するために、アップストリームのロードバランシングを担当する。ＭＲクラウドマネージャ６１２は、ネットワーク内のＭＲの数を増減することができ、ＭＲを通過するスループットの平均値が指定された最適化範囲内に収まるようにする。さらに、ＭＲクラウドマネージャ６１２は、ＭＲ全体にわたるＬＰＰの分散を最適化し、これにより、個々のＭＲが過負荷とならないようにする。好ましい実施形態においては、一のＭＲから他の一のＭＲへ出力を移転するためのＬＰＰの実際の命令は、ＬＰＰクラウドマネージャ６１０によって行なわれる。

Ｍクラウド自律的マネージャ６１４は、クロスストリームのロードバランシングを担当する。そのため、Ｍクラウドマネージャ６１４は、ＭＲを通過するルーティングされたスループットを処理するための十分なＭがあることを保証する。このために、Ｍクラウドマネージャ６１４は、それぞれのＭモジュールに対する平均負荷が指定された範囲内に収まるように、Ｍの数を調整する。また、Ｍクラウドマネージャ６１４は、個々のＭが過負荷とならないように、Ｍ間でメディエーションセグメントサービスを分散することを担当する。ある範囲の条件下でこれを実行するために、Ｍクラウドマネージャ６１４は、Ｍ間でメディエーションセグメントあるいはタスクを移転することができる。これを実現するアルゴリズムについては、以下に挙げる例に基づいて、より詳細に説明する。

ＴＰクラウド自律的マネージャ６１６は、ダウンストリームのロードバランシングを担当する。そのため、ＴＰクラウドマネージャ６１６は、各ＴＰの平均スループットが指定された範囲内となることを保証し、また、個々のＴＰが過負荷とならないよう、Ｍが複数のＴＰ間で分散されることを保証する。好ましい実施形態においては、一のＴＰから他のＴＰへのＭの実際の切り替えは、Ｍクラウドマネージャ６１４へ委任される。

クラウドマネージャによって実行されるロードバランシングに関する方針は同一の基本パターンに従うが、メディエーションセグメントサービスの切り替えは次に挙げる複数の処理の組み合わせである複合的処理であることを付言しておく。その複数の処理とは、あらゆる関連する状態を移転する処理などの、セグメントのプロセスを移行する処理と、所定のメッセージの宛先（ターゲット）を決定するために各ＭＲが使用し、以前のメディエータがその間に受信したメッセージの再ルーティングを行うための、ルーティング機能を更新する処理である。次に、この理由を説明するために、Ｍクラウドマネージャの動作を以下詳細に説明する。

一般に、ロードバランシングの方針は、より高いレベルのサービス（分散メディエーションネットワークマネージャ）によって解決されるあらゆるリソースの衝突とは独立して動作することが可能である必要がある。しかしながら、各クライアントから適切なメディエーションセグメントサービスへのメッセージの因果的配信則、及び各メディエーションサービスによって生成され、関心を持っているクライアントへ送信されるメッセージの因果的配信則が、両方とも常に保証されるように、開始済みの切り替え処理が構成されなければならない。

クロスストリームのロードバランシング−メディエーションセグメントサービスの譲渡
本発明の分散メディエーション構造は、ＬＰＰノード、ＭＲノード、Ｍノード及びＴＰノードから成る任意のトポロジーに基づいている。このトポロジーのノードは、「定常状態」に関して上述した特性を有する。この前述のトポロジーは、既存の機能的コンポーネント間における動的なロードバランシングに非常に適している。

上述の通り、特定のセグメントに重い負荷が掛かっていると考えられる場合に、Ｍクラウドマネージャは、関連するメディエーションタスク（メディエーションセグメントサービス）の担当を、処理能力に余裕があるネットワーク内のマシンへ自律的に移動させることができる。また、現在ネットワーク内にあるあらゆるメッセージ又は将来受信する予定のあらゆるメッセージが、新しいＭノードへ経路が変更されることを保証するために、メディエーションタスクを譲渡する処理は、メディエーションネットワークの動的な調整を要求する。これは、新しい論理的ネットワークトポロジー内の特別なメッセージの伝達によって、すなわち、適切なマシンを介した「コーザルリップリング（ｃａｕｓａｌ ｒｉｐｐｌｉｎｇ）」によって、達成される。それによって、稼働中のシステムにおいて、メッセージ入出力の観点からシステムの観測可能な動作に影響することなく、メディエーションの変更を行うことができる。メディエーションセグメント及びメディエーションタスクは統合して単一のメディエーションアプリケーションを形成し、種々のセグメントはＭ全体にわたって分散されることを再度記載しておく。

メディエーションの変更は、根本的には、「全体的な不変条件」の特性が持つ利点によって可能となる。これにより、入力メッセージは、当該メッセージが生成されるＬＰＰにかかわらず同じメディエータへルーティングされることになる。メディエーションの変更は、実システムにおいて、一の整合性のある状態から他の整合性のある状態への変更という問題が発生するが、システムの正確さあるいは性能に悪影響を及ぼす問題は発生しない。ここで、分散メディエーションネットワークの２つの主要な機能に関して説明する必要がある。その機能とは、メッセージの伝達の機能及びメッセージの問合わせの機能である。また、メッセージの問合わせは、特に起動時の問い合わせ（ｓｔａｒｔ−ｕｐ ｑｕｅｒｉｅｓ）を指す。

先に述べた通り、Ｍクラウドマネージャは、メディエーション要求の自律的なロードバランシングを担当する。そのため、Ｍクラウドマネージャは、（十分なリソースが利用可能であれば、）新しいＭをシステムに導入することができ、個々のＭが過負荷とならないようにセグメントをＭ間に分散することができる。

さらに、Ｍクラウドマネージャは、所定のメディエーションサービスから、メディエーションセグメントを追加及び削除することができる。例えば、Ｍクラウドマネージャは、新しいメディエーションセグメントを担当することができる適切なＭを特定することができる。

例えば、毎秒１５個のリクエストを発行している１０個のクライアントが、２つのＬＰＰ（以下、ｌｐｐ１及びｌｐｐ２とする。）にそれぞれ属しているシステムを仮定する。さらに、それらのリクエストは、３種の別個のセグメント（以下、ｓ１、ｓ２及びｓ３とする。）に均等に関連付けられている。毎秒３００個のリクエストから成るアップストリームのトラフィック合計は、ｌｐｐ１とｌｐｐ２との間で均等に分担される。その結果として生成される毎秒３００個のリクエストから成るクロスストリームのトラフィックは、（この単純な例においては、）２つのＭＲ（以下、ｍｒ１及びｍｒ２とする。）の間で均等に分担され、セグメントｓ１、ｓ２及びｓ３の間で均等に（それぞれのセグメントに対して毎秒１００個のリクエストの速度で）分担される。

先に述べた通り、メディエータは、トラフィックをセグメントの種類に応じて取り扱う。この例においては、２つのメディエータ（以下、ｍ１及びｍ２とする。）は、それぞれが毎秒２００個のリクエストを処理することができる。そのため、ｍ１がセグメントｓ１のトラフィックをメディエートし、ｍ２が残りのトラフィック（セグメントｓ２及びセグメントｓ３）をメディエートするシナリオが考えられる。この場合、明らかに、ｍ１にかかる負荷は毎秒１００個のリクエストになり、ｍ２にかかる負荷は毎秒２００個のリクエストになる。

ここに挙げたシンプルな例において、メディエーションサービスは、トラフィックの現在状況をダウンストリームネットワーク上へ伝送する。また、ＴＰであるｔｐ１はｍ１に関連付けられており、ＴＰであるｔｐ２はｍ２に関連付けられている。その結果、ｔｐ１には毎秒１００個のアップデートが供給されることになり、ｔｐ２には毎秒２００個のアップデートが供給されることになる。これらのアップデートは、次にｌｐｐ１及びｌｐｐ２へ渡され、ｌｐｐ１及びｌｐｐ２のそれぞれがｔｐ１及びｔｐ２から合わせて毎秒３００個のアップデートを受信することになる。この毎秒３００個のアップデートは、システムのクライアントによって受信されるアップデートの総量を表わしている。

上記の例のシステムが動作する条件を変更した場合を考える。例えば、セグメントｓ２に対するクライアントの関心が上昇し、セグメントｓ１に対するクライアントの関心が低下すると、各セグメントに対する各クライアントからのリクエストの数の変化に、これらの関心の増減が反映される。例えば、各クライアントは、ｓ１に関連する毎秒３個のリクエストと、ｓ２に関連する毎秒７個のリクエストを伝送すると仮定する。システムにおけるｓ１及びｓ２に関連するリクエストの数の合計は、同じ（毎秒２００個）であるが、今回の場合、ｓ１に関連するリクエストは毎秒６０個のみであり、ｓ２に関連するリクエストは毎秒１４０個である。従って、ｍ１に係る負荷は毎秒６０個のリクエストのみであるが、ｍ２にかかる負荷は毎秒２４０個のリクエストであり、負荷が増加している。しかしながら、先に述べた通り、ｍ２には毎秒２００個のリクエストという処理能力の制限がある。

従って、Ｍクラウドマネージャは、ｍ１及びｍ２に対して処理可能な負荷量より大きな負荷が掛からないように、自律的に作用して状況を修正することが要求される。この例において、Ｍクラウドマネージャは、セグメントｓ３の処理の担当をｍ２からｍ１へ切り替えるように作用する。一旦この切り替えが行われると、ｍ１及びｍ２上の全体的な負荷は、それぞれ毎秒１６０個のリクエスト及び毎秒１４０個のリクエストとなる。また、ｓ２の処理の担当をｍ１へ移転した場合も、Ｍ上の負荷は許容範囲内に収まるが、この場合ｍ１は最大限の処理能力で動作する必要がある。

一のＭから他のＭへのセグメントの移行は、因果的配信則が維持される方法で、かつ分散メディエーションネットワークに対する変更が外部から見えないような方法で、処理されなければならない。

システムが第１の整合状態ＰＳ１にある時刻から、新しい整合状態ＰＳ２にある時刻へ状態が推移する場合について考える。時間ｔ₀において、新しい状態ＰＳ２へと変化するプロセスが始まる。この後、ある未知の時間ｔ₁において、新しい整合状態ＰＳ２への変化が完了したことを、システムが認識する。実際の変更が起きた時間ｔ_bは不明であるが、時間ｔ_bは時間ｔ₀と時間ｔ₁の間にある。

時間ｔ₀と時間ｔ₁の間においては、システムは不安定な状態にあると定義され、メディエーションタスクが現在動作している箇所が、全体的には認識されていないことを意味している。しかしながら、それぞれの箇所において、情報のフローを正確に処理するために十分に局所的な知識が利用可能であるので、システムの各機能は影響を受けない。

当初、メディエータｍ１がセグメントｓ１をメディエートして、メディエータｍ２がセグメントｓ２及びｓ３をメディエートしている上記の例を考える。次に、ユーザの観点から見てメディエーションサービスを中断することなく、全ての３つのセグメント（ｓ１、ｓ２及びｓ３）のメディエーションのロードバランシングを実行するために、セグメントｓ３に対して、ｍ２からｍ１へメディエーションサービスのホットな移行（ｈｏｔ ｍｉｇｒａｔｉｏｎ）あるいはホットな譲渡（ｈｏｔ ｈａｎｄｏｖｅｒ）を可能にするアルゴリズムについて、詳細に説明する。

図７Ａ乃至図７Ｆは、メディエーション変更サイクルを例示している。図７Ａに示す通り、メディエーション変更サイクルは、Ｍクラウドマネージャがメディエータｍ２に対するＨＡＮＤＯＶＥＲ＿ＳＥＧＭＥＮＴ（ｓ３）エフェクタメソッドを呼び出すことで、セグメントｓ３をメディエータｍ１へ譲渡するように指示することから開始される。その結果、メディエータｍ２はＨＡＮＤＯＶＥＲ＿ＳＥＮＤＥＲ（ｓ３）状態に入る。この状態において、メディエータｍ２は、バッファリングされた、セグメントｓ３に対応するあらゆるメッセージを処理する。図７Ｂに示す通り、一旦セグメントｓ３のバッファがフラッシュされると、メディエータｍ２は、ダウンストリームのＭＥＤＩＡＴＩＯＮ＿ＣＨＡＮＧＥ（ｓ３）制御メッセージを、ＴＰを介して全てのＬＰＰへ送信し、また、順番に並べられたスナップショットをＭＥＤＩＡＴＩＯＮ＿ＨＡＮＤＯＶＥＲ（ｓ３−ｓｔａｔｅ）制御メッセージの形式で、メディエータｍ１に対して送信する。この時点から、メディエータｍ２は、セグメントｓ３をメディエートすることを中止し、以降セグメントｓ３に対応するあらゆるメッセージはメディエータｍ２によってメディエータｍ１へ転送される。

メディエータｍ１は、ＭＥＤＩＡＴＩＯＮ＿ＨＡＮＤＯＶＥＲ（ｓ３−ｓｔａｔｅ）制御メッセージを受信すると、ＨＡＮＤＯＶＥＲ＿ＲＥＣＥＩＶＥＲ（ｓ３）状態に入り、受信された状態情報を用いて、セグメントｓ３に対するメディエーションサービスを開始する。次に、図７Ｃに示すように、メディエータｍ１は、ダウンストリームのＮＥＷ＿ＭＥＤＩＡＴＯＲ（ｓ３）制御メッセージを、ＴＰを介して全てのＬＰＰへ送信する。

ＮＥＷ＿ＭＥＤＩＡＴＯＲ（ｓ３）及びＭＥＤＩＡＴＩＯＮ＿ＣＨＡＮＧＥ（ｓ３）制御メッセージは、セグメントｓ３に関連するメディエーションタスクの出力のクライアントに対する因果的配信則を保証するために用いられる。特に、以前のメディエータ（ｍ２）からのダウンストリームメッセージは、新しいメディエータ（ｍ１）からのものよりも前にクライアントへ配送されなければならない。これを保証するために、ＮＥＷ＿ＭＥＤＩＡＴＯＲ（ｓ３）制御メッセージが、対応するＭＥＤＩＡＴＩＯＮ＿ＣＨＡＮＧＥ（ｓ３）制御メッセージの前に受信される場合には、ＬＰＰによって新しいメディエータから受信されたｓ３メッセージがバッファリングされる。

同様に、メディエータｍ１はＨＡＮＤＯＶＥＲ＿ＲＥＣＥＩＶＥＲ（ｓ３）状態に入ると直ちに、各ＭＲから直接的に受信したあらゆるｓ３メッセージを、その各ＭＲから発信された未処理のｓ３メッセージがメディエータｍ２から再ルーティングされなくなることが確定するまで、バッファリングし始める。

これを実現するためには、メディエータｍ１は、コントロールプレインを介してＭクラウドマネージャと相互作用する必要がある。従って、メディエータｍ１は、ＨＡＮＤＯＶＥＲ＿ＲＥＣＥＩＶＥＲ（ｓ３）状態に入ると、センサイベントを発信することによって、この状態変更をＭクラウドマネージャへ知らせる。

図７Ｄに示すように、Ｍクラウドマネージャがこのイベントを受信すると、ＭＲクラウドマネージャのエフェクタを呼び出し、ＭＲに対するルーティングテーブルを更新するよう命令する。ＭＲクラウドマネージャは、それぞれのＭＲにＵＰＤＡＴＥ＿ＲＯＵＴＩＮＧ＿ＴＡＢＬＥ（ｓ３，ｍ２−＞ｍ１）制御メッセージを送信する。この場合では、ＭクラウドマネージャはＭＲクラウドマネージャと直接通信しているが、他の実施形態においてはこの通信を他の方法で行うこともできる。例えば、より厳密な階層構造を有する実施形態においては、ＤＭＮマネージャを介して通信することもできる。（例えば、Ｍクラウドマネージャが、ＤＭＮマネージャによって選択されるセンサイベントを送出し、次いでＭＲクラウドマネージャのエフェクタメソッドを呼び出すこともできる。）いくつかの実施形態においては、クラウドマネージャ間で直接通信することができない場合もありうる。一般的に、以下に説明する全ての場合において、クラウドマネージャ間の通信は互いに直接的に、あるいはＤＭＮマネージャを介して行われることが意図される。

ＭＲは、ルーティングテーブルを更新すると、ＲＴ＿ＣＨＡＮＧＥＤ（ＭＲ−ｉｄ，ｓ３）制御メッセージをメディエータｍ２へ送信し、以降の全てのｓ３メッセージをメディエータｍ１へと送信する。図７Ｅに示すように、このＲＴ＿ＣＨＡＮＧＥＤ制御メッセージはメディエータｍ２からメディエータｍ１へ転送される。これは、この特定のＭＲから直接転送されたセグメントｓ３に対応するあらゆるバッファリングされたメッセージをフラッシュするための、メディエータｍ１に対するトリガーとなる。また、あらゆるバッファリングされたメッセージがいったんフラッシュされると、メディエータｍ１はＲＴ＿ＣＨＡＮＧＥＤセンサイベントを発信し、コントロールプレインを介して、この特定のＭＲの更新が成功したことをＭＲクラウドマネージャに通知する。

ＭＲクラウドマネージャが新しいメディエータｍ１を介して全てのＭＲから確認（ＡＣＫ）を受信した場合には、メディエーション変更プロセスは有効に完了している。図７Ｆに示すように、この時点で、ＭＲクラウドマネージャは、全てのＭＲを更新したことを、コントロールプレインを介してＭクラウドマネージャに通知することができる。また、Ｍクラウドマネージャは、セグメントｓ３に対するメディエーション変更が、メディエータｍ１及びメディエータｍ２が共にＳＴＡＢＬＥ（ｓ３）状態へ戻ることができる時点で完了していることを、メディエータｍ１及びメディエータｍ２に対して通知することができる。

クロスストリームの拡張及び縮小
当業者には自明のことであるが、同様の手法を、要求に応じて（オンデマンドに）Ｍノードをシステムに追加、あるいはシステムから削除するために利用することができる。Ｍノードを追加する操作を完了するためには、要求されるリソースを取得する作業と、空のＭノードを生成してＴＰに接続する作業と、時間経過に伴ってＭノードにセグメントを追加する作業とを行う。２つのＭモードを「キュービックな」分散メディエーションモデルへ追加した結果を、図８に例示する。一方、Ｍノードを削除する操作を完了するためには、最初に全てのセグメントを他のＭノードへ移行する作業と、その後にＭノードをＴＰから切断する作業と、Ｍノードを停止してＭノードに関連するリソースを解放する作業とを行う。

アップストリームにおけるロードバランシング−メディエーションルータの切り替え
図９に、分散メディエーションネットワークの他の例を示す。図９に示すネットワークは、図４に示す「キュービックな」ネットワークとトポロジー的に等価である。この図で示されたレイアウトを以下、「円筒状の」レイアウトと呼ぶことにする。このタイプの図においては、各ＬＰＰは、例示したネットワーク伝送路の始点と終点との両方において、計２回図示されている。円筒状のレイアウトは、分散メディエーションネットワーク内に存在するロードバランシングの機会を効果的に示す。

上述した通り、クロスストリームのロードバランシングは、各Ｍノードにおける負荷が許容範囲内に収まることを保証する。そのため、目標は、任意のＭノードを通るトラフィックが適切な高水位線と低水位線の間に収まることと、Ｍノードのセットが取り扱う全体的な作業の負荷も、同様に許容可能な高水位線と低水位線の間に収まることとを保証することである。トラフィックのレベルはＭノードに対するメディエーションセグメントサービスの分散によって決定されるので、一のＭノードから他のＭノードへ、メディエーションセグメントサービスを移行あるいは譲渡する手法が提供される。

アップストリームにおけるロードバランシングの場合は以下のようにまとめることができる。目標は、任意のＭノードを通るトラフィックが適切な高水位線と低水位線の間に収まることと、Ｍノードのセットが取り扱う全体的な作業の負荷も、同様に許容可能な高水位線と低水位線の間に収まることとを保証することである。任意のＭＲノードを通るトラフィックは、そのＭＲノードと接続しているＬＰＰノードによって生成されるスループットによって決定されるので、ＬＰＰノードの出力を一のＭＲノードから他のＭＲノードへ切り替える機能は、任意のＭＲノードにかかる負荷を管理する際に肝要である。トラフィックが軽い場合には、ＭＲノード間でＬＰＰノードを切り替えることで、ＭＲノードは複数のＬＰＰノードに対してサービスを提供することができる。これは、例えば、専用のＭＲノードが各ＬＰＰノードに常に割り当てられている固定的なシステムと比較して、効率面において著しく優位である。

図１０Ａは、２つのＭＲノードによってサービスが提供される４つのＬＰＰノードと、２つのＴＰノードによってサービスが提供される４つのＭノードとから成る、拡張された円筒状のレイアウトを示す。図１０Ａにおけるノード間の矢印は、ネットワークトラフィックの初期状態のフローを表わしている。これを開始時点として、ｍｒ１に過大な負荷がかかる可能性がある大量のスループットをｌｐｐ１が生成し始める場合について考える。次に、２つのＭＲノードを通過するアップストリームトラフィックをロードバランシングするために、ｌｐｐ２がｍｒ２へホットスイッチング（サービス稼働中での切り替え、ｈｏｔ ｓｗｉｔｃｈｉｎｇ）する作業を可能にするためのアルゴリズムについて詳細に説明する。

図１０Ｂ乃至図１０Ｅは、ＬＰＰスイッチオーバー（切り替え）サイクルを例示している。図１０Ｂに示すように、スイッチオーバーサイクルは、ＬＰＰクラウドマネージャによって開始され、ＬＰＰクラウドマネージャは、ノードｌｐｐ２に対するＳＷＩＴＣＨ＿ＭＲ（ｍｒ２）エフェクタメソッドを呼び出して、現在のＭＲノードｍｒ１からノードｍｒ２への切り替えを命令する。この時点で、ＬＰＰノードｌｐｐ２はＳＷＩＴＣＨＯＶＥＲ（ｍｒ２）状態に移行する。

図１０Ｃに示すように、ｌｐｐ２はＭＲ＿ＣＨＡＮＧＥ（ｌｐｐ２）制御メッセージをｍｒ１へ送信することによって応答する。ｍｒ１は、ルーティングテーブルにおける各セグメントｓ＜ｉ＞に対応する適切なメディエータへＭＲ＿ＣＨＡＮＧＥ（ｌｐｐ２，ｓ＜ｉ＞）制御メッセージを送信し、同時にＭＲ＿ＣＨＡＮＧＥ（ｌｐｐ２，ｓ＜ｉ＞）センサイベントを発信することによって、応答する。ＭＲ＿ＣＨＡＮＧＥ（ｌｐｐ２，ｓ＜ｉ＞）センサイベントは、ＭＲクラウドマネージャによって検出され、Ｍクラウドマネージャがアクセス可能な共有データ空間に記憶されている。いくつかの他の実施形態においては、各ＬＰＰは、「アクティブな（ａｃｔｉｖｅ）」セグメントのリストを維持し、ｍｒ１によってルーティングされる、これらのセグメントに対するＭＲ＿ＣＨＡＮＧＥ（ｌｐｐ２，ｓ＜ｉ＞）制御メッセージを生成することもできる。しかしながら、そのような変形例では、それ以外の場合では要求されないＬＰＰにおける状態情報を維持する必要がある。

図１０Ｄに示すように、その後、ｌｐｐ２は新しいＭＲノードｍｒ２へ切り替えて、ｍｒ２に対してＮＥＷ＿ＭＲ（ｌｐｐ２）制御メッセージを送信する。上記の作業により、適切なＭノードへ伝送される、ルーティングテーブルにおけるそれぞれのセグメントｓ＜ｉ＞に対するＮＥＷ＿ＭＲ（ｌｐｐ２，ｓ＜ｉ＞）制御メッセージが生成される。

Ｍノードによって受信されたＮＥＷ＿ＭＲ（ｌｐｐ２，ｓ＜ｉ＞）及びＭＲ＿ＣＨＡＮＧＥ（ｌｐｐ２，ｓ＜ｉ＞）制御メッセージは、適切なセグメントサービスによって、クロスストリームメッセージの因果的処理（ｃａｕｓａｌ ｐｒｏｃｅｓｓｉｎｇ）を保証するために用いられる。特に、ｌｐｐ２によって以前のメディエーションルータ（ｍｒ１）を介して送信されたアップストリームメッセージは、新しいメディエーションルータ（ｍｒ２）を介して送信されたメッセージの前に処理されなければならない。

これを保証するために、ｌｐｐ２から発信され、新しいメディエーションルータを経由してメディエータが受信した全てのｓ＜ｉ＞メッセージは、ＮＥＷ＿ＭＲ（ｌｐｐ２，ｓ＜ｉ＞）制御メッセージが対応するＭＲ＿ＣＨＡＮＧＥ（ｌｐｐ２，ｓ＜ｉ＞）制御メッセージの前に受信される場合には、バッファリングされる。このバッファリング処理は、上述したクロスストリームにおけるロードバランシングにおいて新しいメディエータ（ｍ２）が行ったバッファリング処理と類似している。しかし、アップストリームにおけるロードバランシングでは、ＬＰＰノードから発信されたメッセージがバッファリングされ、クロスストリームにおけるロードバランシングでは、ＭＲノードから発信されたメッセージがバッファリングされる。

図１０Ｅに示すように、両方の制御メッセージ（ＮＥＷ＿ＭＲ及びＭＲ＿ＣＨＡＮＧＥ）が受信された後に、あらゆるバッファがフラッシュされると、ＮＥＷ＿ＭＲ（ｌｐｐ２，ｓ＜ｉ＞）センサイベントが、関連するＭノードによって検出されると共に、Ｍクラウドマネージャによって検出される。先に記憶されたＭＲ＿ＣＨＡＮＧＥセンサイベントに対応する全てのＮＥＷ＿ＭＲセンサイベントが検出されると、ＭクラウドマネージャはＬＰＰクラウドマネージャに、スイッチオーバーサイクルが完了し、結果として、ｌｐｐ２をＳＴＡＢＬＥ（ｍｒ２）状態へ切り替えるためのエフェクタメソッドを、ＬＰＰクラウドマネージャが呼び出すことを通知する。

最適化された安定性を確保するために、本発明に係るいくつかの実施形態で想定されることは、ＬＰＰクラウドマネージャとＭクラウドマネージャとの間の通信は、全てのＭノードがＳＴＡＢＬＥ状態であったときにのみＭＲノード間におけるＬＰＰノードの切り替えが開始されることと、ＬＰＰノードがＳＷＩＴＣＨＯＶＥＲ状態である間はＭノード間におけるセグメントの譲渡が開始されないこととを保証することができることである。

ダウンストリームにおけるロードバランシング−伝送プロキシの切り替え
ダウンストリームにおけるロードバランシングは、上述したアップストリームにおけるロードバランシングの繰り返しであり、以下のように要約できる。目標は、任意のＴＰノードを通るトラフィックが適切な高水位線と低水位線の間に収まることと、ＴＰノードのセットが取り扱う全体的な作業の負荷も、同様に許容可能な高水位線と低水位線の間に収まることとを保証することである。任意のＴＰノードを通るトラフィックは、そのＴＰノードと接続しているＭノードによって生成されるスループットによって決定されるので、Ｍノードの出力を一のＴＰノードから他のＴＰノードへ切り替える能力は肝要である。トラフィックが軽い場合には、ＴＰノード間でＭノードを切り替えることで、ＴＰノードは複数のＭノードに対してサービスすることができる。これは、例えば、専用のＴＰノードが各Ｍノードに常に割り当てられている固定的なシステムと比較して、効率面において著しく優位である。

アップストリームにおけるロードバランシングに関して上述した図１０Ａに示す分散メディエーションネットワークを開始時点として、ｔｐ１に過大な負荷がかかる可能性がある大量のスループットをｍ１が生成し始める場合について考える。次に、２つのＴＰノードを通過するダウンストリームトラフィックをロードバランスするために、ｍ２がｔｐ２へホットスイッチングする作業を可能にするためのアルゴリズムについて詳細に説明する。

図１１Ａ乃至図１１Ｄは、Ｍノードのスイッチオーバーサイクルを例示している。図１１Ａに示すように、スイッチオーバーサイクルは、Ｍクラウドマネージャによって開始される。Ｍクラウドマネージャは、ノードｍ２に対するＳＷＩＴＣＨ＿ＴＰ（ｔｐ２）エフェクタメソッドを呼び出して、現在のＴＰノードｔｐ１からノードｔｐ２への切り替えを命令する。この時点で、Ｍノードｍ２はＳＷＩＴＣＨＯＶＥＲ（ｔｐ２）状態に移行する。

図１１Ｂに示すように、ｍ２は、自身が担当するアクティブな各セグメントｓ＜ｉ＞に対して、ＴＰ＿ＣＨＡＮＧＥ（ｍ２，ｓ＜ｉ＞）制御メッセージをｔｐ１へ送信することによって応答する。ｔｐ１ノードは、この制御メッセージを全てのＬＰＰノードに一括送信すると同時に、各ＬＰＰノードに対応するＴＰ＿ＣＨＡＮＧＥ（ｍ２，ｌｐｐ＜ｊ＞，ｓ＜ｉ＞）センサイベントを発信する。このセンサイベントは、ＴＰクラウドマネージャによって検出され、ＬＰＰクラウドマネージャがアクセス可能な共有データ空間に記憶されている。

図１１Ｃに示すように、その後、ｍ２は新しいＴＰノードｔｐ２へ切り替えて、自身が担当するアクティブな各セグメントｓ＜ｉ＞に対して、ＮＥＷ＿ＴＰ（ｍ２，ｓ＜ｉ＞）制御メッセージをｔｐ２へ送信する。ｔｐ２ノードはこのメッセージを全てのＬＰＰノードへ一括送信する。

ＮＥＷ＿ＴＰ（ｍ２，ｓ＜ｉ＞）及びＴＰ＿ＣＨＡＮＧＥ（ｍ２，ｓ＜ｉ＞）制御メッセージは、適切なセグメントサービスによって、ダウンストリームメッセージの因果的処理（ｃａｕｓａｌ ｐｒｏｃｅｓｓｉｎｇ）を保証するために用いられる。特に、ｍ２によって以前の伝送プロキシ（ｔｐ１）を介して送信されたダウンストリームメッセージは、新しい伝送プロキシ（ｔｐ２）を介して送信されたメッセージの前に処理されなければならない。

これを保証するために、ｍ２から発信され、新しい伝送プロキシを経由してＬＰＰノードが受信した全てのｓ＜ｉ＞メッセージは、ＮＥＷ＿ＴＰ（ｍ２，ｓ＜ｉ＞）制御メッセージが対応するＴＰ＿ＣＨＡＮＧＥ（ｍ２，ｓ＜ｉ＞）制御メッセージの前に受信される場合には、バッファリングされる。このバッファリング処理は、セグメントの譲渡の際に、ＬＰＰモジュールが行ったバッファリング処理に類似している。異なる点は、今回の場合では、伝送プロキシ（ＴＰ）ノードではなくメディエーション（Ｍ）ノードから発信されたメッセージがバッファリングされる点である。

図１１Ｄに示すように、両方の制御メッセージ（ＮＥＷ＿ＴＰ及びＴＰ＿ＣＨＡＮＧＥ）が受信された後に、あらゆるバッファがフラッシュされると、ＮＥＷ＿ＴＰ（ｍ２，ｌｐｐ＜ｊ＞，ｓ＜ｉ＞）センサイベントが、ＬＰＰノードによって発信されると共に、Ｍクラウドマネージャによって検出される。先に記憶されたＴＰ＿ＣＨＡＮＧＥセンサイベントに対応する全てのＮＥＷ＿ＴＰセンサイベントが検出されると、ＬＰＰクラウドマネージャは、Ｍクラウドマネージャにスイッチオーバーサイクルが完了したことを通知し、Ｍクラウドマネージャは、ｍ２をＳＴＡＢＬＥ（ｔｐ２）状態へ切り替えるためにｍ２に対するエフェクタメソッドを呼び出す。

いくつかの実施形態においては、Ｍクラウドマネージャは、全てのＭノードがＳＴＡＢＬＥ状態であったときにのみ、ＴＰノード間におけるＭノードの切り替えを開始する。さらに、いずれかのＭノードがＳＷＩＴＣＨＯＶＥＲ状態である間は、メディエーションセグメントの移転を開始しないように、Ｍクラウドマネージャを設計することもできる。

アップストリーム及びダウンストリームの拡張及び縮小
当業者には自明なことであるが、必要に応じて（オンデマンドに）ＭＲノード及びＴＰノードをシステムに追加、あるいはシステムから削除するために、同様の手法を利用することができる。追加する場合には、要求されるリソースを取得し、ＭＲノードあるいはＴＰノードを生成し、１つ以上のＬＰＰノードあるいはＭノードを、生成されたＭＲノードあるいはＴＰノードにそれぞれ切り替える単純な作業を行う。

図１０及び図１１で示されるネットワークトポロジーへＭＲノード（ｍｒ３）を追加する操作と、既存のＭＲノードにかかる作業負荷が閾値を越えて全体的に増加するに応じてＬＰＰノード（ｌｐｐ４）の送信先を切り替える操作とを行った最終的な結果を図１２Ａに例示する。この図から、既存のＭＲノードにかかる作業負荷が全体的に低下した結果、負荷が閾値以下になった場合にＭＲノードを削除するためには、削除対象のＭＲノードに向かっている全てのＬＰＰノードを他のＭＲノードへ切り替えなければならないということになる。

次に、前記操作を行ったネットワークトポロジーへＴＰノード（ｔｐ３）を追加する操作と、既存のＴＰノードにかかる作業負荷が閾値を越えて全体的に増加するに応じてＭノード（ｍ４）の送信先をｔｐ３に切り替える操作とを行った最終的な結果を図１２Ｂ及び図１２Ｃに例示する。この図から、既存のＴＰノードにかかる作業負荷が全体的に低下した結果、負荷が閾値以下になった場合にＴＰノードを削除するためには、削除対象のＴＰノードに向かっている全てのＭノードを他のＴＰノードへ切り替えなければならないということになる。

最後に、４つのＬＰＰノード及び４つのＭノードを有する図１０及び図１１で示されたネットワークの最大限の構成を、図１２Ｄに示す。この図において、各ＬＰＰノードは唯一の専用のＭＲノードに接続され、また各Ｍノードは唯一の専用のＴＰノードに接続される。分散メディエーションネットワークの制約条件としては、ネットワーク上においてＭＲノードの数はＬＰＰノードの数を上回ることができない。同様に、ＴＰノードの数もＭノードの数を上回ることができない。

例外処理
アップストリーム、クロスストリーム及びダウンストリームにおけるロードバランシングでは対処できないネットワークの負荷に関する問題がいくつか存在する。これらの例外では、関連するクラウドマネージャがＤＭＮマネージャに対して対策を問い合わせる。

Ｍクラウドマネージャによる例外処理
例外：一のセグメントｓ＜ｉ＞を担当するＭノードが過負荷となる。すなわち、負荷が個々のＭノードに対する高水位線を超える。Ｍクラウドマネージャは、ＤＭＮマネージャに対してこの例外を生成する必要がある。
対策：Ｍノードの取り扱いを差別化できない限り、この例外に対する取り得る処置はない。すなわち、複数のＭノードの一部がより強力なコンピュータ上で処理を行っている場合には（例えば昨年発売されたＰＣではなく最新のマルチコアチップセットを搭載したＰＣ）、セグメントをより強力な処理能力を有するノードへ移動させるようにロードバランシングのアルゴリズムを改良することができる。そのようにしても、ある時点で、この限界的状況に再び陥ることになるだろう。
所見：この例外から理解できるように、Ｍノードの結合は脆弱であるという障害が潜在的に存在する。

ＴＰクラウドマネージャによる例外処理
例外：一のｍ＜ｊ＞ノードを担当するＴＰノードが過負荷となる。すなわち、負荷が個々のＭノードに対する高水位線を超える。ＴＰクラウドマネージャは、ＤＭＮマネージャに対してこの例外を生成する必要がある。
対策：ＴＰノード間で処理能力が異なるなど、ＴＰノードを差別化することができる場合に、ロードバランシングのアルゴリズムを改良することができる。その場合においても、ある時点で、この限界的状況に再び陥ることになるだろう。そうでない場合でも、ＤＭＮマネージャは、ｍ＜ｊ＞ノードがネットワークに過負荷をかけているとＭクラウドマネージャに通知することができる。ｍ＜ｊ＞ノードが複数のセグメントを担当している場合であれば、理論上はこれらのセグメントを再分散することができる。
所見：この例外から理解できるように、ＴＰノードの結合は脆弱であるという障害が潜在的に存在する。

ＭＲクラウドマネージャによる例外処理
例外：一のｌｐｐ＜ｋ＞ノードを担当するＭＲノードが過負荷となる。すなわち、負荷が個々のＭＲノードに対する高水位線を超える。ＭＲクラウドマネージャは、ＤＭＮマネージャに対してこの例外を生成する必要がある。
対策：ＭＲノードの取り扱いを差別化できない限り、この例外に対する取り得る処置はない。すなわち、ＭＲノード間で処理能力が異なる場合には、ロードバランシングのアルゴリズムを改良することができる。その場合においても、ある時点で、この限界的状況に再び陥ることになるだろう。
所見：この例外から理解できるように、ＭＲノードの結合は脆弱であるという障害が潜在的に存在する。

いくつかの実施形態において、個々のＬＰＰノードがＭＲノードに過大な負荷をかけていることをＤＭＮマネージャが観測した場合に、ＬＰＰノード間でユーザの再調整を行うように指示することもできる。これを達成する手法は、ユーザへ提供されているメディエーションサービスの性質に依存することになる。

図１３に示される表１は、分散メディエーションネットワーク内のノード間でネットワークトラフィックを分散する際に、自律的コントロールプレインが取る動作の概要を示している。表１は、自律的コントロールプレインが定める測定基準又は変数を示している。例えば、「Ｘ＿ＮＯＤＥ＿ＨＩＧＨ＿ＷＡＴＥＲＭＡＲＫ」は、一のＸノード（Ｘは、ＬＰＰ、ＴＰ、ＭＲ及びＭのいずれか）が処理可能なトラフィックの最大の閾値を表す。また、「Ｘ＿ＮＯＤＥ＿ＰＯＯＬ＿ＨＩＧＨ＿ＷＡＴＥＲＭＡＲＫ」は、Ｘノードのグループにかかるトラフィックのスループットの最大平均値を表す。

Claims (27)

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. 前記クラウドマネージャ間の全ての通信は前記ＤＭＮマネージャを通過しなければならない、請求項１５から２６のいずれかに記載の方法。

Images