JP2011070364A - 運用管理サーバ、ロールバック実行方法およびロールバック実行プログラム - Google Patents

Abstract

【課題】障害発生時にシステムの状態を障害発生前の状態に戻す。
【解決手段】ＪＡＶＡ（登録商標）を使用したアプリケーションの運用を管理する運用管理サーバ１であって、データ更新を伴うメソッドが呼び出された場合に更新の対象となる更新前データを取得し、メソッドに対応する更新処理を実行する更新処理実行部１２と、更新処理が異常終了したか否かを判定する第１異常終了判定部１３と、更新処理が異常終了した場合に更新処理の対象となっているデータを更新前データに戻す第１ロールバック部１５と、データ更新を伴わないメソッドが呼び出された場合にこのメソッドに対応する操作処理を実行する操作処理実行部２１と、操作処理が異常終了したか否かを判定する第２異常終了判定部２２と、操作処理が異常終了した場合に操作処理が実行される前の状態に戻す第２ロールバック部２４とを備える。
【選択図】図１

Description

本発明は、運用管理サーバ、ロールバック実行方法およびロールバック実行プログラムに関する。

一般に、システムで障害が発生した場合には、ロールバックを実行してシステムの状態を障害発生前の状態に戻すことが行われている。下記特許文献１には、データベースの更新処理の途中で何らかの障害が発生した場合に、ロールバックを実行してデータベースの状態を更新処理の開始時点に戻す技術が開示されている。

特開２００６−０１８５４０号公報

ところで、オブジェクト指向プログラミング言語であるＪＡＶＡ（登録商標）は、プラットフォームに依存することなくシステムを構築できることもあり、システム開発に多用されている。ＪＡＶＡ（登録商標）でシステムを構築する場合には、フレームワークとして一般にJava（登録商標） Management Extensions（以下、「ＪＭＸ（登録商標）」という。)が用いられる。しかしながら、このＪＭＸには、処理の途中で障害が発生した場合にシステムの状態を障害発生前の状態に戻す仕組みが実装されていない。そのため、ＪＭＸを利用するクライアント側でロールバックさせる処理を組み込む必要があり、開発者の作業負担が大きくなっている。

本発明は、上述した課題を解決するためになされたものであり、クライアント側でロールバックさせる処理を組み込むことなく、障害が発生時にシステムの状態を障害発生前の状態に戻すことができる運用管理サーバ、ロールバック実行方法およびロールバック実行プログラムを提供することを目的とする。

本発明の運用管理サーバは、オブジェクト指向プログラミング言語を使用したアプリケーションの運用を管理する運用管理サーバであって、データの更新を伴う第１のメソッドの呼び出し要求を受信した場合に、当該更新の対象となる更新前データを取得するメソッドを呼び出して当該更新前データを取得した後に、第１のメソッドを呼び出して当該第１のメソッドに対応する更新処理を実行する更新処理実行手段と、更新処理が異常終了したか否かを判定する第１の異常終了判定手段と、第１の異常終了判定手段によって更新処理が異常終了したと判定された場合に、更新処理の対象となっているデータを更新前データに戻すメソッドを呼び出す第１のロールバック手段と、データの更新を伴わない第２のメソッドの呼び出し要求を受信した場合に、当該第２のメソッドを呼び出して当該第２のメソッドに対応する操作処理を実行する操作処理実行手段と、操作処理が異常終了したか否かを判定する第２の異常終了判定手段と、第２の異常終了判定手段によって操作処理が異常終了したと判定された場合に、当該操作処理が実行される前の状態に戻すメソッドを呼び出す第２のロールバック手段と、を備える。

本発明のロールバック実行方法は、オブジェクト指向プログラミング言語を使用したアプリケーションの運用を管理するサーバで実行されるロールバック実行方法であって、データの更新を伴う第１のメソッドの呼び出し要求を受信した場合に、当該更新の対象となる更新前データを取得するメソッドを呼び出して当該更新前データを取得した後、第１のメソッドを呼び出して当該第１のメソッドに対応する更新処理を実行する更新処理実行ステップと、更新処理が異常終了したか否かを判定する第１の異常終了判定ステップと、更新処理が異常終了したと判定された場合に、更新処理の対象となっているデータを更新前データに戻すメソッドを呼び出す第１のロールバックステップと、データの更新を伴わない第２のメソッドの呼び出し要求を受信した場合に、当該第２のメソッドを呼び出して当該第２のメソッドに対応する操作処理を実行する操作処理実行ステップと、操作処理が異常終了したか否かを判定する第２の異常終了判定ステップと、操作処理が異常終了したと判定された場合に、当該操作処理が実行される前の状態に戻すメソッドを呼び出す第２のロールバックステップと、を含む。

本発明のロールバック実行プログラムは、上記ロールバック実行方法に含まれる各ステップをコンピュータに実行させる。

本発明によれば、クライアント側でロールバックさせる処理を組み込むことなく、障害が発生時にシステムの状態を障害発生前の状態に戻すことができる。

実施形態における運用管理サーバの機能構成を示すブロック図である。 オブジェクトの属性値を更新する際の処理手順を示すフローチャートである。 オブジェクトの属性値を更新する際の処理内容の一例を模式的に示した図である。 オブジェクトの操作処理を実行する際の処理手順を示すフローチャートである。 オブジェクトの操作処理を実行する際の処理内容の一例を模式的に示した図である。

以下、添付図面を参照して、本発明に係る運用管理サーバ、ロールバック実行方法およびロールバック実行プログラムの好適な実施形態について説明する。

まず、図１を参照して、運用管理サーバの構成について説明する。運用管理サーバは、オブジェクト指向プログラミング言語であるＪＡＶＡ（登録商標）によって生成されるオブジェクトを運用管理するサーバである。運用管理サーバには、ＪＭＸが実装されており、アプリケーションの管理・監視を行うオブジェクトであるＭＢｅａｎ(Managed Bean)、およびＭＢｅａｎの属性や操作に関する情報を管理するオブジェクトであるＭＢｅａｎＩｎｆｏが登録されている。ＭＢｅａｎＩｎｆｏには、オブジェクトの属性や操作に関する情報に対するコメント等の補足情報を格納するためのディスクリプタ領域が設けられている。なお、本実施形態では、運用管理サーバにＪＭＸが実装されている場合について説明するが、本発明はＪＭＸが実装されていない運用管理サーバにも適用可能である。

図１を参照して、実施形態における運用管理サーバの機能構成について説明する。運用管理サーバ１は、第１ロールバック実行部１０と、第２ロールバック実行部２０と、を有する。運用管理サーバ１には、ＭＢｅａｎやＭＢｅａｎＩｎｆｏを含む各種のオブジェクトを記憶するオブジェクト記憶部３０が設けられている。

第１ロールバック実行部１０は、第１ロールバック要否判定部（第１のロールバック要否判定手段）１１と、更新処理実行部（更新処理実行手段）１２と、第１異常終了判定部（第１の異常終了判定手段）１３と、データ判定部（データ判定手段）１４と、第１ロールバック部（第１のロールバック手段）１５と、を有する。第２ロールバック実行部２０は、操作処理実行部（操作処理実行手段）２１と、第２異常終了判定部（第２の異常終了判定手段）２２と、第２ロールバック要否判定部（第２のロールバック要否判定手段）２３と、第２ロールバック部（第２のロールバック手段）２４と、を有する。

第１ロールバック要否判定部１１は、オブジェクトの属性値（データ）を更新するためのｓｅｔｔｅｒメソッドの呼び出し要求をクライアント端末２から受信した場合に、このｓｅｔｔｅｒメソッドに対応する更新処理がロールバックを要する処理であるか否かを判定する。ロールバックを要する処理であるか否かは、ロールバックを要する処理であるか否かを示すロールバック要否情報に基づいて判定することができる。ロールバック要否情報は、ｓｅｔｔｅｒメソッドを定義するオブジェクトのＭＢｅａｎＩｎｆｏに設けられたディスクリプタ領域に格納することができる。第１ロールバック要否判定部１１が参照するロールバック要否情報としては、例えば、ロールバック要否情報の識別名を”ｒｏｌｌｂａｃｋ”とし、その値として“ｔｒｕｅ”または“ｆａｌｓｅ”のいずれか一方を格納することができる。この値は、例えばtrue/falseフラグを利用して格納することができる。なお、フレームワークとしてとしてＪＭＸを用いる場合には、ｓｅｔｔｅｒメソッドをｐｕｂｌｉｃ指定することが好ましい。

具体的に、第１ロールバック要否判定部１１は、ｓｅｔｔｅｒメソッドの呼び出し要求を受信した場合に、ｓｅｔｔｅｒメソッドに対応するオブジェクトのＭＢｅａｎＩｎｆｏに設けられたディスクリプタ領域から識別名”ｒｏｌｌｂａｃｋ”の値を取得する。第１ロールバック要否判定部１１は、識別名”ｒｏｌｌｂａｃｋ”の値が“ｔｒｕｅ”である場合には、ｓｅｔｔｅｒメソッドに対応する更新処理がロールバックを要する処理であると判定する。一方、第１ロールバック要否判定部１１は、識別名”ｒｏｌｌｂａｃｋ”の値が“ｆａｌｓｅ”である場合には、ｓｅｔｔｅｒメソッドに対応する更新処理がロールバックを要しない処理であると判定する。

なお、ロールバックの要否判定を行う際の条件は、ｓｅｔｔｅｒメソッドが呼び出された場合には限定されない。データの更新を伴うメソッド（第１のメソッド）が呼び出された場合に、ロールバックの要否判定を行うことができればよい。

更新処理実行部１２は、第１ロールバック要否判定部１１によって、ｓｅｔｔｅｒメソッドに対応する更新処理がロールバックを要する処理であると判定された場合に、更新処理の対象となるオブジェクトの属性値を取得するためのｇｅｔｔｅｒメソッドを呼び出す。このｇｅｔｔｅｒメソッドを呼び出すことで、更新処理の対象となる属性に設定されている更新前データを取得することができる。更新処理実行部１２は、取得した更新前データをメモリに一時的に記憶させる。なお、フレームワークとしてとしてＪＭＸを用いる場合には、ｇｅｔｔｅｒメソッドをｐｕｂｌｉｃ指定することが好ましい。

更新処理実行部１２は、更新前データを取得した後に、クライアント端末２から呼び出し要求されたｓｅｔｔｅｒメソッドを呼び出す。このｓｅｔｔｅｒメソッドを呼び出すことで、更新処理を実行することができる。

第１異常終了判定部１３は、更新処理実行部１２によって実行されている更新処理が異常終了したか否かを判定する。

データ判定部１４は、第１異常終了判定部１３によって更新処理が異常終了したと判定された場合に、更新処理の対象となっていたオブジェクトの属性値を取得するためのｇｅｔｔｅｒメソッドを呼び出し。このｇｅｔｔｅｒメソッドを呼び出すことで、更新処理の対象になっていた更新データを取得することができる。

データ判定部１４は、取得した更新データが、更新処理実行部１２によってメモリに記憶させられた更新前データと異なるか否かを判定する。

第１ロールバック部１５は、データ判定部１４によって更新データが更新前データと異なると判定された場合に、ｓｅｔｔｅｒメソッドの引数に更新前データを設定し、このｓｅｔｔｅｒメソッドを呼び出す。ｓｅｔｔｅｒメソッドを呼び出すことで、更新処理の対象となるデータを更新前データに戻すことができる。すなわち、ロールバックを行うことができる。

操作処理実行部２１は、オブジェクトの操作を実行するためのメソッドとして、例えばｓｔａｒｔメソッドの呼び出し要求をクライアント端末２から受信した場合に、このｓｔａｒｔメソッドに対応する操作処理を実行する。なお、操作処理を実行する際の条件は、ｓｔａｒｔメソッドが呼び出された場合には限定されない。例えばファイルのアップロードやモジュールのロード等、データの更新（例えば、属性の更新）を伴わないメソッド（第２のメソッド）が呼び出された場合に、操作処理を実行することができればよい。ただし、操作処理中に属性を更新する処理を含むメソッドについては、上述したデータの更新を伴うメソッドに含めてもよい。

第２異常終了判定部２２は、例えばｓｔａｒｔメソッドがクライアント端末２から呼び出された場合に、このｓｔａｒｔメソッドに対応する操作処理が異常終了したか否かを判定する。

第２ロールバック要否判定部２３は、第２異常終了判定部２２によって操作処理が異常終了したと判定された場合に、ロールバック要否情報に基づいて、この操作処理がロールバックを要する処理であるか否かを判定する。ロールバック要否情報は、例えばｓｔａｒｔメソッドを定義するオブジェクトのＭＢｅａｎＩｎｆｏに設けられたディスクリプタ領域に格納することができる。第２ロールバック要否判定部２３が参照するロールバック要否情報としては、例えば、ロールバック要否情報の識別名を”ｒｏｌｌｂａｃｋＭｅｔｈｏｄ”とし、その値として操作処理を打ち消すメソッド、言い換えるとシステムの状態を操作処理が実行される前の状態に戻すメソッドを格納することができる。操作処理が実行される前の状態に戻すメソッドとしては、例えば、実行される操作処理のメソッドがｓｔａｒｔメソッドである場合には、ｓｔａｒｔ操作が実行される前の状態に戻すことができるｓｔｏｐメソッドが該当する。また、実行される操作処理のメソッドがファイルのアップロードメソッドである場合には、ファイルのアップロード操作が実行される前の状態に戻すことができるファイル削除メソッドが該当する。

具体的に、第２ロールバック要否判定部２３は、操作処理が異常終了した場合に、ｓｔａｒｔメソッドに対応するオブジェクトのＭＢｅａｎＩｎｆｏに設けられたディスクリプタ領域から識別名”ｒｏｌｌｂａｃｋＭｅｔｈｏｄ”の値を取得する。第２ロールバック要否判定部２３は、識別名”ｒｏｌｌｂａｃｋＭｅｔｈｏｄ”の値を取得することができた場合には、ｓｔａｒｔメソッドに対応する操作処理がロールバックを要する処理であると判定する。一方、第２ロールバック要否判定部２３は、識別名”ｒｏｌｌｂａｃｋＭｅｔｈｏｄ”の値を取得することができなかった場合には、ｓｔａｒｔメソッドに対応する操作処理がロールバックを要しない処理であると判定する。

第２ロールバック部２４は、第２ロールバック要否判定部２３によって、操作処理がロールバックを要する処理であると判定された場合に、識別名”ｒｏｌｌｂａｃｋＭｅｔｈｏｄ”の値として格納されているメソッドを呼び出す。

上述した第１ロールバック実行部１０および第２ロールバック実行部２０が有する各部の機能は、オブジェクト記憶部３０に格納される共有オブジェクトの共有メソッドを実行することで実現することができる。共有メソッドは、オブジェクト記憶部３０に記憶されている各オブジェクト（共有オブジェクトを除く）のメソッドが呼び出された場合に実行されるメソッドである。

このように、第１ロールバック実行部１０および第２ロールバック実行部２０が有する各部の機能を、共有オブジェクトの共有メソッドを実行させて実現することで、障害発生前の状態に戻すためのロールバック処理を、オブジェクト（ＭＢｅａｎ）ごとに独自に組み込む手間を省くことができる。これにより、開発者の作業負担を軽減させることが可能となる。また、オブジェクトごとに独自にロールバック処理を組み込む場合には、開発者が一部の処理を組み込み忘れることも考えられ、この場合には、障害発生時にデータの整合性が失われるおそれがある。これに対して、本発明では、共有メソッドを定義した共有オブジェクトを登録することで、ロールバック処理の組み込み作業を省略することができる。これにより、障害発生時のデータの整合性も確保することが可能となる。

ここで、運用管理サーバ１は、物理的には、例えば、ＣＰＵと、メモリと、入出力インターフェースとを含んで構成される。メモリには、例えば、ＣＰＵで処理されるプログラムやデータを記憶するＲＯＭやＨＤＤと、主として制御処理のための各種作業領域として使用されるＲＡＭとが含まれる。これらの要素は、互いにバスを介して接続されている。ＣＰＵが、ＲＯＭに記憶されたプログラムを実行し、入出力インターフェースを介して受信される各種のメッセージや、ＲＡＭに展開された各種のデータを用いて処理することで、上述した運用管理サーバ１における各部の機能を実現することができる。

次に、図面を参照して、本実施形態における運用管理サーバの動作について説明する。

まず、図２および図３を参照して、オブジェクトの属性値を更新する際の動作について説明する。図２は、オブジェクトの属性値を更新する際の処理手順を示すフローチャートである。図３は、オブジェクトの属性値を更新する際の処理内容の一例（ロールバックに成功した例）を模式的に示した図である。

最初に、クライアント端末２からオブジェクトの属性値を更新するためのｓｅｔｔｅｒメソッドの呼び出し要求を受信した場合（ステップＳ１０１）に、運用管理サーバ１の第１ロールバック要否判定部１１は、ＭＢｅａｎＩｎｆｏを参照して、ｓｅｔｔｅｒメソッドに対応する更新処理がロールバックを要する処理であるか否かを判定する（ステップＳ１０２）。この判定がＮＯである場合（ステップＳ１０２；ＮＯ）には、後述するステップＳ１０５に処理を移行する。

一方、上記ステップＳ１０２の判定でｓｅｔｔｅｒメソッドに対応する更新処理がロールバックを要する処理であると判定された場合（ステップＳ１０２；ＹＥＳ）に、更新処理実行部１２は、更新処理の対象となるオブジェクトの属性値を取得するためのｇｅｔｔｅｒメソッドを呼び出して、更新前データを取得する（ステップＳ１０３）。更新処理実行部１２は、取得した更新前データをメモリに記憶させる（ステップＳ１０４）。

続いて、更新処理実行部１２は、上記ステップＳ１０１で要求されたｓｅｔｔｅｒメソッドを呼び出して、ｓｅｔｔｅｒメソッドに対応する更新処理を実行する（ステップＳ１０５）。

続いて、第１異常終了判定部１３は、更新処理実行部１２によって実行されている更新処理が異常終了したか否かを判定する（ステップＳ１０６）。この判定がＮＯの場合（ステップＳ１０６；ＮＯ）には、この処理手順を終了する。

一方、上記ステップＳ１０６の判定で更新処理が異常終了したと判定された場合（ステップＳ１０６；ＹＥＳ）であって、かつ更新処理がロールバックを要する処理である場合（ステップＳ１０７；ＹＥＳ）に、データ判定部１４は、更新処理の対象となっていたオブジェクトの属性値を取得するためのｇｅｔｔｅｒメソッドを呼び出して、更新処理の対象になっていた更新データを取得する（ステップＳ１０９）。

続いて、データ判定部１４は、上記ステップＳ１０９で取得された更新データが、上記ステップＳ１０４で記憶された更新前データと異なるか否かを判定する（ステップＳ１１０）。この判定がＮＯである場合（ステップＳ１１０；ＮＯ）には、ロールバックが正常に行われたことを示すロールバック済メッセージを発行し（ステップＳ１１１）、この処理手順を終了する。このロールバック済メッセージには、クライアント端末２から要求されたｓｅｔｔｅｒメソッドに対応する更新処理が行われなかったことを示すメッセージも含まれる。

一方、上記ステップＳ１１０の判定で更新データが更新前データと異なると判定された場合（ステップＳ１１０；ＹＥＳ）に、第１ロールバック部１５は、ｓｅｔｔｅｒメソッドの引数に更新前データを設定し、このｓｅｔｔｅｒメソッドを呼び出す（ステップＳ１１２）。これにより、更新処理の対象となるデータを更新前データに戻すことができる。

続いて、上記ステップＳ１１２で呼び出したｓｅｔｔｅｒメソッドが正常終了した場合（ステップＳ１１３；ＹＥＳ）には、ロールバック済メッセージを発行し（ステップＳ１１４）、この処理手順を終了する。一方、上記ステップＳ１１２で呼び出したｓｅｔｔｅｒメソッドが異常終了した場合（ステップＳ１１３；ＮＯ）には、クライアント端末２から要求されたｓｅｔｔｅｒメソッドに対応する更新処理が異常終了したことを示すエラーメッセージを発行し（ステップＳ１１５）、この処理手順を終了する。このエラーメッセージの代わりに、ロールバックに失敗したことを示すメッセージを発行することとしてもよい。

次に、図４および図５を参照して、オブジェクトの操作処理を実行する際の動作について説明する。図４は、オブジェクトの操作処理を実行する際の処理手順を示すフローチャートである。図５は、オブジェクトの操作処理を実行する際の処理内容の一例（ロールバックに成功した例）を模式的に示した図である。

最初に、クライアント端末２からオブジェクトの操作を実行するためのメソッドとして、例えばｓｔａｒｔメソッドの呼び出し要求を受信した場合（ステップＳ２０１）に、運用管理サーバ１の操作処理実行部２１は、ｓｔａｒｔメソッドを呼び出して、ｓｔａｒｔメソッドに対応する操作処理を実行する（ステップＳ２０２）。

第２異常終了判定部２２は、ｓｔａｒｔメソッドに対応する操作処理が異常終了したか否かを判定する（ステップＳ２０３）。この判定がＮＯである場合（ステップＳ２０３；ＮＯ）には、この処理手順を終了する。

一方、上記ステップＳ２０３の判定でｓｔａｒｔメソッドに対応する操作処理が異常終了したと判定された場合（ステップＳ２０３；ＹＥＳ）に、第２ロールバック要否判定部２３は、ＭＢｅａｎＩｎｆｏを参照して、ｓｔａｒｔメソッドに対応する操作処理がロールバックを要する処理であるか否かを判定する（ステップＳ２０４）。この判定がＮＯである場合（ステップＳ２０４；ＮＯ）には、クライアント端末２から要求されたｓｔａｒｔメソッドに対応する操作処理が異常終了したことを示すエラーメッセージを発行し（ステップＳ２０５）、この処理手順を終了する。

一方、上記ステップＳ２０４の判定で操作処理がロールバックを要する処理であると判定された場合（ステップＳ２０４；ＹＥＳ）に、第２ロールバック部２４は、ＭＢｅａｎＩｎｆｏを参照して、ｓｔｏｐメソッドを呼び出す（ステップＳ２０６）。このｓｔｏｐメソッドが正常終了することで、ｓｔａｒｔメソッドに対応する操作処理が実行される前の状態に戻すことができる。

続いて、上記ステップＳ２０６で呼び出したｓｔｏｐメソッドが正常終了した場合（ステップＳ２０７；ＹＥＳ）には、ロールバックが正常に行われたことを示すロールバック済みメッセージを発行し（ステップＳ２０８）、この処理手順を終了する。一方、上記ステップＳ２０６で呼び出したｓｔｏｐメソッドが異常終了した場合（ステップＳ２０７；ＮＯ）には、クライアント端末２から要求されたｓｔａｒｔメソッドに対応する操作処理が異常終了したことを示すエラーメッセージを発行し（ステップＳ２０９）、この処理手順を終了する。このエラーメッセージの代わりに、ロールバックに失敗したことを示すメッセージを発行することとしてもよい。

上述してきたように、実施形態における運用管理サーバ１によれば、データの更新を伴うメソッドが呼び出され、その更新処理が異常終了した場合には、更新処理の対象となっているデータを更新前データに戻すメソッドを呼び出すことができ、データの更新処理を含まないメソッドが呼び出され、その操作処理が異常終了した場合には、システムの状態を操作処理が実行される前の状態に戻すメソッドを呼び出すことができる。これにより、障害発生時にロールバックすることができるため、障害が発生した場合であってもシステムの状態を障害発生前の状態に戻すことができる。

また、ロールバック処理を行う共有メソッドを定義した共有オブジェクトを登録することで、オブジェクトごとに障害発生時のロールバック処理を組み込む必要がなくなるため、開発者の作業負担を軽減させることができ、障害発生時のデータの整合性を確保することができる。

なお、上述した実施形態は、単なる例示に過ぎず、実施形態に明示していない種々の変形や技術の適用を排除するものではない。すなわち、本発明は、その趣旨を逸脱しない範囲で様々な形態に変形して実施することができる。

最後に、上述した実施形態において説明した運用管理サーバ１は、図１に示す各要素を備えているが、運用管理サーバ１は、必ずしもこれら全ての要素を備える必要はない。例えば、運用管理サーバ１は、少なくとも、更新処理実行部１２と、第１異常終了判定部１３と、第１ロールバック部１５と、操作処理実行部２１と、第２異常終了判定部２２と、第２ロールバック部２４と、を備えることとしてもよい。

１…運用管理サーバ、２…クライアント端末、１０…第１ロールバック実行部、１１…第１ロールバック要否判定部、１２…更新処理実行部、１３…第１異常終了判定部、１４…データ判定部、１５…第１ロールバック部、２０…第２ロールバック実行部、２１…操作処理実行部、２１…異常終了判定部、２２…第２異常終了判定部、２３…第２ロールバック要否判定部、２４…第２ロールバック部、３０…オブジェクト記憶部。

Claims (6)

1. オブジェクト指向プログラミング言語を使用したアプリケーションの運用を管理する運用管理サーバであって、
   データの更新を伴う第１のメソッドの呼び出し要求を受信した場合に、当該更新の対象となる更新前データを取得するメソッドを呼び出して当該更新前データを取得した後、前記第１のメソッドを呼び出して当該第１のメソッドに対応する更新処理を実行する更新処理実行手段と、
   前記更新処理が異常終了したか否かを判定する第１の異常終了判定手段と、
   前記第１の異常終了判定手段によって前記更新処理が異常終了したと判定された場合に、前記更新処理の対象となっているデータを前記更新前データに戻すメソッドを呼び出す第１のロールバック手段と、
   データの更新を伴わない第２のメソッドの呼び出し要求を受信した場合に、当該第２のメソッドを呼び出して当該第２のメソッドに対応する操作処理を実行する操作処理実行手段と、
   前記操作処理が異常終了したか否かを判定する第２の異常終了判定手段と、
   前記第２の異常終了判定手段によって前記操作処理が異常終了したと判定された場合に、当該操作処理が実行される前の状態に戻すメソッドを呼び出す第２のロールバック手段と、
   を備えることを特徴とする運用管理サーバ。
2. 前記第１のメソッドの呼び出し要求を受信した場合に、当該第１のメッソッドに対応する更新処理がロールバックを要する処理であるか否かを判定する第１のロールバック要否判定手段を、さらに備え、
   前記更新処理実行手段は、前記第１のロールバック要否判定手段によって前記更新処理がロールバックを要する処理であると判定された場合に、当該更新処理の対象となる更新前データを取得するメソッドを呼び出して当該更新前データを取得し、
   前記第１のロールバック手段は、前記第１のロールバック要否判定手段によって前記更新処理がロールバックを要する処理であると判定され、かつ、前記第１の異常終了判定手段によって前記更新処理が異常終了したと判定された場合に、前記更新処理の対象となっているデータを前記更新前データに戻すメソッドを呼び出す
   ことを特徴とする請求項１記載の運用管理サーバ。
3. 前記第１の異常終了判定手段によって前記更新処理が異常終了したと判定された場合に、前記更新処理の対象になっていた更新データを取得するメソッドを呼び出して当該更新データを取得し、当該取得した更新データが、前記更新処理実行手段によって取得された前記更新前データと異なるか否かを判定するデータ判定手段を、さらに備え、
   前記第１のロールバック手段は、前記データ判定手段によって前記更新データが前記更新前データと異なると判定された場合に、前記更新処理の対象となっているデータを前記更新前データに戻すメソッドを呼び出すことを特徴とする請求項１または２記載の運用管理サーバ。
4. 前記第２の異常終了定手段によって前記操作処理が異常終了したと判定された場合に、当該操作処理がロールバックを要する処理であるか否かを判定する第２のロールバック要否判定手段を、さらに備え、
   前記第２のロールバック手段は、前記第２のロールバック要否判定手段によって、前記操作処理がロールバックを要する処理であると判定された場合に、当該操作処理が実行される前の状態に戻すメソッドを呼び出すことを特徴とする請求項１〜３のいずれか1項に記載の運用管理サーバ。
5. オブジェクト指向プログラミング言語を使用したアプリケーションの運用を管理するサーバで実行されるロールバック実行方法であって、
   データの更新を伴う第１のメソッドの呼び出し要求を受信した場合に、当該更新の対象となる更新前データを取得するメソッドを呼び出して当該更新前データを取得した後、前記第１のメソッドを呼び出して当該第１のメソッドに対応する更新処理を実行する更新処理実行ステップと、
   前記更新処理が異常終了したか否かを判定する第１の異常終了判定ステップと、
   前記更新処理が異常終了したと判定された場合に、前記更新処理の対象となっているデータを前記更新前データに戻すメソッドを呼び出す第１のロールバックステップと、
   データの更新を伴わない第２のメソッドの呼び出し要求を受信した場合に、当該第２のメソッドを呼び出して当該第２のメソッドに対応する操作処理を実行する操作処理実行ステップと、
   前記操作処理が異常終了したか否かを判定する第２の異常終了判定ステップと、
   前記操作処理が異常終了したと判定された場合に、当該操作処理が実行される前の状態に戻すメソッドを呼び出す第２のロールバックステップと、
   を含むことを特徴とするロールバック実行方法。
6. 請求項５に記載の各ステップをコンピュータに実行させるためのロールバック実行プログラム。

Images