JP2013025442A

JP2013025442A - データ管理方法、データ管理サーバ、そのデータ移行方法及びプログラム

Info

Publication number: JP2013025442A
Application number: JP2011157710A
Authority: JP
Inventors: Masashi Kaneko; 雅志金子; Gosei Nishimura; 豪生西村
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2011-07-19
Filing date: 2011-07-19
Publication date: 2013-02-04
Anticipated expiration: 2031-07-19
Also published as: JP5503599B2

Abstract

【課題】データの更新時やシステム更新時に、データの不整合を発生させず、かつ、システム無停止でサービスを提供でき処理のリアルタイム性を確保できる、ＨＴＴＰをベースとしたデータ管理システムを実現する。
【解決手段】複数のクライアント（アプリケーションサーバ２）からアクセスされる共有データを記憶し管理するデータ管理システムにおいて、データ管理サーバ１をＸＣＡＰサーバとして構築し、このデータ管理サーバ１が、クライアントからの更新リクエストに基づいて共有データを更新するときに、データの更新処理を実行するデータ更新処理手段（データハンドラ２０）に当該共有データを引き渡して処理を委譲し、このデータ更新処理手段からの応答に含まれる更新結果のデータを自身の記憶部に格納するまでの期間αは、当該共有データに対する他の更新リクエストについての処理を行わないように排他制御を行う。
【選択図】図６

Description

本発明は、ネットワーク接続される端末やアプリケーションサーバからアクセスされるデータ管理サーバにおけるデータを管理する技術に関する。

次世代ネットワーク（ＮＧＮ：Next Generation Network）の中核技術であるＩＭＳ（IP Multimedia Subsystem）では、データを管理する仕組みとして、ＸＭＬ（Extensible Markup Language）形式のドキュメント（以下、「ＸＭＬドキュメント」という）によって記述されるデータをアクセスするＸＣＡＰ（XML Configuration Access Protocol）が規定されている。

ＸＣＡＰサーバは、ネットワーク接続されるコンピュータによって構築され、ＸＭＬドキュメントを記憶し管理するサーバであり、ＸＣＡＰによるクライアントからの遠隔アクセスが可能である。ＸＣＡＰは、ＨＴＴＰ（Hypertext Transfer Protocol）をベースとしたプロトコルであり、リクエストとレスポンスとの対で完結する単純なプロトコルである。それ故、標準で規定されているオペレーションにおいては、読み込み（ＧＥＴ）、生成・置換（ＰＵＴ）、削除（ＤＥＬＥＴＥ）といったオペレーションが、１回１回独立して実行されるものとなっている（例えば、非特許文献１参照）。

高い可用性と信頼性とが求められる通信ネットワークにおいて、各種サービスを提供する通信事業者のネットワーク装置は、いかなる場合も無停止での運用が求められる。そのため、ネットワーク装置がサービスを提供するために必要なデータを管理するＸＣＡＰサーバは、それらのサービスを停止させることなくデータ内容の更新（データやスキーマの更新）やシステム更新（ソフトウェアやハードウェアの更新）を行える必要がある。また、ＸＣＡＰサーバには、処理のリアルタイム性が要求される。

ゴンザロ・カマリロ／ミゲール・A・マーチン共著、「ＩＭＳ標準テキスト改訂版」、リックテレコム、2010年3月

ＸＣＡＰサーバのようなデータ管理システムにおいては、データの更新時やシステム更新時に複数のクライアントから同一のデータがアクセスされた場合であっても、データの不整合を発生させず、かつ、無停止でサービスを提供する必要がある。また、実装を複雑化させないためには、すべてがＨＴＴＰベースで実現できるアクセス方法とすることが好ましい。

ＸＣＡＰ標準で規定されているIf-MatchヘッダとEtagヘッダとを利用すれば、更新の競合によるデータの不整合を避けることができるが、この方法では競合が発生してデータが更新されたときには処理をリトライする必要がある。そのため、並列に更新が行われ頻繁に競合が発生するデータに関しては、更新が成功するまでに何度もリトライを繰り返さねばならない可能性があるので、処理のリアルタイム性を保証すること（想定時間内で処理を完了させること）が難しい。

本発明は、これら従来技術の課題を解決するためになされたものであり、ＨＴＴＰをベースとしたリクエスト−レスポンス型のデータ管理システムにおいて、データの更新時やシステム更新時に複数のクライアントから同一のデータがアクセスされた場合であっても、データの不整合を発生させず、かつ、無停止でサービスを提供できるとともに、処理のリアルタイム性を確保できるデータ管理方法、データ管理サーバ、そのデータ移行方法及びプログラムを提供することを目的とする。

前記の目的を達成するために、本発明は、ネットワーク接続された複数のクライアントからアクセスされる共有データを記憶し管理するデータ管理サーバにおけるデータ管理方法において、前記データ管理サーバをＸＣＡＰサーバとして構築し、前記データ管理サーバが、クライアントからの更新リクエストに基づいて共有データを更新するときに、データの更新処理を実行するデータ更新処理手段に当該共有データを引き渡して更新処理を委譲し、当該データ更新処理手段からの応答に含まれる更新結果のデータを受領して自身の記憶部に格納するまでの期間は、当該共有データに対する他の更新リクエストについての更新処理を行わないように排他制御を行うものとした。

こうすることにより、データの更新時やシステム更新時に複数のクライアントから同一のデータがアクセスされた場合であっても、データの不整合を発生させず、かつ、無停止でサービスを提供できリアルタイム性が高いＨＴＴＰベースのデータ管理システムを実現することができる。

また、本発明は、前記のデータ管理方法において、更新処理の委譲先となるデータ更新処理手段を、前記更新リクエストを発行するクライアントが指定するものとし、さらに、ネットワーク接続されたユーザ端末に所定のサービスを提供するアプリケーションサーバのなかに前記データ更新処理手段を実装することで、クライアントとなるアプリケーションサーバが自身に備えるデータ更新処理手段に更新処理を委譲できるものとした。

こうすることにより、アプリケーションサーバが提供するサービスに応じた任意のデータ更新処理を容易に実装することができる。

また、本発明は、前記のデータ管理サーバが記憶している共有データを、オンラインで他のデータ管理サーバに移行するためのデータ移行方法において、移行元のデータ管理サーバが、共有データの移行処理を実行するアプリケーションサーバから、当該アプリケーションサーバ自身に備えるデータ移行処理手段を委譲先とする前記共有データの更新リクエストを受け付けて当該データ移行処理手段に当該共有データの移行処理を委譲するステップと、このデータ移行処理手段が、移行処理の委譲時に移行元のデータ管理サーバから引き渡されるデータを、必要に応じて所定の変換処理を行ったのちに、移行先のデータ管理サーバに移行先における識別キーを指定して引き渡して当該データの登録を要求し、当該データの登録完了の応答を受領したのちに、この移行先における識別キーを移行元のデータ管理サーバへの応答に含めて通知するステップと、移行元のデータ管理サーバが、この応答に含まれる移行先における識別キーを移行を完了した当該共有データの移行元における識別キーに対応付けてデータ管理テーブルに登録するまでの期間は、当該共有データに対する他の更新リクエストについての更新処理を行わないように排他制御を行うステップと、移行元のデータ管理サーバに対して任意のクライアントから移行を完了した共有データへのアクセス要求があった場合に、移行元のデータ管理サーバが前記データ管理テーブルを参照して移行先における識別キーを前記アクセス要求への応答に含めて当該要求元のクライアントに当該共有データが移行された旨を通知するステップとを含むものとした。

こうすることにより、システム更新などのためにデータ管理サーバを他の装置に移行する場合においても、クライアントへのサービスを継続しつつ共有データを順次移行することが可能となる。

本発明によれば、ＨＴＴＰをベースとしたリクエスト−レスポンス型のデータ管理システムにおいて、データの更新時やシステム更新時に複数のクライアントから同一のデータがアクセスされた場合であっても、データの不整合を発生させず、かつ、無停止でサービスを提供できるとともに、処理のリアルタイム性を確保できるデータ管理方法、データ管理サーバ、そのデータ移行方法及びプログラムを提供することができる。

本発明の実施形態に係るデータ管理サーバの適用例を示す構成図である。セッション接続サービスにおけるシーケンス例である。回線数制限を伴うセッション接続サービスの従来のシーケンス例である。回線数制限が正しく行われない場合の従来のシーケンス例である。本発明に係るデータ管理サーバの機能構成を示すブロック図である。本発明に係るデリゲート機能の基本的な動作を示すシーケンスである。デリゲート機能を用いて回線数制限を行う場合のシーケンス例である。データ管理サーバをシステム移行する場合の従来のシーケンス例である。デリゲート機能を用いてデータ管理サーバをシステム移行する場合のシーケンス例である。データ管理テーブルの構成及びデータ例である。

以下、本発明の実施形態を適宜図面を参照して詳細に説明する。
図１は、本発明の実施形態に係るデータ管理サーバの適用例を示す構成図である。ここでは、ネットワーク４に接続された複数のユーザ端末５に対して各種サービスを提供する複数のアプリケーションサーバ２が、データ管理サーバ１のクライアントとして、データ管理サーバ１によって管理される共有データをアクセスしながら所定のサービスを提供するものとする。

データ管理サーバ１は、ＸＣＡＰサーバとして実装されており、管理対象の共有データはＸＭＬによって記述され不図示の記憶部に格納されている。アプリケーションサーバ２は、ユーザ端末５からのサービス要求に応じて、読み込み（ＧＥＴ）、生成・置換（ＰＵＴ）、削除（ＤＥＬＥＴＥ）といった共有データに対するＸＣＡＰのリクエストを生成してデータ管理サーバ１に送信し、データ管理サーバ１は、受信したリクエストによって指定された共有データに対して該当する処理を行い、その結果を示すレスポンスを送信元のアプリケーションサーバ２に返送する。このとき、対象とする共有データは、ＸＭＬドキュメントやその構成要素を識別するＵＲＩ（Uniform Resource Identifier）と呼ばれる所定形式の文字列キーによって指定される。

＜第一実施形態＞セッション接続サービス
まず、第一実施形態として、アプリケーションサーバ２が、ユーザ端末５同士の通信を可能とするためのセッションを確立する、セッション接続サービスを提供する例につき、データ管理サーバ１の動作を詳しく説明する。

図２は、セッション接続サービスにおけるシーケンス例である。本例では、ユーザ端末Ａ（５Ａ）がアプリケーションサーバ２に対してユーザ端末Ｂ（５Ｂ）との間でＳＩＰ（Session Initiation Protocol）セッションの接続を要求するときのシーケンス例を示している。

本例において、各ユーザ端末５、例えばユーザ端末Ｂ（５Ｂ）は、あらかじめＳＩＰのＲＥＧＩＳＴＥＲ要求を用いて自身のＲＥＧＩＳＴＥＲ情報（ＩＰアドレス等）をデータ管理サーバ１に登録しておくものとする（ステップＳ２０１〜Ｓ２０４）。このとき、アプリケーションサーバ２は、当該ＲＥＧＩＳＴＥＲ情報を識別するためのキーとなるＵＲＩとして例えば「Ｘb」（Ｘbは、「ユーザ端末Ｂ」なる名称から一意に定まる文字列キーとする）を設定し、「Ｘb」に対するＰＵＴリクエストをデータ管理サーバ１に送信する（ステップＳ２０２）。データ管理サーバ１は、指定された「Ｘb」に対応付けて当該ＲＥＧＩＳＴＥＲ情報を不図示の記憶部に格納したのち、成功のレスポンスをアプリケーションサーバ２に返送する（ステップＳ２０３）。

その後、ユーザ端末Ａ（５Ａ）がアプリケーションサーバ２に対してユーザ端末Ｂ（５Ｂ）との間のセッション接続要求（ＩＮＶＩＴＥ要求）を送信すると（ステップＳ２０５）、当該要求を受信したアプリケーションサーバ２は、ユーザ端末Ｂ（５Ｂ）への発信を行うために、データ管理サーバ１に対して「Ｘb」に対応付けられた値（以下、単に「Ｘb」の値という。他のキーについても同様。）の読み込みを要求し（ステップＳ２０６）、そのレスポンス（ステップＳ２０７）に含まれるユーザ端末Ｂ（５Ｂ）のＲＥＧＩＳＴＥＲ情報を取得し、取得したＲＥＧＩＳＴＥＲ情報を使用することでユーザ端末Ｂ（５Ｂ）に対してＩＮＶＩＴＥ要求を転送する（ステップＳ２０８）。

なお、図２には、１つのセッション接続要求についてのシーケンス例を示したが、同様なセッション接続サービスは複数のアプリケーションサーバ２によって提供されるので、データ管理サーバ１に対しては複数のアプリケーションサーバ２から並列にデータの読み込み要求が発行されることになる。

続いて、同時に利用可能な回線数の制限を伴う場合のセッション接続サービスのシーケンス例について説明する。図３は、回線数制限を伴うセッション接続サービスの従来のシーケンス例である。本例においては、データ管理サーバ１が、例えば「Ｘa」の値としてユーザ端末Ａ（５Ａ）が利用可能な残りの回線数を保持しており、同時に２回線までしかセッションを確立できないように制限するものとする。

本例においては、「Ｘa」の初期値には２が設定されており、ユーザ端末Ａ（５Ａ）からセッション接続要求を受信するアプリケーションサーバ２が、データ管理サーバ１から残りの回線数である「Ｘa」の値を取得し（ステップＳ３０２〜Ｓ３０３、ステップＳ３０８〜Ｓ３０９、ステップＳ３１４〜Ｓ３１５）、残りの回線数が１以上であれば、新たなセッションの確立を行うものとして、残りの回線数を−１して「Ｘa」の値を更新するようにＰＵＴリクエストをデータ管理サーバ１に送信する（ステップＳ３０４、ステップＳ３１０）。データ管理サーバ１は、「Ｘa」の値として当該更新された残りの回線数を格納したのち、成功のレスポンスをアプリケーションサーバ２に返送する（ステップＳ３０５、ステップＳ３１１）。一方、取得した残りの回線数が０であった場合には（ステップＳ３１５）、アプリケーションサーバ２は、これ以上新たなセッションを確立することはできない（回線確保ＮＧ）と判定して、ユーザ端末Ａ（５A）に対して回線数が不足している旨のエラー応答を返送する（ステップＳ３１６）。

このように、「Ｘa」の値を更新するＰＵＴリクエストが１つずつ順番に発行される場合には、アプリケーションサーバ２による回線数制限は正しく作用することとなるが、「Ｘa」の値を更新するＰＵＴリクエストがほぼ同時に発行されると、データの不整合により回線数制限が正しく行われなくなる場合がある。図４は、回線数制限が正しく行われない場合の従来のシーケンス例である。

本例においては、図３のステップＳ３０７におけるセッション接続要求の直後に、次のセッション接続要求が発行されたものとする（ステップＳ４０１、ステップＳ４０４）。図４では、ユーザ端末Ｃへのセッション接続要求に係る処理を実線で、ユーザ端末Ｄへのセッション接続要求に係る処理を破線で表している。本例のように、２つのセッション接続要求がほぼ同時に連続して発行されると、先に発行されたセッション接続要求（ステップＳ４０１）に対する残り回線数の更新が反映される（ステップＳ４０７とステップＳ４０８との間）以前に、次のセッション接続要求（ステップＳ４０４）の処理に用いる残り回線数が取得されてしまうこととなる（ステップＳ４０５〜Ｓ４０６）。そのため、データの不整合が発生して、破線で示したようにユーザ端末Ｄへのセッションが確立される結果となり（ステップＳ４１２）、回線数制限が正しく行われなくなってしまう。

このようなデータの不整合を避けるためには、データの更新処理を行っている間に発行される他の更新要求をすべてブロックする必要がある。この更新処理のブロックとブロック解除の機能をアプリケーションサーバ２に持たせる方法も考えられるが、更新処理をブロックしている状態でアプリケーションサーバ２がダウンすると、更新処理のブロック解除の契機が失われてしまうという解除契機の喪失問題が発生する。

これに対し、本発明では、データ管理サーバ１が管理している共有データを更新する処理を、データ管理サーバ１から本発明におけるデータの更新処理を実行するデータ更新処理手段としてのデータハンドラ２０に委譲し、データハンドラ２０による更新処理が完了するまでの期間は、当該共有データに対する次の更新要求を受け付けないようにデータ管理サーバ１側でブロックすることにより、前記の問題を解決する。

図５は、本発明に係るデータ管理サーバの機能構成を示すブロック図である。図５に示すように、データ管理サーバ１は、デリゲート機能１０とデータ管理テーブル１１とを備える。デリゲート機能１０とは、アプリケーションサーバ２などのクライアントからの要求にしたがって、データに対する処理を指定された第三者に委譲する機能である。本実施形態においては、アプリケーションサーバ２のなかに実装され、当該サーバの管理下にあるデータハンドラ２０にデータの更新処理を委譲する場合について説明するが、これに限らず、データ管理サーバ１自身や他の専用サーバのなかにデータハンドラ２０を実装するようにしてもよい。

データ管理テーブル１１には、ＸＣＡＰリクエストのなかに記述されるデータを指定するための文字列キーである当該データのＵＲＩとデータの実体の存在位置（ファイルパス等のロケーション情報）とを対応付けるデータエントリが格納される。データ管理サーバ１は、ＸＣＡＰリクエストを受信すると、当該リクエストに含まれる対象データのＵＲＩをキーとしてデータ管理テーブル１１を検索することにより、当該データの存在位置を取得する。また、データ管理テーブル１１に未登録のＵＲＩに対してデータのＰＵＴリクエストが発行された場合は、当該データの格納位置を決定して当該ＵＲＩと当該データとを対応付けるデータエントリを生成してデータ管理テーブル１１に追加登録する。

図６は、本発明に係るデリゲート機能の基本的な動作例を示すシーケンスである。本例では、ＨＴＴＰのＰＯＳＴメソッドを利用してデリゲート機能１０を起動する場合の例を示している。具体的には、アプリケーションサーバ２が、データ「X」に対するＰＯＳＴリクエストを発行するときに、「ｄｅｌｅｇａｔｅ」ヘッダにより処理の委譲先のＵＲＬ（Uniform Resource Locator）として「ｄｈ」（データハンドラ２０を識別するための文字列キー）を指定する（ステップＳ６０１）ことにより、自身に備えるデータハンドラ２０にてデータ更新処理を行わせている。

デリゲート機能１０の起動を要求されたデータ管理サーバ１は、指定されたＵＲＬ（「ｄｈ」）によって示されるデータハンドラ２０に対して、新たなＰＯＳＴリクエストを発行することにより、「Ｘ」の現在の値であるｘ_１を引き渡す（ステップＳ６０２）。データハンドラ２０は、所定のデータ更新処理を行うことで引き渡されたｘ_１をｘ_２に更新し、ステップＳ６０２のＰＯＳＴリクエストへの応答として、データ管理サーバ１に更新後の値であるｘ_２を返送する（ステップＳ６０３）。データ管理サーバ１は、データハンドラ２０からの応答を受け取ると、自身が管理している「Ｘ」の値をｘ_１からｘ_２に更新し、ステップＳ６０１のＰＯＳＴリクエストへの応答として、アプリケーションサーバ２にｘ_２を返送する（ステップＳ６０４）。

これらの一連の処理（ステップＳ６０１〜Ｓ６０４）により、「Ｘ」によって識別されるデータの値は、１つのＰＯＳＴリクエスト（Ｓ６０１）を発行するだけで更新を行うことができる。このとき、データ管理サーバ１のデリゲート機能１０は、これら一連の処理が完了するまでのαの期間で、「Ｘ」のデータをロックすることで他のクライアントからの「Ｘ」に対する更新要求をブロックし、ブロックした更新要求はステップＳ６０４の後に処理を行う。これにより、データハンドラ２０によって更新処理が実行される任意のデータについて、複数のクライアントからの更新要求を排他的に処理することが可能となり、データに不整合が発生する事態を抑止することができる。

また、更新要求のブロックを解除する契機を、ＰＯＳＴリクエスト処理の終了契機（ステップＳ６０４）と連動させることによって、例えば、αの期間内でアプリケーションサーバ２がダウンした場合であっても、当該リクエストの処理中にデータハンドラ２０との間で設定されているＴＣＰ（Transmission Control Protocol）セッションが切断されることになるため、データ管理サーバ１は、それを契機に更新要求のブロックを解除することができる。よって、前記のような解除契機の喪失問題を避けることができる。

図７は、デリゲート機能１０を用いて回線数制限を行う場合のシーケンス例である。本例では、アプリケーションサーバ２は、ユーザ端末Ａ（５Ａ）からセッション接続要求を受信すると（ステップＳ７０１、ステップＳ７０４）、データ管理サーバ１に対してデリゲート機能１０によって「Ｘa」の値（残り回線数）の更新処理を自身に備えるデータハンドラ２０に委譲するように要求する（ステップＳ７０２、ステップＳ７０５）。データ管理サーバ１は、自身が管理している「Ｘa」の値を取得して当該データの更新処理をデータハンドラ２０に要求する（ステップＳ７０３、ステップＳ７０９）。データハンドラ２０は、データ管理サーバ１から引き渡された当該データの更新処理（ここでは、残り回線数を−１する処理）を行い、更新処理の結果をデータ管理サーバ１に応答する（ステップＳ７０６、ステップＳ７１０）。データ管理サーバ１は、更新処理が成功した場合は（ステップＳ７０６）、データハンドラ２０から引き渡された更新結果のデータを「Ｘa」の値として格納し、アプリケーションサーバ２に成功応答を転送する（ステップＳ７０７）。また、更新処理が失敗した場合は（ステップＳ７１０）、失敗の応答をアプリケーションサーバ２に転送する（ステップＳ７１１）。

このとき、データ管理サーバ１は、ステップＳ７０２にて「Ｘa」の値の更新要求を受けてからその処理が完了するステップＳ７０７までのαの期間で、「Ｘa」のデータをロックすることにより、次の更新要求（ステップＳ７０５）に対する処理をブロックし、その処理はステップＳ７０７が完了したのちに実行する（ステップＳ７０９）。これにより、ユーザ端末Ａ（５Ａ）からのセッション接続要求がほぼ同時に発行された場合においても、図４にて説明したようなデータの不整合を避けることができ、回線数制限を正しく行うことが可能となる。

＜第二実施形態＞データ管理サーバのデータ移行
続いて、第二実施形態として、アプリケーションサーバ２がデータ管理サーバ１によって管理される共有データを用いてサービスを提供している環境（図１参照）において、システム更新（ソフトウェアやハードウェアの更新）のためにデータ管理サーバ１を別の装置に移行する方法について説明する。

図８は、データ管理サーバ１ｇを新たなデータ管理サーバ１ｈにシステム移行する場合の従来のシーケンス例である。アプリケーションサーバ２ｅがサービスを提供するために用いる共有データである「Ｘg」の値ｘ_１は、移行元のデータ管理サーバ１ｇに格納されており、アプリケーションサーバ２ｅから随時アクセスされているものとする（ステップＳ８０１〜Ｓ８０２）。また、共有データの移行処理は、アプリケーションサーバ２ｆによって実行されるものとする。

アプリケーションサーバ２ｆが「Ｘg」の移行処理を開始すると、まず移行元のデータ管理サーバ１ｇから「Ｘg」の値であるｘ_１を取得する（ステップＳ８０３〜Ｓ８０４）。続いて、アプリケーションサーバ２ｆは、必要があれば新たなデータ管理サーバ１ｈに移行後のデータを格納するための形式変換などのデータ移行処理によってｘ_１をｘ_２に変換するとともに、移行先のデータ管理サーバ１ｈにおける格納先のＵＲＩとなる「Ｘh」を設定してｘ_２を格納するよう要求し、データ管理サーバ１ｈは「Ｘh」の値としてｘ_２を格納する（ステップＳ８０５〜Ｓ８０６）。

続いて、アプリケーションサーバ２ｆは、データ管理サーバ１ｇから「Ｘg」のデータを削除するよう要求し（ステップＳ８０７）、データ管理サーバ１ｇは、自身のデータ管理テーブル１１から「Ｘg」に対応するデータエントリを削除することによって「Ｘg」のデータを削除したのち（図では「Ｘg＝null」と表記している。）、アプリケーションサーバ２ｆに削除完了の成功応答を返送する（ステップＳ８０８）。削除完了の成功応答を受信したアプリケーションサーバ２ｆは、「Ｘg」の移行処理を完了する。

「Ｘg」の移行処理が完了したのちにアプリケーションサーバ２ｅがデータ管理サーバ１ｇに対して「Ｘg」の値の取得を要求すると、データ管理サーバ１ｇは当該データが未登録である旨の応答を返送する（ステップＳ８０９〜Ｓ８１０）。その後、アプリケーションサーバ２ｅは、何らかの手段によって移行先のデータ管理サーバ１ｈにおける当該データのＵＲＩである「Ｘh」を入手して、データ管理サーバ１ｈから「Ｘh」の値ｘ_２を取得する必要がある（ステップＳ８１１〜Ｓ８１２）。

以上のシーケンスにおいて、図８に示したβの期間内で他のアプリケーションサーバ２が「Ｘg」のデータの更新処理を行った場合、当該アプリケーションサーバ２からは更新が成功したように見えても、更新後のデータは新たなデータ管理サーバ１ｈの「Ｘh」の値には引き継がれず、データの不整合が発生してしまう。そのようなデータの不整合を避けるためには、例えば、データ管理サーバ１ｇから１ｈへの移行処理中はすべてのデータの更新処理をブロックすればよいが、移行対象の共有データ数が多いとブロック時間が長くなり、サービスの途中で共有データの更新を要求するサービスはすべて停止してしまうこととなる。つまり、「いかなる場合も無停止での運用が求められる」という通信事業者のネットワーク装置の要件と合わなくなってしまう。

また、複数のリクエストを跨いでデータに対する更新処理の排他制御を行う従来技術として、一連のリクエスト処理を１つのトランザクションとみなし、トランザクション間の調停を行うトランザクションモニタを設置するという構成も考えられるが、システムが複雑化してしまう。

これに対し、本発明では、データ管理サーバ間の共有データの移行処理を、移行元のデータ管理サーバ１ｇから本発明におけるデータ移行処理手段としてのデータハンドラ２０に委譲し、データハンドラ２０による移行処理が完了するまでの期間は、当該共有データに対する次の更新要求を受け付けないように当該データ管理サーバ１ｇがブロックすることにより、前記の問題を解決する。

図９は、デリゲート機能を用いてデータ管理サーバをシステム移行する場合のシーケンス例である。本例では、アプリケーションサーバ２ｆが、データ管理サーバ１ｇが管理している「Ｘg」の値ｘ_１を、データ管理サーバ１ｈが管理する「Ｘh」の値ｘ_２に移行するものとする。

データ管理サーバ１ｇに格納されている共有データである「Ｘg」の値ｘ_１は、アプリケーションサーバ２ｅがサービスを提供するために随時アクセスされている（ステップＳ９０１〜Ｓ９０２）。アプリケーションサーバ２ｆが「Ｘg」の移行処理を開始すると、移行元のデータ管理サーバ１ｇに対してデリゲート機能１０によって「Ｘg」の移行処理を自身に備えるデータハンドラ２０に委譲するように要求する（ステップＳ９０３）。データ管理サーバ１ｇは、自身が管理している「Ｘg」の値ｘ_１を取得して当該データの移行処理をデータハンドラ２０に要求する（ステップＳ９０４）。

続いて、データハンドラ２０は、必要があれば移行先のデータ管理サーバ１ｈにデータを格納するためのデータ形式変換などのデータ移行処理によってｘ_１をｘ_２に変換するとともに、データ管理サーバ１ｈにおける格納先のＵＲＩである「Ｘh」を設定してｘ_２を格納するよう要求し、データ管理サーバ１ｈは、自身のデータ管理テーブル１１に「Ｘh」に対応するデータエントリを追加登録するとともに、「Ｘh」に対応する格納位置にｘ_２を格納したのち、ステップＳ９０５のＰＵＴリクエストに対する成功応答をデータハンドラ２０に返送する（ステップＳ９０５〜Ｓ９０６）。

続いて、データハンドラ２０は、ステップＳ９０４のＰＯＳＴリクエストに対する応答として、データの移行先のＵＲＩである「Ｘh」を含むリダイレクト応答を移行元のデータ管理サーバ１ｇに返送し（ステップＳ９０７）、データ管理サーバ１ｇは、自身のデータ管理テーブル１１の「Ｘg」に対応するデータエントリに移行先のＵＲＩである「Ｘh」を登録するとともに（図９では「Ｘg→Ｘh」と表記している。）、ステップＳ９０３のＰＯＳＴリクエストに対する応答として、同様なリダイレクト応答をアプリケーションサーバ２ｆに返送する（ステップＳ９０８）。このリダイレクト応答を受信したアプリケーションサーバ２ｆは、「Ｘg」の移行処理を完了する。

「Ｘg」の移行処理が完了したのちにアプリケーションサーバ２ｅがデータ管理サーバ１ｇに対して「Ｘg」のデータの取得を要求すると、データ管理サーバ１ｇは当該データが「Ｘh」に移行されたことを示すリダイレクト応答を返送する（ステップＳ９０９〜Ｓ９１０）。これにより、アプリケーションサーバ２ｅは、移行先のデータ管理サーバ１ｈから「Ｘh」の値ｘ_２を取得することができる（ステップＳ９１１〜Ｓ９１２）。

このとき、データ管理サーバ１ｇは、ステップＳ９０３にて「Ｘg」の移行要求を受けてからその処理が完了するステップＳ９０８までのαの期間で、「Ｘg」のデータをロックすることにより、「Ｘg」に対する更新要求の処理をブロックし、その処理はステップＳ９０８が完了したのちに実行する。これにより、「Ｘg」のデータ移行中にアプリケーションサーバ２ｅからデータの更新要求が発行された場合においても、リダイレクト応答によってデータの移行先を通知してデータの再取得を促すことができるので、図８にて説明したようなデータの不整合を避けることが可能となる。

また、これら一連のデータ移行処理においては、データ管理システムの機能の全体が停止することはなく、データ移行の途中においても高々一部の共有データに対する更新処理がαの期間だけブロックされるに過ぎず、アプリケーションサーバ２ｅは無停止でサービスを継続することが可能となる。

図１０は、前記のデータ移行処理に係るデータ管理テーブルの構成及びデータ例である。本例では、データ管理テーブル１１には、それぞれの共有データを識別するための文字列キーであるデータＵＲＩ１０１と、データ移行の有無を示すステータス１０２と、データの格納位置（ファイルのパス）を示すロケーション１０３との３つのフィールドからなるデータエントリが、データ管理サーバ１ｇ，１ｈが管理している共有データの数だけ登録される。

このうち、１行目の「Ｘg」のデータエントリに示すように、ステータス１０２には、当該データの移行が行われて、図９のステップＳ９０７にてリダイレクト応答を受信したときに「301 Moved」が設定され、ロケーション１０３には、当該リダイレクト応答によって通知された移行先のＵＲＩである「Ｘh」が格納される。このように他のサーバへの移行が完了したデータに対するリクエストを受信した場合には、ロケーション９０３に格納されている移行先のＵＲＩ（例えば「Ｘh」）を含むリダイレクト応答を返送する。

このようなデータ管理テーブル１１を用いて共有データの移行状態を管理することにより、すべての共有データのステータス１０２が「301 Moved」に設定された時点でデータの移行が完了したものと判断することができ、それにより移行元のデータ管理サーバ１ｇのサービス停止の可否を決めることが可能となる。

以上説明したように、本実施形態によれば、トランザクションモニタのような特別な装置を用意する必要がなく、ＨＴＴＰベースのリクエスト−レスポンスのやりとりのみで共有データの更新やシステム移行に係る排他制御を実装することが可能である。

以上にて本発明を実施するための形態の説明を終えるが、本発明の実施の態様はこれに限られるものではなく、本発明の趣旨を逸脱しない範囲内で各種の変更が可能である。

１，１ｇ，１ｈデータ管理サーバ（ＸＣＡＰサーバ）
２，２ｅ，２ｆアプリケーションサーバ（クライアント）
４ネットワーク
５，５Ａ，５Ｂユーザ端末
１０デリゲート機能
１１データ管理テーブル
２０データハンドラ（データ更新処理手段、データ移行処理手段）

Claims

ネットワーク接続された複数のクライアントからアクセスされる共有データを記憶し管理するデータ管理サーバにおけるデータ管理方法であって、
前記データ管理サーバはＸＣＡＰサーバとして構築され、
前記データ管理サーバは、前記クライアントからの更新リクエストに基づいて前記共有データを更新するときに、データの更新処理を実行するデータ更新処理手段に当該共有データを引き渡して更新処理を委譲し、当該データ更新処理手段からの応答に含まれる更新結果のデータを受領して自身の記憶部に格納するまでの期間は、当該共有データに対する他の更新リクエストについての更新処理を行わないように排他制御を行う
ことを特徴とするデータ管理方法。
請求項１に記載のデータ管理方法において、
更新処理の委譲先となる前記データ更新処理手段は、前記更新リクエストが発行されるときに前記クライアントによって指定される
ことを特徴とするデータ管理方法。
請求項２に記載のデータ管理方法において、
前記クライアントは、ネットワーク接続されたユーザ端末に所定のサービスを提供するアプリケーションサーバであり、
前記データ管理サーバは、前記アプリケーションサーバからの更新リクエストに基づいて前記共有データを更新するときに、前記アプリケーションサーバによって指定される当該アプリケーションサーバ自身に備えるデータ更新処理手段に当該共有データを引き渡して更新処理を委譲する
ことを特徴とするデータ管理方法。
ネットワーク接続された複数のクライアントからアクセスされる共有データを記憶し管理するデータ管理サーバであって、
ＸＣＡＰサーバとして構築され、
前記クライアントからの更新リクエストに基づいて前記共有データを更新するときに、データの更新処理を実行するデータ更新処理手段に当該共有データを引き渡して更新処理を委譲し、当該データ更新処理手段からの応答に含まれる更新結果のデータを受領して自身の記憶部に格納するまでの期間は、当該共有データに対する他の更新リクエストについては更新処理を行わないように排他制御を行うデリゲート機能を備える
ことを特徴とするデータ管理サーバ。
請求項４に記載のデータ管理サーバにおいて、
更新処理の委譲先となる前記データ更新処理手段は、前記共有データの更新リクエストが発行されるときに前記クライアントによって指定される
ことを特徴とするデータ管理サーバ。
請求項４または請求項５に記載のデータ管理サーバが記憶している共有データを、オンラインで他のデータ管理サーバに移行するためのデータ移行方法であって、
前記クライアントは、前記共有データの移行処理を実行するアプリケーションサーバであり、
移行元のデータ管理サーバが、前記共有データの移行処理を実行するアプリケーションサーバから、当該アプリケーションサーバ自身に備えるデータ移行処理手段を委譲先とする前記共有データの更新リクエストを受け付けて、当該データ移行処理手段に当該共有データの移行処理を委譲するステップと、
前記データ移行処理手段が、前記移行元の前記データ管理サーバから前記移行処理の委譲時に引き渡されるデータを、必要に応じて所定の変換処理を行ったのちに、移行先の前記他のデータ管理サーバに移行先における識別キーを指定して引き渡して当該データの登録を要求し、当該データの登録完了の応答を受領したのちに、前記移行先における識別キーを前記移行元の前記データ管理サーバへの前記応答に含めて通知するステップと、
前記移行元のデータ管理サーバが、前記応答に含まれる前記移行先における識別キーを移行を完了した前記共有データの移行元における識別キーに対応付けてデータ管理テーブルに登録するまでの期間は、当該共有データに対する他の更新リクエストについての更新処理を行わないように排他制御を行うステップと
を含むことを特徴とするデータ移行方法。
請求項６に記載のデータ移行方法において、
前記移行元のデータ管理サーバに対して任意のクライアントから移行を完了した前記共有データへのアクセス要求があった場合に、前記移行元のデータ管理サーバが前記データ管理テーブルを参照して前記移行先における識別キーを前記アクセス要求への応答に含めて当該要求元のクライアントに当該共有データが移行された旨を通知するステップ
をさらに含むことを特徴とするデータ移行方法。
コンピュータを、請求項４または請求項５に記載のデータ管理サーバとして機能させるためのプログラム。