アプリケーション統合へのメッセージ駆動型アプローチとイベント駆動型アプローチ
SOAまたはミドルウェア、一般的にアプリケーションとエンタープライズ統合の場合）を参照するときに、メッセージ駆動型環境とイベント駆動型環境の間に明確な違いがあるかどうか疑問に思いました。ユーザーインターフェイスは、システムがユーザーのアクションをインターセプトするイベント駆動型モデル。
また、メッセージングがパブリッシュ/サブスクライブ、同期または非同期通信、トランザクションなどに基づくシステムをサポートしていることも明らかです。
しかし、ミドルウェア/ SOA /アプリケーション統合コンテキストに違いはありますか？ （アーキテクチャレベル）。私はそのようなウィキペディア（ ここ と ここ ）のソースを調べようとしていますが、それでも多少混乱しています。開発者はいつ他のソリューションよりも1つのソリューションを好むべきですか？
あるアプローチが他のアプローチよりも理にかなっている例やケースはありますか？または、それぞれを実装するための包括的なリソースとガイドはありますか？
洞察に感謝します。
「明確な区別はありますか」に対する短い答えは「いいえ」です。
用語は完全に交換可能ではありませんが、同じ基本アーキテクチャを意味します。具体的には、イベントまたはメッセージからトリガーされます。
最初に参照する記事は、低レベルの配管、ユーザーに代わってメッセージを転送するMOMまたはpub-sub "バス"に関するものです。イベント駆動型アーキテクチャは、そのフレームワークの上に構築するものです。
イベント駆動という用語は、GUIコードにも当てはまりますが、実際には同じレベルの抽象化ではありません。その場合、それはメッセージ/イベント駆動型のラインに沿って企業全体を構築することと比較して、小さなパターンです。
これは、Jonasからの質問に関する Typesafe / Reactive の視点ですボネール。 このブログ投稿の第3段落から ：
違いは、メッセージが送信され、イベントは送信されないということです。メッセージには明確なアドレス指定可能な受信者がいますが、他の人（0-N）がそれを観察するためにイベントが発生します。
この質問はずっと前に尋ねられました。より現代的で明確な応答は、 Message-Driven（Event-Drivenとは対照的に） の Reactive Manifesto によって与えられると思います：
メッセージは、特定の宛先に送信されるデータのアイテムです。イベントは、特定の状態に達したときにコンポーネントによって発行される信号です。メッセージ駆動型システムでは、アドレス指定可能な受信者はメッセージの到着を待ち、メッセージに反応します。イベント駆動型システムでは、イベントの発生時に通知リスナーが呼び出されるように、イベントのソースに通知リスナーが接続されます。つまり、メッセージ駆動型システムはアドレス指定可能な受信者に集中する一方で、イベント駆動型システムはアドレス指定可能なイベントソースに焦点を当てています。メッセージには、エンコードされたイベントをペイロードとして含めることができます。
イベント駆動型アーキテクチャは、メッセージングの有無にかかわらず実装できます。メッセージングは、信頼できる保証された方法でプロデューサーによって発生したイベントをコンシューマーに伝達する1つの方法です。特に、プロデューサーとコンシューマーが完全に分離されており、異なるサーバー/ VM /環境でホストされ、共有メモリに直接アクセスできない場合。
ただし、特定の場合-イベントのコンシューマーが同じアプリケーション自体に登録された関数/コールバックである場合、またはコンシューマーを同期的に実行する必要がある場合、メッセージングなしでイベントサブスクリプションを実装できます。
EコマースWebサイトの支払いサービスを構築しているとします。注文が行われると、注文サービスは支払いサービスに顧客のクレジットカードの承認を求めます。クレジットカードが承認された場合にのみ、注文サービスが注文を倉庫に送り、梱包と配送を行います。
クレジットカード認証のリクエストがサービスからあなたに送信される方法について、注文サービスに取り組んでいるチームに同意する必要があります。 2つのオプションがあります。
- Message-driven：注文が行われると、注文サービスは承認リクエストを支払いサービスに送信します。サービスはリクエストを処理し、成功/失敗をOrderサービスに返します。最初のリクエストと結果は、同期または非同期で送信できます。
- Event-driven：注文が出されると、OrderサービスはNewOrderイベントを発行します。支払いサービスはそのタイプのイベントをサブスクライブするため、トリガーされます。サービスがリクエストを処理し、AuthorizationAcceptedまたはAuthorizationDeclinedイベントを発行します。 Orderサービスは、これらのイベントタイプをサブスクライブします。すべてのイベントは非同期です。
イベント駆動型アプローチの利点は、他のサービスもさまざまなイベントにサブスクライブできることです。たとえば、AuthorizationAcceptedイベントをサブスクライブして、Financeチームのレポートを作成するRevenueReportingサービスがあるとします。
イベント駆動型アプローチの欠点は、システム全体が少し理解しにくくなることです。たとえば、注文サービスに取り組んでいるチームが、クレジットカードが拒否された理由（資金がない、アカウントが閉鎖されている、請求先住所が正しくないなど）に応じて、AuthorizationDeclinedイベントを別のイベントに置き換えるように依頼したとします。 AuthorizationDeclinedイベントの発行を停止すると、他のサービスが中断しますか？多くのイベントとサービスがある場合、これを追跡するのは難しいかもしれません。
this の記事にうまく記載されているように、イベント駆動型デザインを理解するには、何が表示されているかを見るのではなく、何が隠されているかを観察する必要があります。これはプログラミングの基本にすぎません。 「コールスタック」。
イベント駆動型設計では、メソッド呼び出しの定義はウィンドウの外に出ます。呼び出し元と呼び出し先はもうありません。それは、シーケンスと順序を呼び出すためのキスの別れです。システムは、発生する順序を知る必要はありません。したがって、コールスタックの前提条件である共有メモリ空間が不要になります。
ただし、呼び出しスタック環境では、呼び出し元は次に何が起こるかを知る必要があるだけでなく、機能をメソッド名に関連付けることができる必要があります。
メッセージ指向のアプリケーションには、デフォルトで共有メモリが削除されています。パブリッシャーとサブスクライバーは、メモリ空間を共有する必要はありません。一方、他のすべての機能（つまり、順序、メソッド名の結合など）は必ずしも必要ではありません。
イベント駆動型アーキテクチャの公理に準拠するようにメッセージパッシングが設計されている場合、それらは同一であると見なすことができます。そうでなければ、それらの間には大きな違いがあります。
イベント駆動型アーキテクチャとメッセージ駆動型アーキテクチャは2つの異なるものであり、2つの異なる問題を解決します。
イベント駆動型アーキテクチャーの焦点は、システムがどのようにトリガーされて機能するかにあります。 EDAのコンテキストでイベントと見なされるトリガーの大部分は、キーボードとマウス以外の方法で生成されるイベントです。イベントジェネレーター、イベントチャネル、イベント処理エンジンについて明確に考えさせるのは、EDAです。
キーボードとマウスは明らかなイベントジェネレータですが、これらのイベントの処理はすでにさまざまなフレームワークまたはランタイムによって処理されており、アーキテクトとしてそれを心配する必要はありません。特定のドメインに固有のイベントが他にもあり、Architectが考えることを期待されています。例–サプライチェーン管理イベント–ピック、パック、発送、流通、小売業者、販売など。産業IoTタイプのアプリケーションの技術的な観点から、イベントは– RFID読み取り、バイオメトリック読み取り、センサーデータ、バーコードスキャン、システム生成イベントこれらのイベントはシステムの機能を駆動するため、明示的に注意する必要があるイベントです。
メッセージ駆動型アーキテクチャの焦点は、標準のメッセージ指向ミドルウェアを使用して、システムの1つのモジュールから別のモジュールにメッセージを渡すことにより、分散システムを統合することです。
イベント駆動型アプローチを使用する場合、通常、このイベントでソースオブジェクトを送信します-イベントを発行したコンポーネントです。したがって、サブスクライバーでは、データを取得できるだけでなく、このイベントを発行したユーザーを知ることもできます。例えば。モバイル開発では、ボタン、画像、またはカスタムビューなどのビューを受け取ります。このビューのタイプに応じて、サブスクライバーでさまざまなロジックを使用できます。この場合、バック処理を追加したり、ソースコンポーネントを変更したりすることもできます。それらのソースビューにアニメーションを追加します。
メッセージ駆動型のアプローチを使用する場合は、いくつかのデータを含むメッセージのみを公開します。このメッセージを発行したサブスクライバーにとっては問題ではありません。データを受信して何らかの方法で処理したいだけです。
メッセージの概念は抽象的で、より具体的なタイプのメッセージはイベントとコマンドです。
メッセージには特別な意図はありませんが、イベントは発生してすでに完了している（過去に）何かについて通知します。コマンドは、（将来的に）発生するはずの何かをトリガーします。