トランザクション管理の複雑性を克服する（パート1）：The Rational Edge（4/4 ページ）

[Benjamin Lieberman，＠IT]

サービス指向アーキテクチャでトランザクションをインプリメントする際の課題

　サービス指向アーキテクチャにトランザクション管理をインプリメントする際に固有の課題は多い。この中で最も大きいのは、サービス自体の特性だ。サービスは疎結合されているため、ステートレスで、非同時で、分散され、不明瞭になりがちだ。ステートレスのサービスはトランザクションのステート（状態）を感知せず、トランザクションが失敗しても一連の変更の「ロールバック」を受け付けられない。サービスがWebサービスとしてインプリメントされている場合は、現行のプロトコルではインターネットの非同時の特性を活用する。これはつまり、サービスがリクエストに対してタイムリーな対応ができない場合があることを意味する。並行作業ではこれが考慮されないが、トランザクションが逐次処理で、あるサービスコールの情報が別のところで必要になる場合を考えたい。

　Webサービスとしてインプリメントされるサービスはどこからでもアクセスできるため、これらは定義上は分散されており、これが待ち時間、信頼性、およびセキュリティに関する懸念を生じさせ、トランザクション管理に影響を与える。

　最後に、サービスは定義されたTCSとのインターフェイスでしか認識されず、処理内容に関する詳細はない。これは、あるサービスがクライアントの知らない間に別のサービスを利用し、副次的効果によって変更を伝達する「ブラックボックス」の利用モデルへとつながっていく。トランザクションにとって、これはトランザクションの一部であるサービスが、やはりそのトランザクションの別のサービスを呼び出すことを意味する。これは、並行処理の重大な問題につながる可能性がある。最初のコールが2番目にとって必要なデータを変えてしまう場合があり、トレースが非常に困難になるためだ。

　これらの課題をすべて考慮すると、信頼性の高いTCSを作成することは、サービス指向アーキテクチャをインプリメントする誰にとっても難しい仕事だ。TCSはさまざまな複雑性を持つトランザクションを、ネスティング、同時処理、セキュリティ、スケジューリング、そして本稿で解説したほかのすべての問題を加味しながら管理できなくてはならない。では、気の毒なサービスアーキテクトはどうすればよいだろうか？ 本稿のパート2ではTransaction Control Serviceのアーキテクチャ候補を紹介し、これらの問題について解説する。

著者プロフィール

Benjamin Lieberman

BioLogic Software Consulting, LLC

主任ソフトウェアアーキテクト

---

本記事は「The Rational Edge」に掲載された「SOA transaction management -- Part I: The transaction coordination service」をアットマーク・アイティが翻訳したものです。

---

「The Rational Edge」バックナンバー

• トランザクション管理の複雑性を克服する（パート1）
• アジャイルとシステムテストの新たな関係（後編）
• アジャイルとシステムテストの新たな関係（前編）
• アジャイル開発の広範な普及を目指して
• 見積もりの精度 Accuracy of Estimation
• 複雑性を理解する（後編）：ソフトウェアの複雑性を手なずける
• 複雑性を理解する（前編）：ソフトウェアが複雑なのは仕方がない？
• 鈍重な開発チームは鈍重なシステムを作る？/パート3：役割とポリシー（後編）
• 人事評価と開発者のモチベーション/パート3：役割とポリシー（中編）
• 自己管理型チームの利点と弱点/パート3：役割とポリシー（前編）
• プロセスはチャンスが訪れるたびに改善する/パート2：プロセスと基準（後編）
• 開発プロセス導入のアンチパターン/パート2：プロセスと基準（中編）
• 反復開発の「ここはぜひカバーしたいポイント」/パート2：プロセスと基準（前編）
• 開発プロジェクト「統治」のピンポイント解説/パート1：原則と組織（後編）
• 開発プロジェクトを「統治」するベストプラクティス/パート1：原則と組織（前編）
• 初歩の「Perl」「Python」「Ruby」
• ビルドが全滅する原因/プロジェクトの状態を評価する：パート2（後編）
• 不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する：パート2（前編）
• UMLを使ったビジネスモデリング（後編）：そうだったのか！ システムユースケース
• UMLを使ったビジネスモデリング（前編）:なるほど！ ビジネスユースケース
• 「この開発プロジェクトは中止！」の基準/プロジェクトの状態を評価する：パート1（後編）
• プロジェクトのはじめに計画を立てるのは無謀/プロジェクトの状態を評価する：パート1（前編）
• 専門家に聞くモデル駆動開発のメカニズム
• 「設計」や「構築」よりも重宝されるスキル
• キミのコードが汚い理由
• 汎用グラフィカルモデリング言語「SysML」 パート2：グラフィカルなモデル言語で製品構造を記述
• 汎用グラフィカルモデリング言語「SysML」 パート1： 要件、ユースケース、およびテストケースのモデリング
• ウォーターフォールから反復型への移行手順
• ソフトウェアアーキテクティングのメリット
• ソフトウェアアーキテクティングのプロセス
• ソフトウェアアーキテクトの役割
• ソフトウェアアーキテクチャって何なの？（後編）
• ソフトウェアアーキテクチャって何なの？（前編）
• ITプロジェクトを見える化する
• ユーザー要件を引出すテクニック： ユースケースかストーリーボードか
• オブジェクト指向を超えて
• ルネサンスの巨匠たちに学ぶエンジニアリングの技
• ソフトウェア開発の「いま」と「近未来」の話
• 中国のソフトウェア開発現場はこんなにスゴイ
• 隣のテストチームが優秀ないくつかの理由（後編）
• 隣のテストチームが優秀ないくつかの理由（前編）