メッセージ駆動型とアプリケーション統合型のイベント駆動型アプローチ

Question

私は、SOAまたはミドルウェアを参照するとき、そして一般的にアプリケーションとエンタープライズの統合の場合に、メッセージ駆動型環境とイベント駆動型環境の間に明確な区別があるのだろうかと思っていました。私は、ユーザーインターフェイスが、ユーザーの行動をインターセプトするイベントドリブンモデルに似ていることを理解しています。

また、メッセージングは​​パブリッシュ/サブスクライブに基づくシステム、sychronousまたは非同期通信、取引など

をサポートしていますが、ミドルウェア/ SOA /アプリケーションの積分するコンテキストに差があることは明らかですか？ （アーキテクチャレベル）。私はウィキペディア（here、およびhere）のようなソースを参照しようとしていますが、まだ多少混乱しています。開発者は、いつ他のソリューションよりも1つのソリューションを好むべきですか？

1つのアプローチが他のアプローチよりも理にかなっている例やケースがありますか？または、包括的なリソースとそれぞれを実装するためのガイド？

洞察力に感謝します。

Answer 1

「明確な区別があるか」という短い答えは「いいえ」です。

これらの用語は全く互換性がありませんが、同じ基本アーキテクチャを意味します。具体的には、イベントやメッセージをトリガーします。

あなたが参照する最初の記事は、あなたのためにメッセージを転送するMOMまたはpub-sub "バス"に関する低レベルの配管に関するものです。イベント駆動型アーキテクチャは、そのフレームワークの上に構築するものです。

イベントドリブンという用語は、GUIコードにも適用されますが、抽象化のレベルは実際には同じではありません。その場合、メッセージ/イベント駆動型の行に沿って企業全体を構築するのに比べて、小さなパターンです。

Answer 2

イベント駆動アーキテクチャは、メッセージングの有無にかかわらず実装できます。メッセージングは​​、信頼できる保証された方法で、生産者が消費者に提起したイベントを通知するための1つの方法です。特に、プロデューサとコンシューマが本当にデカップリングされ、異なるサーバ/ VM /環境でホストされ、共有メモリに直接アクセスすることができない場合。

ただし、イベントのコンシューマが同じアプリケーション自体に登録された関数/コールバックである場合、またはコンシューマを同期して実行する必要がある場合は、メッセージなしでイベントサブスクリプションを実装できます。

Answer 3

イベントドリブンデザインを理解するために、それが何を提示するのかを理解するために、それが隠すものを観察する必要があります。それはプログラミングの基本ではありません。 "コールスタック"。

イベントドリブンデザインでは、メソッド呼び出しの定義がウィンドウの外に出てきます。呼び出し元と呼び出し先はもうありません。それはシーケンスと注文を呼び出すキスさようならです。システムは、何が起こるかを知る必要はありません。したがって、コールスタックの前提条件である 共有メモリ領域が不要になります。

しかし、コールスタック環境では、呼び出し元は次に何が起こるのかを知るだけでなく、機能をメソッド名に関連付けることができる必要があります。

メッセージ指向のアプリケーションでは、デフォルトで共有メモリが削除されます。パブリッシャとサブスクライバはメモリ空間を共有する必要はありません。一方、他のすべての特徴（すなわち、順序、メソッド名の結合など）は必須ではありません。

イベントドリブンアーキテクチャの公理に準拠するようにメッセージパッシングが設計されている場合、それらは同一と見なすことができます。そうでなければ、それらの間には大きな違いがあります。

Answer 4

イベントドリブンアプローチを使用する場合、通常、このイベント（イベントを公開したコンポーネント）でソースオブジェクトを送信します。したがって、購読者はデータだけでなく、誰がこのイベントを公開したのかを知ることができます。例えば。モバイル開発では、ビュー、ボタン、イメージ、またはカスタムビューを受け取ることができます。このビューのタイプによっては、加入者に異なるロジックを使用することができます。この場合、バックプロセスを追加してソースコンポーネントを変更することもできます。これらのソースビューにアニメーションを追加します。

メッセージ駆動型のアプローチを使用する場合、いくつかのデータを含むメッセージのみを公開したいと考えています。このメッセージを公開した加入者にとって重要なことではなく、データを受信して​​処理するだけです。

Answer 5

ここでは、Jonas Bonerの質問に対するTypesafe/Reactiveの視点があります。 this blog postの3番目の段落から：「メッセージが指示されるという違いは、イベントは、メッセージが明確なアドレス可能な受信者を有し、他の人（0-N）がそれを観察するためにイベントが発生しただけである」。

Answer 6

イベントドリブンアーキテクチャとメッセージ駆動アーキテクチャは、2つの異なるもので、2つの異なる問題を解決します。

イベントドリブンアーキテクチャは、システムがどのように機能するようトリガされているかに焦点を当てています。 EDAのコンテキストでイベントと考えられるトリガーの大部分は、キーボードやマウス以外の手段で生成されたイベントです。イベントジェネレータ、イベントチャネル、イベント処理エンジンについて明示的に考えるならば、EDAです。

キーボードとマウスは明らかなイベントジェネレータですが、これらのイベントの処理はすでにさまざまなフレームワークやランタイムによって処理されており、アーキテクトとしては心配する必要はありません。特定のドメインに固有のイベントは、Architectが考えると思われるイベントです。例 - サプライチェーンマネジメントイベント - ピック、パック、ディスパッチ、流通、小売店、販売など産業IoTタイプのアプリケーションの技術的観点からは、RFIDリード、バイオメトリックリード、センサデータ、バーコードスキャン、システム生成イベントこれらのイベントがシステムの機能を駆動するため、明示的に注意を払う必要があるイベントです。

メッセージドリブンアーキテクチャは、標準のメッセージ指向ミドルウェアを使用して、あるモジュールから別のモジュールにメッセージを渡すことによって分散システムを統合することに焦点を当てています。

Answer 7

この質問は長年前に尋ねられました。私は、より近代的で明確な応答がMessage-Driven (in contrast to Event-Driven)にReactive Manifestoによって与えられていると思う：

メッセージは、特定の宛先に送信されるデータの項目です。イベントとは、特定の状態に到達したときにコンポーネントによって放出される信号のことです。メッセージ駆動型システムでは、アドレス指定可能な受信者はメッセージの到着を待って応答し、そうでない場合は休眠状態になります。イベント駆動型のシステム通知では、リスナは、イベントが発生したときに呼び出されるように、イベントのソースにアタッチされます。これは、イベントドリブンシステムがアドレス可能なイベントソースに焦点を当て、メッセージ駆動システムがアドレス指定可能な受信者に集中することを意味します。メッセージには、ペイロードとしてエンコードされたイベントを含めることができます。