"複数のタイプのネットワークモジュールであって、メディエーションネットワークとクライアントプログラムとの間のネットワークトラフィックを受信及び送信するローカルポイントオブプレゼンスLPPモジュールと、メディエーションタスクを担当するメディエータMモジュールと、入力メッセージのコンテンツを解析するメディエータルータMRモジュールであって、前記各MRモジュールは、前記コンテンツに応じて予め決定されたメディエーションタスクへ前記入力メッセージをルーティングする前記MRモジュールと、少なくとも1つの前記LPPモジュールへメッセージを転送する伝送プロキシTPモジュールであって、前記MRモジュール、前記Mモジュール及び前記TPモジュールの各々は、それらのモジュールを通過するネットワークトラフィックの全てのパスが非相互的であるように適合されている前記TPモジュールと、から成る前記ネットワークモジュール以下、単にモジュールと言う。と、自律的コントロールプレインと、を備え、前記自律的コントロールプレインは、前記LPPモジュールに対する切り替え動作を呼び出して、一の前記LPPモジュールから送信されるネットワークトラフィックの宛先を第1MRモジュールから第2MRモジュールへ変更する動作によって、又は、前記Mモジュールに対する切り替え動作を呼び出して、一の前記Mモジュールから送信されるネットワークトラフィックの宛先を第1TPモジュールから第2TPモジュールへ変更する動作によって、前記モジュール間におけるネットワークトラフィックの分散を管理するように適合され、及び/又は、第1Mモジュールに対する譲渡動作を呼び出して、前記第1Mモジュールから第2Mモジュールへ特定のメディエーションタスクを移転する動作によって、前記Mモジュール間におけるメディエーションタスクの分散を達成するように適合され、前記モジュールは、前記モジュールの状態を前記自律的コントロールプレインに伝達するセンサインターフェースと、前記自律的コントロールプレインからコマンドを受信するエフェクタインターフェースと、を有し、前記LPPモジュールが前記MRモジュールを指定し、次に前記MRモジュールが前記Mモジュールを指定し、次に前記Mモジュールが前記TPモジュールを指定し、次に前記TPモジュールが前記LPPモジュールを指定する一方向メディエーションサイクルに従って、ネットワークトラフィックを接続する、分散メディエーションネットワーク。前記自律的コントロールプレインは、前記各タイプのモジュールの数が制限されるように適合されている、請求項1に記載の分散メディエーションネットワーク。前記自律的コントロールプレインは、多数のリソースにわたって提供されている、請求項1または2に記載の分散メディエーションネットワーク。前記自律的コントロールプレインは、所定のタイプの前記モジュール間におけるネットワークトラフィックの分散を管理するクラウドマネージャと、前記モジュールのタイプ間におけるリソースの分散を管理する分散メディエーションネットワークDMNマネージャと、を備える階層構造を有している、請求項1から3のいずれか1項に記載の分散メディエーションネットワーク。前記クラウドマネージャは互いに直接通信することができる、請求項4に記載の分散メディエーションネットワーク。前記クラウドマネージャ間の全ての通信は前記DMNマネージャを通過しなければならない、請求項4または5に記載の分散メディエーションネットワーク。前記第1Mモジュールに対する譲渡動作を呼び出して、前記第1Mモジュールから前記第2Mモジュールへ特定のメディエーションタスクを移転する動作は、前記自律的コントロールプレインが、前記第1Mモジュールに対するHANDOVER_SEGMENTエフェクタメソッドを呼び出す動作と、前記第1Mモジュールが、HANDOVER_SEGMENTエフェクタメソッドの呼び出しを受けた後に、状態をHANDOVER_SENDER状態に変更し、前記第1Mモジュールに現在記憶されている前記特定のメディエーションタスクに関連するコンテンツを処理し、次いでMEDIATION_CHANGE制御信号を全ての前記LPPモジュールに送信する動作と、前記第1Mモジュールが、MEDIATION_HANDOVER制御信号を前記第1Mモジュールから前記第2Mモジュールへ送信し、次いで前記第1Mモジュールが受信した前記特定のメディエーションタスクに関連するコンテンツを前記第2Mモジュールへ転送する動作と、前記第2Mモジュールが、MEDIATION_HANDOVER制御信号を受信した後に、状態をHANDOVER_RECEIVER状態へ変更し、前記状態変更を示すセンサ信号を前記自律的コントロールプレインに送信し、NEW_MEDIATOR制御信号を全ての前記LPPモジュールへ送信する動作であって、NEW_MEDIATOR制御信号の受信後に受信され、MEDIATION_CHANGE制御信号の受信前に受信された前記特定のメディエーションタスクに関連するコンテンツを、前記LPPモジュールがバッファリングする動作と、前記第2MモジュールがHANDOVER_RECEIVER状態にあることを示すセンサ信号を受信した後に、前記自律的コントロールプレインが、前記MRモジュールに対するエフェクタメソッドを呼び出し、前記特定のメディエーションタスクに関連するコンテンツを前記第1Mモジュールではなく前記第2Mモジュールへ転送するように前記MRモジュールに対して命令する動作と、前記各MRモジュールが、転送されるコンテンツの宛先を前記第2Mモジュールへ変更した後に、宛先の変更を示すセンサ信号を前記自律的コントロールプレインへ発信し、前記各MRモジュールに対応するRT_CHANGED制御メッセージを前記第1Mモジュールへ転送し、次いで前記第1MモジュールがRT_CHANGED制御メッセージを前記第2Mモジュールへ転送する動作であって、前記第2Mモジュールが前記各MRモジュールから直接受信した前記特定のメディエーションタスクに関連するコンテンツを、前記各MRモジュールに対応するRT_CHANGED制御メッセージを前記第2Mモジュールが受信するまで、バッファリングする動作と、前記第2Mモジュールが、前記各MRモジュールから発信されたそれぞれのRT_CHANGED信号を前記第2Mモジュールが受信した場合に、センサ信号を前記自律的コントロールプレインに送信する動作と、前記自律的コントロールプレインが、全ての前記MRモジュールからRT_CHANGED制御信号が受信されたことを示すセンサ信号を前記第2Mモジュールから受信した場合に、前記第1Mモジュール及び前記第2Mモジュールに対するエフェクタメソッドを呼び出して前記第1Mモジュール及び前記第2MモジュールをSTABLE状態に戻す動作と、から構成されている、請求項1から6のいずれか1項に記載の分散メディエーションネットワーク。前記LPPモジュールに対する切り替え動作を呼び出して、一の前記LPPモジュールから送信されるネットワークトラフィックの宛先を前記第1MRモジュールから前記第2MRモジュールへ変更する動作は、前記自律的コントロールプレインが、前記LPPモジュールに対するSWITCH_MRエフェクタメソッドを呼び出す動作と、前記LPPモジュールが、SWITCH_MRエフェクタメソッドの呼び出しを受けた後に、状態をSWITCHOVER状態に変更し、MR_CHANGE制御信号を前記第1MRモジュールへ送信し、NEW_MR制御信号を前記第2MRモジュールへ送信する動作と、前記第1MRモジュールが、MR_CHANGE制御信号を受信した後に、MR_CHANGE信号を各Mモジュールへ転送し、MR_CHANGE制御信号が送信された前記各Mモジュールに対する前記自律的コントロールプレインへ、MR_CHANGEセンサイベントを発信する動作と、前記第2MRモジュールが、NEW_MR制御信号を受信した後に、NEW_MR制御信号を各Mモジュールへ転送する動作であって、前記Mモジュールは、NEW_MR制御信号の受信後に受信され、MR_CHANGE制御信号の受信前に受信されたコンテンツをバッファリングするように適合されており、これにより、前記コンテンツが正しい順に処理されることを保証している動作と、前記各Mモジュールが、NEW_MR制御信号を受信した後に、センサイベントを前記自律的コントロールプレインへ送信する動作と、前記自律的コントロールプレインが、前記第1MRモジュールからMR_CHANGEセンサイベントを受信した全ての前記Mモジュールからのセンサイベントを受信した後に、エフェクタメソッドを呼び出して前記LPPモジュールをSTABLE状態へ戻す動作と、から構成されている、請求項1から7のいずれか1項に記載の分散メディエーションネットワーク。前記Mモジュールに対する切り替え動作を呼び出して、一の前記Mモジュールから送信されるネットワークトラフィックの宛先を前記第1TPモジュールから前記第2TPモジュールへ変更する動作は、前記自律的コントロールプレインが、前記Mモジュールに対するSWITCH_TPエフェクタメソッドを呼び出す動作と、前記Mモジュールが、SWITCH_TPエフェクタメソッドの呼び出しを受けた後に、状態をSWITCHOVER状態に変更し、TP_CHANGE制御信号を前記第1TPモジュールへ送信し、NEW_TP制御信号を前記第2TPモジュールへ送信する動作と、前記第1TPモジュールが、TP_CHANGE制御信号を受信した後に、TP_CHANGE信号を各LPPモジュールへ転送し、TP_CHANGE制御信号が送信された前記各LPPモジュールに対する前記自律的コントロールプレインへ、TP_CHANGEセンサイベントを発信する動作と、前記第2TPモジュールが、NEW_TP制御信号を受信した後に、NEW_TP制御信号を各LPPモジュールへ転送する動作であって、前記LPPモジュールは、NEW_TP制御信号の受信後に受信され、TP_CHANGE制御信号の受信前に受信されたコンテンツをバッファリングするよう適合されており、これにより、前記コンテンツが正しい順に処理されることを保証している動作と、前記各LPPモジュールが、NEW_TP制御信号を受信した後に、センサイベントを前記自律的コントロールプレインへ送信する動作と、前記自律的コントロールプレインが、前記第1TPモジュールからTP_CHANGEセンサイベントを受信した全ての前記LPPモジュールからのセンサイベントを受信した後に、エフェクタメソッドを呼び出して前記MモジュールをSTABLE状態へ戻す動作と、から構成されている、請求項1から8のいずれか1項に記載の分散メディエーションネットワーク。メディエーションネットワークへ入力されるネットワークトラフィックは、一群のメッセージタイプのうちの1つに属しており、前記一群のメッセージタイプは、情報源として作用するプロセスから発生する新しい情報と、前記メディエーションネットワークに含まれるノードであって、応答を要求するノードの状態に関する問い合わせと、前記メディエーションネットワークが新しい関連情報を受信する場合に、進行中の応答を要求する関心の表明と、から成る、請求項1から9のいずれか1項に記載の分散メディエーションネットワーク。コンピュータネットワークにおけるネットワークトラフィックのフローをメディエートする方法であって、コンピュータネットワークはメディエーションネットワークを有しており、メディエーションネットワークは、複数のタイプのネットワークモジュールであって、メディエーションネットワークとクライアントプログラムとの間のネットワークトラフィックを受信及び送信するローカルポイントオブプレゼンスLPPモジュールと、メディエーションタスクを担当するメディエータMモジュールと、入力メッセージのコンテンツを解析するメディエータルータMRモジュールであって、前記各MRモジュールは、前記コンテンツに応じて予め決定されたメディエーションタスクへ前記入力メッセージをルーティングする前記MRモジュールと、少なくとも1つの前記LPPモジュールへメッセージを転送する伝送プロキシTPモジュールであって、前記MRモジュール、前記Mモジュール及び前記TPモジュールの各々は、それらのモジュールを通過するネットワークトラフィックの全てのパスが非相互的であるように適合されている前記TPモジュールと、から成る前記ネットワークモジュールと、自律的コントロールプレインと、を備える前記メディエーションネットワークであって、前記自律的コントロールプレインは、前記LPPモジュールに対する切り替え動作を呼び出して、一の前記LPPモジュールから送信されるネットワークトラフィックの宛先を第1MRモジュールから第2MRモジュールへ変更する動作によって、又は、前記Mモジュールに対する切り替え動作を呼び出して、一の前記Mモジュールから送信されるネットワークトラフィックの宛先を第1TPモジュールから第2TPモジュールへ変更する動作によって、前記モジュール間におけるネットワークトラフィックの分散を管理するように適合され、及び/又は、第1Mモジュールに対する譲渡動作を呼び出して、前記第1Mモジュールから第2Mモジュールへ特定のメディエーションタスクを移転する動作によって、前記Mモジュール間におけるメディエーションタスクの分散を達成するように適合され、前記モジュールは、前記モジュールの状態を前記自律的コントロールプレインに伝達するセンサインターフェースと、前記自律的コントロールプレインからコマンドを受信するエフェクタインターフェースと、を有し、前記方法において、前記入力メッセージはメディエーションサイクルに沿って伝達され、前記メディエーションサイクルは、前記LPPモジュールが、少なくとも1つの前記MRモジュールのそれぞれ1つへ前記入力メッセージを送信するステップと、送信された前記MRモジュールが、前記入力メッセージのコンテンツを解析し、前記解析されたコンテンツに応じて、予め決定された前記Mモジュールへ前記メッセージをルーティングするステップと、予め決定された前記Mモジュールが、メディエーションタスクを前記解析されたメッセージに対して適用し、メディエートされたメッセージを前記TPモジュールの1つへ送信するステップと、前記メディエートされたメッセージを受信した前記TPモジュールが、前記メディエートされたメッセージを前記LPPモジュールの少なくとも1つへ送信するステップと、から成る前記メディエーションサイクルである前記方法。前記自律的コントロールプレインは、前記各タイプのモジュールの数が制限されるように適合されている、請求項11に記載の方法。前記自律的コントロールプレインは、多数のリソースにわたって提供されている、請求項11または12に記載の方法。前記自律的コントロールプレインは、所定のタイプの前記モジュール間におけるネットワークトラフィックの分散を管理するクラウドマネージャと、前記モジュールのタイプ間におけるリソースの分散を管理する分散メディエーションネットワークDMNマネージャと、を備える階層構造を有している、請求項11から13のいずれか1項に記載の方法。前記クラウドマネージャは互いに直接通信することができる、請求項14に記載の方法。前記クラウドマネージャ間の全ての通信は前記DMNマネージャを通過しなければならない、請求項14または15に記載の方法。前記第1Mモジュールに対する譲渡動作を呼び出して、前記第1Mモジュールから前記第2Mモジュールへ特定のメディエーションタスクを移転する動作は、前記自律的コントロールプレインが、前記第1Mモジュールに対するHANDOVER_SEGMENTエフェクタメソッドを呼び出す動作と、前記第1Mモジュールが、HANDOVER_SEGMENTエフェクタメソッドの呼び出しを受けた後に、状態をHANDOVER_SENDER状態に変更し、前記第1Mモジュールに現在記憶されている前記特定のメディエーションタスクに関連するコンテンツを処理し、次いでMEDIATION_CHANGE制御信号を全ての前記LPPモジュールに送信する動作と、前記第1Mモジュールが、MEDIATION_HANDOVER制御信号を前記第1Mモジュールから前記第2Mモジュールへ送信し、次いで前記第1Mモジュールが受信した前記特定のメディエーションタスクに関連するコンテンツを前記第2Mモジュールへ転送する動作と、前記第2Mモジュールが、MEDIATION_HANDOVER制御信号を受信した後に、状態をHANDOVER_RECEIVER状態へ変更し、前記状態変更を示すセンサ信号を前記自律的コントロールプレインに送信し、NEW_MEDIATOR制御信号を全ての前記LPPモジュールへ送信する動作であって、NEW_MEDIATOR制御信号の受信後に受信され、MEDIATION_CHANGE制御信号の受信前に受信された前記特定のメディエーションタスクに関連するコンテンツを、前記LPPモジュールがバッファリングする動作と、前記第2MモジュールがHANDOVER_RECEIVER状態にあることを示すセンサ信号を受信した後に、前記自律的コントロールプレインが、前記MRモジュールに対するエフェクタメソッドを呼び出し、前記特定のメディエーションタスクに関連するコンテンツを前記第1Mモジュールではなく前記第2Mモジュールへ転送するように前記MRモジュールに対して命令する動作と、前記各MRモジュールが、転送されるコンテンツの宛先を前記第2Mモジュールへ変更した後に、宛先の変更を示すセンサ信号を前記自律的コントロールプレインへ発信し、前記各MRモジュールに対応するRT_CHANGED制御メッセージを前記第1Mモジュールへ転送し、次いで前記第1MモジュールがRT_CHANGED制御メッセージを前記第2Mモジュールへ転送する動作であって、前記第2Mモジュールが前記各MRモジュールから直接受信した前記特定のメディエーションタスクに関連するコンテンツを、前記各MRモジュールに対応するRT_CHANGED制御メッセージを前記第2Mモジュールが受信するまで、バッファリングする動作と、前記第2Mモジュールが、前記各MRモジュールから発信されたそれぞれのRT_CHANGED信号を前記第2Mモジュールが受信した場合に、センサ信号を前記自律的コントロールプレインに送信する動作と、前記自律的コントロールプレインが、全ての前記MRモジュールからRT_CHANGED制御信号が受信されたことを示すセンサ信号を前記第2Mモジュールから受信した場合に、前記第1Mモジュール及び前記第2Mモジュールに対するエフェクタメソッドを呼び出して前記第1Mモジュール及び前記第2MモジュールをSTABLE状態に戻す動作と、から構成されている、請求項11から16のいずれか1項に記載の方法。前記LPPモジュールに対する切り替え動作を呼び出して、一の前記LPPモジュールから送信されるネットワークトラフィックの宛先を前記第1MRモジュールから前記第2MRモジュールへ変更する動作は、前記自律的コントロールプレインが、前記LPPモジュールに対するSWITCH_MRエフェクタメソッドを呼び出す動作と、前記LPPモジュールが、SWITCH_MRエフェクタメソッドの呼び出しを受けた後に、状態をSWITCHOVER状態に変更し、MR_CHANGE制御信号を前記第1MRモジュールへ送信し、NEW_MR制御信号を前記第2MRモジュールへ送信する動作と、前記第1MRモジュールが、MR_CHANGE制御信号を受信した後に、MR_CHANGE信号を各Mモジュールへ転送し、MR_CHANGE制御信号が送信された前記各Mモジュールに対する前記自律的コントロールプレインへ、MR_CHANGEセンサイベントを発信する動作と、前記第2MRモジュールが、NEW_MR制御信号を受信した後に、NEW_MR制御信号を各Mモジュールへ転送する動作であって、前記Mモジュールは、NEW_MR制御信号の受信後に受信され、MR_CHANGE制御信号の受信前に受信されたコンテンツをバッファリングするように適合されており、これにより、前記コンテンツが正しい順に処理されることを保証している動作と、前記各Mモジュールが、NEW_MR制御信号を受信した後に、センサイベントを前記自律的コントロールプレインへ送信する動作と、前記自律的コントロールプレインが、前記第1MRモジュールからMR_CHANGEセンサイベントを受信した全ての前記Mモジュールからのセンサイベントを受信した後に、エフェクタメソッドを呼び出して前記LPPモジュールをSTABLE状態へ戻す動作と、から構成されている、請求項11から17のいずれか1項に記載の方法。前記Mモジュールに対する切り替え動作を呼び出して、一の前記Mモジュールから送信されるネットワークトラフィックの宛先を前記第1TPモジュールから前記第2TPモジュールへ変更する動作は、前記自律的コントロールプレインが、前記Mモジュールに対するSWITCH_TPエフェクタメソッドを呼び出す動作と、前記Mモジュールが、SWITCH_TPエフェクタメソッドの呼び出しを受けた後に、状態をSWITCHOVER状態に変更し、TP_CHANGE制御信号を前記第1TPモジュールへ送信し、NEW_TP制御信号を前記第2TPモジュールへ送信する動作と、前記第1TPモジュールが、TP_CHANGE制御信号を受信した後に、TP_CHANGE信号を各LPPモジュールへ転送し、TP_CHANGE制御信号が送信された前記各LPPモジュールに対する前記自律的コントロールプレインへ、TP_CHANGEセンサイベントを発信する動作と、前記第2TPモジュールが、NEW_TP制御信号を受信した後に、NEW_TP制御信号を各LPPモジュールへ転送する動作であって、前記LPPモジュールは、NEW_TP制御信号の受信後に受信され、TP_CHANGE制御信号の受信前に受信されたコンテンツをバッファリングするよう適合されており、これにより、前記コンテンツが正しい順に処理されることを保証している動作と、前記各LPPモジュールが、NEW_TP制御信号を受信した後に、センサイベントを前記自律的コントロールプレインへ送信する動作と、前記自律的コントロールプレインが、前記第1TPモジュールからTP_CHANGEセンサイベントを受信した全ての前記LPPモジュールからのセンサイベントを受信した後に、エフェクタメソッドを呼び出して前記MモジュールをSTABLE状態へ戻す動作と、から構成されている、請求項11から18のいずれか1項に記載の方法。メディエーションネットワークへ入力されるネットワークトラフィックは、一群のメッセージタイプのうちの1つに属しており、前記一群のメッセージタイプは、情報源として作用するプロセスから発生する新しい情報と、前記メディエーションネットワークに含まれるノードであって、応答を要求するノードの状態に関する問い合わせと、前記メディエーションネットワークが新しい関連情報を受信する場合に、進行中の応答を要求する関心の表明と、から成る、請求項11から19のいずれか1項に記載の方法。発明の詳細な説明最初に、本発明の背景として、P2Pモデル及び集中仲介型メッセージモデルに関して説明する。以下の説明において、ソースという文言は、新しいメッセージを生成してネットワークサービスへ送信するクライアントを意味し、シンクという文言は、ネットワークサービスからのメッセージを受信するクライアントを意味する。ネットワークサービスにおける各クライアントは、ソース、シンクあるいはその両者の機能を有する。別の専門用語を用いると、情報のソースは発行者publishersと呼ばれ、情報に対するシンクは購読者subscribersと呼ばれる。P2Pモデルにおけるコンテンツベースのルーティングを行う際には、適切なソースと適切なシンクとの間で仮想チャンネルを確立することで、ソースからシンクへのメッセージの効率的な伝送が可能になるように、ネットワークが構成される。伝送効率を向上させるためには、一般的には、完全結合グラフfullyconnectedgraphから不必要なエッジノード間を接続している通信線のことを検出して削除する。その結果生じた最適化されたグラフは、利用可能なネットワークインフラに適合している。P2P仮想チャンネルを確立するためには、一のピアによる関心の表明expressionofinterestと、別のピアによる関心の承諾acceptanceofthatinterestと、が要求される。一方、集中仲介型メッセージモデルにおいては、全てのメッセージは集中メディエーションノードを介して伝送される図1A及び図1Bを参照。メディエーションネットワークに関する専門用語において、メディエーションサービスは、全ての入力メッセージへ適用されるある種の計算処理を意味する一般的な用語である。また、仲介型構造における特定のインスタンスに対するメディエーション要求は、提供される全てのメディエーションサービスの照合を意味する。また、メディエーション権限は、メディエーションサービスを提供する人を意味する。また、メディエーションネットワークは、メディエーション権限の制御下にある物理的な計算主体機械から成るネットワークを意味する。また、メディエーションサーバは、1つ以上のメディエーションサービスを提供する物理的機械を意味する。一般的な仲介型情報フローシステムを単純化したモデルにおいては、メディエーション権限へ送信されたメッセージは、以下の複数のタイプのうちの1つへ当てはめることができる。そのタイプとは、情報のソースとして動作するプロセスが生成した新しい情報と、メディエーション権限が有する状態に関する、迅速な応答を要求する問い合わせクエリーと、メディエーション権限によって新しい関連情報が受信される度に、進行中の応答を要求する本質的かつ永続的な問い合わせクエリーである関心の表明と、である。完全仲介型モデルにおいてさえ、各仮想チャンネルにかかる回線容量の要求量を低減して、ネットワークサービスをシンクへ転送する際に、関心の表明が重要であるということは、注目に値する。上記の定義に照らすと、仲介型情報フローシステムは、中央のメディエーション権限へ送信されると共に、中央のメディエーション権限から送信される情報を含むメッセージから構成されるシステムである。この権限によって実行される動作アクションには、時系列に沿った受信メッセージに関するログの記録と、ある時点までに受信されたメッセージ全体に対する演算処理と、メッセージの内容に基づいてある種の計算処理を実行した後に行われる他のクライアント間における入力メッセージの分散と、がある。本発明は、コンテンツベースの非集中型P2Pモデルと、単純な集中型かつ仲介型のネットワークモデルと、の複合モデルに関する。この複合モデルでは、集中メディエーションノードが1つだけ備えられる代わりに、多数の独立した機能コンポーネントを備えるメディエーションネットワーク内に、種々のメディエーションサービスが分散して配置される。このような複合モデルにおいて、関心の表明は、ソースノードとMノードとの間で仮想チャンネルを開く目的で用いられる。また、関心の表明は、Mノードとシンクノードとの間で仮想チャンネルを開く目的でも用いられる。従って、シンクノードが受信したメッセージは、メディエーションサービスに登録された関心の表明によって所轄される。ソースノードとシンクノードとの間には2つ以上の論理的な飛びlogicalhopsが存在するために、ソースノードとシンクノードとの間で発生する待ち時間は、単純なコンテンツベースのルーティングに要する時間に比べて必然的に長くなる。状況によっては、より静的な情報が利用可能になるに従って、各々の論理的な飛びにおける待ち時間を順次低減することができる。単純な仲介型モデルと比べて、この複合モデルでは、メディエーションタスクが多数のノードにわたって分散されているために、より複雑な構造を有する図2Aを参照。しかしながら、集中型かつ仲介型のモデルに固有の集中メディエーションノードで発生する障害は除去されるので、結果として生じる構造は拡張可能である。図3は、静止しているquiescentあるいは定常状態steadystateにある、すなわち論理的トポロジーの変化がない状態にある複合分散メディエーションモデルが備える機能コンポーネントを表す最小限のトポロジーを示す。図3は、データがシステム内部において種々のコンポーネントノード間をどのように流れるかを示している。無限の規模を有する分散メディエーションネットワークにおいても、必要なコンポーネントノードは全て、この最小限のトポロジーに含まれており、ソースと、シンクと、ローカルポイントオブプレゼンスと、メディエータルータと、メディエータと、伝送プロキシとが備えられている。以下、これらの用語及び他の用語について定義する。ローカルポイントオブプレゼンスLPPは、クライアントソース及びシンクと分散メディエーションネットワークの他のネットワークノードとの間の仲介者intermediaryとして作用する。ローカルポイントオブプレゼンスは、ネットワーク上の特定の地理的領域に対するメディエーションサービスを代理するネットワークノードである。メディエーションサービスの各クライアントは、一のローカルポイントオブプレゼンスのみと通信して、メディエーション構造内の他のノードとは通信しない。システムは任意の数のLPPを備えることができ、各LPPはそれぞれのクライアントにサービスを提供する。メディエーションルータMRは、入力メッセージのコンテンツを分析して多数のクロスストリーム上のMノードの内の1つへ入力メッセージを送信するメディエーションルータモジュールを内部に組み込んでいるネットワークノードである。各メディエーションルータは、アップストリームネットワークの先頭に位置し、多数のLPPからメッセージを受信する。また、メディエーションルータは、例えば、担当する地理的領域内のローカルなサービスを使用可能にするために、入力メッセージに関するログを記録する。メディエータMは、メディエータモジュールを内部に組み込んでいるネットワークノードであり、メディエーション要求のサービスを提供する。各メディエータは、関連するダウンストリームに対してメッセージを分散する機能を有し、該当するメッセージをLPP、そして最終的にシンクへと転送させるために用いられる。それぞれのメディエータモジュールは、1つ以上のメディエーションタスクを実行する。それぞれのタスクは、特定のタイプのメッセージセグメントへ適用される一つのメディエーションセグメントサービスを表している。メディエータモジュールは、受信する全ての入力メッセージをログに記録して、これらの入力メッセージを関連するダウンストリームの伝送ネットワークへ転送するように、構成することもできる。この場合、メディエーションタスクは、このように生成された入力メッセージを記録したログに関する問い合わせクエリーのサービスを提供する。伝送プロキシTPは、伝送プロキシモジュールを内部に組み込んでいるネットワークノードである。伝送プロキシモジュールは、1つ以上のMノードから出力されたメッセージを分析し、登録された関心の表明に基づいて、どのシンクへ送信メッセージを転送するかを決定し、各メディエータに関連付けられるダウンストリームネットワーク上のメッセージを転送する。後で詳細に説明する通り、本発明の好ましい実施形態は、ネットワークモジュールノードに加えて、自律的コントロールプレインを備える。自律的コントロールプレインにより、システムの自律的な制御が可能となる。アップストリームネットワークソースからメディエータルータまでは、メディエーションの機能を有するが、コンテンツベースではない。メディエータルータとメディエータとの間におけるルーティングは、いわゆるクロスストリームネットワークにあり、コンテンツベースである。ダウンストリームネットワークもコンテンツベースのルーティングを要求する。実際のところ、メディエータルータとLPPとの間におけるルーティングは、それ自体複合的なコンテンツベースのメッセージ転送機構と見なすことができる。この複合モデルの一部分としてメッセージ空間を分割することで、拡張可能でない集中メディエーションノードにおける障害を発生させることなく、発行購読モデルに対してミッドストリームmid-streamメディエーションサービスを導入することができる。静止しているあるいは定常状態にあるシステムに対しては、分散メディエーションネットワークに関する以下の記述は常に成立する。これらの記述は、分散メディエーション構造が有する全体的な不変条件と考えられる。全てのノードは、LPP->MR->M->TP->LPPサイクルの一部分である。全てのLPPは、一のMRを常に指定する。全てのMRは、任意の数のMを指定することができる。全てのMは、一のTRを常に指定する。全てのTPは、任意の数のLPPを指定することができる。ここで、記号->は、一方向への接続方向付きエッジを表す。上記の全体的な不変条件を検討することで、なぜ、図3に例示したネットワークが最小限の分散メディエーショントポロジーであるかは自明である。このネットワークは、メディエーションが分散される2つのMと、1つのLPPと、1つのMRと、1つのTPとから構成される。また、LPP->MR->M->TP->LPPのようにノードが一方向に沿って接続された単純なサイクルとして、全ノードが構成されている。より現実的かつ複雑な分散メディエーションネットワークを、図4に示す。以降キュービックなcubicネットワークとして知られるこのネットワーク構成には、4種類のノードが2つずつ含まれる。キュービックなネットワークは、一般的な分散メディエーションネットワークの特性をより詳細に例示する。循環cyclicネットワークにおいて、接続されたノード間のメッセージフローは一方通行である。キュービックなネットワークにおける全てのノードは、少なくとも1つのサイクルLPP->MR->M->TP->LPPを構成するコンポーネントである。キュービックなネットワークは、ファンイン/ファンアウトfanin/fanoutトポロジーを示す。すなわち、ファンインfan-inトポロジーにおいては、全てのLPPは、メッセージを唯一のMRへ送信すると共に、各MRは複数のLPP図4においては、2つのLPPが存在する。からメッセージが送信される。また、ファンアウトfan-outトポロジーにおいては、全てのMRは、メッセージを任意のMへ送信する。また、ファンインfan-inトポロジーにおいては、全てのMは、受信した任意のメッセージを唯一のTPへ送信すると共に、各TPは、複数のMからメッセージが転送される。最後に、ファンアウトfan-outトポロジーにおいては、全てのTPは、メッセージを任意のLPPへ送信する。また、最小限の循環ネットワーク及びキュービックなネットワークのような分散メディエーションネットワークは、他にも重要な特性を示す。ネットワーク内の全てのノードから他のノードへは方向付き経路が存在している。グラフ理論の用語を用いると、全てのノードから他の全てのノードへの推移閉包が常に存在すると言える。この特性が循環ネットワークに当てはまることは自明である。しかしながら、この特性は、全体的な不変条件が持つ特性の帰結として、より複雑な分散メディエーションネットワークにも当てはまる。方向付き経路は、方向付き循環グラフと常に見なすことができる。このように、一般化された分散メディエーションネットワーク内の任意の2つのノードA及びノードBに対して、ノードAからノードBを経由してノードAへ至るサイクルが常に存在する。ここで、キュービックな単一のレベルのネットワークにおいて、そのようなサイクルの最大経路長は4ではなく8であることに留意するべきである。さらに、各ノードは、全体への依存性も、当該ノードの直近の領域を除くネットワーク全体に関する詳細な知識も有していない。各ノードは、自身が直接指定するノードに関する情報のみを記憶する。また、ノードは、ネットワーク内の各ノードを指定するノード全体に関する情報を記憶する。この情報は、ノード自身における参照カウント値として記憶されるか、当該ノードを直接指定する全てのノードにおけるクレジットバランスcreditbalance値として記憶されることもできる。いずれの場合も、他ノードの指定を行うノードに関する情報は記憶される必要はない。実際のところ、全てのノードは、残りのシステム全体に関するあらゆる追加情報も記憶する必要がない。本発明に係る分散メディエーションネットワークのさらに重要な特性は、動作が決定論的であり、各ノード内における動作の順序が確定していることにある。すなわち、メッセージAの後に到着するメッセージBは、メッセージAの後に転送されることが保証される。同様に、複数のメッセージは、ノード間の直接的なリンク上で互いに追い越すことはない。従って、任意の2つのノードN1及びノードN2に対して、N2がN1によって指定される場合、メッセージAがN1からN2へ送信され、続いてメッセージBがN1からN2へ送信されると、N2はメッセージBを受信する前に常にメッセージAを受信することになる。分散メディエーションネットワークアプリケーションアプリケーションAは、メッセージ指向パラダイムmessageorientedparadigmに基づいて構成されている。Aは、セットMから抽出される、部分的に配列された一連のメッセージm1,m2,m3,...を受信し、追加メッセージを生成することで応答する。アプリケーションAの観測可能な動作以下、obsAによって表す。は、特定の入力シーケンスから生成された全ての可能な出力シーケンスのセットとして、定義される。そのようなアプリケーションが、分散メディエーションネットワークによって提供される利点を享受するためには、以下の原則に従わなければならない。-アプリケーションは、1セットの、各々が独立して動作するアプリケーションコンポーネント{Ai}として並行して存在しなければならないが、結果として生じる出力メッセージの全てを任意にインターリーブinterleavedすることで、{Ai}の観測可能な動作がAの観測可能な動作と等しくなる。-全ての入力メッセージのセットMは、segment関数M->Sに従って、1セットのメッセージセグメント{Sj}に分割されなければならない。-mediates関数S->Aが、メッセージセグメントとアプリケーションコンポーネントとの間に存在する。すなわち、各メッセージセグメントは、正確に1つのアプリケーションコンポーネントへ対応する、-一連のメッセージm1、m2、m3、...に対する応答である、全てのアプリケーションコンポーネントの総体ΣAiの観測可能な動作ここで、それぞれのコンポーネントAiには、mediates関数及びsegment関数に従って、入力ストリームからフィルターにかけられたメッセージのみが通過する。は、入力ストリーム全体を受信した際のAの観測可能な動作と正確に同一である。さらに、上記の制約条件が存在する場合には、分散メディエーションネットワークによって提供されたロードバランシング機能を登録するために、以下の2つの副次的メソッドside-effectingmethodsがアプリケーションコンポーネントAiのインスタンスに追加される必要である。-gainSegmentsegDescriptor,data関数-loseSegmentsegDescriptor->data関数任意の2つのアプリケーションコンポーネントA1、A2及び任意のセグメントsに対して、mediatess=A2の条件下におけるobsA1A2は、mediatess=A1の条件下におけるobsA1.gainSegments,dA2.loseSegmentsと同等である。ここで、dはA2.loseSegmentsの結果を表す。自律的コントロールプレイン本発明に係る分散メディエーション構造は、自律的に機能するように設計されている。すなわち、本システムは、最適化に関するユーザ入力やユーザが有する知識を必要としないで、自身を現時点での要求に従って最適化する。特に、自律的システムは、利用可能なコンポーネントにかかる負荷が効果的に分散されることを保証し、これにより、システムにおけるデータの取り扱いにおける不必要な障害を回避する措置を取る。本発明において、自律的機能は、自律的コントロールプレインによって提供される。図5に示す通り、自律的コントロールプレインは、メディエーションサービス、分散メディエーションネットワーク及び基礎的なリソース仮想のリソースあるいは現実のリソースのいずれかを管理する。各ネットワークノードは、自律的コントロールプレインに対して管理された要素として自分自身を表す。管理された要素は、センサインターフェース及びエフェクタインターフェースの両方をサポートする。センサインターフェースは、指定された測定基準metricsを発信し、これにより、自律的マネージャは、管理された要素の属性を監視することができる。エフェクタインターフェースは、自律的マネージャから、管理された要素の動作を変更するための指定された処理方法を受信する。そのため、各センサインターフェース及び各エフェクタインターフェースは、センサインターフェースでは管理された要素から自律的マネージャへ、エフェクタインターフェースでは自律的マネージャから管理された要素へ情報が一方向に流れることを可能にする。好ましい実施形態においては、図6に示す通り、自律的コントロールプレインは、1つの階層的なセットの自律的マネージャから成る。図6に示す例では、それぞれのタイプのネットワークノードLPP、MR、MおよびTPに対して一つの自律的マネージャが存在する。この階層的レベルにおけるマネージャは、クラウドマネージャと呼ばれる。それぞれのクラウドマネージャは、特定のロードバランシング機能を担当する。好ましい実施形態において、それぞれのクラウドマネージャは、それ自身がピアツーピアネットワークにわたって分散されており、それぞれのクラウドマネージャが担当するタイプのそれぞれのネットワークモジュールからセンサイベントを受信する。次の階層レベルにおいては、全体的な分散メディエーションネットワークDMNマネージャ620が、クラウドマネージャの制御を担当し、これにより、クラウドマネージャが一貫した単位coherentunitとして動作することを保証している。そのため、クラウドマネージャは、DMNマネージャ620の管理された要素と言える。DMNマネージャ620は、各クラウドマネージャが利用可能なリソースは、関連するロードバランシングの処理タスクを実行するために十分であることを保証する義務がある。一方、クラウドマネージャは、クラウドマネージャが現在要求していないあらゆるリソースの制御を解放する義務がある。DMNマネージャ620は、クラウドマネージャ間のあらゆるリソースの衝突を解決する。図6に示す例において、MRクラウド自律的マネージャ612は、MRがネットワークトラフィックによって過負荷とならないことを保証するために、アップストリームのロードバランシングを担当する。MRクラウドマネージャ612は、ネットワーク内のMRの数を増減することができ、MRを通過するスループットの平均値が指定された最適化範囲内に収まるようにする。さらに、MRクラウドマネージャ612は、MR全体にわたるLPPの分散を最適化し、これにより、個々のMRが過負荷とならないようにする。好ましい実施形態においては、一のMRから他の一のMRへ出力を移転するためのLPPの実際の命令は、LPPクラウドマネージャ610によって行なわれる。Mクラウド自律的マネージャ614は、クロスストリームのロードバランシングを担当する。そのため、Mクラウドマネージャ614は、MRを通過するルーティングされたスループットを処理するための十分なMがあることを保証する。このために、Mクラウドマネージャ614は、それぞれのMモジュールに対する平均負荷が指定された範囲内に収まるように、Mの数を調整する。また、Mクラウドマネージャ614は、個々のMが過負荷とならないように、M間でメディエーションセグメントサービスを分散することを担当する。ある範囲の条件下でこれを実行するために、Mクラウドマネージャ614は、M間でメディエーションセグメントあるいはタスクを移転することができる。これを実現するアルゴリズムについては、以下に挙げる例に基づいて、より詳細に説明する。TPクラウド自律的マネージャ616は、ダウンストリームのロードバランシングを担当する。そのため、TPクラウドマネージャ616は、各TPの平均スループットが指定された範囲内となることを保証し、また、個々のTPが過負荷とならないよう、Mが複数のTP間で分散されることを保証する。好ましい実施形態においては、一のTPから他のTPへのMの実際の切り替えは、Mクラウドマネージャ614へ委任される。クラウドマネージャによって実行されるロードバランシングに関する方針は同一の基本パターンに従うが、メディエーションセグメントサービスの切り替えは次に挙げる複数の処理の組み合わせである複合的処理であることを付言しておく。その複数の処理とは、あらゆる関連する状態を移転する処理などの、セグメントのプロセスを移行する処理と、所定のメッセージの宛先ターゲットを決定するために各MRが使用し、以前のメディエータがその間に受信したメッセージの再ルーティングを行うための、ルーティング機能を更新する処理である。次に、この理由を説明するために、Mクラウドマネージャの動作を以下詳細に説明する。一般に、ロードバランシングの方針は、より高いレベルのサービス分散メディエーションネットワークマネージャによって解決されるあらゆるリソースの衝突とは独立して動作することが可能である必要がある。しかしながら、各クライアントから適切なメディエーションセグメントサービスへのメッセージの因果的配信則、及び各メディエーションサービスによって生成され、関心を持っているクライアントへ送信されるメッセージの因果的配信則が、両方とも常に保証されるように、開始済みの切り替え処理が構成されなければならない。クロスストリームのロードバランシング-メディエーションセグメントサービスの譲渡本発明の分散メディエーション構造は、LPPノード、MRノード、Mノード及びTPノードから成る任意のトポロジーに基づいている。このトポロジーのノードは、定常状態に関して上述した特性を有する。この前述のトポロジーは、既存の機能的コンポーネント間における動的なロードバランシングに非常に適している。上述の通り、特定のセグメントに重い負荷が掛かっていると考えられる場合に、Mクラウドマネージャは、関連するメディエーションタスクメディエーションセグメントサービスの担当を、処理能力に余裕があるネットワーク内のマシンへ自律的に移動させることができる。また、現在ネットワーク内にあるあらゆるメッセージ又は将来受信する予定のあらゆるメッセージが、新しいMノードへ経路が変更されることを保証するために、メディエーションタスクを譲渡する処理は、メディエーションネットワークの動的な調整を要求する。これは、新しい論理的ネットワークトポロジー内の特別なメッセージの伝達によって、すなわち、適切なマシンを介したコーザルリップリングcausalripplingによって、達成される。それによって、稼働中のシステムにおいて、メッセージ入出力の観点からシステムの観測可能な動作に影響することなく、メディエーションの変更を行うことができる。メディエーションセグメント及びメディエーションタスクは統合して単一のメディエーションアプリケーションを形成し、種々のセグメントはM全体にわたって分散されることを再度記載しておく。メディエーションの変更は、根本的には、全体的な不変条件の特性が持つ利点によって可能となる。これにより、入力メッセージは、当該メッセージが生成されるLPPにかかわらず同じメディエータへルーティングされることになる。メディエーションの変更は、実システムにおいて、一の整合性のある状態から他の整合性のある状態への変更という問題が発生するが、システムの正確さあるいは性能に悪影響を及ぼす問題は発生しない。ここで、分散メディエーションネットワークの2つの主要な機能に関して説明する必要がある。その機能とは、メッセージの伝達の機能及びメッセージの問合わせの機能である。また、メッセージの問合わせは、特に起動時の問い合わせstart-upqueriesを指す。先に述べた通り、Mクラウドマネージャは、メディエーション要求の自律的なロードバランシングを担当する。そのため、Mクラウドマネージャは、十分なリソースが利用可能であれば、新しいMをシステムに導入することができ、個々のMが過負荷とならないようにセグメントをM間に分散することができる。さらに、Mクラウドマネージャは、所定のメディエーションサービスから、メディエーションセグメントを追加及び削除することができる。例えば、Mクラウドマネージャは、新しいメディエーションセグメントを担当することができる適切なMを特定することができる。例えば、毎秒15個のリクエストを発行している10個のクライアントが、2つのLPP以下、lpp1及びlpp2とする。にそれぞれ属しているシステムを仮定する。さらに、それらのリクエストは、3種の別個のセグメント以下、s1、s2及びs3とする。に均等に関連付けられている。毎秒300個のリクエストから成るアップストリームのトラフィック合計は、lpp1とlpp2との間で均等に分担される。その結果として生成される毎秒300個のリクエストから成るクロスストリームのトラフィックは、この単純な例においては、2つのMR以下、mr1及びmr2とする。の間で均等に分担され、セグメントs1、s2及びs3の間で均等にそれぞれのセグメントに対して毎秒100個のリクエストの速度で分担される。先に述べた通り、メディエータは、トラフィックをセグメントの種類に応じて取り扱う。この例においては、2つのメディエータ以下、m1及びm2とする。は、それぞれが毎秒200個のリクエストを処理することができる。そのため、m1がセグメントs1のトラフィックをメディエートし、m2が残りのトラフィックセグメントs2及びセグメントs3をメディエートするシナリオが考えられる。この場合、明らかに、m1にかかる負荷は毎秒100個のリクエストになり、m2にかかる負荷は毎秒200個のリクエストになる。ここに挙げたシンプルな例において、メディエーションサービスは、トラフィックの現在状況をダウンストリームネットワーク上へ伝送する。また、TPであるtp1はm1に関連付けられており、TPであるtp2はm2に関連付けられている。その結果、tp1には毎秒100個のアップデートが供給されることになり、tp2には毎秒200個のアップデートが供給されることになる。これらのアップデートは、次にlpp1及びlpp2へ渡され、lpp1及びlpp2のそれぞれがtp1及びtp2から合わせて毎秒300個のアップデートを受信することになる。この毎秒300個のアップデートは、システムのクライアントによって受信されるアップデートの総量を表わしている。上記の例のシステムが動作する条件を変更した場合を考える。例えば、セグメントs2に対するクライアントの関心が上昇し、セグメントs1に対するクライアントの関心が低下すると、各セグメントに対する各クライアントからのリクエストの数の変化に、これらの関心の増減が反映される。例えば、各クライアントは、s1に関連する毎秒3個のリクエストと、s2に関連する毎秒7個のリクエストを伝送すると仮定する。システムにおけるs1及びs2に関連するリクエストの数の合計は、同じ毎秒200個であるが、今回の場合、s1に関連するリクエストは毎秒60個のみであり、s2に関連するリクエストは毎秒140個である。従って、m1に係る負荷は毎秒60個のリクエストのみであるが、m2にかかる負荷は毎秒240個のリクエストであり、負荷が増加している。しかしながら、先に述べた通り、m2には毎秒200個のリクエストという処理能力の制限がある。従って、Mクラウドマネージャは、m1及びm2に対して処理可能な負荷量より大きな負荷が掛からないように、自律的に作用して状況を修正することが要求される。この例において、Mクラウドマネージャは、セグメントs3の処理の担当をm2からm1へ切り替えるように作用する。一旦この切り替えが行われると、m1及びm2上の全体的な負荷は、それぞれ毎秒160個のリクエスト及び毎秒140個のリクエストとなる。また、s2の処理の担当をm1へ移転した場合も、M上の負荷は許容範囲内に収まるが、この場合m1は最大限の処理能力で動作する必要がある。一のMから他のMへのセグメントの移行は、因果的配信則が維持される方法で、かつ分散メディエーションネットワークに対する変更が外部から見えないような方法で、処理されなければならない。システムが第1の整合状態PS1にある時刻から、新しい整合状態PS2にある時刻へ状態が推移する場合について考える。時間t0において、新しい状態PS2へと変化するプロセスが始まる。この後、ある未知の時間t1において、新しい整合状態PS2への変化が完了したことを、システムが認識する。実際の変更が起きた時間tbは不明であるが、時間tbは時間t0と時間t1の間にある。時間t0と時間t1の間においては、システムは不安定な状態にあると定義され、メディエーションタスクが現在動作している箇所が、全体的には認識されていないことを意味している。しかしながら、それぞれの箇所において、情報のフローを正確に処理するために十分に局所的な知識が利用可能であるので、システムの各機能は影響を受けない。当初、メディエータm1がセグメントs1をメディエートして、メディエータm2がセグメントs2及びs3をメディエートしている上記の例を考える。次に、ユーザの観点から見てメディエーションサービスを中断することなく、全ての3つのセグメントs1、s2及びs3のメディエーションのロードバランシングを実行するために、セグメントs3に対して、m2からm1へメディエーションサービスのホットな移行hotmigrationあるいはホットな譲渡hothandoverを可能にするアルゴリズムについて、詳細に説明する。図7A乃至図7Fは、メディエーション変更サイクルを例示している。図7Aに示す通り、メディエーション変更サイクルは、Mクラウドマネージャがメディエータm2に対するHANDOVER_SEGMENTs3エフェクタメソッドを呼び出すことで、セグメントs3をメディエータm1へ譲渡するように指示することから開始される。その結果、メディエータm2はHANDOVER_SENDERs3状態に入る。この状態において、メディエータm2は、バッファリングされた、セグメントs3に対応するあらゆるメッセージを処理する。図7Bに示す通り、一旦セグメントs3のバッファがフラッシュされると、メディエータm2は、ダウンストリームのMEDIATION_CHANGEs3制御メッセージを、TPを介して全てのLPPへ送信し、また、順番に並べられたスナップショットをMEDIATION_HANDOVERs3-state制御メッセージの形式で、メディエータm1に対して送信する。この時点から、メディエータm2は、セグメントs3をメディエートすることを中止し、以降セグメントs3に対応するあらゆるメッセージはメディエータm2によってメディエータm1へ転送される。メディエータm1は、MEDIATION_HANDOVERs3-state制御メッセージを受信すると、HANDOVER_RECEIVERs3状態に入り、受信された状態情報を用いて、セグメントs3に対するメディエーションサービスを開始する。次に、図7Cに示すように、メディエータm1は、ダウンストリームのNEW_MEDIATORs3制御メッセージを、TPを介して全てのLPPへ送信する。NEW_MEDIATORs3及びMEDIATION_CHANGEs3制御メッセージは、セグメントs3に関連するメディエーションタスクの出力のクライアントに対する因果的配信則を保証するために用いられる。特に、以前のメディエータm2からのダウンストリームメッセージは、新しいメディエータm1からのものよりも前にクライアントへ配送されなければならない。これを保証するために、NEW_MEDIATORs3制御メッセージが、対応するMEDIATION_CHANGEs3制御メッセージの前に受信される場合には、LPPによって新しいメディエータから受信されたs3メッセージがバッファリングされる。同様に、メディエータm1はHANDOVER_RECEIVERs3状態に入ると直ちに、各MRから直接的に受信したあらゆるs3メッセージを、その各MRから発信された未処理のs3メッセージがメディエータm2から再ルーティングされなくなることが確定するまで、バッファリングし始める。これを実現するためには、メディエータm1は、コントロールプレインを介してMクラウドマネージャと相互作用する必要がある。従って、メディエータm1は、HANDOVER_RECEIVERs3状態に入ると、センサイベントを発信することによって、この状態変更をMクラウドマネージャへ知らせる。図7Dに示すように、Mクラウドマネージャがこのイベントを受信すると、MRクラウドマネージャのエフェクタを呼び出し、MRに対するルーティングテーブルを更新するよう命令する。MRクラウドマネージャは、それぞれのMRにUPDATE_ROUTING_TABLEs3,m2->m1制御メッセージを送信する。この場合では、MクラウドマネージャはMRクラウドマネージャと直接通信しているが、他の実施形態においてはこの通信を他の方法で行うこともできる。例えば、より厳密な階層構造を有する実施形態においては、DMNマネージャを介して通信することもできる。例えば、Mクラウドマネージャが、DMNマネージャによって選択されるセンサイベントを送出し、次いでMRクラウドマネージャのエフェクタメソッドを呼び出すこともできる。いくつかの実施形態においては、クラウドマネージャ間で直接通信することができない場合もありうる。一般的に、以下に説明する全ての場合において、クラウドマネージャ間の通信は互いに直接的に、あるいはDMNマネージャを介して行われることが意図される。MRは、ルーティングテーブルを更新すると、RT_CHANGEDMR-id,s3制御メッセージをメディエータm2へ送信し、以降の全てのs3メッセージをメディエータm1へと送信する。図7Eに示すように、このRT_CHANGED制御メッセージはメディエータm2からメディエータm1へ転送される。これは、この特定のMRから直接転送されたセグメントs3に対応するあらゆるバッファリングされたメッセージをフラッシュするための、メディエータm1に対するトリガーとなる。また、あらゆるバッファリングされたメッセージがいったんフラッシュされると、メディエータm1はRT_CHANGEDセンサイベントを発信し、コントロールプレインを介して、この特定のMRの更新が成功したことをMRクラウドマネージャに通知する。MRクラウドマネージャが新しいメディエータm1を介して全てのMRから確認ACKを受信した場合には、メディエーション変更プロセスは有効に完了している。図7Fに示すように、この時点で、MRクラウドマネージャは、全てのMRを更新したことを、コントロールプレインを介してMクラウドマネージャに通知することができる。また、Mクラウドマネージャは、セグメントs3に対するメディエーション変更が、メディエータm1及びメディエータm2が共にSTABLEs3状態へ戻ることができる時点で完了していることを、メディエータm1及びメディエータm2に対して通知することができる。クロスストリームの拡張及び縮小当業者には自明のことであるが、同様の手法を、要求に応じてオンデマンドにMノードをシステムに追加、あるいはシステムから削除するために利用することができる。Mノードを追加する操作を完了するためには、要求されるリソースを取得する作業と、空のMノードを生成してTPに接続する作業と、時間経過に伴ってMノードにセグメントを追加する作業とを行う。2つのMモードをキュービックな分散メディエーションモデルへ追加した結果を、図8に例示する。一方、Mノードを削除する操作を完了するためには、最初に全てのセグメントを他のMノードへ移行する作業と、その後にMノードをTPから切断する作業と、Mノードを停止してMノードに関連するリソースを解放する作業とを行う。アップストリームにおけるロードバランシング-メディエーションルータの切り替え図9に、分散メディエーションネットワークの他の例を示す。図9に示すネットワークは、図4に示すキュービックなネットワークとトポロジー的に等価である。この図で示されたレイアウトを以下、円筒状のレイアウトと呼ぶことにする。このタイプの図においては、各LPPは、例示したネットワーク伝送路の始点と終点との両方において、計2回図示されている。円筒状のレイアウトは、分散メディエーションネットワーク内に存在するロードバランシングの機会を効果的に示す。上述した通り、クロスストリームのロードバランシングは、各Mノードにおける負荷が許容範囲内に収まることを保証する。そのため、目標は、任意のMノードを通るトラフィックが適切な高水位線と低水位線の間に収まることと、Mノードのセットが取り扱う全体的な作業の負荷も、同様に許容可能な高水位線と低水位線の間に収まることとを保証することである。トラフィックのレベルはMノードに対するメディエーションセグメントサービスの分散によって決定されるので、一のMノードから他のMノードへ、メディエーションセグメントサービスを移行あるいは譲渡する手法が提供される。アップストリームにおけるロードバランシングの場合は以下のようにまとめることができる。目標は、任意のMノードを通るトラフィックが適切な高水位線と低水位線の間に収まることと、Mノードのセットが取り扱う全体的な作業の負荷も、同様に許容可能な高水位線と低水位線の間に収まることとを保証することである。任意のMRノードを通るトラフィックは、そのMRノードと接続しているLPPノードによって生成されるスループットによって決定されるので、LPPノードの出力を一のMRノードから他のMRノードへ切り替える機能は、任意のMRノードにかかる負荷を管理する際に肝要である。トラフィックが軽い場合には、MRノード間でLPPノードを切り替えることで、MRノードは複数のLPPノードに対してサービスを提供することができる。これは、例えば、専用のMRノードが各LPPノードに常に割り当てられている固定的なシステムと比較して、効率面において著しく優位である。図10Aは、2つのMRノードによってサービスが提供される4つのLPPノードと、2つのTPノードによってサービスが提供される4つのMノードとから成る、拡張された円筒状のレイアウトを示す。図10Aにおけるノード間の矢印は、ネットワークトラフィックの初期状態のフローを表わしている。これを開始時点として、mr1に過大な負荷がかかる可能性がある大量のスループットをlpp1が生成し始める場合について考える。次に、2つのMRノードを通過するアップストリームトラフィックをロードバランシングするために、lpp2がmr2へホットスイッチングサービス稼働中での切り替え、hotswitchingする作業を可能にするためのアルゴリズムについて詳細に説明する。図10B乃至図10Eは、LPPスイッチオーバー切り替えサイクルを例示している。図10Bに示すように、スイッチオーバーサイクルは、LPPクラウドマネージャによって開始され、LPPクラウドマネージャは、ノードlpp2に対するSWITCH_MRmr2エフェクタメソッドを呼び出して、現在のMRノードmr1からノードmr2への切り替えを命令する。この時点で、LPPノードlpp2はSWITCHOVERmr2状態に移行する。図10Cに示すように、lpp2はMR_CHANGElpp2制御メッセージをmr1へ送信することによって応答する。mr1は、ルーティングテーブルにおける各セグメントs<i>に対応する適切なメディエータへMR_CHANGElpp2,s<i>制御メッセージを送信し、同時にMR_CHANGElpp2,s<i>センサイベントを発信することによって、応答する。MR_CHANGElpp2,s<i>センサイベントは、MRクラウドマネージャによって検出され、Mクラウドマネージャがアクセス可能な共有データ空間に記憶されている。いくつかの他の実施形態においては、各LPPは、アクティブなactiveセグメントのリストを維持し、mr1によってルーティングされる、これらのセグメントに対するMR_CHANGElpp2,s<i>制御メッセージを生成することもできる。しかしながら、そのような変形例では、それ以外の場合では要求されないLPPにおける状態情報を維持する必要がある。図10Dに示すように、その後、lpp2は新しいMRノードmr2へ切り替えて、mr2に対してNEW_MRlpp2制御メッセージを送信する。上記の作業により、適切なMノードへ伝送される、ルーティングテーブルにおけるそれぞれのセグメントs<i>に対するNEW_MRlpp2,s<i>制御メッセージが生成される。Mノードによって受信されたNEW_MRlpp2,s<i>及びMR_CHANGElpp2,s<i>制御メッセージは、適切なセグメントサービスによって、クロスストリームメッセージの因果的処理causalprocessingを保証するために用いられる。特に、lpp2によって以前のメディエーションルータmr1を介して送信されたアップストリームメッセージは、新しいメディエーションルータmr2を介して送信されたメッセージの前に処理されなければならない。これを保証するために、lpp2から発信され、新しいメディエーションルータを経由してメディエータが受信した全てのs<i>メッセージは、NEW_MRlpp2,s<i>制御メッセージが対応するMR_CHANGElpp2,s<i>制御メッセージの前に受信される場合には、バッファリングされる。このバッファリング処理は、上述したクロスストリームにおけるロードバランシングにおいて新しいメディエータm2が行ったバッファリング処理と類似している。しかし、アップストリームにおけるロードバランシングでは、LPPノードから発信されたメッセージがバッファリングされ、クロスストリームにおけるロードバランシングでは、MRノードから発信されたメッセージがバッファリングされる。図10Eに示すように、両方の制御メッセージNEW_MR及びMR_CHANGEが受信された後に、あらゆるバッファがフラッシュされると、NEW_MRlpp2,s<i>センサイベントが、関連するMノードによって検出されると共に、Mクラウドマネージャによって検出される。先に記憶されたMR_CHANGEセンサイベントに対応する全てのNEW_MRセンサイベントが検出されると、MクラウドマネージャはLPPクラウドマネージャに、スイッチオーバーサイクルが完了し、結果として、lpp2をSTABLEmr2状態へ切り替えるためのエフェクタメソッドを、LPPクラウドマネージャが呼び出すことを通知する。最適化された安定性を確保するために、本発明に係るいくつかの実施形態で想定されることは、LPPクラウドマネージャとMクラウドマネージャとの間の通信は、全てのMノードがSTABLE状態であったときにのみMRノード間におけるLPPノードの切り替えが開始されることと、LPPノードがSWITCHOVER状態である間はMノード間におけるセグメントの譲渡が開始されないこととを保証することができることである。ダウンストリームにおけるロードバランシング-伝送プロキシの切り替えダウンストリームにおけるロードバランシングは、上述したアップストリームにおけるロードバランシングの繰り返しであり、以下のように要約できる。目標は、任意のTPノードを通るトラフィックが適切な高水位線と低水位線の間に収まることと、TPノードのセットが取り扱う全体的な作業の負荷も、同様に許容可能な高水位線と低水位線の間に収まることとを保証することである。任意のTPノードを通るトラフィックは、そのTPノードと接続しているMノードによって生成されるスループットによって決定されるので、Mノードの出力を一のTPノードから他のTPノードへ切り替える能力は肝要である。トラフィックが軽い場合には、TPノード間でMノードを切り替えることで、TPノードは複数のMノードに対してサービスすることができる。これは、例えば、専用のTPノードが各Mノードに常に割り当てられている固定的なシステムと比較して、効率面において著しく優位である。アップストリームにおけるロードバランシングに関して上述した図10Aに示す分散メディエーションネットワークを開始時点として、tp1に過大な負荷がかかる可能性がある大量のスループットをm1が生成し始める場合について考える。次に、2つのTPノードを通過するダウンストリームトラフィックをロードバランスするために、m2がtp2へホットスイッチングする作業を可能にするためのアルゴリズムについて詳細に説明する。図11A乃至図11Dは、Mノードのスイッチオーバーサイクルを例示している。図11Aに示すように、スイッチオーバーサイクルは、Mクラウドマネージャによって開始される。Mクラウドマネージャは、ノードm2に対するSWITCH_TPtp2エフェクタメソッドを呼び出して、現在のTPノードtp1からノードtp2への切り替えを命令する。この時点で、Mノードm2はSWITCHOVERtp2状態に移行する。図11Bに示すように、m2は、自身が担当するアクティブな各セグメントs<i>に対して、TP_CHANGEm2,s<i>制御メッセージをtp1へ送信することによって応答する。tp1ノードは、この制御メッセージを全てのLPPノードに一括送信すると同時に、各LPPノードに対応するTP_CHANGEm2,lpp<j>,s<i>センサイベントを発信する。このセンサイベントは、TPクラウドマネージャによって検出され、LPPクラウドマネージャがアクセス可能な共有データ空間に記憶されている。図11Cに示すように、その後、m2は新しいTPノードtp2へ切り替えて、自身が担当するアクティブな各セグメントs<i>に対して、NEW_TPm2,s<i>制御メッセージをtp2へ送信する。tp2ノードはこのメッセージを全てのLPPノードへ一括送信する。NEW_TPm2,s<i>及びTP_CHANGEm2,s<i>制御メッセージは、適切なセグメントサービスによって、ダウンストリームメッセージの因果的処理causalprocessingを保証するために用いられる。特に、m2によって以前の伝送プロキシtp1を介して送信されたダウンストリームメッセージは、新しい伝送プロキシtp2を介して送信されたメッセージの前に処理されなければならない。これを保証するために、m2から発信され、新しい伝送プロキシを経由してLPPノードが受信した全てのs<i>メッセージは、NEW_TPm2,s<i>制御メッセージが対応するTP_CHANGEm2,s<i>制御メッセージの前に受信される場合には、バッファリングされる。このバッファリング処理は、セグメントの譲渡の際に、LPPモジュールが行ったバッファリング処理に類似している。異なる点は、今回の場合では、伝送プロキシTPノードではなくメディエーションMノードから発信されたメッセージがバッファリングされる点である。図11Dに示すように、両方の制御メッセージNEW_TP及びTP_CHANGEが受信された後に、あらゆるバッファがフラッシュされると、NEW_TPm2,lpp<j>,s<i>センサイベントが、LPPノードによって発信されると共に、Mクラウドマネージャによって検出される。先に記憶されたTP_CHANGEセンサイベントに対応する全てのNEW_TPセンサイベントが検出されると、LPPクラウドマネージャは、Mクラウドマネージャにスイッチオーバーサイクルが完了したことを通知し、Mクラウドマネージャは、m2をSTABLEtp2状態へ切り替えるためにm2に対するエフェクタメソッドを呼び出す。いくつかの実施形態においては、Mクラウドマネージャは、全てのMノードがSTABLE状態であったときにのみ、TPノード間におけるMノードの切り替えを開始する。さらに、いずれかのMノードがSWITCHOVER状態である間は、メディエーションセグメントの移転を開始しないように、Mクラウドマネージャを設計することもできる。アップストリーム及びダウンストリームの拡張及び縮小当業者には自明なことであるが、必要に応じてオンデマンドにMRノード及びTPノードをシステムに追加、あるいはシステムから削除するために、同様の手法を利用することができる。追加する場合には、要求されるリソースを取得し、MRノードあるいはTPノードを生成し、1つ以上のLPPノードあるいはMノードを、生成されたMRノードあるいはTPノードにそれぞれ切り替える単純な作業を行う。図10及び図11で示されるネットワークトポロジーへMRノードmr3を追加する操作と、既存のMRノードにかかる作業負荷が閾値を越えて全体的に増加するに応じてLPPノードlpp4の送信先を切り替える操作とを行った最終的な結果を図12Aに例示する。この図から、既存のMRノードにかかる作業負荷が全体的に低下した結果、負荷が閾値以下になった場合にMRノードを削除するためには、削除対象のMRノードに向かっている全てのLPPノードを他のMRノードへ切り替えなければならないということになる。次に、前記操作を行ったネットワークトポロジーへTPノードtp3を追加する操作と、既存のTPノードにかかる作業負荷が閾値を越えて全体的に増加するに応じてMノードm4の送信先をtp3に切り替える操作とを行った最終的な結果を図12B及び図12Cに例示する。この図から、既存のTPノードにかかる作業負荷が全体的に低下した結果、負荷が閾値以下になった場合にTPノードを削除するためには、削除対象のTPノードに向かっている全てのMノードを他のTPノードへ切り替えなければならないということになる。最後に、4つのLPPノード及び4つのMノードを有する図10及び図11で示されたネットワークの最大限の構成を、図12Dに示す。この図において、各LPPノードは唯一の専用のMRノードに接続され、また各Mノードは唯一の専用のTPノードに接続される。分散メディエーションネットワークの制約条件としては、ネットワーク上においてMRノードの数はLPPノードの数を上回ることができない。同様に、TPノードの数もMノードの数を上回ることができない。例外処理アップストリーム、クロスストリーム及びダウンストリームにおけるロードバランシングでは対処できないネットワークの負荷に関する問題がいくつか存在する。これらの例外では、関連するクラウドマネージャがDMNマネージャに対して対策を問い合わせる。Mクラウドマネージャによる例外処理例外:一のセグメントs<i>を担当するMノードが過負荷となる。すなわち、負荷が個々のMノードに対する高水位線を超える。Mクラウドマネージャは、DMNマネージャに対してこの例外を生成する必要がある。対策:Mノードの取り扱いを差別化できない限り、この例外に対する取り得る処置はない。すなわち、複数のMノードの一部がより強力なコンピュータ上で処理を行っている場合には例えば昨年発売されたPCではなく最新のマルチコアチップセットを搭載したPC、セグメントをより強力な処理能力を有するノードへ移動させるようにロードバランシングのアルゴリズムを改良することができる。そのようにしても、ある時点で、この限界的状況に再び陥ることになるだろう。所見:この例外から理解できるように、Mノードの結合は脆弱であるという障害が潜在的に存在する。TPクラウドマネージャによる例外処理例外:一のm<j>ノードを担当するTPノードが過負荷となる。すなわち、負荷が個々のMノードに対する高水位線を超える。TPクラウドマネージャは、DMNマネージャに対してこの例外を生成する必要がある。対策:TPノード間で処理能力が異なるなど、TPノードを差別化することができる場合に、ロードバランシングのアルゴリズムを改良することができる。その場合においても、ある時点で、この限界的状況に再び陥ることになるだろう。そうでない場合でも、DMNマネージャは、m<j>ノードがネットワークに過負荷をかけているとMクラウドマネージャに通知することができる。m<j>ノードが複数のセグメントを担当している場合であれば、理論上はこれらのセグメントを再分散することができる。所見:この例外から理解できるように、TPノードの結合は脆弱であるという障害が潜在的に存在する。MRクラウドマネージャによる例外処理例外:一のlpp<k>ノードを担当するMRノードが過負荷となる。すなわち、負荷が個々のMRノードに対する高水位線を超える。MRクラウドマネージャは、DMNマネージャに対してこの例外を生成する必要がある。対策:MRノードの取り扱いを差別化できない限り、この例外に対する取り得る処置はない。すなわち、MRノード間で処理能力が異なる場合には、ロードバランシングのアルゴリズムを改良することができる。その場合においても、ある時点で、この限界的状況に再び陥ることになるだろう。所見:この例外から理解できるように、MRノードの結合は脆弱であるという障害が潜在的に存在する。いくつかの実施形態において、個々のLPPノードがMRノードに過大な負荷をかけていることをDMNマネージャが観測した場合に、LPPノード間でユーザの再調整を行うように指示することもできる。これを達成する手法は、ユーザへ提供されているメディエーションサービスの性質に依存することになる。図13に示される表1は、分散メディエーションネットワーク内のノード間でネットワークトラフィックを分散する際に、自律的コントロールプレインが取る動作の概要を示している。表1は、自律的コントロールプレインが定める測定基準又は変数を示している。例えば、X_NODE_HIGH_WATERMARKは、一のXノードXは、LPP、TP、MR及びMのいずれかが処理可能なトラフィックの最大の閾値を表す。また、X_NODE_POOL_HIGH_WATERMARKは、Xノードのグループにかかるトラフィックのスループットの最大平均値を表す。"