私たちがSOAまたはミドルウェアに言及するとき、そして一般的にアプリケーションとエンタープライズ統合の場合に、メッセージ駆動型環境とイベント駆動型環境の間に明確な違いがあるかどうか疑問に思いました。ユーザーインターフェイスは、システムがユーザーによるアクションをインターセプトするイベント駆動型モデルに似ていることを理解しています。
また、メッセージングがパブリッシュ/サブスクライブ、同期または非同期通信、トランザクションなどに基づくシステムをサポートしていることも明らかです。
しかし、ミドルウェア/ SOA /アプリケーションの統合コンテキストに違いはありますか？（アーキテクチャレベル）。私はウィキペディア（ここ、およびここ）などの情報源を調べようとしていますが、それでも多少混乱しています。開発者はいつ一方のソリューションを他方よりも好むべきですか？
あるアプローチが他のアプローチよりも理にかなっている例や事例はありますか？または、それぞれを実装するための包括的なリソースとガイドはありますか？
洞察に感謝します。
「明確な区別はありますか」に対する短い答えは「いいえ」です。
これらの用語は完全に互換性があるわけではありませんが、基本的なアーキテクチャが同じであることを意味します。具体的には、イベントまたはメッセージをトリガーするということです。
あなたが参照する最初の記事は、あなたに代わってメッセージを転送する MOM または pub-sub「バス」である低レベルの配管に関するものです。イベント駆動型アーキテクチャは、そのフレームワークの上に構築するものです。
イベント駆動という用語は、GUI コードにも適用されますが、実際には同じレベルの抽象化ではありません。その場合、メッセージ/イベント駆動型のラインに沿って企業全体を構築することに比べれば、これは小さなパターンです。
e コマース Web サイトの支払いサービスを構築しているとします。注文が行われると、注文サービスは支払いサービスに顧客のクレジット カードの承認を求めます。クレジット カードが承認された場合にのみ、注文サービスは梱包と発送のために注文を倉庫に送信します。
注文サービスに取り組んでいるチームと、クレジット カード承認の要求が彼らのサービスからあなたのサービスに送信される方法について同意する必要があります。2 つのオプションがあります。
イベント駆動型アプローチの利点は、他のサービスもさまざまなイベントにサブスクライブできることです。たとえば、AuthorizationAccepted イベントをサブスクライブし、財務チーム向けのレポートを作成する RevenueReporting サービスがあるとします。
イベント駆動型のアプローチの欠点は、システム全体が少し理解しにくくなることです。たとえば、注文サービスに取り組んでいるチームが、クレジット カードが拒否された理由 (資金がない、アカウントが閉鎖された、請求先住所が間違っているなど) に応じて、AuthorizationDeclined イベントを別のイベントに置き換えるよう依頼したとします。AuthorizationDeclined イベントの発行を停止すると、他のサービスが中断されますか? 多くのイベントやサービスがある場合、これを追跡するのが難しい場合があります。
イベント ドリブン アーキテクチャは、メッセージングの有無にかかわらず実装できます。メッセージングは、信頼できる保証された方法で、プロデューサーによって発生したイベントをコンシューマーに伝える 1 つの方法です。特に、プロデューサーとコンシューマーが完全に切り離されており、異なるサーバー/VM/環境でホストされていて、共有メモリに直接アクセスできない場合は特にそうです。
ただし、特定のケースでは、イベントのコンシューマーが同じアプリケーション自体内に登録された関数/コールバックである場合、またはコンシューマーを同期的に実行する必要がある場合、events-subscription はメッセージングなしで実装できます。
この記事でうまく説明されているように、イベント ドリブン デザインを理解するには、イベント ドリブン デザインが示すものを見るのではなく、イベント ドリブン デザインが隠しているものを観察する必要があります。「コールスタック」。
イベント ドリブン設計では、メソッド呼び出しの定義は窓から出てきます。呼び出し元と呼び出し先はもうありません。それは、シーケンスと順序を呼び出すためのさようならのキスです。システムは、物事がどの順序で発生する必要があるかを知る必要はありません。したがって、Call Stack の前提条件である共有メモリ空間が不要になります。
ただし、呼び出しスタック環境では、呼び出し元は次に何が起こるかを知る必要があるだけでなく、機能をメソッド名に関連付けることができなければなりません。
メッセージ指向のアプリケーションでは、デフォルトで共有メモリが削除されています。パブリッシャーとサブスクライバーはメモリ空間を共有する必要はありません。一方、その他のすべての機能 (順序、メソッド名の結合など) は必須ではありません。
メッセージ パッシングがイベント ドリブン アーキテクチャの公理に準拠するように設計されている場合、それらは同一であると見なすことができます。そうでなければ、それらの間には大きな違いがあります。
イベント駆動型のアプローチを使用する場合、通常、このイベントでソース オブジェクト (イベントを発行したコンポーネント) を送信します。サブスクライバーでは、データだけでなく、誰がこのイベントを発行したかを知ることもできます。たとえば、モバイル開発では、ビューを受け取ります。ビューは、ボタン、イメージ、またはカスタム ビューです。このビューのタイプに応じて、サブスクライバーで異なるロジックを使用できます。この場合、バックプロセッシングを追加して、ソース コンポーネントを変更することもできます。たとえば、アニメーションをソース ビューに追加します。
メッセージ駆動型のアプローチを使用する場合、データを含むメッセージのみを公開したいと考えています。このメッセージを発行したサブスクライバーには関係ありません。データを受信して何らかの方法で処理したいだけです。