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

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

[栗原 潔，ITmedia]

栗原 潔（テックバイザージェイピー代表取締役）

　前回は、企業内におけるセマンティクスギャップの問題、すなわち、アプリケーションレベルのデータ設計の相違の問題が、SOAによるアプリケーション統合における重要課題となること（より正確に言えば、SOAはこの課題に対する直接的解決策ではないこと）を述べた。

　今回は、もう1つの重要課題として、トランザクションに関する課題について説明しよう。ここでいうトランザクションとは、複数の処理を一体のものとして扱い、障害が発生した場合にも、データベースの更新が中途半端な状態にならないことを保証する機能である。前回同様、この問題もSOAを使うか否かには関係なく、一般的なアプリケーション連携における重要考慮点だ。

SOAにおける分散トランザクションの課題

　SOAによるアプリケーション間連携では、各サービスとアプリケーションプログラムは、いわゆる疎結合の状態でつながっている。疎結合という言葉のニュアンスは人によりさまざまであるが、少なくとも、呼び出し側のプログラムと呼び出される側のサービスが独立したトランザクションとして稼動することが通常である（両者を1つのトランザクションとして稼動させるためには、2フェーズコミットなどの仕組みが必要となり、これはもはや疎結合とはいえないだろう）。

　サービスが検索処理しか行わないステートレスなものであれば、それほどの問題は生じない。だが、更新処理を伴う処理の場合は当然、例外的なケースにおけるトランザクション特性を保証するための考慮をしなくてはならなくなる。そして、この問題に対する直接的な解決策がSOAに提供されていない点には注意が必要だ。

　これも、セマンティクスギャップの問題と同様に、サンプルプログラムで考えれば簡単そうであっても、現実の企業の情報システムに適用しようとすると困難となる設計要素の1つだ。

　例えば、旅行代理店アプリケーションの例で考えてみよう。飛行機予約サービスとレンタカー予約サービスが存在し、顧客の要求に従って両サービスを呼び出し、両方の予約が取れたときに初めて予約を確定し、顧客にレスポンスを返すというアプリケーションを考えてみる。これは、サンプルプログラムとして見てみれば容易に実現できそうだ。