TOP業務システム> リクエスト・リプライ方式とイベントドリブン方式




SOA/ESB
SOA/ESBの真の姿とは

第6回:リクエスト・リプライ方式とイベントドリブン方式の違い

著者:Fiorano Software  青島 茂   2007/11/2
1   2  3  次のページ
リクエスト・リプライ方式とイベントドリブン方式

   「第5回:アプリケーションの連携方式」では、ESBのルーティング機能であるリクエスト・リプライ方式とイベントドリブン方式について解説しました。

   今回は、これらについてより深く解説し、業務処理上どのような意味があるのか探っていきます。

リクエスト・リプライ方式

   簡単な受注処理の例を基に解説します。受注処理は図1に示す業務フローによって実現されるものとします。

受注処理の例題
図1:受注処理の例題

   なお、図中の○は単にフローの始点と終点を示すもので、サブルーチンの入り口や出口といったような特別な意味はありません。今回はこの業務フローを処理する受注アプリケーションを実装します。ただし、図1中の「在庫確認」と「発注処理」は、次のように実装します。

  • 在庫確認処理は、受注アプリケーションの中に処理ロジックを組み込むのではなく、既存の在庫管理システムにその処理を依頼
  • 同様に、発送処理も既存の配送システムに処理を依頼

表1:「在庫確認」と「発注処理」の実装

   システム連携という観点から受注アプリケーションの部分を詳細に示すと、図2のようになります。

受注アプリケーションにおけるアプリケーション連携
図2:受注アプリケーションにおけるアプリケーション連携

   図2は典型的なリクエスト・リプライ方式の連系をあらわしています。この図から、リクエスト・リプライ方式が次の特徴を持っていることがわかります。

  • リクエスト・リプライ方式とは、自身の処理ロジックの一部を他のシステムに依頼する方式です
  • 依頼した処理の実行結果を受け取ります
  • 依頼先(サービス)の呼び出しタイミングやどの条件で呼び出すかなどの制御は、サービスコンシューマ側で行います(この例題では、受注アプリケーションがこれにあたります)
  • 依頼先のサービスも含めて、全体が業務処理上の同じステートで実行されます

表2:リクエスト・リプライ方式の特徴

   つまり、今回の例では受注アプリケーションも在庫管理システムも、また配送システムも同一の受注書に対する処理を行っています。あるシステムだけ2通目の受注書を扱うということはありません。この意味において、すべての関係するシステムが同期を取っています。

   いい換えれば、外部のサービスも含めてすべての処理が同じトランザクションを処理しているといえるでしょう。このため、トランザクション管理におけるロールバックやコミット処理が容易になるのです。

   リクエスト・リプライ方式とは、自身の処理の一部を他のシステムに依頼(もしくは委譲)するものです。依頼した処理の結果は、原則として自身の側で利用するという方法です。他のシステムの結果を自身の側に持ってくるので、いわゆるプル型の業務方式となります。

   この考え方は、サブルーチンコールやメソッドインボケーションと同じアナロジーとして、IT技術者にとっても理解しやすいものです。WebサービスやBPELなどの標準仕様も、このリクエスト・リプライ方式に基づくものなのです。


リクエスト・リプライ方式とESB

   「第5回:アプリケーションの連携方式」の図5で、1対1の連携におけるESBの位置づけを示しました。では、複数アプリケーションがリクエスト・リプライ方式で連携する場合、ESBはどのように位置づけられるのでしょうか。

   今回の例では、在庫管理システムおよび配送システムを呼び出すための通信プロトコルの制御やデータ変換は、受注アプリケーションの中に組み込まれています。「ESBの役割は、この通信プロトコルとデータ変換を受注アプリケーションから切り離し、受注アプリケーションと呼び出すシステムとの間を疎結合なものとすること」にあります。図3は、これを一般化して図示したものです。

リクエスト・リプライ方式におけるESB
図3:リクエスト・リプライ方式におけるESB

   リクエスト・リプライ方式の大きな特徴は、サービス(アプリケーション)の実行結果を利用するコンシューマが、ビジネスプロセスのコントロールを行うことです。トポロジー的にみれば、コンシューマが中央のハブとしての機能を果たす、ハブ&スポーク形態となります。

   図3に示したように、ESBはコンシューマの側に置かれ、ハブ的な位置づけとなります。本連載の「第1回:ESBの「B(バス)」が意味するものとは」で述べたように、ESBはハブ&スポークの欠点を解消するために誕生したバス形式の連携基盤です。ESBは、すべての関係するロケーションにまたがった1本のバスとして敷設されるのが理想的といえます。

   しかしながら、リクエスト・リプライ方式のビジネスプロセスにおいては、その性質上、バス本来の利点を活かしきることができないのです。また、この形態においては、今までに考察してきたESBの基本機能で充分にその役目を果たすことができます。

   では次に、イベントドリブン方式についてみていきましょう。

1   2  3  次のページ


Fiorano Software, Inc. 日本オフィス ジャパン オペレーション マネージャ 青島 茂
著者プロフィール
Fiorano Software, Inc.
日本オフィス ジャパン オペレーション マネージャ
青島 茂
SOA/ESBの分野に2003年1月からたずさわる。2005年3月にFiorano Softwareの日本オフィスを開設し、現在SOA/ESB製品の国内市場への普及に専心している。


この記事の評価をお聞かせください
ボタンをクリックしますとウインドウが開きます。

INDEX
第6回:リクエスト・リプライ方式とイベントドリブン方式の違い
リクエスト・リプライ方式とイベントドリブン方式
  イベントドリブン方式
  イベントドリブンとESB
SOA/ESBの真の姿とは
第1回 ESBの「B(バス)」が意味するものとは
第2回 ESBからSOAを理解する
第3回 ESBにおけるデータ変換(前編)
第4回 ESBにおけるデータ変換(後編)
第5回 アプリケーションの連携方式
第6回 リクエスト・リプライ方式とイベントドリブン方式の違い
第7回 BPEL 2.0とは?
第8回 BPELの課題