連載 ビジネスWebサービス最新事情（6）
混迷するWebサービス・トランザクション制御

Webサービスをビジネスで利用するために、高度なセキュリティやトランザクション処理、複数のWebサービスの連携などを実現するさまざまな仕様が策定されようとしている。本連載では、これらの仕様を理解するための解説を行っていく。（編集局）

日本アイオナテクノロジーズ（株）
小野沢 博文
2004/1/22

　今回から2回に分けて、Webサービスのトランザクション仕様の解説を行います｡本連載の第1回に、「Webサービスのトランザクション仕様は、セキュリティ仕様以上にあわただしい動きが見られる分野」と述べましたが、あれからわずか半年足らずの間にさらに大きな変化がありました。今回は、前半でこうした新しい変化を踏まえて、現在提案されているトランザクション仕様の最新事情を説明し、後半でこれらのトランザクション仕様がそもそも何を目指しているのかというベーシックな部分を解説します。

■Webサービス・トランザクション仕様の最新事情

　第1回では、Webサービス・トランザクション仕様として「BTP」「WS-Transaction」「WS-CAF」の3つの仕様が乱立しているという話をしました。まずは、これらの仕様のその後の状況を簡単にレビューしましょう。

BTP（Business Transaction Protocol）

　BTPは、2002年5月にバージョン1.0がOASIS委員会仕様になってから、その後大きな変化はなく、いまのところOASISオープン標準に向けた動きは見えていません｡

WS-Transaction

　マイクロソフト、IBM、BEAの3社は、2003年9月にWS-Coordinationの改定仕様とWeb Services Atomic Transaction（WS-AtomicTransactionまたはWS-AT）仕様を公開しました。WS-Transaction仕様はもともと、ACIDトランザクションをサポートする「アトミック・トランザクション」と、ロング・ラニング・トランザクションをサポートする「ビジネス・アクティビティ」から構成されていましたが、WS-AtomicTransactionは前者のアトミック・トランザクション部分を置き換える新仕様です。ビジネス・アクティビティを置き換えるWS-BusinessActivity仕様もいずれ公開されるはずです。第1回に、WS-Transaction仕様では「プロトコルの詳細までは規定されていない」と説明しましたが、これらの新仕様でこの点が改善されていることを期待します（特に不十分だったビジネス・アクティビティを置き換えるWS-BusinessActivity仕様がそろっていないので、現時点ではまだ判断できません）｡

WS-CAF（Web Services Composite Application Framework）

　2003年10月、OASISにWS-CAF TC（技術委員会）が発足し、Arjuna Technologies、富士通ソフトウェア、アイオナテクノロジーズ、オラクル、サン・マイクロシステムズによって提出された仕様セットをベースにした議論が開始されています｡このTCは、トランザクションを中心とする複合Webサービスの仕様セットをロイヤルティー・フリーで提供することを目的にしています。当初の予定では、2004年中にWS-CTX、WS-CF、WS-TXMの各ドラフト仕様が順次リリースされることになっています。

仕様名 標準化ステータス サポートするトランザクション・モデル BTP OASIS委員会仕様 ロング・ラニング・トランザクション WS-Transaction 未提出 ACIDトランザクション、 ロング・ラニング・トランザクション WS-CAF OASISに提出され、TCでの議論が開始 ACIDトランザクション、 ロング・ラニング・トランザクション、 ビジネス・プロセス・トランザクション

表1　Webサービス・トランザクション仕様の標準化ステータス

■Webサービス・トランザクションが目指すもの

　複数の仕様が乱立してしまい、これぞという標準がなかなか決まらない現在の状態は、利用者にとってもベンダにとっても非常に不幸です。しかし、技術的に見るとこれら3つの仕様はほぼ同じ方向を目指しています。ここでは、どの仕様が生き残るのかという血なまぐさい話はしばらく忘れて、これらの仕様が実現しようとしているWebサービス・トランザクションの基本的な部分を解説します｡

トランザクション処理とは

　「トランザクション」という用語は、金銭や商品の交換を伴う取引（ビジネス・トランザクション）や、取引を実現するためのコンピュータ・プログラムの実行（オンライン・トランザクション）という意味で広く使われています。ここでは、もう少し範囲を狭めて、1つ以上のアプリケーションにまたがる処理において、各アプリケーションの処理結果の整合性を保つための仕組み、またはそうした仕組みによって整合性が保証された処理という意味でトランザクションという言葉を使うことにします。　

　例えば、ネットで株を購入する場合、個人の現金口座から購入代金と手数料を引き落とす処理と、購入した株を個人の証券口座に追加する処理は必ず両方行われる必要があり、片方だけが失敗するという事態は許されません｡どちらか一方の処理が失敗した場合には、取引全体をキャンセルしなければなりません。このように、全体の整合性が保たれた処理がトランザクション処理です。

　このようなトランザクション処理には、主に2つのモデルがあります。

　1つ目のモデルは、従来のTPモニタとDBMSで採用されているACIDトランザクションです。このモデルは通常密結合システムで使われることから、密結合トランザクションと呼ばれることもあります。あるいは、次のロング・ラニング・トランザクションとの対比でショート・ラニング・トランザクション（または単にショート・トランザクション）、またはアトミック・トランザクションと呼ばれることもあります。

　2つ目のモデルは、ロング・ラニング・トランザクション（または単にロング・トランザクション）です。こちらは、通常疎結合システムで使われることから、疎結合トランザクションとも呼ばれます。

ACIDトランザクションとは

　ACIDトランザクションの「ACID」は、Atomicity（原子性）、Consistency（一貫性）、Isolation（隔離性）、Durability（耐久性）の頭文字からなる略語です。ちなみに、俗語のacidは薬物（LSD）を意味します。ACIDトランザクションとは、これら4つの特性が保証されたトランザクションです。これらの4つの特性の詳細な解説は、トランザクション処理の教科書（例えば、Philip Bernstein＋Eric Newcomer著、『トランザクション処理システム入門』、日経BP、ISBN 4-8222-8026-8）に譲ることにして、ここではACIDトランザクションとロング・ラニング・トランザクションの共通点と相違点を理解するうえで重要になる、原子性と隔離性の2つの特性について少し説明しましょう。

　株のネット購入の例で、処理の一部が失敗した場合に全体をキャンセルするのは、原子性によって保証されます。原子性とは、処理全体が完全に実行されるか、あるいはまったく実行されない（結果を元に戻す）かのいずれかであることを保証する、トランザクションの最も重要な特性です。この特性は、ACIDトランザクションに限らず、ロング・ラニング・トランザクションでも重要になります。ACIDトランザクションでは、原子性はアプリケーションの介在なしに、TPモニタとリソース・マネージャ（例えばDBMS）の機能として実現されます。

図1　ACIDトランザクションの例

　複数のサーバまたは複数のリソース・マネージャにまたがる処理では、原子性の実現はそれほど単純ではなく、何らかの調整プロトコルが必要になります。ACIDトランザクションでは、通常、2相コミット・プロトコル（2PC：2 Phase Commit）が使われています｡

図2　2相コミット・プロトコルの例

　複数のトランザクションを同時に実行する場合、各トランザクションがほかのトランザクションの影響を受けてしまうと、正しい結果が得られないことがあります。

　例えば株の買い注文の処理で、トランザクションXがAさんの現金口座の残高を確認して、買い注文を出せると判断した直後に、別のトランザクションYがAさんの口座から代金を引き落としてしまったらどうなるでしょうか（図3）。この場合、トランザクションXでは、NASDAQに買い注文を出した後に残高不足が判明するという事態になってしまいます。これはノン・リピータブル・リードと呼ばれる現象です。

図3　隔離性が保証されていないと……（ノン・リピータブル・リードの例）

　もう1つ例を挙げましょう。トランザクションZがAさんの口座に入金して、まだコミットする前にトランザクションXがこれを読み取って、その後トランザクションZがロールバック（キャンセル）されてしまったとしたらどうでしょうか（図4）。本来読んではならないゴミのデータを読んでしまったことになります。これはダーティー・リードと呼ばれる現象です｡

図4　隔離性が保証されていないと……（ダーティ・リードの例）

　トランザクションがお互いに影響を及ぼしあうと、こうしたさまざまな不都合が発生してしまいます。このような影響を断ち切って、各トランザクションがあたかも隔離されて、直列に実行されているかのように制御するのが隔離性です。隔離性の実現のために通常使用されているのが、リソース（例えばDBテーブルのレコード）のロックです。例えば、1つのトランザクションがあるレコードを更新する場合、トランザクション終了までそのレコードをロックすることで、ほかのトランザクションからのアクセスを禁止するといった方法です。

　このように隔離性はリソースに対するロックという方法で実現されるため、しばしば処理性能に大きな影響を及ぼします｡これが、ACIDトランザクションを単純に疎結合システムに適用できない理由の1つでもあります。

ロング・ラニング・トランザクション

　管理主体が異なる組織をまたがるトランザクションや、同一組織内でも長時間にわたるトランザクションでは、アプリケーションで実装するかWebサービス製品の機能として実現するかは別にして、通常はACIDトランザクションではなくロング・ラニング・トランザクションが使用されます。これには次のような理由があります。

• ACIDトランザクションでは、トランザクション完了までリソースがロックされます。そればかりか、リソースの一貫性（ACIDのC）までもが要求元のアプリケーションにゆだねられてしまう場合もあります。企業間取引のようなケースで、自組織のリソースが外部組織が主導権を握るトランザクションの制御下に置かれるのは極めて危険です。
  　
• トランザクションが長時間にわたる場合には、リソースが長時間ロックされてしまうことになり、性能と可用性の面で問題が発生します。
  　
• 企業間取引で、しかもトランザクションが長時間にわたる場合、本来の処理でリソースがロックされているのか、取引先企業のシステム障害やネットワーク障害の結果ロックされたままになっているのかの切り分けが困難です｡

　ロング・ラニング・トランザクションの仕様では、トランザクションの単位をアクティビティと呼ぶことが多いので、以下では「アクティビティ」という用語を使用して説明します。これはACIDトランザクションにおける「トランザクション」と同じく、整合性を保持する必要のあるひとまとまりの作業単位と考えてください。

　ロング・ラニング・トランザクションでは、上記のようなACIDトランザクションの問題を避けるために、アクティビティをいくつかのサブ・アクティビティ（WS-Transactionではタスクと呼んでいます）から構成して、サブ・アクティビティ内の処理にある程度の自律性を持たせるようにしています。

　例えば、全体のアクティビティが完了する前に、サブ・アクティビティ内でのデータベースの更新を個々にコミットまたはロールバックすることが許されています｡この場合、サブ・アクティビティの処理結果をアクティビティ完了前にほかのアクティビティから参照することができます。このように、ACIDトランザクションとは異なり、ロング・ラニング・トランザクションでは隔離性に対する要求がかなり緩和されています｡

　これをもう少し具体的に、よく引き合いに出される典型的な旅行予約を例に説明しましょう｡

　図5のように、顧客からの申し込みに従って、旅行代理店が航空券、鉄道の指定席、さらにホテルを予約するケースを考えます｡ここでは、旅行予約の全体がアクティビティで、個々のチケットまたはホテルの予約がサブ・アクティビティになります。これらの予約は、1つでも欠けると旅行が成立しなくなるので、最終的にはすべての予約が成立するか、またはすべてがキャンセルされるかのいずれかの状態で完了しなければなりません。

　この意味で、アクティビティは原子的でなければなりません。ただし、ACIDトランザクションの原子性とは異なり、第1希望の予約が取れない場合には、旅行代理店は顧客の要求を確認しながら、第2希望、第3希望での予約を試みるといった柔軟性が要求されます。さらに、顧客との対話や代理店オペレータの介在によって、アクティビティ完了までに長時間かかることも予想されます。

図5　ロング・ラニング・トランザクションの例

　サブ・アクティビティ内の予約処理は、それぞれ航空会社、鉄道会社、またはホテルのシステムで実行されますが、これらは全体のアクティビティが完了するまで待たされることなく、それぞれの処理に閉じてコミットできます。つまり、個々の処理は従来のACIDトランザクションとして実装することができます。このため、旅行代理店側の都合やシステム障害で自社のリソースが長時間ロックされる恐れがなくなります。

　次に予約の取り消しまたは変更処理について考えてみましょう。例えば、第1希望のホテルを予約した後、航空券が取れなかったためホテルの予約をキャンセルしなければならないようなケースです。ACIDトランザクションでは、トランザクション内の処理が1つでも失敗した場合には、トランザクション全体が自動的にロールバックされます。ロング・ラニング・トランザクションのアクティビティではこの点はどうでしょうか。

　上記のように各サブ・アクティビティ内の処理をACIDトランザクションとして実装して、予約をその都度コミットした場合には、アクティビティ全体を機械的にロールバックすることはできません。このため、予約をキャンセルまたは変更するためのサブ・アクティビティを別途実行する必要があります。このようなサブ・アクティビティを補償トランザクションと呼んでいます｡

　補償トランザクションは、ほかのサブ・アクティビティと同様にアプリケーションの一部として実装されます。そして、単なる取り消し処理だけではなく、キャンセル料の処理といった業務に依存した複雑な処理を伴う場合もあります。こうした補償トランザクション実行のトリガは、アプリケーション・プログラム内にハード・コードする代わりに、前回説明したBPEL4WSやWSCIのようなフロー記述言語で定義することができます。

図6　補償トランザクションの例

◆

　今回は、Webサービス・トランザクション仕様の最新事情と、トランザクション仕様が実現しようとしている基本機能を解説しました。次回（最終回）は、Webサービス・トランザクション仕様の具体的な中身の解説と、「標準化戦争」の今後の行方についての議論を予定しています｡

■バックナンバー

　1 .複雑化するWebサービスの仕様群を整理する
　2. Webサービスのキュリティ技術を詳解する
　3. OASIS WS-SecurityとXKMSの構造を知る
　4. OASIS SAMLとXACMLの構造を知る
　5. Webサービスを連携させるコレオグラフィ
　6. 混迷するWebサービス・トランザクション制御
　7. BtoB基盤となるWebサービス・トランザクション（最終回）

ビジネスWebサービス最新事情

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）