 |
||||||||||||||||||
|
||||||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||||||
|
||||||||||||||||||
| ビジネスプロセスの形態 | ||||||||||||||||||
|
ここでいうビジネスプロセスの形態とは、アプリケーションの連携方式を指しています。アプリケーションの連携方式が重要なのは、これによってビジネスプロセス実行基盤のあり方にも大きく影響してくるからです。 これまでは説明をシンプルにするためにあえて連携方式については触れず、1対1のアプリケーション連携を前提としてESBの基本機能を解説してきました。これには、1対1の連携ではその違いが顕著にあらわれないという理由もあるからです。 連携方式は図4に示すように、リクエスト・リプライ方式方式とイベントドリブン方式の2つに大別できます。  図4：リクエスト・リプライ方式とイベントドリブン方式 リクエスト・リプライ方式方式とは、サービスを提供しているアプリケーションにサービス実行のリクエストを送り、その実行結果をリプライとして受け取る方式を指しています。SOAの世界では、リクエストを送る側を「サービスコンシューマ」または「リクエスター」、サービスを提供する側を「サービスプロバイダ」と呼んだりします。一方、イベントドリブンとは、ある事象の発生を他のアプリケーションに通知する方式です。 次の図5はESBによるアプリケーション連携を説明したもので、ESBの役割を示すためによく用いられるものです。  図5：1対1連携の方式 （画像をクリックすると別ウィンドウに拡大図を表示します） 図5を見る限りにおいては、リクエスト・リプライ方式方式、イベントドリブン方式のどちらにもESBがきれいにマッチしていますし、また両連携方式にもさほど大きな違いがないように思えます。 このような図の意味として「リクエスト・リプライ方式＝同期式」vs「イベントドリブン＝非同期式」あるいは「2方向通信」vs「1方向通信」という区分けによる解説をしばしば目にします。 確かに、図からは一目瞭然のようにして2方向通信と1方向通信の違いがみてとれますし、リクエストとそれに対するリプライによってコンシューマ側とプロバイダ側が同期を取っていることもわかります。 しかしながら、このような区分けは連携方式の部分的な特徴をあらわしているだけで、本質を捉えたものではありません。アプリケーション連携やSOAを考える際に重要なのは、「業務処理上のセマンティクスにおいてどのような意味を持つか」ということです。 例えば、リクエスト・リプライ方式方式において、リプライが直ちに返されず、その間コンシューマ側では別の処理を行うというのは現実の業務処理ではよくあることです。これは、コンシューマ側とプロバイダ側が非同期に動作していることをあらわしていますが、リクエスト・リプライ方式という方式には変わりはないのです。 また、イベントドリブン方式においても、送信したイベントに対する受信確認（Ack）を待ってから次の処理に移行するという同期を取った業務処理も存在します。 |
||||||||||||||||||
| 次回は | ||||||||||||||||||
|
さて次回は、両方式のそれぞれについて詳細に考察し、業務処理上どのような意味があるのか探っていきます。 |
||||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||||
|
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
-
-
連載
