こんにちは、最近執筆が多く首が回らなくなってきた岩崎です。さて、今回はサービス指向とトランザクションとの関係について、「重要です」という話をひとつ致します。

ここで言うトランザクションとは、生な「取引」という意味ではなく、情報(データ)に対する操作においてのACIDトランザクションの話になります。ACID(エイシッド)とは、ある処理がトランザクションとみなせるために満たすべき4つの条件である、原子性(Atomicity)、一貫性(Consistency)、独立性(Isolation)、 永続性(Durability)、の頭字語になります。難しい話はさておき、大量の情報を、同時にドンドン処理しても、情報が壊れずに(メチャクチャにならずに)格納できる、という、業務システムではごく当たり前の処理の話です。

バッチ処理 VS オンライン型トランザクション処理

このトランザクション処理、厳密にはオンライン型トランザクション処理(On-Line Transaction Process)と呼ばれます。以前はよくこれを略してOLTP(オーエルティーピー)と呼ばれておりました。この処理は、ホストコンピューターなどで従来行われてきたバッチ処理(つまり、操作情報を溜め込んでおき、誰も使わなくなった後に操作受付を停止させ、更新情報をまとめて一気に書き込みに行く処理)に対して、処理の受付と同時に情報の更新までまとめて行ってしまう、いわゆる逐次処理に当たります。

ところでバッチ処理VSオンライン型トランザクション処理ですが、長期的な傾向として、後者の方に比重が高まりつつあります。以前だと技術的にACID処理をドンドン行う為には性能が問題になりましたが、ハードウェアの高速化とソフトウェアの充実に従い、以前よりもハードルは低くなりました。もちろん、業務の視点からも、画面で指定した瞬間に情報が更新されている方が(ほとんどの場合)良いに決まっている訳です。

単一システム VS 複数システム

これまでの業務システム内でトランザクションという言葉が使われてきたのは、あくまで単一システム(及びそのクラスター構成)内の話が主でした。ところが、サービス指向の設計の話になってくると、物理的なハードウェアを超えて、オンライン型トランザクション処理を行わなければならなくなってきます。

例えば、呼び出し元のシステムから、呼び出し先のシステム(サービス)三つ(イ・ロ・ハ)に対して、更新処理を行う際を考えてみましょう。呼び出し元が処理を開始し、呼び出し先サービスの「イ」を更新、その次に「ロ」を更新、最後に「ハ」を更新に行きました。ところが「ハ」の更新が、何らかの理由で失敗していまいました。さて困った。

この場合、特に先のACIDのA(原子性、つまり実行されたか、またはされなかったか、ふたつにひとつ)の為に、処理そのものを丸ごと取り消す必要があります。これを情報技術の用語では「巻き戻し処理」(英語で言えばロールバック・オペレーション)と言います。これを処理して、失敗した呼び出し先サービス「ハ」の中途更新状況だけでなく、「ロ」・「イ」の更新ですら、すべて無かったことにしてしまわなければなりません。

さて、この「ハ」・「ロ」・「イ」のサービスの取り消し処理、うまくやらないと情報が壊れてしまいます。その為にトランザクション・システムという機能がOSやトランザクション処理(TP)モニター、アプリケーション・サーバーに搭載されています。オンライン型トランザクション処理を行う一般の業務アプリケーションは、(バッチ型の場合やよっぽど古い実装や変な実装を除き)これを利用しながら安全に情報の更新を行っているのではと考えられます。

分散トランザクション処理

ところが、ここからが本題ですが、SOAで前提となる分散型のシステムの場合、この物理的なシステムを超えてオンライン型トランザクション処理を行う為には、そのトランザクション情報を呼び出し元から呼び出し先サービス「イ」・「ロ」・「ハ」に伝達して、全体としてひとつのトランザクション処理を行う必要が出てきます。これは「分散トランザクション」と一般に呼ばれたりします。そして、呼び出し元まで含めた分散トランザクション部分を「グローバルトランザクション」、従来の単一システム内の部分を「ローカルトランザクション」と便宜的に呼ばれたりもします。

図:分散トランザクション処理
図:分散トランザクション処理

従来だとX/Openというコンソーシアムが策定したXAプロトコルというデファクト・スタンダードな規格を用い、二相コミット(Two-Phase Commit)という高度な技術が使われていました。これの具体的な実装は、例えばJavaだとEJB(Enterprise JavaBeans)とその基盤技術のJTA(Java Transaction Architecture)、Microsoft系だとCOM+やその基盤技術であるMTS(Microsoft Transaction Server/Service)などが代表例になります。該当基盤でこれらの技術がもし使われていない場合、この分散トランザクションの技術は使われていない可能性が高いと考えられるでしょう。

Webサービス越しにオンライン・トランザクション処理

さて、この分散トランザクション、SOAの世界ではいかがでしょうか。上記の技術ではそれぞれの通信プロトコルが使われていましたが、SOAでは「Webサービス」と呼ばれる、WSDLで規定されたSOAP文書をHTTPで送受信するスタイルがベースとされています。ところがこのWebサービス、単なる情報のやりとりだけしか規定されていないため、トランザクションの引き継ぎなど高度な処理に全く対応していません。

無論、そういう高度な処理への需要は容易に想定されるわけで、Webサービスの仕様に後から追加されました。OASISという標準化団体による「WS-Atomic Transaction」(WS-AT)という仕様です。これはWS-Coordinationなど他の追加仕様に依存する複雑な仕様なのですが、ややこしい話はさておき、このWS-ATに対応しているアプリケーション・サーバーを用いれば、Webサービス越しに分散トランザクションが実現できる土壌ができる、そう覚えておけば良いでしょう。もちろん、土壌ができるだけなので、実際の中身は従来どおりプログラミングが必要です。

WS-ATの現状

この気になるWS-ATですが、残念ながら現状それほど多くのアプリケーション ・サーバーが対応している訳ではありません。この規格自体は2005年に第1版、2007年に第1.1版が出ているため、さほど新しいものではありません。にもかかわらず、本稿執筆時点でも、具体的な製品名はさておき、対応しているサーバー製品は数える程度です。

しかし、バッチ型からオンライン型トランザクション処理へのシフトは、技術の長期トレンドとして今後変わるとも思えません。サービス指向を前提とした場合、今後の製品の評価軸として、このWS-ATへの対応有無はひとつの重要な指標となり得ると筆者は考えています。

次回はさらにSOAの内部の技術について、深く追っていきたいと思います。