JP2005250900A - オブジェクトの管理方法、システム、およびプログラム - Google Patents

Abstract

【課題】オブジェクトとＡＰＩ通信の復旧をプラットフォームとサービスアプリケーションで連携して実施することによりサービス処理を救済できるようにする。
【解決手段】アプリケーションプログラムインタフェースを有するプラットフォームがイベント毎に生成した第１のオブジェクトと、イベント毎にアプリケーションが生成した第２のオブジェクトとがソフトウェアバスを介して通信することによりイベントを処理するシステムにおけるオブジェクトの管理方法において、ソフトウェアバスを介して第１、第２のオブジェクトが互いを参照するために必要な第１、第２のオブジェクト参照情報を含む保存情報を記憶手段に記憶する記憶ステップと、第１、第２のオブジェクトの少なくともいずれかの消滅に応じ、イベントの処理を継続するために必要なオブジェクトを再生する再生ステップと、ソフトウェアバスを介した通信を記憶手段の保存情報を用いて復旧する復旧ステップとを具備する。
【選択図】 図１

Description

本発明は通信システムに好適であり、OpenAPIを搭載するプラットフォームと、OpenAPIを利用するサービスアプリケーションとの間がソフトウェアバスにより結合されたコンピュータシステムにおいて、プロセスの消滅および再起動またはクラスタ切替に応じてオブジェクトを復旧し、オブジェクト間通信を再開するためのオブジェクト管理方法、システム、およびプログラムに関する。

ＯｐｅｎＡＰＩのようなアプリケーションプログラムインタフェース（ＡＰＩ）を有するプラットフォームと、このＡＰＩを使用するサービスアプリケーションとがソフトウェアバスを介して結合され、分散システム環境におけるオブジェクト間のメッセージ交換技術を利用し、プラットフォームのＡＰＩにおいて生成されたオブジェクトとサービスアプリケーションのオブジェクトとがソフトウェアバスを介してオブジェクト間通信を行えるように構成されたシステムが知られている。このようなシステム構成はＩＰネットワークをベースとした種々の電話サービスにも応用されるようになり、いわゆるＶｏＩＰ(Voice Over IP)やＩＰセントレックス(Centrex)として知られる。ユーザに提供する新たなサービスを構築するにあたり、呼処理のような基本的な制御がＯｐｅｎＡＰＩを通じて統一化されることは、開発コスト等を含む多大なメリットがある。

このようなシステムにおいて、種々の障害への耐性を高め、堅牢にサービスを提供し続けることができるような仕組みを備えることが必要とされるが、従来では次のような問題がある。例えば、プラットフォーム側のプロセスが単独で再起動した場合、プロセス起動や呼生起により生成されたプラットフォーム側のオブジェクトが消滅するが、該オブジェクトを再生する情報を保持していないために、再起動後にサービスアプリケーション側で管理しているオブジェクトとの差分が発生し、サービスの続行ができなくなる。サービスアプリケーション側でプロセスが再起動した場合も同様であり、消滅したオブジェクトに関して差分が生じてしまう。一方、呼を処理する現用系と予備系から構成された制御装置間のクラスタ切替においても、現用系のプラットフォームおよびサービスアプリケーションで管理しているオブジェクトに対応するものが予備系のプラットフォームおよびサービスアプリケーションに不存在となり、サービスを続行できなくなる。これらのケースにおけるオブジェクトの扱いに関してOpenAPIではなんら言及されていない（例えば非特許文献１を参照）。

したがって、上記のような問題があることから、従来、プロセス再起動等によるオブジェクトの初期設定においてはサービスを非救済とする他なかった。なお、オブジェクトの集合によりアプリケーションが構成され、これら一連のオブジェクトにより呼接続が実現される電子交換機が例えば下記特許文献１に記載されている。同特許文献１においては呼処理の初期設定についても記載されているが、上記問題の解決策とはならない。

特許第２８５４９５７号

ＥＴＳＩ ＥＳ ２０２ ９１５−３ Ｖ１．２．１ （２００３−０８）

上記のようにOpenAPIを搭載するプラットフォームと、OpenAPIを使用するサービスアプリケーションソフトウェアとの間がソフトウェアバスで結合されたシステムにおいて、これらプラットフォームまたはサービスアプリケーションのプロセスが消滅し、再起動した際に、それぞれのプロセスで管理している呼情報を有するオブジェクトが消滅すると、通話中呼に関する呼の制御を行えないという問題がある。いわゆるＶｏＩＰ(Voice Over IP)やＩＰセントレックス(Centrex)の様なサービスでは、サービスの継続が必要であり、そのためにはオブジェクトの再生ならびにオブジェクト間ＡＰＩ通信の復旧が必須である。

本発明はかかる事情を考慮してなされたものであり、オブジェクトとＡＰＩ通信の復旧をプラットフォームとサービスアプリケーションで連携して実施することにより、サービス処理を救済することができるオブジェクト間通信におけるオブジェクトの管理方法、システム、およびプログラムを提供することを目的とする。

本発明の一観点に係るオブジェクトの管理方法は、アプリケーションプログラムインタフェースを有するプラットフォームがイベント毎に生成した第１のオブジェクトと、前記イベント毎にアプリケーションが生成した第２のオブジェクトとがソフトウェアバスを介して通信することにより前記呼を処理するシステムにおけるオブジェクトの管理方法において、前記ソフトウェアバスを介して前記第１、第２のオブジェクトが互いを参照するために必要な第１、第２のオブジェクト参照情報を含む保存情報を記憶手段に記憶する記憶ステップと、前記第１、第２のオブジェクトの少なくともいずれかの消滅に応じ、前記呼の処理を継続するために必要なオブジェクトを再生する再生ステップと、前記ソフトウェアバスを介した通信を前記記憶手段の保存情報を用いて復旧する復旧ステップとを具備するオブジェクトの管理方法である。

本発明によれば、OpenAPIを搭載し、OpenAPIを使用するソフトウェア間をソフトウェアバスで結合しているシステムにてプロセス再起動の際のサービス継続に必要な情報とそれを保持するオブジェクトに関するオブジェクトとAPI通信の復旧をプラットフォームとサービスアプリケーションで連携して実施することにより、サービス処理を救済することができる。

以下、図面を参照しながら本発明の実施の形態を説明する。図１は本発明が適用された一実施形態に係るシステムを示すブロック図である。このシステムは、現用系の制御装置１０と予備系の制御装置２０とを同図のようにクラスタ切り替え部５０を介して切り替えて運用可能な通信システムであって、ネットワーク４０に接続されている。ネットワーク４０は例えばＩＰネットワークをベースにした電話ネットワークであり、例えばＩＰ電話機１，２…ｎが接続される。制御装置１０，２０は例えばキャリヤまたはサービスプロバイダ等に設置され、ＩＰ電話サービス、ＩＰセントレックスサービスおよびその他種々のサービスを提供する。あるいは制御装置１０，２０は例えば企業や自治体等の構内に設置され、ＰＢＸ(Private Branch Exchange)を提供する。なお、これら実施形態はあくまで一例であって他の通信システムに本発明を適用することができる。また、図１に示す本実施形態の構成についても当業者に自明な範囲で種々変形することができる。例えば、図１のような現用系と予備系を有するクラスタ構成を採らない制御装置に本発明を適用することもできる。

現用系の制御装置１０は、本実施形態ではＩＰ電話サービスに係る呼処理を担う装置であって、プラットフォーム呼処理機能部１００と、サービスアプリケーション呼処理機能部１１０とを有する。図１には示さないが、プラットフォーム呼処理機能部１００はオペレーティングシステム（ＯＳ）をベースにして実現される。このようなプラットフォーム呼処理機能部１００ならびにサービスアプリケーション呼処理機能部１１０はいずれもコンピュータプログラムの形態とすることができ、本発明についてもコンピュータプログラムとして実施することができる。

プラットフォーム呼処理機能部１００と、サービスアプリケーション呼処理機能部１１０とは、ソフトウェアバス１２０を介して通信可能に構成される。ここで、ソフトウェアバス１２０を介した通信とは、アプリケーションプロセスとプラットフォーム側プロセスとの間のオブジェクト間通信（あるいはＡＰＩ通信）のことである。プラットフォーム呼処理機能部１００は、図１に示すように呼制御／プロトコル部１０１と、OpenAPI１０２とを有する。本明細書に記載の「OpenAPI」とは「Open Application Program Interface」の略称であり、ソフトウェアバスを介して実現されるオブジェクト間通信の方式に沿うように規定される。ソフトウェアバスとしては、例えばCORBA(Common Object Request Broker Architecture)等の分散技術に基づくものが想定される。OpenAPI１０２では、このようなソフトウェアバス１２０を介してサービスアプリケーション呼処理機能部１１０とのオブジェクト間通信を行えるよう、該サービスアプリケーション呼処理機能部１１０に対するインタフェースを提供する。

図２はオブジェクトデータの一例を示す図である。プラットフォーム呼処理機能部１００では、呼の生起毎に生成されるオブジェクトと、呼毎に生成されたオブジェクトを管理するための少なくとも一つのオブジェクトとが存在する。本明細書では前者のオブジェクトをCallオブジェクトと称し、後者のオブジェクトをCallCntMngと称する。図２（ａ）はCallオブジェクトとCallCntMngオブジェクトとの間の関係を示している。すなわち図２（ａ）に示すように、生成された一つの呼に対応する一つのCallオブジェクトのデータ（１０２２オブジェクトデータ）は、呼識別子、呼情報、このCallオブジェクトにリモートからもアクセス可能とさせるCallオブジェクトの参照情報（１０２２オブジェクト参照情報）、およびサービスアプリケーション呼処理機能部１１０においてこのCallオブジェクトに対応するAppCallオブジェクトにアクセス可能とさせるためのAppCallオブジェクト参照情報（１１０２オブジェクト参照情報）を有する。一方、CallCntMngオブジェクトのデータ（１０２１）は、このCallCntMngオブジェクトの参照情報（１０２１オブジェクト参照情報）と、サービスアプリケーション呼処理機能部１１０においてこのCallCntMngオブジェクトに対応するAppCallCntMngオブジェクトの参照情報（１１０１オブジェクト参照情報）とを有する。また、全ての呼について、呼識別子、呼情報、およびCallオブジェクトを示すポインタ（１０２２オブジェクトのポインタ）を有する。

サービスアプリケーション呼処理機能部１１０においても同様に、呼毎に生成されるオブジェクトと、該オブジェクトを管理するためのオブジェクトとが存在する。本明細書では前者のオブジェクトをAppCallオブジェクトと称し、後者のオブジェクトをAppCallCntMngオブジェクトと称する。図２（ｂ）はAppCallオブジェクトとAppCallCntMngオブジェクトとの間の関係を示している。データ構造の詳細については、同図から分かるように、プラットフォーム呼処理機能部１００のものと対応している。

プラットフォーム呼処理機能部１００のオブジェクトとサービスアプリケーション呼処理機能部１１０のオブジェクトとが通信を行えるためには、これらのオブジェクトについての参照情報がソフトウェアバス１２０に登録されている必要がある。該ソフトウェアバス１２０に登録された各々のオブジェクトの参照情報は、ソフトウェアバス１２０を通じて取得することができ、サービスアプリケーション呼処理機能部１１０およびプラットフォーム呼処理機能部１００のOpenAPI１０２のそれぞれの内部で管理される。

図３はソフトウェアバスにおけるオブジェクト参照情報の管理テーブルの構成例を示す図である。ソフトウェアバス１２０は、該ソフトウェアバス１２０に登録されたオブジェクトとオブジェクトの参照情報とを図３に示すような管理テーブル１２０１で管理する。サービスアプリケーションのオブジェクト（例えばオブジェクト１１０２）がプラットフォームのオブジェクト（例えばオブジェクト１０２２）と通信する場合、ソフトウェアバス１２０において、図３の管理テーブル１２０１をオブジェクト参照情報（例えばオブジェクト参照情報２）で検査（ルックアップ）すると、プラットフォームで生成された複数のオブジェクトのうち該当するもの（この例ではオブジェクト２）が特定される。

逆に、プラットフォームからサービスアプリケーションに対して通信を開始する場合においても、同様にサービスアプリケーションで生成されたオブジェクトのオブジェクト参照情報から該当オブジェクトを特定し、そのオブジェクトにイベントを通知することができる。

現用系の制御装置１０は以上のように構成される。一方、予備系の制御装置２０は現用系の制御装置１０と対で設けられるのであり、図１からも分かるように現用系の制御装置１０と実質的に等価な構成を有する。このような予備系の制御装置２０は、現用系の制御装置１０に障害等が発生した際に、クラスタ切替の働きによって駆動され、代替で運用される。予備系の制御装置２０へのクラスタ切替が発生した場合、使用されるソフトウェアバスはソフトウェアバス２２０になるが、該ソフトウェアバス２２０が提供する機能は上記ソフトウェアバス１２０と同じである。なお、ネットワーク４０を介して接続されたソフトウェアバス１２０とソフトウェアバス２２０とでそれぞれ管理されるオブジェクト参照情報は、これらの間においてもオブジェクトを一意に特定できるようにユニークでなければならない。

図４は、本実施形態のシステムにおける基本動作手順の一例としてのコールバックの処理手順を示すシーケンス図である。コールバックの呼処理自体については公知であり、本発明が主眼とするものではないから概略的に説明する。この処理手順は、外部からの呼設定要求（イベント）に応じてコールバックを登録するステップＳ１と、コールバックのために本実施形態のシステムから外部に対して呼設定を要求するステップＳ２とを有する。これらステップＳ１、Ｓ２の後に実際の通信が開始される。この通信中に、本発明に係る情報保存処理ステップＳ３、Ｓ４および情報削除処理ステップＳ６、７が実行される。

まず上記ステップＳ１について説明する。外部において呼が発生すると、呼制御／プロトコル部１０１側に呼設定イベントが発生し、CallCntMngオブジェクトに該イベントが通知される。この呼設定イベント通知に応じてCallCntMngオブジェクトはCallオブジェクトを生成する。Callオブジェクトをソフトウェアバス１２０に登録することで、CallCntMngオブジェクトはCallオブジェクトのオブジェクト参照情報を取得する。次に、生成されたCallオブジェクトに対する呼識別子をCallCntMngオブジェクトの処理の中で払い出し、図２に示したようにCallオブジェクトと呼識別子とを関連付けることで呼毎にオブジェクトを管理する。ここで、「呼識別子を払い出す」とは、既に払い出された他の識別子と重複しない識別子を新規に生成し又は所定の選択候補のなかから選択することである。次にCallCntMngオブジェクトは、呼制御の対象であるCallオブジェクトのオブジェクト参照情報、呼識別子等のパラメータ設定した呼処理イベントをAppCallCntMngオブジェクトに通知する。AppCallCntMngオブジェクトはAppCallオブジェクトを生成し、Callと同様に該オブジェクトをソフトウェアバス１２０に登録し、必要なオブジェクト参照情報を取得する。また、コールバック登録により、Callオブジェクトは対応するAppCallオブジェクトの参照情報を取得して保持する。

呼に対応するオブジェクトが登録され、オブジェクト参照情報が適切に取得保持された後は、通信相手先のオブジェクトの参照情報をソフトウェアバス１２０に渡すことにより、該当するオブジェクトが特定され、すなわちCall，CallCntMng，AppCall，AppCallCntMng間でオブジェクト間通信が行われる。

本実施形態では、現用系プロセス復旧ならびにクラスタ切替に伴うプロセスの再起動が発生した場合であっても、サービスを中断することなく継続できるように、現用系の制御装置１０のプラットフォーム呼処理機能部１００およびサービスアプリケーション呼処理機能部１１０では、通信中の呼に関してステップＳ３およびステップＳ４を実行する。ステップＳ３では、サービスアプリケーション側のオブジェクトについて、復旧に必要な情報を記憶装置３０に保存する。ステップＳ４では、プラットフォーム側のオブジェクトについて、復旧に必要な情報を記憶装置３０に保存する。なお、呼が切断された場合（例えばステップＳ５の呼解放通知）は、ステップＳ６，Ｓ７において保存データを記憶装置３０から削除する。

図５は記憶装置３０に保存するデータの構造を示す図である。図５に示すように、保存データは、そのオブジェクトで管理する呼情報やソフトウェアバス１２０を介してＡＰＩ通信を行うためのオブジェクトと対応づけられる１０２１，１１０１オブジェクトのオブジェクト参照情報、１０２１、１１０１オブジェクトがそれぞれ保持している呼識別子をキーとしたオブジェクト間の連携情報、ならびに、１０２２，１１０２オブジェクトに保持している呼識別子、呼情報、１０２２，１１０２オブジェクトのオブジェクト参照情報である。

上述したように、ソフトウェアバス１２０は、呼処理イベント通知したオブジェクトと該オブジェクトの参照情報との関係を図３に示すようなテーブルで管理している。サービスアプリケーション呼処理機能部１１０がプラットフォーム呼処理機能部１００のOpenAPI１０２のオブジェクトと通信する場合、ソフトウェアバス１２０は、プラットフォーム呼処理機能部１００で生成されたオブジェクトのオブジェクト参照情報から図３の管理テーブル１２０１からオブジェクトを特定する。また、プラットフォーム呼処理機能部１００のOpenAPI１０２側からサービスアプリケーション呼処理機能部１１０との通信が開始される場合においても、アプリケーションと同様にサービスアプリケーション呼処理機能部１１０で生成されたオブジェクトのオブジェクト参照情報から該当オブジェクトを特定し、そのオブジェクトにイベントを通知する。

以下、図６〜図８を参照し、プラットフォーム呼処理機能部がプロセス再起動する場合、サービスアプリケーション呼処理機能部がプロセス再起動する場合、および現用系と予備系との間でクラスタ切替する場合のそれぞれについて、本実施形態の処理手順を説明する。

図６は、現用系の制御装置１０においてプラットフォーム呼処理機能部１００のプロセスが再起動した際の処理手順を示す図である。図４の呼処理シーケンス例で説明したように、通信中に遷移した呼に関する１０２１，１０２２オブジェクトが図５に示したデータ構造に従って記憶装置３０に保存される（ステップＳ１０１；プラットフォーム管理対象呼情報・オブジェクト情報保存）。１１０１，１１０２オブジェクトについても同様に保存される（ステップＳ１０２；サービスアプリケーション管理対象呼情報・オブジェクト情報保存）。

ここで、プラットフォーム呼処理機能部１００がプロセスを再起動する場合（ステップＳ１０３）、通信中に遷移した呼に関連する１０２１，１０２２オブジェクトの保存データを記憶装置３０から読み出す（ステップＳ１０４；プラットフォーム管理対象呼情報・オブジェクト情報取得）。これにより得られた情報を元に、プラットフォーム呼処理機能部１００のOpenAPI１０２で管理する１０２１，１０２２オブジェクトを再生成し復旧する（ステップＳ１０５）。その後、復旧したオブジェクトを図３に示したソフトウェアバス１２０の管理テーブル１２０１に再登録し（ステップＳ１０６；プラットフォーム管理対象オブジェクト登録）、サービスアプリケーション呼処理機能部１１０とのＡＰＩ通信を復旧する（ステップＳ１０７）。

以上の処理手順によれば、プラットフォーム呼処理機能部１００がプロセスを再起動する場合であっても、プラットフォーム呼処理機能部１００内のオブジェクトが記憶装置３０の保存データに基づいて再生され、ソフトウェアバス１２０に再登録されることから、ソフトウェアバス１２０を介したオブジェクト間通信（ＡＰＩ通信）を復旧でき、サービスが中断されることがない。したがって、システムの堅牢性、可用性を向上できる。

図７は、現用系の制御装置１０においてサービスアプリケーション呼処理機能部１１０のプロセスが再起動した際の処理手順を示す図である。図４の呼処理シーケンス例で説明したように、通信中に遷移した呼に関する１０２１，１０２２オブジェクトが図５に示したデータ構造に従って記憶装置３０に保存される（ステップＳ２０１；プラットフォーム管理対象呼情報・オブジェクト情報保存）。１１０１，１１０２オブジェクトについても同様に保存される（ステップＳ２０２；サービスアプリケーション管理対象呼情報・オブジェクト情報保存）。

ここで、サービスアプリケーション呼処理機能部１１０がプロセスを再起動する場合（ステップＳ２０３）、１１０１，１１０２オブジェクトの保存データを記憶装置３０から読み出す（ステップＳ２０４；サービスアプリケーション管理対象呼情報・オブジェクト情報取得）。これにより得られた情報を元に、サービスアプリケーション呼処理機能部１１０で管理する１１０１，１０２２オブジェクトを再生成し復旧する（ステップＳ２０５）。その後、復旧したオブジェクトを図３に示したソフトウェアバス１２０の管理テーブル１２０１に再登録し（ステップＳ２０６；サービスアプリケーション管理対象オブジェクト登録）、プラットフォーム呼処理機能部１００とのＡＰＩ通信を復旧する（ステップＳ２０７）。

以上の処理手順によれば、サービスアプリケーション呼処理機能部１１０がプロセスを再起動する場合であっても、サービスアプリケーション呼処理機能部１１０内のオブジェクトが記憶装置３０の保存データに基づいて再生され、ソフトウェアバス１２０に再登録されることから、ソフトウェアバス１２０を介したオブジェクト間通信（ＡＰＩ通信）を復旧でき、サービスが中断されることがない。したがって、システムの堅牢性、可用性を向上できる。

図８は、現用系の制御装置１０から予備系の制御装置２０へクラスタ切替が発生した際の処理手順を示す図である。現用系の制御装置１０において、図２の呼処理シーケンス例のように通信中に遷移した呼に関する１０２１，１０２２オブジェクトが図５に示したデータ構造に従って記憶装置３０に保存される（ステップＳ３０１；プラットフォーム管理対象呼情報・オブジェクト情報保存）。１１０１，１１０２オブジェクトについても同様に保存される（ステップＳ３０２；サービスアプリケーション管理対象呼情報・オブジェクト情報保存）。

ここで、現用系の制御装置１０から予備系の制御装置２０へクラスタ切替が発生した場合（ステップＳ３０３）、予備系の制御装置２０のプラットフォーム呼処理機能部２００とサービスアプリケーション呼処理機能部２１０では、まず１０２１，１０２２オブジェクトの保存データを記憶装置３０から読み出す（ステップＳ３０４；プラットフォーム管理対象呼情報・オブジェクト情報取得）。次に、１１０１，１１０２オブジェクトの保存データを取得し、記憶装置３０から読み出す（ステップＳ３０５；サービスアプリケーション管理対象呼情報・オブジェクト情報取得）。

これにより得られた情報を元に、予備系制御装置２０のプラットフォーム呼処理機能部２００のOpenAPI２０２とサービスアプリケーション呼処理機能部２１０が管理する１０２１，１０２２，１１０１，１１０２オブジェクトをそれぞれ再生成する（ステップＳ３０６）。その後、復旧した１０２１，１０２２，１１０１，１１０２オブジェクトに対応するオブジェクト参照情報を新規にソフトウェアバス２２０から取得するため、これらオブジェクトを図３に示したものと同様のソフトウェアバス２２０のオブジェクトとオブジェクト参照情報との対応テーブルに再登録する（ステップＳ３０７；プラットフォーム管理対象オブジェクト登録およびオブジェクト参照情報取得，ステップＳ３０８；サービスアプリケーション管理対象オブジェクト登録およびオブジェクト参照情報取得）。

次に、ステップＳ３０９において、プラットフォーム呼処理機能部２００のOpenAPI２０２で管理している１０２１，１０２２オブジェクトの参照情報とサービスアプリケーション呼処理機能部２１０で管理している１１０１，１１０２オブジェクトの参照情報とを互いに交換したのち、ステップＳ３１０においてＡＰＩ通信を復旧する。

以上の処理手順によれば、現用系の制御装置１０と予備系の制御装置２０との間でクラスタ切替が発生した場合であっても、これら現用系の制御装置１０と予備系の制御装置２０との間で必要なオブジェクトが記憶装置３０の保存データに基づいて再生され、該当するソフトウェアバス１２０（あるいは２２０）に再登録されることから、ソフトウェアバス１２０（あるいは２２０）を介したオブジェクト間通信（ＡＰＩ通信）を復旧でき、サービスが中断されることがない。したがって、システムの堅牢性、可用性を向上できる。

なお、以上の実施形態は、サービスアプリケーションとプラットフォームとが同一制御装置上で動作するクラスタ構成をとる形態として説明したが、シングル構成の形態や、サービスアプリケーションとプラットフォームとが制御装置として分離する形態においても、自明な変形を行って本発明を適用可能であることは言うまでもない。また、通信中の呼を処理する場合について説明したが、他の状態の呼処理や、呼処理以外の処理を有するオブジェクトに対しても同様に本発明に従って処理できることは勿論である。

また、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

本発明が適用された一実施形態に係るシステムを示すブロック図 オブジェクトデータの一例を示す図 ソフトウェアバスにおけるオブジェクト参照情報の管理テーブルの構成例を示す図 実施形態のシステムにおける基本動作手順の一例としてのコールバックの処理手順を示すシーケンス図 記憶装置に保存するデータの構造を示す図 現用系の制御装置においてプラットフォーム呼処理機能部のプロセスが再起動した際の処理手順を示す図 現用系の制御装置においてサービスアプリケーション呼処理機能部のプロセスが再起動した際の処理手順を示す図 現用系の制御装置から予備系の制御装置へクラスタ切替が発生した際の処理手順を示す図

符号の説明

１〜ｎ…ＩＰ電話機、１０…現用系の制御装置、２０…予備系の制御装置、３０…記憶装置、４０…ＩＰネットワーク、５０…クラスタ切替部

Claims (9)

1. アプリケーションプログラムインタフェースを有するプラットフォームがイベント毎に生成した第１のオブジェクトと、前記イベント毎にアプリケーションが生成した第２のオブジェクトとがソフトウェアバスを介して通信することにより前記イベントを処理するシステムにおけるオブジェクトの管理方法において、
   前記ソフトウェアバスを介して前記第１、第２のオブジェクトが互いを参照するために必要な第１、第２のオブジェクト参照情報を含む保存情報を記憶手段に記憶する記憶ステップと、
   前記第１、第２のオブジェクトの少なくともいずれかの消滅に応じ、前記イベントの処理を継続するために必要なオブジェクトを再生する再生ステップと、
   前記ソフトウェアバスを介した通信を前記記憶手段の保存情報を用いて復旧する復旧ステップとを具備するオブジェクトの管理方法。
2. 前記ソフトウェアバスは、前記第１、第２のオブジェクトと前記第１、第２のオブジェクト参照情報とを対応付けて記憶するテーブルを有し、
   前記復旧ステップは、前記再生したオブジェクトのオブジェクト参照情報を前記テーブルに再登録するステップを具備する請求項１に記載のオブジェクトの管理方法。
3. 第１のクラスタを第２のクラスタに切り替える切替ステップと、
   前記第１のクラスタに存在する前記第１、第２のオブジェクトを前記第２のクラスタにおいて再生するステップと、
   前記第１のクラスタにおけるソフトウェアバスを介した通信を、前記記憶手段の保存情報を用いて前記第２のクラスタにおいて復旧するステップとを具備する請求項１または２に記載のオブジェクトの管理方法。
4. アプリケーションプログラムインタフェースを有し、イベント毎に第１のオブジェクトを生成するプラットフォームと、
   前記イベント毎に第２のオブジェクトを生成するアプリケーションと、
   前記プラットフォームにおいて生成された第１のオブジェクトと前記アプリケーションにおいて生成された第２のオブジェクトとが通信するためのソフトウェアバスと、
   前記ソフトウェアバスを介して前記第１、第２のオブジェクトが互いを参照するために必要な第１、第２のオブジェクト参照情報を含む保存情報を記憶する記憶手段と、
   前記第１、第２のオブジェクトの少なくともいずれかの消滅に応じ、イベントの処理を継続するために必要なオブジェクトを再生する再生手段と、
   前記ソフトウェアバスを介した通信を前記記憶手段の保存情報を用いて復旧する復旧手段とを具備するシステム。
5. 前記ソフトウェアバスは、前記第１、第２のオブジェクトと前記第１、第２のオブジェクト参照情報とを対応付けて記憶するテーブルを有し、
   前記復旧手段は、前記再生したオブジェクトのオブジェクト参照情報を前記テーブルに再登録する手段を具備する請求項４に記載のシステム。
6. 第１のクラスタを第２のクラスタに切り替える切替手段と、
   前記第１のクラスタに存在する前記第１、第２のオブジェクトを前記第２のクラスタにおいて再生する手段と、
   前記第１のクラスタにおけるソフトウェアバスを介した通信を、前記記憶手段の保存情報を用いて前記第２のクラスタにおいて復旧する手段とを具備する請求項５または６に記載のシステム。
7. アプリケーションプログラムインタフェースを有するプラットフォームがイベント毎に生成した第１のオブジェクトと、前記イベント毎にアプリケーションが生成した第２のオブジェクトとがソフトウェアバスを介して通信することにより前記イベントを処理するシステムにおいてオブジェクトを管理するプログラムであって、
   前記ソフトウェアバスを介して前記第１、第２のオブジェクトが互いを参照するために必要な第１、第２のオブジェクト参照情報を含む保存情報を記憶手段に記憶する記憶手順と、
   前記第１、第２のオブジェクトの少なくともいずれかの消滅に応じ、前記イベントの処理を継続するために必要なオブジェクトを再生する再生ステップと、
   前記ソフトウェアバスを介した通信を前記記憶手段の保存情報を用いて復旧する復旧手順とをコンピュータに実行させるためのプログラム。
8. 前記ソフトウェアバスは、前記第１、第２のオブジェクトと前記第１、第２のオブジェクト参照情報とを対応付けて記憶するテーブルを有し、
   前記復旧手順は、前記再生したオブジェクトのオブジェクト参照情報を前記テーブルに再登録する手順を具備する請求項７に記載のプログラム。
9. 第１のクラスタを第２のクラスタに切り替える切替手順と、
   前記第１のクラスタに存在する前記第１、第２のオブジェクトを前記第２のクラスタにおいて再生する手順と、
   前記第１のクラスタにおけるソフトウェアバスを介した通信を、前記記憶手段の保存情報を用いて前記第２のクラスタにおいて復旧する手順とを具備する請求項７または８に記載のプログラム。

Images