(57)【要約】【課題】融合サーバにおいて、各アプリケーションに係る複数のセッション間に依存関係を保持させたままレプリケーションを実行させることができる。【解決手段】本発明のセッション管理システムは、それぞれ異なるプロトコルのアプリケーションを管理する第１アプリケーション管理手段及び第２アプリケーション管理手段と、第１セッションのセッション情報を対応する第２セッションの識別情報に変換する第２セッション対応変換手段と、第２セッションの識別情報に基づいて対応する第２セッションを第２アプリケーション管理手段から検索する第２セッション検索手段と、第２セッションのセッション情報を対応する第１セッションの識別情報に変換する第１セッション対応変換手段と、第１セッションの識別情報に基づいて対応する第１セッションを第１アプリケーション管理手段から検索する第１セッション検索手段とを備えることを特徴とする。【選択図】      図１
2006350635.tif 000002
【特許請求の範囲】
【請求項１】
第１ネットワークプロトコルに基づくアプリケーションを管理すると共に、実行アプリケーションに係る第１セッションを管理する第１アプリケーション管理手段と、
第２ネットワークプロトコルに基づくアプリケーションを管理すると共に、実行アプリケーションに係る第２セッションを管理する第２アプリケーション管理手段と、
上記第１セッションのセッション情報に上記第２セッションと関連する旨の情報が含まれている場合に、上記第１セッションのセッション情報を対応する上記第２セッションの識別情報に変換する第２セッション対応変換手段と、
上記第１セッション情報のセッション情報が上記第２セッションの識別情報である場合に、上記第２セッションの識別情報に基づいて対応する第２セッションを上記第２アプリケーション管理手段から検索する第２セッション検索手段と、
上記第２セッションのセッション情報に上記第１セッションと関連する旨の情報が含まれている場合に、上記第２セッションのセッション情報を対応する上記第１セッションの識別情報に変換する第１セッション対応変換手段と、
上記第２セッション情報のセッション情報が上記第１セッションの識別情報である場合に、上記第１セッションの識別情報に基づいて対応する第１セッションを上記第１アプリケーション管理手段から検索する第１セッション検索手段と
を備えることを特徴とするセッション管理システム。
【請求項２】
第１ネットワークプロトコルに基づくアプリケーションを管理すると共に、実行アプリケーションに係る第１セッションを管理する第１アプリケーション管理工程と、
第２ネットワークプロトコルに基づくアプリケーションを管理すると共に、実行アプリケーションに係る第２セッションを管理する第２アプリケーション管理工程と、
上記第１セッションのセッション情報に上記第２セッションと関連する旨の情報が含まれている場合に、上記第１セッションのセッション情報を対応する上記第２セッションの識別情報に変換する第２セッション対応変換工程と、
上記第１セッション情報のセッション情報に上記第２セッションの識別情報がある場合に、上記第２セッションの識別情報に基づいて対応する第２セッションを上記第２アプリケーション管理手段から検索する第２セッション検索工程と、
上記第２セッションのセッション情報に上記第１セッションと関連する旨の情報が含まれている場合に、上記第２セッションのセッション情報を対応する上記第１セッションの識別情報に変換する第１セッション対応変換工程と、
上記第２セッション情報のセッション情報に上記第１セッションの識別情報がある場合に、上記第１セッションの識別情報に基づいて対応する第１セッションを上記第１アプリケーション管理手段から検索する第１セッション検索工程と
を備えることを特徴とするセッション管理方法。
【請求項３】
それぞれ異なる複数のネットワークプロトコルを利用した複数のアプリケーションを融合させたサービスを提供するサーバにおいて、上記複数のアプリケーションに係るセッション管理システムが、請求項１に記載のセッション管理システムに対応するものであることを特徴とするサーバ。
【請求項４】
あるサーバが実行アプリケーションに係るセッションを生成したときに、他の複数のサーバが利用可能なように上記セッションのレプリカを生成させる通信システムにおいて、上記各サーバが請求項３に記載のサーバであることを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、セッション管理システム、セッション管理方法、サーバ及び通信システムに関し、複数のネットワークプロトコルによるセッション間を管理するシステム、サーバ及び通信システムに適用し得る。
【背景技術】
【０００２】
近年、Ｗｅｂアプリケーションなどを開発する際に、アプリケーションサーバを利用したシステム構築が広く行われている。例えば、Ｊａｖａ環境におけるアプリケーションサーバ技術はＪ２ＥＥ（Ｊａｖａ  ２  Ｐｌａｔｆｏｒｍ，Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ）等が定義されている（非特許文献１参照）。
【０００３】
また、インターネットを利用したサービスとして、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を利用したＶｏＩＰ（Ｖｏｉｃｅ  Ｏｖｅｒ  ＩＰ）なども広く利用されている（非特許文献２参照）。例えば、ＳＩＰアプリケーションサーバの規格として非特許文献３に規定されるものがある。
【０００４】
一般に、これらのアプリケーションは独立して開発されることが多いが、複数のプロトコルを同時に制御することにより、付加価値の高いアプリケーションを提供することが可能となる。
【０００５】
このようなＨＴＴＰプロトコルとＳＩＰプロトコルとの両方を利用したアプリケーションの例として「クリックトゥーダイアル」などある。なお、クリックトゥーダイアルに関するＳＩＰの詳細動作は非特許文献４に記載されている。
【０００６】
従来のアプリケーションサーバ上でクリックトゥーダイアルを提供する動作について図２及び図３を参照して説明する。
【０００７】
図２は、非クラスタリング環境での従来のアプリケーションサーバの機能構成図である。アプリケーションサーバ１００は、ＨＴＴＰアプリケーションを動作させるＨＴＴＰサーブレットコンテナ１０１と、ＳＩＰアプリケーションを動作させるＳＩＰサーブレットコンテナ１０２とを備える。
【０００８】
図２において、アプリケーションサーバ１００は、発信者側の端末であるＷｅｂブラウザ１０５から通話要求（ＨＴＴＰプロトコル）があると、ＨＴＴＰサーブレットコンテナ１０１に与えられる。
【０００９】
ＨＴＴＰサーブレットコンテナ１０１は、そのリクエストに対するＨＴＴＰアプリケーション１０３を動作させ、ＨＴＴＰセッション１０８を生成させると共に、ＳＩＰアプリケーション１０４に対して通話要求を通知する。
【００１０】
一方、ＳＩＰアプリケーション１０４は、通話要求に応じた３ＰＣＣ（第三者呼制御機能）処理を管理するためのＡＰセッション１０９を生成し、受信者側のソフトフォン１０７への接続要求に係るＳＩＰセッション１１１と発信者側のソフトフォン１０６への接続要求に係るＳＩＰセッション１１０とを作成し、ＡＰセッション１０９とＳＩＰセッション１１０及び１１１とを関連付ける。
【００１１】
なお、ＡＰセッション１０９は、ＳＩＰ  Ｓｅｒｖｌｅｔ  ＡＰＩでのＳｉｐ  Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｓｓｉｏｎオブジェクトに相当する。
【００１２】
そして、発信者が接続要求に応じると、ＳＩＰアプリケーション１０４は、ＳＩＰセッション１１０及び１１１間で送受信されるＳＩＰメッセージを、Ｂ２ＢＵＡ（Ｂａｃｋ  Ｔｏ  Ｂａｃｋ  Ｕｓｅｒ  Ａｇｅｎｔ）として仲介し、発信者と受信者との間の通話を実現する。
【００１３】
さらに、ＳＩＰアプリケーション１０４が３ＰＣＣ処理のきっかけとなったＨＴＴＰセッション１０８をＡＰセッション１０９に関連付けることで、発信者は、上記の処理中にＷｅｂブラウザ１０５を利用して、通話のキャンセルや切断をＨＴＴＰプロトコル経由で要求した場合でも適切な呼が選択できるようにする。
【００１４】
続いて、クラスタリング環境での従来のアプリケーションサーバ上で提供するクリックトゥーダイアルの動作について図３を参照して説明する。
【００１５】
図３において、セカンダリサーバ２０３は、プライマリサーバ２０２のレプリケーション先として利用されるサーバであり、プライマリサーバ２０２上で作成されたＨＴＴＰセッションやＳＩＰセッションはすべてセカンダリサーバ２０３上にレプリカが作成されるものとする。
【００１６】
プライマリサーバ２０２は、発信者側の端末であるＷｅｂブラウザ２１２から通話要求（ＨＴＴＰプロトコル）があると、ＨＴＴＰ／ＳＩＰロードバランサ２０１を経由して、ＨＴＴＰサーブレットコンテナ２０４に与えられる。
【００１７】
ＨＴＴＰサーブレットコンテナ２０４は、そのリクエストに対するＨＴＴＰアプリケーション２０６を動作させ、ＨＴＴＰセッション２１５を生成させると共に、ＳＩＰアプリケーション２０７に対して通話要求を通知する。このとき、ＨＴＴＰサーブレットコンテナ２０４はＨＴＴＰサーブレットコンテナ２０８と連携して、ＨＴＴＰセッション２１５のレプリカ（ＨＴＴＰセッション２１９）をセカンダリサーバ２０３上に生成させる。
【００１８】
一方、ＳＩＰアプリケーション２０７がＨＴＴＰアプリケーション２０６からの発信要求に対応する３ＰＰＣ処理を管理するためのＡＰセッション２１６を生成すると、ＳＩＰサーブレットコンテナ２０５はＳＩＰサーブレットコンテナ２０９と連携して、ＡＰセッション２１６のレプリカ（ＡＰセッション２２３）をセカンダリサーバ２０３上に生成させる。同様に、ＳＩＰセッションがＳＩＰセッション２１８及びＳＩＰセッション２１７を生成すると、ＳＩＰサーブレットコンテナ２０５はＳＩＰサーブレットコンテナ２０９と連携して、セカンダリサーバ２０３上でＳＩＰセッション２１８のレプリカ（ＳＩＰセッション２２２）及びＳＩＰセッション２１７のレプリカ（ＳＩＰセッション２２１）を生成させる。
【００１９】
以上のように、プライマリサーバ２０２上で生成させたＨＴＴＰセッション、ＡＰセッション、ＳＩＰセッションのそれぞれは、セカンダリサーバ２０３上でレプリカとして作成される。また、各セッションのレプリカは、セッションの内部状態が変化した場合でも常に最新の内部状態が反映されるように、各コンテナ間の連携により更新動作される。
【００２０】
【非特許文献１】Ｊａｖａ  ２  Ｐｌａｔｆｏｒｍ，Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ（Ｊ２ＥＥ）.[Ｏｎｌｉｎｅ]．Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ.[２００５年５月６日検索]．<ｈｔｔｐ：／／ｊａｖａ．ｓｕｎ．ｃｏｍ／ｊ２ｅｅ／ｉｎｔｅｘ．ｊｓｐ>
【非特許文献２】Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ，Ｎｅｔｗｏｒｋ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ，Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ：３２６１，[２００５年５月６日検索]，<ｈｔｔｐ／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３２６１．ｔｘｔ>
【非特許文献３】ＪＳＲ−０００１１６  ＳＩＰ  Ｓｅｒｖｌｅｔ  ＡＰＩ，[Ｏｎｌｉｎｅ]，Ｊａｖａ  Ｃｏｍｍｕｎｉｔｙ  Ｐｒｏｓｅｓｓ，[２００５年５月６日検索]，<ｈｔｔｐ／／ｗｗｗ．ｊｃｐ．ｏｒｇ／ａｂｏｕｔＪａｖａ／ｃｏｍｍｕｎｉｔｙｐｒｏｃｅｓｓ／ｆｉｎａｌ／ｊｓｒ１１６／>
【非特許文献４】Ｂｅｓｔ  Ｃｕｒｒｅｎｔ  Ｐｒａｃｔｉｃｅｓ  ｆｏｒ  Ｔｈｉｒｄ  Ｐａｒｔｙ  Ｃａｌｌ  Ｃｏｎｔｒｏｌ（３ｐｃｃ）ｉｎ  ｔｈｅ  Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＳＩＰ），Ｎｅｔｗｏｒｋ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ，Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ：３７２５，[２００５年５月６日検索]，<ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３７２５．ｔｘｔ>
【発明の開示】
【発明が解決しようとする課題】
【００２１】
しかしながら、上述した図３に示すような、複数のプロトコルを制御するアプリケーションを従来のレプリケーション機能だけを備えたアプリケーションサーバ上で動作させる場合には次のような問題点があった。
【００２２】
図３において、プライマリザーバ２０２上のＨＴＴＰサーブレットコンテナ２０４がＨＴＴＰセッション２１５のレプリカをセカンダリサーバ２０３上に作成又は更新する時で、かつ、ＨＴＴＰセッションの属性情報にＡＰセッション２１６又はＳＩＰセッション２１７、２１８を格納している場合、ＨＴＴＰサーブレットコンテナ２０８はＡＰセッションなどの復元オブジェクト２２３を作成し、ＨＴＴＰセッション２１９のレプリカは、復元オブジェクト２２３への参照をＨＴＴＰセッション属性として有するものとなる。
【００２３】
また、同様に、プライマリサーバ２０２上のＳＩＰサーブレットコンテナ２０５がＡＰセッション２１６又はＳＩＰセッション２１７、２１８のレプリカをセカンダリサーバ２０３上に作成又は更新する時で、かつ、ＡＰセッションの内部情報又はＳＩＰセッションの属性情報にＨＴＴＰセッション２１５を格納している場合、ＳＩＰサーブレットコンテナ２０９は、ＨＴＴＰセッションの復元オブジェクト２２４を作成し、ＡＰセッション２１６又はＳＩＰセッション２１７及び２１８のレプリカ（ＡＰセッション２２０、ＳＩＰセッション２２１、ＳＩＰセッション２２２）は、復元オブジェクト２２４ヘの参照をＳＩＰセッション属性として有するものとなる。
【００２４】
すなわち、プライマリサーバ２０２上で設定したＨＴＴＰ／ＳＩＰセッション間の連携情報は、セカンダリサーバ２０３上にレプリケーションした時点で互いに切断され、別々のセッション情報として管理されることになる。
【００２５】
これにより、プライマリサーバ２０２がダウンし、ＨＴＴＰ／ＳＩＰロードバランサ２０１が後続のＨＴＴＰ／ＳＩＰメッセージをセカンダリサーバ２０３に配送したとしても、ＨＴＴＰ／ＳＩＰ連携アプリケーションが期待通りに動作しなくなる。すなわち、ＳＩＰだけ又はＨＴＴＰだけのアプリケーションであれば、正常に動作し続けるが、前述のようにＷｅｂブラウザからのＨＴＴＰリクエストにより、ＳＩＰ接続を切断させるなどの処理ができなくなるという問題がある。
【００２６】
そこで、複数のネットワークプロトコルに基づいて、それぞれのアプリケーションを実行させることができるサーバにおいて、各アプリケーションに係る複数のセッション間に依存関係を保持させたままレプリケーションを実行させることができるセッション管理システム、セッション管理方法、サーバ及び通信システムが求められている。
【課題を解決するための手段】
【００２７】
かかる課題を解決するために、第１の本発明のセッション管理システムは、（１）第１ネットワークプロトコルに基づくアプリケーションを管理すると共に、実行アプリケーションに係る第１セッションを管理する第１アプリケーション管理手段と、（２）第２ネットワークプロトコルに基づくアプリケーションを管理すると共に、実行アプリケーションに係る第２セッションを管理する第２アプリケーション管理手段と、（３）第１セッションのセッション情報に、第２セッションと関連する旨の情報が含まれている場合に、第１セッションのセッション情報を対応する第２セッションの識別情報に変換する第２セッション対応変換手段と、（４）第１セッション情報のセッション情報が第２セッションの識別情報である場合に、第２セッションの識別情報に基づいて対応する第２セッションを第２アプリケーション管理手段から検索する第２セッション検索手段と、（５）第２セッションのセッション情報に、第１セッションと関連する旨の情報が含まれている場合に、第２セッションのセッション情報を対応する第１セッションの識別情報に変換する第１セッション対応変換手段と、（６）第２セッション情報のセッション情報が第１セッションの識別情報である場合に、第１セッションの識別情報に基づいて対応する第１セッションを第１アプリケーション管理手段から検索する第１セッション検索手段とを備えることを特徴とする。
【００２８】
第２の本発明のセッション管理方法は、（１）第１ネットワークプロトコルに基づくアプリケーションを管理すると共に、実行アプリケーションに係る第１セッションを管理する第１アプリケーション管理工程と、（２）第２ネットワークプロトコルに基づくアプリケーションを管理すると共に、実行アプリケーションに係る第２セッションを管理する第２アプリケーション管理工程と、（３）第１セッションのセッション情報に、第２セッションと関連する旨の情報が含まれている場合に、第１セッションのセッション情報を対応する第２セッションの識別情報に変換する第２セッション対応変換工程と、（４）第１セッション情報のセッション情報に第２セッションの識別情報がある場合に、第２セッションの識別情報に基づいて対応する第２セッションを第２アプリケーション管理手段から検索する第２セッション検索工程と、（５）第２セッションのセッション情報に、第１セッションと関連する旨の情報が含まれている場合に、第２セッションのセッション情報を対応する第１セッションの識別情報に変換する第１セッション対応変換工程と、（６）第２セッション情報のセッション情報に第１セッションの識別情報がある場合に、第１セッションの識別情報に基づいて対応する第１セッションを第１アプリケーション管理手段から検索する第１セッション検索工程とを備えることを特徴とする。
【００２９】
第３の本発明のサーバは、それぞれ異なる複数のネットワークプロトコルを利用した複数のアプリケーションを融合させたサービスを提供するサーバにおいて、複数のアプリケーションに係るセッション管理システムが、第１の本発明のセッション管理システムに対応するものであることを特徴とする。
【００３０】
第４の本発明の通信システムは、あるサーバが実行アプリケーションに係るセッションを生成したときに、他の複数のサーバが利用可能なようにセッションのレプリカを生成させる通信システムにおいて、各サーバが第３の本発明のサーバであることを特徴とする。
【発明の効果】
【００３１】
本発明によれば、複数のネットワークプロトコルに基づいて、それぞれのアプリケーションを実行させることができるサーバにおいて、各アプリケーションに係る複数のセッション間に依存関係を保持させたままレプリケーションを実行させることができる。
【発明を実施するための最良の形態】
【００３２】
（Ａ）第１の実施形態
以下、本発明のセッション管理システム、セッション管理方法、サーバ及び通信システムの第１の実施形態について図面を参照して説明する。
【００３３】
本実施形態は、ＨＴＴＰプロトコルとＳＩＰプロトコルとの２種類のネットワークプロトコルを利用することができるアプリケーションサーバに、本発明のサーバを適用した場合を示す。
【００３４】
（Ａ−１）第１の実施形態の構成
図１は、本発明のアプリケーションサーバの内部構成を示す機能ブロック図である。
【００３５】
図１に示すように、本実施形態のアプリケーションサーバ３００は、ＨＴＴＰサーブレットコンテナ３０１、ＳＩＰサーブレットコンテナ３０２を備える。
【００３６】
ＨＴＴＰサーブレットコンテナ３０１は、アプリケーション開発者が作成したＨＴＴＰサーブレット技術に準拠したＨＴＴＰアプリケーション３０３を動作させるものである。ＨＴＴＰサーブレットコンテナ３０１は、例えばネットワークを通じて図示しないクライアント端末（例えばＷｅｂ端末）から所望のＨＴＴＰリクエストを受信すると、そのＨＴＴＰリクエストに対応する所定のＨＴＴＰアプリケーションを立ち上げて動作させるものである。また、ＨＴＴＰサーブレットコンテナ３０１は、レプリケーション処理時に使用するＳＩＰセッション／ＩＤ変換モジュール３０５を有する。
【００３７】
ＳＩＰセッション／ＩＤ変換モジュール３０５は、レプリケーション処理の際に、プライマリサーバ上において、レプリケーション対象となるＨＴＴＰセッションの属性情報に基づいて、当該ＨＴＴＰセッションがＡＰセッション又はＳＩＰセッションと関連付けられているものである場合に、それらセッション情報をセッションＩＤに変換するものである。
【００３８】
また、ＳＩＰセッション／ＩＤ変換モジュール３０５は、セカンダリサーバ上において、プライマリサーバから与えられた復元対象の永続化データが、ＡＰセッション又はＳＩＰセッションのセッションＩＤである場合には、セッション検索モジュール３０７を利用して、当該セッションＩＤに対応するＡＰセッション又はＳＩＰセッションを取得するものである。
【００３９】
ＳＩＰサーブレットコンテナ３０２は、アプリケーション開発者が作成したＳＩＰサーブレット技術に準拠したＳＩＰアプリケーションを動作させるものである。また、ＳＩＰサーブレットコンテナ３０２は、レプリケーション処理時に使用するＨＴＴＰセッション／ＩＤ変換モジュール３０６を有する。
【００４０】
ＨＴＴＰセッション／ＩＤ変換モジュール３０６は、レプリケーション処理の際に、プライマリサーバ上において、レプリケーション対象となるＡＰセッションの属性情報に基づいて、当該ＡＰセッションがＨＴＴＰセッションと関連付けられているものである場合に、それらセッション情報をセッションＩＤに変換するものである。
【００４１】
また、ＨＴＴＰセッション／ＩＤ変換モジュール３０６は、セカンダリサーバ上において、プライマリサーバから与えられた復元対象の永続化データが、ＨＴＴＰセッションのセッションＩＤである場合には、セッション検索モジュール３０７を利用して、当該セッションＩＤに対応するＨＴＴＰセッションを取得するものである。
【００４２】
ＨＴＴＰサーブレットコンテナ３０１とＳＩＰサーブレットコンテナ３０２とは、それぞれのコンテナが管理するセッション情報をセッションＩＤから検索するセッション検索機能３０７を備え、相互のコンテナ間での呼び出しが可能である。
【００４３】
次に、本実施形態に係るアプリケーションサーバを複数用いて、クラスタリング環境でセッション管理するシステムの構成について説明する。
【００４４】
図４は、図３で説明した２台のアプリケーションサーバ上でクリックトゥーダイアルを提供する機能構成図である。
【００４５】
図４に示す本実施形態のシステムは、２台のアプリケーションサーバであるプライマリサーバ４０２及びセカンダリサーバ４０３、ＨＴＴＰ／ＳＩＰロードバランス４０１、発信者側端末のＷｅｂブラウザ４１２及び第１のソフトフォン４１３、受信者側の端末の第２のソフトフォン４１４を有して構成される。
【００４６】
ＨＴＴＰ／ＳＩＰロードバランサ４０１は、ＨＴＴＰプロトコル及びＳＩＰプロトコルに対応した負荷分散装置であり、クリックトゥーダイアル処理実行の際、クラスタ環境内で障害が発生しない限り、ＨＴＴＰ、ＳＩＰ共に同じサーバが選択され続けるように設定されているものとする。また、ＨＴＴＰ／ＳＩＰロードバランス４０１は、受信したリクエストをどのサーバに与えるかを決定するサーバ決定部を有しており、そのサーバ決定機能により決定されたアプリケーションサーバにリクエストを配送するものである。なお、一般的に、サーバ決定手段は、クリックトゥーダイアル処理の場合、各クリックトゥーダイアル処理毎に決定する。さらに、ＨＴＴＰ／ＳＩＰロードバランサ４０１は、プライマリサーバ４０２がシステム障害などの理由によりサービスを停止した場合、プライマリサーバ４０２に配送していたすべてのＨＴＴＰ／ＳＩＰメッセージをセカンダリサーバ４０３に配送するものである。
【００４７】
プライマリサーバ４０２とセカンダリサーバ４０３は共に対応する機能を有するアプリケーションサーバであり、ＨＴＴＰ／ＳＩＰロードバランサ４０１により決定されたサーバがプライマリサーバとなる。
【００４８】
プライマリサーバ４０２は、ＨＴＴＰ／ＳＩＰロードバランス４０１から与えられたリクエストに基づいてアプリケーションを動作させるアプリケーションサーバであり、セッション情報のレプリカをセカンダリサーバ４０３上に作成させるものである。
【００４９】
セカンダリサーバ４０３は、プライマリサーバ４０２がセッション情報のレプリケーション先として利用するアプリケーションサーバであり、プライマリサーバ４０２上で作成されたＨＴＴＰセッションやＳＩＰセッションはすべてセカンダリサーバ４０３上にレプリカが作成される。
【００５０】
プライマリサーバ４０２は、ＨＴＴＰサーブレットコンテナ４０４、ＨＴＴＰアプリケーション４０６、ＳＩＰサーブレットコンテナ４０５、ＳＩＰアプリケーション４０７を備え、また、セカンダリサーバ４０３は、ＨＴＴＰサーブレットコンテナ４０８、ＨＴＴＰアプリケーション４１０、ＳＩＰサーブレットコンテナ４０９、ＳＩＰアプリケーション４１１を備える。これらは、図３で説明したコンテナ、アプリケーションに対応するものである。
【００５１】
（Ａ−２）第１の実施形態の動作
以下、このような構成を備えるクラスタリング環境でのクリックトゥーダイアルの動作について図４を参照しながら説明する。
【００５２】
まず、発信者がＷｅｂブラウザ４１２を用いて、受信者との通話を要求する。この通話要求はＨＴＴＰプロトコルにより、ＨＴＴＰ／ＳＩＰロードバランサ４０１に到達する（Ｓ１）。
【００５３】
通話要求がロードバランサ４０１に与えられると、ロードバランサ４０１は、予め設定されているサーバ選択手段により決定されたアプリケーションサーバに対してＨＴＴＰリクエストを与える。本実施形態では、ロードバランサ４０１は、プライマリサーバ４０２にＨＴＴＰリクエストを与えるものとする（Ｓ２）。
【００５４】
ロードバランサ４０１からＨＴＴＰリクエストが与えられると、プライマリサーバ４０２上のＨＴＴＰサーブレットコンテナ４０４が、ＨＴＴＰリクエストを受信する（Ｓ３）。
【００５５】
ＨＴＴＰサーブレットコンテナ４０４は、ＨＴＴＰリクエストを受信すると、そのＨＴＴＰリクエストに含まれているＵＲＩ情報に基づいて、ＨＴＴＰリクエストを適切なＨＴＴＰアプリケーション４０６に配送する（Ｓ４）。
【００５６】
ＨＴＴＰリクエストを受信したＨＴＴＰアプリケーション４０６は、受け取ったＨＴＴＰリクエストを他のＨＴＴＰリクエストと関連付けるためにＨＴＴＰセッション４１５を生成する（Ｓ５）。
【００５７】
また、ＨＴＴＰアプリケーション４０６は、受信したＨＴＴＰリクエストの内容を判断し、当該リクエストが通話開始要求であると判別すると、通話要求をＳＩＰアプリケーション４０７に通知する（Ｓ６）。
【００５８】
ここで、ＨＴＴＰセッション４１５を生成するタイミングは、通話要求のリクエストを受信した時点に限定されず、例えば、それ以前のＨＴＴＰアプリケーション４０６ヘのログイン時などであっても構わない。
【００５９】
また、ＨＴＴＰサーブレットコンテナ４０４は、ＨＴＴＰアプリケーション４０６がＨＴＴＰセッション４１５を作成すると、ＨＴＴＰサーブレットコンテナ４０８と連携をとり、ＨＴＴＰセッション４１５のレプリカ（ＨＴＴＰセッション４１９）をセカンダリサーバ４０３上に作成させる（Ｓ７）。
【００６０】
このとき、レプリカ（ＨＴＴＰセッション４１９）は、ＨＴＴＰセッション４１５が削除されるまで、セカンダリサーバ４０３上に存在し、またＨＴＴＰセッション４１５の状態変更に応じて更新される。
【００６１】
ここで、ＨＴＴＰセッション４１５のレプリカ（ＨＴＴＰセッション４１９）を生成する際、ＨＴＴＰサーブレットコンテナ４０４とＨＴＴＰサーブレットコンテナ４０８との間で、次のような処理を行う。
【００６２】
まず、プライマリサーバ４０２のＨＴＴＰサーブレットコンテナ４０４において、ＨＴＴＰサーブレットコンテナ４０４が、レプリケーション対象であるＨＴＴＰセッション４１５の属性情報に基づいて、ＡＰセッション又はＳＩＰセッションが含まれているか否かを判断する。これにより、当該ＨＴＴＰセッションが既に生成されている関連するＡＰセッション又はＳＩＰセッションと関連するものであるかどうかを判断することができる。
【００６３】
そして、ＨＴＴＰセッション４１５にＡＰセッション又はＳＩＰセッションが含まれているとＨＴＴＰサーブレットコンテナ４０４が判断した場合、ＳＩＰセッション／ＩＤ変換モジュール４２３は、これらのセッション情報をセッションＩＤに変換する。これにより、ＡＰセッション又はＳＩＰセッションの情報を、セッションＩＤと対応付けることができる。なお、ＨＴＴＰセッション４１５の属性情報にＡＰセッション又はＳＩＰセッションが含まれていない場合には、従来と同様のレプリカ処理がなされる。
【００６４】
一方、セカンダリサーバ４０３のＨＴＴＰサーブレットコンテナ４０８において、ＨＴＴＰサーブレットコンテナ４０８は、ＨＴＴＰサーブレットコンテナ４０４から与えられた復元対象の永続化データがＡＰセッション又はＳＩＰセッションのセッションＩＤである場合、ＳＩＰセッション／ＩＤ変換モジュール４２６はセッション検索モジュール４２８を利用して、ＳＩＰサーブレットコンテナ４０９からセッションＩＤに対応したＡＰセッション又はＳＩＰセッションのオブジェクトを獲得する。それ以外の場合は、従来通りにレプリカ復元処理を実施する。
【００６５】
Ｓ６において、ＳＩＰアプリケーション４０７がＨＴＴＰアプリケーション４０６から通話要求を受けると、ＳＩＰアプリケーション４０７は、その要求に対応する３ＰＣＣ処理を管理するためのＡＰセッション４１６を生成する（Ｓ８）。
【００６６】
ＳＩＰアプリケーション４０７がＡＰセッション４１６を生成すると、ＳＩＰサーブレットコンテナ４０５は、ＳＩＰサーブレットコンテナ４０９と連携して、ＡＰセッション４１６のレプリカ４２０をセカンダリサーバ４０３上に作成する（Ｓ９）。
【００６７】
ここで、ＡＰセッション４１６のレプリカ（ＡＰセッション４２０）を作成する際、ＳＩＰサーブレットコンテナ４０５とＳＩＰサーブレットコンテナ４０９との間で、次のような処理が行われる。
【００６８】
まず、プライマリサーバ４０２のＳＩＰサーブレットコンテナ４０５において、ＳＩＰサーブレットコンテナ４０５が、レプリケーション対象であるＡＰセッション４１６の属性情報に基づいて、関連付けられたＨＴＴＰセッションあるか、または、ＡＰセッション又はＳＩＰセッションの属性情報として登録されたＨＴＴＰセッションがあるか否かを判断する。
【００６９】
そして、ＳＩＰセッション４１６に関連付けられたＨＴＴＰセッションがあると判断された場合、ＨＴＴＰセッション／ＩＤ変換モジュール４２４は、これらＨＴＴＰセッション情報をセッションＩＤに変換する。なお、ＡＰセッション４１６の属性情報に関連付けられたＨＴＴＰセッションがない場合には従来と同様のレプリカ処理がなされる。
【００７０】
一方、セカンダリサーバ４０３のＳＩＰサーブレットコンテナ４０９において、ＳＩＰサーブレットコンテナ４０９は、ＳＩＰサーブレットコンテナ４０５から与えられた復元対象の永続化データがＨＴＴＰセッションのセッションＩＤである場合、ＨＴＴＰセッション／ＩＤ変換モジュール４２７はセッション検索モジュール４２８を利用して、ＨＴＴＰサーブレットコンテナ４０８からセッションＩＤに対応したＨＴＴＰセッションのオブジェクトを獲得する。それ以外の場合は、従来通りにレプリカ復元処理を実施する。
【００７１】
このようにすることで、ＡＰセッションに関連付けられたＨＴＴＰセッションを多重に復元することなく、既に復元済みのＨＴＴＰセッション４１９への参照が復元される。
【００７２】
続いて、ＳＩＰアプリケーション４０７は、第１のＳＩＰセッション４１８を作成し、受信者側に存在する第２のソフトフォン４１４に対してＳＩＰプロトコルに従った接続要求を送信する（Ｓ１０）。
【００７３】
また、ＳＩＰサーブレットコンテナ４０５は、ＳＩＰサーブレットコンテナ４０９と連携し、ＳＩＰセッション４１８のレプリカ４２２を、セカンダリサーバ４０３上で作成させる（Ｓ１１）。
【００７４】
そして、プライマリサーバ４０２からの接続要求に対し受信者側のソフトフォン４１４から応答があると、プライマリサーバ４０２のＳＩＰサーブレットコンテナ４０５は、第２のＳＩＰセッション４１７を作成し、発信者側の第１のソフトフォン４１３に接続要求を送信する（Ｓ１２）。
【００７５】
また、ＳＩＰサーブレットコンテナ４０５は、ＳＩＰサーブレットコンテナ４０９と連携し、ＳＩＰセッション４１７のレプリカ４２１を、セカンダリサーバ４０３上で作成させる（Ｓ１３）。
【００７６】
その後、発信者側が接続要求に応じると、ＳＩＰアプリケーション４０７は第１のＳＩＰセッション４１８及び第２のＳＩＰセッション４１７間で送受信されるＳＩＰメッセージをＢ２ＢＵＡとして仲介することで、発信者と受信者との間の通話を実現する。
【００７７】
また、ＳＩＰサーブレットコンテナ４０５は、第１のＳＩＰセッション４１８又は第２のＳＩＰセッション４１７が更新されるたびに、それらのレプリカ４２２及び４２１も更新される。
【００７８】
ＳＩＰセッション４１７及び４１８のレプリケーション処理においても、ＡＰセッション４１６のレプリケーション処理と同様に、ＨＴＴＰセッション／ＩＤ変換モジュール４２４及び４２７を利用することで、仮にＳＩＰセッションにＨＴＴＰセッションが関連付けられたとしても、これを多重に復元することなく、既に復元済みのＨＴＴＰセッションヘの参照として復元することができる。
【００７９】
（Ａ−３）第１の実施形態の効果
以上のように、本実施形態によれば、詳細に説明したように本発明によるセッション管理方式であれば、複数のプロトコルをサポートしたアプリケーションサーバであっても、セッション間の依存関係を壊すことなく、レプリケーション処理を実行することができる。
【００８０】
（Ｂ）他の実施形態
上述した実施形態では、ＨＴＴＰプロトコルとＳＩＰプロトコルをサポートしたアプリケーションサーバについて説明したが、適用するプロトコルはこれに限定されず、他のプロトコルであっても構わないし、また３つ以上のプロトコルをサポートしたアプリケーションサーバであっても構わない。
【００８１】
上述した実施形態では、それぞれのコンテナ（ＨＴＴＰサーブレットコンテナなど）が他プロトコルのセッション／ＩＤ変換モジュールを備えるものとして説明したが、どちらか一方のコンテナが、両方のセッション／ＩＤ変換処理を担当するように配置することが可能である。
【００８２】
また、セッション／ＩＤ変換モジュールでは、セッションオブジェクトをセッションＩＤに変換／復元することで、レプリケーションを実施するように説明したが、セッションＩＤ以外の手段を永続化情報として使用しても構わない。
【図面の簡単な説明】
【００８３】
【図１】第１の実施形態のアプリケーションサーバの機能ブロック図である。
【図２】従来のアプリケーションサーバの機能ブロック図である。
【図３】従来のクラスタリング環境での通信システムの構成図である。
【図４】第１の実施形態のクラスタリング環境での通信システムの構成図である。
【符号の説明】
【００８４】
１…通信システム、３００、４０２及び４０３…アプリケーションサーバ、３０１、４０４及び４０８…ＨＴＴＰサーブレットコンテナ、３０２、４０５及び４０９…ＳＩＰサーブレットコンテナ、３０３、４０６及び４１０…ＨＴＴＰアプリケーション、３０４、４０７及び４１１…ＳＩＰアプリケーション、３０５、４２３及び４２６…ＳＩＰセッション／ＩＤ変換モジュール、３０６、４２４及び４２７…ＨＴＴＰセッション／ＩＤ変換モジュール、３０７、４２５及び４２８…セッション検索モジュール。
【図１】
2006350635.tif 000003
【図２】
2006350635.tif 000004
【図３】
2006350635.tif 000005
【図４】
2006350635.tif 000006