JP2005538460A - データ処理システム及び方法（非同種プロセスを統合するように適合されたデータ処理システム） - Google Patents

Abstract

【課題】コミット／バックアウト・プロトコルに従ってそれぞれのシステム・リソースに対する変更を管理する少なくとも１つのリソース管理手段（ＲＭ）と、少なくとも１つのリソース・マネージャのコミット／バックアウト・アクティビティを調整する調整手段（ＲＭＣ）を含むデータ処理システムを提供すること。
【解決手段】コミット／バックアウト・プロトコルに従って調整手段によって調整される、コミット／バックアウト・プロトコルに従わない非準拠プロセスの実行を管理するプロセス・リソース管理手段が設けられる。プロセス・リソース管理手段は、バックアウト要求を受け取ったことに応答して、副非準拠プロセスの実行中に実行されたアクションをバック・アウトするために実行すべき補償アクションのシーケンスを自動的に決定し、前記補償アクションの実行を管理する。

Description

本発明は、全般的にはデータ処理システムに関し、具体的には、トランザクション処理システムなど、システムで動作するプロセスをコミット／バックアウト・プロトコルに従って調整する必要があるデータ処理システムに関する。具体的に言うと、本発明は、非同種プロセスすなわち、コミット／バックアウト・プロトコルに準拠するプロセスとそのようなプロトコルに準拠しないプロセスとを統合するように適合されたデータ処理システムに関する。

既存のデータ処理環境での新しいアプリケーション（プログラム、トランザクション、クラス、オブジェクト、またはメソッド）の導入は、複数の問題を提出する。すばやい技術の進歩に起因して、新しいアプリケーションは、通常、既存のアプリケーションと比較して異なるアーキテクチャに基づき、新しいアプリケーションが既存のアプリケーションとて相互作用できるようにすることが、実際に難題になる可能性がある。

たとえばｅ−ｂｕｓｉｎｅｓｓ機能を実装するために、一種の新しいインターネットベース・サービスが導入されるので、この問題は、現在、特に感じられている。これらの新しいサービスは、レガシ・アプリケーションなど、会社のデータ処理システム内の既存のビジネス機能と相互作用する必要がある。

既に存在するコンポーネントが新しいサービスを実装するために協力する必要がある時に、類似する問題に出会う可能性がある。

既存の異種アプリケーションのフレームワーク内で新しいアプリケーションを統合するために、または新しい機能を達成するために既存の異種アプリケーションを相互作用させるために、技術的なおよび応用の両方の複数のクリティカルな要因を考慮する必要がある。情報技術の分野の複数の異なるスキルがかかわり、その結果、コストおよび時間が増える。

４つの可能な方法論を識別することができる。

第１の手法では、既存プロセスを最大限に活用することを試み、新しいプロセスが既存プロセスと相互作用できるようにするために、ビジネス・プロセスからの要求を解釈でき、これをサービスおよび関連するコヒーレンス・コントロールに正しく変換できるインターフェース層が作成される。既に存在するアプリケーションを開発するために行われた投資が、この形で保存される。

第２の手法によれば、冗長な機能が開発される。新しいビジネス・プロセスを実行するのに必要な機能は、既存環境に既に存在しても、新しい環境で複製される。その結果は、機能およびデータの重複であり、開発および管理の時間およびコストが増加する。さらに、重複したデータの調停という問題が生じる場合がある。

第３の手法に従うと、既に存在する機能が、実施される新しいビジネス・プロセスの要件に適合するように変更される。これには、既存の機能および環境の非常に正確な知識と、簡単には入手できない可能性があるプロフェッショナル・スキルの可用性がかかわってくる。その結果、コストが非常に高くなる可能性がある。

最後に、第４の手法では、新しいビジネス・プロセスおよび既に生産中のビジネス・プロセスの両方を含む新しいアプリケーションの開発が提供される。コストは別にして、新しいプロセスを生産に移すためにどちらかといえば長い時間が必要であり、会社のコア・ビジネスに対する悪影響がある。

前述で概要を示された技術的現状に鑑みて、本発明の目的は、異種アプリケーションをサポートできるデータ処理システムを提供することである。

本発明によれば、上記および他の目的は、請求項１に記載のデータ処理システムによって達成された。

短く言えば、データ処理システムに、コミット／バックアウト・プロトコルに従ってそれぞれのシステム・リソースに対する変更を管理する少なくとも１つのリソース管理手段と、少なくとも１つのリソース管理手段のコミット／バックアウト・アクティビティを調整する調整手段が含まれる。

プロセス・リソース管理手段が、コミット／バックアウト・プロトコルに従って調整手段によって調整されて、コミット／バックアウト・プロトコルに準拠しない非準拠プロセスの実行を管理するために設けられる。バックアウト要求の受取に応答して、プロセス・リソース管理手段は、非準拠プロセスの実行中に実行されたアクションをバックアウトするために実行すべき補償アクションのシーケンスを決定する。

本発明の特徴および長所は、非制限的な例としてのみ提供される、添付図面を参照して説明される、本発明の実施形態の下の詳細な説明によって明白になる。

図面を参照すると、図１に、本発明の実施形態によるトランザクション管理システムの主要な構成要素が、機能ブロックに関して概略的に示されている。

トランザクション処理システムに、下で短くトランザクション・マネージャと称するトランザクション・マネージャ・システムＴＭをホスティングする、データ処理システムＳＹＳが含まれる。

トランザクション・マネージャＴＭは、図示の例ではアプリケーションＡＰＰなどの、トランザクション・マネージャＴＭをホスティングするデータ処理システムＳＹＳにローカルに、または、たとえばインターネットを介して企業のデータ処理システムに接続されたクライアント・コンピュータ上などのリモート・データ処理システム内のいずれかで動作するアプリケーションによって発行されるビジネス・サービス要求ＢＲ（以下ではビジネス要求と称する）を管理する。たとえば、データ処理システムＳＹＳは、銀行ＡＴＭによって要求されたビジネス・サービスを受け取る銀行代理店のフロントエンド・サーバである。

データ処理システムＳＹＳは、以下では対応システムと称する、図に示された２つのデータ処理システムＣ＿ＳＹＳ１およびＣ＿ＳＹＳ２などの１つまたは複数の別個のデータ処理システムに接続される。データ処理システムＳＹＳは、ビジネス要求をサービスするために対応システムＣ＿ＳＹＳ１およびＣ＿ＳＹＳ２と相互作用することができる。システムＳＹＳならびに対応システムＣ＿ＳＹＳ１およびＣ＿ＳＹＳ２は、ＬＡＮ、シスプレックス、クラスタ、ＷＡＮ、およびインターネットを介して接続することができる。システムＳＹＳならびに対応システムＣ＿ＳＹＳ１およびＣ＿ＳＹＳ２は、シスプレックスまたはクラスタなどのデータ処理システムのローカル・セットを形成することができ、システムのローカル・セットは、１つまたは複数の地理的に離れたデータ処理システムまたはシステムの組に接続することができる。前に示した例に戻ると、システムＳＹＳ（フロントエンド銀行代理店サーバ）は、銀行代理店の主サーバに接続され、この主サーバは、異なる銀行代理店の他の主サーバのネットワークに接続される。

データ処理システムＳＹＳは、複数のリソース管理手段（以下、リソース・マネージャ）ＲＭのアクティビティを制御し、調整手段（以下、リソース・マネージャ・コーディネータ）ＲＭＣをホスティングする。各リソース・マネージャは、データベース、アーカイブ、データ・テーブル、ファイル、データ・レコード、および類似物などのそれぞれのシステム・リソース（図には示さず）を管理する責任を負う。各リソース・マネージャＲＭは、トランザクション・マネージャＴＭの制御の下で動作する一般タスクによって要求される、それぞれのリソースに対する変更を管理する。

原始性と称する、トランザクション処理システムの特徴は、システム・リソースに対するアクセスおよび更新が、通常は、作業単位（以下ではＵＯＷ）とも称する、別個のトランザクションの実行によって実行されることである。ＵＯＷは、変更のすべてが行われるか全く行われないかのいずれかになる、システム・リソースに対する一連の調整された動作である。これらの動作は、通常は、トランザクション処理システム内のストレージに保持されたデータに対して行われる変更である。この形で、システム・リソースが、互いに一貫しない状態にされなくなる。更新動作のセットの１つが失敗した場合、他の動作も有効になってはならない。その場合に、ＵＯＷは、すべての中間ステップでの一貫性を必ずしも保持せずに、システム・リソースの一貫性のある状態を別の一貫性のある状態に変換する。

トランザクションの原子的性質は、一般にコミット手順と称するトランザクション同期化手順によって維持される。リソース変更がトランザクション実行内で同期化される、一貫性の論理的な点を、コミット点と称する。ＵＯＷは、コミット点に達した時またはタスクが終了した時にコミットを宣言するタスクによってクローズされる。

トランザクションの原始性は、トランザクションの完了時にコミットが宣言されるまで未解決である（コミットされていない）、トランザクション内で行われたリソース更新によって達成される。トランザクションが成功する場合に、トランザクションの結果が、永久的にされる（コミットされる）。トランザクションが失敗する場合には、不成功のトランザクションのすべての影響が拒否される（バック・アウトまたはロール・バックされる）。すなわち、リソース更新は、成功裡の完了の時に限って、リソース更新が実行されたタスク以外のタスクに可視かつ永久的にされ、各作業単位の持続中は、すべての更新されたリソースが、さらなる更新アクセスを防ぐためにロックされなければならない。逆に、トランザクションがバック・アウトするときには、リソースは、そのトランザクションが開始される前に存在した一貫した状態に復元される。

一般リソース・マネージャＲＭによって管理されるシステム・リソースに対してタスクによって要求された変更は、そのリソース・マネージャによって、タスクの結果に応じて、単一相コミット・プロトコルまたは２相コミット・プロトコルの下で、リソース・マネージャ・コーディネータＲＭＣによるコミット要求の受取時の延期されたコミットを可能にする形で管理される。システム・リソースに対する変更の統合または拒否は、コミット・コマンドまたはバックアウト・コマンドによって明示的に、あるいはタスクの成功裡または不成功の終了によって暗黙のうちに、トリガすることができる。リソース・マネージャ・コーディネータＲＭＣは、明示的なコミット・コマンドまたはバックアウト・コマンド、あるいはタスクの成功裡または不成功の終了の表示を受け取り、その変更にかかわるシステム・リソースを管理する責任を負うリソース・マネージャＲＭにコミット要求またはバックアウト要求を伝搬させる。

トランザクション・マネージャＴＭに、ビジネス要求マネージャ・サブシステムＢＲＭ、拡張リソース・マネージャ・サブシステムＥＲＭ、ならびにビジネス要求マネージャ・サブシステムＢＲＭおよび拡張リソース・マネージャ・サブシステムＥＲＭの両方にサービスを提供するサービス・プロバイダ・サブシステムＳＥＲが含まれる。

ビジネス要求マネージャＢＲＭは、ビジネス要求ＢＲが受け取られると、必ず、トランザクション・マネージャＴＭによってアクティブ化される。トランザクション・マネージャＴＭは、入ってくるビジネス要求を検出し、ビジネス要求マネージャＢＲＭをアクティブ化する。入ってくるビジネス要求ＢＲは、一般トランザクションまたはアプリケーション宛のサービス要求としてビジネス要求マネージャＢＲＭによって管理され、サービス要求は、タスクＴ１によって、１つまたは複数のＵＯＷを用いて処理される。

下で詳細に説明するように、タスクＴ１の起動時にトランザクション・マネージャＴＭによってアクティブ化され、ビジネス要求ＢＲの処理のために開始されるビジネス要求マネージャＢＲＭは、タスク実行を制御するためにサービス・プロバイダ・サブシステムＳＥＲによって提供されるサービスを活用する。

具体的に言うと、ビジネス要求マネージャＢＲＭは、ビジネス要求分類方式を実施し、入ってくるビジネス要求ＢＲが属するビジネス要求クラスに応じて、サービス・プロバイダＳＥＲによって提供される異なるサービスを活用する。

一般に、ビジネス処理フローに応じて、入ってくるビジネス要求ＢＲの処理のために起動されるタスクＴ１の実行中に、図１に示されたサービス要求ＯＢＲ１およびＯＢＲ２など（以下ではアウトバウンド・ビジネス要求または短くＯＢＲと称する）、トランザクション・マネージャＴＭをホスティングするのと同一のシステムＳＹＳ内あるいは１つまたは複数の対応システムＣ＿ＳＹＳ１およびＣ＿ＳＹＳ２内のいずれかで動作する異なるプログラムまたはトランザクション宛の１つまたは複数のサービス要求を、生成することができる。これらのサービス要求は、入ってくるビジネス要求ＢＲと同様に扱われるが、ＯＢＲが向けられるそれぞれの対応システムＣ＿ＳＹＳ１およびＣ＿ＳＹＳ２内で、拡張リソース・マネージャＥＲＭによって管理されるタスクＴ２１およびＴ２２を起動させる。

この説明の文脈で、ＯＢＲが、システムＳＹＳの対応システムに関して発行されるビジネス要求だけではなく、システムＳＹＳの、たとえばアプリケーションであるが、弱いリンクを特徴とするコンポーネントすなわち、コミット／バックアウト・プロトコルの対象にすることができないコンポーネントに関して発行されるビジネス要求でもあることが観察される。

コミット・プロトコルに準拠しないインターフェースするプロセス、すなわち、そのＵＯＷがリソース・マネージャ・コーディネータによってバックアウト相中に同種に調整されないプロセスは、動的に判定されるコヒーレントな状態に向かってシステムを収束させることに向けられた補償アクティビティ（暗黙のまたは明示的な）を管理することを必要にする。これは、誤動作または明示的なバックアウト要求によってトリガされ、補償コンポーネント（後で詳細に説明するＸＢＲまたはＸＯＢＲあるいはその両方）の明示的アクティブ化によって、またはサービス・プロバイダ・サブシステムＳＥＲによって提供されるログ・サービスによって以前に記録されたものを取り出すことによって、拡張リソース・マネージャＥＲＭによって管理される。補償アクティビティに必要な情報は、前の詳述（ｅｌａｂｏｒａｔｉｏｎ）相（おそらくは前の補償の試みを含む）中にログ・サービスによって記録された情報に基づいて動的に判定される。

具体的に言うと、拡張リソース・マネージャＥＲＭは、トランザクション・マネージャＴＭによって、リソース・マネージャＲＭの１つとして見られる。トランザクション・マネージャＴＭは、ＯＢＲ、たとえばＯＢＲ ＯＢＲ１、ＯＢＲ２が発行されるたびに、拡張リソース・マネージャＥＲＭをアクティブ化する。後で説明するように、ＯＢＲは、拡張リソース・マネージャＥＲＭを明示的に呼び出すことができ、あるいは、後者を暗黙のうちに呼び出すことができる。短く言うと、拡張リソース・マネージャＥＲＭは、ＯＢＲの実行を監督し、ＯＢＲの処理に含まれるＵＯＷの実行中におそらくは生じる未確定状況の場合など、異常の場合であってもＯＢＲが正しく実行されることを保証する。リソース・マネージャ・コーディネータＲＭＣの観点からは、拡張リソース・マネージャＥＲＭは、ＯＢＲおよびＯＢＲにサービスする対応システムで動作するプロセスを、それぞれのシステム・リソースを管理するリソース・マネージャＲＭに似た形で管理し、対応システムで動作するプロセスの単一相または２相のコミット／バックアウト・プロトコルの実施を可能にする。

具体的に言うと、拡張リソース・マネージャＥＲＭは、識別子を管理し、主プロセス（Ｔ１）によって呼び出されビジネス要求マネージャＢＲＭによってアクティブ化される副プロセス（この例では、タスクＴ２１およびＴ２２）をアクティブ化し、監視する。リソース・マネージャＲＭによって管理されるシステム・リソースに対して行われる変更を、バック・アウトすることができ、このシステム・リソースを、そのような変更が適用される前の状態に戻すことができるが、これは、一般に、副プロセスによって引き起こされる変更については可能でない。システムＳＹＳと対応システムの間の通信プロトコルの問題、後者および類似物の挙動（この文脈では、全体的に、不安定なリンクの問題と称する）は、対応システムを副プロセスが起動される前の状態に戻すことを不可能にする場合がある。一般に、真のバックアウトではなく、拡張リソース・マネージャＥＲＭは、副プロセスによって行われる変更の補償アクティビティを管理する。

一般タスクのライフ・サイクル中に、複数のＵＯＷを、順次インスタンス化し、コミットまたはバック・アウトすることができる。各ＵＯＷは、ＵＯＷの管理に使用される一義識別コード（ｕｎｉｖｏｃａｌ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｃｏｄｅ、ＵＯＷＩＤ）によって識別される。ＵＯＷのコミットまたはバックアウトは、実行中のＵＯＷの自動的終了を引き起こし、ビジネス・ロジックによって要求される場合の新しいＵＯＷのインスタンス化を可能にする。

タスクＴ１の実行中に、異なるリソース・マネージャＲＭによって管理されるシステム・リソースに対する変更が要求される場合がある。この場合に、複数の相関するＵＯＷが、同時にインスタンス化され、これらの相関するＵＯＷのすべてが、リソース・マネージャ・コーディネータＲＭＣによって管理される主ＵＯＷ（以下ではコーディネーションＵＯＷ（ＣＯＯ−ＵＯＷ）と称する）に従属する。この状況を、概略的に図２に示すが、図２では、ＵＯＷ ＵＯＷ１、ＵＯＷ２、およびＵＯＷ３が、相関され、コーディネーションＵＯＷ ＣＯＯ−ＵＯＷとしてリソース・マネージャ・コーディネータＲＭＣによって管理される。

同様に、タスクＴ１（主タスク）の実行中に、相関されたタスクＴ２１およびＴ２２（副タスク）を、異なる対応システムＣ＿ＳＹＳ１およびＣ＿ＳＹＳ２で起動することができ、したがって、潜在的に互いに相関する複数のＵＯＷが、論理的に主タスクＴ１に関連し、この事例では、これらのＵＯＷのすべてが、リソース・マネージャ・コーディネータＲＭＣによって管理されるＣＯＯ−ＵＯＷに従属する。この状況を、概略的に図３に示す。

この第２の事例では、システムＳＹＳと対応システムの間のリンクが強い（すなわち、不安定ではなく、コミット／バックアウト・プロトコルの実装を可能にする）場合に、図３に示された対応システムＣ＿ＳＹＳ１内のリソース・マネージャＣ−ＲＭＣ１などの対応システム内のリソース・マネージャを、システムＳＹＳのリソース・マネージャ・コーディネータＲＭＣによって調整することができ、あるいは、ローカル・リソース・マネージャ・コーディネータによって調整し、このローカル・リソース・マネージャ・コーディネータをシステムＳＹＳのリソース・マネージャ・コーディネータＲＭＣによって調整することができる。どの場合でも、インスタンス化されたＵＯＷのすべてが、一意のＣＯＯ−ＵＯＷに従属する。

その代わりに、システムＳＹＳと対応システムの間のリンクが不安定である場合に、複数のＣＯＯ−ＵＯＷがセット・アップされ、そのそれぞれが、互いに調整されないそれぞれのリソース・マネージャ・コーディネータによって管理される。そのようなＣＯＯ−ＵＯＷ、たとえば図３のＣＯＯ−ＵＯＷ ＣＯＯ−ＵＯＷ１およびＣＯＯ−ＵＯＷ２は、下でＥＸＴ−ＵＯＷと称する拡張ＵＯＷ ＥＸＴ−ＵＯＷとして拡張リソース・マネージャＥＲＭによって処理される。

通常、ＵＯＷとしてグループ化される各タスクによって要求されるデータに対する変更は、リソース・マネージャ・コーディネータＲＭＣによって調整されるリソース・マネージャＲＭによって管理されて、より多くのタスクが同時に共用されるアーカイブに作用できるようになる。一般タスクによって要求された変更は、関連するＵＯＷのコミットの後に限って、公にされ、他のタスクから使用可能にされ、ＵＯＷがバック・アウトされる場合には、変更は統合されず、アーカイブのデータは、未変更の形で他のタスクに公にされる。この形で、異なるタスクが、他のタスクによる部分的な変更を受けない、コヒーレントなデータにアクセスすることが保証される。プログラムまたはトランザクションによって活用されるデータの論理的にコヒーレントなグループを管理するトランザクション処理システムの能力を、参照保全性（ｒｅｆｅｒｅｎｔｉａｌ ｉｎｔｅｇｒｉｔｙ）と称する。

しかし、ＣＯＯ−ＵＯＷによって調整されるＵＯＷに、コミット／バックアウト・プロトコルに従うＵＯＷ（準拠ＵＯＷ）および、使用されるプロセスまたはリソースの性質に起因してコミット／バックアウト・プロトコルをサポートしないＵＯＷ（いわゆる非準拠ＵＯＷ）の両方を含めることができる。この場合に、ＣＯＯ−ＵＯＷを、拡張ＵＯＷ（ＥＸＴ−ＵＯＷ）と称する。

準拠ＵＯＷによって構成されるＣＯＯ−ＵＯＷの場合と異なって、ＥＸＴ−ＵＯＷの場合に、非準拠ＵＯＷの存在によって、少なくとも変更のうちで非準拠ＵＯＷ内で発生する部分に関して、通常のデータ保全性方式を保証できなくなる。準拠ＵＯＷの実行中に行われるシステム・リソースに対する変更の統合は、延期され、主タスクの結果に従属する。非準拠ＵＯＷの実行中に行われるシステム・リソースに対する残りの変更は、その実行にコンテキスト的にまたは関連する副タスクの終りにのいずれかで、統合することができる。ＥＸＴ−ＵＯＷに関連する主タスクの成功裡の完了は、問題を提出しない。というのは、すべての変更が確認されるからである。すなわち、準拠ＵＯＷ内で行われる変更は、確認され、非準拠ＵＯＷ内で行われる変更は、既に統合されており、バック・アウトされる必要がない。言い換えると、可能なバックアウト要求（適用可能またはインフラストラクチャ的のいずれか）は、用いられるリソースのミスアライメントを作り、まだコミットされていない変更は、バック・アウトでき、バック・アウトされるが、コミット・プロトコルの対象でないので既に統合されている変更は、バック・アウトできず、バック・アウトされない。この場合に、システム全体（システムＳＹＳならびに対応システムＣ＿ＳＹＳ１およびＣ＿ＳＹＳ２）の状態を、変更が行われる前の状態に戻すことはできない。システムを最初の状態に戻すことができないので、動的に判定されるコヒーレントな状態に向かってシステム全体を収束させることを対象とする特定の補償アクティビティを実行する必要がある。

これには、システムの２レベルの露出が用いられる。第１レベルの露出は、準拠ＵＯＷ内で行われた変更のコミットの場合に、変更されたデータが異なるタスクに公にされる異なるタイミングに起因して生成される。第２レベルの露出は、タスクによって行われた変更のバックアウトの結果で生成され、システムがバックアウト要求をサービスする際の差に起因する。すなわち、準拠ＵＯＷ内で行われる変更は、即座にバック・アウトされるが、非準拠ＵＯＷ内で行われる変更は、補償され、この補償は、延期される可能性がある。一時的なミスアライメントは、異なる時に決定的でない形で公にされる、論理的に相関するデータについて発生する可能性がある。

図４を参照すると、本発明の実施形態で、サービス・プロバイダ・サブシステムＳＥＲによって実施されるサービスが概略的に示されている。サービス・プロバイダ・サブシステムＳＥＲによって提供されるサービスの一部は、ビジネス要求マネージャＢＲＭによって活用され、他のサービスは、拡張リソース・マネージャＥＲＭによって活用され、一部のサービスは、ビジネス要求マネージャＢＲＭおよび拡張リソース・マネージャＥＲＭの両方によって活用される。具体的に言うと、サービスのサブセットは、分類されたビジネス要求に関連するタスクであれ、分類されないビジネス要求に関連するタスクであれ、ビジネス要求マネージャＢＲＭによって起動されるすべてのタスクに共通して提供される。サービス・プロバイダ・サブシステムＳＥＲによって提供されるサービスのリストに、ビジネス要求カタログ作成サービスＣＡＴＳ、ディレクトリ・サービスＤＩＲＳ、タスク回復サービスＴＳＲ、システム回復サービスＳＹＳＲ、接続性サービスＣＮＣＴ、ログ・サービスＬＯＧ、監視サービスＭＯＮ、ＵＯＷ保護サービスＵＯＷ−Ｐ、エラー回復サービスＥＲＲ、ビジネス要求保護サービスＢＲＰＲ、およびビジネス要求検証サービスＢＲＶＲが含まれる。

分類されたビジネス要求および分類されないビジネス要求の両方に共通して提供されるサービスに、ログ・サービスＬＯＧ、監視サービスＭＯＮ、ＵＯＷ保護サービスＵＯＷ−Ｐ、およびエラー回復サービスＥＲＲが含まれる。

分類されたビジネス要求に固有のサービスに、共通のサービスに加えて、カタログ作成サービスＣＡＴＳ、ビジネス要求保護サービスＢＲＰＲ、およびビジネス要求検証サービスＢＲＶＲが含まれる。

ビジネス要求マネージャＢＲＭによって活用されるサービスに、ビジネス要求保護サービスＢＲＰＲ、エラー回復サービスＥＲＲ、ＵＯＷ保護サービスＵＯＷ−Ｐ、ビジネス要求検証サービスＢＲＶＲ、監視サービスＭＯＮ、ログ・サービスＬＯＧ、およびカタログ作成サービスＣＡＴＳが含まれる。

拡張リソース・マネージャＥＲＭによって活用されるサービスに、カタログ作成サービスＣＡＴＳ、ログ・サービスＬＯＧ、ＵＯＷ保護サービスＵＯＷ−Ｐ、監視サービスＭＯＮ、エラー回復サービスＥＲＲ、接続性サービスＣＮＣＴ、ディレクトリ・サービスＤＩＲＳ、タスク回復サービスＴＳＲ、およびシステム回復サービスＳＹＳＲが含まれる。

ビジネス要求マネージャＢＲＭによって実施されるビジネス要求分類方式は、カタログ作成サービスＣＡＴＳによって保持されるビジネス要求カタログにリストされた分類されたビジネス要求ＣＢＲまたはカタログに存在しない分類されないビジネス要求ＮＣＢＲとして入ってくるビジネス要求を分類するために、ビジネス要求カタログ作成サービスＣＡＴＳに頼る。

サービス・プロバイダ・サブシステムＳＥＲによって実施されるサービスを、後で詳細に説明する。

動作中に、ビジネス要求マネージャＢＲＭおよび拡張リソース・マネージャＥＲＭは、サービス要求が向けられるコンポーネント（アプリケーション・プログラム、トランザクション、インフラストラクチャ・サービス、たとえばコネクタ）の性質およびそれに関連するプロセスの論理的状態（実行中、バック・アウト中、保留中、未確定など）を考慮に入れて、トランザクション処理システムへの入ってくるビジネス要求であれ、前に受け取られたビジネス要求の処理中に生成されるサービス要求であれ、サービス要求を分類する。

ビジネス要求マネージャＢＲＭおよび拡張リソース・マネージャＥＲＭの挙動は、サービス要求を発行したエンティティの状況、発行されたサービス要求の種類、およびサービス要求が向けられたコンポーネントの状況に依存する。

システムＳＹＳの外部から来るものと既に受け取られたビジネス要求のサービス中に生成されるものの両方のサービス要求のそれぞれが、ビジネス要求マネージャＢＲＭによって分析される。サービス要求に、そのサービス要求がビジネス要求マネージャＢＲＭまたは拡張リソース・マネージャＥＲＭのどちらに向けられるかの明示的表示が含まれる場合があり（明示的サービス要求）、この場合に、ビジネス要求マネージャＢＲＭは、そのサービス要求の直接処理または拡張リソース・マネージャＥＲＭの呼び出しのいずれかを行う。サービス要求にそのような明示的表示が含まれない場合（暗黙のサービス要求）、サービス要求は、監視サービスＭＯＮによってインターセプトされ、ビジネス要求マネージャＢＲＭに渡される。カタログ作成サービスＣＡＴＳを活用して、ビジネス要求マネージャＢＲＭは、サービス要求の種類を判定する。サービス要求が分類されたサービス要求である場合に、そのサービス要求は、ビジネス要求マネージャＢＲＭによってまたは拡張リソース・マネージャＥＲＭによって処理される。逆に、サービス要求が分類されないサービス要求である場合には、そのサービス要求は、トランザクション・マネージャＴＭにルーティングされ、トランザクション・マネージャＴＭによって処理される。

本発明の１実施形態で、可能なサービス要求の次の分類方式が採用される。

「分類されないビジネス要求」（以下ではＮＣＢＲと称する）は、トランザクション・マネージャＴＭによって管理されるトランザクションまたはプログラムに関して発行され、ビジネス要求マネージャＢＲＭがカタログ作成サービスＣＡＴＳによって保持されるビジネス要求カタログにリストされたサービス要求のどれにも関連付けることができない包括的なサービス要求であり、ビジネス要求マネージャＢＲＭによってＮＣＢＲに供給されるサービスは、共通サービスのサブセットに属するサービスだけである。ＮＣＢＲは、明示的および暗黙の、分類されたおよび分類されないのいずれであれ、すべての種類のビジネス要求を発行することができると同時に、回復可能または回復不能のいずれであれ、システム・リソースにアクセスすることができる。

「分類されたビジネス要求」（以下ではＣＢＲと称する）は、ビジネス要求マネージャＢＲＭが、カタログ作成サービスＣＡＴＳによって保持されるカタログにリストされたサービス要求の１つに関連付けることができるサービス要求である。

ＣＢＲのクラス内で、ビジネス要求の次のカテゴリが、追加して定義される。

「保護されない分類されたビジネス要求」（以下ではＮＰＣＢＲと称する）は、ビジネス要求マネージャＢＲＭが、共通サービスのすべてとカタログ作成サービスＣＡＴＳおよび検証サービスＶＥＲを提供するＣＢＲである。ＮＰＣＢＲの処理が、エラーまたは異常に起因して完了しない場合に、ビジネス要求マネージャＢＲＭは、ビジネス要求の自動再アクティブ化を対象とするアクションを一切行わず、この重荷をサービスのオリジナルの要求元に委ねる。ＮＰＣＢＲは、明示的および暗黙、分類されたおよび分類されないのいずれであれ、すべての種類のビジネス要求を発行することができ、回復可能または回復不能のいずれであれ、システム・リソースにアクセスすることができる。

「保護された分類されたビジネス要求」（以下ではＰＣＢＲと称する）は、保護サービスＢＲＰＲを含む、ビジネス要求マネージャＢＲＭによって実装されるすべてのサービスの利益を得るＣＢＲである。ＮＰＣＢＲと異なって、ＰＣＢＲの処理が、エラーまたは異常に起因して完了しない場合に、ビジネス要求マネージャＢＲＭは、ビジネス要求保護サービスを活用することによって、ビジネス要求の再アクティブ化を自動的に管理して、その処理と、おそらくは延期された完了を保証する。ＰＣＢＲは、明示的または暗黙、分類されたまたは分類されないのいずれであれ、すべての種類のビジネス要求を発行することができ、回復可能または回復不能のいずれであれ、システム・リソースにアクセスすることができる。ＰＣＢＲ（主ＰＣＢＲ）が別のＰＣＢＲ（副ＰＣＢＲ）を発行する場合に、保護サービスは、副ＰＣＢＲの多重アクティブ化を防ぐために、副ＰＣＢＲではなく主ＰＣＢＲだけに提供される。ＮＰＣＢＲまたはＮＣＢＲによって発行された副ＰＣＢＲが、保護サービスを提供されず、自動的に再アクティブ化されない、言い換えると、主ＰＣＢＲだけが再アクティブ化されることが観察される。

「補償ビジネス要求」（以下ではＸＢＲと称する）は、バックアウトのアクティビティ、より一般的には補償を実行するためにアクティブ化される、特定の種類のＰＣＢＲである。ＸＢＲは、トランザクション・マネージャＴＭをホスティングするシステムＳＹＳ内で動作するプログラムまたはトランザクションを対象とする。具体的に言うと、ＸＢＲは、拡張リソース・マネージャＥＲＭがエラーまたはバックアウト要求についてリソース・マネージャ・コーディネータＲＭＣによって通知されると、拡張リソース・マネージャＥＲＭによって自動的にアクティブ化される。ＸＢＲは、ビジネス要求マネージャＢＲＭおよび拡張リソース・マネージャＥＲＭの制御の下で働くが、補償アウトバウンドビジネス要求（後で説明するＸＯＢＲ）、ＮＣＢＲ、およびＣＢＲを発行し、回復可能または回復不能のいずれであれ、システム・リソースにアクセスすることができる。特定の種類のＰＣＢＲであるＸＢＲは、保護サービスの利益を得、自動的に再アクティブ化される。

ＯＢＲに関して、次のカテゴリが定義される。

「回復不能アウトバウンド・ビジネス要求」（以下ではＮＲＯＢＲと称する）は、ＮＣＢＲまたはＣＢＲ（ＮＰＣＢＲ、ＰＣＢＲ、またはＸＢＲのいずれか）によって明示的にまたは暗黙のうちに発行され、システムＳＹＳにローカルまたはリモートのいずれかの対応システムＣ＿ＳＹＳ１またはＣ＿ＳＹＳ２で動作するプログラムまたはトランザクションを対象とするか、システムＳＹＳに弱くリンクされたシステムＳＹＳのコンポーネントを対象とするサービス要求である。ＮＲＯＢＲの処理のために、ＥＲＭは、カタログ作成サービスＣＡＴＳ、ディレクトリ・サービスＤＩＲ、タスク回復サービスＴＳＲ、システム回復サービスＳＹＳＲ、および接続性サービスＣＮＣＴを活用する。異常またはバックアウト要求が起こったとき、拡張リソース・マネージャＥＲＭは、アウトバウンド・ビジネス要求の回復の試みを行わない。ＮＲＯＢＲは、回復可能であれ回復不能であれ、システム・リソースにアクセスし、ビジネス・ロジックおよびそれが対象とする対応システムの特徴に依存して、すべての種類のサービスを発行することができる。

「明示的補償回復可能アウトバウンド・ビジネス要求」（以下では、ＥＲＯＢＲと称する）は、ＮＣＢＲまたはＣＢＲによって発行され、対応システムＣ＿ＳＹＳ１およびＣ＿ＳＹＳ２で動作するプログラムまたはトランザクションを対象とするか、システムＳＹＳに弱くリンクされたシステムＳＹＳのコンポーネントを対象とするサービス要求である。異常またはバックアウト要求が起こると、拡張リソース・マネージャＥＲＭは、ＥＲＯＢＲの明示的補償のためのアクティビティを直接に開始し、このために、サービス・プロバイダ・サブシステムＳＥＲによって提供されるサービス、特にログ・サービスＬＯＧ、ＵＯＷ保護サービスＵＯＷ−Ｐ、接続性サービスＣＮＣＴ、監視サービスＭＯＮ、およびエラー回復サービスＥＲＲが活用される。ＥＲＯＢＲは、回復可能であれ回復不能であれ、システム・リソースにアクセスし、ビジネス・ロジックおよびそれが対象とする対応システムの特徴に依存して、すべての種類のサービスを発行することができる。

「暗黙補償回復可能アウトバウンド・ビジネス要求」（以下ではＩＲＯＢＲと称する）は、ＮＣＢＲまたはＣＢＲによって発行され、対応システムで動作するプログラムまたはトランザクションを対象とするか、システムＳＹＳに弱くリンクされたシステムＳＹＳのコンポーネントを対象とするサービス要求である。異常またはバックアウト要求が起こると、拡張リソース・マネージャＥＲＭは、ＩＲＯＢＲの補償のためのアクティビティを直接的には開始せず、逆に、補償は、暗黙のうちに実行される。これは、ＩＲＯＢＲの再実行の時まで延期されることを意味し、その再実行は、ＩＲＯＢＲがＰＣＢＲによって呼び出された場合にはビジネス要求マネージャＢＲＭによって自動的に管理され、ＩＲＯＢＲがＮＰＣＢＲによって発行された場合にはサービス・リクエスタによってアクティブ化される。拡張リソース・マネージャＥＲＭは、サービス・プロバイダ・サブシステムＳＥＲによって提供されるサービス、特にログ・サービスＬＯＧ、作業単位保護サービスＵＯＷ−Ｐ、接続性サービスＣＮＣＴ、監視サービスＭＯＮ、およびエラー回復サービスＥＲＲを活用する。ＩＲＯＢＲは、回復可能であれ回復不能であれ、システム・リソースにアクセスすることができる。

「補償アウトバウンド・ビジネス要求」（以下ではＸＯＢＲと称する）は、特定の種類のＩＲＯＢＲであり、エラーまたはバックアウト要求に起因して補償される必要があるかまだ補償されていない前に発行されたＥＲＯＢＲをサポートして拡張リソース・マネージャＥＲＭによって制御される特定のタスク内で動作するＸＢＲによって発行されたサービス要求である。ＸＯＢＲは、タスク回復相（後で説明する）でインフラストラクチャ・サービスによってアクティブ化される場合もある。ＸＯＢＲは、対応システムで動作するプログラムまたはトランザクションを対象とするか、システムＳＹＳに弱くリンクされたシステムＳＹＳのコンポーネントを対象とする。異常が発生すると、ＸＯＢＲは、自動的にはアクティブ化されず、拡張リソース・マネージャＥＲＭによって発行されたＸＢＲだけが、ＸＯＢＲをアクティブ化することができる。ＸＯＢＲは、回復可能であれ回復不能であれ、システム・リソースにアクセスすることができる。ＸＢＲおよびＸＯＢＲのアクティブ化は、ＥＲＭによって処理され、リクエスタ・アプリケーションに重荷は与えられず、リクエスタ・アプリケーションは、タスク回復相の完了コードを待つことができ、あるいは、タイムアウトをこうむる場合に、回復動作の拡張リソース・マネージャＥＲＭによって、責任を引き受けることについて既に通知されている。

したがって、分類されない（ＮＣＢＲ）または分類される（ＣＢＲ）のいずれであれ、分類される要求の場合に保護される（ＰＣＢＲ）または保護されない（ＮＰＣＢＲ）のいずれであれ、すべてのビジネス要求は、１つまたは複数のＯＢＲ（ＮＲＯＢＲ、ＥＲＯＢＲ、またはＩＲＯＢＲのいずれか）を発行（明示的にまたは暗黙のうちに）することができる。

所望のビジネス・プロセスを実装するのに必要なコンポーネントを正しく識別するために新しいアプリケーションの開発で採用される、上で説明したサービス要求の分類は、エラー、異常なイベント、またはバックアウト要求の場合に、リソース・マネージャ・コーディネータＲＭＣを介してトランザクション・マネージャＴＭによって調整されて、正しいアプリケーションまたはインフラストラクチャ・コンポーネントが、ＥＸＴ−ＵＯＷで用いられるデータに対してその時点までに行われたすべてのことの補償を管理するためにアクティブ化されることを保証する。したがって、エラー、異常、またはアプリケーション・バックアウト要求の場合に、ＥＸＴ−ＵＯＷに用いられたリソースの状態が、ビジネス要求マネージャＢＲＭおよび拡張リソース・マネージャＥＲＭによって制御される、自動的明示的補償または延期された暗黙の補償によって、コヒーレントな最終状態に収束することが保証される。

具体的に言うと、ＥＸＴ−ＵＯＷを用いるタスクの不成功の完了の場合に、ビジネス要求マネージャＢＲＭおよび拡張リソース・マネージャＥＲＭは、可能な時に初期状態に向かって、あるいはビジネス要求マネージャＢＲＭ、拡張リソース・マネージャＥＲＭ、およびおそらくＸＢＲ／ＸＯＢＲで実施されるアプリケーション・ビジネス・ロジックによって動的に判定されるコヒーレントな状態に向かってシステム全体（すなわち、用いられるリソース）を収束させるためのプロセスを識別し、自動的にアクティブ化することができる。すべての種類のＸＢＲを開発することができるが、デフォルトＸＢＲでは、接続性サービスＣＮＣＴへの呼び出しの結果および各呼び出されたＸＯＢＲの結果に基づいて働く各ＥＲＯＢＲに関連するＸＯＢＲＭを逆のシーケンスで発行する補償相を実施する。

ビジネス要求マネージャＢＲＭおよび拡張リソース・マネージャＥＲＭによって実施されるサービスを、これから詳細に説明する。

カタログ作成サービスＣＡＴＳ
カタログ作成サービスＣＡＴＳを用いると、前述で説明した分類方式に従うビジネス要求の分類が可能になる。

カタログ作成サービスＣＡＴＳは、カタログＣＡＴに基づいて動作し、このカタログＣＡＴの例を、図５に概略的に示す。カタログＣＡＴは、複数のレコードを有するテーブルである。各カタログ・レコードに、複数のフィールド、ＢＲＩＤ／ＣＬＩＤ、ＢＲＣＬＳ、ＡＳＳＣＭＰ、ＳＴＵＰＳＴＡＴ、ＩＮ−ＦＬＧＴ ＳＴＡＴ、Ｃ−ＳＹＳ、ＳＵＢ Ｃ−ＳＹＳ、ＨＥＡＤＥＲ、ＴＲＡＩＬＥＲ、ＡＳＳＢＲ、ＸＢＲ／ＸＯＢＲ、ＵＳＡＵＴ／ＡＣＣ、ＭＳＧＦＲＭＴ、およびＯＴＨＥＲ ＩＮＦＯが含まれる。

フィールドＢＲＩＤ／ＣＬＩＤには、分類されたビジネス要求を識別するビジネス要求識別子（Ａ、Ｂ、Ｃ、…）またはビジネス要求クラスを識別するビジネス要求クラス識別子（たとえば、ＮＰＣＢＲ、ＮＣＢＲなど）が含まれる。フィールドＢＲＩＤ／ＣＬＩＤは、カタログＣＡＴへのエントリ・キーである。

フィールドＢＲＣＬＳには、関連するフィールドＢＲＩＤ／ＣＬＩＤで識別されたビジネス要求のクラスを指定するビジネス要求クラス識別子（たとえばＮＰＣＢＲ、ＰＣＢＲ、ＯＢＲ、ＸＢＲ、ＸＯＢＲ）が含まれる。

フィールドＡＳＳＣＭＰには、関連するフィールドＢＲＩＤ／ＣＬＩＤで識別されたビジネス要求に関連するコンポーネント（プログラムまたはトランザクションあるいはその両方）の表示が含まれる。たとえば、Ａとして識別されるビジネス要求について、関連するプログラムまたはトランザクションが、カタログで指定されておらず、ビジネス要求Ａが受け取られると、アクティブ化されるコンポーネントはＡ自体である。あるいは、Ｐとして識別されるビジネス要求について、プログラムＰＧｈおよびトランザクションＴｒｋが指定されており、これは、ビジネス要求Ｐが受け取られると、トランザクションＴｒｋ内のプログラムＰｇｈがアクティブ化されることを意味する。

フィールドＳＴＵＰＳＴＡＴは、システム開始時にビジネス要求に帰せられる状況（ＯＮまたはＯＦＦ）を定義する（後で詳細に説明する）。フィールドＩＮ−ＦＬＧＴ ＳＴＡＴには、処理中（ｉｎ ｆｌｉｇｈｔ）である時のビジネス要求の現在の状況の表示が含まれる。

フィールドＣ−ＳＹＳは、ＯＢＲについて、それが向けられる対応システムを定義する。対応システムが１つまたは複数のサブシステムを関連付けられている場合には、フィールドＳＵＢ Ｃ−ＳＹＳが、ＯＢＲが向けられる、フィールドＣ−ＳＹＳで定義された対応システムのサブシステムを指定する。フィールドＣ−ＳＹＳおよびＳＵＢ−Ｃ ＳＹＳに保管される情報は、ディレクトリ・サービスへのアクセス・キーを形成する。

フィールドＨＥＡＤＥＲおよびＴＲＡＩＬＥＲは、関連するフィールドＢＲＩＤ／ＣＬＩＤで識別されるビジネス要求をサービスすることに対してそれぞれ予備的におよび後に発行されるビジネス要求を定義する。図示の例では、Ａとして識別されるビジネス要求が受け取られると、それをサービスする前にビジネス要求Ｅが、そのサービスの後にビジネス要求Ｆが、それぞれサービスされる。

フィールドＡＳＳＢＲは、関連するフィールドＢＲＩＤ／ＣＬＩＤで識別されるビジネス要求をサービスする間に発行できるビジネス要求を定義する。図示の例をもう一度参照すると、Ａとして識別されるビジネス要求が受け取られると（ヘッダ・ビジネス要求Ｅがサービスされた後に）、ビジネス要求ＧおよびＨがサービスされる（トレーラ・ビジネス要求Ｆがこれに続く）。

フィールドＸＢＲ／ＸＯＢＲ（ＥＲＯＢＲに必須）は、関連するフィールドＢＲＩＤ／ＣＬＩＤで識別されるビジネス要求によって実行されるアクションを補償するために実行すべき補償ビジネス要求（ＸＢＲまたはＸＯＢＲ）を定義する。図示の例では、ビジネス要求Ａのサービス中に実行されるアクションを補償するために、ＸＢＲ Ｊが発行される（これは、ＸＯＢＲシーケンスＬおよびＭに対応する）。特定のＸＢＲが所与のビジネス要求について指定されない場合には、ビジネス要求内で発行されたＯＢＲによって実行されたアクションを補償するために、デフォルトＸＢＲが呼び出され、補償するアクションは、サービスＬＯＧによって提供される情報に基づいて、拡張リソース・マネージャＥＲＭによって決定される。ＸＢＲおよびＸＯＢＲは、暗黙の補償ビジネス要求なので、ＸＢＲおよびＸＯＢＲに補償ビジネス要求を関連付けることはできず、補償は、サービスＬＯＧによって提供される情報（既に実行されたアクティビティおよびこれから実行されるアクティビティを示す）に基づいて実行されることが観察される。

要約すると、ビジネス要求Ａに関して、カタログＣＡＴに保管された情報は、ビジネス要求Ａが受け取られた時に、ビジネス要求のシーケンスＥ→Ｇ→Ｈ→Ｆが実際に発行され、サービスされることと、何かがおかしくなった場合に、実行されたアクションの補償が、ＸＢＲ Ｊによって実行され、ＸＢＲ Ｊは、ＸＯＢＲのシーケンスＬ→Ｍに対応することを示す。ビジネス要求Ｂに関して、これは、ビジネス要求Ｐの別名である。ＯＢＲ ＧおよびＨの発行の後に発生する障害の場合に、デフォルトＸＢＲが拡張リソース・マネージャＥＲＭによって呼び出され、ＸＯＢＲ ＬおよびＭを伴う逆のシーケンスが、自動的に実施される。

フィールドＵＳＡＵＴ／ＡＣＣは、関連するフィールドＢＲＩＤ／ＣＬＩＤで識別されるビジネス要求の実行許可のユーザ・オーソリティ・レベルおよびアカウントを定義する。

ＭＳＧＦＲＭＴは、関連するフィールドＢＲＩＤ／ＣＬＩＤで識別されるビジネス要求の呼び出しメッセージのフォーマットを定義する（解釈の規則のセットを指定する）。

フィールドＯＴＨＥＲ ＩＮＦＯは、追加情報をカタログＣＡＴに保管できることを示すのに使用される。

特定のビジネス要件に関するレコード（図５でＡ、Ｂ、Ｃなどとして識別されるレコード）のほかに、カタログＣＡＴに、ＮＰＣＢＲとして識別されるレコード（クラスＮＰＣＢＲのすべてのビジネス要求に関する）などのビジネス要求のクラスに関するデフォルト情報を提供するレコードも含めることができる。リストＡ、Ｂ、Ｃなどに見つからないが、ＮＰＣＢＲとして識別されるビジネス要求が受け取られると、カタログのレコードＮＰＣＢＲに保管された情報が適用される。図示の例では、クラスＮＰＣＢＲに関して指定されるデフォルト情報に、システム開始時にすべてのＮＰＣＢＲに帰せられるＯＮ状況と、エラーまたはＮＰＣＢＲ内で発行される１つまたは複数のＯＢＲによって実行されたアクションを補償するバックアウト要求の場合に呼び出されるＸＢＲ Ｚが含まれる。

さらに、カタログＣＡＴに、分類されないビジネス要求に帰せられる、図示の例のレコードＮＣＢＲなど、ＮＣＢＲに関するデフォルト情報を指定するレコードも含めることができる。

最後に、カタログＣＡＴに、特定のクラスのビジネス要求のオーバーライド情報を定義するレコード（図示の例のレコードＮＰＣＢＲなど）を含めることができる。

カタログＣＡＴから取り出される情報は、ビジネス要求の実行コンテキストの定義に寄与する。具体的に言うと、カタログ作成プロセスまたはビジネス要求の実行コンテキストを定義するプロセスは、次の通りである。

ビジネス要求が発行されると、そのビジネス要求の実行コンテキストを定義する情報を提供することができる。この情報は、ビジネス要求が明示的に呼び出される場合に明示的に供給することができ、暗黙の呼び出しの場合にビジネス要求の呼び出しのコンテキストから導出することができる。通常、ビジネス要求の明示的呼び出しは、次の形になる。
ａ）ＡＰＰｃａｌｌＢＲＭ（ＢＲ、ｉｎｐＤａｔａ、［ＸＢＲ］、［ＣＴＸＴ／ＡＮＮＬ ｄａｔａ］、［ｔｒａｎ］、［ｕｓｅｒ］）；
ｂ）ＢＲｃａｌｌＥＲＭ（ＯＢＲ、ｉｎｐＤａｔａ、［Ｃ−ＳＹＳ］、［ＳＵＢＣ−ＳＹＳ］、［ＸＯＢＲ］、［ＣＴＸＴ／ＡＮＮＬ ｄａｔａ］、［ｔｒａｎ］、［ｕｓｅｒ］）；
ｃ）ＸＢＲｃａｌｌＥＲＭ（ＸＯＢＲ、ＯＢＲｉｎｐ／ｏｕｔ／ＣＴＸＴ／ＡＮＮＬｄａｔａ、［Ｃ−ＳＹＳ］、［ＳＵＢＣ−ＳＹＳ］、［ｔｒａｎ］、［ｕｓｅｒ］、［ｐｒｅｖｉｏｕｓ ＸＯＢＲ ｉｎ／ｒｅｐｌｙ／ｏｕｔｃｏｍｅ］）
ここで、ａ）は、アプリケーションＡＰＰがビジネス要求（カタログ作成されたものまたはそうでないもの）を呼び出す場合を表し、ｂ）は、ビジネス要求（カタログ作成されたものまたはそうでないもの）がＯＢＲを発行する場合を表し、ｃ）は、ＸＢＲが補償相中にＸＯＢＲを呼び出す場合を表す。大括弧内の情報は、オプションである。具体的に言うと、ＢＲは、呼び出されるビジネス要求識別子であり、ｉｎｐＤａｔａは、呼び出しで供給される入力メッセージであり、Ｃ−ＳＹＳおよびＳＵＢＣ−ＳＹＳは、対応システムおよびサブシステムの識別子であり、ＸＢＲは、補償を実行する必要がある場合にシステムによってアクティブ化される補償ビジネス要求の識別子であり、ＸＯＢＲは、アウトバウンド補償ビジネス要求の識別子であり、ＣＴＸＴ／ＡＮＮＬ ｄａｔａは、呼出し時に供給される、補償相中にシステムによって使用できる情報を表し、ｔｒａｎおよびｕｓｅｒは、呼び出されたビジネス要求が実行されるコンテキスト（許可のレベル、トランザクションなど）を定義する。ＸＯＢＲ（事例ｃ））の呼出し時に供給される情報に、ＯＢＲの結果／応答メッセージを含む、補償されるＯＢＲに関連する情報を含めることができる。

この情報は、カタログに保管された情報と一体化される。異なる優先順位レベルが、情報の異なるソースに割り当てられ、具体的には、ビジネス要求の呼び出しと一緒に供給される情報は、そのビジネス要求のカタログで指定される情報より高い優先順位を持ち、後者は、ビジネス要求のクラスについてカタログで指定されるデフォルト情報より高い優先順位を持つ。存在する場合に、ビジネス要求のクラスに関してカタログで指定されるオーバーライド情報は、最高の優先順位を持つ。

単一のカタログではなく、ビジネス要求マネージャＢＲＭに１つ、拡張リソース・マネージャＥＲＭにもう１つの、２つの別個のカタログを設けることができることを観察されたい。１つまたは複数のカタログを、複数のテーブルで構成することができる。

システムＳＹＳの専用コンポーネント（構成コンポーネント）が、システムの構成、特にカタログＣＡＴの構成を可能にする。

ディレクトリ・サービスＤＩＲＳ
ディレクトリ・サービスＤＩＲＳは、ＯＢＲの実行コンテキストを定義する情報を提供する。

ディレクトリ・サービスＤＩＲＳは、ディレクトリＤＩＲに基づいて動作し、その例を、図６に概略的に示す。ディレクトリＤＩＲは、複数のレコードを有するテーブルである。各ディレクトリ・レコードに、複数のフィールド、Ｃ−ＳＹＳ、ＳＵＢ Ｃ−ＳＹＳ、ＡＳＳＣＭＰ、Ｃ−ＳＹＳ ＳＴ−ＵＰ ＳＴＡＴ、Ｃ−ＳＹＳ ＩＮ−ＦＬＧＴ ＳＴＡＴ、ＣＮＣＴ ＩＤ、ＣＮＣＴ ＡＴＴＲ、ＳＩＧＮ−ＯＮ、ＩＮ−ＤＯＵＢＴ、ＢＡＣＫＯＵＴ、ＶＥＲ、ＳＹＳ ＲＥＣ ＭＯＤＥ、ＴＯ、ＵＳＡＵＴ／ＡＣＣ、およびＭＳＧＦＲＭＴが含まれる。

フィールドＣ−ＳＹＳおよびＳＵＢ Ｃ−ＳＹＳは、ディレクトリＤＩＲのエントリ・キーである。ＯＢＲが呼び出される時に、この情報が、上で説明したカタログ作成プロセスから導出される。

フィールドＡＳＳＣＭＰには、カタログＣＡＴのフィールドＡＳＳＣＭＰに似て、ＯＢＲに関連するコンポーネント（プログラムまたはトランザクションあるいはその両方）の表示が含まれる。ディレクトリのこのフィールドで指定される情報は、上で説明したカタログ作成プロセスから導出された情報をオーバーライドし、このディレクトリ・フィールドで関連するコンポーネントが指定されない場合に、カタログ作成プロセスから導出された情報が、有効になる。図示の例を参照すると、対応システムＣ−ＳＹＳ２に向けられたＯＢＲが呼び出されるたびに、リモート・トランザクションＲＭＴＲｑ内のリモート・プログラムＲＭＰＧｐが実行される。

フィールドＣ−ＳＹＳ ＳＴ−ＵＰ ＳＴＡＴは、システムＳＹＳの開始時の対応システムの状況を定義する。このフィールドにＯＮがセットされている場合に、対応システムのシステム回復手順をシステムＳＹＳの開始時に実行する必要はない。フィールドＣ−ＳＹＳ ＩＮ−ＦＬＧＴ ＳＴＡＴは、対応システムの現在の状況を定義し、ＯＮがセットされている場合に、このフィールドは、対応システムが使用可能であることを示す。

フィールドＣＮＣＴ ＩＤは、対応システムとの接続を確立するために拡張リソース・マネージャＥＲＭが呼び出すコネクタの識別子を提供する。コネクタは、システムＳＹＳと、ＯＢＲが向けられる対応システムとをインターフェースする責任を負うコンポーネントである。インターフェースは、論理レベルおよび物理レベルの両方での通信プロトコルの処理を含むことが意図されている。対応システムごとに、１つまたは複数のコネクタを定義することができ、所与のコネクタの選択は、通信問題の考慮事項、採用される通信パラダイム、およびＯＢＲの性質に依存する。各コネクタが、１つまたは複数の対応システムとの複数のセッション（１つまたは複数の対応システムに向けられる複数のＯＢＲ）を一時にサポートできるように設計されることが好ましい。コネクタは、ＯＢＲ提案、ＯＢＲ補償（ＸＯＢＲ）、システム・サインオン相およびシステム検証相、未確定状況の解決のアクティビティのいずれかを実行する際に拡張リソース・マネージャＥＲＭを助ける。

新しいＯＢＲが開発される時に、それに関連するコネクタを識別する必要があり、使用可能なコネクタに適切なものがない場合には、新しいＯＢＲのアプリケーション・プロトコルおよび拡張リソース・マネージャＥＲＭのアクティブ化プロトコルに従って、新しいコネクタを開発する必要がある。

フィールドＣＮＣＴ ＡＴＴＲは、確立されるコネクタの属性、接続の種類の定義、接続を確立するのに活用されるリソースなど、コネクタに関する情報を指定する。この情報は、コネクタのデフォルト情報をオーバーライドする。

フィールドＳＩＧＮ−ＯＮ、ＩＮ−ＤＯＵＢＴ、ＢＡＣＫＯＵＴ、およびＶＥＲは、それぞれ、システム回復相（後で説明する）でアクティブ化される、サインオン手順、未確定手順、バックアウト手順、および検証手順を指定する。特定の手順がこのフィールドで識別されない場合には、拡張リソース・マネージャＥＲＭによって実施されるデフォルト手順が活用され、その代わりに特定の手順が指定される場合には、その手順が、デフォルト手順の代わりにアクティブ化される。

フィールドＳＹＳ ＲＥＣ ＭＯＤＥは、対応システムの誤動作または使用不能に反応してビジネス要求マネージャＢＲＭおよび拡張リソース・マネージャＥＲＭによって採用されるシステム回復／タスク回復エスカレーション・パラダイム（後で説明する）を指定する。この場合にも、デフォルト・パラダイムを定義することができ、このデフォルト・パラダイムは、特定の情報がディレクトリで指定されない場合に採用される。

フィールドＴＯは、タイムアウトすなわち、コネクタ（および拡張リソース・マネージャＥＲＭ）が対応システムからの応答を待つことを許可される最大の時間を指定する。応答を受け取らずにタイムアウトが経過した場合に、その動作は未確定として分類される。

フィールドＵＳＡＵＴ／ＡＣＣおよびＭＳＧＦＲＭＴには、カタログＣＡＴの対応するフィールドに含まれるものに類似する情報が含まれる。具体的に言うと、フィールドＵＳＡＵＴ／ＡＣＣは、ビジネス要求のサービスに用いられる、ユーザおよび関連する特権を指定する。フィールドＭＳＧＦＲＭＴは、ＯＢＲの呼び出しと共に提供されるデータのフォーマットを識別する。

ＯＢＲが発行される時に、ディレクトリＤＩＲ（カタログＣＡＴのフィールドＣ−ＳＹＳおよびＳＵＢ Ｃ−ＳＹＳで指定されるアクセス・キーを介してアクセスされる）から取り出された情報によって、カタログ作成プロセスから導出された実行コンテキスト情報が完成する。ある情報（具体的には、ＯＢＲに関連するリモート・プログラム／トランザクション、接続属性、タイムアウト、ユーザ、およびメッセージ・フォーマット）は、拡張リソース・マネージャＥＲＭによって呼び出される時にコネクタに供給され、拡張リソース・マネージャＥＲＭは、対応システム状況、サインオン手順、未確定手順、バックアウト手順、検証手順、およびエスカレーション・パラダイムに関する情報を活用する。

ディレクトリＤＩＲは、システム構成コンポーネントによって構成することができる。

ログ・サービスＬＯＧ
ログ・サービスＬＯＧは、専用アーカイブ（ログ・アーカイブ）での、リソース・マネージャ・コーディネータＲＭＣおよびリソース・マネージャＲＭによって実行される動作を含むシステムＳＹＳのアクティビティ、ビジネス要求マネージャＢＲＭのアクティビティ、および拡張リソース・マネージャＥＲＭのアクティビティに関する合成情報および詳細情報の保管を対象とする。保管された情報は、発生したイベントの論理的にコヒーレントなビューを提供し、後者は、補償アクティビティが必要な時に使用することができる。

ログ・アーカイブに保管された情報は、用いられる異なるインフラストラクチャ的コンポーネントによるビジネス要求の処理中または補償中あるいはその両方にビジネス要求マネージャＢＲＭまたは拡張リソース・マネージャＥＲＭによって明示的に提供される。

ログ・サービスＬＯＧは、リソース・マネージャ・コーディネータＲＭＣの調整の下でリソース・マネージャとして動作する。データは、ビジネス要求マネージャまたは拡張リソース・マネージャによってログ・サービスに供給され、リソース・マネージャ・コーディネータは、他のリソース・マネージャに似て、ログ・サービスを調整する。ログ・サービスは、ＵＯＷに関してビジネス要求マネージャまたは拡張リソース・マネージャによって受け取られた情報の扱い方を決定し、所与のＵＯＷがコミットされる場合には、そのＵＯＷに関するログ・アーカイブに保管された情報が統合され、そのＵＯＷがバック・アウトされる場合には、そのＵＯＷに関するログ・アーカイブに保管された情報が、可能な補償アクティビティのために使用可能である。ビジネス要求マネージャまたは拡張リソース・マネージャによって供給される情報は、そのＵＯＷが実行されるコンテキストに関する情報（たとえば、作業単位識別子、状況情報、作業単位完了コード）によって完成する。

ログ・アーカイブに保管された情報への高速アクセスを可能にするために、ログ・サービスは、ログ・アーカイブに保管される情報を論理的に編成する。具体的に言うと、情報は、ＥＸＴ−ＵＯＷ、ＥＸＴ−ＵＯＷのＵＯＷ、ＵＯＷを実施するタスク、ビジネス要求、ビジネス要求内で呼び出されるＯＢＲ、およびＯＢＲが向けられる対象システムによって編成される。ＥＸＴ−ＵＯＷ、ＵＯＷ、タスク、ビジネス要求、ＯＢＲ、および対応システムの識別子コードが活用される。

ビジネス要求が受け取られると、トランザクション・マネージャＴＭが、タスクをアクティブ化し、そのタスクの中で、プログラムによって実施されるトランザクションが動作する。トランザクション・マネージャは、ＵＯＷをタスクに関連付け、そのタスクに一義識別子コードを割り当てる。ビジネス要求が、ビジネス要求マネージャによってインターセプトされる場合に、一義識別子コードが、そのビジネス要求に割り当てられる。ＯＢＲが、ビジネス要求内で発行される場合に、一義識別子コードが、そのＯＢＲに割り当てられる。これらの一義識別子コードのすべてが、ログ・サービスに供給される。

ログ・サービスによって、各サービス要求（完了したか、処理中または遅延中なのでまだ完了していない）の詳細ヒストリを、明示的補償アクティビティまたは暗黙補償アクティビティを含めて判定することができる。

サービス要求のサービス中のエラーまたは未確定情況の場合に、コンテキスト情報（拡張リソース・マネージャによって供給され、またはログ・サービスによって直接に収集され、あるいはその両方）が、次の詳述または評価タスク／システム回復サービスあるいはその両方のための使用のために、ログ・アーカイブに保管される。

上でリストした呼び出しのフォーマットに戻ると、ＯＢＲが呼び出される時に、単一のＯＢＲ要求を、やはりＬＯＧサービスによって保管される特定のユーザ・データＡＮＮＬによって達成することができる。これらのユーザ・データは、ＯＢＲ呼び出しコンテキストの一部になるが、ＸＢＲプロセスから使用可能であるか接続性サービスＣＮＣＴに直接に供給される、タスク回復サービスおよびシステム回復サービスによる次の詳述または評価あるいはその両方にも使用することができる。

ログ・サービスは、まだ完了していないＥＸＴ−ＵＯＷ、ＵＯＷ、およびタスクを識別するアンカ・ポイントを処理する。ＥＸＴ−ＵＯＷが完了する時に、ＥＸＴ−ＵＯＷの実行中にリソースにもたらされる変更のコミットの際にまたは補償アクションの結果で達する状態すなわちそのＥＸＴ−ＵＯＷに関連するアンカ・ポイントが削除され、この形で、どのアクティビティが実行中であり、延期され、または完了を待っているかを簡単に判定することがいつでも可能になる。

補償相中に、受け取られるか取り込まれ、ログ・アーカイブに保管される情報によって、動的に判定されるコヒーレント状態に達するのに必要なアクティビティのシーケンスを正確に判定することが可能になる。この情報は、ＸＢＲコンポーネントによってまたは接続性サービスＣＮＣＴによってこの時に混合され、または再配置され、あるいはその両方を行われて、ＸＯＢＲ入力メッセージを構成することができる。デフォルトで、呼び出されるＸＢＲまたはコネクタに追加されるビジネス・ロジックがない場合に、デフォルトＸＢＲによって作られるＸＯＢＲ入力メッセージを、次の１つとすることができる（カタログまたはディレクトリあるいはその両方に保管された情報によって導出される）
・元々のＯＢＲ入力メッセージ
・ＯＢＲ応答メッセージ
・ＯＢＲ呼出し時に供給されたデータＣＴＸＴ／ＡＮＮＬ
・データＩＮ／ＯＵＴ／ＣＴＸＴ／ＡＮＮＬを含むマルチセグメント・メッセージ

具体的に言うと、ログ・アーカイブに保管されるデータは、次の表で報告されるように、用いられるコンポーネントおよびビジネス要求の性質に依存する。

エラー回復サービスＥＲＲ
エラー回復サービスＥＲＲは、アプリケーションまたはインフラストラクチャでの誤動作に起因するエラー状態の制御を対象とする。このサービスは、システム開始時およびトランザクションまたはプログラムを対象とするサービス要求の実行中にエラーが発生する時に必ず、トランザクション・マネージャＴＭによってアクティブ化される。

エラー回復サービスＥＲＲをアクティブ化する前に、用いられる異なるアプリケーションまたはインフラストラクチャ・コンポーネントのすべてが、エラーを解決するか適切な信号を発行するために、エラー状態の自律的な処理を試みる。一般に、すべてのエラーを、トランザクション・マネージャＴＭにエラーとして宣言する必要はない。エラー状態は、アプリケーション・エラーに階級を下げることができ、それぞれのアプリケーションによって処理することができる。

エラー状態が永続する（アプリケーションがそのエラー状態を処理できないので、またはエラー状態の階級を下げることができないのでのいずれかで）場合に、トランザクション・マネージャＴＭは、エラー回復サービスＥＲＲをアクティブ化する。エラー回復サービスＥＲＲは、エラー状態を引き起こしたタスクのＵＯＷ内で、エラー状態を分類し、処理する。コンテキスト情報は、ログ・サービスＬＯＧによってログ・アーカイブにアーカイブされ、この情報は、タスク回復サービスＴＲおよびビジネス要求保護サービスＰＲに有用である可能性がある。

具体的に言うと、獲得された情報は、ビジネス要求マネージャＢＲＭおよび拡張リソース・マネージャＥＲＭの論理状態（エラー状態の処理を決定する）、実行中のアクティビティの種類（通常処理、バックアウト、補償、未確定解決、システム回復、タスク回復）、用いられるコンポーネントのタイプ、エラーの種類、およびエラーがどのように生成されたかに関係する。

エラー回復サービスＥＲＲは、次のアクションの１つを採用して、実行すべき動作を決定する。
ａ）エラー状態を確認し、トランザクション・マネージャＴＭに制御を返す。トランザクション・マネージャは、リソース・マネージャ・コーディネータＲＭＣによって管理されるバックアウト手順を自動的にアクティブ化する
ｂ）拡張リソース・マネージャＥＲＭによって使用される情報の収集および編成のために、タスク回復サービスＴＲＳによってタスク回復手順をアクティブ化する。制御は、その後にトランザクション・マネージャＴＭに返され、トランザクション・マネージャＴＭは、リソース・マネージャ・コーディネータＲＭＣによって管理されるバックアウト手順を自動的にアクティブ化する。リソース・マネージャ・コーディネータは、拡張リソース・マネージャＥＲＭを呼び出し、拡張リソース・マネージャＥＲＭは、可能な補償アクティビティをサポートする動作を実行する。
ｃ）タスク回復サービスＴＲＳがタスク回復手順をアクティブ化し、エラー処理手順を抑止する。制御は、トランザクション・マネージャＴＭに返されて、リソース・マネージャ・コーディネータＲＭＣによって管理されるコミット手順が自動的にアクティブ化される。したがって、エラー状態は、トランザクション・マネージャによって処理されない。

エラー回復サービスＥＲＲは、暗黙の補償または明示的補償の相に直接には参加しない。このアクティビティは、他のリソース・マネージャＲＭに似て、サービス要求の実行中に発生する変更のバックアウトの相でリソース・マネージャ・コーディネータＲＭＣによってアクティブ化される拡張リソース・マネージャＥＲＭによって管理される。

ａ）およびｂ）の事例で、バックアウトが実行され、このバックアウトに、補償手順を含めることができ、この補償手順の前に、タスク回復相を置くことができる。

事例ｂ）およびｃ）に関して、アプリケーション誤動作またはインフラストラクチャ誤動作の場合であっても、延期された補償アクティビティを管理する責任を負うビジネス要求マネージャＢＲＭおよび拡張リソース・マネージャＥＲＭが正しくアクティブ化されることを保証するために、エラー回復サービスＥＲＲは、必ず、ＰＣＢＲ、ＸＢＲ、およびＸＯＢＲが存在する場合にタスク回復サービスＴＲＳをアクティブ化する。

ＵＯＷ保護サービスＵＯＷ−Ｐ
このサービスは、１つまたは複数のアプリケーション・プログラムがサービス要求の処理でその下で動作するＵＯＷの保全性を保証する。ログ・サービスＬＯＧを活用して、ＵＯＷ保護サービスＵＯＷ−Ｐは、ビジネス要求の処理で呼び出されたアプリケーションによって発行される明示的コミット要求およびバックアウト要求をインターセプトし、コミット・コマンドの実行を抑制する。バックアウト・コマンドは、実行され、ビジネス要求マネージャＢＲＭおよび拡張リソース・マネージャＥＲＭに通知されると同時に、こうむる可能なミスアライメントの延期された処理を可能にするために、他のアプリケーションまたはコンポーネントから使用可能にされる。

具体的に言うと、ＵＯＷ保護サービスは、ＣＯＯ−ＵＯＷまたはＥＸＴ−ＵＯＷの場合に明示的コミット・コマンドが実行されないようにし、したがって、そのフラグメンテーションを避ける。バックアウト・コマンドの場合に、コマンドが、実行され、ＵＯＷ保護サービスが、ビジネス要求マネージャおよび拡張リソース・マネージャに通知する。したがって、ＵＯＷ保護サービスは、ＣＯＯ−ＵＯＷおよびＥＸＴ−ＵＯＷの保全性を保護し、サービス要求に関して実行されるすべてのアクティビティが、コヒーレントでフラグメント化してないＵＯＷだけによって管理されるようにする。したがって、各アクティビティは、入力メッセージ獲得、メッセージ処理、応答出力メッセージ生成の相の完了の後に、処理の終りに限って完了したと暗黙のうちに見なされる。

ＵＯＷ保護サービスのおかげで、ビジネス要求マネージャＢＲＭは、各サービス要求が一義に処理され、一義の応答を作ることを保証し、入出力メッセージの消失または複数の応答メッセージの生成あるいはその両方を回避する。

このシナリオで、コンポーネント（ビジネス要求マネージャおよび拡張リソース・マネージャと異なる）が、明示的コミット要求を発行すると、処理が、割り込まれ、エラー状態が、トランザクション・マネージャに通知される。エラー状態は、エラー回復サービスによってインターセプトされ、エラー回復サービスは、前に説明したようにエラー状態を処理する。コンポーネントが、明示的バックアウト要求を発行する時に、そのコマンドは、実行されるが、ＵＯＷ保護サービスは、そのバックアウト・イベントをビジネス要求マネージャおよび拡張リソース・マネージャに通知し、その結果、このイベントが、タスク終了相中に成功裡に処理されるようにする。

タスク回復サービスＴＳＲ
このサービスは、タスク回復手順を処理する責任を負う。

ビジネス要求を処理する一般タスク（処理中タスク）の実行中に、エラー回復サービスＥＲＲによって処理されるエラー、またはリソース・マネージャ・コーディネータＲＭＣによって調整されるバックアウト要求が発生する場合がある。この事例の両方で、タスク回復手順がアクティブ化されるが、第１の事例では、前に説明したようにエラー回復サービスＥＲＲによって、第２の事例ではリソース・マネージャ・コーディネータＲＭＣによってアクティブ化される拡張リソース・マネージャＥＲＭによって、タスク回復手順がアクティブ化される。

タスク回復手順は、システム回復手順（後で説明する）内でシステムＳＹＳの開始時に、システム障害またはシャットダウンの後にも、アクティブ化されて、ビジネス要求を識別するビジネス要求マネージャおよび拡張リソース・マネージャをアクティブ化または再アクティブ化することが可能になる。具体的に言うと、ビジネス要求マネージャは、前に処理中のまたは待機中のＰＣＢＲを識別し、開始／再始動し、拡張リソース・マネージャは、前に処理中のまたは待機中の補償ビジネス要求（ＸＢＲ）を識別し、開始／再始動する。このために、タスク回復サービスは、ログ・サービスＬＯＧから得られる情報と、リソース・マネージャ・コーディネータＲＭＣによって供給される情報（処理中タスクおよび保留中の補償タスクに関する）をマージして、拡張リソース・マネージャが呼び出される回復相に必要な情報を収集する（単一のタスクごとに）。

タスク回復手順中に、ログ・アーカイブに保管されたデータを分析して、単一のタスクごとに、現在のＵＯＷを識別し、識別されたＵＯＷごとに、関連する状態および用いられるリソースを識別する。

この動作の後に、完全なリストが、ビジネス要求マネージャによって再アクティブ化されなければならない前に処理中のまたは保留中のＰＣＢＲについて得られ、拡張リソース・マネージャについて、前に処理中のビジネス要求を補償するＸＢＲ／ＸＯＢＲの完全なリストと、補償保留中ビジネス要求のリストが得られる。

ＰＣＢＲは、ビジネス要求マネージャによって即座に再アクティブ化され、ＥＲＯＢＲのアクティブ化は、その代わりに、補償相（ある場合に）の完了の後まで延期される。

拡張リソース・マネージャは、カタログ作成サービスＣＡＴＳおよびディレクトリ・サービスＤＩＲＳによって提供される情報に応じて、単一ＵＯＷのレベルで、または互いに直列に単一対応システムのレベルでのいずれかで補償タスクをアクティブ化する。

システム回復サービスＳＹＳＲ
このサービスは、ディレクトリ・サービスＤＩＲＳによって保持されるテーブルＤＩＲで定義される各対応システムのシステムＳＹＳの開始時に実行されるシステム回復手順（概略的に図７に図示）を処理する。システム回復手順では、拡張リソース・マネージャが主に用いられるが、ビジネス要求マネージャも、ＰＣＢＲに関して部分的に用いられる。

システム回復手順は、次のサービス要求の実行をそこから進行させる対応システム、たとえばＣ−ＳＹＳ１およびＣ−ＳＹＳ２とシステムＳＹＳの間の一義の同期ポイントの確立を可能にする。

さらに、システム回復サービスは、１つまたは複数の対応システムに関して異常なイベントが発生する時にも、システム回復手順をアクティブ化する。そのような異常なイベントは、アプリケーション・コンポーネントまたはインフラストラクチャ・サービス（拡張リソース・マネージャ）のいずれかによってインターセプトされるが、一貫性のある点を確立するために、システムＳＹＳおよび対応システムを再割り当てすることが必要になる場合がある。この場合に、システム回復手順は、異常なイベントが発生した対応システムに関してのみ、選択的に実行される。

システム回復手順の目的は、指示されたステップのシーケンスの後に、対応システムの論理状態（ディレクトリＤＩＲのフィールドＣ−ＳＹＳ ＳＴ−ＵＰ ＳＴＡＴおよびＳＹＳ ＩＮ−ＦＬＧＴ ＳＴＡＴからシステムＳＹＳに既知になる）をＯＮにし、対応システムが動作することを示すことである。これを行うために、拡張リソース・マネージャが必要とする場合に、システム機能およびアプリケーション機能の両方をアクティブ化することができる。

具体的に言うと、システム回復手順には、対応システム静止（以下では、単にＣ−ＳＹＳ ＱＵＩＥＳＣＥと称する）、対応システム停止（Ｃ−ＳＹＳ ＳＴＯＰ）、対応システム・サインオン（Ｃ−ＳＹＳ ＳＩＧＮ−ＯＮ）、対応システム未確定（Ｃ−ＳＹＳ ＩＮ−ＤＯＵＢＴ）、対応システム・バックアウト（Ｃ−ＳＹＳ ＢＡＣＫＯＵＴ）、対応システム検証（Ｃ−ＳＹＳ ＶＥＲＩＦＹ）、および対応システム・レディ（Ｃ−ＳＹＳ ＲＥＡＤＹ）が含まれる。これらのステップを、次に詳細に説明する。

Ｃ−ＳＹＳ ＱＵＩＥＳＣＥステップでは、拡張リソース・マネージャＥＲＭが、対応システムを論理的にディスエーブルし、ディレクトリＤＩＲのそれぞれの状態にＱＵＩＥＳＣＥをセットする。この形で、対応システムが拡張リソース・マネージャによってＲＥＡＤＹ（ＯＮ）状況に戻されるまで、対応システムに向けられるすべての可能な新しいビジネス要求が、拒否される（保護されない場合）か、延期される（保護される場合）。ビジネス要求マネージャまたは拡張リソース・マネージャによって管理される、対応システムに関係するすべての処理中アクティビティの完了が、待たれる。

このステップを成功裡に完了できない（たとえば、対応システムを用いる処理中のトランザクションがあり、それを完了できなので）場合に、システム回復手順全体が、ディレクトリＤＩＲで定義される（タイムアウト・フィールドＴＯ内）時間間隔だけ延期される。その時間間隔が経過した後に、システム回復手順がもう一度アクティブ化される。

Ｃ−ＳＹＳ ＱＵＩＥＳＣＥステップの成功の結果の場合に入るＣ−ＳＹＳ ＳＴＯＰステップでは、拡張リソース・マネージャが、ディレクトリＤＩＲで指定される対応システムの状態を強制的にＳＴＯＰにする。対応システムの状態がＳＴＯＰである時には、対応システムに関連するアクティビティがシステムＳＹＳ内で動作していないことが保証され、ＳＴＯＰ状態は、対応システムがサービス要求の処理に使用可能でないことも宣言する。ＵＯＷの補償は、割り込まれ、次のＣ−ＳＹＳ ＢＡＣＫＯＵＴステップまで延期される。対応システムの状態は、自動的に強制的にＳＩＧＮ−ＯＮにされる。

対応システムは、システムＳＹＳのシステム・マネージャ・コンポーネントによっても強制的にＳＴＯＰ状態にされる場合がある。この場合に、対応システムは、システム回復手順が次に再アクティブ化されるまで、ＳＴＯＰ状態に留まる。

Ｃ−ＳＹＳ ＳＩＧＮ−ＯＮステップでは、システムＳＹＳは、対応システムへの論理リンクまたは対応システムとの一貫性ポイントあるいはその両方を確立する。ディレクトリＤＩＲ内の情報（フィールドＳＩＧＮ−ＯＮ）に基づいて、その対応システムに関するこのアクティビティを管理することを意図された指定されたサインオン手順が、識別され、アクティブ化される。特定のサインオン手順がその対応システムのディレクトリで宣言されていない場合に、拡張リソース・マネージャは、接続性サービス（すなわちコネクタ・コンポーネント）によって実施されるデフォルトアクションを実行する。識別されたサインオン手順は、拡張リソース・マネージャＥＲＭにサービスを要求することができ、このサービスは、ＮＲＯＢＲの形をとって、システムＳＹＳが対応システムによって識別されるようにする相（ディレクトリ・フィールドＵＳＡＵＴ／ＡＣＣに含まれる情報を活用する）、対応システムがシステムＳＹＳから来るサービス要求をサポートするために割り振らなければならない対応システム・リソースを折衝する相、将来のＯＢＲの識別コードを獲得／折衝する相を実行する。ＯＢＲ識別コードは、アプリケーション・ドメインに留まる（すなわち、コネクタ・レベルでのみ知られる）か、拡張リソース・マネージャに宣言して、対応システムに向けられる将来のＯＢＲに自動的に相関される（ログ・アーカイブのレベルで）ようにすることができる。したがって、ＯＢＲごとに、サービスを呼び出すアプリケーションは、アクティブ化メッセージ、応答メッセージ、および対応システムで実行されるタスクの間の自動相関を可能にするために、呼び出されるサービス要求に関連する識別子コードおよび受け取られた応答に対する識別子コードを拡張リソース・マネージャに宣言することができる。

Ｃ−ＳＹＳ ＳＩＧＮ−ＯＮステップの成功裡の結果は、ディレクトリＤＩＲで指定される対応システムの状態の自動的推移（ＳＩＧＮ−ＯＮからＩＮ−ＤＯＵＢＴへの）を伴う。不成功の結果の場合には、システム回復手順全体が、ディレクトリＤＩＲのタイムアウト・フィールドＴＯで定義される時間間隔だけ延期される。

Ｃ−ＳＹＳ ＩＮ−ＤＯＵＢＴステップでは、対応システムから生じる可能な未確定情況が、検出され、解決される。未確定情況は、拡張リソース・マネージャが、対応システムに関して発行された一般ＯＢＲ／ＸＯＢＲの結果を獲得するか一義に解決することができなかった情況である。未確定情況の解決は、次のＣ−ＳＹＳ ＢＡＣＫＯＵＴステップに必須であり、このＣ−ＳＹＳ ＢＡＣＫＯＵＴステップでは、エラーを生成した回復可能ＯＢＲに関連する未解決のＵＯＷまたは延期されたＵＯＷが、分析され、詳述される。たとえば、対応システムがシャット・ダウンするか、それへの通信リンクがＯＢＲの実行中にダウンする場合に、拡張リソース・マネージャは、対応システムの状態が確認される（Ｃ−ＳＹＳ ＳＩＧＮ−ＯＮステップで）まで、そのＯＢＲを未確定とみなす。

未確定情況の解決は、異常な状況にかかわる各ＯＢＲ／ＸＯＢＲの結果の判定と、コンテキスト的に生成された応答メッセージ（存在する場合に）の獲得をもたらす。異常な情況とは、拡張リソース・マネージャが応答メッセージを獲得できなくするイベントを意味し、異常な情況は、ＯＢＲ／ＸＯＢＲの処理の失敗または対応システムによって引き起こされる全般的なエラーに起因する可能性がある。

ディレクトリＤＩＲに存在する情報に基づいて、未確定情況の解決を管理する特定の手順が、識別され、アクティブ化され、特定の手順が識別されない場合には、拡張リソース・マネージャが、接続性サービスによって提供されるデフォルト・アクションを実行する。未確定情況の解決について、Ｃ−ＳＹＳ ＳＩＧＮ−ＯＮステップで折衝されたＯＢＲ／ＸＯＢＲ識別コードを活用することができる。

拡張リソース・マネージャが、ログ・アーカイブに存在する情報に基づいて、動作が対応システムで実行されたかどうか、その結果、およびどの応答メッセージが生成されたかを確認できる場合に、未確定情況は解決されたとみなされる。対応システムとの接続を管理する責任を負うコネクタ（たとえばディレクトリ・フィールドＣＮＣＴ ＩＤで指定される）に応じて、未確定情況を解決する異なるモードが、拡張リソース・マネージャに提供され、たとえば、ＯＢＲ／ＸＯＢＲ識別子コードを使用して、コネクタが、対応システムによって実行された最後の動作を知るために対応システムに質問することができ、あるいは、対応システムが、ＯＢＲ／ＸＯＢＲが実行されたかどうかを明示的に要求される時に、「終了」または「元に戻された」を応答できるものとすることができる。

ＩＮ−ＤＯＵＢＴステップの成功裡の結果は、対応システムの状態を、自動的にＩＮ−ＤＯＵＢＴからＢＡＣＫＯＵＴに変更させる。不成功の結果の場合に、システム回復手順全体が、ディレクトリで定義される時間間隔だけ延期される。システム回復手順が、すべての対応システムで実行される、未確定情況が、一部の対応システムだけについて解決可能である時には、解決可能なシステムが、次のステップに進む。

Ｃ−ＳＹＳ ＢＡＣＫＯＵＴステップでは、拡張リソース・マネージャが、対応システムに関して発行されたＯＢＲに関係する保留中のまたは未解決のＵＯＷを識別する。これらのＵＯＷが識別されたならば、その補償が試みられるか否かは、カタログ作成サービスＣＡＴＳおよびディレクトリ・サービスＤＩＲＳによって提供される情報に依存する。具体的に言うと、補償は、ＥＲＯＢＲについて試みられるが、ＩＲＯＢＲについては試みられない。さらに、カタログ・フィールドＳＴ−ＵＰ ＳＴＡＴおよびＩＮ−ＦＬＧＴ ＳＴＡＴで定義されるＸＯＢＲの状態が検証され、状況がＯＦＦである場合には、そのＸＯＢＲは発行されない。

補償タスクのアクティブ化は、タスク回復サービスＴＳＲによって管理されるタスク回復手順で行われる。

各ＵＯＷが補償される形は、次の変数に基づいて決定される。
・システム回復手順のアクティブ化の原因（システムＳＹＳの開始あるいは異常な情況または未確定情況の発生）。これは、システムＳＹＳおよびシステム回復手順を呼び出したコンポーネントの状態から判定される
・システムＳＹＳの再始動モード（コールドまたはウォーム）
・ＵＯＷに含まれる各ＯＢＲの補償モーダリティ（暗黙または明示）
・単一のＵＯＷに含まれる対応システム、ならびに回復アクティビティの処理および問題エスカレーション・パラダイムのそれぞれのモーダリティ（ＡＳＹＳ、ＳＳＹＳなど）
・システム・マネージャ・コンポーネントを介して発行される、ＵＯＷ／ＯＢＲのパージの可能な一方的なコマンド
・ＯＢＲの各補償ステップの結果：前の補償ステップの結果に依存して、補償アクティビティは、進行できるか、延期され、後に再開されるか、割り込まれるか、早期完了される。

これらの変数は、階層的に獲得される。各ＯＢＲの属性（カタログＣＡＴで指定される）は、対応システムの属性（ディレクトリＤＩＲで指定される）に従属し、最高の優先順位は、システム・マネージャ・コンポーネントを介して強制されるすべてのものに割り当てられる。この形で、補償手順を処理する形を区別できて、異常なイベントの制御または克服あるいはその両方を対象とする広範囲の挙動が可能になる。

ＵＯＷに、ＮＲＯＢＲ、ＥＲＯＢＲ、およびＩＲＯＢＲを含めることができる。通常、ＮＲＯＢＲは、照会サービス要求であり、明示的補償の対象ではない。

ＥＲＯＢＲだけを有するＵＯＷに関して、これらは、すべてのＥＲＯＢＲが補償された（ＸＯＢＲによって）時に補償されたとみなされる。次の補償モーダリティが設けられる。
・ＡＳＹＳモーダリティ ＵＯＷの保留中ＯＢＲのすべてが、元の実行シーケンスと逆のシーケンスで補償される。各補償ステップは、先行する補償ステップの適用結果の対象である。ＵＯＷは、拡張リソース・マネージャによって動的に判定されるシーケンスが成功裡に完了した時に、解決されたと見なされる。対応システムは、すべての関連するＵＯＷが解決された時に、ＢＡＣＫＯＵＴ状態からＶＥＲＩＦＹ状態に移る。この相で検出される不成功の結果またはエラー状態は、補償手順の延期または割込みを引き起こす。この場合に、ＵＯＷにかかわる対応システムは、システム・マネージャ・コンポーネントを介する介入が行われるか、ディレクトリＤＩＲで問題エスカレーション・シーケンスが定義され（後で説明する「ＳＳＹＳ」モーダリティ、「ＢＳＹＳ」モーダリティ、または「ＢＥＲＲ」モーダリティへの移動を引き起こす）ない限り、エラーと宣言され、Ｃ−ＳＹＳ ＢＡＣＫＯＵＴステップを通過できない。
・「ＳＳＹＳ」モーダリティ（システム再始動時に適用されるデフォルト・モーダリティ） ＵＯＷの保留中ＯＢＲが、そのＯＢＲが向けられる対応システムに従ってグループ化される。ＯＢＲの各グループは、元の実行シーケンスと比較して逆のシーケンスでの、すべての動作の結果に従属する補償の対象になる。ＯＢＲの各グループは、拡張リソース・マネージャによって動的に判定される、シーケンスの成功裡の完了時に解決されたとみなされる。ＵＯＷは、ＯＢＲのすべてのグループが成功裡に完了した時に解決されたとみなされる。その後、対応システムは、Ｃ−ＳＹＳ ＶＥＲＩＦＹステップに移る。この相で検出される不成功の結果またはエラー状態は、補償シーケンスの延期または割込みを引き起こす。この場合に、対応システムは、システム・マネージャ・コンポーネントを介する介入が行われるか、ディレクトリで問題エスカレーション・シーケンスが定義され、「ＢＥＲＲ」モーダリティへの移動が引き起こされない限り、エラーと宣言され、Ｃ−ＳＹＳ ＢＡＣＫＯＵＴステップを通過できない。
・「ＢＳＹＳ」モーダリティ ＵＯＷの保留中のＯＢＲのすべてが、元の実行シーケンスと逆のシーケンスで補償され、各補償ステップは、前の補償ステップの適用結果に従属する。ＵＯＷは、拡張リソース・マネージャによって動的に判定されるシーケンスが成功裡に完了した時に、解決されたと宣言される。不成功の結果または異常なイベントが発生する場合には、シーケンスが修正されて、不成功の結果を引き起こしたＯＢＲと同一の対応システムに向けられたＯＢＲのすべての補償が延期される。そのような対応システムは、エラーと宣言され、システム・マネージャ・コンポーネントを介する介入が行われない限り、Ｃ−ＳＹＳ ＢＡＣＫＯＵＴ相を通過できない。エラーと宣言されない対応システムは、次のＣ−ＳＹＳ ＶＥＲＩＦＹに移ることができる。
・「ＢＥＲＲ」モーダリティ このモーダリティでは、単一の対応システムによる進行の代わりに、補償が単一の動作によって進行する。ＵＯＷの保留中のＯＢＲのすべてが、元の実行シーケンスと比較して逆のシーケンスで補償され、各補償ステップは、前の補償ステップの結果と独立に実行される。ＵＯＷは、拡張リソース・マネージャによって動的に判定される補償ステップのシーケンスが成功裡に完了した時に、解決されたと宣言される。補償ステップが、不成功の結果をもたらすか、異常なイベントが発生する場合には、かかわるＯＢＲの補償が延期され、シーケンス内のそれに続くＯＢＲが、補償にサブミットされる。エラーになったＯＢＲに関連する対応システムは、エラーと宣言され、システム・マネージャ・コンポーネントを介する介入が行われない限り、Ｃ−ＳＹＳ ＢＡＣＫＯＵＴステップを通過できず、そうでない場合には、対応システムは、次のＣ−ＳＹＳ ＶＥＲＩＦＹステップに移る。

ＩＲＯＢＲだけを含むＵＯＷについて、直接の補償アクションは行われない。補償は、ＮＲＯＢＲまたはＩＲＯＢＲを発行したビジネス要求の次の再アクティブ化まで延期される。関連するＵＯＷのすべてが、延期される。かかわる対応システムは、次のＣ−ＳＹＳ ＶＥＲＩＦＹステップに移ることができる。

ＥＲＯＢＲおよびＩＲＯＢＲの両方を含むＵＯＷは、ＥＲＯＢＲに関して前に説明した補償の対象になるが、ＩＲＯＢＲについて、直接の補償アクションは行われない。すべてのＥＲＯＢＲが成功裡に解決される場合に、ＵＯＷは、保証されたまたは延期されたと宣言され、深刻な異常が発生する場合には、ＵＯＷがエラーと宣言される。エラーが発生しない場合に、ＩＲＯＢＲの補償は、上で述べたように、それを発行したビジネス要求の次の再アクティブ化まで延期され、かかわる対応システムは、Ｃ−ＳＹＳＴＥＭ ＶＥＲＩＦＹステップに移ることができる。エラーのＥＲＯＢＲの存在は、補償アクティビティの延期を引き起こし、関連する対応システムは、システム・マネージャ・コンポーネントを介する介入が行われない限り、Ｃ−ＳＹＳ ＶＥＲＩＦＹステップに進むことができない。

すべてのバックアウト・アクティビティが完了した時、すなわち、すべての保留中ＵＯＷが解決されるか、システム・マネージャの介入によって強制された時、またはその明示的補償が対応システムによって実行される保留中ＯＢＲを有する保留中ＵＯＷがない場合に、対応システムは、Ｃ−ＳＹＳ ＶＥＲＩＦＹステップに進むことができる。Ｃ−ＳＹＳ ＶＥＲＩＦＹステップに進めない対応システムは、Ｃ−ＳＹＳ ＢＡＣＫＯＵＴステップの延期された再アクティブ化の対象になる。不成功の結果がもう一度発生する場合に、システム回復手順全体が、ディレクトリ・フィールドＴＯで指定される時間間隔だけ延期される。

Ｃ−ＳＹＳ ＶＥＲＩＦＹステップでは、システムＳＹＳは、対応システムまたはＯＢＲが向けられたシステムに関して実行された動作の論理的コヒーレンスを検証する。ディレクトリ・フィールドＶＥＲに保管された情報に基づいて、Ｃ−ＳＹＳ ＶＥＲＩＦＹステップを管理する特定の手順（検証手順）が、識別され、アクティブ化される。検証手順は、検証アクティビティを実行するために、拡張リソース・マネージャにサービス（ＮＲＯＢＲの形）を要求することができる。これらのアクティビティに、対応システムに向けられるＯＢＲの識別子コードの獲得／折衝と、システムＳＹＳと対応システムがまだアラインされていることを検証するための、Ｃ−ＳＹＳ ＳＩＧＮ−ＯＮステップで獲得／折衝された識別子コードとの獲得／折衝されたコードの比較を含めることができる。その代わりに、ＯＢＲ識別子の獲得／折衝を、Ｃ−ＳＹＳ ＳＩＧＮ−ＯＮステップで実行せず、このステップでのみ実行することができる。各ＯＢＲは、要求または受け取られた応答あるいはその両方に関連する識別子コードを拡張リソース・マネージャに宣言して、識別子コードとＢＲＩＤの自動関連付けを可能にするか、拡張リソース・マネージャによって実行された自動関連付けを受け入れることができる。特定の手順がディレクトリＤＩＲで宣言されていない場合には、拡張リソース・マネージャは、接続性サービスによって実施されるデフォルト・アクションを実行する。

Ｃ−ＳＹＳ ＶＥＲＩＦＹステップの成功裡の結果によって、ＶＥＲＩＦＹ状態からＲＥＡＤＹ（ＯＮ）状態への対応システムの状態の自動推移が決定される。不成功の結果の場合に、システム回復手順全体が、ディレクトリ・フィールドＴＯで指定される指定された時間間隔だけ延期される。

Ｃ−ＳＹＳ ＲＥＡＤＹ相には、一般ＯＢＲおよびＸＯＢＲの両方によって形成されるアプリケーション・トラフィックを管理する対応システムの可用性を確認した後に進入する。ＲＥＡＤＹ状態に達した時に、対応システムのディレクトリ・フィールドＣ−ＳＹＳ ＩＮ−ＦＬＧＴ ＳＴＡＴにＯＮがセットされ、対応システムは、新たに発行されたＯＢＲおよび実行を待っているすべてのもの（前に延期され、拡張リソース・マネージャによってもう一度要求されているので）の両方を処理する。ビジネス要求マネージャは、まだ待っているか、対応システムが使用可能でないことに起因して前に遅延されたＰＣＢＲＳを再起動する。具体的に言うと、ＯＢＲは、拡張リソース・マネージャＥＲＭによって対応システムに関連するコネクタ（ディレクトリ・フィールドＣＮＣＴ ＩＤで指定される）に向けられ、監視サービスおよびログ・サービスによって監視される。エラーの場合に、リソース・マネージャ・コーディネータＲＭＣによって調整される拡張リソース・マネージャが、可能な補償アクティビティを処理する。対応システムは、深刻な誤動作、未確定事例、対応システムの使用不能（たとえば、対応システム／接続リンク障害に起因する）によってトリガされるシステム回復手順の再アクティブ化まで、またはシステム・マネージャ・コンポーネントを介して対応システムが強制的にＳＴＯＰ状態にされるまで、ＲＥＡＤＹ状態に留まる。

ビジネス要求保護サービスＢＲＰＲ
このサービスは、ビジネス要求マネージャＢＲＭによって、ＰＣＢＲを自動的に再アクティブ化するのに活用される。具体的に言うと、このサービスは、ビジネス要求キューイングを管理する。

ビジネス要求検証サービスＢＲＶＲ
このサービスは、ＰＣＢＲと異なる、まだ完了していない同一のビジネス要求が、不注意で１回または複数回再提案されていないことを検証するために、ビジネス要求マネージャＢＲＭによって活用される。このサービスは、カタログ作成サービスＣＡＴＳによって提供される情報に基づいて、すべての場合のビジネス要求の処理をイネーブルし（デフォルト条件）、ビジネス要求の処理に割り込み、前の試みがエラーの包括的条件に起因して割り込まれた場合にビジネス要求の処理をイネーブルし、ビジネス要求に応答して前の結果／応答メッセージを返すことができる。ビジネス要求の識別は、コンテキスト依存（入力メッセージ・データ）とするか、発行された時にビジネス要求に関連した一意のユーザ識別子に基づくものとすることができる。

ビジネス要求検証サービスは、再アクティブ化される時にＩＲＯＢＲを管理するために、拡張リソース・マネージャＥＲＭによっても活用される。

接続性サービスＣＮＣＴ
このサービスには、複数のコネクタ・コンポーネントが含まれ、拡張リソース・マネージャＥＲＭは、これらのコネクタ・コンポーネントを活用して、所望の対応システムとの接続リンクを確立する。適当なコネクタは、時々、カタログＣＡＴＳおよびディレクトリＤＩＲに保管された情報に基づいて判定される。コネクタは、複数の機能を実行し、特に、システムＳＹＳと対応システムの間の通信を管理し、コネクタは、通信プロトコルおよびメッセージ・フォーマットの変換も実行することができる。

具体的に言うと、コネクタの入出力情報は、次の通りである：
ａ）ＯＢＲ呼び出しの場合（コネクタ・アクティブ化につながるアクションのシーケンスが、ＢＲｃａｌｌ→ＥＲＭ→ＣＮＣＴ→ＯＢＲＡＰＰＬｅｘｅｃである）：
コネクタ入力：ディレクトリ・データ、ＯＢＲ ＩＤ、［ＯＢＲ識別子／カウンタ］、［ＣＴＸＴデータ］
コネクタ出力：ＯＢＲ応答メッセージ、物理／論理結果、［ＯＢＲ識別子／カウンタ］
ｂ）ＸＯＢＲ呼び出しの場合（コネクタ・アクティブ化につながるアクションのシーケンスが、ＥＲＭｃａｌｌ→ＸＢＲｃａｌｌ→ＥＲＭ→ＣＮＣＴ→ＸＯＢＲＡＰＰＬｅｘｅｃである）：
コネクタ入力：ディレクトリ・データ、ＸＯＢＲ ＩＤ、ＸＯＢＲ入力データ、ＯＢＲ入力／応答／結果データ、［ＯＢＲ ＣＴＸＴ／ＡＮＮＬデータ］、［ＸＯＢＲ／ＯＢＲ識別子／カウンタ］、［前のＸＯＢＲ入力／応答／結果］
コネクタ出力：ＸＯＢＲ応答メッセージ、ＸＯＢＲ物理／論理結果、［ＸＯＢＲ識別子／カウンタ］
ｃ）システム回復手順のＣ−ＳＹＳ ＳＩＧＮ−ＯＮステップ、Ｃ−ＳＹＳ ＩＮ−ＤＯＵＢＴステップ、およびＣ−ＳＹＳ ＶＥＲＩＦＹステップでの呼び出しの場合（コネクタ・アクティブ化につながるアクションのシーケンスが、ＥＲＭｃａｌｌ→[ディレクトリ内のＵｓｅｒＰｒｏｇ→］ＣＮＣＴ→［ＯＢＲＡＰＰＬｅｘｅｃ］である）：
Ｃ−ＳＹＳ ＳＩＧＮ−ＯＮステップおよびＣ−ＳＹＳ ＶＥＲＩＦＹステップでの呼び出しの場合：
コネクタ入力：ディレクトリ・データ、［ローカルＯＢＲ／ＸＯＢＲ識別子／カウンタ］
コネクタ出力：物理／論理結果、［折衝されたＯＢＲ／ＸＯＢＲ識別子／カウンタ］
Ｃ−ＳＹＳ ＩＮ−ＤＯＵＢＴステップでの呼び出しの場合：
コネクタ入力：ディレクトリ・データ、ＯＢＲ／ＯＢＲ：入力データ、［識別子／カウンタ］、［ＣＴＸＴ／ＡＮＮＬデータ］
コネクタ出力：ＯＢＲ／ＸＯＢＲ：物理／論理結果、［応答メッセージ］、［識別子／カウンタ］
ただし、大括弧内のデータはオプションである。

監視サービスＭＯＮ
このサービスは、トランザクション・マネージャに発行されたコマンドをインターセプトし、そのコマンドをビジネス要求マネージャにルーティングする。ビジネス要求マネージャは、カタログ作成サービスＣＡＴＳを活用し、どのインフラストラクチャ・コンポーネント（ビジネス要求マネージャ自体、ＯＢＲの拡張リソース・マネージャ、またはＮＣＢＲのトランザクション・マネージャ）がそのコマンドを処理するかを決定する。

トランザクション・マネージャＴＭを、これから説明する。

システムＳＹＳが開始される時に、システム開始手順が起動される。システム開始手順は、ビジネス要求マネージャＢＲＭおよび拡張リソース・マネージャＥＲＭをアクティブ化し、このインフラストラクチャ・コンポーネントの可用性についてトランザクション・マネージャＴＭおよびリソース・マネージャ・コーディネータＲＭＣに通知し、サービス・プロバイダ・サブシステムＳＥＲもアクティブ化される。

開始手順は、リソース・マネージャ・コーディネータＲＭＣから情報、特に保留中ＵＯＷのリストも獲得する。このリストに基づいて、拡張テーブル・マネージャＥＲＭは、ログ・アーカイブをスキャンし、マトリックスを生成し、このマトリックスでは、保留中ＵＯＷごとに、かかわるＸＯＢＲおよび対応システムが示される。システム回復サービスＳＹＳＲが呼び出され、マトリックス内の対応システムごとに、システム回復手順がアクティブ化され、このシステム回復手順は、ディレクトリＤＩＲで指定される情報に基づいて実行される。システム回復手順は、前に説明したステップの指定されたシーケンスが対応システムごとに実行されたならば、完了する。

タスク回復サービスＴＳＲが、呼び出される。マトリックスのＵＯＷごとに、タスク回復手順がアクティブ化される。しかし、このタスク回復手順は、ＵＯＷに用いられる対応システムが状態ＢＡＣＫＵＯＴ（ＵＯＷがＥＲＯＢＲも含む場合）または状態ＲＥＡＤＹ（ＵＯＷがＩＲＯＢＲを含む場合）になる時まで延期される。

タスク回復サービスＴＳＲは、まだ保留中のタスクを再アクティブ化するのに活用される。タスク回復サービスによって実行されるタスク回復手順は、ビジネス要求マネージャＢＲＭが、ログ・サービスＬＯＧのアーカイブに保管された情報に基づいて、まだ完了していないＰＣＢＲを識別できるようにし、このＰＣＢＲは、再アクティブ化される必要がある。

トランザクション・マネージャＴＭは、通常はウォームまたはコールドと称する２つのモードのいずれかで開始することができる。コールド・モードでは、ウォーム・モードと異なって、タスクは、前のシステム・シャット・ダウンが処理されず、したがって補償されない後でも保留中であり、システム回復手順のＣ−ＳＹＳ ＢＡＣＫＯＵＴステップは、ＥＲＯＢＲに関して実行されない。

ウォーム開始の場合に、ビジネス要求マネージャＢＲＭは、前のシステム・シャットダウン時にまだ完了していないかキューに入れられていた（遅延されていた）ＰＣＢＲを再アクティブ化する。拡張リソース・マネージャＥＲＭは、システム・シャットダウン時にまだ完了していなかったか未解決の（すなわち未確定の）ＯＢＲを管理する。

システム回復手順が完了したならば、システムＳＹＳならびに対応システムＣ−ＳＹＳ１およびＣ−ＳＹＳ２が、同期化され、保留中のビジネス要求を再発行できると同時に、新しいビジネス要求を受け入れることができる。

システムＳＹＳのシャットダウン時に、トランザクション・マネージャＴＭは、ビジネス要求マネージャＢＲＭおよび拡張リソース・マネージャＥＲＭにシャット・ダウンを通知する。ビジネス要求マネージャＢＲＭおよび拡張リソース・マネージャＥＲＭは、新しいサービス要求を拒否するか、新しいサービス要求をビジネス要求保護サービスＢＲＰＲによって管理されるキューに入れることができる。新しいビジネス要求がＰＣＢＲである場合に、その要求は、受け入れられ、ビジネス要求キューに入れられ、できる限り速くサービスされる。ビジネス要求がＮＰＣＢＲの場合には、拒否される。

ビジネス要求マネージャＢＲＭは、処理中のトランザクションが完了するのを待つ。拡張リソース・マネージャＥＲＭは、前にエラーであったかバック・アウトされたＵＯＷに関連する可能な補償アクティビティの完了を待つ。

対応システムについてディレクトリＤＩＲのタイムアウトが経過した場合またはシステムＳＹＳの強制シャットダウンの場合で、処理中のトランザクションあるいは前にエラーであったかバック・アウトされたＵＯＷの補償アクティビティを完了できない場合に、システムＳＹＳの次の開始時に、システム回復手順およびタスク回復手順が再実行され、その結果、ビジネス要求マネージャＢＲＭおよび拡張リソース・マネージャＥＲＭが、ＰＣＢＲおよび保留中のＵＯＷを再始動できるようになる（トランザクション・マネージャＴＭがウォーム・モードで再始動されるならば）。

システムＳＹＳの動作中に、拡張リソース・マネージャＥＲＭが、一般ＯＢＲによって生成される応答／結果メッセージを入手せず、ログ・アーカイブに保管しない場合に、未確定情況が確立される。他のアクティビティに先立って、未確定情況を解決しなければならない。未確定をもたらしたすべてのＯＢＲのアクティブ化および完了に関する情報を取り出すために、拡張リソース・マネージャＥＲＭは、ＯＢＲに関連するコネクタ（ディレクトリＤＩＲで指定される）をアクティブ化する。

具体的には、拡張リソース・マネージャＥＲＭは、ＯＢＲの識別子コードを活用して、次の検査を実行する。

まず、拡張リソース・マネージャは、ＯＢＲがアクティブ化されていることを確認する。そうでない場合に（たとえば、上で述べたキューイング機構の結果として）、ＯＢＲは、実行されていないとみなされ、アクティブ化メッセージ（存在する場合に）が削除される。したがって、未確定情況が解決され、システムが、必要な場合に補償アクティビティを実行できるようになる。未確定ＯＢＲがＥＸＴ−ＵＯＷ内で唯一のＯＢＲである場合には、補償アクティビティも必要でない。

その代わりに、ＯＢＲがアクティブ化されていると確認される場合に、拡張リソース・マネージャは、ＯＢＲがまだ実行中であるかどうかを確認する。これは、ＯＢＲを発行した主タスクがタイムアウトを尊重しなければならない時に発生する可能性がある。この場合に、ＯＢＲの完了および応答メッセージ／結果の獲得を待つことが可能であり、あるいは、ＯＢＲを打ち切り、エラーと宣言して、バックアウト相のＯＢＲの結果を取り消すことができる。したがって、未確定情況が解決され、システムが、補償アクティビティを実行できるようになり、この補償アクティビティは、強制的に打ち切られたＯＢＲが回復不能リソースを使用した場合に必要になる。

拡張リソース・マネージャが、ＯＢＲの完了を待つ場合には、それからの論理結果が検証される。ＯＢＲ応答メッセージ／結果は、ＯＢＲのアクティブ化に採用されるプロトコルの性質に応じて、使用可能な場合とそうでない場合がある。応答メッセージ／結果の獲得は、補償アクティビティの決定を単純にするのに有用である。

応答メッセージ／結果がない場合に、ＯＢＲは形式的に正しく実行される結果になるが、論理結果の処理に関する情報がなく、処理が対応システムによってどのように分類されたかに関する情報がない。この情報は、通常は応答メッセージに含まれる。応答メッセージ／結果の獲得によって、アプリケーションまたはインフラストラクチャ内部コーディングに基づく、用いられるコネクタまたはＸＢＲによって直接に解釈される、サービス要求の論理結果を判定できるようになる。結果に基づいて、ＯＢＲが期待される結果を作ったかどうかを確立でき、したがって、補償相が必要であり、あるいは、失敗またはバックアウト要求の場合には補償アクティビティが不要である。

応答メッセージ／結果を獲得できない場合には、ＯＢＲが、自動的に補償にサブミットされ、あるいは、システム回復手順が開始される。

ＯＢＲが打ち切られ、回復可能リソースだけが用いられた場合に、補償相は必要でない。そうではなく、ＯＢＲが回復不能リソースを使用した場合には、そのＯＢＲによって操作された変更（部分的であっても）が存在する可能性があるので、未確定情況は部分的にのみ解決される。この場合に必要な補償相の前に、打ち切られる前にそのＯＢＲによってどれが部分的に行われたかの予備的検証を行うことができる。この情況は、ＸＯＢＲに関連するコネクタのアクティブ化の際に、拡張リソース・マネージャによって通知される。

未確定情況の解決の間接的サポートを、システム回復手順のアクティブ化によって得ることができ、これには、予備的なＣ−ＳＹＳ ＳＩＧＮ−ＯＮステップおよび最終的なＣ−ＳＹＳ ＶＥＲＩＦＹステップが含まれ、その間に、対応システムごとに、対応システムとシステムＳＹＳの間の再割り当てを処理することが可能である。この形で、対応システムに向けられるＯＢＲの識別子コードが、獲得／折衝され、獲得／折衝された識別コードを活用して、それに向けられた／完了した最後の動作に関する情報を対応システムから獲得することが可能であり、したがって、対応システムから取り出された情報に基づく未確定事例の自動的解決が可能である。

未確定情況を自動的に解決できない場合に、一般ユーザ／システム・マネージャを直接的に含むことができ、このマネージャは、必要な検査を実行した後に、各未確定情況をシステムによってどのように処理するかの指示を提供する。すなわち、未確定情況は、ＯＢＲが実行をもたらさず、補償が不要なので解決されたとみなされ、あるいは、未確定情況は、ＯＢＲが部分的にのみ実行をもたらし、解決を必要とするので解決されたとみなされる。

未確定情況を解決する形は、異なるタイプのＯＢＲに共通するが、各ＯＢＲの異なる性質が、次の補償相（その相が必要な場合に）のシステム挙動に影響する。ＯＢＲの実行およびその結果を確認した後に、補償アクションは、次のようになる。
・ＮＲＯＢＲ これらのＯＢＲは、一般に照会サービス要求に関連するが、どの補償アクションにもサブミットされない。可能な未確定情況の解決は、オプションである。システム全体の正しい動作を検証することが有用である可能性はあるが、ＯＢＲ実行および可能な場合の応答メッセージ／結果の獲得は、次の詳述をトリガしない。
・ＩＲＯＢＲ これらのＯＢＲは、照会サービス要求と修正サービス要求の両方に関連する。後者の場合に、可能な未確定情況の解決が必須である。直接の補償アクションは行われない。ＯＢＲを発行したビジネス要求の可能な再詳述によってトリガされる再詳述に、応答メッセージ／結果の獲得の相中に拡張リソース・マネージャによってログ記録されるすべてのものの獲得または対応システムによる再詳述に向けられたＯＢＲの直接アクティブ化と、そのような再詳述の応答メッセージ／結果の管理が含まれる。
・ＥＲＯＢＲ これらのＯＢＲは、通常は、リソースに対する変更を伴う。可能な未確定情況の解決は、必須である。補償アクティビティは、関連するＸＯＢＲの直接アクティブ化または関連するＸＢＲのアクティブ化からなる。
・ＸＯＢＲ これらのＯＢＲは、用いられるＸＢＲによって発行され、システムによってＩＲＯＢＲのように扱われる。可能な未確定情況の解決は、必須である。ＸＯＢＲの実行中に生じたエラーは、拡張リソース・マネージャＥＲＭによって暗黙のうちに補償され、あるいは、ＸＯＢＲまたはＸＢＲの詳述フローへの割込みが、拡張リソース・マネージャＥＲＭによって自動的に処理され、再アクティブ化される。前に成功裡に終了したＸＯＢＲは、実行されたとみなされ、それぞれの応答メッセージ／結果が、次の補償アクションを決定するのに使用される。実行されなかったＸＯＢＲは、再アクティブ化され、その結果、対応システムが、それらを詳述でき、期待される応答メッセージ／結果を作れるようになる。ＸＢＲのアクティブ化には、補償されるＯＢＲおよび前に要求／実行されたものの通知が、関連する応答メッセージ／結果と共に付随する。ＸＢＲは、アーカイブまたはプロセスに直接に向けられた特定のアクティビティの直接実行または延期された実行を介して補償相に進行することができる。

ＥＸＴ−ＵＯＷの正しい管理は、普通のトランザクション管理システムで採用されるものと異なるシステム・リソース割り当て判断基準を必要とする。

ＥＸＴ−ＵＯＷの場合の保全性の問題を減らすために、接続性サービスＣＮＣＴは、時々各タスクのレベルで定義される論理リソースのシリアライズを対象とする、アクティビティのキューイングを実施する。キューイングのタイプおよびその持続時間に応じて、タスクは、それに論理的に関連するリソースの制御を獲得し、タスクが完了するまで、または適当な場合に補償相が完了するまで、その制御を保つことができる。

具体的に言うと、ビジネス要求マネージャおよび拡張リソース・マネージャは、論理エンティティの定義を可能にし、それへのアクセスを管理する。各論理エンティティは、定義されたならば、各タスクによって要求されるアクセスのタイプに基づいて、１つまたは複数のタスクによって獲得することができる。論理エンティティのタイプおよび要求されたアクセスのタイプに応じて、使用の次の排他的／非排他的権利（ＬＯＣＫ）を、タスクに割り当てることができる。
・タスクに割り当てられる排他的アクセス権および他のタスクのキューイング。キューイングは、たとえば「先入れ先出し」（ＦＩＦＯ）タイプである
・タスクに割り当てられる修正での排他的アクセス権（読取アクセス権が他のタスクに割り当てられる）および変更を要求する他のすべてのタスクのキューイング（たとえばＦＩＦＯ）

各ＬＯＣＫの有効性の時間は、論理エンティティのタイプおよびサービスを要求するタスクの性質に依存して変化する可能性がある。具体的には、次の時間ウィンドウが設けられる。
・ＴＡＳＫ時間ウィンドウ タスクによる論理エンティティの使用の権利は、要求が発行された時からそのタスクの終了までアクティブのままになる
・ＵＯＷ時間ウィンドウ 要求が発行された時から特定のＵＯＷの完了までアクティブ
・ＥＸＴ−ＵＯＷ時間ウィンドウ 要求が発行された時から、可能な補償相を含めて関係するＵＯＷのすべての完了までアクティブ。各ＵＯＷが、単一相または２相のコミット・プロトコルに準拠するＵＯＷとしてトランザクション・マネージャＴＭおよびリソース・マネージャ・コーディネータＲＭＣに既知であるが、異なるＵＯＷが直接に相関しない場合であっても、拡張リソース・マネージャＥＲＭが、ビジネス要求の処理中にシステムによって実施されるＥＸＴ−ＵＯＷを構成するＵＯＷを相関できることに留意する価値がある
・ＳＹＳＴＥＭ時間ウィンドウ 要求が発行された時から、そのシステムに向けられるすべての可能な補償アクティビティの完了を含めて、特定のリモート・システムの検出可用性までアクティブ
・ＧＥＮＥＲＩＣ時間ウィンドウ 要求が発行された時から、デキューの明示的コマンドが発行されるまでアクティブ

トランザクション処理システムの動作の例を、図８に概略的に示す。トランザクション・マネージャＴＭが、分類されたビジネス要求ＣＢＲとしてカタログにリストされたビジネス要求ＢＲを受け取ると仮定する。そのビジネス要求をサービスするタスクＴ１が、ＵＯＷ ＵＯＷ１を伴ってアクティブ化される。タスクＴ１の処理中に、ＯＢＲ ＯＢＲ１がまず発行され、対応システムＣ−ＳＹＳ１およびＣ−ＳＹＳ２の１つに向けられ、ＯＢＲ ＯＢＲ１をサービスするタスクＴ２が、作業単位ＵＯＷ２を伴って対応システムでアクティブ化される。タスクＴ２が成功裡に終了する時に、ＵＯＷ ＵＯＷ２がコミットされる。タスクＴ１は、第２のＯＢＲ ＯＢＲ２を発行し、同一のまたは別の対応システムに向ける。タスクＴ３が、その対応システムで開始され、ＵＯＷ ＵＯＷ３内のサービス要求を処理する。タスクＴ３が成功裡に完了する時に、ＵＯＷ ＵＯＷ３がコミットされる。

この時に、まだ処理中のＵＯＷ ＵＯＷ１のバックアウト要求が、リソース・マネージャ・コーディネータＲＭＣによって受け取られると仮定する。リソース・マネージャ・コーディネータＲＭＣは、拡張リソース・マネージャＥＲＭを呼び出し、拡張リソース・マネージャＥＲＭは、可能な場合にシステムを初期状態に戻し、さもなければシステムを別のコヒーレントな状態にするために、バックアウト・アクティビティまたは補償アクティビティを管理する。また、トランザクション・マネージャＴＭによって受け取られたビジネス要求が、カタログ内に、関連するＸＢＲ ＸＢＲを有すると仮定する。ＸＢＲ ＸＢＲが呼び出され、ＵＯＷ ＵＯＷ４に関連するタスクＴ４がアクティブ化される。ＵＯＷ ＵＯＷ２およびＵＯＷ３の補償を実行するために、前に実行されたアクションが、逆のシーケンスで実行される。ＸＯＢＲ ＯＢＲ−２およびＯＢＲ−１が、順番に発行され、対応システムでそれぞれのタスクＴ５およびＴ６のアクティブ化を引き起こし、タスクＴ５およびＴ６の処理に、ＵＯＷ ＸＵＯＷ５およびＸＵＯＷ６の補償が含まれる。タスクＴ５およびＴ６の両方が成功裡に完了し、したがってＵＯＷ ＸＵＯＷ５およびＸＵＯＷ６がコミットされる時に、ＵＯＷ ＵＯＷ２およびＵＯＷ３は、補償済みである（この相で送出されるすべてのエラー状態は、補償相の割込みを強制し、待機中のタスクＴ１は、積極的に延期されるか、イベントについて通知されるか、異常終了することができる。補償アクティビティだけが延期され、新しいＸＢＲがインスタンス化され、失敗したＸＯＢＲが開始され、システムによってＩＲＯＢＲのように扱われる）。ＵＯＷ ＵＯＷ１は、この時までまだ処理中であるが、したがって、バック・アウトされ、終了する。

タスクＴ１は、ビジネス要求ＢＲの処理に進む、新しいＵＯＷ ＵＯＷ７に入る。ＵＯＷ ＵＯＷ７中に、新しいＯＢＲ ＯＢＲ３が、タスクＴ１によって発行され、対応システムの１つに向けられる。タスクＴ７が、その対応システムで、ＵＯＷ ＵＯＷ８内のＯＢＲ ＯＢＲ７をサービスするために起動される。タスクＴ７が成功裡に終了する時に、ＵＯＷ ＵＯＷ８およびＵＯＷ７がコミットされる。したがって、ビジネス要求ＢＲがサービスされており、応答メッセージが、ビジネス要求ＢＲを発行したアプリケーションに返される。

要約すると、本発明は、コミット／バックアウト・プロトコルに準拠する新しいビジネス・プロセスを開発し、管理し、個別にコミット／バックアウト・プロトコルに準拠するまたは準拠しない既存のプロセスを活用できるようにする方法およびシステムを提供する。具体的には、新しいビジネス・プロセスの開発で、新しいビジネス・プロセスのコンポーネント（ビジネス要求、ＯＢＲ、ＸＢＲ、ＸＯＢＲ、およびコネクタ）を識別しなければならない。ビジネス・ロジックは、ビジネス要求のレベルに置かれなければならない。補償ビジネス・ロジック（指定される場合に）は、ＸＢＲまたはコネクタのレベルに置かれなければならない。統合ロジックは、コネクタのレベルに置かれなければならない。代替案で、統合ロジックを、ＸＢＲおよびビジネス要求のレベルで分散する。データ解析は、ビジネス要求のレベル、または、不可能な場合に、コネクタのレベルに置かれなければならない。ネットワーク・インフラストラクチャ・レベルでの通信結果は、コネクタによって処理されなければならない。ビジネス要求の論理結果は、ビジネス要求によって、ＸＢＲによって、またはコネクタによって生成されなければならない。

本発明を、いくつかの実施形態によって開示したが、請求項で定義される本発明の範囲から逸脱せずに、本発明の説明した実施形態ならびに他の実施形態に対する複数の修正が可能であることを、当業者は諒解するであろう。

本発明の実施形態によるトランザクション管理システムの主要な構成要素を示す概略ブロック図である。 図１のトランザクション管理システムのリソース・マネージャ・コーディネータによる作業単位の管理を概略的に示す図である。 図１のトランザクション管理システムのリソース・マネージャ・コーディネータによる作業単位の管理を概略的に示す図である。 図１のトランザクション管理システムのサービス・プロバイダ・サブシステムによって提供されるサービスを概略的に示す図である。 サービス・プロバイダ・サブシステムによって提供されるビジネス要求カタログ作成サービスによって保持されるビジネス要求カタログを概略的に示す図である。 サービス・プロバイダ・サブシステムによって提供されるディレクトリ・サービスによって保持される対応システム・ディレクトリを概略的に示す図である。 サービス・プロバイダ・サブシステムによって提供されるシステム回復サービスによって実施されるシステム回復手順を概略的に示す図である。 トランザクション管理システムの動作を概略的に示す図である。

Claims (24)

1. コミット／バックアウト・プロトコルに従ってそれぞれのシステム・リソースへの変更を管理する少なくとも１つのリソース管理手段（ＲＭ）と、
   前記少なくとも１つのリソース管理手段のコミット／バックアウト・アクティビティを調整する調整手段（ＲＭＣ）と
   を含むデータ処理システムであって、
   前記コミット／バックアウト・プロトコルに準拠しない非準拠プロセスの実行を管理するプロセス・リソース管理手段（ＥＲＭ）
   を含み、前記プロセス・リソース管理手段が、前記コミット／バックアウト・プロトコルに従って前記調整手段によって調整され、バックアウト要求を受け取ったことに応答して、前記非準拠プロセスの実行中に実行されたアクションをバックアウトするために実行すべき補償アクションのシーケンスを自動的に決定し、前記補償アクションの実行を管理する
   ことを特徴とするデータ処理システム。
2. 補償アクションの前記シーケンスは、逆アクションのシーケンスであり、各逆アクションが、前記非準拠プロセスの前記実行中に実行されたそれぞれのアクションの逆である、請求項１に記載のデータ処理システム。
3. バックアウト要求を受け取ったことに応答して、前記補償アクションが、前記調整手段によって調整されて、前記リソース管理手段の前記バックアウト・アクティビティと並列に実行される、請求項１に記載のデータ処理システム。
4. バックアウト要求を受け取ったことに応答して、前記補償アクションが、前記リソース管理手段の前記バックアウト・アクティビティに関して延期される、請求項１に記載のデータ処理システム。
5. 前記プロセス・リソース管理手段が、１つの作業単位または複数の相関する作業単位のいずれかに関連する少なくとも１つのタスクによる前記非準拠プロセスおよび前記補償アクションの実行を管理する、請求項１に記載のデータ処理システム。
6. 少なくとも１つの前記非準拠プロセスの実行中に実行されるアクションに関する情報を記録する情報記録サービス（ＬＯＧ）を含み、前記プロセス・リソース管理手段が、前記情報記録サービスによって記録された前記情報に基づいて補償アクションの前記シーケンスを自動的に決定する、請求項１に記載のデータ処理システム。
7. 補償アクションの前記シーケンスは、前記データ処理システムを、前記非準拠プロセスによって前記アクションが実行される前の前記システムの初期状態に対応する第１システム状態と、前記システムの初期状態と異なる第２システム状態との間の１つにし、前記第２システム状態は、前記情報記録サービスによって記録された前記情報に基づいて、前記プロセス・リソース管理手段によって判定される、請求項６に記載のデータ処理システム。
8. 実行されるプロセスを分類し、プロセスが非準拠プロセスであるかどうかを判定するプロセス分類サービス（ＣＡＴＳ、ＣＡＴ、ＢＲＭ）を含む、請求項７に記載のデータ処理システム。
9. 前記分類サービスが、プロセス・タイプのカタログを提供するプロセス・カタログ（ＣＡＴ）であって、前記カタログ内の前記プロセス・タイプごとに、前記プロセス・リソース管理手段による前記記録された情報に基づく補償アクションの前記シーケンスの自動的判定を可能にする情報を提供するプロセス・カタログ（ＣＡＴ）を含む、請求項８に記載のデータ処理システム。
10. 前記プロセス・タイプは、バックアウト要求の受取に応答して、前記プロセス・リソース管理手段が補償アクションの前記シーケンスを直接にアクティブ化するのではなく、前記プロセスの次の再起動を待つ第１プロセス・タイプを含む、請求項９に記載のデータ処理システム。
11. プロセスの前記実行中に発行されたバックアウト要求を管理するプロセス回復手順を実施するプロセス回復サービス（ＴＳＲ）を含む、請求項６に記載のデータ処理システム。
12. プロセスの前記実行中に発生するエラー状態を管理するエラー回復手順を実施するエラー回復サービス（ＥＲＲ）を含む、請求項６に記載のデータ処理システム。
13. 前記エラー回復手順が、前記情報記録サービスによって提供される前記情報に依存する、請求項１２に記載のデータ処理システム。
14. 前記エラー回復手順が、プロセス回復手順を実行することを含む、請求項１３に記載のデータ処理システム。
15. 前記非準拠プロセスが、少なくとも１つの別個のデータ処理システム（Ｃ−ＳＹＳ１、Ｃ−ＳＹＳ２）で稼動するプロセスおよび前記データ処理システムで稼動するが前記コミット／バックアウト・プロトコルに準拠しないプロセスの中の少なくとも１つを含む、請求項１に記載のデータ処理システム。
16. 前記データ処理システムと前記少なくとも１つの別個のデータ処理システムとの間の同期ポイントを確立するシステム回復手順を実施するシステム回復サービス（ＳＹＳＲ）を含む、請求項１５に記載のデータ処理システム。
17. 前記システム回復手順が、前記プロセス・リソース管理手段によって呼び出される、請求項１６に記載のデータ処理システム。
18. 前記システム回復手順が、前記データ処理システムの開始に応答して呼び出される、請求項１７に記載のデータ処理システム。
19. 前記システム回復手順が、前記データ処理システムと前記少なくとも１つの別個のデータ処理システムとの間の折衝相を含み、前記折衝相が、前記別個のデータ処理システムに向けられる前記プロセスの識別情報を折衝することを含む、請求項１６に記載のデータ処理システム。
20. 前記データ処理システムと前記少なくとも１つの別個のデータ処理システムとの間の通信を管理する、前記プロセス・リソース管理手段によって活用される接続性サービス（ＣＮＣＴ）を含む、請求項１５に記載のデータ処理システム。
21. プロセスの自動的再実行を管理するサービスを含む、請求項１に記載のデータ処理システム。
22. トランザクションを管理するトランザクション・マネージャ・システム（ＴＭ）を含む、請求項１乃至２１のいずれか一項に記載のデータ処理システム。
23. 第１トランザクション管理システム
    を含む、トランザクションを管理するデータ処理システムであって、前記第１トランザクション管理システムが、
    それぞれがコミット／バックアウト・プロトコルに従ってそれぞれのシステム・リソースを管理する責任を負う複数のリソース管理手段と、
    前記リソース管理手段のコミット／バックアウト・アクティビティを調整する調整手段と
    を含み、
    リソース管理手段として働き、前記第１のシステムと別個の少なくとも１つの第２トランザクション管理システムによって実行されるトランザクションに関して前記調整手段によって調整され、前記少なくとも１つの第２のシステムによって実行されるトランザクションのバックアウト・アクティビティを管理する、プロセス・リソース管理手段
    を含むことを特徴とするデータ処理システム。
24. コミット／バックアウト・プロトコルに従ってそれぞれのシステム・リソースに対する変更を管理する少なくとも１つのリソース管理手段（ＲＭ）を設けることおよび、
    前記少なくとも１つのリソース管理手段のコミット／バックアウト・アクティビティを調整する調整手段（ＲＭＣ）を設けること
    を含む、前記コミット／バックアウト・プロトコルに準拠する準拠プロセスを前記コミット／バックアウト・プロトコルに準拠しない非準拠プロセスと統合する方法であって、
    前記コミット／バックアウト・プロトコルに従って前記調整手段によって調整され、前記非準拠プロセスの実行を管理し、前記非準拠プロセスの前記実行中に実行されたアクションをバックアウトするためにバックアウト要求の受取に応答して実行すべき補償アクションのシーケンスを自動的に決定し、前記補償アクションの実行を管理する、プロセス・リソース管理手段（ＥＲＭ）を設けること
    を含むことを特徴とする方法。

Images