編集この記事には独自研究が含まれているおそれがあります。問題箇所を検証し出典を追加して、記事の改善にご協力ください。議論はノートを参照してください。(2015年12月)トランザクションモニター(トランザクションマネージャ、トランザクションコーディネータとも)とは、各種通信プロトコル上のセッションとその上に流れるデータとアプリケーションプログラムと永続性記憶資源(トランザクショナルなファイルやデータベース)間での不可分な処理単位であるトランザクションを監視し、その一貫性を保持する役目を担うトランザクション管理ミドルウェアのこと。(トランザクショナルなキューやファイルシステムやデータベース等)間で分散トランザクションを実現するプログラムモジュール。(ACID特性)を保持する役目を担うプログラムモジュール。coordinator)と同義語。X/Openモデルに従わない、狭い意味での「トランザクション管理」は個別の「資源管理」内部のローカルトランザクションを実現する部分とされることもあるので注意が必要。そこで「トランザクションモニター」と言えば、個別の「資源管理」の外部で、複数の「資源管理」または複数ノードの「資源管理」にまたがる対外的な分散トランザクションを管理する独立したプログラムモジュールを指すことが明確になる。個別のトランザクショナルな「資源管理」が自分自身のローカルトランザクションを管理し、トランザクションモニターたる「トランザクション管理」が複数の「資源管理」を束ねて分散トランザクションを管理する。トランザクションモニターは別のコンピュータノードのトランザクションモニターと連携して外部組織との対外的な分散トランザクションを実現する。したがって対外的な商業トランザクションには必須のモジュールである。個別の「資源管理」内のローカルトランザクションでマルチユーザ分散データベースを実現したとしても、同じデータベーススキームを共有する社内システムに過ぎず、対外的な分散トランザクションを実現できないからである。ベンダーの違う自社と他社のデータベースを直接、共有して、検索や更新することは技術的にも不可能だし、セキュリティ上も実現困難である。対外的な商業トランザクションでは異なるベンダーのトランザクションモニター間で分散トランザクションを実行する必要がある。初期のTPモニタは今日のアプリケーションサーバ、トランザクション管理、トランザクション資源をすべて一体化して集中トランザクションだけを実行していた。その後、分散トランザクション技術が、徐々に実現されるにつれ、別々のモジュールとして分離され、現在ではそれらの要素はすべて別の遠隔コンピュータノードで分散されうる。トランザクションモニターの機能は各システム単位で作り込んでおり、その膨大な開発規模は、各種業務のコンピューティング化に大きな障害となっていた。この煩雑な処理を個々のシステムで開発するのではなく、一つの体系化・製品化して売り出したのが、集中トランザクション用モニタのIBMのIMSやCICSである。1969年に登場したCICSは、今日のアプリケーションサーバに近い機能を分担し、UIとアプリケーションプログラムのフロントエンド周りを管理し、バックエンドのIMSに処理をさせるのが一般的であった。どちらのTPモニタも永続性記憶資源にはメインフレームのファイルを用いることができ、RDBMSが登場後はDB2も使用できた。これらの製品をきっかけに、各汎用機ベンダーがそれぞれのOSに特化したトランザクションモニタを提供している。II(郵政省簡易保険システムを念頭に開発)、日立製作所のTMS4V(日本国有鉄道(現JR)座席予約システムを念頭に開発)がある。分散トランザクション機能編集1970年代までのTPモニタは分散トランザクション機能を装備していなかった。ローカルトランザクションと分散トランザクションが未分化であったが、1970年代後半から分散トランザクションの研究が進展して、1980年代に商業TPモニタにも実装されるようになる。1978年に分散トランザクションのアトミックコミットメントプロトコルである2相コミットプロトコルを発表しており、今日のTPモニタに例外なく実装されている。IBMでは80年代当初、2相コミットプロトコルを独自の通信規格SNAのLU6.2内に実装し、自社TPモニタ間の分散トランザクションを実現した。分散トランザクションでは異機種間トランザクションを実現しなければならないので各種プロトコルやプログラムインタフェースが標準化された。プログラムインタフェースでは1990年から93年にかけてX/Openモデルが発表されて業界標準となっている。X/Openモデルでも遠隔サイト用に特定TPモニタ依存のRPCが多用されており、社外システムの標準ではなかった。準拠したトランザクションモニターが、各ベンダーから製品化された。オープン系トランザクションモニタの著名なものとしては、BEA社のTuxedo、日立のOpenTP1、NECのTPBASEなどがある。IMSやCICSもX/Openモデルに対応している。これらのTPモニタは以下に示すWebサービスベースの分散トランザクション業界標準用のアタッチメントを追加しつつある。Web系システムの進展により、Webアプリケーションサーバに、このトランザクションモニターの機能が付加され、より一般的に利用されるようになっている。Webアプリケーションサーバはサーバ側Javaのアプリケーションプログラムと、Webブラウザベースのシンクライアント間のUI処理を実現するフロントエンドの実行系という意味で使われており、バックエンドとの連携が必ずしも以下に述べるWebサービスベースの分散トランザクション業界標準規格に対応していない。すべての遠隔プログラムインタフェースはRMIなどのJavaのRPCが前提となっている。今日、Webベースの分散トランザクション業界標準規格が提唱されており、TCP/IP上のXMLをプレゼンテーション層として利用し、基本プロトコルはロールバック想定2相コミットプロトコルとなっている。RPCから分離し、標準化しようとしていることになる。アプリケーション言語やOSに依存しないように規定されている。Webサービス・トランザクション(WS-Transaction)バージョン1.1を、同組織の最高位レベルを示すステータスであるOASIS標準として批准した。XMLメッセージと状態遷移でSOAPプロトコルを定義、またはWSDLサービスを定義しているので、モデリングが一致しないが、比較のために、あえて旧来のX/Openモデルの定義にあわせて記述する。X/Openよりも、無駄な部分が削除され、本質的な部分に単純化されて合理化されている。マルチベンダーのTPモニタ間でも何とか使えるモデリングに進化している。プロトコルまたはサービスを選択して利用する。非同期なロングトランザクションの終結プロトコルを規定している。本来のトランザクション資源とは永続性記憶資源であるが、X/Openでは、UI端末も資源としていたために混乱していた。これはサーバアプリケーションと端末画面の遷移をトランザクションと考えた古いTPモニタの名残である。これは根本的にはアプリケーションの状態遷移に帰結する。永続性記憶資源だけを制御対象としている。永続性記憶資源のうち独自に遠隔分散資源を実現している例が分散データベースや分散ファイルシステムや遠隔側にあるキューである。し、そのインタフェースであるベンダ独自のRPCを通信資源管理としてモデル内に含めて混乱していた。資源管理が独自に遠隔資源を実現している部分を標準規格の範疇外のアプリケーションプログラムと資源管理間のAPIとして除外している。WS-ATでは資源管理は調整者の配下で永続性2相コミットプロトコルに参加する参加者になる。機能的には同じである。層で調整者(coordinator)と呼んでいる。service)を提供する。アプリケーションプログラムがトランザクションを開始するに当たって各ノードのローカル調整者にトランザクションの活性化とプロトコルの登録を行う。どちらのプロトコルを使うかの設定についてもアプリケーション間の通信によって設定する。XAインタフェース相当のサービスを提供する。モデルでは遠隔資源を管理するものは何でもかんでもCRMとしてTPモニタに含めた為に問題だった。アプリケーションサーバとUI端末間をつなぐ機能もCRMとされたが、プロトコルもインタフェースも特定ベンダ商品に依存していたので標準に値しなかった。遠隔TM同士を結ぶCRMとTM間のインタフェースはXA+インタフェースとして標準化されていたが、遠隔CRM間の通信は特定TPモニタ製品に依存した通信プロトコルだったので、マルチベンダは実現困難だった。(調整者)間を結ぶプロトコルは標準化されていない。ベンダ独自プロトコルが認められており、マルチベンダの実現のためには信頼できる仲介調整者を使うこととされている。TM間で標準化されたのは遠隔APがTMを設定する手順だけであり、曖昧さが残る。TM(調整者)間を除く通信や遠隔資源管理を行わず、大幅に単純化された。範疇ではなく、外部のアプリケーションサーバに任せる。XA+インタフェース相当部分も出てこない。WS-TX1.1自身に相当し、基本的にTPモニタにCRMを含まないモデルになっている。アプリケーションプログラムが分散しているときのモデルが曖昧だった。上で示したUIのように遠隔アプリケーション間通信もTPモニタのCRMにしたが、マルチベンダーを実現できないものだったので、標準とは言えなかった。アプリケーション間通信においても分散トランザクションの開始と終了に関するものだけを規定し、アプリケーション依存の通信は規定しない。リアルタイムなACID分散トランザクションの開始と終了に関する手順だけを規定している。WS-ATのアプリケーションプログラムは要求者(Initiator)と参加者(Participant)の双方になれる。要求者はフロントエンドでACIDトランザクションを起動し、コミットするアプリケーションであり、参加者はバックエンドでサービスを提供する側のアプリケーションである。ACIDトランザクションの分散アプリケーションが実現できる。AP参加者は調整者の配下で揮発性2相コミットプロトコルに参加し、遠隔ノードの永続性記憶資源に対して書き込んだ後、該当遠隔ノードの資源管理が永続性2相コミットプロトコルにより結果を永続化する。ロングトランザクション用の分散アプリケーション間の終結プロトコルだけを規定している。その他の分散アプリケーション間通信は規定されない。ロングトランザクションを構成する個別のACIDトランザクション内は外部に公開するものではないので、上の段落で述べたようにアプリケーションプログラム側で独自に決めてよい。実際のロングトランザクションの終結は著しくアプリケーションに依存する。ベンダ依存のアプリケーションサーバ機能(端末画面を制御する機能)や分散データベース機能やアプリケーション依存の通信はWS-TXの範疇にない。これらは別の(標準化)体系に含まれるAPIとされる。間の通信プロトコルは標準化されていない。これはAPの状態変化を永続化させる対象がRMなので一歩前進の合理化である。参加者側のノードではAPインタフェースにもX/OpenモデルのXAインタフェース相当が現れる代わりにTXインタフェースが出てこない。なり、TXインタフェース相当が出てくる代わりにXAインタフェースは現れない。X/OpenモデルではAP,TM,RMモジュール間の静的なインタフェースと誤解されていたTX,XAインタフェースが分散トランザクション内の要求者と参加者の立場の違いであることが明確にされた。3.0のもとで利用可能です。プライバシーデスクトップ。