JP5220059B2

JP5220059B2 - ネットワーク通信システム及びネットワーク通信方法

Info

Publication number: JP5220059B2
Application number: JP2010126904A
Authority: JP
Inventors: 大輔原; 義樹江村
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2010-06-02
Filing date: 2010-06-02
Publication date: 2013-06-26
Anticipated expiration: 2030-06-02
Also published as: JP2011254303A

Description

本発明は、ＳＯＡＰ（Simple Object Access Protocol）／ＲＥＳＴ（Representational State Transfer）による呼制御インタフェースを備えたネットワーク通信システム及びネットワーク通信方法に関する。

従来から、次世代ネットワーク（ＮＧＮ；Next Generation Network）でのアプリケーションサービスを制御する機能として、ＩＴＵ−Ｔ勧告Ｙ．２０１２において規定されるApplication Support Functions and Service Support Functions（ＡＳＦ＆ＳＳＦ）が知られている（例えば、非特許文献１参照）。ＡＳＦ＆ＳＳＦの構成要素のうち、Application gateway functional entity（ＡＰＬ−ＧＷ−ＦＥ）は、次世代ネットワーク（ＮＧＮ）外部のアプリケーション（ＡＰＬ）向けのゲートウェイであり、外部ＡＰＬ向けのＳＯＡＰ（例えば、非特許文献２参照）やＲＥＳＴインタフェースと次世代ネットワーク（ＮＧＮ）向けのＳＩＰ（Session Initiation Protocol）とのインタワークを行うものである。

ＩＴＵ−ＴＹ．２０１２０９／２００６ＥＴＳＩＥＳ２０２５０４Ｐａｒｔ１，２，３，４，１１

ところで、次世代ネットワーク（ＮＧＮ）におけるＡＰＬ−ＧＷ−ＦＥ含むＡＳＦ＆ＳＳＦでは、ＰＳＴＮ（Public Switched Telephone Networks）における電話交換機と同程度の信頼性／可用性が要求されるため、プログラムのコード量が膨大になり開発コスト高くなるという問題がある。一方、ＳＯＡＰやＲＥＳＴインタフェースの処理機能が実装されたオープンソースソフトウェア等の市中製品が存在しているが、ＳＩＰ呼処理を行う高信頼／高可用な呼処理ソフトウェアと信頼性条件やメモリ動的確保などの性能条件が異なり、単に組合せて利用するだけではＡＰＬ−ＧＷ−ＦＥシステム全体の信頼性が低下してしまうという問題がある。

本発明は、このような事情に鑑みてなされたもので、市中製品をシステム内に組み込む場合であっても信頼性／可用性を向上させることができるネットワーク通信システム及びネットワーク通信方法を提供することを目的とする。

本発明は、外部アプリケーションサーバからのＳＯＡＰ／ＲＥＳＴリクエストを処理する要求受付手段と、前記外部アプリケーションサーバに対してＳＯＡＰリクエストを送信する非同期通知手段とからなる呼制御インタフェースと、呼処理を行う呼処理手段とを備え、前記外部アプリケーションサーバ向けのゲートウェイ機能を実現する現用系と待機系の２系統のサーバによって構成するネットワーク通信システムであって、前記２系統のサーバ内のメモリに記憶されている情報を同期させるメモリ同期手段と、現用系の切り替えを行う際に、前記メモリ同期手段により、現時点で現用系となっている前記サーバと現時点で待機系となっている前記サーバのメモリ内の情報を同期させて現用系の切り替えを行った後に前記呼処理手段により呼処理を実行させる高可用処理手段とを備え、前記呼処理手段は、前記高可用処理手段からの起動要求を受けると、前記要求受付手段に対して、起動要求を送信した後に、前記非同期通知手段に対して起動要求を送信し、前記高可用処理手段は、前記要求受付手段と前記非同期通知手段が起動したことを確認した後に、前記呼処理手段に対して、該呼処理手段を備えるサーバが現用系となるための処理を実行し、現用系の切り替えを行う際には、前記呼処理手段に対して、現用系の処理を停止させるための処理を実行することを特徴とする。

本発明は、前記高可用処理手段は、前記呼処理手段に対して、ヘルスチェックの要求を送信することにより前記呼処理手段にリクエスト送信要求を送信させ、該リクエスト送信要求に対して、前記非同期通知手段が要求受付手段に対して送信したリクエストに応じて、前記要求受付手段が前記非同期通知手段に対して送信したレスポンスの状況を示す情報を前記呼処理手段に受信させて、前記レスポンスの状況を示す情報に基づいてヘルスチェックを行うことを特徴とする。

本発明は、前記高可用処理手段が提供する高可用機能に関するインタフェースを前記呼処理手段内で終端させるように構成したことを特徴とする。

本発明は、外部アプリケーションサーバからのＳＯＡＰ／ＲＥＳＴリクエストを処理する要求受付手段と、前記外部アプリケーションサーバに対してＳＯＡＰリクエストを送信する非同期通知手段とからなる呼制御インタフェースと、呼処理を行う呼処理手段とを備え、前記外部アプリケーションサーバ向けのゲートウェイ機能を実現するため現用系と待機系の２系統のサーバと、前記２系統のサーバ内のメモリに記憶されている情報を同期させるメモリ同期手段とを備えるネットワーク通信システムにおけるネットワーク通信方法であって、現用系の切り替えを行う際に、前記メモリ同期手段により、現時点で現用系となっている前記サーバと現時点で待機系となっている前記サーバのメモリ内の情報を同期させて現用系の切り替えを行った後に前記呼処理手段により呼処理を実行させる高可用処理ステップを有し、前記呼処理手段は、前記高可用処理ステップからの起動要求を受けると、前記要求受付手段に対して起動要求を送信した後に、前記非同期通知手段に対して起動要求を送信し、前記高可用処理ステップは、前記要求受付手段と前記非同期通知手段が起動したことを確認した後に、前記呼処理手段に対して、該呼処理手段を備えるサーバが現用系となるための処理を実行し、現用系の切り替えを行う際には、前記呼処理手段に対して、現用系の処理を停止させるための処理を実行することを特徴とする。

本発明は、前記高可用処理ステップでは、前記呼処理手段に対して、ヘルスチェックの要求を送信することにより前記呼処理手段にリクエスト送信要求を送信させ、該リクエスト送信要求に対して、前記非同期通知手段が要求受付手段に対して送信したリクエストに応じて、前記要求受付手段が前記非同期通知手段に対して送信したレスポンスの状況を示す情報を前記呼処理手段に受信させて、前記レスポンスの状況を示す情報に基づいてヘルスチェックを行うことを特徴とする。

本発明は、前記高可用処理ステップが提供する高可用機能に関するインタフェースを前記呼処理手段内で終端させるように構成したことを特徴とする。

本発明によれば、高可用処理部が提供する高可用機能に関するインタフェースを呼処理部内で終端させ、ＳＯＡＰ／ＲＥＳＴアダプタ側のインタフェースに変換するようにしたため、市中製品であるＳＯＡＰ／ＲＥＳＴアダプタのバージョンアップ等があっても、ＳＯＡＰ／ＲＥＳＴアダプタには改造を加えること無く信頼性／可用性を担保することが可能になるという効果が得られる。

本発明の一実施形態の構成を示すブロック図である。図１に示す装置の動作を示す図である。図１に示す装置の動作を示すシーケンス図である。図１に示す装置の動作を示すシーケンス図である。図１に示す装置の動作を示すシーケンス図である。図１に示す装置の動作を示すシーケンス図である。システム構成の違いによる評価結果を示す図である。

以下、図面を参照して、本発明の一実施形態によるネットワーク通信システムを説明する。図１は同実施形態の構成を示すブロック図である。この図において、符号１１、１２、１３は、ユーザによって利用される端末装置であり、電話機や、携帯電話機、あるいは、インターネット接続可能なコンピュータ等である。符号２は、複数の端末１１、１２、１３が接続されるネットワークである。符号３は、音声データ、画像データあるいは動画データ等を記憶しているメディアサーバである。符号４は、ＳＯＡＰ（Simple Object Access Protocol）／ＲＥＳＴ（Representational State Transfer）による呼制御インタフェース及びＳＩＰによる呼処理機能を備えたアプリケーションサービス提供システムであり、複数のサーバによって構成する。符号５は、現用系のサーバであり、ＡＰＬ−ＧＷ−ＦＥの機能を実現する。符号６は、待機系のサーバであり、ＡＰＬ−ＧＷ−ＦＥの機能を実現する。待機系と現用系は、論理的な呼称であり、現在運用されているサーバが現用系サーバであり、障害等が発生した場合に切り替えを行うために待機しているサーバが待機系のサーバある。符号７は、外部ＡＰＬ（アプリケーション）を提供するサーバが接続されている外部ＡＰＬネットワークである。符号８１、８２は、外部のアプリケーション（ＡＰＬ）を提供するサーバである。

符号５１は、端末１１、１２、１３からの呼を処理する呼処理部である。符号５２は、可用性を高めるための処理を実行する高可用処理部である。符号５３は、市中製品であるＳＯＡＰ／ＲＥＳＴアダプタであり、外部ＡＰＬ８１、８２からのＨＴＴＰリクエスト（ＳＯＡＰ／ＲＥＳＴ）を処理する要求受付部５３１と、外部ＡＰＬ８１、８２へＨＴＴＰリクエスト（ＳＯＡＰ）を送信する非同期通知部５３２とから構成する。符号５４は、現用系サーバ５と待機系サーバ６内のメモリに記憶されている情報の同期を取るメモリ同期部である。呼処理部５１は、ＳＯＡＰ／ＲＥＳＴアダプタ５３のメモリ使用量の制限、ＳＯＡＰ／ＲＥＳＴアダプタ５３のプロセス監視、起動・系切り替え、ヘルスチェック等のプロセス管理を行う。

符号６１は、端末１１、１２、１３からの呼を処理する呼処理部である。符号６２は、可用性を高めるための処理を実行する高可用処理部である。符号６３は、市中製品であるＳＯＡＰ／ＲＥＳＴアダプタであり、外部ＡＰＬ８１、８２からのＨＴＴＰリクエスト（ＳＯＡＰ／ＲＥＳＴ）を処理する要求受付部６３１と、外部ＡＰＬ８１、８２へＨＴＴＰリクエスト（ＳＯＡＰ）を送信する非同期通知部６３２とから構成する。符号６４は、現用系サーバ５と待機系サーバ６内のメモリに記憶されている情報の同期を取るメモリ同期部である。呼処理部６１は、ＳＯＡＰ／ＲＥＳＴアダプタ６３のメモリ使用量の制限、ＳＯＡＰ／ＲＥＳＴアダプタ６３のプロセス監視、起動・系切り替え、ヘルスチェック等のプロセス管理を行う。２つのサーバ５、６内の構成は同じであり、現用系の切り替えを行う場合、運用されていない状態の待機系のサーバ６のメモリ内の情報と、現用系サーバ５内のメモリに記憶されている情報と同一の状態になるようにしてから、現用系と待機系の切り替えが行われる。

次に、図２を参照して、アプリケーションサービス提供システム４が扱う通信の分類について説明する。アプリケーションサービス提供システム４が扱う通信は、次の３種類に分類することができる。第１の通信は、端末１１と呼処理部５１によるＳＩＰのみで完了するものである（図２に示す（ａ））。第２の通信は、外部ＡＰＬ８１、要求受付部５３１、呼処理部５１によるＳＯＡＰリクエスト等ＨＴＴＰリクエストを契機に、ＨＴＴＰレスポンス及びＳＩＰ送信が発生するもの（例：Click to dial）である（図２に示す（ｂ）。第３の通信は、外部ＡＰＬ８２、非同期通知部５３２、呼処理部５１、端末１３によるＳＩＰ受信を契機に、ＨＴＴＰリクエストを送信、ＨＴＴＰレスポンスを受信するもの（例：端末の発呼を外部ＡＰＬに通知する）である。各処理部の依存関係は、要求受付部５３１、呼処理部５１、非同期通知部５３２の順となる。したがって、各処理部が処理要求の受付を開始する順序はこの逆順となり、非同期通知部５３２、呼処理部５１、要求受付部５３１となる。また、終了順序は、要求受付部５３１、呼処理部５１、非同期通知部５３２となる。

次に、図３を参照して、ＡＰＬ−ＧＷ−ＦＥ機能を実現するサーバ５の処理動作を説明する。図３は、起動とサーバ５、サーバ６のいずれかを現用系にするための処理動作を示すシーケンス図である。図３において、細い実線はその処理部が起動状態であることを示している。また、太い実線は、その処理部が処理要求を受付可能な状態であることを示している。

まず、高可用処理部５２は、呼処理部５１に対して起動要求を送信する（ステップＳ１）。これにより呼処理部５１は、起動し、要求受付部５３１に対して起動要求を送信する（ステップＳ２）。これにより要求受付部５３１が起動する。続いて、呼処理部５１は、非同期通知部５３２に対して起動要求を送信する（ステップＳ３）。これにより非同期部５３２が起動し、処理要求受付可能となる。

次に、呼処理部５１は、要求受付部５３１、非同期通知部５３２のそれぞれに対して起動要求を送信し、起動させたこと示す情報を含む応答を高可用処理部５２へ送信する（ステップＳ４）。これを受けて、高可用処理部５２は、現用系として設定する「ＡＣＴ」命令を呼処理部５１へ送信する（ステップＳ５）。これにより、呼処理部５１は、現用系となり、ＳＩＰ着信許可状態となる。また、要求受付部５３１は、ＨＴＴＰ着信許可状態となる（ステップＳ６、Ｓ７）。このＳＩＰ／ＨＴＴＰ着信許可は、サーバ５のＯＳ（例えば、Linux）は有するパケットフィルタリング機能（例えば、iptables）を利用する。これにより、呼処理部５１と要求受付部５３１は、処理要求受付可能となる。これを受けて、呼処理部５１は、呼処理部５１と要求受付部５３１が理要求受付可能となったことを示す情報を含む応答を高可用処理部５２へ返す（ステップＳ８）。

次に、図４を参照して、ＡＰＬ−ＧＷ−ＦＥ機能を実現するサーバ５の処理動作を説明する。図４は、系切替の際に現用系が処理を停止するための静止化処理の動作を示すシーケンス図である。図４において、細い実線はその処理部が起動状態であることを示している。また、太い実線は、その処理部が処理要求を受付可能な状態であることを示している。

まず、高可用処理部５２は、呼処理部５１に対して静止化要求を送信する（ステップＳ１１）。静止化とは、系切替の際に現用系が処理を停止するための処理を実行することである。これにより呼処理部５１、要求受付部５３１は、ＨＴＴＰ着信を拒否するようになり、要求受付部５３１は、処理要求受付可能状態でなくなる（ステップＳ１２）。また、呼処理部５１は、ＳＩＰ着信を拒否するようになる（ステップＳ１３）。このＳＩＰ／ＨＴＴＰ着信拒否は、サーバ５のＯＳ（例えば、Linux）は有するパケットフィルタリング機能（例えば、iptables）を利用する。ただし、非同期通知部５３２は、常時処理要求を受付可能な状態である。続いて、ＨＴＴＰ掃き出し処理（呼処理部５１の静止化処理）を行う期間となり、静止化処理が完了した時点で、呼処理部５１は、静止化処理が完了したことを示す情報を含む応答を高可用処理部５２へ返す（ステップＳ１４）。

次に、図５を参照して、ＡＰＬ−ＧＷ−ＦＥ機能を実現するサーバ５の処理動作を説明する。図５は、ヘルスチェック処理の動作を示すシーケンス図である。ヘルスチェックとは、ＳＯＡＰ／ＲＥＳＴアダプタ５３の正常性を確認することである。まず、高可用処理部５２は、呼処理部５１に対してヘルスチェック要求を送信する（ステップＳ２１）。呼処理部５１は、高可用処理部５２からヘルスチェック要求を受信すると、ＡＰＬ−ＧＷ−ＦＥ（サーバ５）自身に対するダミーのＳＯＡＰまたはＲＥＳＴリクエストを送信するよう、非同期通知部５３２に対してリクエスト送信要求を送信する（ステップＳ２２）。

これを受けて、非同期通知部５３２は、要求受付部５３１に対してＳＯＡＰリクエストまたはＲＥＳＴリクエストを送信する（ステップＳ２３）。このリクエストに対して、要求受付部５３１は、非同期通知部５３２に対してＳＯＡＰレスポンスまたはＲＥＳＴレスポンスを送信する（ステップＳ２４）。このレスポンスを受信すると、非同期通知部５３２は、呼処理部５１に対して、ヘルスチェックを行った結果を示す情報を含むレスポンスを返す（ステップＳ２５）。呼処理部５１は、非同期通知部５３２からのレスポンス内容に応じて、高可用処理部５２に対して「ＯＫ」または「ＮＧ」の情報をヘルスチェック要求の応答として送信する（ステップＳ２６）。

このように、ヘルスチェックを行うことにより、一度に非同期通知部５３２と要求受付部５３１両方の正常性を確認することが可能となる。また、リクエスト／レスポンスは通常と同じ処理ルート（インタフェース）を用いて行うため、ＯＳＳ側の改造が不要である。

次に、図６を参照して、現用系と待機系（予備系）の切り替えを行う際のメモリの同期を行う動作を説明する。図６は、現用系と待機系（予備系）の切り替えを行う際のメモリの同期を行う動作を示すシーケンス図である。まず、現用系（サーバ５）の切り替えを行う状況になった場合、呼処理部５１は、高可用処理部５２に対して、同期用のデータの書き込みを要求する（ステップＳ３１）。これを受けて、高可用処理部５２は、メモリ同期部５４に対して、メモリ内の情報を同期させる指示を出す。これを受けて、メモリ同期部５４は、同期用のデータをメモリ同期部６４へ書き込む。これにより２つの系のメモリの同期が取れたことになる。続いて、高可用処理部５２は、呼処理部５１に対してメモリ同期の処理を行ったことを示す情報を含む応答を返す（ステップＳ３２）。そして、系の切り替えを行う。

次に、呼処理部６１は、系の切り替えが行われると、高可用処理部６２に対して、同期用データの読み込みを要求する（ステップＳ３３）。これを受けて、高可用処理部６２は、メモリ同期部６４に対して、同期用データの読み込みを指示する。メモリ同期部６４は、同期用データの読み込みを行う。高可用処理部６２は、呼処理部６１に対して、メモリ同期処理が終了したことを示す情報を含む応答を返す（ステップＳ３４）。これによりサーバ６が現用系となり呼処理を行うとともに、サーバ５が待機系（予備系）となる。

次に、図７を参照して、ＳＯＡＰ／ＲＥＳＴアダプタとして市中製品を用いない場合と本発明との比較結果について説明する。比較対象は、（１）呼処理部とＳＯＡＰ／ＲＥＳＴアダプタが別構成であるがアダプタも開発する方法、（２）呼処理部内にＳＯＡＰ／ＲＥＳＴアダプタ機能を内蔵しアダプタも開発する方法、（３）本発明の呼処理部と市中製品であるＳＯＡＰ／ＲＥＳＴアダプタを別構成とした方法の３つである。図７に示すように、ＳＯＡＰ／ＲＥＳＴアダプタ障害時の影響範囲は、アダプタと呼処理部を別構成とした（１）、（３）の方法が優れており、呼処理部内にアダプタ機能を備えた（２）の方法は、呼処理部が異常終了してしまう危険性があり劣っている。また、ＳＯＡＰ／ＲＥＳＴ／ＨＴＴＰ仕様のバージョンアップと開発コストに対しては、市中製品を用いた（３）の方法が優れており、市中製品を用いない（１）、（２）の方法は、バージョンアップの度に開発する作業が必要となるため劣っている。この比較結果から明らかなように、本発明の方法が他の方法より優れていることが分かる。

次世代ネットワーク（ＮＧＮ）でのアプリケーションサービスを制御する機能をサーバ上に実装する際には、ＰＳＴＮにおける電話交換機と同程度の信頼性／可用性が要求されており、通常は、同機能を構成する高可用処理部に合わせて他の構成要素が作成されるため、その一部である外部アプリケーション向けのインタフェースを提供するＳＯＡＰ／ＲＥＳＴアダプタ機能に市中製品を単純に採用すると機能全体の信頼性／可用性が低下する。一方、これらを改造するとソフトウェア開発を頻繁に行う必要が生じるが、高可用処理部が提供する高可用機能に関するインタフェースを呼処理部で終端し、ＳＯＡＰ／ＲＥＳＴアダプタ側のインタフェースに変換することにより、ＳＯＡＰ／ＲＥＳＴアダプタのバージョンアップ等があっても、ＳＯＡＰ／ＲＥＳＴアダプタには改造を加えること無く信頼性／可用性を担保することが可能となる。

なお、図１に示すサーバ５、サーバ６の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによりアプリケーションサービス提供処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。

また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。

以上説明したように、市中製品（ＳＯＡＰ／ＲＥＳＴアダプタ）を改造せずに呼処理部が利用する高可用処理に対応するため、高可用処理部が提供する高可用機能（現用系と待機系を備えたクラスタ構成、起動・系切り替えヘルスチェック等のプロセス管理機能、系間のメモリ同期機能）に関するインタフェースを呼処理部側で終端し、市中製品側のインタフェースに変換するようにした。また、動的にメモリを確保する市中製品の処理が呼処理に悪影響を与えないように、市中製品の処理が使用するメモリ量を制限するようにした。

このため、外部ＡＰＬ向けのインタフェースを提供するＳＯＡＰ／ＲＥＳＴアダプタを少ないコード量で提供することが可能となる。また、市中製品単体のアップデートする際に、呼処理部に対する変更作業が不要となる。特に、ＡＰＬ−ＧＷ−ＦＥへＳＯＡＰ／ＲＥＳＴインタフェース処理機能（ＳＯＡＰ／ＲＥＳＴアダプタ）を具備する際、呼処理部とＳＯＡＰ／ＲＥＳＴアダプタを提供する市中製品を組合せ、ＡＰＬ−ＧＷ−ＦＥ全体の信頼性／可用性を確保すると共に、プログラムのコード量を最小化することが可能となる。また、市中製品は、不具合の修正等により頻繁にアップデートされることが想定されるが、市中製品自体には改造を加えず、そのまま利用することが可能となる。

ＳＯＡＰ（Simple Object Access Protocol）／ＲＥＳＴ（Representational State Transfer）による呼制御インタフェースを備えことが不可欠な用途に適用できる。

１１、１２、１３・・・端末、２・・・ネットワーク、３・・・メディアサーバ、４・・・アプリケーションサービス提供システム、５・・・ＡＰＬ−ＧＷ−ＦＥ（サーバ）、５１・・・呼処理部、５２・・・高可用処理部、５３・・・ＳＯＡＰ／ＲＥＳＴアダプタ、５４・・・メモリ同期部、６・・・ＡＰＬ−ＧＷ−ＦＥ（サーバ）、６１・・・呼処理部、６２・・・高可用処理部、６３・・・ＳＯＡＰ／ＲＥＳＴアダプタ、６４・・・メモリ同期部、７・・・外部ＡＰＬ用ネットワーク、８１、８２・・・外部ＡＰＬ

Claims

外部アプリケーションサーバからのＳＯＡＰ／ＲＥＳＴリクエストを処理する要求受付手段と、前記外部アプリケーションサーバに対してＳＯＡＰリクエストを送信する非同期通知手段とからなる呼制御インタフェースと、呼処理を行う呼処理手段とを備え、前記外部アプリケーションサーバ向けのゲートウェイ機能を実現する現用系と待機系の２系統のサーバによって構成するネットワーク通信システムであって、
前記２系統のサーバ内のメモリに記憶されている情報を同期させるメモリ同期手段と、
現用系の切り替えを行う際に、前記メモリ同期手段により、現時点で現用系となっている前記サーバと現時点で待機系となっている前記サーバのメモリ内の情報を同期させて現用系の切り替えを行った後に前記呼処理手段により呼処理を実行させる高可用処理手段と
を備え、
前記呼処理手段は、前記高可用処理手段からの起動要求を受けると、前記要求受付手段に対して、起動要求を送信した後に、前記非同期通知手段に対して起動要求を送信し、
前記高可用処理手段は、前記要求受付手段と前記非同期通知手段が起動したことを確認した後に、前記呼処理手段に対して、該呼処理手段を備えるサーバが現用系となるための処理を実行し、現用系の切り替えを行う際には、前記呼処理手段に対して、現用系の処理を停止させるための処理を実行することを特徴とするネットワーク通信システム。
前記高可用処理手段は、
前記呼処理手段に対して、ヘルスチェックの要求を送信することにより前記呼処理手段にリクエスト送信要求を送信させ、該リクエスト送信要求に対して、前記非同期通知手段が要求受付手段に対して送信したリクエストに応じて、前記要求受付手段が前記非同期通知手段に対して送信したレスポンスの状況を示す情報を前記呼処理手段に受信させて、前記レスポンスの状況を示す情報に基づいてヘルスチェックを行うことを特徴とする請求項１に記載のネットワーク通信システム。
前記高可用処理手段が提供する高可用機能に関するインタフェースを前記呼処理手段内で終端させるように構成したことを特徴とする請求項１または２に記載のネットワーク通信システム。
外部アプリケーションサーバからのＳＯＡＰ／ＲＥＳＴリクエストを処理する要求受付手段と、前記外部アプリケーションサーバに対してＳＯＡＰリクエストを送信する非同期通知手段とからなる呼制御インタフェースと、呼処理を行う呼処理手段とを備え、前記外部アプリケーションサーバ向けのゲートウェイ機能を実現するため現用系と待機系の２系統のサーバと、前記２系統のサーバ内のメモリに記憶されている情報を同期させるメモリ同期手段とを備えるネットワーク通信システムにおけるネットワーク通信方法であって、
現用系の切り替えを行う際に、前記メモリ同期手段により、現時点で現用系となっている前記サーバと現時点で待機系となっている前記サーバのメモリ内の情報を同期させて現用系の切り替えを行った後に前記呼処理手段により呼処理を実行させる高可用処理ステップを有し、
前記呼処理手段は、前記高可用処理ステップからの起動要求を受けると、前記要求受付手段に対して起動要求を送信した後に、前記非同期通知手段に対して起動要求を送信し、
前記高可用処理ステップは、前記要求受付手段と前記非同期通知手段が起動したことを確認した後に、前記呼処理手段に対して、該呼処理手段を備えるサーバが現用系となるための処理を実行し、現用系の切り替えを行う際には、前記呼処理手段に対して、現用系の処理を停止させるための処理を実行することを特徴とするネットワーク通信方法。
前記高可用処理ステップでは、
前記呼処理手段に対して、ヘルスチェックの要求を送信することにより前記呼処理手段にリクエスト送信要求を送信させ、該リクエスト送信要求に対して、前記非同期通知手段が要求受付手段に対して送信したリクエストに応じて、前記要求受付手段が前記非同期通知手段に対して送信したレスポンスの状況を示す情報を前記呼処理手段に受信させて、前記レスポンスの状況を示す情報に基づいてヘルスチェックを行うことを特徴とする請求項４に記載のネットワーク通信方法。
前記高可用処理ステップが提供する高可用機能に関するインタフェースを前記呼処理手段内で終端させるように構成したことを特徴とする請求項４または５に記載のネットワーク通信方法。