JP4735068B2 - 通信システム、通信方法及び通信装置 - Google Patents

Description

本発明は、通信システム、通信方法及び通信装置に関し、例えば、Ｗｅｂ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）環境上のＡＰ（Ａｐｐｌｉｃａｔｉｏｎ：アプリケーションソフトウェア）を提供するＷｅｂ−ＡＰサーバ環境と、ＶｏＩＰ（Ｖｏｉｃｅ Ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を実現する代表的なプロトコルであるＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）によるＶｏＩＰサーバ環境（ＳＩＰサーバ環境）とを統合したＷｅｂ−ＶｏＩＰ融合型ＡＰ環境において、ＳＩＰ−ＡＰサーバにレプリケーション機能を提供するための方式に関するものである。

近年、Ｗｅｂアプリケーションなどを開発する際に、アプリケーションサーバを利用したシステム構築が広く行なわれている。例えば、Ｊａｖａ環境におけるアプリケーションサーバ技術はＪ２ＥＥ（Ｊａｖａ ２ Ｐｌａｔｆｏｒｍ，Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ）等が定義されている。

また、インターネットを利用したサービスとして、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を利用したＶｏＩＰ（Ｖｏｉｃｅ Ｏｖｅｒ ＩＰ）なども広く利用されている。

一般に、これらのアプリケーションは独立して開発されることが多いが、複数のネットワークプロトコルを利用したアプリケーションを同時に制御することにより、付加価値の高い統合させたアプリケーションを提供することができるＷｅｂ−ＡＰ・ＳＩＰ−ＡＰ統合サーバがある。

図２は、従来のＷｅｂ−ＡＰサーバとＳＩＰ−ＡＰサーバとを統合したＷｅｂ−ＡＰ・ＳＩＰ−ＡＰ統合サーバの代表的な機能構成を示す機能ブロック図である。

図２に示すように、従来のＷｅｂ−ＡＰ・ＳＩＰ−ＡＰ統合サーバ２は、Ｗｅｂ−ＡＰ３及びＳＩＰ−ＡＰ４を、Ｓｅｒｖｌｅｔコンテナ５及び１１として実装し、既存のＷｅｂ−ＡＰサーバ上にＳＩＰをベースとしたＳＩＰ−ＡＰサーバ機能を融合させた構成である。

ＳＩＰ ｓｅｒｖｌｅｔに関する仕様は非特許文献１に開示されるものを適用することができ、また、ＳＩＰ−Ｓｅｒｖｌｅｔのレプリケーション機能はＳＩＰ Ｓｅｒｖｌｅｔの仕様に基づいて実装される。このＳＩＰ Ｓｅｒｖｌｅｔのレプリケーション機能により、ホストが障害発生した場合でも、別のホストがＳＩＰセッションのレプリカに基づいてＳＩＰセッションを継続することができる。

また、Ｗｅｂ−ＡＰサーバのレプリケーション機能は、種々の方式があるが、代表的には、２つ以上のＷｅｂ−ＡＰサーバ間でＨＴＴＰセッション情報の同期を取る（ＨＴＴＰセッションのレプリカを生成する）ことによって実現されている。非特許文献２では、例えばＴｏｍｃａｔにおけるレプリケーション機能が開示されている。

Ｔｈｅ Ｊａｖａ Ｃｏｍｍｕｎｉｔｙ Ｐｒｏｃｅｓｓ（ＳＭ） Ｐｒｏｇｒａｍ−ＪＳＲｓ：Ｊａｖａ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔｓ−Ｄｅｔａｉｌ ＪＳＲ＃１１６，[Ｏｎｌｉｎｅ]，Ｊａｖａ Ｃｏｍｍｕｎｉｔｙ Ｐｒｏｃｅｓｓ，[２００５年５月６日検索]，<ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ.ｊｃｐ．ｏｒｇ／ｅｎ／ｊｓｒ／ｄｅｔａｉｌ？ｉｄ＝１１６> Ｔｈｅ Ａｐａｃｈｅ Ｊａｋａｒｔａ Ｔｏｍｃａｔ５ Ｓｅｒｖｌｅｔ／ＪＳＲ Ｃｏｎｔａｉｎｅｒ，[Ｏｎｌｉｎｅ]，Ｔｈｅ Ａｐａｃｈｅ Ｊａｋａｒｔａ Ｐｒｏｊｅｃｔ，[２００５年５月６日検索]，<ＵＲＬ：ｈｔｔｐ：／／ｊａｋａｒｔａ．ａｐａｃｈｅ．ｏｒｇ／ｔｏｍｃａｔ／ｔｏｍｃａｔ−５．０−ｄｏｃ／ｃｌｕｓｔｅｒ−ｈｏｗｔｏ．ｈｔｍｌ>

上述したように、Ｗｅｂ−ＡＰ・ＳＩＰ−ＡＰ統合サーバは、Ｗｅｂ−ＡＰサーバとＳＩＰ−ＡＰサーバとが統合したものである。

しかしながら、ＳＩＰ−ＡＰサーバのレプリケーション機能は、Ｗｅｂ−ＡＰサーバが提供するレプリケーション機能とは別に存在している。そのため、Ｗｅｂ−ＶｏＩＰ融合型ＡＰ環境に、それぞれ異なる２つのレプリケーション機能が存在することとなり、それぞれのレプリケーション機能を作用させることとなり、効率的なものではなかった。また、それぞれのレプリケーション機能は相互に独立したものであるため、互いにそれぞれのレプリケーション機能を利用・コントロールすることが困難であった。

そこで、複数のネットワークプロトコルのそれぞれを利用したそれぞれのアプリケーションを相互に関連付けた融合アプリケーションを提供するサーバにおいて、それぞれのレプリケーション機能を有効に利用し、効率的なレプリケーションを実現することができる通信システム、通信方法及び通信装置が求められている。

かかる課題を解決するために、第１の本発明の通信システムは、第１サーバ及び第２サーバと、第１サーバ及び第２サーバと接続する記憶装置とを有する通信システムにおいて、第１サーバは、第１処理部、第２処理部、第１管理部、第２管理部、設定部、レプリカ生成部、登録部を有し、第２サーバは、取得部、処理部を有し、第１サーバにおいて、第１処理部が、受信したＨＴＴＰに係る信号に対応する処理を行い、第２処理部が、受信したＳＩＰに係る信号に対応する処理を行い、第１管理部が、ＨＴＴＰに係る処理を管理し、第２管理部が、ＳＩＰに係る処理を管理し、設定部が、ＳＩＰに係る処理の情報をレプリケーション可能なオブジェクトに変換して、ＨＴＴＰに係る処理の情報として設定し、レプリカ生成部が、ＨＴＴＰに係る処理の情報のレプリカを生成し、その生成したレプリカを前記第２サーバとの間で同期し、登録部が、レプリカ生成部により生成されたレプリカの第１識別情報と、当該ＨＴＴＰに係る処理の情報に設定したＳＩＰに係る処理を一意に特定する第２識別情報とを対応付けて記憶装置に格納し、記憶装置は、レプリカの第１識別情報と、ＳＩＰに係る処理の第２識別情報とを対応付けて記憶するものであり、第２サーバにおいて、取得部は、ＳＩＰに係る信号を受信したときに、記憶装置から、ＳＩＰに係る信号に含まれる第２識別情報に対応するレプリカの第１識別情報を取得し、取得したレプリカの第１識別情報に対応するＨＴＴＰに係る処理の情報を取得し、取得した前記ＨＴＴＰに係る処理の情報として設定されたオブジェクトを変換して、ＳＩＰに係る処理の情報の復元を行い、処理部は、取得部により復元されたＳＩＰに係る処理の情報を用いてＳＩＰに係る処理を行うことを特徴とする。

第２の本発明の通信方法は、第１サーバ及び第２サーバと、第１サーバ及び第２サーバに接続する記憶装置とを有する通信システムの通信方法において、第１サーバは、第１処理部、第２処理部、第１管理部、第２管理部、設定部、レプリカ生成部、登録部を有し、第２サーバは、取得部、処理部を有し、第１サーバにおいて、第１処理部が、受信したＨＴＴＰに係る信号に対応する処理を行い、第２処理部が、受信したＳＩＰに係る信号に対応する処理を行い、第１管理部が、ＨＴＴＰに係る処理を管理し、第２管理部が、ＳＩＰに係る処理を管理し、設定部が、ＳＩＰに係る処理の情報をレプリケーション可能なオブジェクトに変換して、ＨＴＴＰに係る処理の情報として設定し、レプリカ生成部が、ＨＴＴＰに係る処理の情報のレプリカを生成し、その生成したレプリカを第２サーバとの間で同期し、登録部が、レプリカ生成部により生成されたレプリカの第１識別情報と、当該ＨＴＴＰに係る処理の情報に設定したＳＩＰに係る処理を一意に特定する第２識別情報とを対応付けて記憶装置に格納し、記憶装置は、レプリカの第１識別情報と、ＳＩＰに係る処理の第２識別情報とを対応付けて記憶し、第２サーバにおいて、取得部は、ＳＩＰに係る信号を受信したときに、記憶装置から、ＳＩＰに係る信号に含まれる第２識別情報に対応するレプリカの第１識別情報を取得し、取得したレプリカの第１識別情報に対応するＨＴＴＰに係る処理の情報を取得し、取得した前記ＨＴＴＰに係る処理の情報として設定されたオブジェクトを変換して、ＳＩＰに係る処理の情報の復元を行い、処理部は、取得部により復元されたＳＩＰに係る処理の情報を用いてＳＩＰに係る処理を行うことを特徴とする。

第３の本発明の通信装置は、他の通信装置との間で、ＳＩＰに係る処理の情報をレプリケーション可能なオブジェクトに変換して、ＨＴＴＰに係る処理の情報として設定された当該ＨＴＴＰに係る処理の情報のレプリカの同期を他の通信装置との間で行うものであり、レプリカの第１識別情報とＳＩＰに係る処理の第２識別情報とを対応付けて記憶する記憶装置と接続する通信装置において、ＳＩＰに係る信号を受信したときに、記憶装置から、ＳＩＰに係る信号に含まれる第２識別情報に対応するレプリカの前記第１識別情報を取得し、取得したレプリカの第１識別情報に対応するＨＴＴＰに係る処理の情報を取得し、取得した前記ＨＴＴＰに係る処理の情報として設定されたオブジェクトを変換して、ＳＩＰに係る処理の情報の復元を行う取得部と、取得部により復元されたＳＩＰに係る処理の情報を用いてＳＩＰに係る処理を行う処理部とを備えることを特徴とする。

第４の本発明の通信方法は、他の通信装置との間で、ＳＩＰに係る処理の情報をレプリケーション可能なオブジェクトに変換して、ＨＴＴＰに係る処理の情報として設定された当該ＨＴＴＰに係る処理の情報のレプリカの同期を他の通信装置との間で行うものであり、レプリカの第１識別情報とＳＩＰに係る処理の第２識別情報とを対応付けて記憶する記憶装置と接続する通信装置の通信方法において、通信装置は、取得部と処理部とを有し、取得部が、ＳＩＰに係る信号を受信したときに、記憶装置から、ＳＩＰに係る信号に含まれる第２識別情報に対応するレプリカの第１識別情報を取得し、取得したレプリカの第１識別情報に対応するＨＴＴＰに係る処理の情報を取得し、取得した前記ＨＴＴＰに係る処理の情報として設定されたオブジェクトを変換して、ＳＩＰに係る処理の情報の復元を行い、処理部は、取得部により復元されたＳＩＰに係る処理の情報を用いてＳＩＰに係る処理を行うことを特徴とする。

本発明によれば、複数のネットワークプロトコルのそれぞれを利用したそれぞれのアプリケーションを相互に関連付けたアプリケーションを提供するサーバにおいて、それぞれのレプリケーション機能を有効に利用し、効率的なレプリケーションを実現することができる。

（Ａ）第１の実施形態
以下、本発明の通信システム、通信方法及び通信装置の実施形態について図面を参照しながら詳細に説明する。

本実施形態は、例えばＴｏｍｃａｔ、ＷｅｂＬｏｇｉｃなどに代表されるＷｅｂアプリケーションサーバ環境上において、ＳＩＰをベースとしたＳＩＰアプリケーションサーバ機能を統合した統合サーバに、本発明の通信システム、通信方法及び通信装置を適用した場合を示す。

（Ａ−１）第１の実施形態の構成
図３は、本実施形態に係る通信システムの構成を示すブロック図である。図３に示すように、本実施形態の通信システム１は、ホストＡ１０−１、ホストＢ１０−２、ロードバランサ２０、データベース３０を少なくとも有する。

また、ホストＡ１０−１及びホストＢ１０−２はそれぞれ、Ｗｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ１００−１及び１００−２を有する。なお、図３では、２台のホストＡ１０−１及びホストＢ１０−２を有する場合を示すが、３台以上としても良い。

ホストＡ１０−１は、Ｗｅｂ−ＡＰ・ＳＩＰ−ＡＰ統合サーバ１００−１が動作するホストコンピュータである。また、ホストＢ１０−２は、Ｗｅｂ−ＡＰ・ＳＩＰ−ＡＰ統合サーバ１００−２が動作するホストコンピュータである。ホストＡ１０−１とホストＢ１０−２とは、それぞれ対になりクラスタを構成するものである。

Ｗｅｂ−ＡＰ・ＳＩＰ−ＡＰ統合サーバ１００−１及び１００−２は、ホストＡ１０−１及びホストＢ１０−２で動作するものであり、所定のＷｅｂアプリケーションに係るサービスとＳＩＰに基づく音声通信サービスとを融合させたサービスを提供するものである。なお、Ｗｅｂ−ＡＰ・ＳＩＰ−ＡＰ統合サーバ１００−１及び１００−２はそれぞれ対応する機能構成を備えるものである。

ロードバランサ２０は、ＨＴＴＰプロトコルとＳＩＰプロトコルとの両方に対応可能なものであり、ホストＡ１０−１とホストＢ１０−２との間の負荷を分散する負荷分散装置である。ロードバランサ２０は、接続するネットワークからＳＩＰに係る初期リクエストを受け取ると、その初期リクエストをホストＡ１０−１あるいはホストＢ１０−２に配送するものである。

データベース３０は、ＳＩＰセッションのレプリケーション情報を保持するデータベースである。データベース３０は、ホストＡ１０−１及びホストＢ１０−２からアクセス可能であるとする。本実施形態では、データベース３０は、ＳＩＰセッションのダイアログＩＤとＨＴＴＰセッションＩＤとを関連付けて、またアプリケーションセッションＩＤとＨＴＴＰセッションＩＤとを関連付けて保持する。これにより、どのホスト１０からのアクセスでも、ＳＩＰセッションを復元できる。

図１は、レプリケーション機能を有するＷｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ１００（１００−１及び１００−２）の内部機能を示す機能ブロック図である。

図１に示すように、Ｗｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ１００は、ＨＴＴＰレプリケーションエンジン１１０、ＨＴＴＰＳｅｒｖｌｅｔコンテナ１２０、ＨＴＴＰセッションマネージャ１３０、ＨＴＴＰセッション１４０、ＳＩＰＳｅｒｖｌｅｔコンテナ１５０、ＳＩＰＳｅｒｖｌｅｔコンテキスト１６０、ＳＩＰセッションマネージャ１７０、ＳＩＰレプリケーションマネージャ１８０を有する。

ＨＴＴＰレプリケーションエンジン１１０は、ＨＴＴＰＳｅｒｖｌｅｔコンテナ１２０と連携し、生成したＨＴＴＰセッション１４０のレプリカを生成するレプリケーション機能を行うコンポーネントである。すなわち、ＨＴＴＰレプリケーションエンジン１１０は、ＨＴＴＰセッションのレプリカの生成処理を実行するものである。なお、詳細な動作は後述するが、本実施形態では、ＨＴＴＰセッションの属性情報にＳＩＰセッションを格納するものとし、ＨＴＴＰレプリケーションエンジン１１０が、ＨＴＴＰセッションのレプリカ生成時に、ＨＴＴＰセッションのレプリカを生成することで、ＳＩＰセッションのレプリカも生成することができる。

ＨＴＴＰＳｅｒｖｌｅｔコンテナ１２０は、ＨＴＴＰアプリケーション（ＨＴＴＰコンテキスト）を管理するコンポーネントである。ＨＴＴＰＳｅｒｖｌｅｔコンテナ１２０は、受信したＨＴＴＰリクエストに応じて対応するＨＴＴＰアプリケーションを生成し、そのＨＴＴＰアプリケーションを動作させるものである。また、ＨＴＴＰＳｅｒｖｌｅｔコンテナは、ＨＴＴＰアプリケーションの削除なども管理するものである。

ＨＴＴＰセッションマネージャ１３０は、ＨＴＴＰセッション１４０を管理するコンポーネントである。ＨＴＴＰセッションマネージャ１３０は、ＨＴＴＰセッション１４０の生成、削除などして、ＨＴＴＰセッション１４０を管理するための機能を提供する。

ＨＴＴＰセッション１４０は、ＨＴＴＰのセッション情報を管理するコンポーネントである。ＨＴＴＰセッション１４０は、一連のＨＴＴＰのリクエストを１つの意味のあるまとまりとして扱うための機能を提供する。

ＳＩＰ Ｓｅｒｖｌｅｔコンテナ１５０は、ＳＩＰアプリケーション（ＳＩＰコンテキスト）を管理するコンポーネントである。ＳＩＰ Ｓｅｒｖｌｅｔコンテナ１５０は、ＳＩＰアプリケーションの生成、削除などの管理機能を提供する。

ＳＩＰ Ｓｅｒｖｌｅｔコンテキスト１６０は、ＳＩＰアプリケーションの内部状態を保持するコンポーネントである。ＳＩＰ Ｓｅｒｖｌｅｔコンテキスト１６０は、複数のＳＩＰ Ｓｅｒｖｌｅｔを保持することができる。また、ＳＩＰ Ｓｅｒｖｌｅｔは、ＳＩＰ Ｓｅｒｖｌｅｔコンテキスト１６０の内部状態に従って実行されるものである。

ＳＩＰセッションマネージャ１７０は、ＳＩＰのセッション（ＳＩＰセッション及びＳＩＰアプリケーションセッション）を管理するコンポーネントである。ＳＩＰセッションマネージャ１７０は、受信したＳＩＰのセッションに基づいて、ＳＩＰ Ｓｅｒｖｌｅｔコンテキスト１６０に対して、ＳＩＰのセッションを生成させたり、削除させたりするものである。また、ＳＩＰセッションマネージャ１７０は、ＳＩＰレプリケーションマネージャ１８０に対して、ＳＩＰセッションの取得、登録、削除や、ＳＩＰアプリケーションセッションの取得、登録、削除を要求するものである。

ＳＩＰレプリケーションマネージャ１８０は、ＳＩＰのセッションのレプリカを管理するコンポーネントである。ＳＩＰレプリケーションマネージャ１８０は、ＳＩＰセッションマネージャ１７０からの要求を受けて、ＳＩＰセッションの取得、登録、削除や、ＳＩＰアプリケーションセッションの取得、登録、削除を実行するものである。

続いて、ＳＩＰレプリケーションマネージャ１８０の機能について説明する。図４は、ＳＩＰレプリケーションマネージャ１８０の機能構成と、ＨＴＴＰセッションマネージャ１３０及びＨＴＴＰセッション１４０との関係を示す図である。

図４に示すように、本実施形態のＳＩＰレプリケーションマネージャ１８０は、ＳＩＰセッション取得部１８１、ＳＩＰセッション登録部１８２、ＳＩＰセッション削除部１８３、ＳＩＰアプリケーションセッション取得部１８４、ＳＩＰアプリケーションセッション登録部１８５、ＳＩＰアプリケーションセッション削除部１８６を少なくとも有する。

ＳＩＰセッション取得部１８１は、ＳＩＰセッションに含まれているダイアログＩＤ（ダイアログを識別するＩＤ）を与えて、ＳＩＰセッションのレプリカを取得するためのモジュールである。

ＳＩＰセッション登録部１８２は、ＳＩＰセッションを与えて、そのレプリカを生成させるために、ＳＩＰセッションを登録するためのモジュールである。

ＳＩＰセッション削除部１８３は、ダイアログＩＤを与えて、ＳＩＰセッションのレプリカを削除するためのモジュールである。

ＳＩＰアプリケーションセッション取得部１８４は、アプリケーションセッションＩＤを与えて、ＳＩＰアプリケーションセッションのレプリカを取得するためのモジュールである。

ＳＩＰアプリケーションセッション登録部１８５は、ＳＩＰアプリケーションセッションを与えて、そのレプリカを生成させるために、ＳＩＰアプリケーションセッションを登録するためのモジュールである。

ＳＩＰアプリケーションセッション削除部１８６は、アプリケーションセッションＩＤを与えて、ＳＩＰアプリケーションセッションのレプリカを削除するためのモジュールである。

（Ａ−２）第１の実施形態の動作
次に、本発明のサーバにおける動作について図面を参照して説明する。

以下では、まず、ＳＩＰセッションの登録動作について、ＳＩＰの初期リクエストを受信した場合の動作、ＳＩＰの初期リクエストに対するＳＩＰレスポンスを受信した場合の動作、後続するＳＩＰリクエストを受信した場合の動作、及び、後続するＳＩＰリクエストに対するＳＩＰレスポンスを受信した場合の動作に分けて説明する。

また、上記の各ＳＩＰセッションの登録動作について説明した後に、ＳＩＰアプリケーションセッションを削除する動作、ＳＩＰセッションを削除する動作、及びフェイルオーバしてＳＩＰセッションを取得する動作について説明する。

ここで、本実施形態におけるＳＩＰセッション及びＳＩＰアプリケーションセッションについて説明する。

ＳＩＰセッションとは、２つのＵＡ（Ｕｓｅｒ Ａｇｅｎｔ）間のダイアログ、あるいはダイアログを確立する前の関係を表現するものである。図５は、利用者が利用するソフトフォンのＵＡとサーバ上のＵＡとの２つのＵＡ間での呼シーケンスを示し、ここでなされる一連のメッセージは１つのＳＩＰセッション（ダイアログ）として取り扱う。

例えば、図６は、図５のＦ１でＵＡ（ソフトフォン）が送出するＩＮＶＩＴＥメッセージの例であり、図７は、図５のＦ７でＵＡ（ソフトフォン）が送出する２００ＯＫメッセージの例である。これらのメッセージが１つのＳＩＰセッションで取り扱われる。

また、ダイアログ（ダイアログＩＤ）は、ＳＩＰメッセージのＣａｌｌ−ＩＤ、Ｆｒｏｍのｔａｇパラメータ、Ｔｏのｔａｇパラメータで一意に特定することができる。

例えば、図７の２００ＯＫメッセージにおける「Ｃａｌｌ−ＩＤ：ａ８４ｂ４ｃ７６ｅ６６７１０＠ｐｃ３３．ａｔｌａｎｔａ．ｃｏｍ」、「Ｆｒｏｍ ｔａｇ：１９２８３０１７７４」、「Ｔｏ ｔａｇ：ａ６ｃ８５ｃｆ」によって、ダイアログ（ダイアログＩＤ）は一意に特定できる。なお、Ｆ３〜Ｆ７までのメッセージはすべて同じＣａｌｌ−ＩＤ、Ｆｒｏｍ ｔａｇ、Ｔｏ ｔａｇを持つ。ただし、初期リクエストＦ１とその１００応答Ｆ２は例外としてこれらを持たない。

ＳＩＰアプリケーションセッションは、アプリケーションのデータを保持し、複数のＳＩＰセッション（厳密にはＳＩＰセッションだけでなく、ＨＴＴＰセッションなど別のプロトコルのセッションでもよい）を関連付けるためのものである。図８は、２つのソフトフォンのＵＡと、サーバ上のＵＡとの間の呼接続シーケンスを示す。ただし、サーバ上のＵＡはＢ２ＢＵＡ（Ｂａｃｋ ｔｏ Ｂａｃｋ Ｕｓｅｒ Ａｇｅｎｔ）として動作するものとする。図５では、１つのＳＩＰセッションのみであるが、図８に示すように２つのＳＩＰセッションを関連付け、保持する。

以下では、まず、ＳＩＰセッションを登録する動作について説明する。

（Ａ−２−１）ＳＩＰセッションの登録動作
本実施形態において、ＳＩＰセッションを登録する動作は、ＳＩＰセッションが生成あるいは更新される場合に行われる。

ＳＩＰセッションをＨＴＴＰセッションの属性に格納（厳密にはそのＳＩＰセッションを保持しているＳＩＰアプリケーションセッションを格納）することによって、Ｗｅｂ−ＡＰサーバが提供するＨＴＴＰセッションレプリケーション機能を利用して、ＳＩＰセッションのレプリカを生成する。

このとき、通常ＳＩＰセッションはレプリケーション可能なオブジェクトではないため、レプリケーション可能なオブジェクトヘ変換したものが、ＨＴＴＰセッションの属性へ格納される。

Ｗｅｂ−ＡＰサーバの提供するレプリケーション機能によって、ＨＴＴＰセッションのレプリカを生成すれば、自動的にＳＩＰセッションのレプリカも生成されることとなる。

また、同時にデータベースにダイアログＩＤとＨＴＴＰセッションＩＤ、アプリケーションセッションＩＤとＨＴＴＰセッションＩＤの関連付け情報を格納しておくことによって、どのホストからもそれらの情報が取得できる。さらにデータベースを参照できればフェイルオーバ時に、どのＷｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバからでもＳＩＰのセッションを復元できる。

ここで、ＳＩＰセッションの登録動作におけるレプリケーション機能を動作させるタイミングは、例えば、図８のシーケンスにおいては、Ｆ１５の後：１８０ Ｆ１５の処理が終了した時点、Ｆ１７の後：２００ Ｆ１７の処理が終了した時点、Ｆ１８の後：２０ Ｆ１８の処理（ＩＮＶＩＴＥ Ｆ１１）が終了した時点、Ｆ１９の後：ＡＣＫ Ｆ１９の処理が終了した時点、Ｆ２３の後：２００ Ｆ２３の処理が終了した時点、Ｆ２４の後：Ｆ２４の処理（ＢＹＥ Ｆ２１）が終了した時点に行われる。

（Ａ−２−１−１）ＳＩＰの初期リクエストを受信した場合の登録動作
図９は、ＳＩＰの初期リクエストを受信した場合の、ＳＩＰセッション登録動作を示すシーケンスである。

まず、ロードバランサ２０がネットワークを通じてＳＩＰの初期リクエストを受信すると、ロードバランサ２０は、ホストＡ１０−１のＷｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ１００−１にＳＩＰの初期リクエストをフォワードする（Ｓ１０１）。なお、ホストＢ１０−２にフォワードする場合も同様に、ロードバランサ２０はホストＢ１０−２に初期リクエストを与える。

ロードバランサ２０から初期リクエストを受信すると、Ｗｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ１００−１において、ＳＩＰの初期リクエストはＳＩＰセッションマネージャ１７０に与えられる（Ｓ１０２）。

ＳＩＰセッションマネージャ１７０は、ＳＩＰの初期リクエストを受け取ると、ＳＩＰのセッション（ＳＩＰセッション及びＳＩＰアプリケーションセッション）を生成する。そして、ＳＩＰセッションマネージャ１７０は、ＳＩＰリクエストをＳＩＰ Ｓｅｒｖｌｅｔコンテキスト１６０へフォワードする（Ｓ１０３）。

ＳＩＰリクエストが与えられると、ＳＩＰ Ｓｅｒｖｌｅｔコンテキスト１６０は、そのＳＩＰリクエストを適切なＳＩＰ Ｓｅｒｖｌｅｔヘフォワードする。そして、ＳＩＰ Ｓｅｒｖｌｅｔは、そのＳＩＰリクエストに対する処理を行う（Ｓ１０４）。これにより、ＳＩＰリクエストに対する処理を行うことができる。

一方、ＳＩＰセッションマネージャ１７０は、Ｓ１０３でＳＩＰセッションを生成すると、その生成したＳＩＰセッションをＳＩＰレプリケーションマネージャ１８０のＳＩＰセッション登録部１８２に与える（Ｓ１０５）。これにより、当該ＳＩＰの初期リクエストに係るＳＩＰセッションの登録をさせることができる。

ＳＩＰセッションマネージャ１７０からＳＩＰセッションが与えられると、ＳＩＰセッション登録部１８２は、そのＳＩＰセッションからＳＩＰアプリケーションセッションを取得し、そのＳＩＰアプリケーションセッションをＳＩＰアプリケーションセッション登録部１８５へ与える（Ｓ１０６）。

ＳＩＰセッション登録部１８２からＳＩＰアプリケーションセッションが与えられると、ＳＩＰアプリケーションセッション登録部１８５は、ＨＴＴＰセッションマネージャ１３０から新規のＨＴＴＰセッションを取得する（Ｓ１０７）。このとき、すでにＳＩＰアプリケーションセッションに対応するＨＴＴＰセッションが存在する場合はその存在するＨＴＴＰセッションを取得する。

ここで、ＨＴＴＰセッションを取得する方法は、ＳＩＰアプリケーションセッション取得部１８４が、当該ＳＩＰアプリケーションセッションのＳＩＰアプリケーションＩＤ（ダイアログＩＤ）をキーとして、ＨＴＴＰセッションＩＤをデータベース３０を検索する。

そして、ＳＩＰアプリケーション取得部１８４が、その検索したＨＴＴＰセッションＩＤをＨＴＴＰセッションマネージャ１３０に与えて、そのＨＴＴＰセッションＩＤに対応するＨＴＴＰセッション１４０をＨＴＴＰセッションマネージャ１３０から取得する。

ＳＩＰアプリケーションセッション登録部１８５は、ＳＩＰアプリケーションセッションをレプリケーション可能なオブジェクトヘ変換し、取得したＨＴＴＰセッションの属性に設定する（Ｓ１０８）。

ここで、ＳＩＰアプリケーションセッションをレプリケーション可能なオブジェクトヘ変換するとき、ＳＩＰアプリケーションセッションが保持しているすべてのオブジェクトもレプリケーション可能なオブジェクトヘ変換する。例えば、ＳＩＰセッション、ＳＩＰリクエスト、ＳＩＰレスポンスなどをレプリケーション可能なオブジェクトに変換する。

ＳＩＰセッションをＨＴＴＰセッションの属性に設定すると、ＳＩＰアプリケーションセッション登録部１８５は、ＨＴＴＰセッションマネージャ１３０に対して、Ｓ１０７で取得したＨＴＴＰセッションの同期を取るように要求する（Ｓ１０９）。すなわち、ＨＴＴＰレプリケーションエンジン１１０は、ＳＩＰセッションを属性情報としてもつＨＴＴＰセッションのレプリカを生成する。

そして、ＳＩＰアプリケーションセッション登録部１８５は、データベース３０にＳＩＰアプリケーションセッションのセッションＩＤと、Ｓ１０７で取得したＨＴＴＰセッションのセッションＩＤとを対応付けて格納する（Ｓ１１０）。

また、ＳＩＰアプリケーションセッション登録部１８５は、データベース３０にＳＩＰセッションのダイアログＩＤと、Ｓ１０７で取得したＨＴＴＰセッションのセッションＩＤとを対応付けて格納する（Ｓ１１１）。このとき、ＳＩＰアプリケーションセッションが複数のＳＩＰセッションを保持する場合は、ＳＩＰセッションの数だけ、この処理を繰り返す。

（Ａ−２−１−２）ＳＩＰの初期リクエストに対するＳＩＰレスポンスを受信した場合の登録動作
図１０は、ＳＩＰの初期リクエストに対するＳＩＰレスポンスを受信した場合の登録動作を示すシーケンス図である。

まず、ロードバランサ２０がＳＩＰレスポンスを受信すると、ロードバランス２０は、ＳＩＰレスポンスをホストＡ１０−１のＷｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ１００−１へフォワードする（Ｓ２０１）。ホストＢ１０−２にフォワードする場合も同様である。

ロードバランス２０からＳＩＰレスポンスが与えられると、Ｗｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ１００−１において、ＳＩＰレスポンスはＳＩＰセッションマネージャ１７０にフォワードされる（Ｓ２０２）。

ＳＩＰレスポンスがＳＩＰセッションマネージャ１７０に与えられると、ＳＩＰセッションマネージャ１７０は、そのＳＩＰレスポンスに対応するＳＩＰセッションを取得する。なお、ここで、取得するＳＩＰセッションは、ＳＩＰレスポンスに対応するＳＩＰリクエストの送信時に生成されているものである。そして、ＳＩＰ Ｓｅｒｖｌｅｔコンテキスト１６０へＳＩＰレスポンスをフォワードする（Ｓ２０３）。

ＳＩＰ Ｓｅｒｖｌｅｔコンテキスト１６０はＳＩＰレスポンスを適切なＳＩＰ Ｓｅｒｖｌｅｔヘフォワードする。ＳＩＰ Ｓｅｒｖｌｅｔはレスポンスを処理する（Ｓ２０４）。

一方、ＳＩＰセッションマネージャ１７０は、Ｓ２０３で取得したＳＩＰセッションをＳＩＰレプリケーションマネージャ１８０のＳＩＰセッション登録部１８２に与える（Ｓ２０５）。

ＳＩＰセッションマネージャ１７０からＳＩＰセッションを受け取ると、ＳＩＰセッション登録部１８２は、そのＳＩＰセッションからＳＩＰアプリケーションセッションを取得し、そのＳＩＰアプリケーションセッションをＳＩＰアプリケーションセッション登録部１８５に与える（Ｓ２０６）。

ＳＩＰアプリケーションセッションを受け取ると、ＳＩＰアプリケーションセッション登録部１８５は、ＨＴＴＰセッションマネージャ１３０から新規のＨＴＴＰセッションを取得する（Ｓ２０７）。このとき、すでにＳＩＰアプリケーションセッションに対応するＨＴＴＰセッションが存在する場合はそのＨＴＴＰセッションを取得する。

ＳＩＰアプリケーションセッション登録部１８５は、ＳＩＰアプリケーションセッションをレプリケーション可能なオブジェクトヘ変換し、ＨＴＴＰセッションの属性に設定する（Ｓ２０８）。

ここで、ＳＩＰアプリケーションセッションをレプリケーション可能なオブジェクトヘ変換するとき、ＳＩＰアプリケーションセッションが保持しているすべてのオブジェクトもレプリケーション可能なオブジェクトヘ変換する。

ＳＩＰアプリケーションセッション登録部１８５は、ＨＴＴＰセッションマネージャ１３０に、Ｓ２０７で取得したＨＴＴＰセッションの同期を取るように要求する（Ｓ２０９）。

そして、ＳＩＰアプリケーションセッション登録部１８５は、データベース３０にＳＩＰアプリケーションセッションのセッションＩＤと、Ｓ２０７で取得したＨＴＴＰセッションのセッションＩＤとを対応付けて格納する（Ｓ２１０）。

また、ＳＩＰアプリケーションセッション登録部１８５は、データベース３０にＳＩＰセッションのダイアログＩＤと、Ｓ２０７で取得したＨＴＴＰセッションのセッションＩＤとを対応付けて格納する（Ｓ２１１）。

このとき、ＳＩＰアプリケーションセッションが複数のＳＩＰセッションを保持する場合は、ＳＩＰセッションの数だけ、この処理を繰り返す。

（Ａ−２−１−３）後続ＳＩＰリクエストを受信した場合の動作
図１１は、後続ＳＩＰリクエストを受信した場合の登録動作を示すシーケンス図である。

まず、ロードバランサ２０が後続ＳＩＰリクエストを受信すると、ロードバランサ２０は、ホストＡ１０−１のＷｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ１００−１へフォワードする（Ｓ３０１）。ホストＢ１０−２にフォワードする場合も同様である。

ロードバランサ２０から後続ＳＩＰリクエストが与えられると、Ｗｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ１００−１において、ＳＩＰリクエストはＳＩＰ−セッションマネージャ１７０ヘフォワードされる（Ｓ３０２）。

ＳＩＰセッションマネージャ１７０は、ＳＩＰのセッションを取得し、ＳＩＰ Ｓｅｒｖｌｅｔコンテキスト１６０へＳＩＰリクエストをフォワードする（Ｓ３０３）。このとき、ＳＩＰセッションは既に生成されている。

ＳＩＰ Ｓｅｒｖｌｅｔコンテキスト１６０は、ＳＩＰリクエストを適切なＳＩＰ Ｓｅｒｖｌｅｔヘフォワードする。ＳＩＰ Ｓｅｒｖｌｅｔはリクエストを処理する（Ｓ３０４）。

一方、ＳＩＰセッションマネージャ１７０は、Ｓ３０３で取得したＳＩＰセッションをＳＩＰレプリケーションマネージャ１８０のＳＩＰセッション登録部１８２に与える（Ｓ３０５）。

ＳＩＰセッション登録部１８２は、ＳＩＰセッションからＳＩＰアプリケーションセッションを取得し、ＳＩＰアプリケーションセッション登録部１８５に与える（Ｓ３０６）。

ＳＩＰアプリケーションセッション登録部１８５は、ＨＴＴＰセッションマネージャ１３０からＨＴＴＰセッションを取得する（Ｓ３０７）。

ここで、ＨＴＴＰセッションの取得方法は、データベース３０からＳＩＰアプリケーションセッションＩＤをキーとして、ＨＴＴＰセッションのＩＤを取得する。そして、ＨＴＴＰセッションＩＤからＨＴＴＰセッションを取得することができる（Ｓ３０７）。

なお、Ｓ３０８以降の処理は、図９のＳ１０８〜Ｓ１１１の処理に対応するので詳細な説明は省略する。

（Ａ−２−１−４）後続ＳＩＰリクエストに対するＳＩＰレスポンスを受信した場合
図１２は、後続ＳＩＰリクエストに対するＳＩＰレスポンスを受信した場合の登録動作を示すシーケンス図である。

まず、ロードバランサ２０が後続ＳＩＰレスポンスを受信すると、ロードバランサ２０は、ホストＡ１０−１のＷｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ１００−１へフォワードする（Ｓ４０１）。ホストＢ１０−２にフォワードする場合も同様である。

ロードバランサ２０からＳＩＰレスポンスが与えられると、Ｗｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ１００−１において、ＳＩＰレスポンスはＳＩＰセッションマネージャ１７０ヘフォワードする（Ｓ４０２）。

ＳＩＰセッションマネージャ１７０は、ＳＩＰレスポンスに対応するＳＩＰセッションを取得し、ＳＩＰ Ｓｅｒｖｌｅｔコンテキスト１６０へＳＩＰレスポンスをフォワードする（Ｓ４０３）。ＳＩＰセッションはＳＩＰレスポンスに対応するＳＩＰリクエストの送信時に生成されている。

ＳＩＰ Ｓｅｒｖｌｅｔコンテキスト１６０は、ＳＩＰレスポンスを適切なＳＩＰ Ｓｅｒｖｌｅｔヘフォワードする。ＳＩＰ Ｓｅｒｖｌｅｔはレスポンスを処理する（Ｓ４０４）。

ＳＩＰセッションマネージャ１７０は、Ｓ４０３で取得したＳＩＰセッションをＳＩＰレプリケーションマネージャ１８０のＳＩＰセッション登録部１８２へ渡す（Ｓ４０５）。

ＳＩＰセッション登録部１８２は、ＳＩＰセッションからＳＩＰアプリケーションセッションを取得し、ＳＩＰアプリケーションセッション登録部１８５へ渡す（Ｓ４０６）。

ＳＩＰアプリケーションセッション登録部１８５は、ＨＴＴＰセッションマネージャ１３０からＨＴＴＰセッションを取得する（Ｓ４０７）。ここで、ＨＴＴＰセッションの取得方法は、データベース３０からＳＩＰアプリケーションセッションＩＤをキーとして、ＨＴＴＰセッションのＩＤを取得する。そして、ＨＴＴＰセッションＩＤからＨＴＴＰセッションを取得することができる（Ｓ４０８）。

なお、Ｓ４０８以降の処理は、図１０のＳ２０８〜Ｓ２１１の処理に対応するので詳細な説明は省略する。

（Ａ−２−２）ＳＩＰアプリケーションセッションの削除の動作
次に、ＳＩＰアプリケーションセッションを削除する動作について図１３を参照して説明する。

まず、ＳＩＰアプリケーションセッションを削除する動作は、ＳＩＰアプリケーションが処理を終了し、ＳＩＰアプリケーションセッションを破棄する場合に行われる。

このとき、データベースに格納されている、ＳＩＰアプリケーションセッションＩＤとＨＴＴＰセッションＩＤとの関連付け、及びダイアログＩＤとＨＴＴＰセッションＩＤとの関連付けを削除する。

なお、ＳＩＰアプリケーションセッションの削除動作においてレプリケーション機能を動作させるタイミングは、図８のＦ２４が終了して、アプリケーションがこれ以上処理をしないと判断したタイミングで行われる。

ＳＩＰアプリケーションセッションを削除する際、ＳＩＰ Ｓｅｒｖｌｅｔコンテキスト１６０は、ＳＩＰアプリケーションセッションを破棄するように、ＳＩＰセッションマネージャ１７０へ要求する（Ｓ５０１）。

ＳＩＰセッションマネージャ１７０は、ＳＩＰレプリケーションマネージャ１８０のＳＩＰアプリケーションセッション削除部１８６へＳＩＰアプリケーショシセッションを削除するよう要求する（Ｓ５０２）。

ＳＩＰアプリケーションセッション削除部１８６は、ＨＴＴＰセッションマネージャ１３０からＳＩＰアプリケーションセッションに対応するＨＴＴＰセッション１４０を取得する（Ｓ５０３）。

このとき、当該ＳＩＰアプリケーションセッションのセッションＩＤに基づいて、データベース３０からＨＴＴＰセッションＩＤを取得し、そのＨＴＴＰセッションＩＤをＨＴＴＰセッションマネージャ１３０に与えて、ＨＴＴＰセッションＩＤをキーとしてＨＴＴＰセッション１４０を取得する。

ＨＴＴＰセッションマネージャ１３０からＨＴＴＰセッション１４０を取得すると、ＳＩＰアプリケーションセッション削除部１８６は、その取得したＨＴＴＰセッション１４０に設定されている属性を削除する（Ｓ５０４）。

また、ＳＩＰアプリケーションセッション削除部１８６は、データベース３０からＳＩＰアプリケーションセッションＩＤとＨＴＴＰセッションＩＤの関連付けを削除する（Ｓ５０５）。

さらに、ＳＩＰアプリケーションセッション削除部１８６は、データベース３０からダイアログＩＤとＨＴＴＰセッションＩＤとの関連付けを削除する（Ｓ５０６）。

このＳ５０５及びＳ５０６の処理はＳＩＰアプリケーションセッションＩＤが保持しているＳＩＰセッションの数だけ行われる。

（Ａ−２−３）ＳＩＰセッションの削除動作
次に、ＳＩＰセッションを削除する動作について図１４を参照して説明する。

ＳＩＰセッションを削除する動作は、一連のメッセージの処理（ＳＩＰセッションの処理）が終了し、ＳＩＰセッションを破棄する場合に行われる。このとき、データベースに格納されている、ダイアログＩＤとＨＴＴＰセッションＩＤの関連付けを削除する。

なお、ＳＩＰセッションの削除動作においてレプリケーション機能を動作させるタイミングは、図８のＦ２４が終了して、アプリケーションがこれ以上処理をしないと判断したタイミングで行われる。

ＳＩＰセッションを削除する際、まず、ＳＩＰ Ｓｅｒｖｌｅｔコンテキスト１６０がＳＩＰセッションを破棄するようにＳＩＰセッションマネージャ１７０へ要求する（Ｓ６０１）。

ＳＩＰセッションマネージャ１７０は、ＳＩＰレプリケーションマネージャ１８０のＳＩＰセッション削除部１８３へＳＩＰセッションを削除するよう要求する（Ｓ６０２）。

ＳＩＰセッション削除部１８３は、データベース３０からダイアログＩＤとＨＴＴＰセッションＩＤの関連付けを削除する（Ｓ６０３）。

（Ａ−２−４）フェイルオーバしたときのＳＩＰセッションの取得動作
次に、フェイルオーバしてＳＩＰセッションを取得する動作について図１５を参照して説明する。

フェイルオーバしてＳＩＰセッションを取得する動作は、例えば、ホストＢ１０−２のＷｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ１００−２に障害が発生した場合、Ｗｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ１００−２で処理していたＳＩＰセッションを、ホストＡ１０−１のＷｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ１００−１で継続して処理させるために、ＳＩＰセッションのレプリカを利用して、ＳＩＰセッションを復元するために行われる。

ＳＩＰセッションの復元処理は、まず、ＳＩＰリクエストを受信したときに、ＳＩＰリクエストからダイアログＩＤを取得する。次に、そのダイアログＩＤをキーとしてＨＴＴＰセッションＩＤを取得し、ＨＴＴＰセッションに格納されているＳＩＰアプリケーションセッションからＳＩＰセッションを復元する。受信したＳＩＰリクエストはそのＳＩＰセッションによって処理することが可能となる。

なお、フェイルオーバ時の動作においてレプリケーション機能を動作させるタイミングは、例えば、図８のＦ２０が終了した時点で、アプリケーションサーバに障害が起きたとすると、フェイルオーバ時に別のアプリケーションサーバがＦ２１のリクエストを受信したタイミングで行われる。

以下では、図１５を参照して、フェイルオーバ時のＳＩＰセッション取得動作の詳細を説明する。なお、以下では、ホストＢ１０−２に障害が発生し、ホストＡ１０−１でＳＩＰセッションを復元する場合とする。

ホストＢ１０−２に障害が生じた後、ロードバランサ２０がＳＩＰリクエストを受信すると、ロードバランサ２０は、ＳＩＰリクエストをホストＡ１０−１のＷｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ１００−１にフォワードする（Ｓ７０１）。

ロードバランサ２０からＳＩＰリクエストが与えられると、Ｗｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ１００−１において、ＳＩＰリクエストはＳＩＰセッションマネージャ１７０ヘフォワードされる（Ｓ７０２）。

ＳＩＰリクエストがＳＩＰセッションマネージャ１７０に与えられると、ＳＩＰセッションマネージャ１７０は、当該ＳＩＰセッションを検索する。しかし、ＳＩＰセッションマネージャ１７０は、当該ＳＩＰセッションを検索することができず、ＳＩＰレプリケーションマネージャ１８０のＳＩＰセッション取得部１８１にＳＩＰセッションを取得するよう要求する（Ｓ７０３）。

ＳＩＰセッションマネージャ１７０からの要求を受けると、ＳＩＰセッション取得部１８１は、当該ＳＩＰセッションのダイアログＩＤをキーとしてデータベース３０からＨＴＴＰセッションＩＤを取得する（Ｓ７０４）。

データベース３０からＨＴＴＰセッションＩＤを取得すると、ＳＩＰセッション取得部１８１は、そのＨＴＴＰセッションＩＤに基づいてＨＴＴＰセッションマネージャ１３０から対応するＨＴＴＰセッション１４０を取得する（Ｓ７０５）。

ＨＴＴＰセッション１４０を取得すると、ＳＩＰセッション取得部７１８１は、ＨＴＴＰセッション１４０の属性に格納されているレプリケーション可能なオブジェクトの形式であるＳＩＰアプリケーションセッションを取得する（Ｓ７０６）。

ＳＩＰセッション取得部１８１は、取得したオブジェクトを元のＳＩＰアプリケーションセッションに変換して、ＳＩＰアプリケーションセッションの復元を行う（Ｓ７０７）。このとき、レプリケーション可能形式のすべてオブジェクトを元のオブジェクトに変換する。

ＳＩＰアプリケーションセッションを復元すると、ＳＩＰセッション取得部１８１は、ＳＩＰアプリケーションセッションと、それが保持するＳＩＰセッションを、ＳＩＰセッションマネージャ１７０へ格納する（Ｓ７０８）。

ＳＩＰアプリケーションセッションとＳＩＰセッションが与えられると、ＳＩＰセッションマネージャ１７０は、ＳＩＰ Ｓｅｒｖｌｅｔコンテキスト１６０へＳＩＰリクエストをフォワードする（Ｓ７０９）。

ＳＩＰ Ｓｅｒｖｌｅｔコンテキスト１６０は、ＳＩＰリクエストを適切なＳＩＰＳｅｒｖｌｅｔヘフォワードする。ＳＩＰ Ｓｅｒｖｌｅｔはリクエストを処理する（Ｓ７１０）。

（Ａ−３）第１の実施形態の効果
以上のように、第１の実施形態によれば、従来のＳＩＰレプリケーションエンジンの代りに、ＳＩＰレプリケーションマネージャを設けることにより、Ｗｅｂ−ＡＰサーバのレプリケーションエンジンを利用して、ＳＩＰのレプリケーション機能を実現することができる。これにより、ＳＩＰ−ＡＰサーバ機能自身でＳＩＰレプリケーション機能を持つ必要がなくなる。

また、本実施形態によれば、ＳＩＰセッションのレプリカの生成にＨＴＴＰセッションを利用しているため、Ｗｅｂ−ＡＰサーバから簡単にＳＩＰレプリケーション機能のコントロールが可能となる。

（Ｂ）他の実施形態
第１の実施形態では、ＨＴＴＰセッションを利用してＳＩＰのセッションのレプリケーションを行う方法の実現例を説明したが、本発明の方式を利用することにより、ＳＩＰのセッションだけではなく、ＳＩＰのトランザクションのレプリケーションにも適用できる。

第１の実施形態の統合サーバの内部機能を示す機能ブロック図である。 従来の統合サーバの内部機能を示す機能ブロック図である。 第１の実施形態の通信システムの全体構成図である。 第１の実施形態のＳＩＰレプリケーションマネージャの機能を示す機能ブロック図である。 第１の実施形態においてＳＩＰセッションを説明するためのシーケンスである。 第１の実施形態においてＳＩＰセッションを説明するためのメッセージ例を示す説明図である。 第１の実施形態においてＳＩＰセッションを説明するためのメッセージ例を示す説明図である。 第１の実施形態においてＳＩＰセッションを説明するためのシーケンスである。 第１の実施形態のＳＩＰセッション登録の動作を示すシーケンスである（初期リクエスト受信時）。 第１の実施形態のＳＩＰセッション登録の動作を示すシーケンスである（初期リクエストの応答時）。 第１の実施形態のＳＩＰセッション登録の動作を示すシーケンスである（後続リクエスト受信時）。 第１の実施形態のＳＩＰセッション登録の動作を示すシーケンスである（後続リクエストの応答時）。 第１の実施形態のＳＩＰアプリケーションセッション削除の動作を示すシーケンスである。 第１の実施形態のＳＩＰセッション削除の動作を示すシーケンスである。 第１の実施形態のフェイルオーバ時のＳＩＰセッション取得の動作を示すシーケンスである。

符号の説明

１００…Ｗｅｂ−ＡＰ・ＳＩＰ−ＡＰ融合サーバ、１１０…ＨＴＴＰレプリケーションエンジン、１２０…ＨＴＴＰ Ｓｅｒｖｌｅｔ コンテナ、１３０…ＨＴＴＰ セッションマネージャ、１４０…ＨＴＴＰセッション、１５０…ＳＩＰ Ｓｅｒｖｌｅｔ コンテナ、１６０…ＳＩＰ Ｓｅｒｖｌｅｔ コンテキスト、１７０…ＳＩＰ セッションマネージャ、１８０…ＳＩＰ レプリケーションマネージャ、３０…データベース、１８１…ＳＩＰセッション取得部、１８２…ＳＩＰセッション登録部、１８３…ＳＩＰセッション削除部、１８４…ＳＩＰアプリケーションセッション取得部、１８５…ＳＩＰアプリケーションセッション登録部、１８６…ＳＩＰアプリケーションセッション削除部。

Claims (14)

1. 第１サーバ及び第２サーバと、前記第１サーバ及び前記第２サーバと接続する記憶装置とを有する通信システムにおいて、
   前記第１サーバは、第１処理部、第２処理部、第１管理部、第２管理部、設定部、レプリカ生成部、登録部を有し、
   前記第２サーバは、取得部、処理部を有し、
   前記第１サーバにおいて、
   前記第１処理部が、受信したＨＴＴＰに係る信号に対応する処理を行い、
   前記第２処理部が、受信したＳＩＰに係る信号に対応する処理を行い、
   前記第１管理部が、ＨＴＴＰに係る処理を管理し、
   前記第２管理部が、ＳＩＰに係る処理を管理し、
   前記設定部が、ＳＩＰに係る処理の情報をレプリケーション可能なオブジェクトに変換して、ＨＴＴＰに係る処理の情報として設定し、
   前記レプリカ生成部が、前記ＨＴＴＰに係る処理の情報のレプリカを生成し、その生成したレプリカを前記第２サーバとの間で同期し、
   前記登録部が、前記レプリカ生成部により生成された前記レプリカの第１識別情報と、当該ＨＴＴＰに係る処理の情報に設定したＳＩＰに係る処理を一意に特定する第２識別情報とを対応付けて前記記憶装置に格納し、
   前記記憶装置は、前記レプリカの第１識別情報と、前記ＳＩＰに係る処理の第２識別情報とを対応付けて記憶するものであり、
   前記第２サーバにおいて、
   前記取得部は、
   ＳＩＰに係る信号を受信したときに、
   前記記憶装置から、前記ＳＩＰに係る信号に含まれる前記第２識別情報に対応する前記レプリカの前記第１識別情報を取得し、
   取得した前記レプリカの前記第１識別情報に対応する前記ＨＴＴＰに係る処理の情報を取得し、
   取得した前記ＨＴＴＰに係る処理の情報として設定されたオブジェクトを変換して、ＳＩＰに係る処理の情報の復元を行い、
   前記処理部は、前記取得部により復元された前記ＳＩＰに係る処理の情報を用いてＳＩＰに係る処理を行う
   ことを特徴とする通信システム。
2. 請求項１に記載の通信システムは、さらに中継装置を有し、
   前記中継装置は、プロトコル処理部と、負荷分散処理部、障害処理部とを有し、
   前記プロトコル処理部は、前記ＨＴＴＰに係る信号と前記ＳＩＰに係る信号を処理し、
   前記負荷分散処理部は、前記ＳＩＰに係る信号を受信して、前記第１サーバと前記第２サーバとの間の負荷を分散させるように、前記ＳＩＰに係る信号を前記第１サーバに送信し、
   前記障害処理部は、前記第１サーバに障害が生じたときに、前記ＳＩＰに係る信号を受信すると、前記ＳＩＰに係る信号を前記第２サーバに送信すること
   を特徴とする通信システム。
3. 請求項１又は２に記載の通信システムにおいて、
   前記ＳＩＰに係る処理は、ＳＩＰセッション、またはＳＩＰトランザクションであることを特徴とする通信システム。
4. 請求項１〜３のいずれかに記載の通信システムにおいて、
   前記レプリカは、前記ＳＩＰに係る処理をレプリケーション可能となるように変換されたオブジェクトを、前記ＨＴＴＰに係る処理の属性情報に設定されたものであることを特徴とする通信システム。
5. 第１サーバ及び第２サーバと、前記第１サーバ及び前記第２サーバに接続する記憶装置とを有する通信システムの通信方法において、
   前記第１サーバは、第１処理部、第２処理部、第１管理部、第２管理部、設定部、レプリカ生成部、登録部を有し、
   前記第２サーバは、取得部、処理部を有し、
   前記第１サーバにおいて、
   前記第１処理部が、受信したＨＴＴＰに係る信号に対応する処理を行い、
   前記第２処理部が、受信したＳＩＰに係る信号に対応する処理を行い、
   前記第１管理部が、ＨＴＴＰに係る処理を管理し、
   前記第２管理部が、ＳＩＰに係る処理を管理し、
   前記設定部が、ＳＩＰに係る処理の情報をレプリケーション可能なオブジェクトに変換して、ＨＴＴＰに係る処理の情報として設定し、
   前記レプリカ生成部が、前記ＨＴＴＰに係る処理の情報のレプリカを生成し、その生成したレプリカを前記第２サーバとの間で同期し、
   前記登録部が、前記レプリカ生成部により生成された前記レプリカの第１識別情報と、当該ＨＴＴＰに係る処理の情報に設定したＳＩＰに係る処理を一意に特定する第２識別情報とを対応付けて前記記憶装置に格納し、
   前記記憶装置は、前記レプリカの第１識別情報と、前記ＳＩＰに係る処理の第２識別情報とを対応付けて記憶し、
   前記第２サーバにおいて、
   前記取得部は、
   ＳＩＰに係る信号を受信したときに、
   前記記憶装置から、前記ＳＩＰに係る信号に含まれる前記第２識別情報に対応する前記レプリカの前記第１識別情報を取得し、
   取得した前記レプリカの前記第１識別情報に対応する前記ＨＴＴＰに係る処理の情報を取得し、
   取得した前記ＨＴＴＰに係る処理の情報として設定されたオブジェクトを変換して、ＳＩＰに係る処理の情報の復元を行い、
   前記処理部は、前記取得部により復元された前記ＳＩＰに係る処理の情報を用いてＳＩＰに係る処理を行う
   ことを特徴とする通信方法。
6. 請求項５に記載の通信方法において、前記通信システムはさらに中継装置を有し、
   前記中継装置は、プロトコル処理部と、負荷分散処理部、障害処理部とを有し、
   前記プロトコル処理部は、前記ＨＴＴＰに係る信号と前記ＳＩＰに係る信号を処理し、
   前記負荷分散処理部は、前記ＳＩＰに係る信号を受信して、前記第１サーバと前記第２サーバとの間の負荷を分散させるように、前記ＳＩＰに係る信号を前記第１サーバに送信し、
   前記障害処理部は、前記第１サーバに障害が生じたときに、前記ＳＩＰに係る信号を受信すると、前記ＳＩＰに係る信号を前記第２サーバに送信すること
   を特徴とする通信方法。
7. 請求項５又は６に記載の通信方法において、
   前記ＳＩＰに係る処理は、ＳＩＰセッション、またはＳＩＰトランザクションであることを特徴とする通信方法。
8. 請求項５〜７のいずれかに記載の通信方法において、
   前記レプリカは、前記ＳＩＰに係る処理をレプリケーション可能となるように変換されたオブジェクトを、前記ＨＴＴＰに係る処理の属性情報に設定されたものであることを特徴とする通信方法。
9. 他の通信装置との間で、ＳＩＰに係る処理の情報をレプリケーション可能なオブジェクトに変換して、ＨＴＴＰに係る処理の情報として設定された当該ＨＴＴＰに係る処理の情報のレプリカの同期を他の通信装置との間で行うものであり、前記レプリカの第１識別情報と前記ＳＩＰに係る処理の第２識別情報とを対応付けて記憶する記憶装置と接続する通信装置において、
   ＳＩＰに係る信号を受信したときに、
   前記記憶装置から、前記ＳＩＰに係る信号に含まれる前記第２識別情報に対応する前記レプリカの前記第１識別情報を取得し、
   取得した前記レプリカの前記第１識別情報に対応する前記ＨＴＴＰに係る処理の情報を取得し、
   取得した前記ＨＴＴＰに係る処理の情報として設定されたオブジェクトを変換して、ＳＩＰに係る処理の情報の復元を行う取得部と、
   前記取得部により復元された前記ＳＩＰに係る処理の情報を用いてＳＩＰに係る処理を行う処理部と
   を備えることを特徴とする通信装置。
10. 請求項９に記載の通信装置において、
    前記ＳＩＰに係る処理は、ＳＩＰセッション、またはＳＩＰトランザクションであることを特徴とする通信装置。
11. 請求項９又は１０に記載の通信装置において、
    前記レプリカは、前記ＳＩＰに係る処理をレプリケーション可能となるように変換されたオブジェクトを、前記ＨＴＴＰに係る処理の属性情報に設定されたものであることを特徴とする通信装置。
12. 他の通信装置との間で、ＳＩＰに係る処理の情報をレプリケーション可能なオブジェクトに変換して、ＨＴＴＰに係る処理の情報として設定された当該ＨＴＴＰに係る処理の情報のレプリカの同期を他の通信装置との間で行うものであり、前記レプリカの第１識別情報と前記ＳＩＰに係る処理の第２識別情報とを対応付けて記憶する記憶装置と接続する通信装置の通信方法において、
    前記通信装置は、取得部と処理部とを有し、
    前記取得部が、
    ＳＩＰに係る信号を受信したときに、
    前記記憶装置から、前記ＳＩＰに係る信号に含まれる前記第２識別情報に対応する前記レプリカの前記第１識別情報を取得し、
    取得した前記レプリカの前記第１識別情報に対応する前記ＨＴＴＰに係る処理の情報を取得し、
    取得した前記ＨＴＴＰに係る処理の情報として設定されたオブジェクトを変換して、ＳＩＰに係る処理の情報の復元を行い、
    前記処理部は、前記取得部により復元された前記ＳＩＰに係る処理の情報を用いてＳＩＰに係る処理を行う
    ことを特徴とする通信方法。
13. 請求項１２に記載の通信方法において、
    前記ＳＩＰに係る処理は、ＳＩＰセッション、またはＳＩＰトランザクションであることを特徴とする通信方法。
14. 請求項１２又は１３に記載の通信方法において、
    前記レプリカは、前記ＳＩＰに係る処理をレプリケーション可能となるように変換されたオブジェクトを、前記ＨＴＴＰに係る処理の属性情報に設定されたものであることを特徴とする通信方法。

Images