サービス指向アーキテクチャにトランザクション管理をインプリメントする際に固有の課題は多い。この中で最も大きいのは、サービス自体の特性だ。サービスは疎結合されているため、ステートレスで、非同時で、分散され、不明瞭になりがちだ。ステートレスのサービスはトランザクションのステート(状態)を感知せず、トランザクションが失敗しても一連の変更の「ロールバック」を受け付けられない。サービスがWebサービスとしてインプリメントされている場合は、現行のプロトコルではインターネットの非同時の特性を活用する。これはつまり、サービスがリクエストに対してタイムリーな対応ができない場合があることを意味する。並行作業ではこれが考慮されないが、トランザクションが逐次処理で、あるサービスコールの情報が別のところで必要になる場合を考えたい。
Webサービスとしてインプリメントされるサービスはどこからでもアクセスできるため、これらは定義上は分散されており、これが待ち時間、信頼性、およびセキュリティに関する懸念を生じさせ、トランザクション管理に影響を与える。
最後に、サービスは定義されたTCSとのインターフェイスでしか認識されず、処理内容に関する詳細はない。これは、あるサービスがクライアントの知らない間に別のサービスを利用し、副次的効果によって変更を伝達する「ブラックボックス」の利用モデルへとつながっていく。トランザクションにとって、これはトランザクションの一部であるサービスが、やはりそのトランザクションの別のサービスを呼び出すことを意味する。これは、並行処理の重大な問題につながる可能性がある。最初のコールが2番目にとって必要なデータを変えてしまう場合があり、トレースが非常に困難になるためだ。
これらの課題をすべて考慮すると、信頼性の高いTCSを作成することは、サービス指向アーキテクチャをインプリメントする誰にとっても難しい仕事だ。TCSはさまざまな複雑性を持つトランザクションを、ネスティング、同時処理、セキュリティ、スケジューリング、そして本稿で解説したほかのすべての問題を加味しながら管理できなくてはならない。では、気の毒なサービスアーキテクトはどうすればよいだろうか? 本稿のパート2ではTransaction Control Serviceのアーキテクチャ候補を紹介し、これらの問題について解説する。
Benjamin Lieberman
BioLogic Software Consulting, LLC
主任ソフトウェアアーキテクト
Copyright © ITmedia, Inc. All Rights Reserved.