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

トランザクションモニター（トランザクションマネージャ、トランザクションコーディネータとも）とは、各種通信プロトコル上のセッションとその上に流れるデータとアプリケーションプログラムと永続性記憶資源（トランザクショナルなファイルやデータベース）間での不可分な処理単位であるトランザクションを監視し、その一貫性を保持する役目を担うトランザクション管理ミドルウェアのこと。

概要

各種コンピュータシステムにおいて、ユーザおよびアプリケーションと複数の永続性記憶「資源管理」（トランザクショナルなキューやファイルシステムやデータベース等）間で分散トランザクションを実現するプログラムモジュール。すなわち複数「資源管理」にまたがる処理単位であるトランザクションに必要な原子性・一貫性・独立性・永続性・（ACID特性）を保持する役目を担うプログラムモジュール。TPモニタとも言う。

X/Openモデルの「トランザクション管理」（Transaction Manager）または WS-Transaction モデルの「トランザクション調整者」（WS-Transaction coordinator）と同義語。

ただし、X/Openモデルに従わない、狭い意味での「トランザクション管理」は個別の「資源管理」内部のローカルトランザクションを実現する部分とされることもあるので注意が必要。そこで「トランザクションモニター」と言えば、個別の「資源管理」の外部で、複数の「資源管理」または複数ノードの「資源管理」にまたがる対外的な分散トランザクションを管理する独立したプログラムモジュールを指すことが明確になる。

個別のトランザクショナルな「資源管理」が自分自身のローカルトランザクションを管理し、トランザクションモニターたる「トランザクション管理」が複数の「資源管理」を束ねて分散トランザクションを管理する。さらにトランザクションモニターは別のコンピュータノードのトランザクションモニターと連携して外部組織との対外的な分散トランザクションを実現する。

したがって対外的な商業トランザクションには必須のモジュールである。たとえ個別の「資源管理」内のローカルトランザクションでマルチユーザ分散データベースを実現したとしても、同じデータベーススキームを共有する社内システムに過ぎず、対外的な分散トランザクションを実現できないからである。ベンダーの違う自社と他社のデータベースを直接、共有して、検索や更新することは技術的にも不可能だし、セキュリティ上も実現困難である。さらに対外的な商業トランザクションでは異なるベンダーのトランザクションモニター間で分散トランザクションを実行する必要がある。

初期のTPモニタは今日のアプリケーションサーバ、トランザクション管理、トランザクション資源をすべて一体化して集中トランザクションだけを実行していた。その後、分散トランザクション技術が、徐々に実現されるにつれ、別々のモジュールとして分離され、現在ではそれらの要素はすべて別の遠隔コンピュータノードで分散されうる。今日のトランザクションモニタは複数のノードを結びつけてACIDトランザクションを実現するモジュールを指す。

歴史

初期

当初、トランザクションモニターの機能は各システム単位で作り込んでおり、その膨大な開発規模は、各種業務のコンピューティング化に大きな障害となっていた。

この煩雑な処理を個々のシステムで開発するのではなく、一つの体系化・製品化して売り出したのが、集中トランザクション用モニタのIBMのIMSやCICSである。IMSはアポロ計画における納品物管理に使用され、不揮発性のメッセージキューを高信頼性通信セッションとして使い、階層型データベース (IMS-DB) を提供してトランザクションを管理するTPモニタ (IMS-DC = IMS TM) である。一方、1969年に登場したCICSは、今日のアプリケーションサーバに近い機能を分担し、UIとアプリケーションプログラムのフロントエンド周りを管理し、バックエンドのIMSに処理をさせるのが一般的であった。どちらのTPモニタも永続性記憶資源にはメインフレームのファイルを用いることができ、RDBMSが登場後はDB2も使用できた。これらの製品をきっかけに、各汎用機ベンダーがそれぞれのOSに特化したトランザクションモニタを提供している。

IMSと同等の機能を提供している汎用機のトランザクションモニターとしては、富士通のAIM（郵便貯金システムを念頭に開発）、NECのVISおよびVIS II（郵政省簡易保険システムを念頭に開発）、日立製作所のTMS4V（日本国有鉄道（現JR）座席予約システムを念頭に開発）がある。

分散トランザクション機能

1970年代までのTPモニタは分散トランザクション機能を装備していなかった。すなわち、ローカルトランザクションと分散トランザクションが未分化であったが、1970年代後半から分散トランザクションの研究が進展して、1980年代に商業TPモニタにも実装されるようになる。一例としてジム・グレイ (James Nicholas "Jim" Gray) が1978年に分散トランザクションのアトミックコミットメントプロトコルである２相コミットプロトコルを発表しており、今日のTPモニタに例外なく実装されている。

IBMでは80年代当初、２相コミットプロトコルを独自の通信規格SNAのLU6.2内に実装し、自社TPモニタ間の分散トランザクションを実現した。しかし、分散トランザクションでは異機種間トランザクションを実現しなければならないので各種プロトコルやプログラムインタフェースが標準化された。プログラムインタフェースでは1990年から93年にかけてX/Openモデルが発表されて業界標準となっている。ただし、X/Openモデルでも遠隔サイト用に特定TPモニタ依存のRPCが多用されており、社外システムの標準ではなかった。

その後、進展したダウンサイジングによるUNIXサーバとTCP/IPの浸透、インターネットの広がりにより、X/Openモデルに準拠したトランザクションモニターが、各ベンダーから製品化された。

オープン系トランザクションモニタの著名なものとしては、BEA社のTuxedo、日立のOpenTP1、NECのTPBASEなどがある。IMSやCICSもX/Openモデルに対応している。またこれらのTPモニタは以下に示すWebサービスベースの分散トランザクション業界標準用のアタッチメントを追加しつつある。

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

一方、Web系システムの進展により、Webアプリケーションサーバに、このトランザクションモニターの機能が付加され、より一般的に利用されるようになっている。ただし、Webアプリケーションサーバはサーバ側Javaのアプリケーションプログラムと、Webブラウザベースのシンクライアント間のUI処理を実現するフロントエンドの実行系という意味で使われており、バックエンドとの連携が必ずしも以下に述べるWebサービスベースの分散トランザクション業界標準規格に対応していない。すべての遠隔プログラムインタフェースはRMIなどのJavaのRPCが前提となっている。

WebサービスによるSOA

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

2007年5月8日に国際標準化コンソーシアム OASISは Webサービス・トランザクション（WS-Transaction）バージョン1.1を、同組織の最高位レベルを示すステータスであるOASIS標準として批准した。

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

X/Openモデルはプログラムモジュールとプログラムインタフェースを定義しているのに対して、WS-Transaction Version1.1 はXMLメッセージと状態遷移でSOAPプロトコルを定義、またはWSDLサービスを定義しているので、モデリングが一致しないが、比較のために、あえて旧来のX/Openモデルの定義にあわせて記述する。WS-Transaction Version1.1 は X/Openよりも、無駄な部分が削除され、本質的な部分に単純化されて合理化されている。マルチベンダーのTPモニタ間でも何とか使えるモデリングに進化している。

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

資源管理( RM：Resource Manager )

本来のトランザクション資源とは永続性記憶資源であるが、X/Openでは、UI端末も資源としていたために混乱していた。これはサーバアプリケーションと端末画面の遷移をトランザクションと考えた古いTPモニタの名残である。しかし、これは根本的にはアプリケーションの状態遷移に帰結する。WS-TX1.1 は永続性記憶資源だけを制御対象としている。

また永続性記憶資源のうち独自に遠隔分散資源を実現している例が分散データベースや分散ファイルシステムや遠隔側にあるキューである。分散データベース機能や分散ファイル機能や遠隔キューと、その外側で実現する分散トランザクション機能は似て非なる機能であるが、旧X/Openモデルでは一部を遠隔永続性記憶資源とし、そのインタフェースであるベンダ独自のRPCを通信資源管理としてモデル内に含めて混乱していた。

WS-TX1.1 は資源管理が独自に遠隔資源を実現している部分を標準規格の範疇外のアプリケーションプログラムと資源管理間のAPIとして除外している。WS-ATでは資源管理は調整者の配下で永続性2相コミットプロトコルに参加する参加者になる。

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

ここが、分散トランザクションの状態管理をする本体であり、X/Open でも WS-TX1.1 でも機能的には同じである。ただし、WS-TX は TM を WS-Coordination 層で調整者（coordinator）と呼んでいる。調整者自体が Webサービスであり調整サービス（coordination service）を提供する。アプリケーションプログラムがトランザクションを開始するに当たって各ノードのローカル調整者にトランザクションの活性化とプロトコルの登録を行う。つまり調整者（TM）間で WS-AtomicTransaction か WS-BusinessActivity のどちらのプロトコルを使うかの設定についてもアプリケーション間の通信によって設定する。調整者はトランザクション実行中に同一ノードのローカル参加者（RMまたはAP）との間で X/Openモデルの XAインタフェース相当のサービスを提供する。

通信資源管理( CRM：Communication Resource Manager )

X/Open モデルでは遠隔資源を管理するものは何でもかんでもCRMとしてTPモニタに含めた為に問題だった。アプリケーションサーバとUI端末間をつなぐ機能もCRMとされたが、プロトコルもインタフェースも特定ベンダ商品に依存していたので標準に値しなかった。また遠隔TM同士を結ぶCRMとTM間のインタフェースはXA+インタフェースとして標準化されていたが、遠隔CRM間の通信は特定TPモニタ製品に依存した通信プロトコルだったので、マルチベンダは実現困難だった。

WS-TX1.1 でも TM （調整者）間を結ぶプロトコルは標準化されていない。ベンダ独自プロトコルが認められており、マルチベンダの実現のためには信頼できる仲介調整者を使うこととされている。TM間で標準化されたのは遠隔APがTMを設定する手順だけであり、曖昧さが残る。

ただし、WS-TX1.1 はTM（調整者）間を除く通信や遠隔資源管理を行わず、大幅に単純化された。たとえばサーバ側アプリケーションとUI端末間をつなぐ CRM は WS-TX1.1 の範疇ではなく、外部のアプリケーションサーバに任せる。アプリケーションサーバがバックエンドサーバにトランザクションを起動するところから WS-TX1.1 の範疇となる。X/Openモデルの XA+インタフェース相当部分も出てこない。残りの機能が WS-TX1.1自身に相当し、基本的にTPモニタにCRMを含まないモデルになっている。

アプリケーションプログラム（AP:Application Program）

X/Open ではアプリケーションプログラムが分散しているときのモデルが曖昧だった。たとえば上で示したUIのように遠隔アプリケーション間通信もTPモニタのCRMにしたが、マルチベンダーを実現できないものだったので、標準とは言えなかった。WS-Transaction はアプリケーション間通信においても分散トランザクションの開始と終了に関するものだけを規定し、アプリケーション依存の通信は規定しない。

WS-TX1.1 内の WS-AT ではリアルタイムなACID分散トランザクションの開始と終了に関する手順だけを規定している。分散トランザクション実行中の遠隔アプリケーション間の通信はアプリケーション側で決めるもので、 WS-AT では規定しない。WS-ATのアプリケーションプログラムは要求者（Initiator）と参加者（Participant）の双方になれる。要求者はフロントエンドでACIDトランザクションを起動し、コミットするアプリケーションであり、参加者はバックエンドでサービスを提供する側のアプリケーションである。すなわちACIDトランザクションの分散アプリケーションが実現できる。AP参加者は調整者の配下で揮発性2相コミットプロトコルに参加し、遠隔ノードの永続性記憶資源に対して書き込んだ後、該当遠隔ノードの資源管理が永続性2相コミットプロトコルにより結果を永続化する。

WS-TX1.1 内の WS-BusinessActivity ではロングトランザクション用の分散アプリケーション間の終結プロトコルだけを規定している。その他の分散アプリケーション間通信は規定されない。もちろんロングトランザクションを構成する個別のACIDトランザクション内は外部に公開するものではないので、上の段落で述べたようにアプリケーションプログラム側で独自に決めてよい。複数のACIDトランザクションを実行したまま完了するか、補償トランザクションを実行して取り消すかを WS-BusinessActivity で規定している。実際のロングトランザクションの終結は著しくアプリケーションに依存する。

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

WS-Transaction Version1.1 モデルは通信資源管理 (CRM：Communication Resource Manager) を含んでいない。すなわちベンダ依存のアプリケーションサーバ機能（端末画面を制御する機能）や分散データベース機能やアプリケーション依存の通信はWS-TXの範疇にない。これらは別の（標準化）体系に含まれるAPIとされる。また調整者 (coordinator) 間の通信プロトコルは標準化されていない。

WS-ATではRMとAPを区別せずに参加者 (Participant) にできる。これはAPの状態変化を永続化させる対象がRMなので一歩前進の合理化である。参加者側のノードではAPインタフェースにもX/OpenモデルのXAインタフェース相当が現れる代わりにTXインタフェースが出てこない。一方でトランザクションを起動する側のAPは要求者 (Initiator) となり、TXインタフェース相当が出てくる代わりにXAインタフェースは現れない。X/OpenモデルではAP,TM,RMモジュール間の静的なインタフェースと誤解されていたTX,XAインタフェースが分散トランザクション内の要求者と参加者の立場の違いであることが明確にされた。

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

OpenTP1
CICS
IMS
Jakarta EEサーバ (JTA) がトランザクションモニターとして動作
Oracle Tuxedo
Windows（MS DTCサービス）

概要

歴史

初期