SOAは軽量型のアプリケーション連携技術：SOAでつくる変幻自在の情報システム（2/3 ページ）

前回は、アプリケーションレベルのデータ設計の相違の問題について触れた。今回はトランザクションに関する課題について説明しよう。この問題もSOAを使うか否かには関係なく、一般的にアプリケーション連携においても課題になるものだ。

[栗原 潔，ITmedia]

求められる例外ケースへの対応

　しかし、このような仕組みを現実世界のアプリケーションとして実現しようとするならば、さまざまな例外ケースに対応しなければならなくなる。データベースのエラーやシステムダウンなどのシステム的な障害もあるし、単に予定の便が既に埋まっていた、というようなアプリケーションレベルでの例外もある。

　いずれの例外ケースにおいても、現実のアプリケーションであれば、飛行機とレンタカーのいずれか一方だけの予約が取られている状態が発生しないようにしなければならない。つまり、トランザクションの重要特性である「all or nothing」（技術用語で言う「原子性」）を保証しなければならないわけである。

　飛行機予約とレンタカー予約が1つのアプリケーションの中で稼動している場合や、複数システムで稼動している場合でも、2フェーズコミットの仕組みが実装されている場合であれば、このような「all or nothing」の特性は、システムが自動的に保証してくれる。

　しかし、SOAにおける疎結合のように、複数のサービスが1つのトランザクションとして稼動していない場合には、例外ケースにおける回復処理はアプリケーションロジックの仕事になってくる。具体的には、いったん行った予約の処理をキャンセルするという処理が必要となってくる。

　このようなアプリケーションレベルの回復処理をBPM（ビジネスプロセスマネジメント）製品のワークフロー機能で自動化することもできる。とはいえ、厳密なトランザクション性を実現しようとするならば、設計する上でかなりの考慮が必要になるだろう。これは、分散トランザクションモニタが提供している機能をアプリケーションレベルで実現しようとしているようなものなので、大変なのは当たり前である。