トランザクションモニター

トランザクションモニターとは



トランザクションモニター（トランザクションマネージャ、トランザクションコーディネータとも呼ばれる）は、複数のコンピュータシステムにまたがるトランザクションを管理するミドルウェアです。具体的には、アプリケーションプログラムと、データベースやファイルシステムといった永続性のあるデータストレージ（資源管理）の間で、データの整合性を保ちながら処理を実行します。トランザクションは、複数の操作を不可分な単位として扱うことで、データの矛盾を防ぐ役割を担います。トランザクションモニターは、トランザクションのACID特性（原子性、一貫性、独立性、永続性）を保証し、分散環境におけるデータの信頼性を高めます。

概要



トランザクションモニターは、異なるシステム間でのトランザクションを管理します。例えば、銀行のオンライン取引では、預金の引き落としと口座への入金を同時に行う必要があります。この一連の操作は、トランザクションとして扱われ、トランザクションモニターによって、どちらかの操作が失敗した場合、すべてが元の状態に戻されることが保証されます。トランザクションモニターは、複数の「資源管理」にまたがる処理単位であるトランザクションに必要なACID特性を保持する役割を担い、TPモニタとも呼ばれます。

X/Openモデルの「トランザクション管理」や、WS-Transactionモデルの「トランザクション調整者」と同義ですが、X/Openモデルに従わない狭義の「トランザクション管理」は、個別の「資源管理」内部のローカルトランザクションを指すことがあります。そのため、「トランザクションモニター」という場合、複数の「資源管理」、または複数ノードの「資源管理」にまたがる分散トランザクションを管理する独立したプログラムモジュールを指すことが一般的です。

各「資源管理」がローカルトランザクションを管理し、トランザクションモニターがそれらを束ねて分散トランザクションを管理します。さらに、トランザクションモニターは別のコンピュータノードのトランザクションモニターと連携して、外部組織との分散トランザクションも実現します。これは、異なる企業間でデータを交換するような対外的な商業トランザクションにおいて必須の機能です。たとえ、ローカルトランザクションで分散データベースを実現しても、それは同じデータベーススキーマを共有する社内システムに過ぎず、対外的な分散トランザクションは実現できません。異なるベンダーのデータベースを直接共有することは技術的にもセキュリティ上も困難です。

初期のTPモニタは、アプリケーションサーバ、トランザクション管理、トランザクション資源をすべて一体化して集中トランザクションを実行していましたが、分散トランザクション技術の進歩に伴い、これらの機能は分離され、それぞれが分散配置できるようになりました。今日のトランザクションモニターは、複数のノードを連携させてACIDトランザクションを実現するモジュールを指します。

歴史



初期のトランザクションモニターは、各システムごとに個別に開発されていたため、開発規模が大きく、業務のコンピュータ化を妨げる要因となっていました。IBMのIMSやCICSは、集中トランザクション用のモニタとして製品化され、この状況を大きく改善しました。IMSは、アポロ計画における納品物管理で使用され、高信頼性通信セッションとしてメッセージキューを使用し、階層型データベース（IMS-DB）を提供しました。CICSは、アプリケーションサーバに近い機能を提供し、UIとアプリケーションプログラムのフロントエンドを管理し、バックエンドのIMSに処理をさせるのが一般的でした。これらの製品をきっかけに、各汎用機ベンダーが、それぞれのOSに特化したトランザクションモニタを提供するようになりました。

分散トランザクション機能は、1970年代までのTPモニタには装備されていませんでした。1970年代後半から分散トランザクションの研究が進み、1980年代に商業TPモニタにも実装されるようになりました。ジム・グレイが1978年に発表した2相コミットプロトコルは、今日のTPモニタに広く採用されています。IBMは、独自の通信規格SNAのLU6.2内に2相コミットプロトコルを実装し、自社TPモニタ間の分散トランザクションを実現しました。しかし、異機種間でのトランザクションを実現するため、プロトコルやプログラムインタフェースの標準化が進められました。X/Openモデルは、1990年から93年にかけて発表され、業界標準となりました。

UNIXサーバとTCP/IPの普及、インターネットの発展に伴い、X/Openモデルに準拠したトランザクションモニターが各ベンダーから製品化されました。BEA社のTuxedo、日立のOpenTP1、NECのTPBASEなどが代表的なものです。また、これらのTPモニタは、Webサービスベースの分散トランザクション業界標準にも対応しつつあります。

Webアプリケーションサーバ



Webシステムの進展に伴い、Webアプリケーションサーバにトランザクションモニターの機能が組み込まれるようになりました。しかし、Webアプリケーションサーバは、サーバ側JavaアプリケーションとWebブラウザベースのシンクライアント間のUI処理を主に担当し、バックエンドとの連携は、必ずしもWebサービスベースの分散トランザクション業界標準に対応していません。

WebサービスによるSOA



今日では、Webベースの分散トランザクション業界標準が提唱されており、TCP/IP上のXMLをプレゼンテーション層として利用し、ロールバック対応の2相コミットプロトコルが基本となっています。これは、X/Openモデルで曖昧だった対外接続用の分散トランザクションを、特定の言語や製品のRPCから分離し、標準化しようとするものです。アプリケーション言語やOSに依存しないように規定されています。

OASISは、2007年5月8日にWebサービス・トランザクション（WS-Transaction）バージョン1.1をOASIS標準として批准しました。

X/Openモデルの問題点とWS-Transaction バージョン1.1での改善



X/Openモデルはプログラムモジュールとインタフェースを定義していましたが、WS-Transaction Version1.1は、XMLメッセージと状態遷移でSOAPプロトコルを定義します。WS-Transaction Version1.1は、X/Openモデルよりも無駄な部分が削除され、本質的な部分が単純化されています。マルチベンダー環境での利用を考慮したモデリングとなっています。

WS-Transaction Version1.1（WS-TX）は、WS-Coordination層の上に、WS-AtomicTransaction（WS-AT）またはWS-BusinessActivity（WS-BA）のプロトコルまたはサービスを選択して利用します。WS-ATは、リアルタイムなACIDトランザクション用の2相コミットプロトコルを規定し、WS-BAは、非同期なロングトランザクションの終結プロトコルを規定します。

資源管理 (RM)



本来、トランザクション資源とは永続性記憶資源ですが、X/OpenではUI端末も資源としていたため混乱がありました。WS-TX1.1では、永続性記憶資源のみを制御対象としています。分散データベースや分散ファイルシステム、遠隔キューなどは、独自の遠隔分散資源を実現していますが、これらは標準規格の範囲外のアプリケーションプログラムと資源管理間のAPIとして扱われます。WS-ATでは、資源管理は調整者の配下で永続性2相コミットプロトコルに参加します。

トランザクション管理 (TM)



分散トランザクションの状態管理を行う本体です。X/OpenでもWS-TX1.1でも機能は同じですが、WS-TXではTMを調整者（coordinator）と呼び、調整者自体がWebサービスとして調整サービスを提供します。アプリケーションプログラムは、トランザクション開始時に各ノードのローカル調整者にトランザクションの活性化とプロトコルの登録を行います。調整者は、トランザクション実行中に、同一ノードのローカル参加者（RMまたはAP）との間で、X/OpenモデルのXAインタフェース相当のサービスを提供します。

通信資源管理 (CRM)



X/Openモデルでは、遠隔資源を管理するものすべてをCRMとしてTPモニタに含めていましたが、問題がありました。特に、アプリケーションサーバとUI端末間をつなぐ機能は、ベンダ固有のプロトコルに依存していたため、標準化できませんでした。また、遠隔TM同士を結ぶCRMとTM間のインタフェースはXA+インタフェースとして標準化されていましたが、遠隔CRM間の通信は、特定のTPモニタ製品に依存していました。WS-TX1.1では、TM（調整者）間を結ぶプロトコルは標準化されていません。ベンダー独自のプロトコルが認められており、マルチベンダーを実現するためには、信頼できる仲介調整者を使うことが推奨されています。WS-TX1.1では、TM間を除く通信や遠隔資源管理を行わず、大幅に単純化されました。例えば、サーバ側アプリケーションとUI端末間をつなぐCRMはWS-TX1.1の範囲外となり、アプリケーションサーバに任せられます。

アプリケーションプログラム (AP)



X/Openでは、分散アプリケーションのモデルが曖昧でした。特に、UIのように遠隔アプリケーション間の通信もTPモニタのCRMとしていましたが、マルチベンダーを実現できませんでした。WS-Transactionでは、分散トランザクションの開始と終了に関するもののみを規定し、アプリケーション依存の通信は規定しません。WS-ATでは、リアルタイムなACID分散トランザクションの開始と終了に関する手順のみを規定し、トランザクション実行中の遠隔アプリケーション間の通信は、アプリケーション側で決定します。WS-ATのアプリケーションプログラムは、要求者（Initiator）と参加者（Participant）の両方になれます。WS-BusinessActivityでは、ロングトランザクション用の分散アプリケーション間の終結プロトコルのみを規定しています。

WS-Transaction Version1.1 から見たまとめ



WS-Transaction Version1.1モデルは、通信資源管理（CRM）を含んでいません。ベンダー依存のアプリケーションサーバ機能や分散データベース機能、アプリケーション依存の通信は、WS-TXの範囲外とされています。また、調整者間の通信プロトコルも標準化されていません。WS-ATでは、RMとAPを区別せずに参加者にすることができ、合理化が進んでいます。トランザクションを起動する側のAPは要求者となり、TXインタフェース相当のものが現れます。X/Openモデルでは、AP、TM、RMモジュール間の静的なインタフェースと誤解されていたTX、XAインタフェースは、分散トランザクション内の要求者と参加者の立場の違いであることが明確にされました。

市販されているトランザクションモニター




関連項目



もう一度検索

【記事の利用について】

タイトルと記事文章は、記事のあるページにリンクを張っていただければ、無料で利用できます。
※画像は、利用できませんのでご注意ください。

【リンクついて】

リンクフリーです。