 |
||||||||||
|
||||||||||
| 1 2 3 次のページ | ||||||||||
|
||||||||||
| はじめに | ||||||||||
|
前回はBPIの実行時の特徴の1つである「複数システムの連携」について解説した。今回はもう1つの特徴である「ビジネス的に意味のある一連の作業の自動化」について、さらにBPIの開発時や運用時の特徴について、どのような要件があり、それを解決する機能が必要であるかを解説していく。 |
||||||||||
| ビジネス的に意味のある一連の作業 | ||||||||||
|
単一システム内の1つの処理は、トランザクション処理と呼ばれる1つの作業単位（UOW：Unit Of Work）からできている。このUOWの中ではトランザクション処理を満たすための要件、ACID（Atomicity：原子性、Consistency：一貫性、Isolation：独立性、Durability：永続性）特性が保たれるように開発される。 |
||||||||||
表1：ACID特性 |
||||||||||
| ACID特性の維持はデータベースやTPモニター（Transaction Processing Monitor）などのミドルウェアとアプリケーションによって保証される。 一方、BPIで問題にしているシステム連携処理は、様々なシステムを連携しているので単一トランザクション処理ではなく、複数のUOWから成り立っている。そのため単一システム内の個々のUOWではACID特性が保証されるが、ビジネス的に意味のある処理としてのACIDは特性が保証されない。 永続性がデータベースシステムによって実現されたとしても、他の特性（原子性・一貫性・独立性）は保証されない。そのうえ複数のUOWで構成されるため、中途半端な状態が存在してしまい、やはり原子性・一貫性を保証することはできない。また前述したように長時間にわたる処理を考えると、独立性を保証するために処理が終わるまでの間、関連するシステムにロックをかけるようなことは現実的ではない。 しかしシステム連携処理においても、ビジネス的に意味のある処理として、要件を満たす必要がある。このためには、処理の途中でACID特性が保証されない状態があったとしても、最終的にはビジネスレベルでACID特性を満たすようにすることが重要である。 そのための技術として補償（Compensation）という考え方がある。つまり、ビジネスレベルでの取り消し処理を実現するのである。以下の具体例をみながら、その仕組みを解説しよう。例えば顧客がインターネットで商品を注文した場合、おおまかには以下のような流れになる。
表2：インターネットで商品を注文した時の処理の流れ つまり、表2の各階段はそれぞれ別のシステムで実行されることが多く、それぞれ別のUOWとなる。インターネット注文が混みあって、プロセスが平行して同時に何件も発生した場合、1の段階で余裕のあった在庫が、4まで処理が進んだ時にはすでに在庫がなくなっている場合もある。 このような場合、プロセスは先に進むことができなくなるため、ビジネス的に一貫性を保つためにその注文を取り消さなくてはならない。つまりは4で失敗したため、3のUOWを取り消すために顧客へのキャンセルとお詫びのメールの送付を行い、1の取り消しとして受け付けた注文データはキャンセル状態にするといった処理が必要である。 上記の場合だけをみれば、4の処理時にif文を使用し処理を分岐させれば対応可能だと思われるかも知れない。しかし実際には、1〜6すべての処理時に失敗は起こりうるため、それぞれの取り消しのための処理も用意しなくてはならない。これはビジネスプロセスの定義において、通常処理フローと異常時の処理フローが混在することを意味し、プロセスの可読性を損ない開発生産性やメンテナンス性を悪化させる要因になる。 そこで、上記のような問題を回避するために補償の仕組みを利用し、下図のように取り消し処理を行う。  図1：取り消し処理 （画像をクリックすると別ウィンドウに拡大表示します） そして、補償ロジックは各UOWについて定義することも可能であり、異なる処理箇所で異常が発生した場合でも、そこから任意の補償ロジックを起動させることもできるため、補償ロジックの記述は必要最小限ですむことになる。 現在、この補償の仕組みはWSBPELの仕様の一部として規定されており、ビジネスプロセスの補償はこれが標準となりつつある。 |
||||||||||
|
1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
