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

» 2012年12月06日 01時56分 公開
[Benjamin Lieberman，＠IT]
前のページへ 1|2|3|4 次のページへ

職能別組織（作業グループ）

　業務機能の作業ユニットとサービスが定義されたら、次はこれらの作業を意味のある作業グループに整理する。業務機能の作業グループは、全体的にまとまった目的を持つ業務機能を集めたものだ［注5］。

　例えば、図4にあるOrderManagementGroupは、顧客注文の検索、抽出、作成、修正、キャンセルに関連する業務活動を担当する。これらの各作業は、規則正しく並んだサービスが複数のメッセージをやりとりしながら処理できる（注文がまだ存在しないことを注文作成業務機能が最初にチェックするなど）。作業の整理はトランザクション区分（以下参照）の出発点にもなり、ここでトランザクションに関連して特定の業務活動が行われる。作業グループはさらに連鎖操作に結び付けられ、ここで逐次作業（注文作成、処理、および完了）、あるいは並行作業（在庫の割り当て、請求書作成、および口座情報の更新）が行われる。

［注5］ 筆者の校閲を担当するIBMのSimon Johnstonは、業務機能作業グループはサービスプロバイダが提供する機能の集約としてビジネスサービスの概念と同様だと指摘する。

ALT 図4　サービスグループ（サービス区画）（クリックすると拡大）

・コーディネーション地点（トランザクション区分）

　業務活動が決まり、一連のサービスを定義し、グループ化したら、次はトランザクション区分点を指示する。トランザクション管理はどの業務活動でも必要なわけではなく、すべての業務がうまく完了するようコーディネーションが必要な複数の業務が含まれるものに限定される。図5の例では、LookupCustomerとCreateCustomerRecordがトランザクションとしてまとめられていないが、FinalizeCustomerOrderはCreate Order Transactionで区切られたサービスに入っている。この例では、FinalizeCustomerOrderサービスがTransaction Management Service（TCS）を使ってほかの4つのサービスの逐次処理をコントロールし、各処理に必要なメッセージをTCSに提供する（FinalizeCustomerRequestの添付ファイルになっている）。

　トランザクション・コーディネーションの図は、定義されたトランザクションの構成要素、処理順序（逐次および並行）、そしてネスティングされたトランザクションを示すために利用される。図5の例では、GenerateShippingRequestが、Assign Inventory Itemサービスによって作成され、ネスティングされたトランザクションは、サービスが独立して利用されることを意図していたり、大きなトランザクションに関連しての利用を意図しているなど、さまざまな理由から発生する。ネスティングされたトランザクションにエラーが発生したら、その親トランザクションも確実にエラーになるよう、ネスティングされたトランザクションでも同じTCSが利用できることに注意したい。

　TCSは、トランザクションプロセスの最後で、トランザクションに参加するすべてのプロセスにポーリングを掛け、トランザクションをコミットするかどうかを判断する。2相のコミットプロトコルでは、TCSはまず参加者にポーリングを掛けて準備ができているかどうかを判断し、それぞれに対して順番にコミットを発行する。トランザクション参加者の準備ができていない場合は、ほかのすべての参加者にロールバックコマンドが発行される。参加サービスがトランザクション非対応（例：ステートレス）の場合は、TCSが補正処理（つまり「キャンセル」）を呼び出す。

・注文トランザクション作成　

ALT 図5　Submitorderトランザクション区分（クリックすると拡大）

・プロセスコントロール（逐次／並行）

　先に指摘されているように、トランザクションコントロールは逐次、並行、あるいは両方の組み合わせになる。逐次型として定義されたトランザクションは、特定の順番で発生する必要がある。一般的には、ある処理の完了で得られるトランザクションのコンテキスト情報を次に入力する必要がある（例：在庫割り当てや請求書に注文番号があるなど）。その一方で、並行処理は相互に独立しているため、同時に実行することができる。例えば、搭乗便、滞在ホテル、レンタカーなどが記された旅行日程表は、1つの処理を完了するのに別の処理の結果は必要ではないため、図6のように並行して用意できる。トランザクションの一部が逐次処理される間に残りが並行で処理されるような場合は、統合処理が発生する場合もある。このようなタイプのトランザクションの例としては、サードパーティーベンダ各社それぞれに規定が異なるバンドル製品の注文などがある。

ALT 図6　並行トランザクション処理（クリックすると拡大）

・コンテキストの処理（マップイン、マップアウト）

　最後に、TCSにはトランザクション開始前にトランザクションコンテキスト情報マッピングを割り当てる必要がある。これは、Service Coordinatorが各サービスに必要な情報を理解し、必要なトランザクションコンテキストが各サービスコールと必ず一緒に提供されるようにしなくてはならないことを意味する。図5の逐次処理の例では、CreateOrderサービスがほかの2つのサービスに不可欠なインターフェイスの一部となるOrderIDを生成する。マップインとマップアウトの情報を提供して、このコンテキスト情報を以降のサービスコールに追加できるようにするのはService Coordinatorの仕事だ。図7に示されているように、BillingおよびInventoryの両処理の両入力マップインにマッピングされたCreateOrderサービスから生成されたOrderIDは、マップアウトによって表示される。このマッピングにより、TCSがトランザクションのすべての要素にコンテキスト情報を伝達できるようになる。

ALT 図7 トランザクションのコンテキストマッピング（クリックすると拡大）

TCSのインプリメント

　サービス指向アーキテクチャは一連のサービスによって構成されており、各サービスがジョブを実行するには特定のシステムリソースが必要になる。予約サービスでは、スケジュール情報にアクセスする必要があるし、輸送サービスは、特定の在庫を顧客に出荷するためこの予約サービスを呼び出す必要がある。サービスはそれぞれの機能を定義し、この情報をレジストリに提示し、安全なコミュニケーションを実現することができる。TCSは、一連の正しいサービスを見つけ出し、それらの機能を発見し、コンテキスト情報を各サービスに伝達することでトランザクション中にこの情報を利用することができる。

・リソースの発見と登録（UDDI）

　TCSがトランザクションに参加するサービスについて知る方法は2つある。プログラムを使って「サービスコーディネーター」がTCSへの登録メッセージでサービスの詳細を指定するか、これらをレジストリから探すかだ。UDDI（Universal Description Discovery and Integration）のレジストリ仕様は、サービスを実装する側が統合情報（セキュリティ、トランザクションの認知度、リカバリなど）と一緒にサービスを登録できる設計になっている。

・リソースの機能宣言（ポリシー）

　トランザクションに関連するサービスは、それぞれの機能をTCSに対して宣言する必要がある［注6］。特に、サービスは、トランザクションの処理が可能か、そうでない場合はそれを埋め合わせ可能なサービスとして自身を宣言する必要がある（例：CreateOrderサービスの CancelOrderサービス）。さらに、この機能宣言は複数のサービスがトランザクションの安全なコミュニケーションに参加できるようセキュリティポリシーに注目する。


・セキュリティ（認証／承認）

　サービスにはセキュリティの実装責任がある。セキュリティポリシー［注7］は、TCSとサービス間の安全なアクセスチャネル作成に利用する表明を定義する。このポリシーは、TCSとサービス間の安全な相互運用に必要な安全なプロトコルと信用証明の受け渡しを定義する。


・分散環境における並行処理コントロール

　正しいトランザクション管理には、サービスで必要となるリソース管理に加え、並行処理を行う能力も重要だ。TCSが仲介するトランザクションに参加する各サービスは、あるトランザクション処理中に行われた変更がほかのトランザクションによって上書きされないよう保証できなくてはならない［注8］。例えば、顧客の注文を新規購入製品で更新するトランザクションが始まるとしよう。そして、この注文が処理されている間に、変更の一部をキャンセルする別のトランザクションが始まる。もし、これらのトランザクションが衝突を起こせば、キャンセルされるはずの製品が提供され、提供されるはずの別の製品がキャンセルされる可能性がある。これでは、顧客の要望と全く逆である。

［注8］ これが、トランザクションのACID特性（Atomic＝原子性、Consistent＝一貫性、Independent＝隔離性、Durable＝耐久性）の中の「I」を表している。

　従って、サービスがトランザクションに参加するときは、何らかの形でデータのロック／リリース戦略をインプリメントする必要がある。これは、リレーショナルデータベースが複数の同時トランザクションで一貫性を維持するために行う処理に非常に近い。これらの戦略では、各処理のタイムスタンプのチェックと、スケジューリングのための正しい順番のほか、レコードがロックされた状況とタイミング（例：楽観的および悲観的ロッキング）を判断する。最後に、リソースのデッドロック（あるサービスが、別のサービスで必要なロックを掛けたままにすること）が発生する場合、サービスは何らかの形のデッドロック解消策をインプリメントする必要がある［注9］。

［注9］ トランザクションの並行処理コントロールの概要についてはhttp://www.doc.mmu.ac.ukにあるPowerPointプレゼンテーションを参照していただきたい。

リカバリとリトライ

　TCSで最後に必要とされる要件は、トランザクションで障害が発生したときのリトライとリカバリのインプリメントだ。トランザクションの障害は2種類を考慮に入れておく必要がある。1つ目が、全サービスがトランザクション対応の場合、そして2つ目がトランザクション非対応のサービスが最低1つ存在する場合だ。最初のケースでは、TCSが2フェーズのコミットプロトコル［注10］を使ってトランザクションのステップを管理することができる。2つ目のケースでは、最初の処理をキャンセルできるよう、サービスが補正サービスを用意しておく必要がある。最初のケースの典型的な例としては、すべてのサービスが（2相コミットをインプリメントする）標準のリレーショナルデータベースにアクセスするか、もしくはOpenGroup X/Openトランザクションセマンティクスで定義されている場合だ［注11］。2番目の例は（残念ながらこちらの方がはるかに一般的だ）、Webサービスインターフェイスを使ったホテルの客室予約など、サービスが処理を完了するとすぐに操作がコミットされる場合だ。

［注10］ Alkhatib、G.、Labban、R.S.著、"Transaction Management in Distributed Database Systems: the Case of Oracle's Two Phase Commit" Journal of Information Systems Education, Vol. 13(2)

　TCSがリトライのセマンティクスをインプリメントする場合もある。この場合、TCSは長時間続くトランザクションを長期保持の可能なストレージデバイスに格納し、後でトランザクションを完了するようにする。例えば、旅行日程表を購入するトランザクションが設定された場合は、ホテル、車、ゴルフ、夕食、クルージングなどの前に航空券の予約を完了させる必要がある　TCSは、最初の航空券の予約が失敗する前に、残りのトランザクションのいずれかもしくはすべてをリトライすることもできる。これは、TCSが失敗した部分を指定された回数だけ再実行してトランザクションの完了を目指す「保証付き」トランザクションの例だ。

前のページへ 1|2|3|4 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ