(57)【特許請求の範囲】
【請求項１】
トランザクションの一部としてリソースに対して実行される各正常アクションをリバースすることが可能な補償型リソース・マネージャ・コンポネントを用いて、メモリ中に在るプログラムのコンポネントの相互接続を管理するためのコンピュータ・システムにおいて、
該コンピュータ・システムは、
トランザクション・マネージャ・コンポネントの制御の下に、被管理リソースがトランザクション内部で関与するよう管理するための、コンポーネントによって構成されるオブジェクトモデルとして機能するコンポネント・ベースのリソース管理フレームワークを記憶しているメモリと、中央処理ユニット(CPU)とを備え、
前記トランザクション・マネージャ・コンポネントは、２フェーズ・コミット・プロトコルに従って、ノーティフィケーションを、関与するコンポネントに送信するための命令を有し、
前記コンポネント・ベースのリソース管理フレームワークは、
ログ・エントリーをログ記憶部中に持続的に記録するためのログ命令と、
リソース毎に特有の管理命令を前記フレームワークへと統合するための、複数のコンポーネントで規定される一般化したインターフェース命令と、
前記一般化したインターフェース命令によって前記フレームワークへと統合される前記リソース毎に特有の管理命令とを含み、
前記メモリは、
クライアント・アプリケーションのリクエストに応答してトランザクションの範囲内の被管理リソース中に保持されるデータを繰り返し変更する正常アクションとしてのワークを実行するよう動作する補償型リソース・マネージャ・コンポネントをメモリ内に有し、
前記補償型リソース・マネージャ・コンポネントの命令は、
トランザクションの一部としてリソースに対して実行される各正常アクションをリバースするのに十分な情報をログ記憶部中にログし、且つトランザクションがアボートされたことを示すトランザクション・マネージャ・コンポネントからのノーティフィケーションに応答して、前記ログされた情報に従ってトランザクションの一部としてリソースに対して実行される各正常アクションを完全にリバースするために補償アクションを実行するよう動作し、
前記中央処理ユニット(CPU)は、
トランザクション内部で被管理リソースの統合を実現するよう前記フレームワークの命令を実行する、ことを特徴とするコンピュータ・システム。
【請求項２】
請求項１に記載のコンピュータ・システムにおいて、前記補償型リソース・マネージャ・コンポネントは、ワーカー・コンポネント及びコンペンセータ・コンポネントを含み、前記ワーカー・コンポネントは、前記ワークを実行しログ記憶部内の情報をログするよう動作する命令を有し、前記コンペンセータ・コンポネントは、ログされた情報に従って補償アクションを実行するよう動作する命令を有し、また、前記ワーカー・コンポネントは、ログ記憶部のみを経由して前記コンペンセータ・コンポネントに情報を受け渡すことを特徴とする、コンピュータ・システム。
【請求項３】
CPU とプログラム・コンポネントの相互接続を実行するメモリとを持つ請求項１に記載のコンピュータ・システムにプログラミングするための、コンピュータで実行可能なプログラム・コードを記憶させるコンピュータで読み取り可能な記憶媒体であって、
前記プログラム・コードは、耐久性のあるリソース・コンポネントをトランザクション処理システムに統合してトランザクション・マネージャ・コンポネントの制御の下にトランザクション内部で関与させるために、当該コンポネント・ベースのリソース管理フレームワークを含み、
該統合は、アプリケーション・コンポネントがリクエストすれば耐久性のあるリソース・コンポネントに対し前記ワークの演算を実行するよう動作できるプログラム・コードを含むワーカー・コンポネントの使用と、当該ワーク演算をリバースさせる補償演算を実行するよう動作できるプログラム・コードを含むコンペンセータ・コンポネントの使用とからなり、
前記コンポネント・ベースのリソース管理フレームワークのプログラム・コードは、
コンペンセータ登録コンポネントのプログラム・コードを実行するに際し、CPUがコンペンセータ・コンポネントを登録する場合に、コンペンセータ・コンポネントを登録するための、前記ワーカー・コンポネントによる呼出しに対するコンペンセータ登録インタフェースを有するコンペンセータ登録コンポネントと、
ロギング・コンポネントのプログラム・コードを実行するに際し、CPU が当該ワーク演算の情報を繰り返しログする場合に、当該ワーク演算の情報を繰り返しログするための、前記ワーカー・コンポネントによる呼出しに対するロギング・インタフェースを有するロギング・コンポネントと、
補償を開始するコンポネントのプログラム・コードを実行するに際し、CPU がメモリ中にコンペンセータ・コンポネントを作成して、該コンペンセータ・コンポネントにより当該ワーク演算をリバースさせる場合に、トランザクションをアボートすべき旨のノーティフィケーションをトランザクション・マネージャから受け取るためのノーティフィケーション・インタフェースを有し、コンペンセータ・コンポネントを作成するように動作するとともに、前記ノーティフィケーションに応答してワーカー・コンポネントによりログされる情報に基づきコンペンセータ・コンポネントに補償演算を実行させて、当該ワーク演算をリバースさせるように動作することができる、補償開始コンポネントと、
を有することを特徴とする、コンピュータで読み取り可能な記憶媒体。
【請求項４】
請求項３に記載のコンピュータで読み取り可能な記憶媒体において、コンペンセータ登録コンポネントのプログラム・コードを実行するに際し、CPU はコンペンセータ登録インタフェースへのワーカー・コンポネントの呼出しから戻るに当たりロギング・インタフェースへのポインターをワーカー・コンポネントに受け渡すことを特徴とする、コンピュータで読み取り可能な記憶媒体。
【請求項５】
請求項３に記載のコンピュータで読み取り可能な記憶媒体において、コンペンセータ登録コンポネントのプログラム・コードを実行するに際し、コンペンセータ登録インタフェースへのワーカー・コンポネントの呼出しに応答して、補償開始コンポネントのプログラム・コードを実行するに当たってCPU がトランザクション・マネージャからノーティフィケーションを受け取るように、CPU は更に補償開始コンポネントをワーカー・コンポネントが関与するトランザクション内部に取り入れるように動作できることを特徴とする、コンピュータで読み取り可能な記憶媒体。
【請求項６】
請求項３に記載のコンピュータで読み取り可能な記憶媒体において、補償開始コンポネントのプログラム・コードを実行するに際し、CPU は更に、ノーティフィケーション・インタフェース上のトランザクション・マネージャから準備ノーティフィケーションを受け取るように動作でき、該準備ノーティフィケーションに応答してトランザクションの準備フェーズ中に、該トランザクションをアボートするか否かを決定する演算を、コンペンセータ・コンポネントに実行させるように動作できることを特徴とする、コンピュータで読み取り可能な記憶媒体。
【請求項７】
請求項３に記載のコンピュータで読み取り可能な記憶媒体において、補償開始コンポネントのプログラム・コードを実行するに際し、CPU は更に、ノーティフィケーション・インタフェース上のトランザクション・マネージャからコミット・ノーティフィケーションを受信するように動作でき、且つ該コミット・ノーティフィケーションに応答して当該ワーク演算によって部分的に達成された前記ワークの完了のためにログされた情報に準拠してクリーンアップ演算及び実演算をコンペンセータ・コンポネントに実行させるように動作できることを特徴とする、コンピュータで読み取り可能な記憶媒体。
【請求項８】
メモリ内のプログラムのコンポネントの相互接続を管理するためのオンライン・トランザクション処理コンピュータ・システムであって、
該コンピュータ・システムは、
トランザクション・マネージャ・コンポネントを記憶しているメモリと、該トランザクション・マネージャ・コンポネントの制御の下にトランザクションの内部で耐久性のあるリソースを関与させるように管理するための補償型リソース・マネージャ・コンポネントとを有し、
該補償型リソース・マネージャ・コンポネントは、
トランザクションの一部として耐久性のあるリソース・コンポネントに対して正常アクションとしてのワーク演算をリクエストするためのアプリケーションによる呼出し用のワークリクエストインタフェースを有するワーカー・コンポネントであって、CPU が該ワーカー・コンポネントのプログラム命令を実行し、且つ該アプリケーションによる呼出しに応答して正常アクションとしてリクエストされた当該ワーク演算に関係する情報を繰り返しログに書き込み、正常アクションを実行して、耐久性のあるリソース上のワーク演算を成し遂げるように動作する、ワーカー・コンポネントと、
トランザクションをアボートするためにトランザクション・マネージャによって発行されるノーティフィケーションを受け取るためのノーティフィケーション・インタフェースを有するコンペンセータ・コンポネントであって、前記CPU は該コンペンセータ・コンポネントのプログラム命令を実行し、且つ前記ノーティフィケーションに応答してログから情報を読み出し、トランザクションの一部として耐久性のあるリソースに対して実行される各正常アクションをリバースするための補償アクションを実行するように動作する、コンペンセータ・コンポネントとを含み、
前記ワーカー・コンポネント及び前記コンペンセータ・コンポネントは、前記ワーカー・コンポネントによりログされた情報によってのみ状態を共有することを特徴とする、オンライン・トランザクション処理コンピュータ・システム。
【請求項９】
請求項８に記載のコンピュータ・システムにおいて、
前記補償型リソース・マネージャ・コンポネントは、更に、
コンペンセータ・コンポネントを登録するためのワーカー・コンポネントによる呼出しに対するコンペンセータ登録インタフェースを有する補償マネージャ・コンポネントを含み、
前記CPU は、該補償マネージャ・コンポネントのプログラム命令を実行し、且つワーカー・コンポネントによる呼出しに応答してコンペンセータ・コンポネントを作成してトランザクション内部に取り入れ、トランザクション・マネージャにより発行されるノーティフィケーションを受け取るように動作することを特徴とする、オンライン・トランザクション処理コンピュータ・システム。
【請求項１０】
請求項９に記載のコンピュータ・システムにおいて、前記補償型リソース・マネージャ・コンポネントのプログラム命令を実行するCPU は、更にワーカー・コンポネントの呼出しに応答してワーカー・コンポネントが情報をログに書き込むためのアクセスを供給するように動作できることを特徴とする、オンライン・トランザクション処理コンピュータ・システム。
【請求項１１】
請求項８に記載のコンピュータ・システムにおいて、CPU はトランザクション中の障害後の障害回復のために補償型リソース・マネージャ・コンポネントのプログラム命令を実行し、補償型リソース・マネージャ・コンポネントは更に障害回復マネージャ・コンポネントを有し、
CPU は、該障害回復マネージャ・コンポネントのプログラム命令を実行するに当たり、障害後に障害回復が開始されると、トランザクションの結果をトランザクション・マネージャ・コンポネントから決定し、補償するコンポネントを作成し、該結果が該トランザクションをアボートすべきものであった場合に、ログからの情報に基づいて補償するコンポネントに補償アクションを実行させるように動作できることを特徴とする、オンライン・トランザクション処理コンピュータ・システム。
【請求項１２】
請求項１１に記載のコンピュータ・システムにおいて、障害回復マネージャ・コンポネントのプログラム命令を実行するCPU は、障害回復中に補償アクションを実行すべき補償するコンポネントの障害に当たって、該補償アクションを後続の障害回復まで延期するためにログ内の情報を保存するように動作できることを特徴とする、オンライン・トランザクション処理コンピュータ・システム。
【請求項１３】
請求項８に記載のコンピュータ・システムにおいて、補償するコンポネントのプログラム命令を実行するCPU は、障害回復中の補償アクションの実行の障害に当たって、操作する人間が耐久性のあるリソースに対するアクションをリバースさせる手動アクションを実施するために、操作する人間に供給されるべき注意及び情報をもたらすように動作できることを特徴とする、オンライン・トランザクション処理コンピュータ・システム。
【請求項１４】
請求項８に記載のコンピュータ・システムにおいて、補償するコンポネントの補償アクションは冪等性であることを特徴とする、オンライン・トランザクション処理コンピュータ・システム。
【請求項１５】
請求項８に記載のコンピュータ・システムにおいて、補償するコンポネントの補償アクションはリバースできないことを特徴とする、オンライン・トランザクション処理コンピュータ・システム。
【請求項１６】
フレームワーク・デベロッパーを履行するコンポネント・ベースのトランザクション処理フレームワーク内で、選ばれたリソースがトランザクション処理プロトコルをサポートしないときに、リソースをフレームワークに統合する方法であって、該方法はCPU とメモリとを持つ請求項１に記載のコンピュータ・システム内で実行され、該メモリは該方法を実行するための命令を含む、当該方法は、
CPU が２番目のデベロッパーにより履行される命令を含むワーカー・コンポネントの命令を実行することによりリソースの状態を変えるステップと、
CPU が該２番目のデベロッパーにより履行される命令を含むコンペンセータ・コンポネントの命令を実行することによりリソースを元の状態へ戻すステップとを含み、
リソースのロギング及び復帰を、リソース変更がトランザクションのコミットに際しリソース上で持続的のままであるように、且つリソースがトランザクションのアボートに際しトランザクション以前の状態に戻すように、CPU が実行するフレームワークの命令によってサポートすることを特徴とする、リソースをフレームワークに統合する方法。
【請求項１７】
フレームワーク・デベロッパーを履行するコンポネント・ベースのトランザクション処理フレームワーク内で、選ばれたリソースがトランザクション処理プロトコルをサポートしないときに、リソースをフレームワークに統合する方法であって、請求項１に記載のコンピュータ・システムにおけるCPU がメモリから得られた命令に従って該方法を実行する、当該方法は
CPU が実行する命令によって、２番目のデベロッパーにより履行される実行可能な命令を含むワーカー・コンポネントからのリソース更新リクエストを受け入れるステップと、
CPU が実行する命令によって、前記リソース更新リクエストをログするステップと、
CPU が実行する命令によって、更新リソースリクエストに従ってリソースを更新するステップと、
CPU が実行する命令によって、ワーカー・コンポネントをコンペンセータ・コンポネントと関連させるステップと、
トランザクションのアボートに際しCPU が実行する命令によって、２番目のデベロッパーにより履行される実行可能な命令を含む前記コンペンセータ・コンポネントから、リソースを元へ戻すリクエストを受け入れるステップと、
を含むことを特徴とする、リソースをフレームワークに統合する方法。
【請求項１８】
コンポネント・ベースのトランザクション処理フレームワーク内で、選ばれたリソースがトランザクション処理プロトコルをサポートしないときに、該リソースにトランザクション処理サポートを供給する方法であって、請求項１に記載のコンピュータ・システムにおけるCPU がメモリから得られた命令に従って該方法を実行する、当該方法は、
CPU が実行する命令によって、２番目のデベロッパーにより履行されるコードによりなされるリクエストを露呈されたインタフェースで受け入れ、このコードは、クラークコンポネントの作成とコンペンセータ・コンポネントの登録とリソースの変更とをリクエストするステップと、
CPU が実行する命令によって、露呈されたインタフェースでなされたリクエストに応答して、クラークを作成し、コンペンセータ・コンポネントを登録し、且つリソースに加えられた変更をログするステップと、
CPU が実行する命令によって、トランザクションのコミット又はアボートの指示に応答して、コンペンセータ・コンポネントを作成し、トランザクション中に変更が作ったコンペンセータ・コンポネントをリソースに受け渡すステップと、
を含むことを特徴とする、リソースにトランザクション処理サポートを供給する方法。
【請求項１９】
請求項１８に記載の方法において、該方法は、
CPU が実行する命令によって、コンペンセータ・コンポネントによりなされたリクエストに応答してリソースに加えられた変更をログするステップを更に含むことを特徴とする、リソースにトランザクション処理サポートを供給する方法。
【請求項２０】
露呈されたインタフェースを持つコンポネント・ベースのトランザクション処理フレームワーク内で、選ばれたリソースがトランザクション処理プロトコルをサポートしないときに、且つ２番目のデベロッパーがリソースへの変更をもたらすことになるサーバー・アプリケーション・プログラムを展開するときに、リソースをトランザクション処理プロトコルに統合するために２番目のデベロッパーにより用いられる方法であって、請求項１に記載のコンピュータ・システムにおけるCPU がメモリから得られた命令に従って該方法を実行する、当該方法は、
CPU が実行する命令によって、クラークコンポネントの作成をリクエストするためのインタフェース及び命令を含むコンポネントを作成し、コンペンセータ・コンポネントの登録をリクエストし、変更をリソースにログするステップと、
CPU が実行する命令によって、コンペンセータ・コンポネントを具体化し、トランザクションをアボートする旨の指示を受け取り、リソースにログされた変更の確認を受け取るステップとを含むことを特徴とする、リソースをトランザクション処理プロトコルと統合するために２番目のデベロッパーにより用いられる方法。
【請求項２１】
トランザクション・フレームワークでリソースを管理するコンポネント・コードを統合するための、請求項１に記載のコンピュータ・システムとしてコンピュータを動作させるプログラムであって、第１の役割のデベロッパーがトランザクション・マネージャ・プログラム・コードを展開し、第２の役割のデベロッパーがトランザクション・マネージャの制御の下にリソースがトランザクション内部で関与するよう管理するための補償型リソース・マネージャ・プログラム・コードを展開する、当該プログラムにおいて、
該補償型リソース・マネージャ・プログラム・コードは、
トランザクションの一部としてリソースに対してワーク演算をリクエストするためのアプリケーションによる呼び出し用のワークリクエストインタフェースを有するワーカー・コンポネントであって、CPU が、ワーカー・コンポネントのプログラム・コードを実行しアプリケーション呼び出しに応答して動作するに当たり、正常アクションとしてリクエストされたワーク演算に付随する情報をログに繰り返し書き込み、当該ワーク演算を実行してリソースにおける正常アクションを実現するワーカー・コンポネントと、
トランザクションをアボートするようトランザクション・マネージャの発するノーティフィケーションを受け取るためのノーティフィケーション・インタフェースを有するコンペンセータ・コンポネントであって、CPU が、コンペンセータ・コンポネントのプログラム・コードを実行しログからの情報を読み出すノーティフィケーションに応答して動作するに当たり、補償する動作を実行してトランザクションの一部としてリソースに対して実行される各正常アクションをリバースさせる、コンペンセータ・コンポネントとを含み、
前記CPU が実行するワーカー・コンポネント及びコンペンセータ・コンポネントのプログラム・コードは、CPU が実行するワーカー・コンポネントのプログラム・コードによりログされた情報によってのみ状態を共有することを特徴とする、プログラム。
【請求項２２】
請求項１に記載のコンピュータ・システムにおいて、当該コンポネント・ベースの実行可能な命令及びデータを記憶するメモリを備え、
前記コンポネント・ベースのリソース管理フレームワークは、
トランザクション・マネージャの実行可能な命令の制御の下にトランザクション内部で関与するようリソースを管理し、
該トランザクション・マネージャは、
第１の役割のパーティにより展開され、２フェーズ・コミット・プロトコルに従って関与するコンポネントへのノーティフィケーションを送出するための実行可能な命令を有し、
前記フレームワークは、
ログ・エントリーを記録するために第１の役割のパーティにより展開される実行可能な命令を持つログ記憶コンポネントと、
第２の役割のパーティにより展開される実行可能な命令を有し、クライエントのアプリケーションリクエストの実行可能な命令に応答して動作してトランザクションの範囲内のリソース中に保持されるデータを繰り返し変更する正常アクションとしてのワーク演算を実行する、補償型リソース・マネージャ・コンポネントとを有し、
該補償型リソース・マネージャ・コンポネントは、
ログ記憶部内で該ワーク演算を完全にリバースさせるのに十分な情報をログするための命令をも更に有し、アボートされたトランザクションを指定するトランザクション・マネージャ・コンポネントからのノーティフィケーションを作成する実行可能な命令に応答して動作する命令を有し、該ワーク演算を完全にリバースさせるログされた情報に従って補償アクションを実行し、
前記CPU がフレームワークの実行可能な命令を実行してトランザクション内部のリソースの管理を実現することを特徴とする、コンピュータ・システム。
【請求項２３】
請求項１に記載のコンピュータ・システムにおいて、当該コンポネント・ベースの実行可能な命令及びデータを記憶するメモリを備え、
前記コンポネント・ベースのリソース管理フレームワークは、
トランザクション・マネージャの実行可能な命令の制御の下にトランザクション内部で関与するようリソースを管理するためのフレームワーク・デベロッパーが履行し、
該トランザクション・マネージャの実行可能な命令は、
２フェーズ・コミット・プロトコルに従って関与するコンポネントへのノーティフィケーションを送出し、
前記フレームワークは、
ログ・エントリーを持続的に記録するための実行可能な命令を有するログ記憶部と、
クライエントのアプリケーションリクエストに応答して動作する実行可能な命令を有し、トランザクションの範囲内のリソース中に保持されるデータを繰り返し変更する正常アクションとしてのワーク演算を実行し、ログ記憶部内で該ワーク演算を完全にリバースさせるのに十分な情報をログする補償型リソース・マネージャとを有し、
該補償型リソース・マネージャ・コンポネントは、
アボートされたトランザクションを指定するトランザクション・マネージャからのノーティフィケーションに応答して動作する実行可能な命令を有し、トランザクションの一部としてリソースに対して実行される各正常アクションを完全にリバースさせるログされた情報に従って補償するアクションを実行し、
中央処理ユニットが実行可能な命令を実行してトランザクション内部のリソースの管理を実現することを特徴とする、コンピュータ・システム。
【請求項２４】
１番目のフレームワーク・デベロッパーにより展開された命令を持つコンポネント・ベースのリソース管理フレームワークを含むリソース管理フレームワークとしてコンピュータを動作させる命令で、請求項１に記載のコンピュータ・システムとして動作するコンピュータにて実行することができる命令を記憶してあるコンピュータで読み取り可能な記憶媒体であって、
前記１番目のフレームワーク・デベロッパーにより展開された命令は、トランザクション・マネージャの制御の下でリソースがトランザクション内部で関与するようトランザクション処理システムへ該リソースを統合するための命令であり、該統合はワーカー・コンポネント及びコンペンセータ・コンポネントを用いることによってなされ、
前記ワーカー・コンポネントには２番目のデベロッパーにより履行される複数の実行可能な命令が入っており、これらの命令は、アプリケーションがリクエストすればリソース上で当該ワークの演算を実行するよう動作し、
前記コンペンセータ・コンポネントには２番目のデベロッパーにより履行される複数の実行可能な命令が入っており、これらの命令は、前記ワーク演算をリバースさせる補償演算を実行するよう動作し、
コンポネント・ベースのフレームワークの実行可能な命令は、
CPU が実行するワーカー・コンポネントの実行可能な命令により呼び出しを行ってコンペンセータ・コンポネントを登録するための、コンペンセータ登録インタフェースを有するコンペンセータ登録コンポネントと、
ワーカー・コンポネントによる呼び出しを行うためのロギング・インタフェースを有するとともに、CPU により実行可能な、ワーク演算の情報を繰り返しログする命令を有するロギング・コンポネントと、
トランザクション・マネージャから、トランザクションをアボートする旨のノーティフィケーションを受け取るためのノーティフィケーション・インタフェースを有し、CPU により実行可能な命令で、且つコンペンセータ・コンポネントを作成するように動作することでき、且つ前記ノーティフィケーションに応答してワーカー・コンポネントによりログされる情報に基づきコンペンセータ・コンポネントに補償演算を実行させて、トランザクションの一部としてリソースに対して実行される各正常アクションをリバースさせるように動作することもできる命令を有する、補償開始コンポネントと、
を含むことを特徴とする、コンピュータで読み取り可能な記憶媒体。
【請求項２５】
トランザクション処理システムとして動作するコンピュータで実行することができ、１番目のパーティによって展開される命令が入っているトランザクション・マネージャと、該トランザクション・マネージャの制御の下にトランザクション内部で関与するようリソースを管理するための２番目のパーティによって履行される命令が入っている補償型リソース・マネージャとを含むコンピュータ・プログラムであって、
該補償型リソース・マネージャは、
トランザクションの一部としてリソース上の正常アクションとしてのワーク演算をリクエストするためアプリケーションによる呼び出しのためのワークリクエストインタフェースを有するワーカー・コンポネントを含み、
該ワーカー・コンポネントは、
アプリケーション呼び出しに応答して動作し、正常アクションとしてリクエストされた当該ワーク演算に付随する情報をログに繰り返し書き込み、当該ワーク演算を実行してリソース上に正常アクションを実現する実行可能な命令を有し、
前記補償型リソース・マネージャは、
トランザクションをアボートするようトランザクション・マネージャの発するノーティフィケーションを受け取るためのノーティフィケーション・インタフェースを有するコンペンセータ・コンポネントを含み、
該コンペンセータ・コンポネントは、
ログからの情報を読み出すノーティフィケーションに応答して動作し、トランザクションの一部としてリソースに対して実行される各正常アクションをリバースさせるよう補償する動作を実行する実行可能な命令を有し、
前記ワーカー・コンポネント及びコンペンセータ・コンポネントは、CPUが実行するワーカー・コンポネントの命令によりログされた情報によってのみ状態を共有することを特徴とする、コンピュータ・プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般的にはオンライン・トランザクション処理アプリケーションに関するもので、更に特定すればオンライン・トランザクション処理アプリケーションに対するトランザクション・マネージメントシステムにおける非トランザクション・リソース又は非コンプライアント・トランザクション・リソースの管理に関する。
【０００２】
【従来の技術】
〔本発明の背景および概要〕
多くの情報処理アプリケーションでは、分散ネットワーク中のホスト又はサーバー・コンピュータ上で走るサーバー・アプリケーションは、複数の利用者により操作されるネットワークの端末又はワークステーション・コンピュータ上で走るクライアント・アプリケーションに対して処理サービス又は処理方法を提供する。そのようなサーバー・アプリケーションの一般的な例は、大学でのクラス登録、旅行予約、銀行での送金や他のサービス、および営業での販売に対するソフトウエアを含む。これらの例において、サーバー・アプリケーションにより実行される処理サービスは、データベース又は他の専用フォーマットのデータ記憶装置のような所に、それぞれのステーションにおいて各ユーザによってイニシエートされるアクションのために、クラス・スケジュール、ホテル予約、口座残高、注文品出荷、支払い、在庫記録の耐久性のあるデータ又は「状態("state") 」を典型的に維持している。
【０００３】
度々、サーバー・アプリケーションは、１個のコンピュータ上での分離された処理による複数のコンピュータの協調活動が、しかも単一の処理にすらこの協調活動がリクエストされる。例えば、バンキング応用における送金操作は、地理的に離れている可能性のある別々のコンピュータ上に存在する別々のデータベースに存在する口座情報の更新に関係する。１個のオペレーションの各部分を構成する活動の集団は、通常トランザクションと呼ばれる、１個のワークの分割できないユニットとして実行されるように協調されることが望ましい。多くのアプリケーションにおいて、活動の集団を１個のトランザクションとして実行することは業務上で必要なこととなる。例えば、システム障害のために、送金操作においてただ１個の口座のみを更新すれば、銀行は実際にお金を作造するか、又は破棄することになる。
【０００４】
トランザクションは、アトミック性(Atomicity),首尾一貫性(Consistency),孤立性(Isolation),及び耐久性(Durability)を含む１組のプロパティ("ACID" プロパティと呼ばれるもの) に準拠するアクションの集合である。アトミック性は、１個のトランザクション中の全てのアクティビティ(activity)が１ユニットとして共に動作するか、又は全てが失敗するかを意味する。首尾一貫性は、トランザクションが実行された後、システムは安定又は正常状態に保たれること（即ち、トランザクション中のアクティビティを活性化しても正常安定状態に到達しなければ、システムは最初のトランザクション前の状態に戻ること）を意味する。孤立性は該トランザクションが他の同時に実行中のトランザクションによって影響されないこと（トランザクションによる共用リソースへのアクセスは行列に従い、且つ共有リソースの変更はトランザクションが終了するまでトランザクション外には見えないこと）を意味する。耐久性はトランザクションの効果は永久的でシステム障害に対しても生き残ることを意味する。トランザクション処理に関する追加の背景情報については、とりわけ1993年Morgan Kaufmann の刊行したJimGrayとAndreas Reuter著"Transaction Processing Concepts and Techniques"を参照されたい。
【０００５】
本発明の出願人によるこれ以前の特許出願（すなわち、出願日はいずれも1997年10月28日の米国特許出願No.08/959,141, Helland他による"Automatic Transaction Processing Of Component-Based Server Applications";及び、米国特許出願No.08/959,142, Helland他による"Disabling And Enabling Transaction Committal In Transactional Application Components"; を指し、本出願はここにこれらを参照文献とし、包括的に「合同 MTS特許出願」と呼ぶことにする）は、Microsoft Transaction Server(MTS)version1.0 の製品に組み込まれている分散サーバー・アプリケーションに対する実行環境及びプラットフォームを開示している。 MTSは、コンポネント・ベースのフレームワーク又はオブジェクトモデルに対し、Microsoft Distributed Transaction Coodinator(MSDTC) のようなトランザクション・マネージャの制御下のサーバー・アプリケーションのコンポネントの潜在的に(potentially) 分散されたグループによってトランザクションをサポートするシステム・サービスを提供する。
【０００６】
MTS においては、サーバー・アプリケーションは、手元にある在庫記録、未処理の注文、および支払われるべき勘定書のようなアプリケーションの耐久性のある状態を維持するために、リソース・マネジャーを使用する。リソース・マネジャーは、データベース、耐久性のあるメッセージ・キュー、ファイルシステム、又は他のデータ記憶リソースに記憶されるであろう耐久性のあるデータを管理するシステム・サービスである。１例は、Maicrosoft SQL Server version6.5に含まれるリソース・マネジャーである。リソース・マネジャーは、管理されるリソースの耐久性のあるデータ上のACIDプロパティを強化するために、トランザクションと協調して動作する。
【０００７】
リソース・マネジャーソースは、特殊なリソース（例えば、耐久性のあるデータ記憶装置）に対しては、開発及び実行が困難である。これがリソース・マネジャーがトランザクション処理において多数の一層複雑な事項を取り扱う理由である。特に、リソース・マネジャーはトランザクション・マネジャーと適切にインターフェースし、且つ被管理リソース上のコンポネントによって実行がリクエストされる全ての動作はACIDトランザクション・プロパティに従うことを保証しなければならない。このようにしてリソース・マネジャーは、特別なトランザクションの下で完了するコンポネントによる耐久性のあるデータの全ての更新は、トランザクションがコミット(commit)された時に耐久性のあるものになること、又はトランザクションがアボート(abort) すれば元に戻されること、を保証しなければならない。リソース・マネジャーはアクティブ・トランザクションの実行されなかった仕事を隔離するためにトランザクション・ベースの同期プロトコルを使用する。リソース・マネジャーは、リソース・マネジャーは何れのスレッド(thread)からもアプリケーション・コンポネントによって呼び出されることが出来なければならないことを意味するスレッド・セーフティを保証しなければならない。更に、リソース・マネジャーは、リソースに関係するトランザクションはクラッシュ及び他の障害（通信障害、処理障害、記憶媒体障害、及びサーバーシステム障害）に対して耐久性があるように、ロギング及び障害回復を供給しなければならない。
【０００８】
更に MTSリソース・マネジャー(MTSをサポートするためにこのように呼ばれるリソース・マネジャー) は幾つかの追加の要求条件を満足しなければならない。特に MTSリソース・マネジャーは、MTS への統合を許し且つMS DTCにインタフェースする"OLEトランザクション" インタフェースの全て（又は、重要なサブセット）を実装する。更に MTSリソース・マネジャーは、マネージされたリソースに対してリソース・ディスペンサ(MTSサーバー・アプリケーション・コンポネントに対するプーリング及び自動トランザクション登録を行うサービス) を供給しなければならない。もしリソース・ディスペンサが無ければ、自動トランザクション登録のための他のメカニズムを供給しなければならない。
【０００９】
【発明が解決しようとする課題】
これらの困難のため MTSに対するリソース・マネジャーは未だ殆ど存在しない（前記Microsoft SQL Server version6.5 が１例である）。しかしトランザクション・サポートの無い広範な種類のリソースが現在市場に出回り、且つ使用されている。更に、MS DTSにインタフェースするような、MTS において相互運用するためにリクエストされたインタフェース（即ち、OLE トランザクション・インタフェース）を供給しない他のトランザクション・システムに対する各種のリソース・マネジャー（ここでは、遺物的リソース・マネジャーと呼ぶ）が存在する。例えば、多くの旅行業界の予約システムは、IBM CICSトランザクション・システムの下で管理される予約データベースを持っている。従って、各リソース毎に特有のMTS リソース・マネジャーを導入するよりは一層容易に、そのような非トランザクション・リソース及び遺物的リソース・マネジャーをMTS に統合することが望ましい。
【００１０】
【課題を解決するための手段】
本発明は、耐久性のあるリソースをトランザクション・システム、特に MTSのようなコンポネント・ベースのオンライン・トランザクション処理アプリケーションへ、一層容易に統合することができるリソース・マネージメントの一形式（ここでは、「補償」("compensation")又は「補償型リソース・マネージメント」("compensating resource management")と呼ぶ）を供給する。補償型リソース・マネージメントにおいて、耐久性のあるリソースは、トランザクションの一部としてリソースに対して実行される各正常アクションをリバースする補償アクションを供給することによりトランザクション・システムの下でトランザクションに関与するように統合される。該正常アクションはリクエストのあった時点で持続されている。トランザクションが失敗する場合には、耐久性のあるリソースをトランザクション前の状態に戻すために、補償アクションがトランザクション外で呼び出される。耐久性のために、トランザクション中に実行される各正常アクションに対して取られる補償アクションを識別する情報はライトアヘッド・ベースでログに書き込まれる。このようにして、障害の場合には、トランザクションの状況に応答して回復動作が実行される。
【００１１】
コンポネント・ベースのオンライン・トランザクション処理アプリケーション環境では、補償型リソース・マネージメントは、補償型リソース・マネジャー(CRM) を導入することにより、特定の耐久性のあるリソースに対して与えることができる。開発者は CRMが耐久性のあるリソース上でサポートする各正常アクションに対して、補償アクションをCRM 中に導入する。該開発者は又正常アクションに対する補償アクションを明確化するために前記の各正常アクションと関連させてライトアヘッド・ロギングを実行させるためにCRM を導入する。
【００１２】
ここに例示される本発明の１個の実施例（例示される実施例）に準拠して CRMは、ログの媒体を通じてのみ状態（すなわちデータ）を共有する CRMワーカー(CRM worker)及び CRMコンペンセータ(CRM compensator) の１対のコンポネントとして開発される。CRM ワーカーはサーバー・アプリケーションに対するトランザクションの一部として、サーバー・アプリケーションによってリクエストの時点で正常アクションを実行する。このアクション及びそこを通して該アクションがサーバー・アプリケーションによってアクセスされるインタフェースは特定のCRM に限定される。サーバー・アプリケーションが該インタフェースを経て正常アクションを呼び出す時に、CRM ワーカーは又CRM コンペンセータを識別するシステムが準備したログにログ記録を書き込む。
【００１３】
CRM コンペンセータはCRM ワーカーの正常動作に対応する補償アクションを実行する。CRM ワーカーによって指定されたCRM コンペンセータは、CRM ワーカーによってログされる正常アクションに関連して適切な追加のアクションを実行することにより２フェーズ・コミット・プロトコル（即ち、フェーズ１及びフェーズ２）の後ろの方のフェーズに関与するために、後刻、作成される。CRM コンペンセータは、トランザクション・マネージャから（例示される実施例におけるログ障害回復マネージャの方法により）２フェーズ・コミット・プロトコル・ノーティフィケーション（即ち、準備、コミット、及びアボートのノーティフィケーション）を受け取るシステムにより定義されるインタフェース、をサポートする。これらのノーティフィケーションは、２フェーズ・コミット・プロトコルのこれらのフェーズにCRM コンペンセータが関与することを許す。
【００１４】
一層特別に、準備フェーズの間、CRM コンペンセータはトランザクションのコミッタル(committal) に反対してボート(vote)でき、準備ノーティフィケーションに応答して（即ち、準備ノーティフィケーションに応答して、"No"をボートする値を返すことにより） アボートを強制できる。コミット・ノーティフィケーションはCRM ワーカーの正常アクションの後クリーンアップ・プロセシングを実施する機会をCRM コンペンセータに与える。このクリーンアップ・プロセシングは、アボートしたトランザクションに対して補償する目的で維持されている（耐久性の、又は非耐久性の）如何なる状態も除去することである。コミット・ノーティフィケーションは、又コンペンセータにリバースできない如何なるワークも実行する機会を与える。例えば、ATM トランザクションにおいて、口座残高が減算され現金が払出されるであろう。減算の発生が保証されない限り現金の払出しは望ましくない。ATM を管理するCRM と共に、CRM コンペンセータはATM に物理的に十分な現金がある限り準備ノーティフィケーションへの応答として"yes" をボートするであろう。ついで、コミット・ノーティフィケーションへの応答して、CRM コンペンセータはATM に現金を実際に払出させる。アボーテド・ノーティフィケーションへの応答として、CRM コンペンセータはCRM ワーカーの正常動作をリバースさせる補償アクションを実行する。従って、トランザクションの正常処理の間、CRM コンペンセータはトランザクション準備フェーズに関与し、トランザクションの結果について知らされる。CRM コンペンセータは、その時コミットに対しクリーンアップを、アボートに対して補償をすることができる。一方、回復過程中にCRM コンペンセータは再度作成され、且つログに基づくトランザクションの結果を知らされることにより、該CRM コンペンセータに、如何にも障害が無かったかのようにリソースに関連するトランザクション処理（適切ならば）を完了させる。例えば、フェーズ１がシステム・クラッシ以前に完了していなければ、CRM コンペンセータにはアボート・ノーティフィケーションが送られる。
【００１５】
ここに例示される実施例において、特に補償アクションを含むCRM コンペンセータにより実行される（トランザクション中に実行されるワーク、又は一連のログ記録として定義される）各アクションは冪等性(idempotent)でなければならない。これは、トランザクションのコミット又はアボートに対するCRM コンペンセータのアクションは何度でも試みることができ、且つ若しアクションが成功すれば該アクションは如何にも該アクションが最初のアテンプトで成功したように同一の結果を生じることを意味する。
【００１６】
本発明の別の特徴および利点は、付属する図面を参照しながら進展する例示の実施例の下記の詳細説明から明白になるであろう。
【００１７】
［実施例］
〔例示された実施例の詳細な説明〕
本発明は、オンライン・トランザクション処理における補償型リソース・マネージメントに対する方法、システム、及びソフトウエア製品に対するものである。ここで例示される１実施例において、本発明は、米国Redmond,Washington所在の Microsoft Corporation社による "Microsoft Windows NT Server 5.0"オペレーティング・システムの一部をなす"COM+"と呼称する分散コンピューティングシステム上のサーバー・アプリケーションに対するオペレーティング・ソフトウエアに組み込まれている。簡単に説明すれば、このソフトウエアは、とりわけ、分散コンピュータシステム上の１個の２フェーズ・コミット・プロトコルを使用するトランザクション処理をサポートするシステム・サービスを含むサーバー・アプリケーションに対する１個のコンポネント・フレームワーク及びランタイム(run-time)実行環境を提供する。
【００１８】
〔典型的な動作環境〕
図１及び下記の論述は、本発明が実施されるのに適当なコンピューティング環境に関する簡潔で一般的な記述を与えることを意図している。本発明はサーバー・コンピュータ上で走るコンピュータプログラムのコンピュータが実行可能な命令の一般的な状況下で記述されるが、当業者は本発明は他のプログラム・モジュールとの組み合わせでも実行できることを理解するであろう。一般的に、プログラム・モジュールは、特別なタスクを実行するか又は特別な抽象データ・タイプを実装するルーチン、プログラム、コンポネント、データ構造、などを含む。更に当業者は、本発明は、シングル又はマルチ・プロセッサ・コンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、パソコン、ハンドヘルド・コンピューティング・デバイス、マイクロプロセッサ・ベース又はプログラムが可能の消費者電子機器、及び、その他、を含む他のコンピュータシステム構成と共に実施できるであろうことを理解するであろう。本発明の例示される実施例は、又通信ネットワークを通じて結ばれている遠隔処理機器によってタスクが実行される分散コンピューティング環境においても実行される。しかし、本発明の幾つかの実施例はスタンドアロン・コンピュータ上でも実行可能である。分散コンピューティング環境においては、プログラム・モジュールはローカル及び遠隔記憶蓄積機器の両者に配置されるであろう。
【００１９】
図１を参照して、本発明の実装のための典型的なシステムは、処理ユニット21、システムメモリ22、およびシステムメモリを含む各種のシステムコンポネントを処理ユニット21に結合するシステムバス23、を含む通常のサーバー・コンピュータを含む。処理ユニットは市販されている種々のプロセッサ、例えば、Intelx86, Pentium及び Intel社や Cyrix社,AMD社, Nexgen社等の供給する互換性のあるマイクロプロセッサ;Digital社のAlpha; MIPS Technology社,NEC社,IDT社,Siemens社等の供給するMIPS;IBM社及びMotorola社の供給するPowerPC;等々の何れでも良いであろう。デュアル・マイクロプロセッサ及び他のマルチプロセッサ・アーキテクチャもまた、処理ユニット21として使用できる。
【００２０】
システムバスは、メモリバス又はメモリコントローラ、周辺装置バス、及び少しばかり列挙すればPCI,VESA,Microchannel,ISA,EISAなどの各種の通常のバスアーキテクチャの何れかを使用するローカルバス、を含む数種類のバス構造の何れかであろう。システムメモリは読み出し専用メモリ(ROM)24 及びランダムアクセスメモリ(RAM)25 を含む。スタートアップ中のように、サーバー・コンピュータ20内のエレメント間で情報を転送するのを支援する基本ルーチンを含む基本入出力システム(BIOS)は ROM24中に記憶される。
【００２１】
サーバー・コンピュータ20は、更にハードディスクドライブ27、取り外すことのできるディスク29に読み書きするための磁気ディスクドライブ28、及びCD‐ROM ディスク31からの読み取りと他の光学的媒体に読み書きするための光ディスクドライブ30を含む。ハードディスクドライブ27、磁気ディスクドライブ28、及び光ディスクドライブ30は、それぞれハードディスクドライブ・インタフェース32、磁気ディスクドライブ・インタフェース33、及び光ディスクドライブ・インタフェース34によりシステムバス23に接続されている。ドライブ及びそれらに関係するコンピュータが読み取れる媒体は、データの非揮発性記憶装置、データ構造、コンピュータが実行可能な命令、などをサーバー・コンピュータに供給する。前記のコンピュータが読み取れる媒体の記述には、ハードディスク、取り外すことのできる磁気ディスク及びCDを引き合いに出しているが、当業者には磁気カセット、フラッシメモリカード、ディジタルビデオディスク、ベルヌイユ(Bernoulli) カートリッジ、及び同種のもののようなコンピュータにより読み取ることができる他の型のメディアも又典型的な動作環境において使用できるであろうことが理解されるべきである。
【００２２】
多数のプログラムモジュールは、オペレーティングシステム35, １個又は複数個のアプリケーションプログラム36, その他のプログラムモジュール37, 及びプログラムデータ38を含むドライブ及びRAM 25に記憶されるであろう。例示のサーバー・コンピュータ中のオペレーティングシステム35は Microsoft Windows NTServerオペレーティングシステム、及び前記のMicrosoft Transaction Serverである。
【００２３】
利用者は、キーボード40又はマウス42のようなポインティング・デバイスによってサーバー・コンピュータ20に命令及び情報を入力できる。（ここに示されていない）他の入力装置は、マイクロフォーン、ジョイスティック、ゲームパッド、衛星ディッシュアンテナ、スキャナー、又は同種のものを含むであろう。これら及び他の入力装置は、システムバスに結合はされているが、パラレルポート、ゲームポート又はユニバーサル・シリアル・バス(USB) のような他のインタフェースによって接続されているであろうシリアルポート・インタフェース46を通じて処理ユニット21にしばしば接続される。モニタ47又は他の種類のディスプレイ装置は、又ビデオアダプタ48のようなインタフェースを経てシステムバス23に接続される。モニタとは別に、サーバー・コンピュータは、スピーカやプリンタのような（ここには、示されていない）他の周辺装置を一般的に含んでいる。
【００２４】
サーバー・コンピュータ20は、遠隔クライアント・コンピュータ49のような１又は複数の遠隔コンピュータに対する論理的接続を使用してネットワークした環境で使用できる。遠隔コンピュータ49は、ワークステーション、サーバー・コンピュータ、ルータ、ピア装置又は他の共通ネットワークノードであり、且つ図１には１個の記憶蓄積装置50のみが表示されているが、サーバー・コンピュータ20に関連して記述された多数又は全てのエレメントを一般的に含んでいる。図１に表示の論理接続はローカル・エリア・ネットワーク(LAN)51 及びワイド・エリア・ネットワーク(WAN)52 を含む。そのようなネットワーキング環境は、事務所、企業内のコンピュータ・ネットワーク、イントラネット、及びインターネットにおいて通常的なことである。
【００２５】
LAN ネットワーキング環境で使用される時には、サーバー・コンピュータ20はネットワーク・インタフェース又はアダプタ53によってローカル・ネットワーク51に接続される。WAN ネットワーキング環境で使用される時には、サーバー・コンピュータ20は, 一般的にモデム54を含むか、LAN 上の通信サーバーに接続されているか、又はインターネットのようなワイド・エリア・ネットワーク52上に通信を確立する他の手段を有する。内蔵又は外付けのモデム54は、シリアルポート・インタフェース46を介してシステムバス23に接続される。ネットワーク化環境において、サーバー・コンピュータ20に関連して記述されたプログラム・モジュール又はその部分は遠隔記憶蓄積装置に記憶されるであろう。示されたネットワーク接続は典型的なものであり、且つコンピュータ間に通信リンクを設定する他の手段も使用できることが理解されるであろう。
【００２６】
コンピュータ・プログラミングの当事者の習慣に準拠して、本発明は、特記しない限り、特に他の記述がなければ、下記においてサーバー・コンピュータ20により実施されるアクト(act) 及びオペレーションの記号表現を参照して記述する。そのようなアクト及びオペレーションは、時としてコンピュータにより処理されたと言われることもある。アクト及び記号による表現されたオペレーションは、電気的信号表示の変換又は減少をもたらすデータビットを表す電気的信号のプロセシング・ユニット21による操作、及びそこにおいてコンピュータシステムのオペレーション及び信号の他の処理を再構成又は変更するために、データビットを記憶システム( システムメモリ22、ハードドライブ27、フロッピディスク29及びCD‐ROM31 を含む) 中の記憶位置に維持することを含むことが理解されるであろう。データビットが維持される記憶位置は、該データビットに対応する特別な電気的、磁気的、又は光学的属性を有する物理的位置である。
【００２７】
〔MTS プログラミングモデルの概観〕
図２は、本発明に準拠の補償型リソース・マネージメントが組み込まれているMicrosoft Transaction Server(MTS) のサーバー・アプリケーション実行環境を示す。MTS 実行環境82は、前記の "組み込まれたMTS 特許申請" に一層詳細に記述されている。
【００２８】
次に図２を参照して、トランザクション・サーバー・エクゼクティブ80は、サーバー・コンピュータ84上のサーバー・アプリケーション・コンポネント( 例えば、サーバー・アプリケーション・コンポネント86) によるオンライン・トランザクション処理をサポートするランタイム実行環境80を作成するためのランタイム又はシステム・サービスを供給する。トランザクション・サーバー・エクゼクティブ80は、又サーバー・アプリケーション・コンポネント86へのスレッド及びコンテキスト管理に対するサービスも提供する。更に、トランザクション・サーバー・エクゼクティブ80は、コンポネント・インテグレーション・インタフェースをサポートする（コンポネント・コンテキスト・オブジェクト136 を含む）システム定義オブジェクトを供給する。例示されたトランザクション・サーバー・エクゼクティブ80は、ダイナミック・リンク・ライブラリ("DLL") として実装される。(DLLは実行可能コードをアプリケーション・プログラム処理へのダイナミック・リンク又はランタイム・リンクを許容する周知の実行可能なファイル書式である。) トランザクション・サーバー・エクゼクティブ80は、サーバー・アプリケーション・コンポネントをホストし且つこれらのプロセスの背景で透明にランするアプリケーション・サーバー・プロセス (例えば"ASP"90)へ直接にロードされる。
【００２９】
例示されたASP 90は、サーバー・アプリケーション・コンポネントの実行をホストするシステム・プロセスである。各ASP 90は "パッケージ" と呼ばれる集合にグループ化される複数のサーバー・アプリケーション・コンポネントをホストできる。また、複数のASP 90は、サーバー・コンピュータ上でマルチスレッドでマルチタスクのオペレーティング・システム（例えば、例示の実施例においてはMicrosoft Windows NT） の下で実行できる。各ASP 90は、サーバー・アプリケーション・コンポネントに対して、分離された信頼境界及び障害隔離ドメインを提供する。換言すれば、分離されたASP でランしている時に、そのASP を終了させる原因となる１個のサーバー・アプリケーション・コンポネントによる故障は、一般的に他のASP のサーバー・アプリケーション・コンポネントに影響を与えない。例示された実施例において、複数のサーバー・アプリケーション・コンポネントは、"the COM Explorer"と呼ばれる管理ユーティリティを使用する１個のASP 中に共に走らせるパッケージとしてグループ化される。このユーティリティは、コンポネントをパッケージにグループ化することを含むサーバー・アプリケーション・コンポネントに関する属性を管理するためのグラフイカル・ユーザー・インタフェースを供給する。
【００３０】
図２に示される典型的なインストレーションにおいて、実行環境80は、該実行環境においてサーバー・アプリケーション・コンポネントにアクセスする多数のクライアント・コンピュータ92を有する分散コンピュータ・ネットワークに接続されるところのサーバー・コンピュータ84（それは上述のコンピュータ20の一例であろう）上に存在する。他の方法として、実行環境80は、単一コンピュータ上に存在し、且つクライアント・プロセスによってアクセスされる該コンピュータ上に常駐のサーバー・アプリケーション・コンポネントをホストするかもしれない。
【００３１】
ASP 90の実行環境80内にホストされるサーバー・アプリケーション・コンポネント86は、大学登録アプリケーションにおけるクラス登録又はオンライン・セールス・アプリケーションにおける注文を管理するコードのようなサーバー・アプリケーションのビジネス論理を実装する。典型的には、各サーバー・アプリケーションは、アプリケーション業務の一部に対するプログラム・コードをそれぞれが所有する複数のコンポネントを有する。例えば、バンキング・アプリケーションは、該アプリケーションにおいて送金操作業務の部分を実行する送金コンポネント、口座減算コンポネント、及び口座加算コンポネントを有するであろう。このバンキング・アプリケーション例における口座減算コンポネントは、バンキング・データベース中の特定の口座から特定の金額を減算するためのプログラム・コードを実装する。口座加算コンポネントは、バンキング・データベース中の特定の口座に特定の金額を加算するためのプログラム・コードを実装する。送金コンポネントは、２個の口座間で金銭の移動を実行するために口座減算コンポネント及び口座加算コンポネントを使用するプログラム・コードを実装する。
【００３２】
例示の実施例におけるサーバー・アプリケーション・コンポネント86は、Microsoft Corporation のOLE および ActiveX仕様のComponent Object Model("COM") に準拠するが、それに代わりObject Management Group のCOBRA(Common Object Request Broker Architecture)仕様を含む他のオブジェクト標準に従って実装できる。OLE のCOM 仕様はソフトウエア・コンポネントの統合化を促進するコンポネント及びそれらのインタフェースに対するバイナリー標準を定義する。合意事項により、COM オブジェクトのインタフェースは図２のサーバー・アプリケーション・コンポネント86に対して示されるように、プラグイン・ジャックとして図式的に表示される。また、インタフェースは従来から大文字“Ｉ”で始まる名称が与えられる。OLE に関する詳細な説明は、1995年、米国Redmond,Washington所在の Microsoft Press社刊行のKraig Brockschmidt著"Inside OLE"第２版を参照されたい。
【００３３】
図２の実行環境80において、サーバー・アプリケーション・コンポネント86は、ASP 90中のトランザクション・サーバー・エクゼクティブ80の制御の下に実行される。トランザクション・サーバー・エクゼクティブ80は、サーバー・アプリケーションDLL300をASP 90にローディングし、且つサーバー・アプリケーション・コンポネント86をクラス・ファクトリー(class factory)122を使用して例示する責任を有する。トランザクション・サーバー・エクゼクティブ80は、更に（同一のコンピュータ上、又はネットワーク接続上に存在する）クライアント・プログラムからサーバー・アプリケーション・コンポネント86へのコールを管理する。
【００３４】
例示された実行環境80は、COM 必要条件を準拠することに加えてサーバー・アプリケーション・コンポネント86にある種の追加の要求条件を課す。第１に、サーバー・アプリケーション・コンポネントはDLL ファイル（即ち、図３のサーバー・アプリケーションDLL120）に実装される。（さもなければ、COM オブジェクトは実行可能な(".exe")ファイルに実装できる。）第２は、コンポネントのDLLファイル120 は標準クラス・ファクトリー122 を所有する。（すなわち、DLL はDllGetClassObject 方法を実装し且つエクスポートし、並びにIClassFactory インタフェースをサポートする。）第３に、サーバー・アプリケーション・コンポネントは標準化できるインタフェースのみをエクスポートするが、コンポネントのインタフェースの意味はタイプ・ライブラリにより記述されるかプロキシ・スタブ(proxy‐stub)DLLを有する。プロキシ・スタブDLL は、クライアント・コンピュータ92上のクライアント・プロセス132 にプロキシ・コンポネント130 を、及びサーバ・コンピュータ84上のASP 90にスタブ・コンポネント131 を供給する。プロキシ・コンポネント130 及びスタブ・コンポネント131 は、サーバー・コンピュータ84を介してクライアント・プログラム134 からのコールを導く。例示システム中のプロキシ・スタブDLL は、Oicfコンパイラスイッチを持つMicrosoft Windows NT 4.0のためのMicrosoft Win32 SDK を具えたMIDL version 3.00.44を使用して構築され、且つトランザクション・サーバー・エクゼクティブ80にリンクされる。これらの追加の要求条件は既知の手法に準拠する。
【００３５】
サーバー・アプリケーション・コンポネント86のクライアント・プログラム134 は、サーバー・アプリケーション・コンポネントを使用するプログラムである。クライアント・プログラムは、実行環境80の外( トランザクション・サーバー・エクゼクティブ80の制御外) でランするプログラム・コード( 例えば、アプリケーション・プログラム、COM オブジェクトなど) である筈である。そのようなクライアント・プログラムは"base clients"として参照される。他の方法として、クライアント・プログラム134 は、( 同一又は別のASP 90における) トランザクション・サーバー・エクゼクティブの制御の下でランする他のサーバー・アプリケーション・コンポネントでも有りうる。クライアント・プログラム134 は、サーバー・コンピュータ84上、又は（この場合、クライアント・コンピュータはプロキシ・オブジェクト130 及びスタブ・オブジェクト131 を介して遠隔的にサーバー・アプリケーション・コンポネント86と対話する） 図２に示めされる別のクライアント・コンピュータ上に存在できる。
【００３６】
サーバ・コンピュータ84は又リソース・マネージャ140 及びリソース・ディスペンサ144 をランさせる。リソース・マネージャ140 は耐久性のあるデータ( 例えば、データベース146 中のデータ) を管理するシステム・サービスである。サーバー・アプリケーション・コンポネント86は、( オンライン販売サーバー・アプリケーション中の、手元にある在庫の記録、未処理注文、及び入金口座のような) サーバー・アプリケーションの耐久性のある状態を維持するためにリソース・マネージャを使用できる。例示された実施例におけるリソース・マネージャは、Microsoft SQL Server, 耐久性のあるメッセージ行列、及びトランザクション・ファイル・システムを含む。可能ならば、リソース・マネージャ140 は、トランザクション・ベースで( 即ち、既知のACIDプロパティに準拠するトランザクションにおいて) サーバー・アプリケーション・コンポネント86によってサーバー・アプリケーションの耐久性のある状態へ変化又は更新することを支援することが望ましい。
【００３７】
リソース・ディスペンサ144 は、ASP 90中のサーバー・アプリケーション・コンポネントに代わって非耐久性共用状態を( 即ち、耐久性の補償なしに) 管理するサービスである。リソース・ディスペンサは、又前記の組み込まれたMTS 特許申請に記述されているように、例示の実行環境への自動トランザクション登録への責任も有する。例示の実施例におけるリソース・ディスペンサ144 の例は、Microsoft Open Database Connectivity("ODBC")コール・レベル・インタフェースに準拠のデータベース接続の集合を維持するODBCリソース・ディスペンサを含む。ODBCリソース・ディスペンサは、データベース146 からのデータを評価するためにサーバー・アプリケーション・コンポネントへのデータベース接続を( 一般的に、そのリソース・マネージャ140 を介して) 配分する。更に、ODBCリソース・ディスペンサは、後刻の再使用サーバー・アプリケーション・コンポネントによって開放される時にデータベース接続の回復をリクレームする。
【００３８】
例示の実行環境82は更にトランザクション・マネージャ148 を含む。トランザクション・マネージャ148 は、リソース・マネージャが分散ネットワーク中の１個以上のサーバー・コンピュータに存在する場合を含む複数のリソース・マネージャに分散するトランザクションをコーディネートするシステム・サービスである。トランザクション・マネージャ148 は、１個のトランザクションに関連する全てのリソース・マネージャに渡っての更新は障害（例えば、コンピュータ又はネットワークのハードウエア又はソフトウエアの障害、誤動作したリソース・マネージャ又はアプリケーションに起因するエラー）、競合条件（例えば、１個のリソース・マネージャがアボートを開始する一方でコッミトを開始するトランザクション）、又はアベイラビリティ（リソース・マネージャがトランザクションを準備するが決してリターンしない）に無関係に周知の２フェーズ・コッミト・プロトコルを使用するACIDプロトコルに準拠して発生することを保証する。例示のトランザクション・マネージャ148 は、Microsoft SQL Server6.5 の一部としてレリーズされたMicrosoft Distributed Transaction Coordinator(MSDTC)である。
【００３９】
〔補償型リソース・マネジャーのアーキテクチャ〕
次に図３を参照して、補償型リソース・マネジャー(CRM) のコンポネント又はオブジェクト・ベースのアーキテクチャ200 は、リソースに特有の完全なリソース・マネジャー及びリソース・ディスペンサ（例えば、図２のリソース・マネジャー140 及びリソース・ディスペンサ144 ）を実装する必要なしに、開発者が一層迅速に且つ容易に耐久性のあるデータ記憶装置を持つリソースをMTS 実行環境82（図２）へ統合できるように、多数のシステムが供給したコンポネント及びシステムが定義するインタフェースを含む。例示のアーキテクチャ200 は特に２個のリソース・シナリオ、即ち (1)トランザクション処理の独自の内部メカニズムを持つが、OLE トランザクション・インタフェースをサポートしない遺物か、ブラックボックスのトランザクション処理システム；及び (2)トランザクション・サポートの無いリソース；に適用できる。アーキテクチャ200 は、OLE トランザクション・インタフェースに対するサポート持つリソース・マネジャー・インフラストラクチャを供給し、且つリソース・マネジャーに対するリソース・ディスペンサを持つ必要性を無くすることにより、前記(1) のシナリオにおけるMTS環境82（図２）へ容易に統合することを許す。更に、アーキテクチャ200 は各シナリオ中のリソースに対し、本発明に準拠の補償型リソース・マネージメントの使用により、一層簡単で一層開発が容易なリソース・マネジャーと統合されることを許す。
【００４０】
例示の補償型リソース・マネジャーのアーキテクチャでは、開発者はリソースの補償型リソース・マネージメントを供給するためにアーキテクチャ200 のシステムが供給するコンポネント及びインタフェースを使用する CRMワーカー202 と CRMコンペンセータ206 のみを実装する必要がある。 CRMワーカー202 と CRMコンペンセータ206 は COMオブジェクト・モデルに準拠するコンポネントである。 CRMワーカー202 と CRMコンペンセータ206 は、如何なる MTSサーバー処理（例えば、ASP 90）においても使用できるように、典型的に MTSライブラリ・パッケージに実装される。
【００４１】
CRM ワーカー202 において、開発者はトランザクションの一部としてリソース上で正常アクションを実行するために該リソースに特有のロジック（即ち、プログラム・コード）を実装する。開発者は、又CRM ワーカー202 がリソースに対して正常アクションを実行する原因となるコールをサーバー・アプリケーション・コンポネント86をそれに対して発生できるようにリソースに特有のインタフェース( 例えば "IDoWork"インタフェース210)を実装する。CRM ワーカー202 は、正常アクションの結果はリクエストの直後においてリソース上で耐久性であるように、サーバー・アプリケーション・コンポネントの該リクエストの時点においてリソース上で正常アクションを行う。
【００４２】
一方、開発者は、CRM ワーカー202 の正常アクションに関係する補償アクションを供給するCRM コンペンセータ206 中のロジックを実装する。開発者は更に、CRM コンペンセータがトランザクション・マネージャ148 （図２）から準備、コミット、及びアボートのノーティフィケーションを受けるシステムが定義したインタフェース ("ICompensatingResourceManager"インタフェース212)をサポートするためにCRM コンペンセータを実装する。トランザクション・マネージャからのこれらのノーティフィケーションは、システムが供給したインフラストラクチャである下記の障害回復エンジン及びCRK クラークの方法でCRM コンペンセータへ伝達される。CRM ワーカー202 が正常アクションを実行したトランザクションの準備フェーズ中、状況がトランザクションの成功裏での完了を妨げるような場合にCRM コンペンセータは準備ノーティフィケーションへの対応としてトランザクションをアボートさせるようにできる。トランザクションの第２フェーズにおいて、CRM コンペンセータはリソースに対するCRM ワーカーの正常アクションに適切なクリーンアップ・アクションを実行することにより、コミット・ノーティフィケーションに答えることができる。他の方法として、CRM コンペンセータはCRM ワーカーの正常アクションをリバースする補償アクションを実行することにより、アボート・ノーティフィケーションに答えることができる。
【００４３】
CRM ワーカー及びCRM コンペンセータの正常、クリーンアップ及び補償のアクションは、管理されている特定の耐久性のあるリソースに応じて一般的に変化する。例えば、リソースがファイル・システム又はデータベースの場合は、アクションはデータの変更、新規データの書き込み、又はデータの消し込みのようなデータ処理活動を含むことができる。幾つかのリソースの場合に、CRM コンペンセータのクリーンアップ及び補償のアクションは、データ処理に加えて、逆にできない実社会の結果であろうATM 又は他の自動払出し機械からの現金、切符又は他の物品の払出しのような活動を含むことができる。（逆にできない物理的社会の結果を持つそのような操作はここでは「現実の操作」("real operations") として参照する。）
【００４４】
CRMアーキテクチャ200 の追加のコンポネントは、MTS ランタイム環境及びサービスにこのように組み込まれ、このようにして" システムにより供給されて"いる。これにより開発者は特定のリソースに対して特有なCRM ワーカー及びCRMコンペンセータのみを実装し、ロギング、障害回復、及びスレッド・セイフティのような事項を処理するサービスの提供にはシステムにより供給されたコンポネントに依存することができる。例示されたアーキテクチャ200 のシステムにより供給されたコンポネントは、CRM クラーク222 、CRM 障害回復クラーク224 、及び耐久性のあるログ(persistent log)226 を含む。これらのコンポネントの全てはアプリケーション・サーバー・プロセス(ASP)90 （図２にも示されている）内でランする。
【００４５】
CRM アーキテクチャ200 は、アーキテクチャのシステムにより供給されたコンポネントはどのスレッドからもコールできることを意味する個別にスレッド・セーフであることにおいて、スレッド・セーフティを供給する。更に、CRM アーキテクチャ200 は、MTS とインタフェースするために要求されるOLE トランザクション・インタフェースの全てをサポートする。CRM アーキテクチャ200 は、アーキテクチャのファンクショナリティのコンシューマ(consumer)（即ち、サーバー・アプリケーション・コンポネント86）はそれら自体スレッド・セーフであることを保証しない。CRM アーキテクチャ200 は、CRM コンペンセータへの全てのコールを、標準のCOM プログラム作成方法に準拠してCRM コンペンセータがその中に作成された同一アパートメント内に向かわせることを保証する。換言すれば、CRM アーキテクチャは、そのコンジューマは少なくともアパートメント・モデル・コンポネント（周知のスレッディング・モデル）であることを想定する。
【００４６】
CRM クラーク222 及びCRM 障害回復クラーク224 は、アーキテクチャ200 中でロギング及び障害回復サービスを提供する。正常操作中、各CRM ワーカー202 はCRM クラークの自分自身のインタンスを作成する。（即ち、CRM ワーカーとCRMクラークとの間に１対１の関係がある。）CRM ワーカー202 は、耐久性のあるログ226 にログすべき情報を行列させるためにシステムが定義したインタフェースであるICrmLogControlインタフェース230 を介してCRM クラーク222 にアクセスする。CRM クラークは、ログに書き込まれる前に追加の情報をログ記録に加えるであろう。正常プロセシングの間、CRM クラーク222 は、又必要に応じてCRM コンペンセータをインスタンシエート(instantiate) し、且つ２フェーズ・コミット・ノーティフィケーションをCRM コンペンセータへ通じさせる責任も有する。
【００４７】
CRM 障害回復クラーク224 は、コンピュータ・システムにおける全ての補償型リソース・マネジャーに共通のログ及び障害回復マネージャとして動作する。CRM 障害回復クラーク224 は、ASP 90中にCRM 障害回復クラークの常に１個のインスタンスのみが存在することを意味するシングルトンCOM コンポネントである。CRM 障害回復クラーク224 は、CRM コンポネントをホストするMTS サーバー・プロセス（例えば、ASP 90）がスタートする時に自動的にイニシエートされる耐久性のあるログ226 上での第１次の障害回復を実行する。その後は、CRM 障害回復クラーク224 は、ログ上のチェック・ポイントをイニシエートし、且つそれを通じてCRM クラークが監視されるセントラル・ポイントを供給するためにアクティブ状態に留まる。
【００４８】
CRM 障害回復クラーク224 は、"CoCreateInstance()"API 方法をCRM 障害回復クラークのCLSID と共に呼び出すことにより得られる"ICrmMonitor" インタフェース234 をサポートする。"ICrmMonitor" インタフェース234 は、ASP 90中のCRM に対し何れのトランザクションが現在進行中であるかを( 操作者又は監視者にユーザ・ディスプレー又は対話を提供するプログラム又はCOM コンポネントによるような方法で) 監視するのに使用される。CRM コンペンセータ206 の登録( 下記の"RegisterCompensator()" 方法参照) の時にCRM ワーカーにより供給されるテキスト記述は、特定のCRM 活動を探索するのを援助するために利用可能である。
【００４９】
"ICrmMonitor" インタフェースは、補償型リソース・マネジャー・アーキテクチャ200 のCRM クラーク222 をトラックするクラーク・コレクション・オブジェクト上の"ICrmMonitorClerks" インタフェースへのインタフェース・ポインタを得るための方法("GetClerks()") を供給する。"ICrmMonitorClerks" インタフェースは図17に示めされるプログラム・リスティング319 において定義される。このインタフェースを通じて、CRM クラーク222 上にサポートされる"ICrmMonitorLogRecords" インタフェースへのポインタが得られる。"ICrmMonitorLogRecords" インタフェースは、下記の人手による障害回復のようなことのために、与えられたトランザクションに対する特定のCRM クラークにより維持される個別のログ記録を監視するのに使用される。"ICrmMonitorLogRecords" は、図16に示めされるプログラム・リスティング318 において定義される。
【００５０】
CRM を使用の各ASP 90は、ログ記録を記憶するための自分自身に関係する耐久性のあるログ226 を所有するであろう。例示されたCRM アーキテクチャ200 中の耐久性のあるログ226 はASP 90に関連するAPPLD に基づくファイル名を持つTXFフォーマットのログ・ファイルである。( 下記の"ForceLog()"方法への応答として) ログ記録を書き込む時に、CRM クラーク222 は耐久性のあるログ226 中に連続する順序でログ記録を書き込む。CRM 障害回復クラーク224 は、又トランザクション終了後に開放されたログ記録からスペースの返還をリクレームするために耐久性のあるログ226 中にチェック・ポイントをイニシエートする。
【００５１】
CRM ワーカー202 は，CRM アーキテクチャ200 がCRM コンペンセータ206 に２フェーズ・コミット・プロトコル・ノーティフィケーションに応答しての適切なアクション( 例えば、準備中のボート・アクション、コッミトに対するクリーンアップ・アクション、又はアボートに対する補償アクション) を取らせるために、サーバー・アプリケーション・コンポネント86に代わってリソースに対して正常アクションを実行する時に典型的ではあるが、必ずしも必要とはしないが、ウライト・アヘッド・ベースにより耐久性のあるログ226 中へ( 前記のように、CRMクラーク222 及びCRM 障害回復クラーク224 を通じて) 十分な情報をログする。CRM ワーカー202 は，又CRM コンペンセータ206 のクラス識別子("CLASID")をCRF クラーク222 と共に登録する。後刻、トランザクションが終了（それは、MTS環境においては、典型的に、前記の組み込まれたMTS 特許申請に記述されたように、トランザクション中のサーバー・アプリケーション・コンポネント86からのSetComplete 又はSetAbortのコールに対する応答である）する時に、CRM クラーク222 はCRM コンペンセータ206 を作成し、且つトランザクション・マネージャ148 （図２）から受け取る２フェーズ・コミット・ノーティフィケーションのそれぞれに対しそのICrmCompensator(又はICrmCompensatorVariants)インタフェース212 上に適切な方法を呼び出す。２フェーズ・コミット・ノーティフィケーションと共に、CRF クラーク222 はトランザクションのためにCRM ワーカー202 により書き込まれたログ記録を、トランザクション中のアクション順序を維持するためにコミットに対しては前方向へアボートに対しては逆方向へと、個別に送信する。CRM コンペンセータ206 は、又障害回復中に必要になるであろう自分自身の補償アクションの情報を耐久性のあるログにログできる。CRM ワーカー202 とCRM コンペンセータ206 は、このようにして耐久性のあるログ226 を通じてのみ状態を共有する。
【００５２】
例示アーキテクチャ200 中の耐久性のあるログ226 は、ログ・オブジェクト240 、障害回復エンジン242 、及びログ・ファイル244 として実装される。ログ・オブジェクト240 は、ログ記録の連続するストリームをカプセル化し、且つログ記録の連続するストリームをログ・ファイル244 中に安定に書き込む責任を有する。ログ・オブジェクト240 は、CRM クラーク222 、CRM 障害回復クラーク224及び障害回復エンジン242 により使用される"ILog"インタフェース246 を介してログ・ファイル244 からログ記録を読み書きするための方法を供給する。
【００５３】
ログ・ファイル244 はログ記録が記憶されるファイル・システムの１個のファイル又はファイルの集合のような非揮発性記憶装置（例えば、図１のハード・ディスク・ドライブ）に記憶される連続するデータ・ストリームである。例示のログ・ファイル244 は、Microsoft TXF ファイル・フォーマットを持つファイルである。例示のログ・ファイル244 中の各ログ記録は、連続ストリーム中で64ビット整数を単調に増加させるログ・シーケンス番号(LSN) により識別される。個別のログ・ファイルがコンピュータ20（図１）上の各ASP 90のために維持されている。例示アーキテクチャ200 において、ログ・ファイル244 は、各ASP 90に関係する独自の識別子( 例えば、Microsoft Windows NTオペレーティング・システム中の"Appld")に基づくファイル名により識別され、且つトランザクション・マネージャ148 のログとして同一ファイル・システム・パス上に常駐する。これはログに基づく障害回復を容易にする。
【００５４】
障害回復エンジン242 は、障害から障害回復を実行させるためのログ障害回復プロトコルに従ってログ・ファイル244 からログ記録を処理するために"ILogRecover" インタフェース248 及び"IlogRecoverClerkRegistration"インタフェースを介してサービスを提供するCOM オブジェクトである。例示の障害回復エンジン242 に実装される障害回復プロセシングは、他のログ障害回復プロトコル又はそれの変形が代わりに使用できるが、周知のARIES ログ障害回復プロトコルに基づく。(Michael Stonebraker編"Readings in Database Systems"第２版,1994’中のC.Mohan,D.Haderle,B.Lindsay,H.Pirahesh及びP.Schwarz による"ARIES：A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging"を参照のこと) CRM 障害回復クラーク224 及びCRM クラーク222 は、これらのエンティティにより書き込まれるログ記録が障害回復中に障害回復エンジン242 によって供給されるように、障害回復エンジン242 と共に登録される。障害回復エンジン242 は、又CRM ワーカー202 及びCRM クラーク222 が関与するトランザクション上のトランザクション・マネージャ148 （図２）と共に登録する。アーキテクチャ200 の正常操作中に、障害回復エンジン242 は、トランザクション・マネージャ148 から２フェーズ・コミット・ノーティフィケーションを受け取り、且つ該ノーティフィケーションをトランザクションに関係するログ記録と共にCRM コンペンセータ206 を作成し且つ該CRM コンペンセータ206 により適切な補償アクションをイニシエートことにより該ノーティフィケーションに反応するCRM クラーク222 に伝達する。障害回復エンジン242 は、トランザクション・マネージャ148 と共にトランザクションに登録し、且つOLE トランザクション・インタフェースを使用するトランザクション・マネージャから２フェーズ・コミット・ノーティフィケーションを受け取る。CRM クラーク222 及びCRM 障害回復クラーク224 は、クラークがその上に障害回復エンジン242 から２フェーズ・コミット・ノーティフィケーションを受け取る（"ILogRecoverClerk"インタフェース，"ILogRecoverClerkRecordsOnTerminate"インタフェース，及び "ILogRecoverClerkPhaseNotification"インタフェースを含む）１組のインタフェースを実装する。
【００５５】
〔オペレーティング・シークエンス〕
図４は例示のCRM アーキテクチャ200 内でのコンピュータの実行順序を説明する。当初、サーバー・アプリケーション・コンポネント86はステップ251 に示されるような通常のCOM オブジェクト・インスタンシエーション手法を使用してCRM ワーカー202 を作成する。サーバー・アプリケーション・コンポネント86がトランザクションを持つ場合は、MTS 実行環境82は、( 前記に参照文献として取り込まれている) 米国特許出願No.08/959,141"Automatic Transaction ProcessingOf Component-Based Server Applications"に記述のトランザクションに自動的に CRMワーカー202 を関連させる。
【００５６】
次のステップ252 において、CRM ワーカー202 は、CRM クラーク222 のインスタンスを作成し、且つ"CreateInstance()"方法（オブジェクト・インスタンシエーションのために使用されるCOM ランタイム・ライブラリにおける周知のアプリケーション・プログラミング・インタフェース(API) 方法）を呼び出し、且つCRM クラーク222 のCLSID 及びICrmLogControlインタフェースのIID を規定することによりCRM クラーク222 のICrmLogControlインタフェース230 へのインタフェース・リファレンスを得る。これは又CRM クラーク・インスタンスを自動的にトランザクション中に関連させる。
【００５７】
ICrmLogControlインタフェース・リファレンスを得た後、CRM ワーカー202 は、ステップ253 に示すようにCRM ワーカー202 に対する補完者のCRM コンペンセータ206 をCRM クラーク222 と共に登録するためにインタフェースの"RegisterCompensator()" 方法を呼び出す。CRM ワーカー202 は、後刻CRM コンペンセータ206 を作成するためにCOM の下でCRM クラーク222 のために十分なアイデンティフィケーションを与える、そのクラスの識別子（例えば、プログラム識別子(PROGID)又はクラス識別子(CLSID) ）によってCRM コンペンセータ206 を登録する。
【００５８】
更に、CRM クラーク222 は、CRM 障害回復クラーク224 と共に自分自身、及びCRM クラーク・クラスの特定のインスタンスに関連するグローバリ・ユニーク(globally unique) 識別子(GUID)を使用する障害回復エンジン242 を登録する。障害回復クラーク224 は、障害回復において後刻CRM クラーク222 を再作成できるように何れものアクティブなCRM クラークをログ226 と共にログする。CRM クラークが障害回復エンジン242 と共に登録される時に、障害回復エンジン242 は、サーバー・アプリケーション・コンポネントのトランザクション上にトランザクション・マネージャと共に登録される。これにより障害回復エンジン242 はトランザクション中のトランザクション・マネージャにより出される２フェーズ・コミット・ノーティフィケーションを受け取り、且つ該ノーティフィケーションをCRM クラーク222 へ渡せるようになる。
【００５９】
次のステップ254 において、サーバー・アプリケーション・コンポネント86は、CRM ワーカー202 がそのトランザクションの一部としてリソース上にワークを実行することをリクエストする。CRM ワーカー202 はリクエストされたワーク（即ち、その正常アクション）を実行するので、CRM ワーカーは、CRM コンペンセータが適切なクリーンアップ及び補償アクションが取れるようにCRM クラーク222 を使用する耐久性のあるログへステップ255 において十分な情報を先ずログする。下記に説明するように、 CRMワーカー202 は ("WriteLogRecord()"方法又は"WriteLogRecordVariants()"方法を使用する)CRMクラーク222 に１連のログ記録を書き込み、次いで("ForceLog()" 方法を使用する) リクエストされたワークを実行する前にライトアヘッド・ベースで耐久性のあるログへ該記録を書き出させるようにする。
【００６０】
後刻、ステップ256 において、トランザクション・マネージャ148 は CRMワーカー202 によって以前に書かれたログ記録と共にノーティフィケーションを CRMクラーク222 に渡す障害回復エンジン242 を含むトランザクション上のパーティシパント(participants)（即ち、該トランザクションにリストされたコンポネント）へ２フェーズ・コミット・プロトコル・ノーティフィケーションを発行する。典型的に、これらのノーティフィケーションは、トランザクションをイニシエートしたサーバー・アプリケーション・コンポネント86がトランザクション中の全てのワークが完了していることを示すSetComplete を呼び出したか、又はトランザクション中のコンポネントがワークは成功裏には完了できないことを示すSetAbortを呼び出す後に送出される。 SetComplete及びSetAbortは、システムにより供給されるコンテキスト・オブジェクト136 （図２）のインタフェース方法であり、且つ前記の組み込まれたMTS 特許申請に一層詳細に記述されている。トランザクション・マネージャ148 は、(OLEトランザクション・インタフェースの一部である)ITransactionResourceAsyncインタフェース238 上の障害回復エンジン242 へ、２フェーズ・コミット・プロトコル・ノーティフィケーションを発行する。
【００６１】
各２フェーズ・コミット・プロトコル・ノーティフィケーションへの応答として、ステップ257 においてCRM クラーク222 は、以前にCRM ワーカー202 によってCRM クラーク222 と共に登録されたCRM コンペンセータ206 を作成する。ステップ258 において、CRM クラーク222 は、次いでノーティフィケーション及び関連するログ記録をCRM コンペンセータ206 に渡すためにICrmCompensator インタフェース212 の適切な方法を呼び出す。CRM コンペンセータ206 へのその呼び出しと共に、CRM クラーク222 は、CRM コンペンセータにその補償アクションのログ記録を書き込ませるためにICrmLogControlインタフェース230 のためのインタフェース・ポインタを渡す。
【００６２】
ステップ259 において、CRM コンペンセータ206 は、CRM ワーカー202 によってログされる情報に基づく２フェーズ・コミット・プロトコル・ノーティフィケーションに適切なボート、クリーンアップ、又は補償アクションを実行する。適切であれば、CRM コンペンセータ206 は、又障害回復中に使用するために、そのクリーンアップ、又は補償アクションの情報をログするであろう。
【００６３】
〔ロギング〕
図５はリソース上の正常アクションのためにCRM ワーカー202 が補償すべき情報をログするプロセス280 を説明する。例示のアーキテクチャ200(図３) において、情報はログにレージー・ライト書法(lazy write fashion)で書き込まれる。CRM ワーカー202 は、CRM ワーカーによって取られた１個のアクションを示し次いでログ・ファイル244 中の非揮発性記憶装置へ共に入れられるログ記録を、待ち合わせ行列に入れるためにCRM クラークのICrmLogControlインタフェース230を使用する。CRM ワーカー202 は、補償を後刻要求されるかも知れないリソース上の何れのアクションの実行前にライト・アヘッド・ベースでロギングを実行することが望ましい。
【００６４】
ロギング・プロセス280 の最初のステップ281 として、CRM ワーカー202 はデータ・エレメントの集合としてログ記録を作成する。例示のアーキテクチャ200において、ログ記録は構造化されているか、又は構造化されていない。構造化ログ記録はVisual Basicコレクション・オブジェクトのようなVariant 型データ・エレメントのコレクションである。非構造化ログ記録はバイト(byte)のバッファに過ぎない。典型的に、Microsoft Visual Basicプログラミング言語で書かれたCRM ワーカーは、構造化されたログ記録を書くであろう一方、Microsoft VisualC++又はJ++ 言語で書かれた方は非構造化ログ記録を書く。例示の補償型リソース・マネージャ・アーキテクチャ200 におけるCRM ワーカー202 は、構造化ログ記録と非構造化ログ記録とを混ぜることは許されず、これらの型の内の唯１つのログ記録を書かねばならない。
【００６５】
ログ記録が作成されると、ステップ282 のCRM ワーカー202 は、ログ記録を行列に写し取るためにCRM クラーク222 のICrmLogControlインタフェース230 上に"WriteLogRecord()"方法（又は、構造化されたログ記録に対して"WriteLogRecordVariants()"方法）を呼び出す。ステップ283 に表示されるように、CRM ワーカー202 は、複数のログ記録を行列させるために281-282 のステップを複数回繰り返すかもしれない。
【００６６】
CRM ワーカー202 がリソースに対して正に取ろうとしているアクションに対してCRM ワーカー202 が全てのログ記録を行列させた後、CRM ワーカー202 は、行列されたログ記録を耐久性のあるログに書き出されるようにするために、ステップ284 においてCRM クラーク222 のICrmLogControlインタフェース上に"ForceLog()"方法を呼び出す。このようにして分離された"WriteLogRecord()"及び"ForceLog()"の方法は、CRM ワーカー202 に複数のログ記録を行列させるようにし、且つそれらを纏めて耐久性のあるログに書き込ませて、ロギング能率を強化する。
【００６７】
CRM クラーク222 中への"WriteLogRecord()"、"WriteLogRecordVariants()"及び"ForceLog()"の実装は、ログ・ファイル244 に書かれたログ記録をキャシュ(cache) し、続いてフォースする。
【００６８】
〔チェックポイント〕
図３を再度参照して、耐久性のあるログ226 は、ログ・ファイル244 中の完了したログ記録のスペースの返還をリクエストするするために、チェックポイントを使用する。
【００６９】
CRM 障害回復クラーク224 は、ILogRecover インタフェース248 上に"TakeCheckpoint()"方法を呼び出すことにより、障害回復エンジン242 へイニシエート・チェックポイントリクエストを発行する。CRM 障害回復クラーク224 は、イベント又はタイムアウトを待つバックグランド・スレッド(background thread) を持つ。タイムアウトにおいて、CRM 障害回復クラーク224 は最終チェックポイント以降に何らかのログ記録が書き込まれたかを検査する。もし、そうでなければ、チェックポイントリクエストはイニシエートされない。これらの周期的なチェックポイントリクエストは、障害回復エンジンに、もしログ記録のトランザクション速度及び量に対して十分でなければ、ログ・ファイル244 を自動的にリサイズ又は拡大することを許容する。
【００７０】
CRM 障害回復クラーク224 は、又チェックポイントリクエストがイニシエートされる前に現在何らかのCRM クラークが存在しないかを検査する。もし存在しないならば、チェックポイントリクエストはイニシエートされない。もし現在CRM クラークが存在すれば、CRM 障害回復クラーク224 は、CRM クラークが障害回復プロセシング中に正しく作成されることができるように、CRM クラークのためにクラーク・インスタンス識別子をログする。CRM 障害回復クラーク224 は、全ての現在のCRMクラークのクラーク・インスタンス識別子を有する単一ログ記録の"clerk listrecord" をログする。
【００７１】
CRM 障害回復クラーク224 は、更にログのトランケーション(truncation)を管理する。障害回復エンジン242 によるチェックポイント・プロセシング中、("ILogRecoverClerk::WriteCheckpoint()"方法を使用する) 障害回復エンジン242 は、CRM 障害回復クラーク224 及び各CRM クラーク222 にチェックポイント・ログ記録を書き込ませ、それらのログ記録に使用された最小ログ・シーケンス番号(LSN) へ戻らせる。CRM 障害回復クラーク224 は、障害回復エンジンにイニシエート・チェックポイントリクエストを発行する前にクラーク・リスト・ログ記録を書き込み、次いでクラーク・リスト・ログ記録のLSN を障害回復エンジンのライト・チェックポイントリクエストからの最小LSN として返す。これは、クラーク・リスト記録が, ログ・ファイル244 中のCRM クラーク222 の何れものチェック・ポイント記録以前に発生すること、及び最終の２個のチェック・ポイントはログ・ファイル244 中に維持されていることを保証する。
【００７２】
CRM クラークへの障害回復エンジンのライト・チェックポイントリクエストへの応答として、各CRM クラーク222 は１つ置きのチェックポイント・ベースでそのログ記録を前方へコピーする。一層特別に、CRM クラーク222 がライト・チェックポイントリクエストと共に呼び出され、且つ進行中のトランザクションを持つ最初の場合に、CRM クラーク222 は使用中の最小LSN をそれに返す。次の時点で、CRM クラーク222 はその全てのログ記録を前方へコピーし、その新しい最小LSN を返す。前方へコピーする時に、CRM クラーク222 はログ・ファイルにそれが書き込んだ全てのログ記録を読み出し、且つログ記録をログ・ファイル244 に再書き込みを行う。この方法は、CRM クラーク222 がそのログ記録を前方へコピーしなければならない頻度を減少させながら、最終の２個のチェック・ポイントがログ・ファイル244 に留め置かれることを意味する。耐久性のあるログ226 は、次いで完了したトランザクションから明け渡されたスペースの再利用のためにラップ(wrap)できる。CRM 障害回復クラークのイニシエート・チェックポイントリクエストのタイムアウト間隔は、大部分のトランザクションは２個のチェック・ポイント以内に完了し且つコピーの差し出しは通常CRM クラーク222 に要求されないように、調整されるのが望ましい。
【００７３】
CRM クラーク222 は、チェック・ポイント記録開始点にチェック・ポイントを書き込むことから始めて、チェック・ポイント記録終了点で終了する。このことは、チェック・ポイントの境界が障害回復のあいだ正確に識別され、且つチェック・ポイントが成功裏に完了したか障害で中断したかを判断できるようにする。CRM クラーク222 は、更にそれが書き込む各ログ記録の連続番号を付与し、且つチェック・ポイントで前方へコピーしたログ記録にコピー・フラッグを加える。( 忘れられるべき以前のログ記録を識別する) フォーゲット記録を前方へコピーする時に、CRM クラーク222 は、その新しい( 前方へコピーした)LSNによって忘れられたログ記録を適切に識別するためにフォーゲット記録を更新する。
【００７４】
チェック・ポイント・プロセシング中、CRM クラーク222 は、CRM クラークを経由して書き込まれたログ記録の順序を維持するために、CRM ワーカー202 又はCRM コンペンセータ206 からの新規のログ記録書き込みを阻止する。また、２フェーズ・コミット・ノーティフィケーションは、チェック・ポイントが進行中は、阻止される。同様に、チェック・ポイントリクエストは、耐久性のあるログ226 への正常書き込み中、及びトランザクション完了ノーティフィケーションを処理中は阻止される。
【００７５】
〔補償〕
図３に例示のCRM アーキテクチャ200 において、トランザクション・マネージャ148 （図２）は、（CRM クラーク222 の障害回復エンジンとの登録中にトランザクションのリストに乗せられる）障害回復エンジン242 のITransactionResourceAsync インタフェース238 を通じて補償型リソース・マネージャへ２フェーズ・コミット・ノーティフィケーションを与える。各ノーティフィケーションに対して、障害回復エンジン242 は、（CRM ワーカー202 によって書き込まれたログ記録を含む）CRM クラーク222 のクラーク・インスタンス識別子に関連してログに書き込まれた全てのログ記録を読み出す。次いで、障害回復エンジン242 は、CRM クラークの（下記の）ILogRecoverClerkPhaseNotification インタフェースを使用するCRM クラーク222 へノーティフィケーション及びログ記録を渡す。
【００７６】
CRM クラーク222 は、CRM リソース・ディスペンサ220 と共に登録されたCLSID を使用するCRM コンペンセータ206 を作成することにより障害回復エンジン242 のコールに応答する。次いで、CRM クラーク222 は、それぞれの２フェーズ・コミット・ノーティフィケーション（例えば、準備フェーズ・ノーティフィケーションに対するBeginPrepare(),PrepareRecord()、及びEndPrepare()）に対して適切なCRM コンペンセータ206 上のICrmCompensator(非構造化ログ記録の場合)又はICrmCompensatorVarients(構造化ログ記録の場合) の方法を呼び出す。CRMクラーク222 は、追加的に、そのICrmLogControlインタフェースに対するポインタを、CRM コンペンセータがその補償アクションのロギイングのために使用するCRM コンペンセータ206 のICrmLogCompensator（又は、ICrmCompensatorVarients ）インタフェース212 上の"SetLogControl" 方法へのコールに渡す。
【００７７】
２フェーズ・コミット・ノーティフィケーション方法のCRM コンペンセータ206 への実装は、CRM ワーカーによりログされたアクションに対するリソースに特定される適切なアクションを実行する。（上記のように、CRM コンペンセータの実装は、例えば特定のリソースに対する補償型リソース・マネージャのシステム・インテグレータ又は他のプログラマーであるデベロッパーにより供給される。）プリペア・ノーティフィケーション方法（すなわち"BeginPrepare()"方法，"PrepareRecord()"方法，及び"EndPrepare()"方法）において、CRM コンペンセータはトランザクション内のリソースに対して実行されたワークはコミットするのに適切に準備されているか否かを決定する。CRM コンペンセータの実装の大部分の場合は、トランザクション中のCRM ワーカー202 のワークは、それがCRM ワーカーによって実行された時点で既にリソース上に持続されている。従って、CRM コンペンセータは、"EndPrepare()"方法の"bOkToPrepare"パラメータを"VARIANT＿TRUE" に単にセットしてリターンするように、実装されることができる。他の実装において、CRM コンペンセータ206 は、ワークはパーシスタントとして残るべきか、又は補償されるべきかを決定するためのチェックを実行し、且つそれに従って"bOkToPrepare"パラメータをセットするであろう。例えば、このチェックはCRM ワーカーにより実行されたワークは正しいか又は首尾一貫(consistent)しているかを決定するであろう。
【００７８】
コミット・ノーティフィケーション（例えば、"BeginCommit()","CommitRecord", 及び"EndCommit()" 方法）に対して、CRM コンペンセータ206 は、リソース上のCRM ワーカーのワークを完了するために、何らかのクリーンアップ・アクションを実行できる。例えば、リソースがファイル・システムであり且つ補償型リソース・マネージャがトランザクション中のファイルを消去する能力を与えるべきであれば、CRM ワーカーの正常アクションは、そのファイルがトランザクションのアボートに当たり復元できるように、消去されるべきファイルにネームを再付与するか又は隠すことであろう。この例におけるCRM コンペンセータは、トランザクションのコミットに応答してネームが再付与されたか又は隠されたファイルを実際に消去するクリーンアップ・アクションを実行する。CRM コンペンセータは、ネームが再付与されたか又は隠されたファイルのネームを読み出すようなCRM ワーカーのアクションのログ記録を（"CommitRecord()"方法を介して）受け取る。CRM コンペンセータは、又障害回復の目的でクリーンアップ・アクションをログするためにCRM クラーク222 のICrmLogControlインタフェースを使用する。CRM コンペンセータは、クリーンアップ・アクションが実行されたことを確証するためにクリーンアップ・アクションの実行後ログ情報を書き込む。例えば消去ファイル補償リソースマネージャの上記の例において、CRM コンペンセータ206 はファイルの消去後にネームが再付与されたか又は隠されたファイルが消去されたことをログする。トランザクションのコミット・フェーズ中に障害が発生すれば、続く障害回復中はクリーンアップ・アクションを除外することができる。"EndCommit()" 方法に実装されるクリーンアップ・アクションは、最初のアテンプトで成功するような同じ結果を得る複数回数アテンプトできるように、ベキ等(idempotent)であるべきである。CRM コンペンセータがクリーンアップ・アクションを実行する後ではあるがそのクリーンアップ・アクションが実行されたことをロギングする前に障害が発生するか、又は障害が障害回復中に発生する場合が、そのような実例である。
【００７９】
アボート・ノーティフィケーション方法において、CRM コンペンセータ206 は、典型的に既にリソース上に持続するCRM ワーカー202 のワークを逆転するイデムポテント補償アクションを実行する。CRM コンペンセータは "AbortRecord()"方法を持つCRM ワーカーによってログされた情報を受け取る。CRM コンペンセータは、又CRM クラーク222 との補償アクションを事後書き込みベースでログする。例えば消去ファイル補償リソースマネージャの上記の例において、CRM コンペンセータを"EndAbort()"方法内のネームが再付与されたか又は隠されたファイルを復元するように実装することができる。
【００８０】
CRM コンペンセータがコミット又はアボート・ノーティフィケーションに対するその補償アクションの処理を成功裏に完了した後、CRM クラーク222 は、その処理を完了したことを示すクラーク・エンド・ログ記録を耐久性のあるログ226に書き込み、CRM クラーク222 は開放されることができる。CRM クラーク222 は又、現在登録されているCRM クラークのリストから除去できるようにCRM 障害回復クラーク224 に通知する。
【００８１】
〔障害回復〕
図３に示される例示のCRM アーキテクチャ200 において、システムが供給するインフラストラクチャ( 例えば、CRM 障害回復クラーク224 及び障害回復エンジン242 )は、又正常プロセシングを中断する障害が発生後、障害回復を実行する。障害回復はASP 90（図２）の起動(startup) によりイニシエートされる。ASP90の起動プロセシング中に、CRM アーキテクチャ200 はASP にロードされ且つCRM 障害回復クラーク224 が作成される。起動において,CRM障害回復クラーク224はASP に関連するログ・ファイル244 を探す。上記のように、ログ・ファイル244 はASP の識別子(Appld) に基づくファイル・ネームを持ち、且つトランザクション・マネージャ148 （図２）のログ・ファイルと同一のファイル・システム・パス上に存在する。もしログ・ファイル244 がASP のために存在すれば、CRM 障害回復クラークは( 例えば、障害回復エンジン242 を作成し、障害回復エンジンの"ILogRecover::Recover()"方法を呼び出して) ログ・ファイル244 上で障害回復をイニシエートする。
【００８２】
障害回復エンジン242 は、ARIES 障害回復プロトコルに準拠して障害回復プロセシングを実装し、且つ（CRM 障害回復クラーク224 上に実装されたILogRecoverClerk・インタフェース及び各CRM クラーク222 を使用する）障害回復プロセシングの分析、やり直し及び元に戻すフェーズ(redo and undo phases)を介して障害回復エンジン（例えば、CRM 障害回復クラーク224 及び各CRM クラーク222 ）と共に登録された各クラークをドライブする。正常プロセシング中、CRM 障害回復クラークは、（チェックポイント以前の）クラーク・リスト・ログ記録及び（新規のCRM クラークがチェックポイント間に作成される時に）新クラーク・ログ記録をログする。障害回復クラークがこれらの記録をログする方法のために、CRM クラーク222 を識別するクラーク・リスト及び新クラーク記録は、ログ・ファイル244 中にそのようなCRM クラークによりログされた何れの記録よりも先行する。（即ち、低いLSN を持つ。）従って障害回復中、障害回復エンジンはCRM 障害回復クラーク224 に、CRM クラーク222 にCRM クラークが書き込んだログ記録の障害回復プロセシングを実行させる前に、CRM クラーク222 を識別する記録の障害回復プロセシングを実行させる。障害回復の分析フェーズにおいてクラーク・リスト及び新クラーク・ログ記録をプロセシングする時に、CRM 障害回復クラーク224 は記録内で識別される各クラーク・インスタンス識別子に対して新規のCRM クラークを作成し、且つそれにそれぞれのクラーク・インスタンス識別子を指定する。作成されたCRM クラークは、指定されたクラーク・インスタンス識別子と共に自身を障害回復エンジン242 に対し識別し、且つ障害回復エンジンからの上記のクラーク・インスタンス識別子と共にログされたログ記録を受け取るために利用可能となる。CRM クラーク222 は、ログ記録を適切に翻訳し、登録されたCRM コンペンセータ206 を作成し、且つトランザクションの結果に応じてCRMコンペンセータ上の適切な方法を呼び出すことに責任を有する。
【００８３】
分析フェーズにおいて、障害回復エンジン242 は、CRM クラーク222 のクラーク・インスタンス識別子に関連する全てのログ記録を("ILogRecoverClerk::AnalyzeRecord()"方法を介して)CRMクラークへ渡す。CRM クラークは適切な障害回復プロセシングを実行するために全てのログ記録を分析する。先ず、CRM クラークはクラーク・エンド記録を探す。CRM クラークは、コミット又はアボート・ノーティフィケーションへのCRM コンペンセータの補償アクションの後にのみ、正常プロセシング中にクラーク・エンド記録をログする。もしクラーク・エンド記録が検出されれば、CRM クラーク222 はトランザクションが(CRMコンペンセータ206 の補償アクションを含み) 成功裏に完了し且つCRM クラークのこの時点では障害回復を必要としないと結論する。
【００８４】
もしクラーク・エンド記録が検出されなければ、CRM クラーク222 は、CRM クラークによってもともと書かれたログ記録の正しいシーケンスを識別することに進む。CRM クラーク222 は、障害以前に複数のチェック・ポイントを生き残り、古いLSN を持つ幾つかのログ記録の２重のコピーの発生と言う結果が生じる。CRM クラーク222 は、障害回復エンジン242 から受け入れるログ記録をそれらのLSN によって整理する。CRM クラーク222 は、与えられたシーケンス番号を持つ唯一の記録が存在することを確認するためにログ記録をプロセスする。何れの重複も破棄される。更に、CRM クラーク222 は、忘れるべきログ記録のためのリストをプロセスし、且つ忘れ去られるべきログ記録をマークする。この結果のリストは、CRM クラーク222 に対する正しいログ記録シーケンスである。
【００８５】
その解析フェーズ中、CRM クラーク222 は、又CRM ワーカー202 によって登録されたCRM コンペンセータのクラス識別子をCRM クラークがその中にログしたクラーク・ビギン記録を探す。解析フェーズの終わりに、CRM クラーク222 は識別したログ記録シーケンス中の最小のLSN を障害回復エンジン242 へ返す。
【００８６】
解析フェーズの後、障害回復エンジン242 は、更に ("ILogRecoverClerk"インタフェースの "BeginRedoPass()"方法，"RedoRecord()"方法,"BeginUndo()"方法，及び"UndoRecord()"方法を介して) やり直し及び元に戻すフェーズを経てCRM障害回復クラーク224 及びCRM クラーク222 をドライブし、又 (IRecoverClerkPhaseNotificationインタフェースを介して) ノーティフィケーションをCRM クラークのトランザクションのステータスに対するものとしてCRM クラークへ渡す。CRM 障害回復クラーク224 及びCRM クラーク222 は、障害回復のやり直し及び元に戻すフェーズを無視する。障害回復エンジン242 は、正常プロセシング中にログしたログ記録から又は再度トランザクション・マネージャ148 （図２）と共にトランザクションのリストに乗せることによりトランザクション・ステータスを決定する。
【００８７】
もし障害回復エンジン242 がトランザクションのためにログした準備記録を見つければ、障害回復エンジンは障害回復中トランザクションを持っているCRM クラーク222 に準備ノーティフィケーションを (IRecoverClerkPhaseNotificationインタフェースの "OnPrepare()"方法を介して) 渡す。しかし、準備は障害回復中CRM コンペンセータに対し十分な意味を持たないので、CRM クラーク222 はCRM コンペンセータに対し準備ノーティフィケーションを渡さない。
【００８８】
トランザクションがコッミトされたか、又はアボートされたかを決定すると、障害回復エンジン242 は適切なノーティフィケーションを (IRecoverClerkPhaseNotificationインタフェースの"OnCommit()"方法又は "OnAbort()"方法を介して) 障害回復中トランザクションを持っているCRM クラーク222 に渡す。正常プロセシング中と同様に、CRM クラーク222 は、これらのノーティフィケーションに対してCRM コンペンセータを作成し、且つCRM ワーカーによって(ICrmCompensatorインタフェース212 の "BeginCommit()"方法，"CommitRecord()"方法,"EndCommit()"方法，"BeginAbort()"方法,"AbortRecord()"方法及び"EndAbort()"方法を介して) 書き込まれたログ記録と共にCRM コンペンセータにコミット又はアボート・ノーティフィケーションを渡すことにより、これらのノーティフィケーションに応答する。これは、CRM コンペンセータにログ記録に基づき（コッミトに対して）適切なクリーンアップ・アクション又は（アボートに対して）補償アクションを実行させることになる。CRM コンペンセータが成功裏にこのプロセシングを完了した後、CRM クラーク222 はこのプロセシングが実行されたことを示すクラーク終了記録を書き込み、CRM クラークは開放される。CRM クラークは、又自分が登録されたCRM クラークのリストから除去されることができるようにCRM 障害回復クラーク224 に通知する。
【００８９】
もし障害回復エンジン242 がトランザクションをトランザクション・マネージャ148 （図２）と共に再度リストへ記入するに当たって疑問があると判断すれば、障害回復エンジンは(ILogRecoverClerk インタフェースの"OnInDoubt()" を介して) 該トランザクションを持つCRM クラーク222 にその旨を通知する。この場合、該CRM クラークは、全ての続くチェックポイントを通じてログファイル中のそのログ記録を維持する責任を有する。
【００９０】
障害回復の最後に、障害回復エンジン242 は障害回復は完了したと(ILogRecoverClerk インタフェースの"EndRecovery()" 方法を介して)CRM障害回復クラーク224 及びCRM クラーク222 に通知する。もし、そのトランザクションが障害回復中に完了した時は、CRM クラーク222 が開放される。CRM 障害回復クラーク224は、登録されたCRM クラークのリストを維持し且つチェックポイントリクエストをイニシエートするために、障害回復後も残る。
【００９１】
〔人的補償〕
CRM アーキテクチャ200 （図３）と共に実装される幾つかの補償型リソース・マネージャにおいて、CRM コンペンセータ206 はそのクリーンアップ及び補償アクションの一部として人的補償を使用することができる。２フェーズ・コミット・プロトコルの一部として、補償型リソース・マネージャは、準備フェーズにおいて肯定的にボートした後はトランザクションをコミット又はアボートする適切なアクションを実行できねばならない。人的補償を使用する補償型リソース・マネージャにおいて、CRM コンペンセータはクリーンアップ及び補償アクションが失敗するような場合は人的アクションに依存する。そのような失敗において、CRM コンペンセータは状況を修復するために適切なアクションを取るために、操作する人間に知らせるために出力を提供する。次いで、CRM コンペンセータは、あたかもクリーンアップ及び補償アクションが成功したように、適切な情報のロギングをすること、及び"EndCommit()" 又は"EndAbort()"コールからの回答として「成功」("success") を表示する（即ち、該方法の HRESULTリターン値として）ことを継続する。必要とあれば、CRM コンペンセータは、CRM クラークが、それによりログ記録がCRM クラークから渡される"CommitRecord()"又は "AbortRecord"コールへ、誤りコードを戻すことによりログ記録をスタートから再プレーをする、ことをリクエストできる。これは、CRM コンペンセータがログ記録をプロセシング中の途中に人的補償を要求する障害が発生する時に後刻の人的補償において使用するために、ログ記録の全てのシーケンスが別のファイルにセーブされることを許容する。
【００９２】
操作する人間への通知は、スクリーン上の可視警報、可聴警報、プリントアウト報告、又は他の警報の形態であろう。通常、操作する人間が要求される手動での修復アクションを実行するために十分な情報を提供するために、警報は、人間が読める形式でのトランザクションに関連するログ記録を含むか、他の方法として、操作する人間がそのような記録を検査する方法（例えば、ログ・ビューイング・ユーティリティを使用して、操作する人間が見ることができる別のファイルにログ記録を書き込む）を提供するであろう。
【００９３】
例えば、クレジット・カード請求を取り扱う補償リソース・マネージャは、クレジット・カード料金に対する補償アクションの一部として人的補償を使用するかも知れない。トランザクションがアボートされた所での補償アクションは口座に入金を実行しなければならない。口座情報にアクセスする必要のある他のコンピュータ又は通信リンクが使用できないような理由のためにCRM コンペンセータが口座に入金できなければ、その代わりにCRM コンペンセータは人的介入によって補償アクションを実行することができる。CRM コンペンセータは、取扱者に人間によるアクションが必要であると通知し、且つ取扱者が何れの口座に入金すべきかとその額を決定するためにログ記録へのアクセスを提供するであろう。
【００９４】
〔遅延された障害回復(Deferred Recovery) 〕
CRM アーキテクチャ200 （図３）と共に実装されているある種の補償リソース・マネージャにおいて、CRM コンペンセータ206 は、他の方法として、そのクリーンアップ及び補償アクションの一部として遅延された障害回復を使用できる。遅延された障害回復において、CRM ワーカーの正常アクションのログ記録は、CRM コンペンセータ206 のクリーンアップ及び補償アクションが正常プロセシング中又は障害回復プロセシング中に障害となった時に、耐久性のあるログ226 に留まる。CRM コンペンセータ206 は"EndCommit()" 又は"EndAbort()"方法から障害結果を返す。トランザクションのコッミト又はアボートが完了しないので、トランザクションは存在し続け且つトランザクション・マネージャ148 （図２）はトランザクション上の情報を保持する。しかし、CRM アーキテクチャ200 及びMTS実行環境82は（もし障害回復中であれば）障害回復プロセシングを継続し、且つ他の正常プロセシングも継続する。後刻の障害回復において、CRM クラーク222はCRM コンペンセータ206 に遅延されたクリーンアップ又は補償アクションを再度試みさせる。
【００９５】
〔インタフェース定義〕
＜ICrmLogControlインタフェース＞再度、図３を参照して、CRM クラーク222はICrmLogControlインタフェース230 をサポートする。ICrmLogControlインタフェースは、記録を耐久性の有るログ226 に書き込むために、CRM ワーカー及び多分CRM コンペンセータ212 によって使用される。CRM ワーカー202 は、又ICrmLogControlインタフェース230 を使用して、自身と対になっているCRM コンペンセータ212 をCRM クラーク222 と共に登録する。
【００９６】
ICrmLogControlインタフェースは、図６のプログラム・リストに示すように、１組の方法を供給する。"TransactionUOW()"方法は、CRM ワーカーが正常アクションを実行するトランザクションのTransaction Unit Of Work識別子を得るためにCRM によって使用される。
【００９７】
上記のように、CRM ワーカー202 は、自身と対になっているCRM コンペンセータ212 をCRM クラーク222 と共に登録するために、"RegisterCompensator()" 方法を呼び出す。CRM ワーカー202 は、ICrmLogControlインタフェースへのポインターを得た後、先ず該方法を呼び出し（即ち、耐久性のあるログに何らかのログ記録を書き込むためにインタフェースを使用する前に）、且つ該方法を一度のみ成功的に呼び出すことができる（引き続いてのアテンプト又は該方法を呼び出すためのCRM コンペンセータによるアテンプトはE ＿FAIL返却値(return value)の結果となる）。CRM ワーカー202 は、CRM コンペンセータ206 のストリング・フォーマット中のクラス識別子(CLASID)又はプログラム識別子(PROGID)を、コール内の"IpcwstrProgldCompensator"パラメータとして定義する。CRM ワーカー202は、テキスト記述を、監視又は管理に使用されるために"IpcwstrDescription"パラメータ内へ渡す。CRM コンペンセータの登録に加えて、該方法は、CRM が先へ進行できることを保証するために、多数の有効性(validation)チェックを実行する。これらのチェックは、CRM コンペンセータが作成されたこと及びそれが（下記の）ICrmCompensator 又はICrmCompensatorVarients インタフェースの少なくとも１個をサポートすることを検証することを含む。もしそうでなければ、該方法は"E＿FAIL" 又は"E＿NOINTERFACE"値をそれぞれ返す。該方法は、更に現在のコンテキストは有効なトランザクション及びアクティビティ識別子を持つことをチェックする。最後に、CRM 障害回復クラークが障害回復プロセシングを完了していないか、又はそれがCRM に対して致命的な誤りを検出した時は、該方法は、"XACT ＿E ＿RECOVERYINPROGRESS" 又は"E＿FAIL" 値をそれぞれ返す。
【００９８】
"WriteLogRecordVarients()"方法がログに構造化ログ記録を書き込むためにCRM ワーカー202 及びCRM コンペンセータ206 により呼び出される。構造化された記録はVariant 型の数値の集合として作成される記録である。典型的に、この方法は、CRM ワーカー及びCRM コンペンセータがMicrosoft Visual Basicで書かれ、且つ構造化された記録がVisual Basic Collection オブジェクトである場合に使用される。該方法は、もしCRM ワーカー202 により登録されたCRM コンペンセータ206 がICrmCompensatorVarients インタフェースをサポートしなければ、障害コードを返す。CRM ワーカー及びCRM コンペンセータは、構造化ログ記録と非構造化ログ記録の両者を使用することは許容されない。従って、"WriteLogRecord()"方法への以前の成功したコールの後でのこの方法へのコールは、"E＿FAIL"値を返すであろう。該方法は、又トランザクションが完了後にCRM ワーカー202により呼び出されるか、又は完了の過程にある時には、"E＿FAIL" 値を返すであろう。しかし、CRM コンペンセータは、トランザクション・アウトカム・ノーティフィケーションの間に更にログ記録を書き込むために、該方法を使用することを継続できる。
【００９９】
"WriteLogRecord()"又は"WriteLogRecordVarients()"方法を使用して以前に書き込まれたログ記録を、障害にも残存するコンピュータの耐久性のあるメモリ（例えば、図１のハードディスクドライブ27）中に存在する耐久性のあるログ226に書き上げるようにするために、"ForceLog()"方法がCRM ワーカー202 及びCRMコンペンセータ206 により呼び出される。耐久性のあるようにされたログ記録を持って、CRM ワーカー202 はリソースに対して正常動作を進めることができる。
【０１００】
"ForgetLogRecord()" 方法がCRM ワーカー202 及びCRM コンペンセータ206 により呼び出され、CRM クラークに（例えば "WriteLogRecord()" 又は"WriteLogRecordVarients()"方法を使用して）書き込まれた最終ログ記録を忘れさせる。例示のCRM アーキテクチャにおいて、該方法は書き込まれた最終ログ記録を忘れさせるためのみに使用可能であり、入れ子(nesting) は許されない。忘れられたログ記録は、２フェーズ・コッミト・ノーティフィケーション中、CRM コンペンセータには伝達されない。
【０１０１】
CRM ワーカー202 は、トランザクションを( 例えば、上記の組み込まれたMTS特許申請に一層詳細に記述されているように、MTS ITransaction::Abort 方法を介して) 一方的に、直ちにアボートさせるために"ForceTransactionToAbort" 方法を呼び出す。登録されたCRM コンペンセータ206 からの該方法へのコールは、トランザクションが完了過程に無い限りCRM コンペンセータはアクティブでないので、障害コード"E＿FAIL" を返す。
【０１０２】
(CRMワーカー及びCRM コンペンセータがMicrosoft Visual C++又はVisual J++で書かれている時に典型的に使用される) 非構造化ログ記録を書かせるために、"WriteLogRecord()"方法がCRM ワーカー202 及びCRM コンペンセータ206 により呼び出される。該非構造化ログ記録は単にバイトのバッファである。該方法は、ログ記録のセクションをCRM ワーカー( 又は、コンペンセータ) によりそのようなバッファの配列(array)("rgBlob"パラメータ) として構築することを許すギャザーリング機能を供給し、次いでそれらのバッファはCRM クラークによって維持されている１個のバッファにこの方法による単一操作によりコピーされる。該方法は、下記の場合に障害コード("E ＿FAIL")を返すであろう：(1) 登録されたCRM コンペンセータがICrmCompensator インタフェースをサポートしない；(2) 該方法は(CRMクラークは構造化及び非構造化記録の混合を許容しないため)"WriteLogRecordVarients()" 方法に対する事前の成功したコールの後で呼び出された；(3) CRM ワーカーがトランザクションが完了した後か又は完了過程にある時に該方法を呼び出す。
【０１０３】
＜ICrmCompensator 及びICrmCompensatorVarients インタフェース＞更に図３を参照して、CRM コンペンセータ206 は ICrmCompensator又はICrmCompensatorVarients インタフェースの一方、又は双方をサポートする。該インタフェースは、２フェーズ・コッミト・ノーティフィケーション及び正常アクション中にCRMワーカーによってログされる記録のCRM コンペンセータへの伝達のために、CRMクラーク222 によって使用される。ICrmLogControlインタフェースのために上記に記述したように、特定のCRM に対する記録は、"WriteLogRecord()"又は"WriteLogRecordVarients()"方法の何れが使用されたかに応じて全てが構造化又は非構造化のいずれかであることがそれぞれ要求される。ICrmCompensator インタフェースは非構造化ログ記録の伝達に使用され、一方、ICrmCompensatorVarients インタフェースは構造化ログ記録をCRM コンペンセータへ伝達する。
【０１０４】
ICrmCompensator 及びICrmCompensatorVarients インタフェースは、図７及び８に示されるプログラム・リスト302-303 において定義される。"SetLogControl()" 方法がCRM コンペンセータを作成した後、CRM クラーク222 が先ず呼び出され、CRM クラークのICrmControl インタフェース230 のポインターを("pLogControl"パラメータとして)CRMコンペンセータ212 へ渡す。これはCRM コンペンセータにトランザクション完了中に更にログ記録を書き込むことを許す。この方法からの"S＿OK" 以外のリターン値は、CRM コンペンセータに対するレジストリ(registry)フラッグCLSID 経由で特別にオーバライド(override)されない限り,ASPの"failfast"を引き起こすであろうCRM コンペンセータの障害と見なされる。
【０１０５】
"BeginPrerare()"方法は、CRM コンペンセータへの準備ノーティフィケーション( ２フェーズ・コッミト・プロトコルのフェーズ１)としてCRM クラーク222により呼び出され、且つログ記録が正に伝達されようとしていることを示す。準備ノーティフィケーションは、正常プロセシング中にのみ送出され、障害回復中は送出されない。更に、"S＿OK" 以外のリターン値はCRM コンペンセータ誤りと見做される。
【０１０６】
"PrepareRecord()" 方法は、準備フェーズ中ログ記録をCRM コンペンセータへ伝達するために、CRM クラーク222 により呼び出される。ログ記録は正方向順序で伝達される。非構造化ログ記録は、フラッグ・フイールド("dwCrmFlags")、シーケンス番号("dwSequenceNumber")、及びログ記録データ("blobUserData")を所有する"CrmLogRecordRead"データ構造として伝達される。フラッグ・フイールド及びシーケンス番号は、デバッグ又は人的補償が必要な環境下での障害識別に有効であろう情報を提供する。フラッグ・フイールドは、記録は忘れられたか、及び何時記録は書き込まれたか、を示すフラッグを含む。ログ記録のシーケンス番号は、耐久性のあるログ226 中のそのシーケンスを示す。CRM コンペンセータ206 はCRM クラークにこの方法のコールにより伝達されるログ記録を忘れさせるようにするために、該方法からの復帰において、フォーゲット・フラグ("pfForget" パラメータ) を設定する。CRM コンペンセータは、忘れられたものや準備フェーズ中にCRM コンペンセータにより書かれたものを含むCRM ワーカーにより書き込まれた全てのログ記録、の伝達を繰り返すことをCRM クラーク222 にさせるようにするために、数値"ERROR＿REPLAY＿RECORDS"を返すことができる。"S＿OK"又は"ERROR＿REPLAY＿RECORDS"以外の回答数値は、ASP 90のフェールファースト(failfast)の原因となるCRM コンペンセータ誤りと見做される。"PrepareRecordVarients()" 方法は"PrepareRecord()" 方法に類似であるが構造化ログ記録を伝達する。
【０１０７】
"EndPrepare()"方法は、準備フェーズ中に利用可能な全てのログ記録は伝達を終えたことを示すために、CRM クラーク222 によって呼び出される。もしCRM ワーカー202 によりログ記録が書き込まれなければ、CRM クラークは、その"BeginPrepare()"及び"EndPrepare()"方法の呼出し間での"PrepareRecord()" 又は"PrepareRecordVariants()" 方法の呼出しを省略する。CRM コンペンセータは、"fOKToPrepare"パラメータを使用するトランザクション結果に対しヴォートする。"S＿OK" 以外のリターン値は、ASP 90のフェールファーストの原因となるCRM コンペンセータ誤りと見做される。
【０１０８】
CRM クラーク222 は、CRM コンペンセータへコミット又はアボート・ノーティフィケーションを伝達するために、"BeginCommit()" 又は"BeginAbort()"方法をそれぞれ呼び出す。この呼出しは、又ログ記録がCRM コンペンセータ206 によるコミット又はアボート・アクションの処理のために正に伝達されようとしていることをCRM コンペンセータに示す。"fRecovery" パラメータは、該方法が障害回復又は正常プロセシング中に呼び出されているかを示すフラッグである。"S＿OK" 以外のリターン値は、ASP 90のフェールファーストの原因となるCRM コンペンセータ誤りと見做される。
【０１０９】
"CommitRecord()"及び "AbortRecord()"方法は、コミット又はアボート・フェーズ・プロセシング中の非構造化ログ記録を伝達するために、CRM クラーク222により呼び出される。構造化ログ記録に対して、CRM クラークは類似の"CommitRecordVarients()"又は"AbortRecordVarients()" 方法を呼び出す。"CommitRecord()"方法に対して、CRM クラーク222 はログ記録を正方向順序で伝達する。"AbortRecord()" 方法に対して、CRM クラーク222 はログ記録を逆方向順序で伝達する。もし記録が書き込まれなければ、CRM クラークは、その"BeginCommit()"(又は "BeginAbort()")と "EndCommit()"（又は"EndAbort()"）方法の呼出し間での"CommitRecord()" (又は"AbortRecord()")方法の呼出しを省略する。CRM コンペンセータは、CRM クラーク222 に伝達されたログ記録を忘れさせるようにするためにリターンとしてフォーゲット・フラグ・パラメータ("fForget") をセットできる。"S＿OK" 又は"ERROR＿REPLAY＿RECORDS"以外のリターン値は、ASP 90のフェールファーストの原因となるCRM コンペンセータ誤りと見做される。
【０１１０】
"EndCommit()" 及び"EndAbort()"方法は、全てのログ記録はコミット又はアボート・フェーズ中に伝達されたことをCRM コンペンセータに通知するために、CRM クラーク222 により呼び出される。CRM クラーク222 は、この方法の成功裏の終了によりトランザクションに関する全てのログ記録を破棄しても良い。"S＿OK" 以外のリターン値は、ASP 90のフェールファーストの原因となるCRM コンペンセータ誤りと見做される。
【０１１１】
＜ILogRecover インタフェース＞障害回復エンジン242 はILogRecover インタフェースをサポートする。該インタフェースは、正常プロセシング中("TakeCheckPoint()" の呼出しを介して) チェックポイントを作り出し且つ障害回復プロセシング中("Recover()"方法を介して) ログ・ファイルに基づく障害回復を開始させるために、CRM 障害回復クラーク224 により使用される。ILogRecover インタフェースは図10に示すプログラム・リスト306 に定義される。
【０１１２】
＜ILogRecoverClerkインタフェース＞CRM 障害回復クラーク224 及び各CRM クラーク222 は、ILogRecoverClerkインタフェースを実装する。障害回復エンジン242 は、障害回復のフェーズを通じてCRM 障害回復クラーク224 及び各CRM クラーク222 をドライブし、且つ障害回復フェーズ中それらのクラークに関係するログ記録を伝達するために、ILogRecoverClerkインタフェースを使用する。障害回復エンジン242 は、又CRM 障害回復クラーク224 及びCRM クラーク222 にそれらのチェックポイント・プロセシングを("WriteCheckpoint()"方法を介して) 実行させるようにするためにILogRecoverClerkインタフェースを使用する。ILogRecoverClerkインタフェースは、図11に示すプログラム・リスト308 により定義される。
【０１１３】
＜ILogRecoverClerkPhaseNotification インタフェース＞ CRMクラーク222 はILogRecoverClerkPhaseNotificationインタフェースを実装する。障害回復エンジン242 は、自身をリスト内に掲載したトランザクションから２フェーズ・コッミト・ノーティフィケーションを受け取ることにより、該障害回復エンジンは、トランザクションを持つCRM クラーク222 にノーティフィケーションを渡すためにILogRecoverClerkPhaseNotification インタフェースを使用する。ILogRecoverClerkPhaseNotification インタフェースは、図12に示すプログラム・リスト310 により定義される。
【０１１４】
＜ILogRecoverClerkRegistrationインタフェース＞障害回復エンジン242 は、耐久性のあるログ226 と共に登録するためにCRM 障害回復クラーク224 及びCRMクラーク222 により呼び出されるILogRecoverClerkRegistrationをサポートする。上記のように、CRM 障害回復クラーク224 は、障害回復クラークと共にそのクラス識別子(CLSID) を登録し、一方CRM クラーク222 は、同一クラスの他のCRMクラークから一義的に該CRM クラーク222 を識別するクラーク・インスタンス識別子を登録する。ILogRecoverClerkRegistrationインタフェースは、図13に示すプログラム・リスト312 により定義される。
【０１１５】
＜ILogインタフェース＞ログ・オブジェクト240 は、ログ記録をログ・ファイル224 へ安定に書き込むために、CRM クラーク222 、CRM 障害回復クラーク224、及び障害回復エンジン242 に対してサービスを提供するILogインタフェースを実装する。ILogインタフェースは、図14に示すプログラム・リスト314 により定義される。
【０１１６】
例示の実施例に関連して本発明の原理は記述し例示したが、例示された実施例は、原理から離れることなく構成及び詳細において改良することが出来ることが認められるであろう。ここに記述のプログラム、プロセス、又は方法は、特別な指定がなければ、コンピュータ装置の如何なる特定の形式にも関係がなく又限定もされない。各種の汎用又は特化したコンピュータ装置は、ここに記述の教義と共に使用され、且つその教義に準拠してオペレーションを実行するであろう。ソフトウエアで示されている例示の実施例のエレメントは、ハードウエア及びその他の方法により実装することも可能であろう。
【０１１７】
例えば、例示のCRM アーキテクチャ200 はCRM コンペンセータ206 を登録するためにインタフェース("ICrmLogControl::RegisterCompensator()"方法) を供給するが、本発明に準拠の補償型リソース・マネージャはそれとは別にトランザクション・マネージャ148 （図２）の２フェーズ・コミット・ノーティフィケーションをプロセスするためのコンペンセータ・コンポネントを作成するためにシステムが提供したインフラストラクチャ（例えば、CRM クラーク222 及びCRM 障害回復クラーク224 ） により使用される耐久性のあるログに書き込まれるログ情報中にコンペンセータ・オブジェクトのアイデンティフィケーション( 例えば、CLSID 又はPROJID) をログすることが出来る。
【０１１８】
本発明の原理が適用できるであろう多くの可能な実施例の観点において、詳細な実施例は単に例示に過ぎず、本発明のスコープを限定するように取られるべきではないことが認識されるべきである。むしろ、本発明として、そのような全ての実施例は請求項及びそれと同等のもののスコープ及び精神の内に属することを主張する。
【図面の簡単な説明】
【図１】オンライン・トランザクション処理システムにおける補償型リソース・マネージメントのために、本発明を実施する方法及び機器を実装するのに使用されるであろう分散コンピュータシステムのブロック図である。
【図２】本発明の例示の実施例に準拠の補償型リソース・マネージメントを伴うトランザクション・プロセシングのためのサービスを持つサーバー・アプリケーション実行環境のブロック図である。
【図３】本発明の例示の実施例に準拠の補償型リソース・マネージメントを提供するために図２のサーバー・アプリケーション実行環境において動作が可能な補償型リソース・マネージャ(CRM) のコンポネント・ベースのアーキテクチャのブロック図である。
【図４】図３のCRM アーキテクチャ内での実行命令の流れ図である。
【図５】図３のアーキテクチャにおけるCRM ワーカー・コンポネントにより実行されるロギング・プロセスの流れ図である。
【図６】図３の補償型リソース・マネージャ・アーキテクチャにおけるCRM クラークに対する“ICrmLogControl"インタフェースのプログラムリストである。
【図７】図３の補償型リソース・マネージャ・アーキテクチャにおけるCRM コンペンセータの“ICrmCompensator" インタフェースに対するデータ構造のプログラムリストである。
【図８】図３の補償型リソース・マネージャ・アーキテクチャにおけるCRM コンペンセータの“ICrmCompensatorVarients" インタフェースのプログラムリストである。
【図９】図３の補償型リソース・マネージャ・アーキテクチャにおけるCRM コンペンセータの“ICrmCompensator" インタフェースのプログラムリストである。
【図１０】図３の補償型リソース・マネージャ・アーキテクチャにおける障害回復エンジンの“ILogRecover" インタフェースのプログラムリストである。
【図１１】図３の補償型リソース・マネージャ・アーキテクチャにおけるCRM 障害回復クラーク及びCRM クラークの“ILogRecoverClerk"インタフェースのプログラムリストである。
【図１２】図３の補償型リソース・マネージャ・アーキテクチャにおけるCRM 障害回復クラーク及びCRM クラークの“ILogRecoverClerkPhaseNotification" インタフェースのプログラムリストである。
【図１３】図３の補償型リソース・マネージャ・アーキテクチャにおける障害回復エンジンの“ILogRecoverClerkRegistration"インタフェースのプログラムリストである。
【図１４】図３の補償型リソース・マネージャ・アーキテクチャにおける持続性のあるログに対するログ・オブジェクトの“ILog"インタフェースのプログラムリストである。
【図１５】図３の補償型リソース・マネージャ・アーキテクチャにおける“ICrmFormatLogRecords"インタフェースのプログラムリストである。
【図１６】図３の補償型リソース・マネージャ・アーキテクチャにおけるCRM クラークの“ICrmMonitorLogRecords" インタフェースのプログラムリストである。
【図１７】補償型リソース・マネージャ・アーキテクチャにおけるクラーク・コレクション・オブジェクトの“ICrmMonitorClerks" インタフェースのプログラムリストである。
【図１８】図３の補償型リソース・マネージャ・アーキテクチャにおけるCRM 障害回復クラークの“ICrmMonitor" インタフェースのプログラムリストである。
【図１】
0004159175.tif 000002
【図２】
0004159175.tif 000003
【図３】
0004159175.tif 000004
【図４】
0004159175.tif 000005
【図５】
0004159175.tif 000006
【図６】
0004159175.tif 000007
【図７】
0004159175.tif 000008
【図８】
0004159175.tif 000009
【図９】
0004159175.tif 000010
【図１０】
0004159175.tif 000011
【図１１】
0004159175.tif 000012
【図１２】
0004159175.tif 000013
【図１３】
0004159175.tif 000014
【図１４】
0004159175.tif 000015
【図１５】
0004159175.tif 000016
【図１６】
0004159175.tif 000017
【図１７】
0004159175.tif 000018
【図１８】
0004159175.tif 000019