デベロッパ達は独自のトランザクションコーディネートロジックを書くべきだろうか？

作者 Jean-Jacques Dubray , 翻訳者 編集部 投稿日 2008年1月17日

セクション

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ

トピック

WS Standards ,

Business Process Management ,

Webサービス ,

SOA ,

ビジネス ,

トランザクション処理 ,

Architecture ,

エンタープライズアーキテクチャ ,

データベース ,

WS-CAF ,

指導 ,

ACID ,

WS_TX ,

WS-BusinessActivity ,

トランザクション

共有 |

Mark Little氏はRed HatのJBoss部門の標準化ディレクター、及びデベロップメントマネジャーである。彼は自身のキャリアのほとんどの時間を分散コンピューティングと分 散トランザクションプロトコルに費やしていた。また彼はBTP、WS-CAFとWS-TXを含むWebサービス用のトランザクションプロトコルを定義するために始められたワークグループ(参考記事・英語)にいくつか関わっていた。

12月にMark氏は”大規模スケールの分散トランザクション”(source)をブログで記している。彼は過去に複製プロトコルに取り組んだことがあり、パフォーマンス と有効性を得るためには一貫性をトレードする必要がある(source)という結果がもたらされたことを説明している。これはWerner Vogels氏がQCon London 2007において行ったスピーチ(参考記事・英語)の内容と一致している。

Mark氏は下記のように論じている。

それはトランザクションにも同じことが言えることが判明した。実際のところサービスの境界の裏で同じトランザクション実装を使用していないかもしれないWebサービス内で、本質的に異なるサービスとドメインを一緒にしたければそれは不可欠なのである。

また、彼はPat Helland氏等の他の人たちもまた、トランザクション性の緩和という比較的同じ考えを持っている(PDF・英語)ことを指摘した。Mark氏は自身の要点を説明するためにHeisenbergの不確定性規則を使用している。

全ての参加者が持つであろう状況を知ることができるが、その時間を知ることはできない。かもしくはその反対も同様である。

また彼はWS-CAF(Composite Application Framework)の仕様セットの一部分としてWS-BP仕様を提示した。

ビジネスプロセストランザクションモデルと従来の2PCのそれとの重要な一つの相違点はそれが成功を想定するということで、BPモデルが楽観主義で障害の ケースを少数派と想定し、必要であればオフラインかもしくはリプレイ・ボイド・コンペンセーションを通してそれらを処理、解消するが常にそれが自動的に行 われるわけでなく頻繁に人的作用が必要とされる。

このアプローチはPat氏が彼のペーパーを解説するために使用している例(PDF・英語)に見受けられる。

家を購入する際のエスクロー会社との関係を考えてみて欲しい。バイヤーがエスクロー会社との信託契約に介入する。売り手、住宅ローン会社と他の団体もこの取引に関わっている。

住居を購入するための契約書に署名する時あなたはその取引の結果がどんなものか分からない。あなたはそれを受け入れるが、エスクロー会社が閉鎖するまでそ の結果は不確かなのである。意思決定において権利がある団体はエスクロー会社のみである。これは分散トランザクションの使用なしに大規模な団体の同意を得 るために使われていた2団体間の関係のハブアンドスポークの集合体一式である。

Pat氏は下記のように付け加えている。

あなたが限りなく無限に近いスケールを考える時、2団体間の関係を考えると面白い。2団体間の暫定・キャンセル・確認（従来のワークフローと同じように）から作り上げることによって。

たくさんのWebサービストランザクション仕様の共同著者であるGreg Pavlik氏もまた異なった考え方をし始めた(source)。

そのアプリケーションには、上記の全てとビジネスロジックそれ自体を超越してなぜプロトコルが必要なのかがどんどん不明瞭になる時点で、コーディネータの役割が含まれているかもしれない。

ここにはアプリケーションデベロッパたちが理解する必要のあるパターンがある。多分それはフレームワークにサポートされているものである。でもそれはただ単にトランザクションマネジメントがそのコンテキストにおいては明白な役割を果たさないだけかもしれない。

Mark氏は下記のように返答している。

彼はACIDトランザクションが大規模スケールシステムにおいて明るい将来を抱えているとはみなしていない

がしかし、

そこにはステートトランジションをコントロールし、障害とリカバリにおいて”正しいことをする”のが可能な信頼性のあるコーディネータが存在するのである。

昨年の夏(参考記事・英語)、IDesign.netのチーフアーキテクトであるJuval Lowy氏はポッドキャストでそれに似たような結果を提示している(MP3・英語)。

いくつかのソフトウェアエージェントが共通のワークユニットを実行するのに関与している時、ステート調整を行うためにアドホックトランザクションプロトコルを再考案することは必ずしも良いアイディアというわけではない。

原文はこちらです：http://www.infoq.com/news/2008/01/dev-tx-coordination-logic