 |
||||||||||||||||||
|
||||||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||||||
|
||||||||||||||||||
| イベントドリブン方式 | ||||||||||||||||||
|
現実の業務処理では、何らかの事象（イベント）が発生するとそれに応じた業務処理が実行される、というケースが数多くあります。イベントには、例えば次のようなものがあります。
表3：業務処理で発生するイベント イベントドリブンとは、イベントの発生によって特定の業務処理が駆動される方式を指します。最近よく耳にするEDA（イベントドリブンアーキテクチャ）も、この方式を指している言葉です。 リクエスト・リプライ方式は、まだ行われていない処理を依頼するもので、イベントドリブンはすでに発生した事柄を他のシステムに通知することで、発生した事柄の処理を促すものです。この観点から、リクエスト・リプライ方式をプル型、イベントドリブン方式をプッシュ型の業務処理方法と呼びます。 ここでも例を基に考えることとしましょう。次の図4は在庫管理のシステムの例で、システム間の連携を示しています。  図4：在庫管理のシステム連携 処理フローは図5のようになります。  図5：処理フロー 一連の処理フローを表4に示します。
表4：処理フローの解説 さて、この例題をリクエスト・リプライ方式で構築することを考えてみましょう。 リクエスト・リプライ方式で構築する場合、一番の問題は誰が全体のフローの制御を行うかという点です。 中央に位置するERPがその候補として考えられますが、スキャンシステムにリクエストを送る場面を想定してみてください。製品の搬入が不定期であるため、スキャンを実施するタイミングとERPがリクエストを出すタイミングをシンクロさせることは不可能です。 これはERPからスキャンシステムにポーリングを繰り返すことで、ある程度解消することは可能です。 ただし、スキャン中にリクエストを受け取った場合の処理方法など、スキャンシステムにもERPにも複雑な処理ロジックが必要になり、処理のオーバーヘッドも発生してしまいます。 また、ある1つのリクエストに対する処理を行っている間にもベルトコンベヤー上を製品が流れていきますので、スキャンシステムがスキャンし損なう可能性もでてきます。在庫管理システムに対するリクエストについても同じことがいえるでしょう。 今回の例のように、関係する他のシステムが関知できないタイミングである処理がなされたり、予期できないタイミングである事象が発生する場合、リクエスト・リプライ方式で実装すると、システムのどこかに大きな無理が生まれるのです。 そのような場合は、処理がなされた時点や事象の発生を検知した時点で他の関係するシステムに通知するイベントドリブン方式が適しているといえます。次の図6は、今回の例をイベントドリブン方式で連携した場合です。  図6：イベントの連鎖 図6からもわかるように、複数のアプリケーションからなるビジネスプロセスは、イベントの連鎖（イベントのパイプライン）として形成されます。イベントの連鎖とは、あるイベントの通知によって別のイベントが発生し、そのイベントの通知によってさらにまた別のイベントが発生するという状態を指しています。 イベントの連鎖は、中心でフロー制御を行う必要がなく（むしろフローをコントロールできないといったほうがよいでしょう）、新たなイベントが次々とアプリケーションに渡されていくパイプラインとなります。 図6を見て、ピンとくる方もおられると思いますが、パイプラインによる連携はバス形式であるESBと非常に相性がよいものです。 |
||||||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||||||
|
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
-
-
連載
