JP5385545B2 - トランザクションの実行を制御する装置及び方法 - Google Patents

Description

本発明は、トランザクションの実行を制御する装置及び方法に関する。特に、本発明は、複数のプロバイダにより提供される処理をリクエスタの要求に応じて行う複数のトランザクションの実行を制御する装置及び方法に関する。

複数の処理を組み合わせて実現される１つのトランザクションにおいて、既に成立しているトランザクションを取り消して（ＵＮＤＯして）再実行する（ＲＥＤＯする）こと（以下、「ＵＮＤＯ／ＲＥＤＯ」という）が必要になる場合がある。例えば、顧客自身の間違いや事務プロセスの入力ミス等、過去の事務プロセスに間違いがあったことに気が付いてそれを修正しようとする場合である。
このようなトランザクションの取消しや再実行については、従来から、種々の技術が提案されている（例えば、特許文献１〜３参照）。

特許文献１では、ログデータを回復単位（ＵＲ）及び機能（ＢＥＧＩＮ、ＣＯＭＭＩＴ、ＡＢＯＲＴ、ＥＮＤ、ＲＥＤＯ、ＵＮＤＯ）で区分してトランザクション回復流（ＴＲＳ）に記録し、ＵＲの状態変化（ＣＯＭＭＩＴ／ＡＢＯＲＴ）に応答してＴＲＳの所定のＵＲ区分のログデータの部分集合（ＲＥＤＯ又はＵＮＤＯ）を資源回復流（ＲＲＳ）にマッピングし、ＵＲの状態変化の終了時にＲＲＳを使用して所定のＵＲ区分に関連する全てのログデータをＴＲＳから消去している。

特許文献２では、回復中に障害が発生すると、予め設定された数の補償動作の後、現在走査している動作記録のシーケンス番号を含むＮｅｘｔＵｎｄｏＶＳＮ記録をログに書き込み、障害後、ログを後ろ向きに走査しているときに、ＮｅｘｔＵｎｄｏＶＳＮ記録からその記録に含まれるシーケンス番号を有する動作記録までを無視している。

特許文献３では、分散トランザクション処理システムを構成する全ての分散トランザクション処理装置がアクセスできるログファイルに、トランザクション処理の進捗状況を示すログデータを記録し、他の分散トランザクション処理装置に障害が発生した場合に、ログファイルに記録されたログデータを用いて、障害が発生した分散トランザクション処理装置に関係するトランザクションの障害回復処理を行い、障害からの回復後に、ログファイルに記録されたログデータを用いて、障害により中断したローカルトランザクションの処理を継続している。

尚、トランザクションに含まれる処理の一例であるＤＢ更新に関する技術としては、共有データに対する更新結果は更新記憶装置に書き込み、その間、共有データに対する参照操作は、共有記憶装置上の１つ前のバージョンの共有データに対して実行することで、ロック機構を不要とする技術（例えば、特許文献４参照）や、トランザクションのグループの総体として構成される大域トランザクションを連鎖階層のセットとして処理し、大域トランザクションのアトミック実行を保証する技術（例えば、特許文献５参照）がある。

また、ＵＮＤＯやＲＥＤＯに関する技術としては、ユーザインターフェースオブジェクトの開発者が、アンドゥ情報の生成及び追跡に責任をもたなくてよいように、アンドゥ情報を自動的に生成し追跡する技術（例えば、特許文献６参照）がある。

特開昭６３−１０２５２号公報 特開平９−２０４３３８号公報 ＷＯ２００４／０５５６７４号公報 特開平８−２３５０４６号公報 特開平１０−６９４１８号公報 特開２００５−１８７７４号公報

しかしながら、これらの特許文献に記載の何れの技術も、複数のプロバイダにより提供される処理をリクエスタの要求に応じて行う環境でＵＮＤＯ／ＲＥＤＯを実現する手段は提供していない。

本発明の目的は、複数のプロバイダにより提供される処理をリクエスタの要求に応じて行う環境でＵＮＤＯ／ＲＥＤＯを可能とすることにある。

かかる目的のもと、本発明は、複数のプロバイダにより提供される処理をリクエスタの要求に応じて行う複数のトランザクションの実行を制御する装置であって、リクエスタは、複数のトランザクションの各々における処理の要求先のプロバイダを示す第１の履歴情報を記憶する第１の記憶部と、複数のトランザクションのうちの特定のトランザクションの再実行の要求があると、第１の履歴情報に基づいて、特定のトランザクションよりも後に実行されたトランザクションの各々における処理の要求先のプロバイダを特定する特定部と、特定部により特定された要求先のプロバイダに対して、特定のトランザクションよりも後に実行されたトランザクションの各々において要求した処理の取消しを指示する取消し指示部とを備え、複数のプロバイダの各々は、複数のトランザクションの各々におけるリクエスタの要求に応じて処理を行う前の状態を示す第２の履歴情報を記憶する第２の記憶部と、取消し指示部により取消しが指示されると、第２の履歴情報に基づいて、特定のトランザクションよりも後に実行されたトランザクションの各々におけるリクエスタの要求に応じて行った処理を取り消す取消し部とを備えた、装置を提供する。

また、この装置において、第１の記憶部は、複数のトランザクションの各トランザクションに関する第１の履歴情報を、各トランザクションを識別する第１の識別情報と、各トランザクションの前及び後の何れかに実行されたトランザクションを識別する第２の識別情報とに関連付けて記憶し、特定部は、第１の識別情報と第２の識別情報とに基づいて、特定のトランザクションよりも後に実行されたトランザクションを特定する、ものであってもよい。この場合、リクエスタは、複数のトランザクションのうちの一のトランザクションを識別する第３の識別情報を取得する取得部と、一のトランザクションにおける処理の要求を第３の識別情報と共に要求先のプロバイダに送信する送信部とを更に備え、複数のプロバイダの各々は、処理の要求を第３の識別情報と共にリクエスタから受信する受信部と、他のトランザクションを識別する第４の識別情報が処理の対象に関連付けて記憶され、他のトランザクションが処理を完了した旨が第４の識別情報に関連付けて記憶されている場合に、処理を行い、第３の識別情報を処理の対象に関連付けて記憶し、処理が終了すると、一のトランザクションが処理を完了した旨を第３の識別情報に関連付けて記憶する処理部とを更に備えた、ものであってもよい。

更に、この装置において、第１の記憶部は、複数のトランザクションの各トランザクションに関する第１の履歴情報を、各トランザクションを識別し、かつ、各トランザクションの順序を特定可能な識別情報に関連付けて記憶し、特定部は、識別情報に基づいて、特定のトランザクションよりも後に実行されたトランザクションを特定する、ものであってもよい。

そして、この装置において、リクエスタは、特定部により特定された要求先のプロバイダに対して、特定のトランザクションよりも後に実行されたトランザクションの各々において要求した処理の再実行を指示する再実行指示部を更に備え、複数のプロバイダの各々は、再実行指示部により再実行が指示されると、特定のトランザクションよりも後に実行されたトランザクションの各々におけるリクエスタの要求に応じて行った処理を、要求以外の要求に応じて行った処理との間の順序関係が損なわれないように再実行する再実行部を更に備えた、ものであってもよい。この場合、第２の記憶部は、複数のトランザクションの各トランザクションに関する第２の履歴情報を、各トランザクションを識別する第１の識別情報と、各トランザクションの前及び後の何れかに実行されたトランザクションを識別する第２の識別情報とに関連付けて記憶し、再実行部は、第１の識別情報と第２の識別情報とに基づいて、特定のトランザクションよりも後に実行されたトランザクションの各々におけるリクエスタの要求に応じて行った処理と、要求以外の要求に応じて行った処理との間の順序関係を特定する、ものであってもよい。また、第２の記憶部は、複数のトランザクションの各トランザクションに関する第２の履歴情報を、各トランザクションを識別し、かつ、各トランザクションの順序を特定可能な識別情報に関連付けて記憶し、再実行部は、識別情報に基づいて、特定のトランザクションよりも後に実行されたトランザクションの各々におけるリクエスタの要求に応じて行った処理と、要求以外の要求に応じて行った処理との間の順序関係を特定する、ものであってもよい。
更に、処理は、複数のプロバイダの各々が保持するデータベースを更新する処理であり、第２の履歴情報は、データベースの更新前イメージを含む、ものであってもよい。

また、本発明は、複数のプロバイダにより提供される処理をリクエスタの要求に応じて行う複数のトランザクションの実行を制御する方法であって、リクエスタには、複数のトランザクションの各々における処理の要求先のプロバイダを示す第１の履歴情報が記憶されており、複数のプロバイダの各々には、複数のトランザクションの各々におけるリクエスタの要求に応じて処理を行う前の状態を示す第２の履歴情報が記憶されており、リクエスタが、複数のトランザクションのうちの特定のトランザクションの再実行の要求があると、第１の履歴情報に基づいて、特定のトランザクションよりも後に実行されたトランザクションの各々における処理の要求先のプロバイダを特定するステップと、リクエスタが、特定した要求先のプロバイダに対して、特定のトランザクションよりも後に実行されたトランザクションの各々において要求した処理の取消しを指示するステップと、複数のプロバイダの各々が、取消しが指示されると、第２の履歴情報に基づいて、特定のトランザクションよりも後に実行されたトランザクションの各々におけるリクエスタの要求に応じて行った処理を取り消すステップとを含む、方法も提供する。

更に、本発明は、複数のプロバイダにより提供される処理をリクエスタの要求に応じて行う複数のトランザクションの実行を制御する装置としてコンピュータを機能させるプログラムであって、コンピュータを、複数のトランザクションの各々における処理の要求先のプロバイダを示す履歴情報を記録する記録部と、複数のトランザクションのうちの特定のトランザクションの再実行の要求があると、履歴情報に基づいて、特定のトランザクションよりも後に実行されたトランザクションの各々における処理の要求先のプロバイダを特定する特定部と、特定部により特定された要求先のプロバイダに対して、特定のトランザクションよりも後に実行されたトランザクションの各々において要求した処理の取消しを指示する取消し指示部として機能させる、プログラムも提供する。

更にまた、本発明は、複数のプロバイダにより提供される処理をリクエスタの要求に応じて行う複数のトランザクションの実行を制御する装置であって、リクエスタは、複数のトランザクションの各トランザクションの第１のトランザクションＩＤと、各トランザクションの直前に実行されたトランザクションの第２のトランザクションＩＤと、各トランザクションにおける処理の要求先のプロバイダのプロバイダＩＤとを含む履歴情報を記憶する第１の履歴情報記憶部と、最新のトランザクションの最新トランザクションＩＤを管理する管理情報を記憶する第１の管理情報記憶部と、複数のトランザクションのうちの特定のトランザクションの再実行の要求があると、最新トランザクションＩＤを第１のトランザクションＩＤとして含む履歴情報を出発点として、第２のトランザクションＩＤを第１のトランザクションＩＤとして含む履歴情報を、特定のトランザクションのトランザクションＩＤを第１のトランザクションＩＤとして含む履歴情報まで辿りながら、特定のトランザクションよりも後に実行されたトランザクションの各々における処理の要求先のプロバイダのプロバイダＩＤを特定する特定部と、特定部により特定されたプロバイダＩＤのプロバイダに対して、特定のトランザクションよりも後に実行されたトランザクションの各々において要求した処理の取消しを指示する取消し指示部と、特定部により特定されたプロバイダＩＤのプロバイダに対して、特定のトランザクションよりも後に実行されたトランザクションの各々において要求した処理の再実行を指示する再実行指示部とを備え、複数のプロバイダの各々は、複数のトランザクションの各トランザクションにおけるリクエスタの要求に応じた処理のログの第１のログＩＤと、処理の直前の処理のログの第２のログＩＤと、処理を行ったトランザクションの第３のトランザクションＩＤと、処理を行う前の状態を示す状態情報とを含む履歴情報を記憶する第２の履歴情報記憶部と、最新のログの最新ログＩＤを管理する管理情報を記憶する第２の管理情報記憶部と、取消し指示部により取消しが指示されると、最新ログＩＤを第１のログＩＤとして含む履歴情報を出発点として、第２のログＩＤを第１のログＩＤとして含む履歴情報を、特定のトランザクションのトランザクションＩＤを第３のトランザクションＩＤとして含む履歴情報まで辿りながら、状態情報を用いて、特定のトランザクションよりも後に実行されたトランザクションの各々におけるリクエスタの要求に応じて行った処理を取り消す取消し部と、再実行指示部により再実行が指示されると、特定のトランザクションよりも後に実行されたトランザクションの各々におけるリクエスタの要求に応じて行った処理を、処理を行ったトランザクションのトランザクションＩＤよりも古いトランザクションＩＤのトランザクションで要求以外の要求に応じて行った処理を再実行した後に再実行する再実行部とを備えた、装置も提供する。

本発明によれば、複数のプロバイダにより提供される処理をリクエスタの要求に応じて行う環境でＵＮＤＯ／ＲＥＤＯが可能となる。

以下、添付図面を参照して、本発明を実施するための最良の形態（以下、「実施の形態」という）について詳細に説明する。
本実施の形態では、データベース（以下、「ＤＢ」という）の更新を含む複数のウェブサービスを組み合わせてトランザクションの一例である１つの業務プロセスを実現するアプリケーションを考える。このようなアプリケーションが原子性（Atomicity）を持つ場合、全てのウェブサービスを２ＰＣ（２フェーズコミット）のスコープに置かなくてはならない。ここで、原子性とは、当業者にはよく知られているように、互いに独立した複数のプロバイダサーバシステムの各々が提供する複数の独立したウェブサービスが実行したＤＢ更新が、全て成立するか、全て失われるか、の何れかであることを意味する。後続のウェブサービスで障害が発生し、ＤＢ更新が完結できなければ、先行するウェブサービスによって既に実行済みのＤＢ更新は全て取り消さなくてはならない。しかし、高い信頼性を求められる基幹系事務システムでは、次のような幾つかの理由から、一般的には２ＰＣの方式は採用されない。

１）一般にリクエスタは高い信頼性／整合性を求められるようなＤＢを保有しない。そのため、高い可用性と永続的な整合性を求められるＤＢを保有するプロバイダに比べて、相対的に信頼性の低いシステム設計／システム運用しか実現できていない。２ＰＣの採用は、トータルシステムとしての信頼性が、リクエスタと複数のプロバイダの中で最も「低い」信頼性になることを意味する。即ち、あるシステムがその低い信頼性のためにスローダウンを引き起こし、業務プロセスの処理時間が著しく遅延すると、その影響は他の全てのリクエスタ／プロバイダに波及する。例えば、全てのシステムにおいてＤＢレコードのロックの開放が著しく遅延し、そのロックの開放を待つ全ての業務プロセスを待たせることになる。また、各プロバイダによって引き起こされたスローダウンは更にそのプロバイダのサービスを要求する全てのリクエスタにも波及する。リクエスタに高い信頼性を保証しなくてはならないプロバイダにとって、このような信頼性を脅かす脅威を潜在的に持つ２ＰＣの設計は容易には受容できない。

２）２ＰＣでは、スコープ内の全てのウェブサービスが完了するまで、各プロバイダは、更新したＤＢレコードのロックを開放できず、コミットまでロックを保持し続けなくてはならない。そのため、一般に、ロック保持時間が長くなり、デッドロックが発生しやすくなる。通常、ＤＢＭＳ（DB Management System）は、デッドロック検知の仕組みを持っており、デッドロックの発生を速やかに検出する。そして、デッドロックの当事者の一方を強制的に異常終了させることによってシステム全体のスローダウンを防止する。しかし、互いに独立したプロバイダシステム間で発生するデッドロックは、各々が独自のＤＢＭＳを保有しているため、検出することができない。従って、一般的には、ロック保持時間の上限値（タイムアウト値）を設定し、その上限値を超えてロックを保持したウェブサービスをタイムアウトとして強制終了させることになる。ところが、広範なスコープを持つ２ＰＣの業務プロセスを持つシステムでは、他のプロバイダでの処理時間を考慮しなくてはならないため、このようなタイムアウト値の設定は非常に困難である。そこで、現実的には、非常に大きなタイムアウト値を設定せざるをえない。これにより、デッドロックは長時間放置されることになり、たった１つのデッドロックがシステム全体のスローダウンを引き起こす脅威となる。

このような課題を解決するため、本実施の形態は、次のような構成を備える。
図１は、本実施の形態における業務プロセス実行制御装置１００の構成を示したブロック図である。本実施の形態における業務プロセス実行制御装置１００は、リクエスタ１０と、プロバイダ２０ａ，２０ｂ，２０ｃ，…と、ＧＢＰＩＤサーバ３０とから構成される。

このうち、リクエスタ１０は、エンドユーザから業務プロセスの要求を受け取り、複数のウェブサービスを組み合わせて、その要求を実現する。このリクエスタ１０は、所謂フロントエンドサーバに相当するものであり、ＳＯＡ（Service Oriented Architecture）における「サービスリクエスタ」である。

プロバイダ２０ａ，２０ｂ，２０ｃ，…は、リクエスタ１０からの要求に従って、ウェブサービスを実行する。このプロバイダ２０ａ，２０ｂ，２０ｃ，…は、所謂バックエンドサーバに相当するものであり、ＳＯＡにおける「サービスプロバイダ」である。尚、以降の説明で各プロバイダを区別する必要がない場合は、「プロバイダ２０」と表記する。また、図では、３つのプロバイダ２０を示したが、プロバイダ２０の数はこれに限られるものではない。

ＧＢＰＩＤサーバ３０は、業務プロセスの要求ごとに採番される識別情報であるＧＢＰＩＤ（Global Business Process ID）に関する処理を実現するサーバである。全てのリクエスタ１０、プロバイダ２０と接続し、要求を処理する。ここで、ＧＢＰＩＤの採番は昇順とする。例えば、タイムスタンプの利用が考えられる。但し、厳密には昇順である必要はなく、複数のリクエスタ１０／プロバイダ２０に跨ってユニークであればよい。尚、このＧＢＰＩＤサーバ３０は、汎用のサーバコンピュータで実現するとよい。

次に、本実施の形態における業務プロセス実行制御装置１００の概略動作を説明する。尚、ここでは、保険契約に関する業務プロセスを例として説明する。
図２は、業務プロセス実行制御装置１００の概略動作を説明するための図である。図において、リクエスタ１０内には、左側から右側へ向けて、リクエスタ１０が行うべき処理を時系列に示しており、それに対応する下段の位置に各処理に対応するサービスを実行するプロバイダ２０又はＧＢＰＩＤサーバ３０を示している。従って、２つのＧＢＰＩＤサーバ３０が示されているが、これらは同じＧＢＰＩＤサーバ３０であり、処理内容の違いに応じて２つ図示したに過ぎない。そして、プロバイダ２０としては、契約管理を行うプロバイダ２０ａと、顧客管理を行うプロバイダ２０ｂとを示している。

また、図２には、図１に示さなかった構成要素も示しているので、これについて説明する。
まず、プロバイダ２０ａは、ログＤＢ２１ａと、契約ＤＢ２９ａとを備える。更に、図面作成の都合上、プロバイダ２０ａの枠外に示しているが、ＩＤ対応ＤＢ２００ａも備える。ログＤＢ２１ａは、後述する更新取消処理等のためにＤＢの更新前イメージを保存するＤＢである。契約ＤＢ２９ａは、業務ＤＢの一例であり、契約に関するデータを保存するＤＢである。ＩＤ対応ＤＢ２００ａは、各ＧＢＰＩＤに関する「更新前ログ」のログＩＤを管理するＤＢである。また、プロバイダ２０ｂは、ログＤＢ２１ｂと、顧客ＤＢ２９ｂとを備える。更に、図面作成の都合上、プロバイダ２０ｂの枠外に示しているが、ＩＤ対応ＤＢ２００ｂも備える。ログＤＢ２１ｂは、ログＤＢ２１ａと同様、後述する更新取消処理等のためにＤＢの更新前イメージを保存するＤＢである。顧客ＤＢ２９ｂは、業務ＤＢの一例であり、顧客に関するデータを保存するＤＢである。ＩＤ対応ＤＢ２００ｂは、各ＧＢＰＩＤに関する「更新前ログ」のログＩＤを管理するＤＢである。尚、図では、プロバイダ２０ａ、２０ｂに対応して、ログＤＢ２１ａ、２１ｂ、及び、ＩＤ対応ＤＢ２００ａ、２００ｂを示したが、以降の説明で各ログＤＢを区別する必要がない場合は、「ログＤＢ２１」、「ＩＤ対応ＤＢ２００」と表記する。

次に、ＧＢＰＩＤサーバ３０は、図面作成の都合上、枠外に示しているが、同期点管理ＤＢ３１を備える。同期点管理ＤＢ３１は、同じ業務プロセスにおける複数のＤＢ更新を１つの「業務同期点」として取り扱うためのＤＢである。「業務同期点」を識別するためにＧＢＰＩＤを用いている。つまり、ＤＢレコードではなく、ＧＢＰＩＤごとに、コミット／ロールバックの状態を管理する。

プロバイダ２０ａ、プロバイダ２０ｂ、ＧＢＰＩＤサーバ３０がこれらのＤＢを有することを前提として、本実施の形態では、次のような概略動作を行う。
まず、リクエスタ１０は、ＧＢＰＩＤサーバ３０からＧＢＰＩＤを入手する（Ａ）。図において、ＧＢＰＩＤサーバ３０は、ＧＢＰＩＤ「１００１」、「１００２」、「１００３」を採番しており、これらのＧＢＰＩＤが「実行中」というステータスと共に同期点管理ＤＢ３１に記録されている。尚、ステップＡでは、このうちＧＢＰＩＤ「１００１」を入手したものとする。

次に、リクエスタ１０は、各プロバイダ２０に対して、ウェブサービスを依頼する。その際、ウェブサービスの実行に使用するＧＢＰＩＤを各プロバイダ２０に通知する。
これにより、各プロバイダ２０は、全てのＤＢの更新に当たって、ＤＢレコードの例えば先頭にＧＢＰＩＤを埋め込んで、そのＧＢＰＩＤを持つ業務プロセスが、ＤＢレコードを「更新実行中」或いは「更新をロールバック中」或いは「更新をコミット済み」であることを示す。この３つのステータスの何れであるかは、同期点管理ＤＢ３１に記録されている。尚、この場合において、プロバイダ２０において同一の業務プロセス内の同一のＧＢＰＩＤを持つ複数のウェブサービスがフロー上並行処理されることが想定されれば、同一ＧＢＰＩＤ内での枝番をＧＢＰＩＤの後ろに付加した、ウェブサービスごとにユニークなＩＤをＧＢＰＩＤの代わりに埋め込んで、同一の業務プロセス内の複数のウェブサービスの処理順序を正確に管理できるようにする必要がある。以降の説明では、特に混乱が生じない限り、このＧＢＰＩＤと枝番の組み合わせからなるＩＤも単にＧＢＰＩＤと表記する。
但し、このとき、ステータスが「実行中」や「ロールバック」のＧＢＰＩＤを持つＤＢレコードは使用しない。つまり、ＤＢレコードはコミットされていなければ使用しないが、コミットされているかどうかは、同期点管理ＤＢ３１を見れば分かる。更新しようとするＤＢレコードに埋め込まれたＧＢＰＩＤのステータスが「実行中」や「ロールバック」になっている状況が生じた場合、コミットになるまで待ち、デッドロック回避のため、一定時間経過後にタイムアウトを返す方法と、トランザクションを異常終了させる方法（タイムアウトと同様に扱う方法）とがある。
また、各プロバイダ２０は、ウェブサービスの処理中に発生した全てのＤＢ更新をコミット後も取り消せるように、ＤＢレコードの更新前イメージをログＤＢ２１に書き出しておく。

図の例では、次の３つのウェブサービスを依頼する。
第一に、リクエスタ１０は、医療特約追加をプロバイダ２０ａに依頼する。このとき、ＧＢＰＩＤ「１００１」もプロバイダ２０ａに通知する（Ｂ）。すると、プロバイダ２０ａは、ＧＢＰＩＤ「１００１」を契約ＤＢ２９ａのレコードに埋め込み、ＤＢレコードの更新前イメージをログＩＤ＃１のログデータとしてログＤＢ２１ａに書き出す（Ｃ）。尚、ＧＢＰＩＤ「１００１」とログＩＤ＃１との対応は、ＩＤ対応ＤＢ２００ａに記録しておく。そして、プロバイダ２０ａは、全ての処理が正常終了した時点で、サービスをコミットし、ＤＢレコードのロックを全て開放する。

第二に、顧客ＤＢ更新データ生成をプロバイダ２０ａに依頼する。このとき、ＧＢＰＩＤ「１００１」もプロバイダ２０ａに通知する（Ｄ）。すると、プロバイダ２０ａは、ＩＤ対応ＤＢ２００ａからＧＢＰＩＤ「１００１」に対応するログＩＤ＃１を特定し、ログＤＢ２１ａ内のログＩＤ＃１のログデータに基づいて、顧客ＤＢ更新データを生成する。そして、これをリクエスタ１０に戻す。そして、プロバイダ２０ａは、全ての処理が正常終了した時点で、サービスをコミットし、ＤＢレコードのロックを全て開放する。

第三に、顧客ＤＢ更新をプロバイダ２０ｂに依頼する。このとき、ＧＢＰＩＤ「１００１」もプロバイダ２０ｂに通知する（Ｅ）。すると、プロバイダ２０ｂは、ＧＢＰＩＤ「１００１」を顧客ＤＢ２９ｂのレコードに埋め込み、ＤＢレコードの更新前イメージをログＩＤ＃２のログデータとしてログＤＢ２１ｂに書き出す（Ｆ）。尚、ＧＢＰＩＤ「１００１」とログＩＤ＃２との対応は、ＩＤ対応ＤＢ２００ｂに記録しておく。そして、プロバイダ２０ｂは、全ての処理が正常終了した時点で、サービスをコミットし、ＤＢレコードのロックを全て開放する。

リクエスタ１０は、全てのウェブサービスが正常に終了し、業務プロセスを完了できると判断した時点で、該当するＧＢＰＩＤを「コミット状態」にするようＧＢＰＩＤサーバ３０に指示する（Ｇ）。図では既に、ＧＢＰＩＤ「１００２」が「コミット状態」というステータスと共に同期点管理ＤＢ３１に記録されているが、この時点で、ＧＢＰＩＤ「１００１」も「コミット状態」というステータスと共に同期点管理ＤＢ３１に記録される。

ところで、本実施の形態では、前述の通り、各プロバイダ２０が、ＤＢレコードの参照／更新の際に常にＧＢＰＩＤの状況をチェックし、「コミット状態」にないＧＢＰＩＤを持つＤＢレコードの参照処理／更新処理を行わないようにしている。
このように、ＧＢＰＩＤのチェックは、基本的には全てのＤＢアクセスについて実施する必要があるものである。しかしながら、ＤＢレコードにアクセスする都度、同期点管理ＤＢ３１を参照していては、パフォーマンスが低下するという問題点が出てくる。

そこで、本実施の形態では、次のような構成も採用可能にしている。
図３は、業務プロセス実行制御装置１００の概略動作の変形例を説明するための図である。
図では、リクエスタ１０がステップＧで行ったＧＢＰＩＤサーバ３０への指示により、ＧＢＰＩＤ「１００２」に加え、ＧＢＰＩＤ「１００１」も「コミット状態」になると、同期点管理ＤＢ３１に「１００３未満はコミット済み」という情報が記録される。尚、図では、これを「＜１００３ ｃｏｍｍｉｔ」と簡略化して示している。こうすることにより、各プロバイダ２０は、メモリ上に「実行中」になっている最小のＧＢＰＩＤであるＯＰＧＩＤ（Oldest Pending GBPID）を保持することができる。そして、ＯＰＧＩＤより小さいＧＢＰＩＤであれば、コミットされていると判断し、ＯＰＧＩＤより大きなＧＢＰＩＤである場合にのみ、同期点管理ＤＢ３１を参照して、コミットされているかどうかを判断することができる。

一方、ウェブサービスの実行中に何らかの障害が発生したとする。この場合、ロールバックを行うことになるが、そのときの概略動作を説明する。
図４は、業務プロセス実行制御装置１００におけるロールバック時の概略動作を説明するための図である。尚、図には、３つのＧＢＰＩＤサーバ３０が示されているが、図２と同様、これらは同じＧＢＰＩＤサーバ３０である。
図において、ステップＡ〜Ｆは、図２で説明したものと同様である。但し、この図では、ステップＦで顧客ＤＢ２９ｂを更新する際に障害が発生したものとする。すると、プロバイダ２０は、ロールバック処理を行い、ロックを開放すると共に、リクエスタ１０にサービスが実行されなかったことを通知する。リクエスタ１０は、障害の通知を受けると、該当するＧＢＰＩＤを「ロールバック状態」にするようＧＢＰＩＤサーバ３０に指示する（Ｈ）。図では、ＧＢＰＩＤ「１００１」が「ロールバック状態」というステータスと共に同期点管理ＤＢ３１に記録されている。

その後、リクエスタ１０は、既に完了している全てのウェブサービスについて、ＤＢ更新を取り消すよう、更新取消処理を起動する（Ｉ）。各プロバイダ２０は、更新取消を依頼されると、例えばログＤＢ２１に保管してあるＤＢレコードの更新前イメージでＤＢを更新する等の方法により、ＤＢを更新前の状態に戻す。この場合、各プロバイダ２０は、「ロールバック状態」になっているＧＢＰＩＤを見つけると、自分でログＤＢ２１を用いて更新前イメージに戻し、処理を継続する。具体的には、ＩＤ対応ＤＢ２００から必要なログＩＤを入手し、そのログＩＤに対応する更新前イメージでレコードを置き換える。このとき、同じＧＢＰＩＤで異なるサービスが同一レコードを更新する場合の更新取消を想定して、ログＩＤの逆順（ＧＢＰＩＤ＋枝番の降順）にログを用いて更新前イメージに戻す必要がある。これにより、ＤＢレコード上のＧＢＰＩＤは、以前の古いＧＢＰＩＤに戻る。図では、プロバイダ２０ａ及びプロバイダ２０ｂが更新取消を指示されており、ＧＢＰＩＤ「１００１」がＧＢＰＩＤ「０８３３」に戻されている。そして、全てのプロバイダ２０における更新取消が完了すると、該当するＧＢＰＩＤを「コミット状態」にするようＧＢＰＩＤサーバ３０に指示する（Ｊ）。更新取消指示直後、ＧＢＰＩＤ「１００１」は「ロールバック状態」というステータスと共に同期点管理ＤＢ３１に記録されていたが、更新取消完了後は、「コミット状態」というステータスと共に同期点管理ＤＢ３１に記録されることになる。

以上述べたように、本実施の形態では、サービスの処理終了時に直ちにコミット／ロールバックを実行し、ロックを開放する。従って、２ＰＣの場合のように、他のリクエスタ１０、プロバイダ２０の処理に引きずられて、ロック保持時間が遅延することはなく、冒頭で述べたような問題は発生しない。
また、コミットされたＤＢレコードであっても、ＧＢＰＩＤごとに管理される状態情報が「コミット状態」にならない限り、参照／更新はされないことが保証される。従って、ＤＢの更新前ログを用いた更新取消処理が常に成立し、業務プロセス全体の大域的なデータの原子性も達成できる。
更に、ＤＢレコードごと或いはウェブサービスごとにコミット／ロールバックを管理するのではなく、それらを包括したＧＢＰＩＤごとにコミット／ロールバックを管理するだけでよいため、仕組みが単純化できる。
更にまた、ＧＢＰＩＤの状態を、リクエスタ１０やプロバイダ２０から独立したＧＢＰＩＤサーバ３０で一括管理するため、リクエスタ１０やプロバイダ２０の間に新たな依存関係は発生せず、各システムに閉じた実装だけで、複雑な大域的なデータの原子性を達成できる。具体的には、リクエスタ１０やプロバイダ２０の数が増大したり、プロバイダ２０が複数の企業に跨ったりしたとしても、ＧＢＰＩＤサーバ３０を共有する限り、実装は変わらない。また、ＧＢＰＩＤサーバ３０の信頼性が十分に高ければ、リクエスタ１０やプロバイダ２０の信頼性が低下することはない。

尚、ＧＢＰＩＤの採番は、特定のプロバイダ２０が提供するウェブサービスとして実装することも考えられる。最も簡単なＧＢＰＩＤの採番方法は、そのプロバイダ２０のタイムスタンプをＧＢＰＩＤとして返すことである。但し、ＧＢＰＩＤのユニーク性を保証するためには、同じタイムスタンプ値が発生した場合に、そのタイムスタンプ値に異なる枝番を付与する等の工夫が必要となる。また、大量の採番が必要となる場合は、ウェブサービスの並列処理化を図る必要も出てくる。この場合、採番プロセスごとにユニークな採番プロセスＩＤを付与し、タイムスタンプ値と枝番と採番プロセスＩＤとの組合せをＧＢＰＩＤとすることによって、並列処理される採番プロセス間でのＧＢＰＩＤの重複を避けることができる。このように採番プロセスＩＤを付与すると、極めて短い時間の間に発生した業務プロセスの間で、ＧＢＰＩＤの逆転が発生する可能性があるが、本実施の形態では、その程度の逆転で不具合は発生しない。

ところで、上述したような複数のＤＢ更新を含むウェブサービスを組み合わせて１つの業務プロセスを実現するアプリケーションでは、次のような問題により、ＵＮＤＯ／ＲＥＤＯの実装が困難であった。

１）１つの業務プロセスは、実際には、リクエスタとは独立した複数のプロバイダがＤＢ更新を伴うサービスを行うことにより実現されている。各プロバイダは、複数のリクエスタからの要求に応じてサービスを実行しているため、あるリクエスタだけではＵＮＤＯ／ＲＥＤＯを行うべき全てのウェブサービスを把握できない。また、あるプロバイダは、１つの業務プロセスに含まれる他のプロバイダによって実行されているＵＮＤＯ／ＲＥＤＯを行うべき全てのウェブサービスを把握できない。従って、どのシステムも、ＵＮＤＯ／ＲＥＤＯを実行することができない。

２）ＵＮＤＯ／ＲＥＤＯの対象となる業務プロセスは、実行した順序とは逆の順序でＵＮＤＯし、実行した順序でＲＥＤＯしなくてはならない。この順序は正確でなくてはならない。プロセスの順序の把握は、１つのシステムで業務プロセスが実行される場合は容易であるが、複数のプロバイダに分散して業務プロセスが実行される場合は容易ではない。例えば、あるプロバイダでは、業務プロセスＡに含まれるサービスのほうが業務プロセスＢよりも先に実行されたが、別のプロバイダでは、業務プロセスＢに含まれるサービスのほうが業務プロセスＡよりも先に実行される場合がある。このような場合は、どの順番でＵＮＤＯ／ＲＥＤＯを行っても何れかのプロバイダでは実行順序が誤ることになるので、正しいＵＮＤＯ／ＲＥＤＯを実行できない。

このような課題を解決するため、本実施の形態では、次のような構成を設ける。
１）リクエスタ側では、業務プロセスの実行履歴（以下、「業務プロセス履歴」という）をとり、各プロバイダでは、サービスの実行履歴（以下、「サービス履歴」という）をとる。そして、各プロバイダがサービス履歴に基づいてＵＮＤＯを実行する。また、リクエスタが、業務プロセス履歴に基づいて、順次業務プロセスのＲＥＤＯを実行する。業務プロセスがＲＥＤＯされると、各プロバイダにはサービスが要求されることになる。各プロバイダは、要求されたサービスを実行する前に、サービス履歴を参照し、それ以前に他のリクエスタから要求されたサービスがあればそれらのＲＥＤＯを実行し、その後で要求されたサービスを実行する。このような設計によって、リクエスタとプロバイダが協調して、全てのリクエスタ／プロバイダで整合のとれたＵＮＤＯ／ＲＥＤＯを実現することができる。

２）先に述べたように、全てのリクエスタは、業務プロセスの要求ごとにプロバイダに跨る昇順のＧＢＰＩＤを付与し、サービスの実行に使用するＧＢＰＩＤを各プロバイダに通知する。各プロバイダは、全てのＤＢの更新に当たって、ＤＢレコードにこのＧＢＰＩＤを埋め込む。リクエスタは、業務プロセスが正常に完了すると、該当するＧＢＰＩＤを「コミット状態」にする。また、各プロバイダは、ＤＢレコードの参照／更新の際に常にＧＢＰＩＤの状況をチェックし、「コミット状態」にないＧＢＰＩＤを持つＤＢレコードは処理しないものとする。このような仕組みを取ることによって、何れかのプロバイダの何れかのＤＢレコードで競合が発生する業務プロセスの実行を逐次化することが可能となる。このＧＢＰＩＤをキーとして処理順序に従った逆方向チェインを作ることによって、ＵＮＤＯ／ＲＥＤＯすべき業務プロセス／サービスの間で整合性のとれた処理順序を確定することができる。

このようなＵＮＤＯ／ＲＥＤＯについて、複数の保険契約に加入している契約者の例を用いて説明する。
図５（ａ）は、このような例を模式的に示した図である。尚、この例では、ＵＮＤＯ／ＲＥＤＯを契約者単位に行うものとし、契約者ＩＤをＵＮＤＯ／ＲＥＤＯのキーとしている。尚、図中、ｃ＃は、各契約者の契約者ＩＤを表すシンボルである。また、ｐ＃１〜ｐ＃４は、各保険の契約番号を表すシンボルである。例えば、ｐ＃１は、この契約者の終身保険の契約番号を示し、ｐ＃２は、この契約者の医療保険の契約番号を示している。

また、図５（ｂ）は、保険契約に関する業務プロセスの一例を示す。
図示するように、処理Ａｘで終身保険の変更を行い、処理Ｂｘでログデータから入力メッセージを生成し、処理Ｃｚで顧客ＤＢを更新する。また、処理Ｄｘで医療保険の変更を行い、処理Ｅｘでログデータから入力メッセージを生成し、処理Ｆｚで顧客ＤＢを更新する。更に、処理Ｇｙで傷害保険の変更を行い、処理Ｈｙでログデータから入力メッセージを生成し、処理Ｉｚで顧客ＤＢを更新する。尚、各処理を表す記号の２文字目が、その処理を提供するプロバイダ２０を示している。具体的には、Ａ，Ｂ，Ｃ，Ｄはプロバイダ２０ｘが、Ｇ，Ｈはプロバイダ２０ｙが、Ｃ，Ｆ，Ｉはプロバイダ２０ｚが提供するウェブサービスである。つまり、終身保険及び医療保険をプロバイダ２０ｘが、傷害保険をプロバイダ２０ｙが、顧客管理をプロバイダ２０ｚが処理することになる。

尚、この例では、各契約処理の結果によって、顧客ＤＢを更新する入力メッセージの内容が異なるものとしている。そこで、ログデータを用いて入力メッセージを生成している。ここで、ログデータとは、先に述べたログＤＢ２１に保管されたデータである。そして、詳細は後述するが、ログＤＢ２１には、入出力メッセージや業務ＤＢの更新前／更新後イメージ等、あるトランザクションに関連したログデータが保管されており、そのログデータを用いて、入出力メッセージの復元又はＤＢ更新のＵＮＤＯができるものとする。
また、図中、顧客ＤＢは、契約者ＩＤをキーとするＤＢの一例である。尚、契約ごとのＵＮＤＯ／ＲＥＤＯを行うためには、契約ごとに顧客ＤＢ更新トランザクションが分割されていることが必要である。

次に、図５に示した業務プロセスにおけるＵＮＤＯ／ＲＥＤＯの概略動作について説明する。
図６は、ＵＮＤＯ／ＲＥＤＯの概略動作を示した図である。図示するように、リクエスタ１０は業務プロセス履歴ＤＢを持ち、プロバイダ２０ｘ，２０ｙ，２０ｚは、それぞれ、サービス履歴ＤＢ２１ｘ，２１ｙ，２１ｚを持つ（サービス履歴ＤＢ２１はログＤＢ２１と同じ）。そして、ＵＮＤＯ／ＲＥＤＯは、リクエスタ１０が業務プロセス履歴に基づいて、ＵＮＤＯ／ＲＥＤＯのプロセスフローを制御することによって行われる。

即ち、リクエスタ１０は、図示するように、ＧＢＰＩＤ「１００１」、契約者ＩＤ「４４２」のＤＢ更新を修正して再実行する（修正ＲＥＤＯする）処理を起動する。これにより、リクエスタ１０は、「フロー制御」の枠内に示すようなフローに従い、プロバイダ２０ｘ，２０ｙ，２０ｚにＵＮＤＯ／ＲＥＤＯを指示する。
即ち、第１ステップとして、リクエスタ１０は、修正ＲＥＤＯのＧＢＰＩＤを採番する。
次に、第２ステップとして、リクエスタ１０は、関連する全てのプロバイダ２０にＵＮＤＯを要求する。ここでは、プロバイダ２０ｘ，２０ｙ，２０ｚがサービスを提供することにより業務プロセスが実行されているので、プロバイダ２０ｘ，２０ｙ，２０ｚに対して、ＵＮＤＯを要求している。尚、暗黙のうちに他のプロバイダ２０に派生することがないことを前提とする。つまり、例えば、あるプロバイダ２０が別のプロバイダ２０にウェブサービスを依頼し、依頼されたプロバイダ２０が何らかのＤＢ更新をしたにも関わらず、そのＤＢ更新がなされたことをリクエスタ１０が知らない、という状況は生じないものとする。

また、第３ステップとして、リクエスタ１０は、ＧＢＰＩＤ「１００１」の保険変更処理の内容を変更し、修正ＲＥＤＯする。
そして、第４、第５ステップとして、リクエスタ１０は、ＧＢＰＩＤ「１００１」以降のプロセスのＲＥＤＯを各プロバイダ２０に対して順次要求する。
更に、全てのＲＥＤＯが完了すると、第６ステップとして、コミットする。

ここで、本実施の形態におけるリクエスタ１０が保持するＤＢの構造について説明する。尚、この例では、ＵＮＤＯ／ＲＥＤＯを契約単位に行うものとし、契約番号をＵＮＤＯ／ＲＥＤＯのキーとする。
図７（ａ）は、業務プロセス履歴ＤＢ１１及び最新ＧＢＰＩＤＤＢ１２の構造例を示した図である。
まず、最新ＧＢＰＩＤＤＢ１２は、契約者ＩＤと契約番号の組み合わせごとに、最後に成立したＧＢＰＩＤだけを保管している。例えば、契約者ＩＤ「ｃ＃１」、契約番号「ｐ＃１」に対しては、ＧＢＰＩＤ「１３４２」が最後に成立しており、契約者ＩＤ「ｃ＃１」、契約番号「ｐ＃２」に対しては、ＧＢＰＩＤ「１９２８」が最後に成立したことが記録されている。図６では、契約者ＩＤごとにＵＮＤＯ／ＲＥＤＯを行うようこととしたが、図７（ａ）では、契約番号ごとにＵＮＤＯ／ＲＥＤＯを行うこととしているため、契約者ＩＤと契約番号の組み合わせごとにＧＢＰＩＤを記憶するようにしている。尚、図中、契約者ＩＤ「ｃ＃１」に対する契約番号と、契約者ＩＤ「ｃ＃２」に対する契約番号とに、同じ「ｐ＃１」が記録されているが、これは、特定の種類の保険契約（この場合は、終身保険）の契約番号であることを示しているに過ぎず、契約番号自体が同じであることを意味するものではない。

また、業務プロセス履歴ＤＢ１１は、業務プロセスの実行ごとの履歴である業務プロセス履歴を記録する。ここで、業務プロセス履歴は、ＧＢＰＩＤをキーとして、入出力メッセージ等を保管する。尚、入力メッセージには、サービスを依頼したプロバイダ２０の識別子（例えば、プロバイダ名）も含まれる。また、業務プロセス履歴は、契約者ＩＤと契約番号の組み合わせに対する１つの前の更新を行ったＧＢＰＩＤも保持する。これが逆方向ポインタとして機能し、全ての業務プロセス履歴を逆順に辿ることができる。尚、現在のＧＢＰＩＤの１つ前のＧＢＰＩＤは、最新ＧＢＰＩＤＤＢ１２から入手できる。
例えば、契約者ＩＤ「ｃ＃１」、契約番号「ｐ＃１」のレコードは、最後にＧＢＰＩＤ「１３４２」で更新されており、その前にＧＢＰＩＤ「１３４４」で更新されており、更にその前にＧＢＰＩＤ「１００１」で更新されている。このように、処理順序は、最新ＧＢＰＩＤＤＢ１２からの逆方向チェインによって保証される。

但し、上述したＧＢＰＩＤ「１３４２」とＧＢＰＩＤ「１３４４」の関係のように、ＧＢＰＩＤは逆転することもある。つまり、あるレコードが、あるＧＢＰＩＤで更新された後に、それよりも小さなＧＢＰＩＤで更新されることが起こり得る。
図７（ｂ）に、このときの状況について示す。
図において、上段はＧＢＰＩＤ「１３４２」のライフサイクルを、下段はＧＢＰＩＤ「１３４４」のライフサイクルを示す。この場合、ＧＢＰＩＤ「１３４４」で先に契約ＤＢの契約番号「ｐ＃１」のレコードが更新されている。これにより、図中、太矢印で示す期間は、前述したＧＢＰＩＤの排他制御機能により、契約ＤＢの契約番号「ｐ＃１」のレコードが更新されないことが保証される。即ち、ＧＢＰＩＤ「１３４４」についてコミットされた後に、ＧＢＰＩＤ「１３４２」で契約ＤＢの契約番号「ｐ＃１」のレコードが更新される。従って、ＧＢＰＩＤは逆転しているものの、逆方向チェインが正しい処理順序を示している。尚、ここでは、各業務プロセス履歴に１つ前のＧＢＰＩＤを含めたが、１つ後のＧＢＰＩＤを含めるようにしてもよい。

また、本実施の形態におけるプロバイダ２０が保持するＤＢの構造について説明する。尚、この例でも、ＵＮＤＯ／ＲＥＤＯを契約単位に行うものとし、契約番号をＵＮＤＯ／ＲＥＤＯのキーとする。また、ここでは、ウェブサービスの依頼時に受け渡されたＧＢＰＩＤをそのままログＩＤとしても用いるものとする。
図８（ａ）は、ログＤＢ２１及び最新ログＩＤＤＢ２２の構造例を示した図である。
まず、最新ログＩＤＤＢ２２は、契約者ＩＤと契約番号の組み合わせごとに、最後に成立したログＩＤだけを保管している。例えば、契約者ＩＤ「ｃ＃１」、契約番号「ｐ＃１」に対しては、ログＩＤ「１３４２」が最後に成立しており、契約者ＩＤ「ｃ＃１」、契約番号「ｐ＃２」に対しては、ログＩＤ「１９２８」が最後に成立したことが記録されている。但し、顧客ＤＢについては、契約者ＩＤごとに、最後に成立したログＩＤを保管する。

また、ログＤＢ２１は、業務ＤＢの更新ごとのログであるログデータを記録する。ここで、ログデータは、ログＩＤをキーとして、入出力メッセージ、ＤＢ更新前イメージ、ＤＢ更新後イメージ等を保管する。また、ログＤＢ２１は、契約者ＩＤと契約番号の組み合わせに対する１つの前のＤＢ更新に関するログＩＤも保持する。これが逆方向ポインタとして機能し、全てのログデータを逆順に辿ることができる。尚、現在のログＩＤの１つ前のログＩＤは、最新ログＩＤＤＢ２２から入手できる。
例えば、契約者ＩＤ「ｃ＃１」、契約番号「ｐ＃１」のレコードは、最後にログＩＤ「１３４２」のログデータに示されるように更新されており、その前にログＩＤ「１３４４」のログデータに示されるように更新されており、その前にログＩＤ「１００１」のログデータに示されるように更新されている。このように、処理順序は、最新ログＩＤＤＢ２２からの逆方向チェインによって保証される。

但し、上述したログＩＤ「１３４２」ログＩＤ「１３４４」の関係のように、ログＩＤは逆転することもある。つまり、あるレコードの更新が、あるログＩＤのログデータとして記録された後に、それよりも小さなログＩＤのログデータとして記録されることが起こり得る。
図８（ｂ）に、このときの状況について示す。
図において、上段はＧＢＰＩＤ「１３４２」のライフサイクルを、下段はＧＢＰＩＤ「１３４４」のライフサイクルを示す。この場合、ＧＢＰＩＤ「１３４４」で先に契約ＤＢの契約番号「ｐ＃１」のレコードが更新されている。これにより、図中、太矢印で示す期間は、前述したＧＢＰＩＤの排他制御機能により、契約ＤＢの契約番号「ｐ＃１」のレコードが更新されないことが保証される。即ち、ＧＢＰＩＤ「１３４４」についてコミットされた後に、ＧＢＰＩＤ「１３４２」で契約ＤＢの契約番号「ｐ＃１」のレコードが更新される。従って、ＧＢＰＩＤが逆転し、その結果、ログＩＤも逆転しているものの、逆方向チェインが正しい処理順序を示している。尚、ここでは、ログデータに１つ前のログＩＤを含めたが、１つ後のログＩＤを含めるようにしてもよい。

ところで、上記説明では、プロバイダ２０がリクエスタ１０からＧＢＰＩＤを受け取った時点で、ＧＢＰＩＤとログＩＤが同じになるように、ログＩＤを決めるものとした。この場合、ＧＢＰＩＤが大きくなると、ログＩＤも大きくなる。これに対し、ログＤＢ２１を更新する時点でログＩＤを採番するような構成も考えられる。この場合、ＧＢＰＩＤ「１３４２」に対応するログＩＤは、ＧＢＰＩＤ「１３４４」に対応するログＩＤよりも後で採番されるため大きくなる。つまり、ログＩＤは逆転していないことになるので、上記の「ログＩＤは逆転することもある」というのは、一般的には、「ログＤＢ２１を更新する順序はＧＢＰＩＤの昇順にならないこともある」ということを意味している。尚、このように、ログＩＤとしてＧＢＰＩＤと異なる値を用いても、ＧＢＰＩＤがＤＢ更新後イメージに含まれているため、各プロバイダ２０はログＤＢ２１から、ＤＢ更新を行った業務プロセスのＧＢＰＩＤを容易に把握できる。

また、ログＤＢ２１には、バッチ処理の場合も、ログデータを記録する必要がある。但し、バッチ処理に対しては、ＧＢＰＩＤは取得されていない。従って、ＲＥＤＯを行えるように、入力データを入力メッセージの代わりにログデータに含める必要がある。

以下、本実施の形態における業務プロセス実行制御装置１００について更に詳細に説明する。尚、以降の説明では、ＵＮＤＯ／ＲＥＤＯの対象を「オブジェクト」と称し、オブジェクトを一意に識別する識別情報を「オブジェクトＩＤ」と称する。つまり、図７、８における契約番号は、この「オブジェクトＩＤ」の一例である。

まず、本実施の形態における業務プロセス実行制御装置１００の機能構成について説明する。
図９は、リクエスタ１０及びプロバイダ２０の機能構成例を示したブロック図である。
図示するように、まず、リクエスタ１０は、業務プロセス履歴ＤＢ１１と、最新ＧＢＰＩＤＤＢ１２と、履歴管理部１３と、制御部１４と、プロバイダ特定部１５とを備える。また、ＵＮＤＯ情報生成部１７と、ＲＥＤＯ情報生成部１８と、送信部４１と、受信部４２とを備える。

業務プロセス履歴ＤＢ１１は、図７（ａ）で説明したように、業務プロセスの実行ごとの履歴である業務プロセス履歴を記録したデータベースである。本実施の形態では、処理の要求先のプロバイダを示す第１の履歴情報の一例として、業務プロセス履歴を用い、第１の履歴情報を記憶する第１の記憶部の一例として、業務プロセス履歴ＤＢ１１を設けている。
最新ＧＢＰＩＤＤＢ１２は、図７（ａ）で説明したように、オブジェクトごとに、そのオブジェクトを最後に更新した業務プロセスのＧＢＰＩＤを記録したデータベースである。
履歴管理部１３は、業務プロセス履歴ＤＢ１１及び最新ＧＢＰＩＤＤＢ１２を管理する。

制御部１４は、リクエスタ１０の全体動作を制御する。
プロバイダ特定部１５は、ウェブサービスを依頼するに当たり、ウェブサービスを依頼すべきプロバイダ２０を業務プロセス定義に基づいて特定する。また、ＵＮＤＯ／ＲＥＤＯに当たり、ウェブサービスを依頼したプロバイダ２０を業務プロセス履歴に基づいて特定する。本実施の形態では、処理の要求先のプロバイダを特定する特定部の一例として、プロバイダ特定部１５を設けている。
ＵＮＤＯ情報生成部１７は、ＵＮＤＯに必要となる情報を生成する。本実施の形態では、処理の取消しを指示する取消し指示部の一例として、ＵＮＤＯ情報生成部１７を設けている。
ＲＥＤＯ情報生成部１８は、ＲＥＤＯに必要となる情報を生成する。本実施の形態では、処理の再実行を指示する再実行指示部の一例として、ＲＥＤＯ情報生成部１８を設けている。

送信部４１は、ウェブサービスやＵＮＤＯ／ＲＥＤＯの依頼をプロバイダ２０に送信する。また、ＧＢＰＩＤの採番や状態の変更の要求をＧＢＰＩＤサーバ３０に送信する。本実施の形態では、処理の要求を第３の識別情報と共に送信する送信部の一例として、送信部４１を設けている。
受信部４２は、ウェブサービスが成功したかどうかをプロバイダ２０から受信する。また、採番されたＧＢＰＩＤをＧＢＰＩＤサーバ３０から受信する。本実施の形態では、第３の識別情報を取得する取得部の一例として、受信部４２を設けている。

また、プロバイダ２０は、ログＤＢ２１と、最新ログＩＤＤＢ２２と、履歴管理部２３と、制御部２４と、ログＩＤ取得部２５と、ＤＢ更新部２６とを備える。また、ＵＮＤＯ処理部２７と、ＲＥＤＯ処理部２８と、送信部５１と、受信部５２とを備える。

ログＤＢ２１は、図８（ａ）で説明したように、業務ＤＢの更新ごとのログであるログデータを記録したデータベースである。本実施の形態では、処理を行う前の状態を示す第２の履歴情報の一例として、ログデータを用い、第２の履歴情報を記憶する第２の記憶部の一例として、ログＤＢ２１を設けている。
最新ログＩＤＤＢ２２は、図８（ａ）で説明したように、オブジェクトごとに、そのオブジェクトの最後の更新を記録したログデータのログＩＤを記録したデータベースである。
履歴管理部２３は、ログＤＢ２１及び最新ログＩＤＤＢ２２を管理する。

制御部２４は、プロバイダ２０の全体動作を制御する。
ログＩＤ取得部２５は、業務ＤＢの更新を記録するログデータの識別情報であるログＩＤを取得する。
ＤＢ更新部２６は、リクエスタ１０からのウェブサービスの依頼に応じて業務ＤＢを更新する。その際、更新対象のＤＢレコードにＧＢＰＩＤを埋め込む。本実施の形態では、他のトランザクションを識別する第４の識別情報が処理の対象に関連付けて記憶され、他のトランザクションが処理を完了した旨が第４の識別情報に関連付けて記憶されている場合に、処理を行い、第３の識別情報を処理の対象に関連付けて記憶し、処理が終了すると、一のトランザクションが処理を完了した旨を第３の識別情報に関連付けて記憶する処理部の一例として、ＤＢ更新部２６を設けている。
ＵＮＤＯ処理部２７は、リクエスタ１０からの要求に応じてＵＮＤＯを実行する。本実施の形態では、処理を取り消す取消し部の一例として、ＵＮＤＯ処理部２７を設けている。
ＲＥＤＯ処理部２８は、リクエスタ１０からの要求に応じてＲＥＤＯを実行する。本実施の形態では、処理を再実行する再実行部の一例として、ＲＥＤＯ処理部２８を設けている。

送信部５１は、ウェブサービスが成功したかどうかをリクエスタ１０に送信する。また、ＧＢＰＩＤの状態の問い合わせメッセージをＧＢＰＩＤサーバ３０に送信する。
受信部５２は、ウェブサービスやＵＮＤＯ／ＲＥＤＯの依頼をリクエスタ１０から受信する。また、ＧＢＰＩＤの状態の問い合わせ結果をＧＢＰＩＤサーバ３０から受信する。本実施の形態では、処理の要求を第３の識別情報と共に受信する受信部の一例として、受信部５２を設けている。

次に、本実施の形態における業務プロセス実行制御装置１００の動作について説明する。尚、この動作の説明においては、ログＩＤとして、ＧＢＰＩＤと異なる値を用いるものとする。
まず、業務プロセスの要求を処理するときのリクエスタ１０の動作について説明する。
図１０は、このときのリクエスタ１０の動作例を示したフローチャートである。
リクエスタ１０では、まず、受信部４２が、エンドユーザからのオブジェクトＩＤを指定した業務プロセスの実行要求を、例えば、図示しないＨＴＴＰサーバを介して受信し、制御部１４に伝える（ステップ１０１）。そして、制御部１４は、ＧＢＰＩＤの取得要求の送信を送信部４１に指示する。すると、送信部４１は、ＧＢＰＩＤを採番してその状態を「実行中」とする旨の要求をＧＢＰＩＤサーバ３０に送信する（ステップ１０２）。これにより、ＧＢＰＩＤサーバ３０は、ＧＢＰＩＤを採番し、同期点管理ＤＢ３１にそのＧＢＰＩＤの状態情報として「実行中」を記録する。一方、受信部４２は、ＧＢＰＩＤサーバ３０からＧＢＰＩＤを受信して制御部１４に受け渡す（ステップ１０３）。

次に、制御部１４は、プロバイダ特定部１５に対して、ウェブサービスの依頼先のプロバイダ２０を特定するよう指示する。すると、プロバイダ特定部１５は、業務プロセス定義に基づいて、ウェブサービスの依頼先のプロバイダ２０を特定し、プロバイダ名を制御部１４に受け渡す（ステップ１０４）。そして、制御部１４は、受信部４２から受け取ったＧＢＰＩＤと、先に受信部４２から受け取ったオブジェクトＩＤと、プロバイダ特定部１５から受け取ったプロバイダ名と、ウェブサービスの依頼内容である入力メッセージとを送信部４１に伝えて、ウェブサービスの依頼の送信を指示する。すると、送信部４１は、ＧＢＰＩＤとオブジェクトＩＤと入力メッセージとを含むウェブサービスの依頼を、指定されたプロバイダ名のプロバイダ２０に送信する（ステップ１０５）。

その後、リクエスタ１０では、受信部４２がプロバイダ２０からの情報を受信し、これを制御部１４に伝える。そして、制御部１４は、その情報がウェブサービスの成功を示すものかどうかを判定する（ステップ１０６）。
ここで、情報がウェブサービスの成功を示すものであれば、制御部１４は、履歴管理部１３に対して、業務プロセス履歴ＤＢ１１及び最新ＧＢＰＩＤＤＢ１２の更新を指示する。このとき、制御部１４は、履歴管理部１３に対して、受信部４２がステップ１０３で受信したＧＢＰＩＤと、ウェブサービスの対象のオブジェクトＩＤと、プロバイダ２０との間で交換した入力／出力メッセージと、プロバイダ特定部１５がステップ１０４で取得したプロバイダ名とを受け渡しておく。すると、履歴管理部１３は、次のような動作を行う。

即ち、まず、履歴管理部１３は、最新ＧＢＰＩＤＤＢ１２を参照して、オブジェクトＩＤに対応付けられたＧＢＰＩＤを取得する（ステップ１０７）。尚、ステップ１０３で取得したＧＢＰＩＤが最新のＧＢＰＩＤなので、このステップ１０７で取得されるＧＢＰＩＤは１つ前のＧＢＰＩＤということになる。
次に、履歴管理部１３は、制御部１４から渡されたＧＢＰＩＤと、同じく制御部１４から渡されたオブジェクトＩＤと、ステップ１０７で取得した１つ前のＧＢＰＩＤと、入力／出力メッセージと、制御部１４から渡されたプロバイダ名とを対応付けて、業務プロセス履歴ＤＢ１１に記録する（ステップ１０８）。そして、制御部１４に制御を戻す。

その後、制御部１４は、業務プロセス定義に基づいて、依頼すべきウェブサービスが他にあるかどうかを判定する（ステップ１０９）。そして、他にあると判定されれば、ステップ１０４に戻って、同様の処理を繰り返す。また、他にないと判定されれば、依頼したウェブサービスが全て成功したことになるので、履歴管理部１３にＧＢＰＩＤを渡して最新ＧＢＰＩＤＤＢ１２の更新を指示する。すると、履歴管理部１３は、制御部１４から渡されたＧＢＰＩＤを、１つ前のＧＢＰＩＤに代えて、最新ＧＢＰＩＤＤＢ１２に記録する（ステップ１１０）。そして、制御部１４は、ＧＢＰＩＤのコミット状態への変更指示の送信を送信部４１に指示する。すると、送信部４１は、ＧＢＰＩＤをコミット状態にする旨の指示をＧＢＰＩＤサーバ３０に送信する（ステップ１１３）。

一方、ステップ１０６で、情報がウェブサービスの失敗を示すものであれば、制御部１４は、ＧＢＰＩＤのロールバック状態への変更指示及び更新取消の送信を送信部４１に指示する。すると、送信部４１は、ＧＢＰＩＤをロールバック状態にする旨の指示を、ＧＢＰＩＤサーバ３０に指示する（ステップ１１１）。そして、このＧＢＰＩＤに関してこれまでに行った更新を取り消すよう、該当するプロバイダ２０に指示する（ステップ１１２）。

次に、業務プロセスの要求を処理するときのプロバイダ２０の動作について説明する。
図１１は、このときのプロバイダ２０の動作例を示したフローチャートである。
プロバイダ２０では、まず、受信部５２が、リクエスタ１０から、ＧＢＰＩＤとオブジェクトＩＤとを伴うウェブサービスの依頼を受信し、制御部２４に伝える（ステップ２０１）。そして、制御部２４は、ログＩＤ取得部２５に対してログＩＤの取得を指示し、ログＩＤ取得部２５が、プロバイダ２０内で一意に採番されたログＩＤを取得して制御部２４に受け渡す（ステップ２０２）。

次に、制御部２４は、ＤＢを更新する場合は、更新対象の業務ＤＢのレコードに埋め込まれたＧＢＰＩＤの状態の判定指示の送信を送信部５１に指示する。すると、送信部５１は、業務ＤＢのレコードに埋め込まれたＧＢＰＩＤの状態をＧＢＰＩＤサーバ３０に問い合わせ、問い合わせ結果を制御部２４に伝える（ステップ２０３）。そして、制御部２４は、送信部５１から受け取った問い合わせ結果に基づいて、ＧＢＰＩＤがコミット状態であるかどうかを判定する（ステップ２０４）。

ここで、ＧＢＰＩＤがコミット状態であると判定されれば、業務ＤＢのレコードは更新可能なので、制御部２４は、受信部５２から受け取ったＧＢＰＩＤをＤＢ更新部２６に渡して、業務ＤＢのレコードの更新を指示する。すると、ＤＢ更新部２６は、次のような動作を行う。
即ち、まず、ＤＢ更新部２６は、業務ＤＢのレコードをロックする（ステップ２０５）。次に、受信部５２から渡されたＧＢＰＩＤをそのレコードに埋め込んで、ウェブサービスの実行に基づく業務ＤＢの更新を行う（ステップ２０６）。そして、制御部２４に業務ＤＢの更新前イメージ／更新後イメージを返す。

その後、制御部２４は、履歴管理部２３に対して、ログＤＢ２１及び最新ログＩＤＤＢ２２の更新を指示する。このとき、制御部２４は、履歴管理部２３に対して、ログＩＤ取得部２５がステップ２０２で取得したログＩＤと、受信部５２から渡されたオブジェクトＩＤと、同じく受信部５２から渡されたＧＢＰＩＤと、ＤＢ更新部２６から渡された更新前／更新後イメージとを受け渡しておく。すると、履歴管理部２３は、次のような動作を行う。

即ち、まず、履歴管理部２３は、最新ログＩＤＤＢ２２を参照して、オブジェクトＩＤに対応付けられたＧＢＰＩＤを取得する（ステップ２０７）。尚、ステップ２０２で取得したログＩＤが最新のログＩＤなので、このステップ２０７で取得されるログＩＤは１つ前のログＩＤということになる。
次に、履歴管理部２３は、制御部２４から渡されたログＩＤと、同じく制御部２４から渡されたＧＢＰＩＤと、同じく制御部２４から渡されたオブジェクトＩＤと、ステップ２０７で取得した１つ前のＧＢＰＩＤと、制御部２４から渡された更新前／更新後イメージとを対応付けて、ログＤＢ２１に記録する（ステップ２０８）。そして、制御部２４に制御を戻す。

その後、制御部２４は、ウェブサービスの内容に基づいて、更新すべき業務ＤＢが他にあるかどうかを判定する（ステップ２０９）。そして、他にあると判定されれば、ステップ２０３に戻って、同様の処理を繰り返す。また、他にないと判定されれば、更新すべき業務ＤＢを全て更新したことになるので、履歴管理部２３にログＩＤを渡して最新ログＩＤＤＢ２２の更新を指示する。すると、履歴管理部２３は、制御部２４から渡されたログＩＤを、１つ前のログＩＤに代えて、最新ログＩＤＤＢ２２に記録する（ステップ２１０）。そして、制御部２４は、ウェブサービスをコミットし、業務ＤＢのレコードにかけていたロックを開放する（ステップ２１１）。そして、制御部２４は、ウェブサービスの正常終了通知の送信を送信部５１に指示し、送信部５１が、ウェブサービスの正常終了をリクエスタ１０に通知する（ステップ２１２）。

一方、ステップ２０４で、ＧＢＰＩＤがコミット状態でないと判定されれば、制御部２４は、ウェブサービスの異常終了通知の送信を送信部５１に指示し、送信部５１が、ウェブサービスの異常終了をリクエスタ１０に通知する（ステップ２１３）。

次いで、特定のＧＢＰＩＤで実行された業務プロセスを修正ＲＥＤＯするときのリクエスタ１０の動作について説明する。
図１２は、このときのリクエスタ１０の動作例を示したフローチャートである。
リクエスタ１０では、まず、受信部４２が、エンドユーザからのオブジェクトＩＤ、ＧＢＰＩＤ、修正ＲＥＤＯ内容を伴う修正ＲＥＤＯ要求を、例えば、図示しないＨＴＴＰサーバを介して受信し、制御部１４に伝える（ステップ１２１）。そして、制御部１４は、履歴管理部１３にオブジェクトＩＤを伝えて、そのオブジェクトＩＤで特定されるオブジェクトに関して成立した最新のＧＢＰＩＤの取得を指示する。すると、履歴管理部１３は、最新ＧＢＰＩＤＤＢ１２を参照して、指定されたオブジェクトＩＤに対応する最新のＧＢＰＩＤを特定する（ステップ１２２）。

次に、履歴管理部１３は、ステップ１２２で特定したＧＢＰＩＤを有する業務プロセス履歴を、業務プロセス履歴ＤＢ１１から読み出し、制御部１４に受け渡す（ステップ１２３）。すると、制御部１４は、受け渡された業務プロセス履歴が、修正ＲＥＤＯ要求で指定されたＧＢＰＩＤを有するものかどうかを判定する（ステップ１２４）。
ここで、修正ＲＥＤＯ要求で指定されたＧＢＰＩＤを有するものでないと判定された場合、その業務プロセス履歴は、修正ＲＥＤＯすべきＧＢＰＩＤの業務プロセスの後に実行された業務プロセスの履歴である。従って、制御部１４は、読み出した業務プロセス履歴をＵＮＤＯ情報生成部１７及びＲＥＤＯ情報生成部１８に渡して、ＵＮＤＯ情報生成部１７にはＵＮＤＯを行うための情報の生成を指示し、ＲＥＤＯ情報生成部１８にはＲＥＤＯを行うための情報の生成を指示する。すると、ＵＮＤＯ情報生成部１７及びＲＥＤＯ情報生成部１８は、次のような動作を行う。

即ち、まず、ＵＮＤＯ情報生成部１７は、制御部１４から渡された業務プロセス履歴からＵＮＤＯを依頼すべきプロバイダ２０のプロバイダ名を取得し、ＵＮＤＯ配列に追加する（ステップ１２５）。また、ＲＥＤＯ情報生成部１８は、制御部１４から渡された業務プロセス履歴からＧＢＰＩＤ、オブジェクトＩＤ、入力メッセージを取得し、ＲＥＤＯ配列の先頭に記憶する（ステップ１２６）。そして、制御部１４に制御を戻す。

その後、制御部１４は、業務プロセス履歴を参照して、１つ前のＧＢＰＩＤを特定する（ステップ１２７）。そして、ＧＢＰＩＤが特定できたかどうかを判定する（ステップ１２８）。
その結果、１つ前のＧＢＰＩＤを特定できたと判定された場合、ステップ１２３に戻り、その特定されたＧＢＰＩＤについて、同様の処理を繰り返す。
一方、１つ前のＧＢＰＩＤを特定できなかったと判定された場合、業務プロセス履歴ＤＢ１１に記録されている最も古いＧＢＰＩＤの業務プロセス履歴に達したことになるので、修正ＲＥＤＯを行えない旨の情報の送信を送信部４１に指示し、送信部４１が、その旨の情報を例えばＨＴＴＰサーバを介して、エンドユーザに送信する（ステップ１２９）。

また、ステップ１２４で、修正ＲＥＤＯ要求で指定されたＧＢＰＩＤを有するものであると判定された場合、その業務プロセス履歴は、修正ＲＥＤＯすべきＧＢＰＩＤの業務プロセス履歴である。従って、制御部１４は、読み出した業務プロセス履歴をＵＮＤＯ情報生成部１７に渡して、ＵＮＤＯを行うための情報の生成を指示する。すると、ＵＮＤＯ情報生成部１７は、制御部１４から渡された業務プロセス履歴からＵＮＤＯを依頼すべきプロバイダ２０のプロバイダ名を取得し、ＵＮＤＯ配列に追加する（ステップ１３０）。そして、制御部１４に制御を戻す。
その後、制御部１４は、ＵＮＤＯ配列にプロバイダ名が含まれる全てのプロバイダ２０に対して、修正ＲＥＤＯ対象のＧＢＰＩＤと、オブジェクトＩＤとを指定して、ＵＮＤＯ依頼を行うよう、送信部４１に指示する。すると、送信部４１は、指示されたプロバイダ２０に対して、修正対象のＧＢＰＩＤと、オブジェクトＩＤとを指定して、ＵＮＤＯ依頼を送信する（ステップ１３１）。また、制御部１４は、ステップ１２１で受信した修正ＲＥＤＯ内容に基づく修正ＲＥＤＯ依頼の送信を送信部４１に指示する。すると、送信部４１は、該当するプロバイダ２０に修正ＲＥＤＯ依頼を送信する（ステップ１３２）。また、制御部１４は、ＲＥＤＯ配列の先頭から順にプロバイダ２０にＲＥＤＯを依頼するよう、送信部４１に指示する。すると、送信部４１は、ＲＥＤＯ配列に従い、該当するプロバイダ２０にＲＥＤＯ依頼を送信する（ステップ１３３）。

次に、特定のＧＢＰＩＤで実行された業務プロセスを修正ＲＥＤＯするときのプロバイダ２０の動作について説明する。このときのプロバイダ２０の動作は、ＵＮＤＯ依頼を受けた場合と、修正ＲＥＤＯ依頼を受けた場合と、ＲＥＤＯ依頼を受けた場合とで異なるので、これらを分けて説明する。
まず、リクエスタ１０からＵＮＤＯ依頼を受けた場合の動作について説明する。
図１３は、ＵＮＤＯ依頼を受けたときのプロバイダ２０の動作例を示したフローチャートである。
プロバイダ２０では、まず、受信部５２が、リクエスタ１０から、修正ＲＥＤＯ対象のＧＢＰＩＤとオブジェクトＩＤとを伴うＵＮＤＯ依頼を受信し、制御部２４に伝える（ステップ２２１）。そして、制御部２４は、履歴管理部２３にオブジェクトＩＤを伝えて、そのオブジェクトＩＤで特定されるオブジェクトに関して成立した最新のログＩＤの取得を指示する。すると、履歴管理部２３は、最新ログＩＤＤＢ２２を参照して、指定されたオブジェクトＩＤに対応する最新のログＩＤを特定する（ステップ２２２）。

次に、履歴管理部２３は、ステップ２２２で特定したログＩＤを有するログデータを、ログＤＢ２１から読み出し、制御部２４に受け渡す（ステップ２２３）。すると、制御部２４は、受け渡されたログデータが、ＵＮＤＯ依頼で指定されたＧＢＰＩＤを有するものかどうかを判定する（ステップ２２４）。
ここで、ＵＮＤＯ依頼で指定されたＧＢＰＩＤを有するものでないと判定された場合、そのログデータは、修正ＲＥＤＯすべきＧＢＰＩＤの業務プロセスの後に実行された業務プロセスに基づくログデータである。従って、制御部２４は、読み出したログデータをＵＮＤＯ処理部２７に渡して、ＵＮＤＯ処理を指示する。すると、ＵＮＤＯ処理部２７は、次のような動作を行う。

即ち、まず、制御部２４から渡されたログデータから更新前イメージを取得し、指定されたオブジェクトＩＤで特定されるオブジェクト、つまり、更新対象の業務ＤＢのレコードを更新前イメージで置き換える（ステップ２２５）。また、ログデータから入力メッセージを取得し、これを入力メッセージ配列の先頭に記憶する（ステップ２２６）。そして、制御部２４に制御を戻す。

その後、制御部２４は、ログデータを参照して、１つ前のログＩＤを特定する（ステップ２２７）。そして、ログＩＤが特定できたかどうかを判定する（ステップ２２８）。
その結果、１つ前のログＩＤを特定できたと判定された場合、ステップ２２３に戻り、その特定されたログＩＤについて、同様の処理を繰り返す。
一方、１つ前のログＩＤを特定できなかったと判定された場合、ログＤＢ２１に記録されている最も古いログＩＤのログデータに達したことになるので、ＵＮＤＯ処理を行えない旨の情報の送信を送信部５１に指示し、送信部５１が、その旨の情報をリクエスタ１０に送信する（ステップ２２９）。

また、ステップ２２４で、ＵＮＤＯ依頼で指定されたＧＢＰＩＤを有するものであると判定された場合、そのログデータは、修正ＲＥＤＯすべきＧＢＰＩＤの業務プロセスに基づくログデータである。従って、制御部２４は、読み出したログデータをＵＮＤＯ処理部２７に渡して、ＵＮＤＯ処理を指示する。すると、ＵＮＤＯ処理部２７は、制御部２４から渡されたログデータから更新前イメージを取得し、指定されたオブジェクトＩＤで特定されるオブジェクト、つまり、更新対象の業務ＤＢのレコードを更新前イメージで置き換える（ステップ２３０）。但し、この場合、ＲＥＤＯ処理は、リクエスタ１０から別途送られてくる修正ＲＥＤＯ依頼に応じて行うので、ＲＥＤＯのための準備処理は行わずに、処理を終了する。

次に、リクエスタ１０から修正ＲＥＤＯ依頼を受けた場合であるが、この場合のプロバイダ２０の動作は、通常のウェブサービス依頼に応じて行われる動作と変わらないので、ここでの詳細な説明は省略する。但し、修正ＲＥＤＯは、現在の日付ではなく、過去の日付で実行する必要がある。

次いで、リクエスタ１０からＲＥＤＯ依頼を受けた場合の動作について説明する。
図１４は、ＲＥＤＯ依頼を受けたときのプロバイダ２０の動作例を示したフローチャートである。
プロバイダ２０では、まず、受信部５２が、リクエスタ１０から、ＧＢＰＩＤ、オブジェクトＩＤ、入力メッセージを伴うＲＥＤＯ依頼を受信し、制御部２４に伝える（ステップ２４１）。そして、制御部２４は、図１３に示したＵＮＤＯ処理において生成した入力メッセージ配列を先頭から参照する（ステップ２４２）。但し、入力メッセージ配列に含まれるメッセージのうち、既にＲＥＤＯ処理に用いられたものは、入力メッセージ配列から削除されているものとする。この状態で、制御部２４は、入力メッセージ配列の先頭に、ステップ２４１で受信した入力メッセージよりも古いＧＢＰＩＤの入力メッセージがあるかどうかを判定する（ステップ２４３）。

その結果、古いＧＢＰＩＤの入力メッセージがなければ、制御部２４は、ＲＥＤＯ依頼に含まれる入力メッセージをＲＥＤＯ処理部２８に渡してＲＥＤＯ処理を指示する。すると、ＲＥＤＯ処理部２８は、制御部２４から渡された入力メッセージを用いてＲＥＤＯ処理を行う（ステップ２４５）。
一方、古いＧＢＰＩＤの入力メッセージがあれば、まず、制御部２４は、入力メッセージ配列に含まれる入力メッセージをＲＥＤＯ処理部２８に渡してＲＥＤＯ処理を指示する。すると、ＲＥＤＯ処理部２８は、制御部２４から渡された入力メッセージを用いてＲＥＤＯ処理を行う（ステップ２４４）。その後、制御部２４は、ＲＥＤＯ依頼に含まれる入力メッセージをＲＥＤＯ処理部２８に渡してＲＥＤＯ処理を指示する。すると、ＲＥＤＯ処理部２８は、制御部２４から渡された入力メッセージを用いてＲＥＤＯ処理を行う（ステップ２４５）。

尚、上記説明では、ログＤＢ２１及び最新ログＩＤＤＢ２２を更新する際、各ＤＢのレコードにＧＢＰＩＤを埋め込むかどうかには言及しなかったが、ログＤＢ２１のレコードにＧＢＰＩＤを埋め込む必要はない。但し、最新ログＩＤＤＢ２２のレコードには、他の業務ＤＢと同様に、ＧＢＰＩＤを埋め込むようにしてもよい。
また、本実施の形態を実装するに当たっては、ＲＥＤＯの処理がプロバイダ２０内に閉じて、他の（プロバイダ２０の）処理を起動しないようなアプリケーションの構造をとる必要がある。

ところで、本実施の形態では、各プロバイダ２０が提供する処理として、ＤＢ更新を想定した。しかしながら、各プロバイダ２０が提供する処理をＤＢ更新以外にまで拡張しても、本実施の形態は実現可能である。

以上述べたように、本実施の形態では、リクエスタが、業務プロセス履歴を記録し、各プロバイダが、ＤＢ更新のログデータを記録し、各プロバイダが、ログデータに基づいてＵＮＤＯを実行し、リクエスタが、業務プロセス履歴に基づいて順次業務プロセスのＲＥＤＯを実行するようにした。これにより、複数のＤＢ更新を含むウェブサービスを組み合わせて１つの業務プロセスを実現するアプリケーションにおいて、ＵＮＤＯ／ＲＥＤＯの実装が容易になった。

最後に、本実施の形態を適用するのに好適なコンピュータのハードウェア構成について説明する。図１５は、このようなコンピュータのハードウェア構成の一例を示した図である。図示するように、コンピュータは、演算手段であるＣＰＵ(Central Processing Unit）９０ａと、Ｍ／Ｂ(マザーボード）チップセット９０ｂを介してＣＰＵ９０ａに接続されたメインメモリ９０ｃと、同じくＭ／Ｂチップセット９０ｂを介してＣＰＵ９０ａに接続された表示機構９０ｄとを備える。また、Ｍ／Ｂチップセット９０ｂには、ブリッジ回路９０ｅを介して、ネットワークインターフェイス９０ｆと、磁気ディスク装置（ＨＤＤ）９０ｇと、音声機構９０ｈと、キーボード／マウス９０ｉと、フレキシブルディスクドライブ９０ｊとが接続されている。

尚、図１５において、各構成要素は、バスを介して接続される。例えば、ＣＰＵ９０ａとＭ／Ｂチップセット９０ｂの間や、Ｍ／Ｂチップセット９０ｂとメインメモリ９０ｃの間は、ＣＰＵバスを介して接続される。また、Ｍ／Ｂチップセット９０ｂと表示機構９０ｄとの間は、ＡＧＰ（Accelerated Graphics Port）を介して接続されてもよいが、表示機構９０ｄがＰＣＩ Ｅｘｐｒｅｓｓ対応のビデオカードを含む場合、Ｍ／Ｂチップセット９０ｂとこのビデオカードの間は、ＰＣＩ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）バスを介して接続される。また、ブリッジ回路９０ｅと接続する場合、ネットワークインターフェイス９０ｆについては、例えば、ＰＣＩ Ｅｘｐｒｅｓｓを用いることができる。また、磁気ディスク装置９０ｇについては、例えば、シリアルＡＴＡ（AT Attachment）、パラレル転送のＡＴＡ、ＰＣＩ（Peripheral Components Interconnect）を用いることができる。更に、キーボード／マウス９０ｉ、及び、フレキシブルディスクドライブ９０ｊについては、ＵＳＢ（Universal Serial Bus）を用いることができる。

ここで、本発明は、全てハードウェアで実現してもよいし、全てソフトウェアで実現してもよい。また、ハードウェア及びソフトウェアの両方により実現することも可能である。また、本発明は、コンピュータ、データ処理システム、コンピュータプログラムとして実現することができる。このコンピュータプログラムは、コンピュータにより読取り可能な媒体に記憶され、提供され得る。ここで、媒体としては、電子的、磁気的、光学的、電磁的、赤外線又は半導体システム（装置又は機器）、或いは、伝搬媒体が考えられる。また、コンピュータにより読取り可能な媒体としては、半導体、ソリッドステート記憶装置、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、リジッド磁気ディスク、及び光ディスクが例示される。現時点における光ディスクの例には、コンパクトディスク−リードオンリーメモリ（ＣＤ−ＲＯＭ）、コンパクトディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）及びＤＶＤが含まれる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態には限定されない。本発明の精神及び範囲から逸脱することなく様々に変更したり代替態様を採用したりすることが可能なことは、当業者に明らかである。

本発明の実施の形態における業務プロセス実行制御装置の概略構成を示した図である。 本発明の実施の形態の業務プロセス実行制御装置における業務プロセス実行時の概略動作を示した図である。 本発明の実施の形態の業務プロセス実行制御装置における業務プロセス実行時の概略動作を示した図である。 本発明の実施の形態の業務プロセス実行制御装置における業務プロセス実行時の概略動作を示した図である。 本発明の実施の形態で用いる保険契約の例について説明するための図である。 本発明の実施の形態のＵＮＤＯ／ＲＥＤＯ時の概略動作を示した図である。 本発明の実施の形態におけるリクエスタが保持するＤＢの例を示した図である。 本発明の実施の形態におけるプロバイダが保持するＤＢの例を示した図である。 本発明の実施の形態におけるリクエスタ及びプロバイダの機能構成例を示したブロック図である。 本発明の実施の形態におけるリクエスタの業務プロセス実行時の動作例を示したフローチャートである。 本発明の実施の形態におけるプロバイダの業務プロセス実行時の動作例を示したフローチャートである。 本発明の実施の形態におけるリクエスタの修正ＲＥＤＯ時の動作例を示したフローチャートである。 本発明の実施の形態におけるプロバイダのＵＮＤＯ時の動作例を示したフローチャートである。 本発明の実施の形態におけるプロバイダのＲＥＤＯ時の動作例を示したフローチャートである。 本発明の実施の形態を適用可能なコンピュータのハードウェア構成を示した図である。

符号の説明

１０…リクエスタ、２０ａ，２０ｂ，２０ｃ…プロバイダ、３０…ＧＢＰＩＤサーバ

Claims (9)

1. 複数のプロバイダにより提供される処理をリクエスタの要求に応じて行う複数のトランザクションの実行を制御する装置であって、
   前記リクエスタは、
   前記複数のトランザクションの各々における処理の要求先のプロバイダを示す第１の履歴情報を記憶する第１の記憶部と、
   前記複数のトランザクションのうちの特定の対象について実行された特定のトランザクションの再実行の要求があると、前記第１の履歴情報に基づいて、当該特定のトランザクションよりも後に当該特定の対象について実行されたトランザクションの各々における処理の要求先のプロバイダを特定する特定部と、
   前記特定部により特定された前記要求先のプロバイダに対して、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々において要求した処理の取消しを指示する取消し指示部と、
   前記特定部により特定された前記要求先のプロバイダに対して、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々において要求した処理の再実行を指示する再実行指示部と
   を備え、
   前記複数のプロバイダの各々は、
   前記複数のトランザクションの各々における前記リクエスタの要求に応じて処理を行う前の状態を示す第２の履歴情報を記憶する第２の記憶部と、
   前記取消し指示部により前記取消しが指示されると、前記第２の履歴情報に基づいて、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々における処理を取り消す取消し部と、
   前記再実行指示部により前記再実行が指示されると、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々における前記リクエスタの要求に応じて行った処理と、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々における当該処理以外の処理とを、これらの処理の間の順序関係が損なわれないように再実行する再実行部と
   を備えた、装置。
2. 前記第１の記憶部は、前記複数のトランザクションの各トランザクションに関する前記第１の履歴情報を、当該各トランザクションを識別する第１の識別情報と、当該各トランザクションの前及び後の何れかに同じ対象について実行されたトランザクションを識別する第２の識別情報とに関連付けて記憶し、
   前記特定部は、前記第１の識別情報と前記第２の識別情報とに基づいて、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションを特定する、請求項１の装置。
3. 前記リクエスタは、
   前記複数のトランザクションのうちの一のトランザクションを識別する第３の識別情報を取得する取得部と、
   前記一のトランザクションにおける処理の要求を前記第３の識別情報と共に前記要求先のプロバイダに送信する送信部と
   を更に備え、
   前記複数のプロバイダの各々は、
   前記処理の要求を前記第３の識別情報と共に前記リクエスタから受信する受信部と、
   他のトランザクションを識別する第４の識別情報が前記処理の対象に関連付けて記憶され、当該他のトランザクションが当該処理を完了した旨が当該第４の識別情報に関連付けて記憶されている場合に、当該処理を行い、前記第３の識別情報を当該処理の対象に関連付けて記憶し、当該処理が終了すると、前記一のトランザクションが当該処理を完了した旨を当該第３の識別情報に関連付けて記憶する処理部と
   を更に備えた、請求項２の装置。
4. 前記第１の記憶部は、前記複数のトランザクションの各トランザクションに関する前記第１の履歴情報を、当該各トランザクションを識別し、かつ、当該各トランザクションの同じ対象についての順序を特定可能な識別情報に関連付けて記憶し、
   前記特定部は、前記識別情報に基づいて、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションを特定する、請求項１の装置。
5. 前記第２の記憶部は、前記複数のトランザクションの各トランザクションに関する前記第２の履歴情報を、当該各トランザクションを識別する第１の識別情報と、当該各トランザクションの前及び後の何れかに同じ対象について実行されたトランザクションを識別する第２の識別情報とに関連付けて記憶し、
   前記再実行部は、前記第１の識別情報と前記第２の識別情報とに基づいて、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々における前記リクエスタの要求に応じて行った処理と、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々における当該処理以外の処理との間の順序関係を特定する、請求項１の装置。
6. 前記第２の記憶部は、前記複数のトランザクションの各トランザクションに関する前記第２の履歴情報を、当該各トランザクションを識別し、かつ、当該各トランザクションの同じ対象についての順序を特定可能な識別情報に関連付けて記憶し、
   前記再実行部は、前記識別情報に基づいて、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々における前記リクエスタの要求に応じて行った処理と、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々における当該処理以外の処理との間の順序関係を特定する、請求項１の装置。
7. 前記処理は、前記複数のプロバイダの各々が保持するデータベースを更新する処理であり、
   前記第２の履歴情報は、前記データベースの更新前イメージを含む、請求項１の装置。
8. 複数のプロバイダとして機能する複数のプロバイダコンピュータにより提供される処理をリクエスタとして機能するリクエスタコンピュータの要求に応じて行う複数のトランザクションの実行を制御する方法であって、
   前記リクエスタコンピュータには、前記複数のトランザクションの各々における処理の要求先のプロバイダコンピュータを示す第１の履歴情報が記憶されており、
   前記複数のプロバイダコンピュータの各々には、前記複数のトランザクションの各々における前記リクエスタコンピュータの要求に応じて処理を行う前の状態を示す第２の履歴情報が記憶されており、
   前記リクエスタコンピュータが、前記複数のトランザクションのうちの特定の対象について実行された特定のトランザクションの再実行の要求があると、前記第１の履歴情報に基づいて、当該特定のトランザクションよりも後に当該特定の対象について実行されたトランザクションの各々における処理の要求先のプロバイダコンピュータを特定するステップと、
   前記リクエスタコンピュータが、特定した前記要求先のプロバイダコンピュータに対して、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々において要求した処理の取消しを指示するステップと、
   前記リクエスタコンピュータが、特定した前記要求先のプロバイダコンピュータに対して、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々において要求した処理の再実行を指示するステップと、
   前記複数のプロバイダコンピュータの各々が、前記取消しが指示されると、前記第２の履歴情報に基づいて、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々における処理を取り消すステップと、
   前記複数のプロバイダコンピュータの各々が、前記再実行が指示されると、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々における前記リクエスタコンピュータの要求に応じて行った処理と、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々における当該処理以外の処理とを、これらの処理の間の順序関係が損なわれないように再実行するステップと
   を含む、方法。
9. 複数のプロバイダにより提供される処理をリクエスタの要求に応じて行う複数のトランザクションの実行を制御する装置であって、
   前記リクエスタは、
   前記複数のトランザクションの各トランザクションの第１のトランザクションＩＤと、当該各トランザクションの直前に同じ対象について実行されたトランザクションの第２のトランザクションＩＤと、当該各トランザクションにおける処理の要求先のプロバイダのプロバイダＩＤとを含む履歴情報を記憶する第１の履歴情報記憶部と、
   同じ対象について最新に実行されたトランザクションの最新トランザクションＩＤを管理する管理情報を記憶する第１の管理情報記憶部と、
   前記複数のトランザクションのうちの特定の対象について実行された特定のトランザクションの再実行の要求があると、当該特定の対象についての前記最新トランザクションＩＤを前記第１のトランザクションＩＤとして含む履歴情報を出発点として、当該特定の対象についての前記第２のトランザクションＩＤを前記第１のトランザクションＩＤとして含む履歴情報を、当該特定のトランザクションのトランザクションＩＤを前記第１のトランザクションＩＤとして含む履歴情報まで辿りながら、当該特定のトランザクションよりも後に当該特定の対象について実行されたトランザクションの各々における処理の要求先のプロバイダのプロバイダＩＤを特定する特定部と、
   前記特定部により特定された前記プロバイダＩＤのプロバイダに対して、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々において要求した処理の取消しを指示する取消し指示部と、
   前記特定部により特定された前記プロバイダＩＤのプロバイダに対して、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々において要求した処理の再実行を指示する再実行指示部と
   を備え、
   前記複数のプロバイダの各々は、
   前記複数のトランザクションの各トランザクションにおける前記リクエスタの要求に応じた処理のログの第１のログＩＤと、当該処理の直前の同じ対象についての処理のログの第２のログＩＤと、当該処理を行ったトランザクションの第３のトランザクションＩＤと、当該処理を行う前の状態を示す状態情報とを含む履歴情報を記憶する第２の履歴情報記憶部と、
   同じ対象についての最新のログの最新ログＩＤを管理する管理情報を記憶する第２の管理情報記憶部と、
   前記取消し指示部により前記取消しが指示されると、前記特定の対象についての前記最新ログＩＤを前記第１のログＩＤとして含む履歴情報を出発点として、前記特定の対象についての前記第２のログＩＤを前記第１のログＩＤとして含む履歴情報を、前記特定のトランザクションのトランザクションＩＤを前記第３のトランザクションＩＤとして含む履歴情報まで辿りながら、前記状態情報を用いて、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々における処理を取り消す取消し部と、
   前記再実行指示部により前記再実行が指示されると、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々における前記リクエスタの要求に応じて行った処理と、前記特定のトランザクションよりも後に前記特定の対象について実行されたトランザクションの各々における当該処理以外の処理とを、これらの処理の間の順序関係が損なわれないように再実行する再実行部と
   を備えた、装置。

Images