JP6533502B2 - 通信サービス提供システムおよび通信サービス提供方法 - Google Patents

Description

本発明は、通信サービスの提供に関し、例えば、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を用いた通信サービスを提供する通信サービス提供システムおよび通信サービス提供方法に関する。

従来、ＳＩＰを用いた通信サービスを作成するためのプラットフォームとして、ＪＳＬＥＥやＳＩＰ Ｓｅｒｖｌｅｔが提供されている（例えば、非特許文献１および非特許文献２参照）。
商用サービスを提供するＳＩＰサーバでは、既存サービスに影響を与えずサービスを追加するファイル更新機能が提供されている。商用サービスを提供するＳＩＰサーバは、高信頼性を提供するためにアクト・スタンバイの二重化構成を取ることが一般的である。二重化構成のＳＩＰサーバのファイル更新機能では、アクト系で既存サービスを提供中にスタンバイ系に新サービスをデプロイし、スタンバイ系をアクト系に切り替えることで、既存サービスを中断することなく新サービスを提供する。

JSR 240: JAINTM SLEE (JSLEE) v1.1，［online］，平成28年8月19日検索，インターネット〈ＵＲＬ：https://jcp.org/aboutJava/communityprocess/final/jsr240/index.html〉 JSR 359: SIP Servlet 2.0，［online］，平成28年8月19日検索，インターネット〈ＵＲＬ：https://jcp.org/aboutJava/communityprocess/final/jsr359/index.html〉

従来技術に基づいたＳＩＰサーバでは、新しいサービスを追加する際には、当該クラスのオブジェクトだけを変更するのではなく、アプリケーション全体を起動し直す必要がある。このため、上述のようなファイル更新機能を用いたファイル更新が必要となるが、通常、ファイル更新はサービスに対する影響の少ない深夜に実行されるため、頻繁に行うことが困難であり、サービスの追加を実行する時間帯が限られる。

また、従来技術に基づいたＳＩＰサーバは、オブジェクト指向に基づいているため、新サービス提供のためにデータ構造の変更が必要になった場合には、既存サービスのデータ構造から新サービスのデータ構造に変換する処理を新サービスのメソッドに追加する必要がある。新サービスが問題なく提供された場合には問題は起きないが、新サービスで問題が発生し既存サービスに切り戻す場合には、新サービスのデータ構造に変更したデータを既存サービスのデータ構造に変換する必要がある。しかしながら、既存サービスのメソッドにはこの処理は定義されていないため、新サービスから既存サービスにデータの引き継いだ復旧を行うことができない。

本発明は、このような事情に鑑みてなされたものであり、通信サービス提供下において新規サービスの追加に伴う作業負担を軽減することを目的とする。

上述の目的を達成するため、請求項１に記載の発明は、ユーザ端末に対して所定の通信プロトコルを使用する通信サービスを提供する通信サービス提供システムであって、前記通信サービスの提供に必要なサービス提供用関数群を保持するとともに、指定されたサービス提供用関数を実行する関数処理部と、前記ユーザ端末から入力メッセージを受信し、前記入力メッセージから今回の通信を識別する識別情報を抽出し、今回の通信のプロトコル状態を照会するメッセージ受信部と、前記入力メッセージの種類を判定し、前記入力メッセージの種類に応じて前記サービス提供用関数群から前記関数処理部に実行させる前記サービス提供用関数を選択する関数選択部と、前記入力メッセージに含まれる前記サービス提供用関数の実行に必要な情報および前記プロトコル状態を変数として前記関数処理部に前記サービス提供用関数を実行させ、返答先ユーザ端末に送信する出力メッセージおよび前記プロトコル状態の遷移先を関数値として得る関数呼び出し部と、前記返答先ユーザ端末に前記出力メッセージを送信する状態遷移部と、を備えることを特徴とする通信サービス提供システムとした。

また、請求項４に記載の発明は、ユーザ端末に対して所定の通信プロトコルを使用する通信サービスを提供する通信サービス提供システムにおける通信サービス提供方法であって、前記ユーザ端末から入力メッセージを受信し、前記入力メッセージから今回の通信を識別する識別情報を抽出し、今回の通信のプロトコル状態を照会するメッセージ受信ステップと、前記入力メッセージの種類を判定し、前記入力メッセージの種類に応じて前記通信サービスの提供に必要なサービス提供用関数群から、関数呼び出しステップで実行するサービス提供用関数を選択する関数選択ステップと、前記入力メッセージに含まれる前記サービス提供用関数の実行に必要な情報および前記プロトコル状態を変数として前記サービス提供用関数を実行し、返答先ユーザ端末に送信する出力メッセージおよび前記今回の通信の状態の遷移先を関数値として得る関数呼び出しステップと、前記返答先ユーザ端末に前記出力メッセージを送信する状態遷移ステップと、を含むことを特徴とする通信サービス提供方法とした。

このように通信サービスにおける各処理をサービス提供用関数として定義することにより、オブジェクト指向に基づくシステムと比較して、新規サービスの追加やサービス内容の変更を容易に行うことができる。
より詳細には、Ｃ＋＋やＪａｖａ（登録商標）で作成されたシステムでは、実施中のサービスを継続しながら新規サービスの追加やサービス内容の変更を行うためには、特別なファイル更新機能をアプリケーションに作りこむ必要がある。
これに対して、関数は実行に必要な情報は引数として受け取るので、関数実行環境にデータを保持する必要がなく、関数実行毎に新しい関数実行環境を起動することが可能となる。新しい関数実行環境を起動する時点で最新の関数定義を参照するため、特別なファイル更新機能は不要であり、サービスの追加等を実行するタイミングを任意に設定することができる。

また、請求項２に記載の発明は、前記通信サービスの提供に用いられるデータベースを保持するデータ管理部を更に備え、前記関数処理部が実行する前記サービス提供用関数は、所定のアプリケーションにおける所定の処理を実行するものであり、前記データ管理部に記録されたデータベースには、当該データベースのデータ構造のバージョンが記録されており、前記所定のデータベースのデータ構造を変更する際は、変更後のデータ構造を前記アプリケーションのバージョンに合わせて変更する新規のデータ構造変更関数を定義し、前記関数処理部が実行する前記サービス提供用関数が前記データ管理部内の所定のデータベースにアクセスする際はラッパー関数を経由してアクセスし、前記ラッパー関数は、前記アプリケーションのバージョンが前記所定のデータベースの前記データ構造のバージョンと異なる場合には、前記データ構造を前記アプリケーションのバージョンに合わせて変更するデータ構造変更関数を呼び出す、ことを特徴とする通信サービス提供システムとした。

また、請求項５に記載の発明は、前記通信サービス提供システムは、前記通信サービスの提供に用いられるデータベースを保持するデータ管理部を備え、前記関数呼び出しステップで実行される前記サービス提供用関数は、所定のアプリケーションにおける所定の処理を実行するものであり、前記データ管理部に記録されたデータベースには、当該データベースのデータ構造のバージョンが記録されており、前記所定のデータベースのデータ構造を変更する際は、変更後のデータ構造を前記アプリケーションのバージョンに合わせて変更する新規のデータ構造変更関数を定義し、前記関数呼び出しステップでは、実行する前記サービス提供用関数が前記データ管理部内の所定のデータベースにアクセスする際はラッパー関数を経由してアクセスし、前記アプリケーションのバージョンが前記所定のデータベースの前記データ構造のバージョンと異なる場合には、前記ラッパー関数が前記データ構造を前記アプリケーションのバージョンに合わせて変更するデータ構造変更関数を呼び出す、ことを特徴とする通信サービス提供方法とした。

このようにすることで、データ構造のバージョンとアプリケーションのバージョンとが一致するか否かを意識することなくデータベースが利用可能となり、データとロジックとを分離して取り扱う上での利便性を向上させることができる。また、実行中のアプリケーションのバージョンの方がデータ構造のバージョンより古い場合にもロールバックが可能となり、例えば新規サービスに不具合が生じた場合などにも容易に対応することができる。

また、請求項３に記載の発明は、前記通信サービスを用いた個々の通信の前記通信プロトコル上の状態を示すプロトコル状態を、当該通信の識別情報と対応付けて記録するプロトコル状態データベースと、前記個々の通信に対応する前記通信サービスのサービス状態を、当該通信の識別情報と対応付けて記録するサービス状態データベースとを更に備え、前記メッセージ受信部は、前記プロトコル状態データベースに前記プロトコル状態を照会し、前記関数処理部は、前記サービス状態を変更する前記サービス提供用関数が実行された場合、前記サービス状態データベースに記録された前記今回の通信に対応するサービス状態を、変更後のサービス状態に更新し、前記状態遷移部は、前記プロトコル状態データベースに記録された前記プロトコル状態を前記遷移先の状態に更新する、ことを特徴とする通信サービス提供システムとした。

また、請求項６に記載の発明は、前記通信サービス提供システムは、前記通信サービスを用いた個々の通信の前記通信プロトコル上の状態を示すプロトコル状態を、当該通信の識別情報と対応付けて記録するプロトコル状態データベースと、前記個々の通信に対応する前記通信サービスのサービス状態を、当該通信の識別情報と対応付けて記録するサービス状態データベースとを更に備え、前記メッセージ受信ステップでは、前記プロトコル状態データベースに前記プロトコル状態を照会し、前記関数呼び出しステップでは、前記サービス状態を変更する前記サービス提供用関数が実行された場合、前記サービス状態データベースに記録された前記今回の通信に対応するサービス状態を、変更後のサービス状態に更新し、前記状態遷移ステップでは、前記プロトコル状態データベースに記録された前記プロトコル状態を前記遷移先の状態に更新する、ことを特徴とする通信サービス提供方法とした。

このように、通信サービスのサービス状態やプロトコル状態を記録しておくことにより、障害発生時にサービス状態やプロトコル状態を復旧することができる。

本発明によれば、通信サービス提供下において新規サービスの追加に伴う作業負担を軽減することができる。

実施の形態にかかる通信サービス提供システムを含むネットワーク構成例を示すブロック図である。 プロトコル処理部、関数処理部およびデータ管理部の詳細構成を示すブロック図である。 データ管理部で保持するデータベースの一例を示す説明図である。 関数処理部で実行する関数の一例を示す説明図である。 関数処理部で実行する関数の一例を示す説明図である。 商用環境と試用環境との分離について説明する説明図である。

以下、本発明を実施するための形態（以下、実施の形態とする）について説明する。
図１は、実施の形態にかかる通信サービス提供システム２０を含むネットワーク構成例を示すブロック図である。また、図２は、プロトコル処理部２１０、関数処理部２２０およびデータ管理部２３０の詳細構成を示すブロック図である。
通信サービス提供システム２０は、ユーザ端末（図１では発端末１０および着端末３０）に対して所定の通信プロトコル（本実施の形態ではＳＩＰ）を使用する通信サービスを提供する。通信サービス提供システム２０の特徴は、ロジックとデータを分離し、ロジックはサービス提供用関数として関数処理部２２０，２２１，２２２で保持し、データはデータ管理部２３０，２３１，２３２で保持している点にある。また、関数だけではＳＩＰの状態遷移を扱うことはできないため、プロトコル処理部２１０，２１１，２１２で状態遷移を行う。

通信サービス提供システム２０は、振り分け処理部２００、プロトコル処理部２１０，２１１，２１２、関数処理部２２０，２２１，２２２およびデータ管理部２３０，２３１，２３２として機能する複数のサーバによって構成されている。各機能部は、１台のサーバによって構成されていてもよいし、仮想マシンやＬｉｎｕｘ（登録商標）コンテナ等の仮想化技術を使って、物理的な１台のサーバ上に複数の仮想サーバ（機能部）を配置してもよい。また、図１では、プロトコル処理部、関数処理部およびデータ管理部が各３つずつ設けられているが、それぞれの構成部の個数は任意である。
また、図１では図示の便宜上、プロトコル処理部２１０，２１１，２１２、関数処理部２２０，２２１，２２２、データ管理部２３０，２３１，２３２間の接続関係を省略しているが、これらの構成部は互いに接続が可能である。

振り分け処理部２００は、ユーザ端末（例えば発端末１０）から送信されたメッセージを、複数台のプロトコル処理部２１０〜２１２に振り分ける。
なお、プロトコル処理部２１０〜２１２は長期保管が必要なデータを有していないため、入力メッセージの内容とプロトコル処理部２１０〜２１２との対応付けを行う必要はない。よって、入力メッセージの振り分けは、例えば単純なラウンドロビンやプロトコル処理部２１０〜２１２の負荷を考慮したラウンドロビン等の比較的単純なアルゴリズムで行うことが可能である。なお、通信サービス提供システム２０内のプロトコル処理部が１台の場合には、振り分け処理部２００は不要である。

プロトコル処理部２１０〜２１２は、入力メッセージの種類に応じて後述する関数処理部２２０〜２２２のサービス提供用関数を呼び出し、出力メッセージの送信と状態遷移を行う。
関数処理部２２０〜２２２は、通信サービスの提供に用いられるサービス提供用関数群を保持するとともに、指定されたサービス提供用関数を実行する。
データ管理部２３０〜２３２は、後述するプロトコル状態データベース２３０１およびサービス状態データベース２３０３（図３参照）を含む通信サービスの提供に用いられるデータベースを保持する。

図２にプロトコル処理部２１０〜２１２、関数処理部２２０〜２２２、データ管理部２３０〜２３２の詳細構成を示す。なお、プロトコル処理部２１０〜２１２の構成は全て同じであるため、図２にはプロトコル処理部２１０のみを図示する。関数処理部２２０〜２２２、データ管理部２３０〜２３２についても同様に、関数処理部２２０、データ管理部２３０のみを図示する。

プロトコル処理部２１０は、メッセージ受信部２１０１、関数選択部２１０２、関数呼び出し部２１０３および状態遷移部２１０４を備える。
メッセージ受信部２１０１は、ユーザ端末からの入力メッセージの受信を待機し、入力メッセージを受信するとメッセージ電文を内部形式に復号し、当該入力メッセージに対応するプロトコル状態をプロトコル状態データベース２３０１から取得する。
ここで、プロトコル状態データベース２３０１は、後述するデータ管理部２３０に記憶されており、通信サービス提供システム２０上の（通信サービスを用いた）個々の通信の通信プロトコル上の状態（ステート）を示すプロトコル状態を、当該通信の識別情報と対応付けて保持している。

図３（ａ）にプロトコル状態データベース２３０１の一例を示す。プロトコル状態データベース２３０１は、個々の通信の識別情報であるＳＩＰのＣａｌｌ−ＩＤと、当該Ｃａｌｌ−ＩＤで識別される通信のプロトコル状態（例えば「通信中（ＥＳＴＡＢＬＩＳＨＥＤ）」など）が対応付けて記録されている。
メッセージ受信部２１０１は、入力メッセージのヘッダ部から識別情報（Ｃａｌｌ−ＩＤ）を抽出し、当該識別情報に対応付けられているプロトコル状態をプロトコル状態データベース２３０１に照会する。

関数選択部２１０２は、入力メッセージの種類を判定し、入力メッセージの種類に応じて関数群から関数処理部２２０に実行させるサービス提供用関数を選択する。関数選択部２１０２は、入力メッセージのヘッダ部から当該入力メッセージの種類（例えばＩＮＶＩＴＥ、ＲＥＧＩＳＴＥＲなど）を抽出し、データ管理部２３０に記憶されているメッセージ−関数対応データベース２３０２を参照して、当該種類に対応付けられているサービス提供用関数を特定する。

図３（ｂ）にメッセージ−関数対応データベース２３０２の一例を示す。メッセージ−関数対応データベース２３０２は、例えばＩＮＶＩＴＥ、ＲＥＧＩＳＴＥＲなどの入力メッセージの種類と、実行するサービス提供用関数名とが対応付けて記録されている。

関数呼び出し部２１０３は、入力メッセージに含まれるサービス提供用関数の実行に必要な情報およびメッセージ受信部２１０１で取得したプロトコル状態を変数として関数処理部２２０にサービス提供用関数を実行させ（関数を呼び出し）、返答先ユーザ端末に送信する出力メッセージおよびプロトコル状態の遷移先を関数値として得る。
なお、プロトコル処理部２１０〜２１２と同様に、関数処理部２２０〜２２２は長期保管が必要なデータを有していないため、単純なラウンドロビンや関数処理部２２０〜２２２の負荷を考慮したラウンドロビン等の比較的単純なアルゴリズムで呼び出し先の関数処理部２２０〜２２２を決定可能である。

状態遷移部２１０４は、返答先ユーザ端末に出力メッセージを送信するとともに、プロトコル状態データベースに記録されたプロトコル状態を遷移先の状態に更新する。すなわち、状態遷移部２１０４は、関数値として受け取った出力メッセージを送信先の端末送信することによりプロトコル状態を遷移先の状態に遷移させ、プロトコル状態データベース２３０１の今回の通信のＣａｌｌ−ＩＤに対応するプロトコル状態を遷移先の状態へと更新する。

つぎに、関数処理部２２０について説明する。
上述のように、関数処理部２２０は、通信サービスの提供に必要なサービス提供用関数群を保持するとともに、プロトコル処理部２１０で指定されたサービス提供用関数を実行する。関数処理部２２０内のサービス提供用関数は、全体として通信サービスの提供に必要な所定のアプリケーションを構成している。すなわち、アプリケーションにおける種々の処理を個々のサービス提供用関数として定義している。また、関数処理部２２０は、後述するラッパー関数およびデータ構造変換関数を有している。ラッパー関数およびデータ構造変換関数の詳細については後述する。
図２では、関数処理部２２０に関数Ａ２２０１、関数Ｂ２２０２、関数Ｃ２２０３が保持されているものとする。
関数処理部２２０には長期保管が必要なデータが含まれないため、アプリケーションの各処理はクラスのメソッドではなく関数として実装が可能となる。よって、新規サービスを提供する際は、新規サービス提供に必要な関数のみの更新が可能となる。
例えば、通信サービスに新たな機能を追加したい場合、新たな機能に対応するサービス提供用関数を通信サービス提供システム２０内の全ての関数処理部２２０〜２２２に実装させ（図面で言えば、図２の関数処理部２２０内に新たに「関数Ｄ」を加え）、全てのデータ管理部２３０〜２３２のメッセージ−関数対応データベース２３０２を書き換えればよい。

より具体的に、通信サービスに転送サービスを機能追加する場合について説明する。
機能追加前は、ＩＮＶＩＴＥメッセージに対して図４に示す基本呼ＩＮＶＩＴＥ関数が対応付けられている。一方、機能追加時には、各関数処理部２２０〜２２２に図５に示す付加サービスＩＮＶＩＴＥ関数を実装するとともに、ＩＮＶＩＴＥメッセージに対応付ける関数を付加サービスＩＮＶＩＴＥ関数に変更する。すなわち、メッセージ−関数対応データベース２３０２において、ＩＮＶＩＴＥメッセージに対応する関数を「基本呼ＩＮＶＩＴＥ関数」から「付加サービスＩＮＶＩＴＥ関数」に書き換える。
図５に示す付加サービスＩＮＶＩＴＥ関数は、加入者情報サーバ内の加入者情報データベース５０（図１、図２参照）が保持する加入者データを参照し、転送サービスに加入している場合には、Ｔｏを転送先に変更して基本呼ＩＮＶＩＴＥ関数を呼び出し、加入していない場合にはそのまま基本呼ＩＮＶＩＴＥ関数を呼び出すものである。付加サービスＩＮＶＩＴＥ関数は、加入者の契約情報に基づいた状態遷移を行うため、その実行時には図２の関数Ｂ２２０２のように加入者情報データベース５０にアクセスする。

上記課題で述べたように、既存のＳＩＰサーバでは、変更されたクラスだけを更新することができず、アプリケーション全体を更新する必要がある。これに対して、通信サービス提供システム２０では、変更が必要な個所を関数として定義し、関数単位で追加を可能としている。よって、サービス追加に必要な関数のみの更新で新サービスの追加が可能となり、サービス追加を容易に行うことができる。
なお、更新単位を関数にするためには、オブジェクト指向を適用することはできない。関数だけでは状態遷移を扱うことはできないため、通信プロトコル（ＳＩＰ）の処理(処理状態遷移)はプラットフォーム（プロトコル処理部２１０）で行っている。

図２の説明に戻り、データ管理部２３０は、通信サービスの提供に用いられるデータベースを保持する。
上述したプロトコル処理部２１０および関数処理部２２０は、データを保持していないため、複数のサーバのいずれを選択してもよいが、データ管理部２３０〜２３２については、必要なデータを保持しているサーバを選択する必要がある（例えばある端末間のセッションのプロトコル状態を保持しているデータ管理部（サーバ）を選択する必要がある）。データベースのライブラリを用いることにより、プロトコル処理部２１０〜２１２や関数処理部２２０〜２２２は、データ管理部２３０〜２３２の構成を意識することなく必要なデータにアクセス可能となる。
なお、データベースは、それぞれのデータ管理部２３０〜２３２が保持するデータを同期する機能を有している。データベースによって同期する機能の詳細は異なるが、例えばＮｏＳＱＬデータベースは一般的にデータの紛失を防ぐためデータを３重化（３台のサーバに同じデータを保存）している。ＮｏＳＱＬデータベースによっては、設定ファイル等で多重度の変更やデータ格納要求に対する応答のタイミングの変更（１台のサーバへの格納が完了した時点で応答か、３台全てのサーバへの格納が完了した時点で応答か、など）が可能である。
データ管理部２３０としては、例えばＮｏＳＱＬデータベースを用いることができる。

データ管理部２３０の保持するデータベースとして、上述したプロトコル状態データベース２３０１およびメッセージ−関数対応データベース２３０２が挙げられる。
また、データ管理部２３０は、個々の通信に対応する通信サービスのサービス状態を、当該通信の識別情報と対応付けて記録するサービス状態データベース２３０３を更に備える。サービス状態データベース２３０３に記録されたサービス状態は、障害時の復旧に必要となる。図３（ｃ）にサービス状態データベース２３０３の一例を示す。

サービス状態データベース２３０３は、個々の通信の識別情報であるＳＩＰのＣａｌｌ−ＩＤと、当該Ｃａｌｌ−ＩＤで識別される通信のサービス状態が対応付けて記録されている。例えば通信サービスがキャッチホンサービスである場合、通話中に新しい着信があった場合に、元々の通話先電話番号（図３（ｃ）における「番号１」）、新しい着信の電話番号（図３（ｃ）における「番号２」）、およびどちらの電話番号と通話中であるか（図３（ｃ）における「相手先」）、の３種類のデータをサービス状態として保存する。
サービス状態データベース２３０３の更新は、関数処理部２２０〜２２２によって行われる。すなわち、関数処理部２２０においてサービス状態を変更する関数（例えば図２の関数Ｃ２２０３）を実行した場合、サービス状態データベース２３０３に記録された今回の通信に対応するサービス状態を、変更後のサービス状態に更新する。

また、データ管理部２３０に記録されたデータベースには、当該データベースのデータ構造のバージョンが記録されている。関数処理部２２０が実行するサービス提供用関数が所定のデータベースにアクセスする際はラッパー関数を経由してアクセスする。ラッパー関数は、データベースアクセスの詳細を隠蔽するための関数である。ラッパー関数は、関数処理部２２０のサービス提供用関数によって構成されるアプリケーションのバージョンが上記所定のデータベースのデータ構造のバージョンと異なる場合には、データ構造をアプリケーションのバージョンに合わせて変更するデータ構造変更関数を呼び出す。アプリケーション更新時には、ラッパー関数から参照可能なアプリケーションのバージョンを関数定義とは独立したファイル等に定義しておく。ラッパー関数は、データベースに格納されたデータ構造のバージョンとアプリケーションのバージョンが整合しているかを確認し、整合していない場合にはデータ構造変換関数を呼び出す。データ構造変換関数は、データベースのデータ構造のバージョンと、アプリケーションのバージョンとの組み合わせ毎に定義される。

より詳細には、既存ＳＩＰサーバでは、Ｊａｖａ（登録商標）やＣ＋＋等のオブジェクトとしてデータが管理されていたため、機能追加時のデータ構造変更時にはアプリケーションがデータ構造の変更を行う必要があった。
一方、本実施の形態の通信サービス提供システム２０では、ロジックとデータを分離し、ロジックはサービス提供用関数として関数処理部２２０で保持し、データはデータ管理部２３０（ＮｏＳＱＬデータベース）で保持している。それぞれのデータベースには、データ構造のバージョンが追加されている。そして、サービス提供用関数からデータベースへのアクセスは、直接ではなく、ラッパー関数経由で行う。ラッパー関数が必要に応じてデータ構造変換関数を呼び出すため、アプリケーションを構成するサービス提供用関数ではデータ構造のバージョンを意識した処理を行う必要はない。

また、既存ＳＩＰサーバでは、不具合等で元のデータ構造にロールバックしたい場合、変更済のデータと変更前のデータを判断して適切な処理を行うプログラムを作成する必要があった。
一方、本実施の形態の通信サービス提供システム２０では、データ構造のロールバック時にも、アプリケーションのバージョンとデータ構造のバージョンとが異なる場合にデータ構造変換関数を呼び出すことになる。ただし、ロールバックの場合には、アプリケーションのバージョンよりもデータ構造のバージョンの方が新しいという点がバージョンアップの場合とは異なる。したがって、データ構造変換関数は、データ構造の新しいバージョンからアプリケーションのバージョンにデータ構造を変換することになる。

以上説明したように、実施の形態にかかる通信サービス提供システム２０によれば、通信サービスにおける各処理をサービス提供用関数として定義することにより、オブジェクト指向に基づくシステムと比較して、新規サービスの追加やサービス内容の変更を容易に行うことができる。
すなわち、関数は実行に必要な情報は引数として受け取るので、関数実行環境にデータを保持する必要がなく、関数実行毎に新しい関数実行環境を起動することが可能となる。新しい関数実行環境を起動する時点で最新の関数定義を参照するため、特別なファイル更新機能は不要であり、サービスの追加等を実行するタイミングを任意に設定することができる。
また、サービス提供用関数からデータベースへのアクセスをラッパー関数経由で行うことによって、データ構造のバージョンとアプリケーションのバージョンとが一致するか否かを意識することなくデータベースが利用可能となり、データとロジックとを分離して取り扱う上での利便性を向上させることができる。また、実行中のアプリケーションのバージョンの方がデータ構造のバージョンより古い場合にもロールバックが可能となり、例えば新規サービスに不具合が生じた場合などにも容易に対応することができる。

なお、一般に、通信サービスに新規サービスを追加する際には、商用サービス提供環境（商用環境）とは別に、これとほぼ同規模の試験環境を構築する必要がある。ここで、本実施の形態の通信サービス提供システム２０が用いるＳＩＰでは、ＨＴＴＰと異なりパスで商用環境と試験環境を分離することができない。このため、ポート番号で商用環境と試験環境を分離する。例えば、商用環境ではポート番号５０６０を使用し、試験環境ではポート番号１５０６０を使用するなどである。
また、メッセージ−関数対応データベース２３０２においても、図６（ａ）に示すように、試験環境と商用環境で対応する関数を別々に管理する。また、関数を変更せずに試験環境では試験用データを、商用環境では商用データを、それぞれ参照・更新できるようにするため、図６（ｂ）および図６（ｃ）に示すように、環境毎にラッパー関数名と関数の対応表およびデータベース名とデータベースの対応表を作成し、実行時にそれぞれの名前解決を行う。
これにより、商用サービス環境で商用サービスに影響を与えずにサービスの試験を実施することができる。

２０ 通信サービス提供システム
２００ 振り分け処理部
２１０，２１１，２１２ プロトコル処理部
２１０１ メッセージ受信部
２１０２ 関数選択部
２１０３ 関数呼び出し部
２１０４ 状態遷移部
２２０，２２１，２２２ 関数処理部
２３０，２３１，２３２ データ管理部
２３０１ プロトコル状態データベース
２３０２ メッセージ−関数対応データベース
２３０３ サービス状態データベース
１０ 発端末
３０ 着端末
５０ 加入者情報データベース

Claims (6)

1. ユーザ端末に対して所定の通信プロトコルを使用する通信サービスを提供する通信サービス提供システムであって、
   前記通信サービスの提供に必要なサービス提供用関数群を保持するとともに、指定されたサービス提供用関数を実行する関数処理部と、
   前記ユーザ端末から入力メッセージを受信し、前記入力メッセージから今回の通信を識別する識別情報を抽出し、今回の通信のプロトコル状態を照会するメッセージ受信部と、
   前記入力メッセージの種類を判定し、前記入力メッセージの種類に応じて前記サービス提供用関数群から前記関数処理部に実行させる前記サービス提供用関数を選択する関数選択部と、
   前記入力メッセージに含まれる前記サービス提供用関数の実行に必要な情報および前記プロトコル状態を変数として前記関数処理部に前記サービス提供用関数を実行させ、返答先ユーザ端末に送信する出力メッセージおよび前記プロトコル状態の遷移先を関数値として得る関数呼び出し部と、
   前記返答先ユーザ端末に前記出力メッセージを送信する状態遷移部と、
   を備えることを特徴とする通信サービス提供システム。
2. 前記通信サービスの提供に用いられるデータベースを保持するデータ管理部を更に備え、
   前記関数処理部が実行する前記サービス提供用関数は、所定のアプリケーションにおける所定の処理を実行するものであり、
   前記データ管理部に記録されたデータベースには、当該データベースのデータ構造のバージョンが記録されており、
   前記所定のデータベースのデータ構造を変更する際は、変更後のデータ構造を前記アプリケーションのバージョンに合わせて変更する新規のデータ構造変更関数を定義し、
   前記関数処理部が実行する前記サービス提供用関数が前記データ管理部内の所定のデータベースにアクセスする際はラッパー関数を経由してアクセスし、
   前記ラッパー関数は、前記アプリケーションのバージョンが前記所定のデータベースの前記データ構造のバージョンと異なる場合には、前記データ構造を前記アプリケーションのバージョンに合わせて変更するデータ構造変更関数を呼び出す、
   ことを特徴とする請求項１に記載の通信サービス提供システム。
3. 前記通信サービスを用いた個々の通信の前記通信プロトコル上の状態を示すプロトコル状態を、当該通信の識別情報と対応付けて記録するプロトコル状態データベースと、
   前記個々の通信に対応する前記通信サービスのサービス状態を、当該通信の識別情報と対応付けて記録するサービス状態データベースとを更に備え、
   前記メッセージ受信部は、前記プロトコル状態データベースに前記プロトコル状態を照会し、
   前記関数処理部は、前記サービス状態を変更する前記サービス提供用関数が実行された場合、前記サービス状態データベースに記録された前記今回の通信に対応するサービス状態を、変更後のサービス状態に更新し、
   前記状態遷移部は、前記プロトコル状態データベースに記録された前記プロトコル状態を前記遷移先の状態に更新する、
   ことを特徴とする請求項１または請求項２に記載の通信サービス提供システム。
4. ユーザ端末に対して所定の通信プロトコルを使用する通信サービスを提供する通信サービス提供システムにおける通信サービス提供方法であって、
   前記ユーザ端末から入力メッセージを受信し、前記入力メッセージから今回の通信を識別する識別情報を抽出し、今回の通信のプロトコル状態を照会するメッセージ受信ステップと、
   前記入力メッセージの種類を判定し、前記入力メッセージの種類に応じて前記通信サービスの提供に必要なサービス提供用関数群から、関数呼び出しステップで実行するサービス提供用関数を選択する関数選択ステップと、
   前記入力メッセージに含まれる前記サービス提供用関数の実行に必要な情報および前記プロトコル状態を変数として前記サービス提供用関数を実行し、返答先ユーザ端末に送信する出力メッセージおよび前記今回の通信の状態の遷移先を関数値として得る関数呼び出しステップと、
   前記返答先ユーザ端末に前記出力メッセージを送信する状態遷移ステップと、
   を含むことを特徴とする通信サービス提供方法。
5. 前記通信サービス提供システムは、
   前記通信サービスの提供に用いられるデータベースを保持するデータ管理部を備え、
   前記関数呼び出しステップで実行される前記サービス提供用関数は、所定のアプリケーションにおける所定の処理を実行するものであり、
   前記データ管理部に記録されたデータベースには、当該データベースのデータ構造のバージョンが記録されており、
   前記所定のデータベースのデータ構造を変更する際は、変更後のデータ構造を前記アプリケーションのバージョンに合わせて変更する新規のデータ構造変更関数を定義し、
   前記関数呼び出しステップでは、実行する前記サービス提供用関数が前記データ管理部内の所定のデータベースにアクセスする際はラッパー関数を経由してアクセスし、前記アプリケーションのバージョンが前記所定のデータベースの前記データ構造のバージョンと異なる場合には、前記ラッパー関数が前記データ構造を前記アプリケーションのバージョンに合わせて変更するデータ構造変更関数を呼び出す、
   ことを特徴とする請求項４に記載の通信サービス提供方法。
6. 前記通信サービス提供システムは、
   前記通信サービスを用いた個々の通信の前記通信プロトコル上の状態を示すプロトコル状態を、当該通信の識別情報と対応付けて記録するプロトコル状態データベースと、
   前記個々の通信に対応する前記通信サービスのサービス状態を、当該通信の識別情報と対応付けて記録するサービス状態データベースとを更に備え、
   前記メッセージ受信ステップでは、前記プロトコル状態データベースに前記プロトコル状態を照会し、
   前記関数呼び出しステップでは、前記サービス状態を変更する前記サービス提供用関数が実行された場合、前記サービス状態データベースに記録された前記今回の通信に対応するサービス状態を、変更後のサービス状態に更新し、
   前記状態遷移ステップでは、前記プロトコル状態データベースに記録された前記プロトコル状態を前記遷移先の状態に更新する、
   ことを特徴とする請求項４または請求項５に記載の通信サービス提供方法。

Images