"ネットワーク接続された複数のクライアントからアクセスされる共有データを記憶し管理するデータ管理サーバにおけるデータ管理方法であって、前記データ管理サーバはXCAPサーバとして構築され、前記データ管理サーバは、前記クライアントからの更新リクエストに基づいて前記共有データを更新するときに、データの更新処理を実行するデータ更新処理手段に当該共有データを引き渡して更新処理を委譲し、当該データ更新処理手段からの応答に含まれる更新結果のデータを受領して自身の記憶部に格納するまでの期間は、当該共有データに対する他の更新リクエストについての更新処理を行わないように排他制御を行うことを特徴とするデータ管理方法。請求項1に記載のデータ管理方法において、更新処理の委譲先となる前記データ更新処理手段は、前記更新リクエストが発行されるときに前記クライアントによって指定されることを特徴とするデータ管理方法。請求項2に記載のデータ管理方法において、前記クライアントは、ネットワーク接続されたユーザ端末に所定のサービスを提供するアプリケーションサーバであり、前記データ管理サーバは、前記アプリケーションサーバからの更新リクエストに基づいて前記共有データを更新するときに、前記アプリケーションサーバによって指定される当該アプリケーションサーバ自身に備えるデータ更新処理手段に当該共有データを引き渡して更新処理を委譲することを特徴とするデータ管理方法。ネットワーク接続された複数のクライアントからアクセスされる共有データを記憶し管理するデータ管理サーバであって、XCAPサーバとして構築され、前記クライアントからの更新リクエストに基づいて前記共有データを更新するときに、データの更新処理を実行するデータ更新処理手段に当該共有データを引き渡して更新処理を委譲し、当該データ更新処理手段からの応答に含まれる更新結果のデータを受領して自身の記憶部に格納するまでの期間は、当該共有データに対する他の更新リクエストについては更新処理を行わないように排他制御を行うデリゲート機能を備えることを特徴とするデータ管理サーバ。請求項4に記載のデータ管理サーバにおいて、更新処理の委譲先となる前記データ更新処理手段は、前記共有データの更新リクエストが発行されるときに前記クライアントによって指定されることを特徴とするデータ管理サーバ。請求項4または請求項5に記載のデータ管理サーバが記憶している共有データを、オンラインで他のデータ管理サーバに移行するためのデータ移行方法であって、前記クライアントは、前記共有データの移行処理を実行するアプリケーションサーバであり、移行元のデータ管理サーバが、前記共有データの移行処理を実行するアプリケーションサーバから、当該アプリケーションサーバ自身に備えるデータ移行処理手段を委譲先とする前記共有データの更新リクエストを受け付けて、当該データ移行処理手段に当該共有データの移行処理を委譲するステップと、前記データ移行処理手段が、前記移行元の前記データ管理サーバから前記移行処理の委譲時に引き渡されるデータを、必要に応じて所定の変換処理を行ったのちに、移行先の前記他のデータ管理サーバに移行先における識別キーを指定して引き渡して当該データの登録を要求し、当該データの登録完了の応答を受領したのちに、前記移行先における識別キーを前記移行元の前記データ管理サーバへの前記応答に含めて通知するステップと、前記移行元のデータ管理サーバが、前記応答に含まれる前記移行先における識別キーを移行を完了した前記共有データの移行元における識別キーに対応付けてデータ管理テーブルに登録するまでの期間は、当該共有データに対する他の更新リクエストについての更新処理を行わないように排他制御を行うステップとを含むことを特徴とするデータ移行方法。請求項6に記載のデータ移行方法において、前記移行元のデータ管理サーバに対して任意のクライアントから移行を完了した前記共有データへのアクセス要求があった場合に、前記移行元のデータ管理サーバが前記データ管理テーブルを参照して前記移行先における識別キーを前記アクセス要求への応答に含めて当該要求元のクライアントに当該共有データが移行された旨を通知するステップをさらに含むことを特徴とするデータ移行方法。コンピュータを、請求項4または請求項5に記載のデータ管理サーバとして機能させるためのプログラム。XCAPサーバのようなデータ管理システムにおいては、データの更新時やシステム更新時に複数のクライアントから同一のデータがアクセスされた場合であっても、データの不整合を発生させず、かつ、無停止でサービスを提供する必要がある。また、実装を複雑化させないためには、すべてがHTTPベースで実現できるアクセス方法とすることが好ましい。XCAP標準で規定されているIfMatchヘッダとEtagヘッダとを利用すれば、更新の競合によるデータの不整合を避けることができるが、この方法では競合が発生してデータが更新されたときには処理をリトライする必要がある。そのため、並列に更新が行われ頻繁に競合が発生するデータに関しては、更新が成功するまでに何度もリトライを繰り返さねばならない可能性があるので、処理のリアルタイム性を保証すること想定時間内で処理を完了させることが難しい。本発明は、これら従来技術の課題を解決するためになされたものであり、HTTPをベースとしたリクエスト-レスポンス型のデータ管理システムにおいて、データの更新時やシステム更新時に複数のクライアントから同一のデータがアクセスされた場合であっても、データの不整合を発生させず、かつ、無停止でサービスを提供できるとともに、処理のリアルタイム性を確保できるデータ管理方法、データ管理サーバ、そのデータ移行方法及びプログラムを提供することを目的とする。前記の目的を達成するために、本発明は、ネットワーク接続された複数のクライアントからアクセスされる共有データを記憶し管理するデータ管理サーバにおけるデータ管理方法において、前記データ管理サーバをXCAPサーバとして構築し、前記データ管理サーバが、クライアントからの更新リクエストに基づいて共有データを更新するときに、データの更新処理を実行するデータ更新処理手段に当該共有データを引き渡して更新処理を委譲し、当該データ更新処理手段からの応答に含まれる更新結果のデータを受領して自身の記憶部に格納するまでの期間は、当該共有データに対する他の更新リクエストについての更新処理を行わないように排他制御を行うものとした。こうすることにより、データの更新時やシステム更新時に複数のクライアントから同一のデータがアクセスされた場合であっても、データの不整合を発生させず、かつ、無停止でサービスを提供できリアルタイム性が高いHTTPベースのデータ管理システムを実現することができる。また、本発明は、前記のデータ管理方法において、更新処理の委譲先となるデータ更新処理手段を、前記更新リクエストを発行するクライアントが指定するものとし、さらに、ネットワーク接続されたユーザ端末に所定のサービスを提供するアプリケーションサーバのなかに前記データ更新処理手段を実装することで、クライアントとなるアプリケーションサーバが自身に備えるデータ更新処理手段に更新処理を委譲できるものとした。こうすることにより、アプリケーションサーバが提供するサービスに応じた任意のデータ更新処理を容易に実装することができる。また、本発明は、前記のデータ管理サーバが記憶している共有データを、オンラインで他のデータ管理サーバに移行するためのデータ移行方法において、移行元のデータ管理サーバが、共有データの移行処理を実行するアプリケーションサーバから、当該アプリケーションサーバ自身に備えるデータ移行処理手段を委譲先とする前記共有データの更新リクエストを受け付けて当該データ移行処理手段に当該共有データの移行処理を委譲するステップと、このデータ移行処理手段が、移行処理の委譲時に移行元のデータ管理サーバから引き渡されるデータを、必要に応じて所定の変換処理を行ったのちに、移行先のデータ管理サーバに移行先における識別キーを指定して引き渡して当該データの登録を要求し、当該データの登録完了の応答を受領したのちに、この移行先における識別キーを移行元のデータ管理サーバへの応答に含めて通知するステップと、移行元のデータ管理サーバが、この応答に含まれる移行先における識別キーを移行を完了した当該共有データの移行元における識別キーに対応付けてデータ管理テーブルに登録するまでの期間は、当該共有データに対する他の更新リクエストについての更新処理を行わないように排他制御を行うステップと、移行元のデータ管理サーバに対して任意のクライアントから移行を完了した共有データへのアクセス要求があった場合に、移行元のデータ管理サーバが前記データ管理テーブルを参照して移行先における識別キーを前記アクセス要求への応答に含めて当該要求元のクライアントに当該共有データが移行された旨を通知するステップとを含むものとした。こうすることにより、システム更新などのためにデータ管理サーバを他の装置に移行する場合においても、クライアントへのサービスを継続しつつ共有データを順次移行することが可能となる。本発明によれば、HTTPをベースとしたリクエスト-レスポンス型のデータ管理システムにおいて、データの更新時やシステム更新時に複数のクライアントから同一のデータがアクセスされた場合であっても、データの不整合を発生させず、かつ、無停止でサービスを提供できるとともに、処理のリアルタイム性を確保できるデータ管理方法、データ管理サーバ、そのデータ移行方法及びプログラムを提供することができる。以下、本発明の実施形態を適宜図面を参照して詳細に説明する。図1は、本発明の実施形態に係るデータ管理サーバの適用例を示す構成図である。ここでは、ネットワーク4に接続された複数のユーザ端末5に対して各種サービスを提供する複数のアプリケーションサーバ2が、データ管理サーバ1のクライアントとして、データ管理サーバ1によって管理される共有データをアクセスしながら所定のサービスを提供するものとする。データ管理サーバ1は、XCAPサーバとして実装されており、管理対象の共有データはXMLによって記述され不図示の記憶部に格納されている。アプリケーションサーバ2は、ユーザ端末5からのサービス要求に応じて、読み込みGET、生成置換PUT、削除DELETEといった共有データに対するXCAPのリクエストを生成してデータ管理サーバ1に送信し、データ管理サーバ1は、受信したリクエストによって指定された共有データに対して該当する処理を行い、その結果を示すレスポンスを送信元のアプリケーションサーバ2に返送する。このとき、対象とする共有データは、XMLドキュメントやその構成要素を識別するURIUniformResourceIdentifierと呼ばれる所定形式の文字列キーによって指定される。<第一実施形態>セッション接続サービスまず、第一実施形態として、アプリケーションサーバ2が、ユーザ端末5同士の通信を可能とするためのセッションを確立する、セッション接続サービスを提供する例につき、データ管理サーバ1の動作を詳しく説明する。図2は、セッション接続サービスにおけるシーケンス例である。本例では、ユーザ端末A5Aがアプリケーションサーバ2に対してユーザ端末B5Bとの間でSIPSessionInitiationProtocolセッションの接続を要求するときのシーケンス例を示している。本例において、各ユーザ端末5、例えばユーザ端末B5Bは、あらかじめSIPのREGISTER要求を用いて自身のREGISTER情報IPアドレス等をデータ管理サーバ1に登録しておくものとするステップS201~S204。このとき、アプリケーションサーバ2は、当該REGISTER情報を識別するためのキーとなるURIとして例えばXbXbは、ユーザ端末Bなる名称から一意に定まる文字列キーとするを設定し、Xbに対するPUTリクエストをデータ管理サーバ1に送信するステップS202。データ管理サーバ1は、指定されたXbに対応付けて当該REGISTER情報を不図示の記憶部に格納したのち、成功のレスポンスをアプリケーションサーバ2に返送するステップS203。その後、ユーザ端末A5Aがアプリケーションサーバ2に対してユーザ端末B5Bとの間のセッション接続要求INVITE要求を送信するとステップS205、当該要求を受信したアプリケーションサーバ2は、ユーザ端末B5Bへの発信を行うために、データ管理サーバ1に対してXbに対応付けられた値以下、単にXbの値という。他のキーについても同様。の読み込みを要求しステップS206、そのレスポンスステップS207に含まれるユーザ端末B5BのREGISTER情報を取得し、取得したREGISTER情報を使用することでユーザ端末B5Bに対してINVITE要求を転送するステップS208。なお、図2には、1つのセッション接続要求についてのシーケンス例を示したが、同様なセッション接続サービスは複数のアプリケーションサーバ2によって提供されるので、データ管理サーバ1に対しては複数のアプリケーションサーバ2から並列にデータの読み込み要求が発行されることになる。続いて、同時に利用可能な回線数の制限を伴う場合のセッション接続サービスのシーケンス例について説明する。図3は、回線数制限を伴うセッション接続サービスの従来のシーケンス例である。本例においては、データ管理サーバ1が、例えばXaの値としてユーザ端末A5Aが利用可能な残りの回線数を保持しており、同時に2回線までしかセッションを確立できないように制限するものとする。本例においては、Xaの初期値には2が設定されており、ユーザ端末A5Aからセッション接続要求を受信するアプリケーションサーバ2が、データ管理サーバ1から残りの回線数であるXaの値を取得しステップS302~S303、ステップS308~S309、ステップS314~S315、残りの回線数が1以上であれば、新たなセッションの確立を行うものとして、残りの回線数を-1してXaの値を更新するようにPUTリクエストをデータ管理サーバ1に送信するステップS304、ステップS310。データ管理サーバ1は、Xaの値として当該更新された残りの回線数を格納したのち、成功のレスポンスをアプリケーションサーバ2に返送するステップS305、ステップS311。一方、取得した残りの回線数が0であった場合にはステップS315、アプリケーションサーバ2は、これ以上新たなセッションを確立することはできない回線確保NGと判定して、ユーザ端末A5Aに対して回線数が不足している旨のエラー応答を返送するステップS316。このように、Xaの値を更新するPUTリクエストが1つずつ順番に発行される場合には、アプリケーションサーバ2による回線数制限は正しく作用することとなるが、Xaの値を更新するPUTリクエストがほぼ同時に発行されると、データの不整合により回線数制限が正しく行われなくなる場合がある。図4は、回線数制限が正しく行われない場合の従来のシーケンス例である。本例においては、図3のステップS307におけるセッション接続要求の直後に、次のセッション接続要求が発行されたものとするステップS401、ステップS404。図4では、ユーザ端末Cへのセッション接続要求に係る処理を実線で、ユーザ端末Dへのセッション接続要求に係る処理を破線で表している。本例のように、2つのセッション接続要求がほぼ同時に連続して発行されると、先に発行されたセッション接続要求ステップS401に対する残り回線数の更新が反映されるステップS407とステップS408との間以前に、次のセッション接続要求ステップS404の処理に用いる残り回線数が取得されてしまうこととなるステップS405~S406。そのため、データの不整合が発生して、破線で示したようにユーザ端末Dへのセッションが確立される結果となりステップS412、回線数制限が正しく行われなくなってしまう。このようなデータの不整合を避けるためには、データの更新処理を行っている間に発行される他の更新要求をすべてブロックする必要がある。この更新処理のブロックとブロック解除の機能をアプリケーションサーバ2に持たせる方法も考えられるが、更新処理をブロックしている状態でアプリケーションサーバ2がダウンすると、更新処理のブロック解除の契機が失われてしまうという解除契機の喪失問題が発生する。これに対し、本発明では、データ管理サーバ1が管理している共有データを更新する処理を、データ管理サーバ1から本発明におけるデータの更新処理を実行するデータ更新処理手段としてのデータハンドラ20に委譲し、データハンドラ20による更新処理が完了するまでの期間は、当該共有データに対する次の更新要求を受け付けないようにデータ管理サーバ1側でブロックすることにより、前記の問題を解決する。図5は、本発明に係るデータ管理サーバの機能構成を示すブロック図である。図5に示すように、データ管理サーバ1は、デリゲート機能10とデータ管理テーブル11とを備える。デリゲート機能10とは、アプリケーションサーバ2などのクライアントからの要求にしたがって、データに対する処理を指定された第三者に委譲する機能である。本実施形態においては、アプリケーションサーバ2のなかに実装され、当該サーバの管理下にあるデータハンドラ20にデータの更新処理を委譲する場合について説明するが、これに限らず、データ管理サーバ1自身や他の専用サーバのなかにデータハンドラ20を実装するようにしてもよい。データ管理テーブル11には、XCAPリクエストのなかに記述されるデータを指定するための文字列キーである当該データのURIとデータの実体の存在位置ファイルパス等のロケーション情報とを対応付けるデータエントリが格納される。データ管理サーバ1は、XCAPリクエストを受信すると、当該リクエストに含まれる対象データのURIをキーとしてデータ管理テーブル11を検索することにより、当該データの存在位置を取得する。また、データ管理テーブル11に未登録のURIに対してデータのPUTリクエストが発行された場合は、当該データの格納位置を決定して当該URIと当該データとを対応付けるデータエントリを生成してデータ管理テーブル11に追加登録する。図6は、本発明に係るデリゲート機能の基本的な動作例を示すシーケンスである。本例では、HTTPのPOSTメソッドを利用してデリゲート機能10を起動する場合の例を示している。具体的には、アプリケーションサーバ2が、データXに対するPOSTリクエストを発行するときに、delegateヘッダにより処理の委譲先のURLUniformResourceLocatorとしてdhデータハンドラ20を識別するための文字列キーを指定するステップS601ことにより、自身に備えるデータハンドラ20にてデータ更新処理を行わせている。デリゲート機能10の起動を要求されたデータ管理サーバ1は、指定されたURLdhによって示されるデータハンドラ20に対して、新たなPOSTリクエストを発行することにより、Xの現在の値であるx1を引き渡すステップS602。データハンドラ20は、所定のデータ更新処理を行うことで引き渡されたx1をx2に更新し、ステップS602のPOSTリクエストへの応答として、データ管理サーバ1に更新後の値であるx2を返送するステップS603。データ管理サーバ1は、データハンドラ20からの応答を受け取ると、自身が管理しているXの値をx1からx2に更新し、ステップS601のPOSTリクエストへの応答として、アプリケーションサーバ2にx2を返送するステップS604。これらの一連の処理ステップS601~S604により、Xによって識別されるデータの値は、1つのPOSTリクエストS601を発行するだけで更新を行うことができる。このとき、データ管理サーバ1のデリゲート機能10は、これら一連の処理が完了するまでのαの期間で、Xのデータをロックすることで他のクライアントからのXに対する更新要求をブロックし、ブロックした更新要求はステップS604の後に処理を行う。これにより、データハンドラ20によって更新処理が実行される任意のデータについて、複数のクライアントからの更新要求を排他的に処理することが可能となり、データに不整合が発生する事態を抑止することができる。また、更新要求のブロックを解除する契機を、POSTリクエスト処理の終了契機ステップS604と連動させることによって、例えば、αの期間内でアプリケーションサーバ2がダウンした場合であっても、当該リクエストの処理中にデータハンドラ20との間で設定されているTCPTransmissionControlProtocolセッションが切断されることになるため、データ管理サーバ1は、それを契機に更新要求のブロックを解除することができる。よって、前記のような解除契機の喪失問題を避けることができる。図7は、デリゲート機能10を用いて回線数制限を行う場合のシーケンス例である。本例では、アプリケーションサーバ2は、ユーザ端末A5Aからセッション接続要求を受信するとステップS701、ステップS704、データ管理サーバ1に対してデリゲート機能10によってXaの値残り回線数の更新処理を自身に備えるデータハンドラ20に委譲するように要求するステップS702、ステップS705。データ管理サーバ1は、自身が管理しているXaの値を取得して当該データの更新処理をデータハンドラ20に要求するステップS703、ステップS709。データハンドラ20は、データ管理サーバ1から引き渡された当該データの更新処理ここでは、残り回線数を-1する処理を行い、更新処理の結果をデータ管理サーバ1に応答するステップS706、ステップS710。データ管理サーバ1は、更新処理が成功した場合はステップS706、データハンドラ20から引き渡された更新結果のデータをXaの値として格納し、アプリケーションサーバ2に成功応答を転送するステップS707。また、更新処理が失敗した場合はステップS710、失敗の応答をアプリケーションサーバ2に転送するステップS711。このとき、データ管理サーバ1は、ステップS702にてXaの値の更新要求を受けてからその処理が完了するステップS707までのαの期間で、Xaのデータをロックすることにより、次の更新要求ステップS705に対する処理をブロックし、その処理はステップS707が完了したのちに実行するステップS709。これにより、ユーザ端末A5Aからのセッション接続要求がほぼ同時に発行された場合においても、図4にて説明したようなデータの不整合を避けることができ、回線数制限を正しく行うことが可能となる。<第二実施形態>データ管理サーバのデータ移行続いて、第二実施形態として、アプリケーションサーバ2がデータ管理サーバ1によって管理される共有データを用いてサービスを提供している環境図1参照において、システム更新ソフトウェアやハードウェアの更新のためにデータ管理サーバ1を別の装置に移行する方法について説明する。図8は、データ管理サーバ1gを新たなデータ管理サーバ1hにシステム移行する場合の従来のシーケンス例である。アプリケーションサーバ2eがサービスを提供するために用いる共有データであるXgの値x1は、移行元のデータ管理サーバ1gに格納されており、アプリケーションサーバ2eから随時アクセスされているものとするステップS801~S802。また、共有データの移行処理は、アプリケーションサーバ2fによって実行されるものとする。アプリケーションサーバ2fがXgの移行処理を開始すると、まず移行元のデータ管理サーバ1gからXgの値であるx1を取得するステップS803~S804。続いて、アプリケーションサーバ2fは、必要があれば新たなデータ管理サーバ1hに移行後のデータを格納するための形式変換などのデータ移行処理によってx1をx2に変換するとともに、移行先のデータ管理サーバ1hにおける格納先のURIとなるXhを設定してx2を格納するよう要求し、データ管理サーバ1hはXhの値としてx2を格納するステップS805~S806。続いて、アプリケーションサーバ2fは、データ管理サーバ1gからXgのデータを削除するよう要求しステップS807、データ管理サーバ1gは、自身のデータ管理テーブル11からXgに対応するデータエントリを削除することによってXgのデータを削除したのち図ではXg=nullと表記している。、アプリケーションサーバ2fに削除完了の成功応答を返送するステップS808。削除完了の成功応答を受信したアプリケーションサーバ2fは、Xgの移行処理を完了する。Xgの移行処理が完了したのちにアプリケーションサーバ2eがデータ管理サーバ1gに対してXgの値の取得を要求すると、データ管理サーバ1gは当該データが未登録である旨の応答を返送するステップS809~S810。その後、アプリケーションサーバ2eは、何らかの手段によって移行先のデータ管理サーバ1hにおける当該データのURIであるXhを入手して、データ管理サーバ1hからXhの値x2を取得する必要があるステップS811~S812。以上のシーケンスにおいて、図8に示したβの期間内で他のアプリケーションサーバ2がXgのデータの更新処理を行った場合、当該アプリケーションサーバ2からは更新が成功したように見えても、更新後のデータは新たなデータ管理サーバ1hのXhの値には引き継がれず、データの不整合が発生してしまう。そのようなデータの不整合を避けるためには、例えば、データ管理サーバ1gから1hへの移行処理中はすべてのデータの更新処理をブロックすればよいが、移行対象の共有データ数が多いとブロック時間が長くなり、サービスの途中で共有データの更新を要求するサービスはすべて停止してしまうこととなる。つまり、いかなる場合も無停止での運用が求められるという通信事業者のネットワーク装置の要件と合わなくなってしまう。また、複数のリクエストを跨いでデータに対する更新処理の排他制御を行う従来技術として、一連のリクエスト処理を1つのトランザクションとみなし、トランザクション間の調停を行うトランザクションモニタを設置するという構成も考えられるが、システムが複雑化してしまう。これに対し、本発明では、データ管理サーバ間の共有データの移行処理を、移行元のデータ管理サーバ1gから本発明におけるデータ移行処理手段としてのデータハンドラ20に委譲し、データハンドラ20による移行処理が完了するまでの期間は、当該共有データに対する次の更新要求を受け付けないように当該データ管理サーバ1gがブロックすることにより、前記の問題を解決する。図9は、デリゲート機能を用いてデータ管理サーバをシステム移行する場合のシーケンス例である。本例では、アプリケーションサーバ2fが、データ管理サーバ1gが管理しているXgの値x1を、データ管理サーバ1hが管理するXhの値x2に移行するものとする。データ管理サーバ1gに格納されている共有データであるXgの値x1は、アプリケーションサーバ2eがサービスを提供するために随時アクセスされているステップS901~S902。アプリケーションサーバ2fがXgの移行処理を開始すると、移行元のデータ管理サーバ1gに対してデリゲート機能10によってXgの移行処理を自身に備えるデータハンドラ20に委譲するように要求するステップS903。データ管理サーバ1gは、自身が管理しているXgの値x1を取得して当該データの移行処理をデータハンドラ20に要求するステップS904。続いて、データハンドラ20は、必要があれば移行先のデータ管理サーバ1hにデータを格納するためのデータ形式変換などのデータ移行処理によってx1をx2に変換するとともに、データ管理サーバ1hにおける格納先のURIであるXhを設定してx2を格納するよう要求し、データ管理サーバ1hは、自身のデータ管理テーブル11にXhに対応するデータエントリを追加登録するとともに、Xhに対応する格納位置にx2を格納したのち、ステップS905のPUTリクエストに対する成功応答をデータハンドラ20に返送するステップS905~S906。続いて、データハンドラ20は、ステップS904のPOSTリクエストに対する応答として、データの移行先のURIであるXhを含むリダイレクト応答を移行元のデータ管理サーバ1gに返送しステップS907、データ管理サーバ1gは、自身のデータ管理テーブル11のXgに対応するデータエントリに移行先のURIであるXhを登録するとともに図9ではXg→Xhと表記している。、ステップS903のPOSTリクエストに対する応答として、同様なリダイレクト応答をアプリケーションサーバ2fに返送するステップS908。このリダイレクト応答を受信したアプリケーションサーバ2fは、Xgの移行処理を完了する。Xgの移行処理が完了したのちにアプリケーションサーバ2eがデータ管理サーバ1gに対してXgのデータの取得を要求すると、データ管理サーバ1gは当該データがXhに移行されたことを示すリダイレクト応答を返送するステップS909~S910。これにより、アプリケーションサーバ2eは、移行先のデータ管理サーバ1hからXhの値x2を取得することができるステップS911~S912。このとき、データ管理サーバ1gは、ステップS903にてXgの移行要求を受けてからその処理が完了するステップS908までのαの期間で、Xgのデータをロックすることにより、Xgに対する更新要求の処理をブロックし、その処理はステップS908が完了したのちに実行する。これにより、Xgのデータ移行中にアプリケーションサーバ2eからデータの更新要求が発行された場合においても、リダイレクト応答によってデータの移行先を通知してデータの再取得を促すことができるので、図8にて説明したようなデータの不整合を避けることが可能となる。また、これら一連のデータ移行処理においては、データ管理システムの機能の全体が停止することはなく、データ移行の途中においても高々一部の共有データに対する更新処理がαの期間だけブロックされるに過ぎず、アプリケーションサーバ2eは無停止でサービスを継続することが可能となる。図10は、前記のデータ移行処理に係るデータ管理テーブルの構成及びデータ例である。本例では、データ管理テーブル11には、それぞれの共有データを識別するための文字列キーであるデータURI101と、データ移行の有無を示すステータス102と、データの格納位置ファイルのパスを示すロケーション103との3つのフィールドからなるデータエントリが、データ管理サーバ1g,1hが管理している共有データの数だけ登録される。このうち、1行目のXgのデータエントリに示すように、ステータス102には、当該データの移行が行われて、図9のステップS907にてリダイレクト応答を受信したときに301Movedが設定され、ロケーション103には、当該リダイレクト応答によって通知された移行先のURIであるXhが格納される。このように他のサーバへの移行が完了したデータに対するリクエストを受信した場合には、ロケーション903に格納されている移行先のURI例えばXhを含むリダイレクト応答を返送する。このようなデータ管理テーブル11を用いて共有データの移行状態を管理することにより、すべての共有データのステータス102が301Movedに設定された時点でデータの移行が完了したものと判断することができ、それにより移行元のデータ管理サーバ1gのサービス停止の可否を決めることが可能となる。以上説明したように、本実施形態によれば、トランザクションモニタのような特別な装置を用意する必要がなく、HTTPベースのリクエスト-レスポンスのやりとりのみで共有データの更新やシステム移行に係る排他制御を実装することが可能である。以上にて本発明を実施するための形態の説明を終えるが、本発明の実施の態様はこれに限られるものではなく、本発明の趣旨を逸脱しない範囲内で各種の変更が可能である。"