JP2000020364A - 補償するリソ―ス・マネ―ジャ - Google Patents

Abstract

(57)【要約】 【課題】 補償するリソース・マネージャの提供。 【解決手段】 補償するリソース・マネージャは、コン
ポネントベースのオンライントランザクション処理シス
テム内のトランザクションに参加するために非トランザ
クショナル・デュラブルリソースを一層容易に統合する
メカニズムを提供する。該リソースは補償するリソース
マネージャを使用して、リソースに対し正常アクション
を実装するワーカーコンポネント及びリソースに対する
正常アクションを反転する補償アクションを実装するコ
ンペンセータコンポネントの２個の単純なコンポネント
を創り出すことにより統合される。システムが供給した
サービスはワーカー・コンポネントが正常アクションを
実施するトランザクションに参加し、それがコミットす
るかアボートするかに応じてログした情報に準拠して適
切なクリーンアップ又は補償アクションを実施するコン
ペンセータコンポネントを創成する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般的にはオンラ
イン・トランザクション処理アプリケーションに関する
もので、更に特定すればオンライン・トランザクション
処理アプリケーションに対するトランザクション・マネ
ージメントシステムにおける非トランザクション・リソ
ース又は非コンプライアント・トランザクション・リソ
ースの管理に関する。

【０００２】

【従来の技術】〔本発明の背景および概要〕多くの情報
処理アプリケーションでは、分散ネットワーク中のホス
ト又はサーバー・コンピュータ上で走るサーバー・アプ
リケーションは、複数の利用者により操作されるネット
ワークの端末又はワークステーション・コンピュータ上
で走るクライアント・アプリケーションに対して処理サ
ービス又は処理方法を提供する。そのようなサーバー・
アプリケーションの一般的な例は、大学でのクラス登
録、旅行予約、銀行での送金や他のサービス、および営
業での販売に対するソフトウエアを含む。これらの例に
おいて、サーバー・アプリケーションにより実行される
処理サービスは、データベース又は他の専用フォーマッ
トのデータ記憶装置のような所に、それぞれのステーシ
ョンにおいて各ユーザによってイニシエートされるアク
ションのために、クラス・スケジュール、ホテル予約、
口座残高、注文品出荷、支払い、在庫記録の持続性のあ
るデータ又は「状態("state") 」を典型的に維持してい
る。

【０００３】度々、サーバー・アプリケーションは、１
個のコンピュータ上での分離された処理による複数のコ
ンピュータの協調活動が、しかも単一の処理にすらこの
協調活動が要請される。例えば、バンキング応用におけ
る送金操作は、地理的に離れている可能性のある別々の
コンピュータ上に存在する別々のデータベースに存在す
る口座情報の更新に関係する。１個のオペレーションの
各部分を構成する活動の集団は、通常トランザクション
と呼ばれる、１個のワークの分割できないユニットとし
て実行されるように協調されることが望ましい。多くの
アプリケーションにおいて、活動の集団を１個のトラン
ザクションとして実行することは業務上で必要なことと
なる。例えば、システム障害のために、送金操作におい
てただ１個の口座のみを更新すれば、銀行は実際にお金
を創造するか、又は破棄することになる。

【０００４】トランザクションは、アトミック性(Atomi
city),首尾一貫性(Consistency),孤立性(Isolation),及
び耐久性(Durability)を含む１組のプロパティ("ACID"
プロパティと呼ばれるもの) に準拠するアクションの集
合である。アトミック性は、１個のトランザクション中
の全てのアクティビティ(activity)が１ユニットとして
共に動作するか、又は全てが失敗するかを意味する。首
尾一貫性は、トランザクションが実行された後、システ
ムは安定又は正常状態に保たれること（即ち、トランザ
クション中のアクティビティを活性化しても正常安定状
態に到達しなければ、システムは最初のトランザクショ
ン前の状態に戻ること）を意味する。孤立性は該トラン
ザクションが他の同時に実行中のトランザクションによ
って影響されないこと（トランザクションによる共用リ
ソースへのアクセスは行列に従い、且つ共有リソースの
変更はトランザクションが終了するまでトランザクショ
ン外には見えないこと）を意味する。耐久性はトランザ
クションの効果は永久的でシステム障害に対しても生き
残ることを意味する。トランザクション処理に関する追
加の背景情報については、とりわけ1993年Morgan Kaufm
ann の刊行したJimGrayとAndreas Reuter著"Transactio
n Processing Concepts and Techniques"を参照された
い。

【０００５】本発明の出願人によるこれ以前の特許出願
（すなわち、出願日はいずれも1997年10月28日の米国特
許出願No.08/959,141, Helland他による"Automatic Tra
nsaction Processing Of Component-Based Server Appl
ications";及び、米国特許出願No.08/959,142, Helland
他による"Disabling And Enabling Transaction Commit
tal In Transactional Application Components"; を指
し、本出願はここにこれらを参照文献とし、包括的に
「合同 MTS特許出願」と呼ぶことにする）は、Microsof
t 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サーバー・アプリケーション・コンポネントに対す
るプーリング及び自動トランザクション登録を行うサー
ビス) を供給しなければならない。もしリソース・ディ
スペンサが無ければ、自動トランザクション登録のため
の他のメカニズムを供給しなければならない。

【０００９】

【発明が解決しようとする課題】これらの困難のため M
TSに対するリソース・マネジャーは未だ殆ど存在しない
（前記Microsoft SQL Server version6.5 が１例であ
る）。しかしトランザクション・サポートの無い広範な
種類のリソースが現在市場に出回り、且つ使用されてい
る。更に、MS DTSにインタフェースするような、MTS に
おいて相互運用するために要請されたインタフェース
（即ち、OLE トランザクション・インタフェース）を供
給しない他のトランザクション・システムに対する各種
のリソース・マネジャー（ここでは、遺物的リソース・
マネジャーと呼ぶ）が存在する。例えば、多くの旅行業
界の予約システムは、IBM CICSトランザクション・シス
テムの下で管理される予約データベースを持っている。
従って、各リソース毎に特有のMTS リソース・マネジャ
ーを導入するよりは一層容易に、そのような非トランザ
クション・リソース及び遺物的リソース・マネジャーを
MTS に統合することが望ましい。

【００１０】

【課題を解決するための手段】本発明は、耐久性のある
リソースをトランザクション・システム、特に MTSのよ
うなコンポネント・ベースのオンライン・トランザクシ
ョン処理アプリケーションへ、一層容易に統合すること
ができるリソース・マネージメントの一形式（ここで
は、「補償」("compensation")又は「補償するリソース
・マネージメント」("compensating resource manageme
nt")と呼ぶ）を供給する。補償するリソース・マネージ
メントにおいて、耐久性のあるリソースは、トランザク
ションの一部としてリソースに対して実行される各正常
アクションを反転する補償アクションを供給することに
よりトランザクション・システムの下でトランザクショ
ンに参画するように統合される。該正常アクションは要
請のあった時点で持続されている。トランザクションが
失敗する場合には、耐久性のあるリソースをトランザク
ション前の状態に戻すために、補償アクションがトラン
ザクション外で呼び出される。耐久性のために、トラン
ザクション中に実行される各正常アクションに対して取
られる補償アクションを識別する情報はライトアヘッド
・ベースでログに書き込まれる。このようにして、障害
の場合には、トランザクションの状況に応じて回復動作
が実行される。

【００１１】コンポネント・ベースのオンライン・トラ
ンザクション処理アプリケーション環境では、補償する
リソース・マネージメントは、補償するリソース・マネ
ジャー(CRM) を導入することにより、特定の耐久性のあ
るリソースに対して与えることができる。開発者は CRM
が耐久性のあるリソース上でサポートする各正常アクシ
ョンに対して、補償アクションをCRM 中に導入する。該
開発者は又正常アクションに対する補償アクションを明
確化するために前記の各正常アクションと関連させてラ
イトアヘッド・ロギングを実行させるためにCRM を導入
する。

【００１２】ここに例示される本発明の１個の実施例
（例示される実施例）に準拠して CRMは、ログの媒体を
通じてのみ状態（すなわちデータ）を共有する CRMワー
カー(CRM worker)及び CRMコンペンセータ(CRM compens
ator) の１対のコンポネントとして開発される。CRM ワ
ーカーはサーバー・アプリケーションに対するトランザ
クションの一部として、サーバー・アプリケーションに
よって要請の時点で正常アクションを実行する。このア
クション及びそこを通して該アクションがサーバー・ア
プリケーションによってアクセスされるインタフェース
は特定のCRM に限定される。サーバー・アプリケーショ
ンが該インタフェースを経て正常アクションを呼び出す
時に、CRM ワーカーは又CRM コンペンセータを識別する
システムが準備したログにログ記録を書き込む。

【００１３】CRM コンペンセータはCRM ワーカーの正常
動作に対応する補償アクションを実行する。CRM ワーカ
ーによって指定されたCRM コンペンセータは、CRM ワー
カーによってログされる正常アクションに関連して適切
な追加のアクションを実行することにより２フェーズ・
コミット・プロトコル（即ち、フェーズ１及びフェーズ
２）の後ろの方のフェーズに参画するために、後刻、創
成される。CRM コンペンセータは、トランザクション・
マネージャから（例示される実施例におけるログ障害回
復マネージャの方法により）２フェーズ・コミット・プ
ロトコル・ノーティフィケーション（即ち、準備、コミ
ット、及びアボートのノーティフィケーション）を受け
取るシステムにより定義されるインタフェース、をサポ
ートする。これらのノーティフィケーションは、２フェ
ーズ・コミット・プロトコルのこれらのフェーズにCRM
コンペンセータが参画することを許す。

【００１４】一層特別に、準備フェーズの間、CRM コン
ペンセータはトランザクションのコミッタル(committa
l) に反対してボート(vote)でき、準備ノーティフィケ
ーションに応じて（即ち、準備ノーティフィケーション
に応じて、"No"をボートする値を返すことにより) アボ
ートを強制できる。コミット・ノーティフィケーション
はCRM ワーカーの正常アクションの後クリーンアップ・
プロセシングを実施する機会をCRM コンペンセータに与
える。このクリーンアップ・プロセシングは、アボート
したトランザクションに対して補償する目的で維持され
ている（耐久性の、又は非耐久性の）如何なる状態も除
去することである。コミット・ノーティフィケーション
は、又コンペンセータに反転できない如何なるワークも
実行する機会を与える。例えば、ATM トランザクション
において、口座残高が減算され現金が払出されるであろ
う。減算の発生が保証されない限り現金の払出しは望ま
しくない。ATM を管理するCRM と共に、CRM コンペンセ
ータはATM に物理的に十分な現金がある限り準備ノーテ
ィフィケーションへの応答として"yes" をボートするで
あろう。ついで、コミット・ノーティフィケーションへ
の応答して、CRM コンペンセータはATM に現金を実際
に払出させる。アボーテド・ノーティフィケーションへ
の応答として、CRM コンペンセータはCRM ワーカーの正
常動作を反転させる補償アクションを実行する。従っ
て、トランザクションの正常処理の間、CRM コンペンセ
ータはトランザクション準備フェーズに参加し、トラン
ザクションの結果について知らされる。CRM コンペンセ
ータは、その時コミットに対しクリーンアップを、アボ
ートに対して補償をすることができる。一方、回復過程
中にCRM コンペンセータは再度創成され、且つログに基
づくトランザクションの結果を知らされることにより、
該CRM コンペンセータに、如何にも障害が無かったかの
ようにリソースに関連するトランザクション処理（適切
ならば）を完了させる。例えば、フェーズ１がシステム
・クラッシ以前に完了していなければ、CRM コンペンセ
ータにはアボート・ノーティフィケーションが送られ
る。

【００１５】ここに例示される実施例において、特に補
償アクションを含むCRM コンペンセータにより実行され
る（トランザクション中に実行されるワーク、又は一連
のログ記録として定義される）各アクションはべき等(i
dempotent)でなければならない。これは、トランザクシ
ョンのコミット又はアボートに対するCRM コンペンセー
タのアクションは何度でも試みることができ、且つ若し
アクションが成功すれば該アクションは如何にも該アク
ションが最初のアテンプトで成功したように同一の結果
を生じることを意味する。

【００１６】本発明の別の特徴および利点は、付属する
図面を参照しながら進展する例示の実施例の下記の詳細
説明から明白になるであろう。

【００１７】

【実施例】〔例示された実施例の詳細な説明〕本発明
は、オンライン・トランザクション処理における補償す
るリソース・マネージメントに対する方法、システム、
及びソフトウエア製品に対するものである。ここで例示
される１実施例において、本発明は、米国Redmond,Wash
ington所在の Microsoft Corporation社による "Micros
oft Windows NT Server 5.0"オペレーティング・システ
ムの一部をなす"COM+"と呼称する分散コンピューティン
グシステム上のサーバー・アプリケーションに対するオ
ペレーティング・ソフトウエアに組み込まれている。簡
単に説明すれば、このソフトウエアは、とりわけ、分散
コンピュータシステム上の１個の２フェーズ・コミット
・プロトコルを使用するトランザクション処理をサポー
トするシステム・サービスを含むサーバー・アプリケー
ションに対する１個のコンポネント・フレームワーク及
びランタイム(run-time)実行環境を提供する。

【００１８】〔典型的な動作環境〕図１及び下記の論述
は、本発明が実施されるのに適当なコンピューティング
環境に関する簡潔で一般的な記述を与えることを意図し
ている。本発明はサーバー・コンピュータ上で走るコン
ピュータプログラムのコンピュータが実行可能な命令の
一般的な状況下で記述されるが、当業者は本発明は他の
プログラム・モジュールとの組み合わせでも実行できる
ことを理解するであろう。一般的に、プログラム・モジ
ュールは、特別なタスクを実行するか又は特別な抽象デ
ータ・タイプを実装するルーチン、プログラム、コンポ
ネント、データ構造、などを含む。更に当業者は、本発
明は、シングル又はマルチ・プロセッサ・コンピュータ
システム、ミニコンピュータ、メインフレームコンピュ
ータ、パソコン、ハンドヘルド・コンピューティング・
デバイス、マイクロプロセッサ・ベース又はプログラム
が可能の消費者電子機器、及び、その他、を含む他のコ
ンピュータシステム構成と共に実施できるであろうこと
を理解するであろう。本発明の例示される実施例は、又
通信ネットワークを通じて結ばれている遠隔処理機器に
よってタスクが実行される分散コンピューティング環境
においても実行される。しかし、本発明の幾つかの実施
例はスタンドアロン・コンピュータ上でも実行可能であ
る。分散コンピューティング環境においては、プログラ
ム・モジュールはローカル及び遠隔記憶蓄積機器の両者
に配置されるであろう。

【００１９】図１を参照して、本発明の実装のための典
型的なシステムは、処理ユニット21、システムメモリ2
2、およびシステムメモリを含む各種のシステムコンポ
ネントを処理ユニット21に結合するシステムバス23、を
含む通常のサーバー・コンピュータを含む。処理ユニッ
トは市販されている種々のプロセッサ、例えば、Intelx
86, Pentium及び Intel社や Cyrix社,AMD社, Nexgen社
等の供給する互換性のあるマイクロプロセッサ;Digital
社のAlpha; MIPS Technology社,NEC社,IDT社,Siemens社
等の供給するMIPS;IBM社及びMotorola社の供給するPowe
rPC;等々の何れでも良いであろう。デュアル・マイクロ
プロセッサ及び他のマルチプロセッサ・アーキテクチャ
もまた、処理ユニット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 NTSer
verオペレーティングシステム、及び前記のMicrosoft T
ransaction 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(MT
S) のサーバー・アプリケーション実行環境を示す。MTS
実行環境82は、上記の "組み込まれたMTS 特許申請"
に一層詳細に記述されている。

【００２８】次に図２を参照して、トランザクション・
サーバー・エクゼクティブ80は、サーバー・コンピュー
タ84上のサーバー・アプリケーション・コンポネント(
例えば、サーバー・アプリケーション・コンポネント8
6) によるオンライン・トランザクション処理をサポー
トするランタイム実行環境80を創成するためのランタイ
ム又はシステム・サービスを供給する。トランザクショ
ン・サーバー・エクゼクティブ80は、又サーバー・アプ
リケーション・コンポネント86へのスレッド及びコンテ
キスト管理に対するサービスも提供する。更に、トラン
ザクション・サーバー・エクゼクティブ80は、コンポネ
ント・インテグレーション・インタフェースをサポート
する（コンポネント・コンテキスト・オブジェクト136
を含む）システム定義オブジェクトを供給する。例示さ
れたトランザクション・サーバー・エクゼクティブ80
は、ダイナミック・リンク・ライブラリ("DLL") として
実装される。(DLLは実行可能コードをアプリケーション
・プログラム処理へのダイナミック・リンク又はランタ
イム・リンクを許容する周知の実行可能なファイル書式
である。) トランザクション・サーバー・エクゼクティ
ブ80は、サーバー・アプリケーション・コンポネントを
ホストし且つこれらのプロセスの背景で透明にランする
アプリケーション・サーバー・プロセス (例えば"ASP"9
0)へ直接にロードされる。

【００２９】例示された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 Managemen
t Group のCOBRA(Common Object Request Broker Archi
tecture)仕様を含む他のオブジェクト標準に従って実装
できる。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 factor
y)122を使用して例示する責任を有する。トランザクシ
ョン・サーバー・エクゼクティブ80は、更に（同一のコ
ンピュータ上、又はネットワーク接続上に存在する）ク
ライアント・プログラムからサーバー・アプリケーショ
ン・コンポネント86へのコールを管理する。

【００３４】例示された実行環境80は、COM 必要条件を
準拠することに加えてサーバー・アプリケーション・コ
ンポネント86にある種の追加の要求条件を課す。第１
に、サーバー・アプリケーション・コンポネントはDLL
ファイル（即ち、図３のサーバー・アプリケーションDL
L120）に実装される。（さもなければ、COM オブジェク
トは実行可能な(".exe")ファイルに実装できる。）第２
は、コンポネントのDLLファイル120 は標準クラス・フ
ァクトリー122 を所有する。（すなわち、DLL はDllGet
ClassObject 方法を実装し且つエクスポートし、並びに
IClassFactory インタフェースをサポートする。）第３
に、サーバー・アプリケーション・コンポネントは標準
化できるインタフェースのみをエクスポートするが、コ
ンポネントのインタフェースの意味はタイプ・ライブラ
リにより記述されるかプロキシ・スタブ(proxy‐stub)D
LLを有する。プロキシ・スタブDLL は、クライアント・
コンピュータ92上のクライアント・プロセス132 にプロ
キシ・コンポネント130 を、及びサーバ・コンピュータ
84上のASP 90にスタブ・コンポネント131 を供給する。
プロキシ・コンポネント130 及びスタブ・コンポネント
131 は、サーバー・コンピュータ84を介してクライアン
ト・プログラム134 からのコールを導く。例示システム
中のプロキシ・スタブDLL は、Oicfコンパイラスイッチ
を持つMicrosoft Windows NT 4.0のためのMicrosoft Wi
n32 SDK を具えたMIDL version 3.00.44を使用して構築
され、且つトランザクション・サーバー・エクゼクティ
ブ80にリンクされる。これらの追加の要求条件は既知の
手法に準拠する。

【００３５】サーバー・アプリケーション・コンポネン
ト86のクライアント・プログラム134 は、サーバー・ア
プリケーション・コンポネントを使用するプログラムで
ある。クライアント・プログラムは、実行環境80の外(
トランザクション・サーバー・エクゼクティブ80の制御
外) でランするプログラム・コード( 例えば、アプリケ
ーション・プログラム、COM オブジェクトなど) である
筈である。そのようなクライアント・プログラムは"bas
e clients"として参照される。他の方法として、クライ
アント・プログラム134 は、( 同一又は別のASP 90にお
ける) トランザクション・サーバー・エクゼクティブの
制御の下でランする他のサーバー・アプリケーション・
コンポネントでも有りうる。クライアント・プログラム
134 は、サーバー・コンピュータ84上、又は（この場
合、クライアント・コンピュータはプロキシ・オブジェ
クト130 及びスタブ・オブジェクト131 を介して遠隔的
にサーバー・アプリケーション・コンポネント86と対話
する) 図２に示めされる別のクライアント・コンピュー
タ上に存在できる。

【００３６】サーバ・コンピュータ84は又リソース・マ
ネージャ140 及びリソース・ディスペンサ144 をランさ
せる。リソース・マネージャ140 は耐久性のあるデータ
( 例えば、データベース146 中のデータ) を管理するシ
ステム・サービスである。サーバー・アプリケーション
・コンポネント86は、( オンライン販売サーバー・アプ
リケーション中の、手元にある在庫の記録、未処理注
文、及び入金口座のような) サーバー・アプリケーショ
ンの耐久性のある状態を維持するためにリソース・マネ
ージャを使用できる。例示された実施例におけるリソー
ス・マネージャは、Microsoft SQL Server, 耐久性のあ
るメッセージ行列、及びトランザクション・ファイル・
システムを含む。可能ならば、リソース・マネージャ14
0 は、トランザクション・ベースで( 即ち、既知のACID
プロパティに準拠するトランザクションにおいて) サー
バー・アプリケーション・コンポネント86によってサー
バー・アプリケーションの耐久性のある状態へ変化又は
更新することを支援することが望ましい。

【００３７】リソース・ディスペンサ144 は、ASP 90中
のサーバー・アプリケーション・コンポネントに代わっ
て非耐久性共用状態を( 即ち、耐久性の補償なしに) 管
理するサービスである。リソース・ディスペンサは、又
上記の組み込まれたMTS 特許申請に記述されているよう
に、例示の実行環境への自動トランザクション登録への
責任も有する。例示の実施例におけるリソース・ディス
ペンサ144 の例は、Microsoft Open Database Connecti
vity("ODBC")コール・レベル・インタフェースに準拠の
データベース接続の集合を維持するODBCリソース・ディ
スペンサを含む。ODBCリソース・ディスペンサは、デー
タベース146 からのデータを評価するためにサーバー・
アプリケーション・コンポネントへのデータベース接続
を( 一般的に、そのリソース・マネージャ140 を介し
て) 配分する。更に、ODBCリソース・ディスペンサは、
後刻の再使用サーバー・アプリケーション・コンポネン
トによって開放される時にデータベース接続の回復をリ
クレームする。

【００３８】例示の実行環境82は更にトランザクション
・マネージャ148 を含む。トランザクション・マネージ
ャ148 は、リソース・マネージャが分散ネットワーク中
の１個以上のサーバー・コンピュータに存在する場合を
含む複数のリソース・マネージャに分散するトランザク
ションをコーディネートするシステム・サービスであ
る。トランザクション・マネージャ148 は、１個のトラ
ンザクションに関連する全てのリソース・マネージャに
渡っての更新は障害（例えば、コンピュータ又はネット
ワークのハードウエア又はソフトウエアの障害、誤動作
したリソース・マネージャ又はアプリケーションに起因
するエラー）、競合条件（例えば、１個のリソース・マ
ネージャがアボートを開始する一方でコッミトを開始す
るトランザクション）、又はアベイラビリティ（リソー
ス・マネージャがトランザクションを準備するが決して
リターンしない）に無関係に周知の２フェーズ・コッミ
ト・プロトコルを使用するACIDプロトコルに準拠して発
生することを保証する。例示のトランザクション・マネ
ージャ148 は、Microsoft SQL Server6.5 の一部として
レリーズされたMicrosoft Distributed Transaction Co
ordinator(MSDTC)である。

【００３９】〔補償するリソース・マネジャーのアーキ
テクチャ〕次に図３を参照して、補償するリソース・マ
ネジャー(CRM) のコンポネント又はオブジェクト・ベー
スのアーキテクチャ200 は、リソースに特有の完全なリ
ソース・マネジャー及びリソース・ディスペンサ（例え
ば、図２のリソース・マネジャー140 及びリソース・デ
ィスペンサ144 ）を実装する必要なしに、開発者が一層
迅速に且つ容易に耐久性のあるデータ記憶装置を持つリ
ソースをMTS 実行環境82（図２）へ統合できるように、
多数のシステムが供給したコンポネント及びシステムが
定義するインタフェースを含む。例示のアーキテクチャ
200 は特に２個のリソース・シナリオ、即ち (1)トラン
ザクション処理の独自の内部メカニズムを持つが、OLE
トランザクション・インタフェースをサポートしない遺
物か、ブラックボックスのトランザクション処理システ
ム；及び (2)トランザクション・サポートの無いリソー
ス；に適用できる。アーキテクチャ200 は、OLE トラン
ザクション・インタフェースに対するサポート持つリソ
ース・マネジャー・インフラストラクチャを供給し、且
つリソース・マネジャーに対するリソース・ディスペン
サを持つ必要性を無くすることにより、上記(1) のシナ
リオにおけるMTS環境82（図２）へ容易に統合すること
を許す。更に、アーキテクチャ200 は各シナリオ中のリ
ソースに対し、本発明に準拠の補償するリソース・マネ
ージメントの使用により、一層簡単で一層開発が容易な
リソース・マネジャーと統合されることを許す。

【００４０】例示の補償するリソース・マネジャーのア
ーキテクチャでは、開発者はリソースの補償するリソー
ス・マネージメントを供給するためにアーキテクチャ20
0 のシステムが供給するコンポネント及びインタフェー
スを使用する CRMワーカー202 と CRMコンペンセータ20
6 のみを実装する必要がある。 CRMワーカー202 と CRM
コンペンセータ206 は COMオブジェクト・モデルに準拠
するコンポネントである。 CRMワーカー202 と CRMコン
ペンセータ206 は、如何なる MTSサーバー処理（例え
ば、ASP 90）においても使用できるように、典型的に M
TSライブラリ・パッケージに実装される。

【００４１】CRM ワーカー202 において、開発者はトラ
ンザクションの一部としてリソース上で正常アクション
を実行するために該リソースに特有のロジック（即ち、
プログラム・コード）を実装する。開発者は、又CRM ワ
ーカー202 がリソースに対して正常アクションを実行す
る原因となるコールをサーバー・アプリケーション・コ
ンポネント86をそれに対して発生できるようにリソース
に特有のインタフェース( 例えば "IDoWork"インタフェ
ース210)を実装する。CRM ワーカー202 は、正常アクシ
ョンの結果は要請の直後においてリソース上で持続性で
あるように、サーバー・アプリケーション・コンポネン
トの該要請の時点においてリソース上で正常アクション
を行う。

【００４２】一方、開発者は、CRM ワーカー202 の正常
アクションに関係する補償アクションを供給するCRM コ
ンペンセータ206 中のロジックを実装する。開発者は更
に、CRM コンペンセータがトランザクション・マネージ
ャ148 （図２）から準備、コミット、及びアボートのノ
ーティフィケーションを受けるシステムが定義したイン
タフェース ("ICompensatingResourceManager"インタフ
ェース212)をサポートするためにCRM コンペンセータを
実装する。トランザクション・マネージャからのこれら
のノーティフィケーションは、システムが供給したイン
フラストラクチャである下記の障害回復エンジン及びCR
K クラークの方法でCRM コンペンセータへ伝達される。
CRM ワーカー202 が正常アクションを実行したトランザ
クションの準備フェーズ中、状況がトランザクションの
成功裏での完了を妨げるような場合にCRM コンペンセー
タは準備ノーティフィケーションへの対応としてトラン
ザクションをアボートさせるようにできる。トランザク
ションの第２フェーズにおいて、CRM コンペンセータは
リソースに対するCRM ワーカーの正常アクションに適切
なクリーンアップ・アクションを実行することにより、
コミット・ノーティフィケーションに答えることができ
る。他の方法として、CRM コンペンセータはCRM ワーカ
ーの正常アクションを反転する補償アクションを実行す
ることにより、アボート・ノーティフィケーションに答
えることができる。

【００４３】CRM ワーカー及びCRM コンペンセータの正
常、クリーンアップ及び補償のアクションは、管理され
ている特定の耐久性のあるリソースに応じて一般的に変
化する。例えば、リソースがファイル・システム又はデ
ータベースの場合は、アクションはデータの変更、新規
データの書き込み、又はデータの消し込みのようなデー
タ処理活動を含むことができる。幾つかのリソースの場
合に、CRM コンペンセータのクリーンアップ及び補償の
アクションは、データ処理に加えて、逆にできない実社
会の結果であろうATM 又は他の自動払出し機械からの現
金、切符又は他の物品の払出しのような活動を含むこと
ができる。（逆にできない物理的社会の結果を持つその
ような操作はここでは「現実の操作」("real operation
s") として参照する。）

【００４４】CRMアーキテクチャ200 の追加のコンポネ
ントは、MTS ランタイム環境及びサービスにこのように
組み込まれ、このようにして" システムにより供給され
て"いる。これにより開発者は特定のリソースに対して
特有なCRM ワーカー及びCRMコンペンセータのみを実装
し、ロギング、障害回復、及びスレッド・セイフティの
ような事項を処理するサービスの提供にはシステムによ
り供給されたコンポネントに依存することができる。例
示されたアーキテクチャ200 のシステムにより供給され
たコンポネントは、CRM クラーク222 、CRM 障害回復ク
ラーク224 、及び持続性のあるログ(persistent log)22
6 を含む。これらのコンポネントの全てはアプリケーシ
ョン・サーバー・プロセス(ASP)90 （図２にも示されて
いる）内でランする。

【００４５】CRM アーキテクチャ200 は、アーキテクチ
ャのシステムにより供給されたコンポネントはどのスレ
ッドからもコールできることを意味する個別にスレッド
・セーフであることにおいて、スレッド・セーフティを
供給する。更に、CRM アーキテクチャ200 は、MTS とイ
ンタフェースするために要求されるOLE トランザクショ
ン・インタフェースの全てをサポートする。CRM アーキ
テクチャ200 は、アーキテクチャのファンクショナリテ
ィのコンシューマ(consumer)（即ち、サーバー・アプリ
ケーション・コンポネント86）はそれら自体スレッド・
セーフであることを保証しない。CRM アーキテクチャ20
0 は、CRM コンペンセータへの全てのコールを、標準の
COM プログラム作成方法に準拠してCRM コンペンセータ
がその中に創成された同一アパートメント内に向かわせ
ることを保証する。換言すれば、CRM アーキテクチャ
は、そのコンジューマは少なくともアパートメント・モ
デル・コンポネント（周知のスレッディング・モデル）
であることを想定する。

【００４６】CRM クラーク222 及びCRM 障害回復クラー
ク224 は、アーキテクチャ200 中でロギング及び障害回
復サービスを提供する。正常操作中、各CRM ワーカー20
2 はCRM クラークの自分自身のインタンスを創成する。
（即ち、CRM ワーカーとCRMクラークとの間に１対１の
関係がある。）CRM ワーカー202 は、持続性のあるログ
226 にログすべき情報を行列させるためにシステムが定
義したインタフェースであるICrmLogControlインタフェ
ース230 を介してCRM クラーク222 にアクセスする。CR
M クラークは、ログに書き込まれる前に追加の情報をロ
グ記録に加えるであろう。正常プロセシングの間、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 は、"CoCreateI
nstance()"API 方法をCRM 障害回復クラークのCLSID と
共に呼び出すことにより得られる"ICrmMonitor" インタ
フェース234 をサポートする。"ICrmMonitor" インタフ
ェース234 は、ASP 90中のCRM に対し何れのトランザク
ションが現在進行中であるかを( 操作者又は監視者にユ
ーザ・ディスプレー又は対話を提供するプログラム又は
COM コンポネントによるような方法で) 監視するのに使
用される。CRM コンペンセータ206 の登録( 下記の"Reg
isterCompensator()" 方法参照) の時にCRM ワーカーに
より供給されるテキスト記述は、特定のCRM 活動を探索
するのを援助するために利用可能である。

【００４９】"ICrmMonitor" インタフェースは、補償す
るリソース・マネジャー・アーキテクチャ200 のCRM ク
ラーク222 をトラックするクラーク・コレクション・オ
ブジェクト上の"ICrmMonitorClerks" インタフェースへ
のインタフェース・ポインタを得るための方法("GetCle
rks()") を供給する。"ICrmMonitorClerks" インタフェ
ースは図17に示めされるプログラム・リスティング319
において定義される。このインタフェースを通じて、CR
M クラーク222 上にサポートされる"ICrmMonitorLogRec
ords" インタフェースへのポインタが得られる。"ICrmM
onitorLogRecords" インタフェースは、下記の人手によ
る障害回復のようなことのために、与えられたトランザ
クションに対する特定のCRM クラークにより維持される
個別のログ記録を監視するのに使用される。"ICrmMonit
orLogRecords" は、図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 障害回復クラーク2
24 を通じて) 十分な情報をログする。CRM ワーカー202
は，又CRM コンペンセータ206 のクラス識別子("CLASI
D")をCRF クラーク222 と共に登録する。後刻、トラン
ザクションが終了（それは、MTS環境においては、典型
的に、上記の組み込まれたMTS 特許申請に記述されたよ
うに、トランザクション中のサーバー・アプリケーショ
ン・コンポネント86からのSetComplete 又はSetAbortの
コールに対する応答である）する時に、CRM クラーク22
2 は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 、CR
M 障害回復クラーク224及び障害回復エンジン242 によ
り使用される"ILog"インタフェース246 を介してログ・
ファイル244 からログ記録を読み書きするための方法を
供給する。

【００５３】ログ・ファイル244 はログ記録が記憶され
るファイル・システムの１個のファイル又はファイルの
集合のような非揮発性記憶装置（例えば、図１のハード
・ディスク・ドライブ）に記憶される連続するデータ・
ストリームである。例示のログ・ファイル244 は、Micr
osoft TXF ファイル・フォーマットを持つファイルであ
る。例示のログ・ファイル244 中の各ログ記録は、連続
ストリーム中で64ビット整数を単調に増加させるログ・
シーケンス番号(LSN) により識別される。個別のログ・
ファイルがコンピュータ20（図１）上の各ASP 90のため
に維持されている。例示アーキテクチャ200 において、
ログ・ファイル244 は、各ASP 90に関係する独自の識別
子( 例えば、Microsoft Windows NTオペレーティング・
システム中の"Appld")に基づくファイル名により識別さ
れ、且つトランザクション・マネージャ148 のログとし
て同一ファイル・システム・パス上に常駐する。これは
ログに基づく障害回復を容易にする。

【００５４】障害回復エンジン242 は、障害から障害回
復を実行させるためのログ障害回復プロトコルに従って
ログ・ファイル244 からログ記録を処理するために"ILo
gRecover" インタフェース248 及び"IlogRecoverClerkR
egistration"インタフェースを介してサービスを提供す
るCOM オブジェクトである。例示の障害回復エンジン24
2 に実装される障害回復プロセシングは、他のログ障害
回復プロトコル又はそれの変形が代わりに使用できる
が、周知のARIES ログ障害回復プロトコルに基づく。(M
ichael Stonebraker編"Readings in Database Systems"
第２版,1994’中のC.Mohan,D.Haderle,B.Lindsay,H.Pir
ahesh及びP.Schwarz による"ARIES：A Transaction Rec
overy Method Supporting Fine-Granularity Locking a
nd 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"Automa
tic Transaction ProcessingOf Component-Based Serve
r Applications"に記述のトランザクションに自動的に
CRMワーカー202 を関連させる。

【００５６】次のステップ252 において、CRM ワーカー
202 は、CRM クラーク222 のインスタンスを創成し、且
つ"CreateInstance()"方法（オブジェクト・インスタン
シエーションのために使用されるCOM ランタイム・ライ
ブラリにおける周知のアプリケーション・プログラミン
グ・インタフェース(API) 方法）を呼び出し、且つCRM
クラーク222 のCLSID 及びICrmLogControlインタフェー
スのIID を規定することによりCRM クラーク222 のICrm
LogControlインタフェース230 へのインタフェース・リ
ファレンスを得る。これは又CRM クラーク・インスタン
スを自動的にトランザクション中に関連させる。

【００５７】ICrmLogControlインタフェース・リファレ
ンスを得た後、CRM ワーカー202 は、ステップ253 に示
すようにCRM ワーカー202 に対する補完者のCRM コンペ
ンセータ206 をCRM クラーク222 と共に登録するために
インタフェースの"RegisterCompensator()" 方法を呼び
出す。CRM ワーカー202 は、後刻CRM コンペンセータ20
6 を創成するためにCOM の下でCRM クラーク222 のため
に十分なアイデンティフィケーションを与える、そのク
ラスの識別子（例えば、プログラム識別子(PROGID)又は
クラス識別子(CLSID) ）によってCRM コンペンセータ20
6 を登録する。

【００５８】更に、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 に１連のログ記録を書き込み、次いで("ForceL
og()" 方法を使用する) 要請されたワークを実行する前
にライトアヘッド・ベースで持続性のあるログへ該記録
を書き出させるようにする。

【００６０】後刻、ステップ256 において、トランザク
ション・マネージャ148 は CRMワーカー202 によって以
前に書かれたログ記録と共にノーティフィケーションを
CRMクラーク222 に渡す障害回復エンジン242 を含むト
ランザクション上のパーティシパント(participants)
（即ち、該トランザクションにリストされたコンポネン
ト）へ２フェーズ・コミット・プロトコル・ノーティフ
ィケーションを発出する。典型的に、これらのノーティ
フィケーションは、トランザクションをイニシエートし
たサーバー・アプリケーション・コンポネント86がトラ
ンザクション中の全てのワークが完了していることを示
すSetComplete を呼び出したか、又はトランザクション
中のコンポネントがワークは成功裏には完了できないこ
とを示すSetAbortを呼び出す後に送出される。 SetComp
lete及びSetAbortは、システムにより供給されるコンテ
キスト・オブジェクト136 （図２）のインタフェース方
法であり、且つ上記の組み込まれたMTS 特許申請に一層
詳細に記述されている。トランザクション・マネージャ
148 は、(OLEトランザクション・インタフェースの一部
である)ITransactionResourceAsyncインタフェース238
上の障害回復エンジン242 へ、２フェーズ・コミット・
プロトコル・ノーティフィケーションを発出する。

【００６１】各２フェーズ・コミット・プロトコル・ノ
ーティフィケーションへの応答として、ステップ257 に
おいてCRM クラーク222 は、以前にCRM ワーカー202 に
よってCRM クラーク222 と共に登録されたCRM コンペン
セータ206 を創成する。ステップ258 において、CRM ク
ラーク222 は、次いでノーティフィケーション及び関連
するログ記録をCRM コンペンセータ206 に渡すためにIC
rmCompensator インタフェース212 の適切な方法を呼び
出す。CRM コンペンセータ206 へのその呼び出しと共
に、CRM クラーク222 は、CRM コンペンセータにその補
償アクションのログ記録を書き込ませるためにICrmLogC
ontrolインタフェース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)のバッファに過ぎない。典型的に、Microsof
t Visual Basicプログラミング言語で書かれたCRM ワー
カーは、構造化されたログ記録を書くであろう一方、Mi
crosoft 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インタフェース上に"ForceLo
g()"方法を呼び出す。このようにして分離された"Write
LogRecord()"及び"ForceLog()"の方法は、CRM ワーカー
202 に複数のログ記録を行列させるようにし、且つそれ
らを纏めて持続性のあるログに書き込ませて、ロギング
能率を強化する。

【００６７】CRM クラーク222 中への"WriteLogRecor
d()"、"WriteLogRecordVariants()"及び"ForceLog()"の
実装は、ログ・ファイル244 に書かれたログ記録をキャ
シュ(cache) し、続いてフォースする。

【００６８】〔チェックポイント〕図３を再度参照し
て、持続性のあるログ226 は、ログ・ファイル244 中の
完了したログ記録のスペースの返還を要請するするため
に、チェックポイントを使用する。

【００６９】CRM 障害回復クラーク224 は、ILogRecove
r インタフェース248 上に"TakeCheckpoint()"方法を呼
び出すことにより、障害回復エンジン242 へイニシエー
ト・チェックポイント要請を発出する。CRM 障害回復ク
ラーク224 は、イベント又はタイムアウトを待つバック
グランド・スレッド(background thread) を持つ。タイ
ムアウトにおいて、CRM 障害回復クラーク224 は最終チ
ェックポイント以降に何らかのログ記録が書き込まれた
かを検査する。もし、そうでなければ、チェックポイン
ト要請はイニシエートされない。これらの周期的なチェ
ックポイント要請は、障害回復エンジンに、もしログ記
録のトランザクション速度及び量に対して十分でなけれ
ば、ログ・ファイル244 を自動的にリサイズ又は拡大す
ることを許容する。

【００７０】CRM 障害回復クラーク224 は、又チェック
ポイント要請がイニシエートされる前に現在何らかのCR
M クラークが存在しないかを検査する。もし存在しない
ならば、チェックポイント要請はイニシエートされな
い。もし現在CRM クラークが存在すれば、CRM 障害回復
クラーク224 は、CRM クラークが障害回復プロセシング
中に正しく創成されることができるように、CRM クラー
クのためにクラーク・インスタンス識別子をログする。
CRM 障害回復クラーク224 は、全ての現在のCRMクラー
クのクラーク・インスタンス識別子を有する単一ログ記
録の"clerk listrecord" をログする。

【００７１】CRM 障害回復クラーク224 は、更にログの
トランケーション(truncation)を管理する。障害回復エ
ンジン242 によるチェックポイント・プロセシング中、
("ILogRecoverClerk::WriteCheckpoint()"方法を使用す
る) 障害回復エンジン242 は、CRM 障害回復クラーク22
4 及び各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 は、チェック・ポイント
記録開始点にチェック・ポイントを書き込むことから始
めて、チェック・ポイント記録終了点で終了する。この
ことは、チェック・ポイントの境界が障害回復のあいだ
正確に識別され、且つチェック・ポイントが成功裏に完
了したか障害で中断したかを判断できるようにする。CR
M クラーク222 は、更にそれが書き込む各ログ記録の連
続番号を付与し、且つチェック・ポイントで前方へコピ
ーしたログ記録にコピー・フラッグを加える。( 忘れら
れるべき以前のログ記録を識別する) フォーゲット記録
を前方へコピーする時に、CRM クラーク222 は、その新
しい( 前方へコピーした)LSNによって忘れられたログ記
録を適切に識別するためにフォーゲット記録を更新す
る。

【００７４】チェック・ポイント・プロセシング中、CR
M クラーク222 は、CRM クラークを経由して書き込まれ
たログ記録の順序を維持するために、CRM ワーカー202
又はCRM コンペンセータ206 からの新規のログ記録書き
込みを阻止する。また、２フェーズ・コミット・ノーテ
ィフィケーションは、チェック・ポイントが進行中は、
阻止される。同様に、チェック・ポイント要請は、持続
性のあるログ226 への正常書き込み中、及びトランザク
ション完了ノーティフィケーションを処理中は阻止され
る。

【００７５】〔補償〕図３に例示のCRM アーキテクチャ
200 において、トランザクション・マネージャ148 （図
２）は、（CRM クラーク222 の障害回復エンジンとの登
録中にトランザクションのリストに乗せられる）障害回
復エンジン242 のITransactionResourceAsync インタフ
ェース238 を通じて補償するリソース・マネージャへ２
フェーズ・コミット・ノーティフィケーションを与え
る。各ノーティフィケーションに対して、障害回復エン
ジン242 は、（CRM ワーカー202 によって書き込まれた
ログ記録を含む）CRM クラーク222 のクラーク・インス
タンス識別子に関連してログに書き込まれた全てのログ
記録を読み出す。次いで、障害回復エンジン242 は、CR
M クラークの（下記の）ILogRecoverClerkPhaseNotific
ation インタフェースを使用するCRM クラーク222 へノ
ーティフィケーション及びログ記録を渡す。

【００７６】CRM クラーク222 は、CRM リソース・ディ
スペンサ220 と共に登録されたCLSID を使用するCRM コ
ンペンセータ206 を創成することにより障害回復エンジ
ン242 のコールに応答する。次いで、CRM クラーク222
は、それぞれの２フェーズ・コミット・ノーティフィケ
ーション（例えば、準備フェーズ・ノーティフィケーシ
ョンに対するBeginPrepare(),PrepareRecord()、及びEn
dPrepare()）に対して適切なCRM コンペンセータ206 上
のICrmCompensator(非構造化ログ記録の場合)又はICrmC
ompensatorVarients(構造化ログ記録の場合) の方法を
呼び出す。CRMクラーク222 は、追加的に、そのICrmLog
Controlインタフェースに対するポインタを、CRM コン
ペンセータがその補償アクションのロギイングのために
使用するCRM コンペンセータ206 のICrmLogCompensator
（又は、ICrmCompensatorVarients ）インタフェース21
2 上の"SetLogControl" 方法へのコールに渡す。

【００７７】２フェーズ・コミット・ノーティフィケー
ション方法のCRM コンペンセータ206 への実装は、CRM
ワーカーによりログされたアクションに対するリソース
に特定される適切なアクションを実行する。（上記のよ
うに、CRM コンペンセータの実装は、例えば特定のリソ
ースに対する補償するリソース・マネージャのシステム
・インテグレータ又は他のプログラマーであるデベロッ
パーにより供給される。）プリペア・ノーティフィケー
ション方法（すなわち"BeginPrepare()"方法，"Prepare
Record()"方法，及び"EndPrepare()"方法）において、C
RM コンペンセータはトランザクション内のリソースに
対して実行されたワークはコミットするのに適切に準備
されているか否かを決定する。CRM コンペンセータの実
装の大部分の場合は、トランザクション中のCRM ワーカ
ー202 のワークは、それがCRM ワーカーによって実行さ
れた時点で既にリソース上に持続されている。従って、
CRM コンペンセータは、"EndPrepare()"方法の"bOkToPr
epare"パラメータを"VARIANT＿TRUE" に単にセットして
リターンするように、実装されることができる。他の実
装において、CRM コンペンセータ206 は、ワークはパー
シスタントとして残るべきか、又は補償されるべきかを
決定するためのチェックを実行し、且つそれに従って"b
OkToPrepare"パラメータをセットするであろう。例え
ば、このチェックはCRM ワーカーにより実行されたワー
クは正しいか又は首尾一貫(consistent)しているかを決
定するであろう。

【００７８】コミット・ノーティフィケーション（例え
ば、"BeginCommit()","CommitRecord", 及び"EndCommit
()" 方法）に対して、CRM コンペンセータ206 は、リソ
ース上のCRM ワーカーのワークを完了するために、何ら
かのクリーンアップ・アクションを実行できる。例え
ば、リソースがファイル・システムであり且つ補償する
リソース・マネージャがトランザクション中のファイル
を消去する能力を与えるべきであれば、CRM ワーカーの
正常アクションは、そのファイルがトランザクションの
アボートに当たり復元できるように、消去されるべきフ
ァイルにネームを再付与するか又は隠すことであろう。
この例におけるCRM コンペンセータは、トランザクショ
ンのコミットに応じてネームが再付与されたか又は隠さ
れたファイルを実際に消去するクリーンアップ・アクシ
ョンを実行する。CRM コンペンセータは、ネームが再付
与されたか又は隠されたファイルのネームを読み出すよ
うなCRM ワーカーのアクションのログ記録を（"CommitR
ecord()"方法を介して）受け取る。CRM コンペンセータ
は、又障害回復の目的でクリーンアップ・アクションを
ログするためにCRM クラーク222 のICrmLogControlイン
タフェースを使用する。CRM コンペンセータは、クリー
ンアップ・アクションが実行されたことを確証するため
にクリーンアップ・アクションの実行後ログ情報を書き
込む。例えば消去ファイル補償リソースマネージャの上
記の例において、CRM コンペンセータ206 はファイルの
消去後にネームが再付与されたか又は隠されたファイル
が消去されたことをログする。トランザクションのコミ
ット・フェーズ中に障害が発生すれば、続く障害回復中
はクリーンアップ・アクションを除外することができ
る。"EndCommit()" 方法に実装されるクリーンアップ・
アクションは、最初のアテンプトで成功するような同じ
結果を得る複数回数アテンプトできるように、ベキ等(i
dempotent)であるべきである。CRM コンペンセータがク
リーンアップ・アクションを実行する後ではあるがその
クリーンアップ・アクションが実行されたことをロギン
グする前に障害が発生するか、又は障害が障害回復中に
発生する場合が、そのような実例である。

【００７９】アボート・ノーティフィケーション方法に
おいて、CRM コンペンセータ206 は、典型的に既にリソ
ース上に持続するCRM ワーカー202 のワークを逆転する
イデムポテント補償アクションを実行する。CRM コンペ
ンセータは "AbortRecord()"方法を持つCRM ワーカーに
よってログされた情報を受け取る。CRM コンペンセータ
は、又CRM クラーク222 との補償アクションを事後書き
込みベースでログする。例えば消去ファイル補償リソー
スマネージャの上記の例において、CRM コンペンセータ
を"EndAbort()"方法内のネームが再付与されたか又は隠
されたファイルを復元するように実装することができ
る。

【００８０】CRM コンペンセータがコミット又はアボー
ト・ノーティフィケーションに対するその補償アクショ
ンの処理を成功裏に完了した後、CRM クラーク222 は、
その処理を完了したことを示すクラーク・エンド・ログ
記録を持続性のあるログ226に書き込み、CRM クラーク2
22 は開放されることができる。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 上に実装されたILogRe
coverClerk・インタフェース及び各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クラークへ渡す。CR
M クラークは適切な障害回復プロセシングを実行するた
めに全てのログ記録を分析する。先ず、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"インタフェースの "Begi
nRedoPass()"方法，"RedoRecord()"方法,"BeginUndo()"
方法，及び"UndoRecord()"方法を介して) やり直し及び
元に戻すフェーズを経てCRM障害回復クラーク224 及びC
RM クラーク222 をドライブし、又 (IRecoverClerkPhas
eNotificationインタフェースを介して) ノーティフィ
ケーションをCRM クラークのトランザクションのステー
タスに対するものとしてCRM クラークへ渡す。CRM 障害
回復クラーク224 及びCRM クラーク222 は、障害回復の
やり直し及び元に戻すフェーズを無視する。障害回復エ
ンジン242 は、正常プロセシング中にログしたログ記録
から又は再度トランザクション・マネージャ148 （図
２）と共にトランザクションのリストに乗せることによ
りトランザクション・ステータスを決定する。

【００８７】もし障害回復エンジン242 がトランザクシ
ョンのためにログした準備記録を見つければ、障害回復
エンジンは障害回復中トランザクションを持っているCR
M クラーク222 に準備ノーティフィケーションを (IRec
overClerkPhaseNotificationインタフェースの "OnPrep
are()"方法を介して) 渡す。しかし、準備は障害回復中
CRM コンペンセータに対し十分な意味を持たないので、
CRM クラーク222 はCRM コンペンセータに対し準備ノー
ティフィケーションを渡さない。

【００８８】トランザクションがコッミトされたか、又
はアボートされたかを決定すると、障害回復エンジン24
2 は適切なノーティフィケーションを (IRecoverClerkP
haseNotificationインタフェースの"OnCommit()"方法又
は "OnAbort()"方法を介して) 障害回復中トランザクシ
ョンを持っているCRM クラーク222 に渡す。正常プロセ
シング中と同様に、CRM クラーク222 は、これらのノー
ティフィケーションに対してCRM コンペンセータを創成
し、且つCRM ワーカーによって(ICrmCompensatorインタ
フェース212 の "BeginCommit()"方法，"CommitRecor
d()"方法,"EndCommit()"方法，"BeginAbort()"方法,"Ab
ortRecord()"方法及び"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 コンペンセータは、あ
たかもクリーンアップ及び補償アクションが成功したよ
うに、適切な情報のロギングをすること、及び"EndComm
it()" 又は"EndAbort()"コールからの回答として「成
功」("success") を表示する（即ち、該方法の HRESULT
リターン値として）ことを継続する。必要とあれば、CR
M コンペンセータは、CRM クラークが、それによりログ
記録がCRM クラークから渡される"CommitRecord()"又は
"AbortRecord"コールへ、誤りコードを戻すことにより
ログ記録をスタートから再プレーをする、ことを要請で
きる。これは、CRM コンペンセータがログ記録をプロセ
シング中の途中に人的補償を要求する障害が発生する時
に後刻の人的補償において使用するために、ログ記録の
全てのシーケンスが別のファイルにセーブされることを
許容する。

【００９２】操作する人間への通知は、スクリーン上の
可視警報、可聴警報、プリントアウト報告、又は他の警
報の形態であろう。通常、操作する人間が要求される手
動での修復アクションを実行するために十分な情報を提
供するために、警報は、人間が読める形式でのトランザ
クションに関連するログ記録を含むか、他の方法とし
て、操作する人間がそのような記録を検査する方法（例
えば、ログ・ビューイング・ユーティリティを使用し
て、操作する人間が見ることができる別のファイルにロ
グ記録を書き込む）を提供するであろう。

【００９３】例えば、クレジット・カード請求を取り扱
う補償リソース・マネージャは、クレジット・カード料
金に対する補償アクションの一部として人的補償を使用
するかも知れない。トランザクションがアボートされた
所での補償アクションは口座に入金を実行しなければな
らない。口座情報にアクセスする必要のある他のコンピ
ュータ又は通信リンクが使用できないような理由のため
にCRM コンペンセータが口座に入金できなければ、その
代わりにCRM コンペンセータは人的介入によって補償ア
クションを実行することができる。CRM コンペンセータ
は、取扱者に人間によるアクションが必要であると通知
し、且つ取扱者が何れの口座に入金すべきかとその額を
決定するためにログ記録へのアクセスを提供するであろ
う。

【００９４】〔遅延された障害回復(Deferred Recover
y) 〕CRM アーキテクチャ200 （図３）と共に実装され
ているある種の補償リソース・マネージャにおいて、CR
M コンペンセータ206 は、他の方法として、そのクリー
ンアップ及び補償アクションの一部として遅延された障
害回復を使用できる。遅延された障害回復において、CR
M ワーカーの正常アクションのログ記録は、CRM コンペ
ンセータ206 のクリーンアップ及び補償アクションが正
常プロセシング中又は障害回復プロセシング中に障害と
なった時に、持続性のあるログ226 に留まる。CRM コン
ペンセータ206 は"EndCommit()" 又は"EndAbort()"方法
から障害結果を返す。トランザクションのコッミト又は
アボートが完了しないので、トランザクションは存在し
続け且つトランザクション・マネージャ148 （図２）は
トランザクション上の情報を保持する。しかし、CRM ア
ーキテクチャ200 及びMTS実行環境82は（もし障害回復
中であれば）障害回復プロセシングを継続し、且つ他の
正常プロセシングも継続する。後刻の障害回復におい
て、CRM クラーク222はCRM コンペンセータ206 に遅延
されたクリーンアップ又は補償アクションを再度試みさ
せる。

【００９５】〔インタフェース定義〕 ＜ICrmLogControlインタフェース＞再度、図３を参照し
て、CRM クラーク222はICrmLogControlインタフェース2
30 をサポートする。ICrmLogControlインタフェース
は、記録を持続性の有るログ226 に書き込むために、CR
M ワーカー及び多分CRM コンペンセータ212 によって使
用される。CRM ワーカー202 は、又ICrmLogControlイン
タフェース230 を使用して、自身と対になっているCRM
コンペンセータ212 をCRM クラーク222 と共に登録す
る。

【００９６】ICrmLogControlインタフェースは、図６の
プログラム・リストに示すように、１組の方法を供給す
る。"TransactionUOW()"方法は、CRM ワーカーが正常ア
クションを実行するトランザクションのTransaction Un
it Of Work識別子を得るためにCRM によって使用され
る。

【００９７】上記のように、CRM ワーカー202 は、自身
と対になっているCRM コンペンセータ212 をCRM クラー
ク222 と共に登録するために、"RegisterCompensato
r()" 方法を呼び出す。CRM ワーカー202 は、ICrmLogCo
ntrolインタフェースへのポインターを得た後、先ず該
方法を呼び出し（即ち、持続性のあるログに何らかのロ
グ記録を書き込むためにインタフェースを使用する前
に）、且つ該方法を一度のみ成功的に呼び出すことがで
きる（引き続いてのアテンプト又は該方法を呼び出すた
めのCRM コンペンセータによるアテンプトはE ＿FAIL返
却値(return value)の結果となる）。CRM ワーカー202
は、CRM コンペンセータ206 のストリング・フォーマッ
ト中のクラス識別子(CLASID)又はプログラム識別子(PRO
GID)を、コール内の"IpcwstrProgldCompensator"パラメ
ータとして定義する。CRM ワーカー202は、テキスト記
述を、監視又は管理に使用されるために"IpcwstrDescri
ption"パラメータ内へ渡す。CRM コンペンセータの登録
に加えて、該方法は、CRM が先へ進行できることを保証
するために、多数の有効性(validation)チェックを実行
する。これらのチェックは、CRM コンペンセータが創成
されたこと及びそれが（下記の）ICrmCompensator 又は
ICrmCompensatorVarients インタフェースの少なくとも
１個をサポートすることを検証することを含む。もしそ
うでなければ、該方法は"E＿FAIL" 又は"E＿NOINTERFAC
E"値をそれぞれ返す。該方法は、更に現在のコンテキス
トは有効なトランザクション及びアクティビティ識別子
を持つことをチェックする。最後に、CRM 障害回復クラ
ークが障害回復プロセシングを完了していないか、又は
それがCRM に対して致命的な誤りを検出した時は、該方
法は、"XACT ＿E ＿RECOVERYINPROGRESS" 又は"E＿FAI
L" 値をそれぞれ返す。

【００９８】"WriteLogRecordVarients()"方法がログに
構造化ログ記録を書き込むためにCRM ワーカー202 及び
CRM コンペンセータ206 により呼び出される。構造化さ
れた記録はVariant 型の数値の集合として作成される記
録である。典型的に、この方法は、CRM ワーカー及びCR
M コンペンセータがMicrosoft Visual Basicで書かれ、
且つ構造化された記録がVisual Basic Collection オブ
ジェクトである場合に使用される。該方法は、もしCRM
ワーカー202 により登録されたCRM コンペンセータ206
がICrmCompensatorVarients インタフェースをサポート
しなければ、障害コードを返す。CRM ワーカー及びCRM
コンペンセータは、構造化ログ記録と非構造化ログ記録
の両者を使用することは許容されない。従って、"Write
LogRecord()"方法への以前の成功したコールの後でのこ
の方法へのコールは、"E＿FAIL"値を返すであろう。該
方法は、又トランザクションが完了後にCRM ワーカー20
2により呼び出されるか、又は完了の過程にある時に
は、"E＿FAIL" 値を返すであろう。しかし、CRM コンペ
ンセータは、トランザクション・アウトカム・ノーティ
フィケーションの間に更にログ記録を書き込むために、
該方法を使用することを継続できる。

【００９９】"WriteLogRecord()"又は"WriteLogRecordV
arients()"方法を使用して以前に書き込まれたログ記録
を、障害にも残存するコンピュータの持続性のあるメモ
リ（例えば、図１のハードディスクドライブ27）中に存
在する持続性のあるログ226に書き上げるようにするた
めに、"ForceLog()"方法がCRM ワーカー202 及びCRMコ
ンペンセータ206 により呼び出される。持続性のあるよ
うにされたログ記録を持って、CRM ワーカー202 はリソ
ースに対して正常動作を進めることができる。

【０１００】"ForgetLogRecord()" 方法がCRM ワーカー
202 及びCRM コンペンセータ206 により呼び出され、CR
M クラークに（例えば "WriteLogRecord()" 又は"Write
LogRecordVarients()"方法を使用して）書き込まれた最
終ログ記録を忘れさせる。例示のCRM アーキテクチャに
おいて、該方法は書き込まれた最終ログ記録を忘れさせ
るためのみに使用可能であり、入れ子(nesting) は許さ
れない。忘れられたログ記録は、２フェーズ・コッミト
・ノーティフィケーション中、CRM コンペンセータには
伝達されない。

【０１０１】CRM ワーカー202 は、トランザクションを
( 例えば、上記の組み込まれたMTS特許申請に一層詳細
に記述されているように、MTS ITransaction::Abort 方
法を介して) 一方的に、直ちにアボートさせるために"F
orceTransactionToAbort" 方法を呼び出す。登録された
CRM コンペンセータ206 からの該方法へのコールは、ト
ランザクションが完了過程に無い限りCRM コンペンセー
タはアクティブでないので、障害コード"E＿FAIL" を返
す。

【０１０２】(CRMワーカー及びCRM コンペンセータがMi
crosoft Visual C++又はVisual J++で書かれている時に
典型的に使用される) 非構造化ログ記録を書かせるため
に、"WriteLogRecord()"方法がCRM ワーカー202 及びCR
M コンペンセータ206 により呼び出される。該非構造化
ログ記録は単にバイトのバッファである。該方法は、ロ
グ記録のセクションをCRM ワーカー( 又は、コンペンセ
ータ) によりそのようなバッファの配列(array)("rgBlo
b"パラメータ) として構築することを許すギャザーリン
グ機能を供給し、次いでそれらのバッファはCRM クラー
クによって維持されている１個のバッファにこの方法に
よる単一操作によりコピーされる。該方法は、下記の場
合に障害コード("E ＿FAIL")を返すであろう：(1) 登録
されたCRM コンペンセータがICrmCompensator インタフ
ェースをサポートしない；(2) 該方法は(CRMクラークは
構造化及び非構造化記録の混合を許容しないため)"Writ
eLogRecordVarients()" 方法に対する事前の成功したコ
ールの後で呼び出された；(3) CRM ワーカーがトランザ
クションが完了した後か又は完了過程にある時に該方法
を呼び出す。

【０１０３】＜ICrmCompensator 及びICrmCompensatorV
arients インタフェース＞更に図３を参照して、CRM コ
ンペンセータ206 は ICrmCompensator又はICrmCompensa
torVarients インタフェースの一方、又は双方をサポー
トする。該インタフェースは、２フェーズ・コッミト・
ノーティフィケーション及び正常アクション中にCRMワ
ーカーによってログされる記録のCRM コンペンセータへ
の伝達のために、CRMクラーク222 によって使用され
る。ICrmLogControlインタフェースのために上記に記述
したように、特定のCRM に対する記録は、"WriteLogRec
ord()"又は"WriteLogRecordVarients()"方法の何れが使
用されたかに応じて全てが構造化又は非構造化のいずれ
かであることがそれぞれ要求される。ICrmCompensator
インタフェースは非構造化ログ記録の伝達に使用され、
一方、ICrmCompensatorVarients インタフェースは構造
化ログ記録をCRM コンペンセータへ伝達する。

【０１０４】ICrmCompensator 及びICrmCompensatorVar
ients インタフェースは、図７及び８に示されるプログ
ラム・リスト302-303 において定義される。"SetLogCon
trol()" 方法がCRM コンペンセータを創成した後、CRM
クラーク222 が先ず呼び出され、CRM クラークのICrmCo
ntrol インタフェース230 のポインターを("pLogContro
l"パラメータとして)CRMコンペンセータ212 へ渡す。こ
れはCRM コンペンセータにトランザクション完了中に更
にログ記録を書き込むことを許す。この方法からの"S＿
OK" 以外のリターン値は、CRM コンペンセータに対する
レジストリ(registry)フラッグCLSID 経由で特別にオー
バライド(override)されない限り,ASPの"failfast"を引
き起こすであろうCRM コンペンセータの障害と見なされ
る。

【０１０５】"BeginPrerare()"方法は、CRM コンペンセ
ータへの準備ノーティフィケーション( ２フェーズ・コ
ッミト・プロトコルのフェーズ１）としてCRM クラーク
222により呼び出され、且つログ記録が正に伝達されよ
うとしていることを示す。準備ノーティフィケーション
は、正常プロセシング中にのみ送出され、障害回復中は
送出されない。更に、"S＿OK" 以外のリターン値はCRM
コンペンセータ誤りと見做される。

【０１０６】"PrepareRecord()" 方法は、準備フェーズ
中ログ記録をCRM コンペンセータへ伝達するために、CR
M クラーク222 により呼び出される。ログ記録は正方向
順序で伝達される。非構造化ログ記録は、フラッグ・フ
イールド("dwCrmFlags")、シーケンス番号("dwSequence
Number")、及びログ記録データ("blobUserData")を所有
する"CrmLogRecordRead"データ構造として伝達される。
フラッグ・フイールド及びシーケンス番号は、デバッグ
又は人的補償が必要な環境下での障害識別に有効であろ
う情報を提供する。フラッグ・フイールドは、記録は忘
れられたか、及び何時記録は書き込まれたか、を示すフ
ラッグを含む。ログ記録のシーケンス番号は、持続性の
あるログ226 中のそのシーケンスを示す。CRM コンペン
セータ206 はCRM クラークにこの方法のコールにより伝
達されるログ記録を忘れさせるようにするために、該方
法からの復帰において、フォーゲット・フラグ("pfForg
et" パラメータ) を設定する。CRM コンペンセータは、
忘れられたものや準備フェーズ中にCRM コンペンセータ
により書かれたものを含むCRM ワーカーにより書き込ま
れた全てのログ記録、の伝達を繰り返すことをCRM クラ
ーク222 にさせるようにするために、数値"ERROR＿REPL
AY＿RECORDS"を返すことができる。"S＿OK"又は"ERROR
＿REPLAY＿RECORDS"以外の回答数値は、ASP 90のフェー
ルファースト(failfast)の原因となるCRM コンペンセー
タ誤りと見做される。"PrepareRecordVarients()" 方法
は"PrepareRecord()" 方法に類似であるが構造化ログ記
録を伝達する。

【０１０７】"EndPrepare()"方法は、準備フェーズ中に
利用可能な全てのログ記録は伝達を終えたことを示すた
めに、CRM クラーク222 によって呼び出される。もしCR
M ワーカー202 によりログ記録が書き込まれなければ、
CRM クラークは、その"BeginPrepare()"及び"EndPrepar
e()"方法の呼出し間での"PrepareRecord()" 又は"Prepa
reRecordVariants()" 方法の呼出しを省略する。CRM コ
ンペンセータは、"fOKToPrepare"パラメータを使用する
トランザクション結果に対しヴォートする。"S＿OK" 以
外のリターン値は、ASP 90のフェールファーストの原因
となるCRM コンペンセータ誤りと見做される。

【０１０８】CRM クラーク222 は、CRM コンペンセータ
へコミット又はアボート・ノーティフィケーションを伝
達するために、"BeginCommit()" 又は"BeginAbort()"方
法をそれぞれ呼び出す。この呼出しは、又ログ記録がCR
M コンペンセータ206 によるコミット又はアボート・ア
クションの処理のために正に伝達されようとしているこ
とをCRM コンペンセータに示す。"fRecovery" パラメー
タは、該方法が障害回復又は正常プロセシング中に呼び
出されているかを示すフラッグである。"S＿OK" 以外の
リターン値は、ASP 90のフェールファーストの原因とな
るCRM コンペンセータ誤りと見做される。

【０１０９】"CommitRecord()"及び "AbortRecord()"方
法は、コミット又はアボート・フェーズ・プロセシング
中の非構造化ログ記録を伝達するために、CRM クラーク
222により呼び出される。構造化ログ記録に対して、CRM
クラークは類似の"CommitRecordVarients()"又は"Abor
tRecordVarients()" 方法を呼び出す。"CommitRecor
d()"方法に対して、CRM クラーク222 はログ記録を正方
向順序で伝達する。"AbortRecord()" 方法に対して、CR
M クラーク222 はログ記録を逆方向順序で伝達する。も
し記録が書き込まれなければ、CRM クラークは、その"B
eginCommit()"(又は "BeginAbort()")と "EndCommit()"
（又は"EndAbort()"）方法の呼出し間での"CommitRecor
d()" (又は"AbortRecord()")方法の呼出しを省略する。
CRM コンペンセータは、CRM クラーク222 に伝達された
ログ記録を忘れさせるようにするためにリターンとして
フォーゲット・フラグ・パラメータ("fForget") をセッ
トできる。"S＿OK" 又は"ERROR＿REPLAY＿RECORDS"以外
のリターン値は、ASP 90のフェールファーストの原因と
なるCRM コンペンセータ誤りと見做される。

【０１１０】"EndCommit()" 及び"EndAbort()"方法は、
全てのログ記録はコミット又はアボート・フェーズ中に
伝達されたことをCRM コンペンセータに通知するため
に、CRM クラーク222 により呼び出される。CRM クラー
ク222 は、この方法の成功裏の終了によりトランザクシ
ョンに関する全てのログ記録を破棄しても良い。"S＿O
K" 以外のリターン値は、ASP 90のフェールファースト
の原因となるCRM コンペンセータ誤りと見做される。

【０１１１】＜ILogRecover インタフェース＞障害回復
エンジン242 はILogRecover インタフェースをサポート
する。該インタフェースは、正常プロセシング中("Take
CheckPoint()" の呼出しを介して) チェックポイントを
創り出し且つ障害回復プロセシング中("Recover()"方法
を介して) ログ・ファイルに基づく障害回復を開始させ
るために、CRM 障害回復クラーク224 により使用され
る。ILogRecover インタフェースは図10に示すプログラ
ム・リスト306 に定義される。

【０１１２】＜ILogRecoverClerkインタフェース＞CRM
障害回復クラーク224 及び各CRM クラーク222 は、ILog
RecoverClerkインタフェースを実装する。障害回復エン
ジン242 は、障害回復のフェーズを通じてCRM 障害回復
クラーク224 及び各CRM クラーク222 をドライブし、且
つ障害回復フェーズ中それらのクラークに関係するログ
記録を伝達するために、ILogRecoverClerkインタフェー
スを使用する。障害回復エンジン242 は、又CRM 障害回
復クラーク224 及びCRM クラーク222 にそれらのチェッ
クポイント・プロセシングを("WriteCheckpoint()"方法
を介して) 実行させるようにするためにILogRecoverCle
rkインタフェースを使用する。ILogRecoverClerkインタ
フェースは、図11に示すプログラム・リスト308 により
定義される。

【０１１３】＜ILogRecoverClerkPhaseNotification イ
ンタフェース＞ CRMクラーク222 はILogRecoverClerkPh
aseNotificationインタフェースを実装する。障害回復
エンジン242 は、自身をリスト内に掲載したトランザク
ションから２フェーズ・コッミト・ノーティフィケーシ
ョンを受け取ることにより、該障害回復エンジンは、ト
ランザクションを持つCRM クラーク222 にノーティフィ
ケーションを渡すためにILogRecoverClerkPhaseNotific
ation インタフェースを使用する。ILogRecoverClerkPh
aseNotification インタフェースは、図12に示すプログ
ラム・リスト310 により定義される。

【０１１４】＜ILogRecoverClerkRegistrationインタフ
ェース＞障害回復エンジン242 は、持続性のあるログ22
6 と共に登録するためにCRM 障害回復クラーク224 及び
CRMクラーク222 により呼び出されるILogRecoverClerkR
egistrationをサポートする。上記のように、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 又はPROJ
ID) をログすることが出来る。

【０１１８】本発明の原理が適用できるであろう多くの
可能な実施例の観点において、詳細な実施例は単に例示
に過ぎず、本発明のスコープを限定するように取られる
べきではないことが認識されるべきである。むしろ、本
発明として、そのような全ての実施例は請求項及びそれ
と同等のもののスコープ及び精神の内に属することを主
張する。

【図面の簡単な説明】

【図１】 図１は、オンライン・トランザクション処理
システムにおける補償するリソース・マネージメントの
ために、本発明を実施する方法及び機器を実装するのに
使用されるであろう分散コンピュータシステムのブロッ
ク図である。

【図２】 図２は、本発明の例示の実施例に準拠の補償
するリソース・マネージメントを伴うトランザクション
・プロセシングのためのサービスを持つサーバー・アプ
リケーション実行環境のブロック図である。

【図３】 図３は、本発明の例示の実施例に準拠の補償
するリソース・マネージメントを提供するために図２の
サーバー・アプリケーション実行環境において動作が可
能な補償するリソース・マネージャ(CRM) のコンポネン
ト・ベースのアーキテクチャのブロック図である。

【図４】 図４は、図３のCRM アーキテクチャ内での実
行命令の流れ図である。

【図５】 図５は、図３のアーキテクチャにおけるCRM
ワーカー・コンポネントにより実行されるロギング・プ
ロセスの流れ図である。

【図６】 図６は、図３の補償するリソース・マネージ
ャ・アーキテクチャにおけるCRM クラークに対する"ICr
mLogControl"インタフェースのプログラムリストであ
る。

【図７】 図７は、図３の補償するリソース・マネージ
ャ・アーキテクチャにおけるCRM コンペンセータの"ICr
mCompensator" インタフェースに対するデータ構造のプ
ログラムリストである。

【図８】 図８は、図３の補償するリソース・マネージ
ャ・アーキテクチャにおけるCRM コンペンセータの"ICr
mCompensatorVarients" インタフェースのプログラムリ
ストである。

【図９】 図９は、図３の補償するリソース・マネージ
ャ・アーキテクチャにおけるCRM コンペンセータの"ICr
mCompensator" インタフェースのプログラムリストであ
る。

【図１０】 図10は、図３の補償するリソース・マネー
ジャ・アーキテクチャにおける障害回復エンジンの"ILo
gRecover" インタフェースのプログラムリストである。

【図１１】 図11は、図３の補償するリソース・マネー
ジャ・アーキテクチャにおけるCRM 障害回復クラーク及
びCRM クラークの"ILogRecoverClerk"インタフェースの
プログラムリストである。

【図１２】 図12は、図３の補償するリソース・マネー
ジャ・アーキテクチャにおけるCRM 障害回復クラーク及
びCRM クラークの"ILogRecoverClerkPhaseNotificatio
n" インタフェースのプログラムリストである。

【図１３】 図13は、図３の補償するリソース・マネー
ジャ・アーキテクチャにおける障害回復エンジンの"ILo
gRecoverClerkRegistration"インタフェースのプログラ
ムリストである。

【図１４】 図14は、図３の補償するリソース・マネー
ジャ・アーキテクチャにおける持続性のあるログに対す
るログ・オブジェクトの"ILog"インタフェースのプログ
ラムリストである。

【図１５】 図15は、図３の補償するリソース・マネー
ジャ・アーキテクチャにおける"ICrmFormatLogRecords"
インタフェースのプログラムリストである。

【図１６】 図16は、図３の補償するリソース・マネー
ジャ・アーキテクチャにおけるCRM クラークの"ICrmMon
itorLogRecords" インタフェースのプログラムリストで
ある。

【図１７】 図17は、補償するリソース・マネージャ・
アーキテクチャにおけるクラーク・コレクション・オブ
ジェクトの"ICrmMonitorClerks" インタフェースのプロ
グラムリストである。

【図１８】 図18は、図３の補償するリソース・マネー
ジャ・アーキテクチャにおけるCRM 障害回復クラークの
"ICrmMonitor" インタフェースのプログラムリストであ
る。

Claims (16)

【特許請求の範囲】
1. 【請求項１】 オンライン・トランザクション処理シス
   テム内で、サーバー・アプリケーションのデータを耐久
   性を持って記憶するリソースであるところの、トランザ
   クションの中にあるリソースを管理する方法において、 該方法は次の諸ステップ、すなわち：サーバー・アプリ
   ケーションの要請により、トランザクションの一部とし
   て該データにワークを実行するステップと；要請時のリ
   ソース内のデータに対するワークの結果を持続するステ
   ップと；トランザクションのフェーズ変化を示すノーテ
   ィフィケーションを出すステップと；トランザクション
   がアボートされていることを示すノーティフィケーショ
   ンに応答して、リソース中のデータに対する耐久性のあ
   るワークを反転するための補償アクションを実行するス
   テップと；を有して成ることを特徴とするトランザクシ
   ョンの中にあるリソースを管理する方法。
2. 【請求項２】 コンピュータ内で、関与するコンポネン
   トに対し２フェーズ・コミット・プロトコルに従ってノ
   ーティフィケーションを送達するところのトランザクシ
   ョン・マネージャの制御の下に、耐久性のあるリソース
   がトランザクションの中で参画するよう管理するための
   コンポネント・ベースのフレームワークにおいて、 該フレームワークは：ログ・エントリーを耐久的に記録
   するためのログ記憶装置と；トランザクションのスコー
   プ内の耐久性のあるリソース中に保持されるデータを持
   続的に変更するワークを、クライアント・アプリケーシ
   ョンの要請に応じて実行する動作をするところの、補償
   するリソース・マネージャと；トランザクションがアボ
   ートされたことを示すトランザクション・マネージャか
   らのノーティフィケーションに応じて、ワークを完全に
   反転するためにログした情報に従って補償アクションを
   実行する動作をするところの、補償するリソース・マネ
   ージャと；を有して成ることを特徴とするコンポネント
   ・ベースのフレームワーク。
3. 【請求項３】 請求項２に記載のコンポネント・ベース
   のフレームワークにおいて、上記補償するリソース・マ
   ネージャは、ワーカー・コンポネント及びコンペンセー
   タ・コンポネントを含み、上記ワーカー・コンポネント
   は、ワークを実行しログ記憶装置内の情報をログする動
   作を行い、上記コンペンセータ・コンポネントは、ログ
   された情報に従って補償アクションを実行する動作を行
   い、また、上記ワーカー・コンポネントは、ログ記憶装
   置のみを経由して情報を上記コンペンセータ・コンポネ
   ントに受け渡すことを特徴とするコンポネント・ベース
   のフレームワーク。
4. 【請求項４】 持続性のあるリソースをトランザクショ
   ン処理システムに統合してトランザクション・マネージ
   ャの制御の下にトランザクション内で参画させるため
   に、コンポネント・ベースのリソース管理フレームワー
   クのコンピュータで実行可能なプログラム・コードを記
   憶させてあるところの、コンピュータで読み取り可能な
   記憶媒体であって、 上記統合は、アプリケーションが要請すれば耐久性のあ
   るリソースに対しワーク演算を実行するよう動作するワ
   ーカー・コンポネントの使用と、上記ワーク演算を反転
   させる補償演算を実行するよう動作するコンペンセータ
   ・コンポネントの使用と、を通してなされるものである
   ところのコンピュータで読み取り可能な記憶媒体におい
   て、 上記コンポネント・ベースのリソース管理フレームワー
   クは：上記コンペンセータ・コンポネントを登録するた
   めの上記ワーカー・コンポネントによる呼出しに対する
   コンペンセータ登録インタフェースを持っているコンペ
   ンセータ登録コンポネントと；上記ワーク演算の情報を
   持続的にログするための上記ワーカー・コンポネントに
   よる呼出しに対するロギング・インタフェースを持って
   いるロギング・コンポネントと；トランザクションがア
   ボートしようとしているというノーティフィケーション
   を上記トランザクション・マネージャから受け取るため
   のノーティフィケーション・インタフェースを持ち、ま
   た、上記コンペンセータ・コンポネントを創成するよう
   に動作することが可能であり、更にまた、上記ノーティ
   フィケーションに応答して上記ワーカー・コンポネント
   によりログされる情報に基づきコンペンセータ・コンポ
   ネントに補償演算を実行させてそれによりワーク演算を
   反転させるように動作することが可能であるところの補
   償を開始させるコンポネントと；を有して成ることを特
   徴とするコンピュータで読み取り可能な記憶媒体。
5. 【請求項５】 請求項４に記載のコンピュータで読み取
   り可能な記憶媒体において、上記コンペンセータ登録コ
   ンポネントは、コンペンセータ登録インタフェースへの
   ワーカー・コンポネントの呼出しから戻るに当たり、ロ
   ギング・インタフェースへのポインターを、ワーカー・
   コンポネントに受け渡すことを特徴とするコンピュータ
   で読み取り可能な記憶媒体。
6. 【請求項６】 請求項４に記載のコンピュータで読み取
   り可能な記憶媒体において、上記コンペンセータ登録コ
   ンポネントは更に、コンペンセータ登録インタフェース
   へのワーカー・コンポネントの呼出しに応答して、補償
   開始コンポネントがトランザクション・マネージャから
   ノーティフィケーションを受け取るようにワーカー・コ
   ンポネントがその中で参画するところのトランザクショ
   ン中の補償開始コンポネントをリストに掲載するように
   動作することを特徴とするコンピュータで読み取り可能
   な記憶媒体。
7. 【請求項７】 請求項４に記載のコンピュータで読み取
   り可能な記憶媒体において、補償開始コンポネントは更
   に、ノーティフィケーション・インタフェース上のトラ
   ンザクション・マネージャから準備ノーティフィケーシ
   ョンを受け取るように動作し、また、該準備ノーティフ
   ィケーションに応答してトランザクションの準備フェー
   ズ中に、該トランザクションをアボートするか否かのボ
   ート動作をコンペンセータ・コンポネントに実行させる
   ように動作することを特徴とするコンピュータで読み取
   り可能な記憶媒体。
8. 【請求項８】 請求項４に記載のコンピュータで読み取
   り可能な記憶媒体において、補償開始コンポネントは、
   更に、ノーティフィケーション・インタフェース上のト
   ランザクション・マネージャからコミット・ノーティフ
   ィケーションを受信するように動作し、且つ該コミット
   ・ノーティフィケーションに応答してワーク演算によっ
   て部分的に達成されたワークの完了のためにログされた
   情報に準拠してクリーンアップ演算及びどのような実演
   算もコンペンセータ・コンポネントに実行させるように
   動作することを特徴とするコンピュータで読み取り可能
   な記憶媒体。
9. 【請求項９】 トランザクション・マネージャを持つオ
   ンライン・トランザクション処理システム内で、該トラ
   ンザクション・マネージャの制御の下に、トランザクシ
   ョンの内部で耐久性のあるリソースを参画させるように
   管理するための補償するリソース・マネージャにおい
   て、該補償するリソース・マネージャは：トランザクシ
   ョンの一部として耐久性のあるリソース上へのワーク演
   算へのアプリケーションによる呼出しに対するワーク要
   請インタフェースを持つワーカー・コンポネントであっ
   て、要請されたワーク演算に関係する情報を持続的にロ
   グに書き込み且つ耐久性のあるリソースに対してワーク
   動作を成し遂げるためのワーク・アクションを実行する
   ために該アプリケーションによる呼出しに応答して動作
   するワーカー・コンポネントと；トランザクションをア
   ボートするためにトランザクション・マネージャによっ
   て発出されるノーティフィケーションを受け取るための
   ノーティフィケーション・インタフェースを持つコンペ
   ンセータ・コンポネントであって、ログから情報を読み
   出し且つ耐久性のあるリソースへのワーク・アクション
   の効果を反転するための補償アクションを実行するため
   に該ノーティフィケーションに応答して動作するコンペ
   ンセータ・コンポネントと；を有して成り、上記ワーカ
   ー・コンポネント及び上記コンペンセータ・コンポネン
   トは上記ワーカー・コンポネントによりログされた情報
   によってのみ状態を分かち合うことを特徴とする補償す
   るリソース・マネージャ。
10. 【請求項１０】 請求項９に記載の補償するリソース・
    マネージャにおいて、該補償するリソース・マネージャ
    は更に、コンペンセータ・コンポネントを登録するため
    のワーカー・コンポネントによる呼出しに対するコンペ
    ンセータ登録インタフェースを持つ補償マネージャであ
    って、該コンペンセータ・コンポネントを創成し且つト
    ランザクション・マネージャにより発出されるノーティ
    フィケーションを受け取るためにトランザクション中の
    リストに掲載するようワーカー・コンポネントによる呼
    出しに応答して動作する補償マネージャを有して成るこ
    とを特徴とする補償するリソース・マネージャ。
11. 【請求項１１】 請求項10に記載の補償するリソース・
    マネージャにおいて、補償マネージャは、更にワーカー
    ・コンポネントが情報をログに書き込むためのアクセス
    を供給するために該ワーカー・コンポネントの呼出しに
    応答して動作することを特徴とする補償するリソース・
    マネージャ。
12. 【請求項１２】 トランザクション中の障害後のそれ以
    上の障害回復に対する請求項９に記載の補償するリソー
    ス・マネージャにおいて、該補償するリソース・マネー
    ジャは、障害後に障害回復が開始される時にトランザク
    ションの結果をトランザクション・マネージャから決定
    し、補償するコンポネントを創成し、且つ若し該結果が
    該トランザクションをアボートさせるべきであった場合
    はログからの情報を基に補償アクションを補償するコン
    ポネントに実行させるように動作する障害回復マネージ
    ャを有して成ることを特徴とする補償するリソース・マ
    ネージャ。
13. 【請求項１３】 請求項12に記載の補償するリソース・
    マネージャにおいて、上記障害回復マネージャは、更に
    障害回復中の補償アクションを実行する補償するコンポ
    ネントの障害に当たって、該補償アクションを引き続い
    ての障害回復に延長するためにログ内の情報を保存する
    ように動作することを特徴とする補償するリソース・マ
    ネージャ。
14. 【請求項１４】 請求項９に記載の補償するリソース・
    マネージャにおいて、補償するコンポネントは、障害回
    復中の補償アクションの実行の障害に当たって、操作す
    る人間が持続性のあるリソースに対する正常アクション
    を反転させる手動アクションを実施するために操作する
    人間に供給されるべき注意及び情報をもたらすように動
    作することを特徴とする補償するリソース・マネージ
    ャ。
15. 【請求項１５】 請求項９に記載の補償するリソース・
    マネージャにおいて、補償するコンポネントの補償アク
    ションはべき等(idempotent)であることを特徴とする補
    償するリソース・マネージャ。
16. 【請求項１６】 請求項９に記載の補償するリソース・
    マネージャにおいて、補償するコンポネントの補償アク
    ションは反転できないことを特徴とする補償するリソー
    ス・マネージャ。