(57)【要約】【課題】 複数個のサーバーの間でメディア資源を負荷分散する方法及びシステムを提供する。【解決手段】  第１のメディア処理資源を要求するクライアントから、第１のプロトコルに従ってフォーマットされた第１の要求が受け取られる。第１の要求は、第２のプロトコルに従ってフォーマットされた第１のモーフされた要求にモーフされる。要求された第１のメディア処理資源をそれぞれが与える複数個のサーバーからなる第１のサーバー・パーティションから、最も負荷が少ない第１のサーバーが選択される。第１のモーフされた要求が第２のプロトコルに従って第１のサーバーに転送されることができる。【選択図】図１
2009519512.tif 000002
【特許請求の範囲】
【請求項１】
複数個のサーバーの間でメディア資源を負荷分散する方法であって、
第１のメディア処理資源を要求するクライアントから、第１のプロトコルに従ってフォーマットされた第１の要求を受け取るステップと、
前記第１の要求を第２のプロトコルに従ってフォーマットされた第１のモーフされた要求にモーフィングするステップと、
前記要求された第１のメディア処理資源をそれぞれが与える複数個のサーバーからなる第１のサーバー・パーティションから、最も負荷が少ない第１のサーバーを選択するステップと、
前記第１のモーフされた要求を第２のプロトコルに従って前記第１のサーバーに転送するステップとを含む、方法。
【請求項２】
前記第１のメディア処理資源を要求するクライアントから、前記第１のプロトコルに従ってフォーマットされた第２の要求を受け取るステップと、
前記第２の要求を、前記第２のプロトコルに従ってフォーマットされた第２のモーフされた要求にモーフィングするステップと、
もしも前記第１のサーバーが依然として最も負荷が少ないサーバーであるならば、前記第２のモーフされた要求を前記第２のプロトコルに従って前記第１のサーバーへ転送するステップと、
もしも前記第１のサーバーが最も負荷が少ないサーバーでないならば、前記第１のサーバー・パーティションから最も負荷が少ない第２のサーバーを選択し、前記第２のモーフされた要求を前記第２のプロトコルに従って前記第２のサーバーに転送するステップとを含む、請求項１に記載の方法。
【請求項３】
第２のメディア処理資源を要求するクライアントから、前記第１のプロトコルに従ってフォーマットされた第２の要求を受け取るステップと、
前記第２の要求を前記第２のプロトコルに従ってフォーマットされた第２のモーフされた要求にモーフィングするステップと、
前記要求された第２のメディア処理資源をそれぞれが与える複数個のサーバーからなる第２のサーバー・パーティションから、最も負荷が少ない第２のサーバーを選択するステップと、
前記第２のモーフされた要求を第２のプロトコルに従って前記第２のサーバーに転送するステップとを含む、請求項１又は請求項２に記載の方法。
【請求項４】
前記最も負荷が少ない第１のサーバーを選択するステップが、
前記要求されたメディア処理資源を同定するために、統一資源識別子（ＵＲＩ）及びコンテンツ・タイプ・ヘッダからなる群から選択されたメッセージ・コンポーネント内に含まれる少なくとも１つのパターンに資源選択ルールを適用するステップと、
前記要求されたメディア処理資源を与える複数個のサーバーからなるサーバー・パーティションを同定するために少なくとも１つのパーティション識別子を参照するステップとを含む、請求項１−３のいずれか１項に記載の方法。
【請求項５】
前記最も負荷が少ない前記第１のサーバーを選択するステップが、
利用可能なサーバーのリストを含むルーチン・リストを参照し、そして前記利用可能なサーバーのそれぞれに質問するステップを含む、請求項１−４のいずれか１項に記載の方法。
【請求項６】
前記ルーチン・リストから利用可能でないサーバーを除去するステップを含む、請求項５に記載の方法。
【請求項７】
前記モーフされた要求を転送するステップが、前記メディア処理資源に関連する前記第１のサーバーのメディア・サーブレットを選択するステップを含む、請求項１−６のいずれか１項に記載の方法。
【請求項８】
前記メディア・サーブレットを有するクライアント・セッションを設立するステップ、又はクッキーズに負荷分散ルーチンをバイパスさせることにより前記クライアント・セッションをサポートするステップとを含む、請求項７に記載の方法。
【請求項９】
前記第１のプロトコルをメディア・リソース制御プロトコル（ＭＲＣＰ）に規定するステップと、
前記第２のプロトコルをハイパーテキスト転送プロトコル（ＨＴＴＰ）に指定するステップと、
前記複数個のサーバーに亘って前記第１のメディア処理資源を分散させるステップとを含む、請求項１−８のいずれか１項に記載の方法。
【請求項１０】
コンピュータに、
第１のメディア処理資源を要求するクライアントから、第１のプロトコルに従ってフォーマットされた第１の要求を受け取る手順と、
前記第１の要求を第２のプロトコルに従ってフォーマットされた第１のモーフされた要求にモーフィングする手順と、
前記要求された第１のメディア処理資源をそれぞれが与える複数個のサーバーからなる第１のサーバー・パーティションから、最も負荷が少ない第１のサーバーを選択する手順と、
前記第１のモーフされた要求を第２のプロトコルに従って前記第１のサーバーに転送する手順とを実行させるためのプログラムを記憶したコンピュータ読み取り可能な記録媒体。
【請求項１１】
複数個のサーバーの間でメディア資源を負荷分散するシステムであって、
第１のメディア処理資源を要求するクライアントから、第１のプロトコルに従ってフォーマットされた第１の要求を受け取り、そして、前記第１の要求を第２のプロトコルに従ってフォーマットされた第１のモーフされた要求にモーフィングするプロトコル・モーフ手段と、
前記要求された第１のメディア処理資源をそれぞれが与える複数個のサーバーからなる第１のサーバー・パーティションから、最も負荷が少ない第１のサーバーを選択し、そして、前記第１のモーフされた要求を第２のプロトコルに従って前記第１のサーバーに転送する負荷分散手段とを備える、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散された資源管理に関し、更に具体的にいうならば、分散されたメディア資源の管理に関する。
【背景技術】
【０００２】
自動音声認識装置（ＡＳＲ）及びテキスト音声合成装置（ＴＴＳ）は、例えば電話のコール・センターにおいて使用される自動音声応答システムにおけるような自動インタラクティブ・システムにおいて一般的に実装される音声資源である。ＡＲＳ及びＴＴＳは、資源消費型であり、そして、しばしば音声サーバー・ソリューションを構成する幾つかのマシンに亘って実装されなければならない。ハードウエアのコストを減少するために、一般的に、音声資源は、多くのクライアントにより共用され、そして、これらが実際に必要な時だけ割り当てられる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
メディア処理リソース制御プロトコル（Mediaprocessing resource Control Protocol,
ＭＲＣＰ）は, 例えばＡＳＲ及びＴＴＳ合成装置のような媒体処理資源を要求するクライアント装置にこのような資源をネットワーク上で制御するための機構を与える。特に、ＭＲＣＰは、メディア処理資源を制御するのに必要な要求、応答及びイベントを規定する。しかしながら残念なことに、ＭＲＣＰ標準は、クライアントがクライアント要求を分散させることを当てにするだけである。実際、ＭＲＣＰは、多数のノードに亘ってメディア処理資源を分散させるためにサーバーにより実装され得るメソッドを欠いている。更に、資源をアクセスするクライアントは、どのサーバー資源が利用可能なのか、そしてどのサーバー資源が現在使用されているかを知ることができない。従って、負荷分散の最も一般的な形は、クライアント・セッションが設立されるまで、クライアントが要求を種々なサーバーに逐次的に送る方法である。しかしながら、このような方法は、サーバーの負荷を適切に分散せず、ハードウエア効率を減少する。
【０００４】
従って、ＭＲＣＰサーバー・クラスタにそれ自身のメディア処理資源を分散させ、そしてこのような資源を負荷分散させる技術を提供することが有益である。
【課題を解決するための手段】
【０００５】
本発明は、複数個のサーバーに間でメディア資源を負荷分散するための方法及びシステムに関する。第１の要求は、第１のメディア処理資源を要求するクライアントから受け取られることができ、この要求は、第１のプロトコルに従ってフォーマットされる。第１の要求は、第２のプロトコルに従ってフォーマットされた第１のモーフされた（ｍｏｒｐｈｅｄ）要求フォーマットにモーフ即ち変換されることができる。要求された第１のメディア処理資源をそれぞれが提供する複数個のサーバーを含む第１のサーバー・パーティションから、最も負荷が小さい第１のサーバーが選択される。第１のモーフされた要求が、第２のプロトコルに従って第１のサーバーに転送される。
【０００６】
本発明の他の実施例は、コンピュータに本明細書で説明する種々な手順を実行させるためのプログラムを記憶するコンピュータ読み取り可能な記録媒体を含むことができる。
【発明を実施するための最良の形態】
【０００７】
本明細書に先立つ特許請求の範囲は、新規であると考える本発明の特徴を規定しているが、本発明は、図面と詳細な説明から更に良く理解されるであろう。要求を満たすように、本発明の詳細な実施例が開示されるが、開示する実施例は、種々な形で実施され得る本発明を説明するための例示的なものであることを理解されたい。従って、本明細書で開示する特定な構造及び機能の詳細は、限定的に解釈されるべきではなく、特許請求の範囲の論拠、そして、本発明を使用した適度に詳細な構成を当業者に知らしめる代表的な論拠となるであろう。更に、本明細書で使用する用語及び言い回しは、本発明を限定するものではなく、本発明の理解を助けるためのものである。
【０００８】
本明細書で開示する実施例は、メディア・リソース制御プロトコル（ＭＲＣＰ）資源を複数個のサーバーに亘って負荷分散するために使用されることができる方法及びシステムに関する。例えば、メディア処理資源を要求するＭＲＣＰメッセージは、ＴＣＰ／ＩＰソケットを介してプロトコル・モーファー／クライアントにより受け取られ、そして、標準的なハイパーテキスト転送プロトコル（ＨＴＴＰ）メッセージにモーフされる（ｍｏｒｐｈｅｄ）。次いで、ＨＴＴＰメッセージは、負荷分散装置に転送される。要求されたメディア処理資源をそれぞれが与える１組のサーバーの中から、負荷分散装置は、最も負荷が少ない１つのサーバーを選択し、そしてこの選択されたサーバーへＨＴＴＰプロトコルに従ってモーフされた要求を転送する。次の要求が負荷分散装置により受け取られると、この負荷分散装置は、１組のサーバーの中から最も負荷が少ないサーバーを再び選択し、そして次の要求をこのサーバーに送る。第２番目に選択されたサーバーは、最初に選択されたサーバーと同じでも良く、又は異なっても良い。
【０００９】
図１は、サーバー・クラスタ１０２を含むシステム１００を示すブロック図である。サーバー・クラスタ１０２は、複数個のサーバー、例えば、第１サーバー１０４，第２サーバー１０６，第３サーバー１０８及び第４サーバー１１０を含む。サーバー１０４，１０６，１０８及び１１０のそれぞれは、例えばＭＲＣＰサーバーのようなプロトコル・ベース・サーバーである。サーバー１０４，１０６，１０８及び１１０は、任意の適切な方法でネットワークに組み込まれることができる。例えばこれらのサーバーは、ローカル・エリア・ネットワーク（ＬＡＮ）、広域通信網（ＷＡＮ）、インターネット、または他の通信回路網を介して回路網化されることができる。
【００１０】
サーバー１０４，１０６，１０８及び１１０のそれぞれは、メディア処理資源を与えることができる。例えば、第１サーバー１０４及び第２サーバー１０６のそれぞれは、第１組のメディア処理資源１１２を与えることができる。同様に、第３サーバー１０８及び第４サーバー１１０は、第２組の処理資源１１４を与えることができる。メディア処理資源１１２及び１１４は、自動音声認識装置（ＡＳＲ）、テキスト音声合成装置（ＴＴＳ），話し手検証装置（ｓｐｅａｋｅｒ  ｖｅｒｉｆｉｅｒ）、デュアル・トーン・マルチ周波数（ＤＴＭＦ）認識装置、又はメディア要求を処理できる他の任意の資源であることができる。例えば、第１組のメディア処理資源１１２は、女性の声を発生するテキスト音声合成装置（ＴＴＳ）を含むことができ、そして、第２組のメディア処理資源１１４は、男性の声を発生するテキスト音声合成装置（ＴＴＳ）を含むことができる。
【００１１】
システム１００は又、例えば、クライアント１２０のような複数個のクライアントを含むことができる。クライアント１２０は、回路網を介してサーバー・クラスタ１０２に接続することができる任意のデバイスでもよく、そして、クライアントに対して、サーバー・クラスタ１０２は、メディア処理資源を提供する。例えば、クライアント１２０は、コンピュータ、電話、携帯電話、携帯情報端末、ゲーム機、インタラクティブ・アプライアンス、又は、ＬＡＮ，ＷＡＮ，インターネット、若しくは他の通信回路網を介してサーバ・クラスタ１０２により与えられるメディア処理資源をアクセスできる任意の他の装置でよい。１つのクライアント１２０だけが示されているが、システム１００は、メディア処理資源１１２及び１１４をアクセスする任意の数のクライアントを含むことができる。実際、メディア処理資源１１２及び１１４を分散させる本明細書で説明する方法は、複数のクライアントによるメディア処理資源１１２及び１１４の同時的は使用を容易にする。
【００１２】
クライアント１２０は、例えば、要求１５０のような第１メッセージを、モーフ制御装置１２２（これはサーバ・クラスタ１０２に通信可能にリンクされている）に伝播させることによりサーバ・クラスタ１０２と通信することができる。この要求１５０は、適切な通信プロトコルに従ってフォーマットされることができる。更に、クライアント１２０は、第１メッセージに応答する例えばイベント１５６のような第２メッセージを受け取ることができる。１つの配列においては、メッセージは、ＭＲＣＰに従ってフォーマットされ、そしてクライアント１２０とモーフ制御装置１２２との間で通信されることができる。
【００１３】
ＭＲＣＰバージョン１に従ってメッセージを通信するためには、クライアント１２０は、ＴＣＰ／ＩＰを介して動作する例えばリアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）を使用してモーフ制御装置１２２とユーザ・セッションを設立することができる。このようにしてメッセージを通信することは一般的には“トンネリング”を呼ばれる。ＭＲＣＰバージョン２に従ってメッセージを通信するためには、クライアント１２０は、セッション開始プロトコル（ＳＩＰ）を使用してユーザ・セッションを設立することができる。ＲＴＳＰと対照的に、ＳＩＰユーザ・セッションが設立された後は、メッセージは、トンネルされる代わりに、ＴＣＰ／ＩＰを介して直接的に送られる。
【００１４】
モーフ制御装置１２２は、ハードウエア、ソフトウエア、又はハードウエア及びソフトウエアの組み合わせにより実現されることができる。モーフ制御装置１２２は、１つの処理システム内に集合されて実現されることができ、又は、互いに異なる構成要素が幾つかの相互接続された処理システムに亘って分散されている分散型として実現されることができる。図１においては、サーバ・クラスタ１０２から独立した形で示されているが、モーフ制御装置１２２は、サーバ・クラスタ１０２の１つのコンポーネントとしてこの中に含まれることができる。
【００１５】
モーフ制御装置１２２は、要求１５０を受け取りそしてこの要求をモーフされた要求１５２にモーフィングする（ｍｏｒｐｈｉｎｇ）プロトコル・モーファー／クライアント１２４を含むことができる。モーフされた要求１５２は、最初の要求１５０がフォーマットされたプロトコルと異なるプロトコルに従ってフォーマットされることができる。例えば、プロトコル・モーファ／クライアント１２４は、ＭＲＣＰ要求からの要求１５０をＨＴＴＰ要求にモーフすることができる。要求１５０をモーフするために、この要求内のＭＲＣＰ指定コードは、関連性があるＨＴＴＰ指定コードに取り替えられる。以下の表１は、モーフされる前に要求１５０に含まれることができるコードの１例を示す。
【００１６】
表１：要求の例
ANNOUNCE rtsp://localhost/media/synthesizerRTSP/1.0
CSeq:1
Session 1.IBM.9.22.74.38
Date: Tue, 15 FEB2005 11:28:01 est
Content-Type:application/mrcp
Content-Length:149
SPEAK 100 MRCP/1.0
Voice-name: Andrew
Content-Type:application/synthesis+ssml
Content-length: 45
<?xmlversion=”1.0”?>
<speak>123.</speak>
【００１７】
表１に示されている要求をモーフするために、プロトコル・モーファ／クライアント１２４は、メッセージのＲＴＳＰ部分のコードを次のように変更することができる。
” ANNOUNCErtsp://localhost/media/synthesizer RTSP/1.0”を、次のものと取り替える。
“POST /synthesizerServlet HTTP 1.1”
“Host: myserver.bocaraton.ibm.com”
“user-agent=Java/1.4.1”
“accept=text/html,image/gif, image/jpeg, *; q=.2, */*; q=.2”
“connection=keep-alive”
【００１８】
この例において、メッセージのＭＲＣＰ部分は、変更されないまま残る。表２は、第１の要求１５０をこのようにしてモーファリングすることにより発生された、モーフされた要求１５２の例を示す。
【００１９】
表２：モーフされた要求の例＃１
POST/synthesizerServletHTTP 1.1
Host: myserver.bocaraton.ibm.com
user-agent=Java/1.4.1
accept=text/html,image/gif, image/jpeg, *; q=.2, */*;q=.2
connection=keep-alive
CSeq: 1
Session1.IBM.9.22.74.38
Date: Tue, 15 FEB2005 11:28:01 est
Content-Type:application/mrcp
Content-Length:149
SPEAK 100 MRCP/1.0
Voice-name: Andrew
Content-Type:application/synthesis+ssml
Content-length: 45
<?xml version=”1.0”?>
<speak>123.</speak>
【００２０】
他の例においては、プロトコル・モーファ／クライアント１２４は、次のようにメッセージのＲＴＳＰ部分のコードを変更することができる。
”ANNOUNCE rtsp://localhost/media/synthesizer RTSP/1.0”を次のものと取り替える。
“POST /synthesizerServlet HTTP 1.1”
“Host: myserver.bocaraton.ibm.com”
“User-agent=Java/1.4.1”
“accept=text/html, image/gif, image/jpeg, *;q=.2, */*; q=.2
“connection=keep-alive”
そして、次のものを除去する。
“Content-Type: application/mrcp”
“Content-length: 149”
【００２１】
この例において、メッセージのＭＲＣＰ部分のコードは、次のように変更される。
“SPEAK100 MRCP/1.0”を、”MRCPMethod:Speak”と取り替える。
このようにしてコードをモーファリングすることは、ＲＴＳＰメッセージ及びＭＲＣＰメッセージを組み合わせ、これは“SPEAK 100”を“MRCPMethod:Speak”に変更する。更に、メッセージのＲＴＳＰ部分から除去されたcontent-type(コンテンツの型)のヘッダ及びcontent-length（コンテンツの長さ）のヘッダの機能は、メッセージのＭＲＣＰ部分に既に含まれていた同様なコードにより取り扱われることができる。表３は、この例に従って、要求１５０をモーファリングすることにより発生された「モーファされた要求１５２」の例を示す。
【００２２】
表３：要求の例＃２
POST/synthesizerSernlet HTTP1.1
Host: myserver.bocaraton.ibm.com
user-agent=Java/1.4.1
accept=text/html,image/gif, image/jpeg, *;q=.2, */*; q=.2
connection=keep-alive
Cseq: 1
Session 1.IBM.9.22.74.38
Date: Tue, 15 FEB2005 11:28:01 est
MRCPMethod: Speak
voice-name: Andrew
Content-Type:application/synthesis+ssml
Content-length: 45
<?xmlversion=”1.0”?>
<speak>123.(/speak>
【００２３】
上述の処理を逆にすることにより、プロトコル・モーファ／クライアント１２４は又、モーフされた要求１５２に応答して発生されたイベント１５４を、ＭＲＣＰに従ってフォーマットされた「モーフされたイベント１５６」にモーフすることができる。例えば、第１イベント１５４内のＨＴＴＰの特定コードは、相関するＭＲＣＰの特定コードに取り替えられることができる。
【００２４】
プロトコル・モーファ／クライアント１２４は又、サーバー１０４，１０６，１０８及び１１０に対するクライアントとして働くことができる。例えば、プロトコル・モーファ／クライアント１２４は、ＨＴＴＰクライアントとして働くことができる。具体的にいうと、プロトコル・モーファ／クライアント１２４は、モーフされた要求１５２を負荷分散装置１３０に伝播させることができる。負荷分散装置１３０は、要求をサーバー１０４，１０６，１０８及び１１０へ送るディスパッチャ１３２を含む。特に、ディスパッチャ１３２は、モーファされた要求１５２をサーバー１０４，１０６，１０８及び１１０の１つへ送ることができる。この１つのサーバーとは、モーファされた要求１５２に応答するに適するメディア処理資源１１２，１１４を有し、そして、このようなメディア処理資源１１２，１１４を有するサーバーグループのうち負荷が最も少ないサーバーである。
【００２５】
例えば、ディスパッチャ１３２は、モーファされた要求１５２に応答するに適する、例えば第１パーティション１４０若しくは第２パーティション１４２のようなサーバー群の１つのパーティションを同定するために、資源選択ルール１３４をモーファされた要求１５２に適用する。例えば、ディスパッチャ１３２は、適切なメディア処理資源１１２，１１４を同定するために、モーファされた要求１５２の統一資源識別子（ＵＲＩ）のパターン又はコンテンツ型ヘッダあるいはその両方に資源選択ルール１３４を適用することができる。次いで、ディスパッチャ１３２は、どのパーティション、例えば第１パーティション１４０若しくは第２パーティション１４２が、同定された資源を与えるサーバーを含んでいるかを調べるために、パーティション識別子１３６を参照することができる。
【００２６】
更に具体的は例において、モーファされた要求１５２は、“音声＝リサ”及び“コンテンツの型＝ＴＴＳ”を含むコンテンツ型ヘッダを含むことができる。これの代わりに、“音声＝リサ”及び“コンテンツの型＝ＴＴＳ”を示す識別子は、モーファされた要求１５２のＵＲＩに含まれることができる。モーファされた要求１５２を受け取ったことに応答して、ディスパッチャ１３２は、“リサ”ＴＴＳを与えるメディア処理資源の型がメディア処理資源１１２であることを調べるために、資源選択ルール１３４を適用することができる。ディスパッチャ１３２は、第１サーバー１０４及び第２サーバー１０６を含む第１パーティション１４０を選択するために、パーティション識別子１３６を参照することができる。次いで、ディスパッチャ１３２は、サーバー１０４，１０６のそれぞれに対応するルーティング情報を含むルーティング・リストを参照し、そしてどのサーバーの負荷が最も少ないかを調べるためにサーバー１０４，１０６のそれぞれに質問することができる。
【００２７】
もしも１つの特定なサーバーがもはや利用不可能であるならば、例えば、このサーバーの接続が切断（オフ・ライン）されているならば、このサーバーは、ルーティン・リストから除去されることができる。従って、ディスパッチャ１３２は、オフ・ラインのサーバーを実質的に無視することができる。このサーバーが、オン・ラインに復帰すると、このサーバーは再びルーティン・リストに加えられることができる。このようにして、負荷分散装置１３０は又、負荷分散に加えてフェイルオーバー能力を与える。
【００２８】
どのサーバーが最も負荷が少ないかを調べた後に、ディスパッチャ１３２は、モーフされた要求１５２をそのサーバーに転送することができる。例えば、もしも第１サイバー１０４が最も負荷が少ないならば、ディスパッチャ１３２は、第１サーバー１０４のメディア処理資源１１２のＵＲＩを選択することができる。次いで、ディスパッチャ１３２は、モーフされた要求１５２をメディア・サーブレット１１６へ送ることにより第１サーバー１０４のメディア・サーブレット１１６を呼び出すことができる。メディア・サーブレット１１６，１１８は、複数個のサーバー・ノードに亘って分散されているサーブレットの例示をサポートする適切なミドルウエア・プラットフォームで実装されたＨＴＴＰサーブレットでも良い。このようなプラットフォームの例は、Ｊ２ＥＥであるが、本発明はこれに限定されない。
【００２９】
選択されたメディア処理資源１０４との相性（ａｆｆｉｎｉｔｙ、アフィニティ）を達成するために、プロトコル・モーファ／クライアント１２４は、クッキーズまたはユニフォーム・リソース・ロケータ（ＵＲＬ，統一資源位置指定子）再書き込みを有するクライアント・セッションをサポートすることができる。負荷分散装置１３０は又、プロトコル・モーファ／クライアント１２４及び要求されているメディア処理資源１０４との間の相性（アフィニティ）を維持するためにアフィニティ・サポート１３８を含むことができる。例えば、負荷分散装置１３０は、例えば、メディア処理資源への或る突出した要求を修正するとき、クッキーズに所望の環境に対する負荷分散ルーティンを消極的にバイパスさせるように構成されることができる。又、アフィニティ・サポートは、必要な場合にクッキー・アフィニティを付け加えることにより、プロトコル・モーファ／クライアント１２４に対するサーバーのアフィニティを得るように構成されることができる。
【００３０】
メディア・サーブレット１１６は、モーフされた要求１５２を解析し、そして、解析された要求１５２を、選択されたメディア処理資源１１２へ転送することができる。モーフされた要求１５２から解析された情報は、モーフされた要求１５２に応答してメディア処理資源１１２により発生されたイベント１５４が、コールバック・サーブレット１２６へ転送されることを示すために、コールバック・サーブレット１２６のＵＲＩを含むことができる。又、解析された情報は、イベント１５４が転送されるべきクライアント１２０を示すセッション識別子を含むことができる。
【００３１】
コールバック・サーブレット１２６は、プロトコル・モーファ／クライアント１２４に通信可能にリンクされることができる。コールバック・サーブレット１２６は、イベント１５４からのセッション識別子を解析し、そしてイベント１５４をプロトコル・モーファ／クライアント１２４に転送して、応答１５６が転送されるべき適切なクライアント１２０を示す。たとえば、コールバック・サーブレット１２６は、クライアント１２０のＵＲＬを与えることができる。次いで、プロトコル・モーファ／クライアント１２４は、イベント１５４を、モーフされたイベント１５６にモーフし、そしてこのモーフされたイベント１５６を、第１プロトコルに従うクライアント１２０へ転送することができる。例えば、プロトコル・モーファ／クライアント１２４は、ＭＲＣＰに従うモーファされたイベント１５６を転送することができる。
【００３２】
クライアント１２０若しくは他のクライアントからの第２の要求が受け取られると、最初の要求１５０について上で説明したプロセスが繰り返される。もしも第２の要求が、第１の要求と同じメディア処理資源１１２を要求し、そして、第１サーバー１０４が依然として最も負荷が少なければ、モーフされた要求は、再び第１サーバー１０４に転送されることができる。しかしながら、もしも第１サーバー１０４が、第１パーティション１４０内の最も負荷が少ないサーバーでなくなったならば、他の最も負荷が少ないサーバーが選択されることができる。例えば、現在、第２のサーバー１０６が、第１パーティション１４０内での最も負荷が少ないサーバーであるならば、この第２サーバー１０６が選択され、そして第２のモーフされた要求がこれに転送されることができる。
【００３３】
もしも第２の要求が、例えばメディア処理資源１１４のような、第１の要求の場合と異なるメディア処理資源を要求するならば、第２のモーフされた要求は、要求されたメディア処理資源１１４を有する他のサーバー、例えば第３サーバー１０８に転送されることができる。もしも第３サーバー１０８が第２パーティション１４２を構成するサーバーの中で最も負荷が少ないサーバーであるならば、この第２パーティション１４２からは第４サーバー１１０ではなく第３サーバー１０８が選択されることができる。
【００３４】
図２は、本発明の他の実施例に従うメディア処理資源を負荷分散する方法２００を示すフローチャートである。ステップ２０５で開始し、第１メディア処理資源を要求するクライアントからの第１要求が受け取られることができ、そしてこの要求は、第１プロトコルに従ってフォーマットされている。ステップ２１０において、第１要求は、第２プロトコルに従ってフォーマットされた第１のモーフされた要求にモーフされることができる。ステップ２１５において、要求された第１メディア処理資源をそれぞれが与えることができる複数個のサーバーを含む第１のサーバー・パーティションの中から最も負荷が少ない第１サーバーが、選択されることができる。ステップ２２０に進み、第１のモーフされた要求が、第２のプロトコルに従って第１のサーバーに転送されることができる。
【００３５】
ステップ２２５において、第２の要求がクライアントから受け取られることができる。第２の要求は、ステップ２３０に示すように、第２のプロトコルに従ってフォーマットされた第２のモーフされた要求にモーフされることができる。決定ブロック２３５を参照すると、もしも第１メディア処理資源が第２の要求により要求されるならば、動作は、決定ブロック２４０に進む。もしも第１サーバーが依然として第１パーティション内の最も負荷が少ないサーバーであるならば、ステップ２４５に示すように、第２のモーフされた要求が、第２プロトコルに従って第１サーバーに転送されることができる。しかしながら、もしも第１サーバーが最も少ない負荷のサーバーでないならば、ステップ２５０に示すように、最も負荷が少ない第２のサーバーが第２パーティションから選択されることができる。動作はステップ２６０に進み、第２のモーフされた要求が第２プロトコルに従って第２サーバーへ転送されることができる。
【００３６】
決定ブロック２３５及びステップ２５５を再び参照すると、もしも第１のメディア処理資源が第２の要求により選択されなければ、要求された第２のマルチメディア処理資源をそれぞれが与える複数個のサーバーからなる第２のサーバー・パーティションの中から最も負荷が少ない第２のサーバーが選択されることができる。ステップ２６０を再び参照すると、第２のモーフされた要求は、第２のプロトコルに従って第２のサーバーへ転送されることができる。
【００３７】
本発明は、ハードウエア、ソフトウエア又はハードウエア及びソフトウエアの組み合わせにより実現されることができる。本発明は、１つの処理システム内で集中方式で、又は異なる多数の構成要素が複数個の相互接続された処理システムに亘って分散されている分散方式で実現されることができる。いずれかの処理システム又は上述の方法を行うことができる他の装置が使用されることができる。ハードウエア及びソフトウエアの代表的な組み合わせは、詰め込まれそして実行されるときに上述の方法を実行するように処理システムを制御するアプリケーションを備えた汎用処理システムでもよい。本発明は、上述の方法の実装を可能とする全ての特徴を備えたアプリケーション製品、又は処理システムに詰め込まれたときに上述の方法を行うことができるプリケーション製品に組み込まれることができる。
【００３８】
本明細書中の用語“コンピュータ・プログラム”、“ソフトウエア”、“アプリケーション”、“バリアント”またはこれらの組み合わせあるいはその両方は、情報処理能力を有するシステムに、（ａ）他の言語、コード若しくは表記法への変換、及び（ｂ）異なる資料フォームでの再生のような特定な機能の両方又は一方を直接的に又は事後に達成させるように意図された１組の命令のコード、表記法若しくは任意の言語の表現を意味する。例えば、アプリケーションは、サブルーチン、機能、プロシージャ、オブジェクト・メソッド、オブジェクト・インプリメンテーション、実行可能なアプリケーション、アプレット、サーブレット、ソースコード、オブジェクトコード、共用されるライブラリィ／ダイナミック・ロード・ライブラリィまたは処理システム上での実行のために設計された他の命令シーケンスあるいはその両方を含むことができる。
【００３９】
本発明が、本発明の本質的特徴若しくは精神から逸脱することなく他の形で実現され得ることが明らかである。
【図面の簡単な説明】
【００４０】
【図１】メディア処理資源が本発明の一実施例に従って負荷分散されるシステムを示すブロック図である。
【図２】本発明の他の実施例に従うメディア処理資源を負荷分散させる方法を示すフローチャートである。
【符号の説明】
【００４１】
１００  システム
１０２  サーバー・クラスタ
１０４  第１サーバー
１０６  第２サーバー
１０８  第３サーバー
１１０  第４サーバー
１１２、１１４  メディア処理資源
１１６，１１８  メディア・サーブレット
１２０  クライアント
１２２  モーフ制御装置
１２４  プロトコル・モーファ／クライアント
１２６  コールバック・サーブレット
１３０  負荷分散装置
１３２  ディスパッチャ
１３４  ルール
１３６  パーティションＩＤ
１３８  アフィニティ・サポート
１４０  第１パーティション
１４２  第２パーティション
１５０  要求
１５２  モーフされた要求
１５４  イベント
１５６  モーフされたイベント
【図１】
2009519512.tif 000003
【図２】
2009519512.tif 000004
【国際調査報告】
2009519512.tif 000005
2009519512.tif 000006
2009519512.tif 000007