「メッセージパッシング」システムと「イベントベース」システムのメリット
私の質問はやや教育されていない視点から来ています。
" メッセージパッシング "システムと " イベントベース "システムの相対的なメリットは何ですか。
なぜ一方が他方を選ぶのでしょうか？彼らの長所と短所は何ですか？
「理論上」だけでなく「実際」についても知りたい。
編集：
特定の問題：
小規模なサービスとして動作するプラグイン可能なコンポーネントのシステムを構築したいと思います（それぞれが小さなタスクを実行したり、情報を提供したりします）。
サービスは次のことができます。
- あるサービスの出力が別のサービスへの入力の1つとして機能できるように階層化される
- 前の文で述べたように、特定の入出力関係がなくても、あるサービスを別のサービスに含めることができるように、包含階層があります。
システムの目標は、別のシステムの低レベルのイベントの単一のフローをより高いレベルの情報と機能に変換し、さらに、一連のイベントを提供する他のシステムに戻るチャネルを提供することです。
これで十分でない場合は、詳細を提供できます。
もう少し見てみました。 This および this は、おそらく私の状況をよりよく説明します。
これは私の状況に適しているようです： http://akka.io/
私の経験では、特定の唯一の違いは、ほとんどのメッセージパッシングシステムでは、メッセージの送信者がメッセージの受信者が誰であるかを認識している（そして多くの場合は宣言している）ことです。
そのため、送信者は、イベントを発生させ、イベントに参加している人がそれを取得する代わりに、目的の受信者または受信者の論理グループのIDを定義し、メッセージを直接送信するか、メッセージブローカーを経由します。 （ただし、OSはイベントベースのシステムではメッセージブローカーと見なすことができます）。
TelastynがC＃のイベントの実装について言及しているスレッド化のケースは明らかにありますが、異なるスレッドで実行する独自のpub/subモデルを作成することもできます。
これはリンゴとオレンジです：
イベントドリブンシステムは、イベントが発生したときにメッセージとして渡されたイベント（このコンテキストのメッセージは暗黙の不変非共有データ）に反応できます。これは純粋に建築デザインです。
メッセージパッシングシステムは、メッセージを作成して渡すイベントによって駆動にすることができます。これは純粋に実装設計です。
2つは相互に排他的ではありません。
例：イベント駆動デザインを任意の言語で実装できます。これは、Erlangのようなメッセージパッシング環境でもかまいません。
「メッセージパッシング」と「イベントベース」の間の混乱の多くは、アーキテクチャの詳細と実装の詳細に関係しています。私は、OSが提供するメッセージを実際に使用して実装するイベント駆動型システムを見てきました（そして記述しました）。あなたは本当に建築のアイデアに言及していると思います。
多くの人々がすでに「メッセージパッシング」と「イベントベース」はあいまいさを避けるのに十分な用語ではないと指摘しています。
「メッセージパッシング」システムと「イベントベース」システムの相対的なメリットは何ですか。
メッセージパッシング
まず、「メッセージパッシング」システムとは、1つのオブジェクトが他の特定のオブジェクトにメッセージを送信するシステムのことだと推測します。このパラダイムに基づくシステムについて考えるとき、私はより一般的に、何かを検出するオブジェクトが、何かについて語られる必要がある人を知っているシステムを考えます。 （私はそれがどのように知っているかを特定しているのではなく、それが知っているというだけです。）
このタイプのアーキテクチャは、プロデューサーとコンシューマーがよく知られているシステムに非常に適しています。メッセージのプロデューサーは、誰がメッセージを受信する必要があるかを知っているか、またはコンシューマーがメッセージを誰から受け取るかを知っている必要があります。
バンキングアプリケーションを作成している場合、トランザクションの送信先と送信元を本当に知りたいと思うでしょう。
イベントベース
「イベントベースの」システムと言ったときにあなたが考えていると思うもう1つのシステムは、オブジェクトが誰に（もしあれば）それに応答するかわからないまま、オブジェクトが「イベント」を発生させるシステムです。
このタイプのイベント駆動型アーキテクチャーは、プロデューサーが誰がイベントを消費するかを気にしないシステム、またはコンシューマーがイベントを生成した人を本当に気にしないシステムに非常に適しています。
一般に、これらのシステムは、コンシューマーとプロデューサーの関係がわからない場合や、関係が動的であると予想される場合に最適です。
私がこれを使用した1つのシステムは、アプリケーションが実行時に読み込まれる動的に構成されたモジュール（プラグイン）で実際に構成されているシステムでした。モジュールがロードされたとき、それはそれが気にかけたイベントに登録するでしょう。その結果、機能の拡張が非常に簡単なシステムが生まれました。
たとえば、通常は応答RAを引き起こした条件AがイベントEAを発生させたとします。応答RAの原因となったオブジェクトは、イベントEAを受信するように登録され、それが到着したときにアクションを実行しました。ここで、RA_1と呼ばれる新しい応答をEAに追加するとします。これを行うには、EAを検索して応答RA_1を生成する新しいオブジェクトを追加するだけです。
いくつかの例を示します（用語を使用して）：
- "メッセージパッシング"：上司からタイムシートに記入するように言われました。
- "イベントドリブン"：部門の秘書は、タイムシートの期限が今日であることを知らせる電子メールを全員に送信します。
SOAには、CommandメッセージとEventメッセージ。両方が必要です。
ただし、コマンドメッセージは、エンドポイントに何らかの機能を実行するよう明示的に要求しているため、受信側エンドポイントとの動作のカップリングが高くなっています。特定のエンドポイントに関連付ける必要はありません（これは、実行時に構成または決定できます）。
一方、イベントメッセージは、送信者が受信者がメッセージをどう処理するかわからないため、送信者と受信者の間に動作のカップリングはありません。 anyoneがイベントにサブスクライブしているかどうかもわかりません。
もう少し背景については、ここに私のサービスバスサイトをよく読んでください。 http://www.servicebus.co.za
私の経験では、2つの最大の違いは、メッセージパッシングシステムのメッセージはファーストクラスのオブジェクトであるのに対し、イベント駆動型システムのイベントははるかに単純です。メッセージは情報を運ぶ傾向があり、その情報は変換、保存、検索、再送信される場合があります。イベントは、すぐに消費されてから破棄される、より小さく焦点を絞った情報のビットを運ぶ傾向があります。メッセージはイベントソースから1つ以上のイベントシンクに直接送信される傾向がありますが、メッセージは複数のレシーバー間でルーティングされることが多く、ルートに沿った任意のポイントで変換/変換/ラップまたはその他の方法で処理されます。それらは同様の技術（バス、キュー、フィルターなど）を使用しますが、実際には異種の獣です。
実用的な観点から見ると、メッセージは通常、送信者のアドレススペースから受信者のアドレススペースにコピーされるメモリのブロックとして実装される（または、変更できないオブジェクトとして強制される）ため、すぐにスレッドセーフになります。
送信者がメッセージを渡す場合、受信者を指定する必要がある場合もありますが、メッセージをメールボックスに投稿するだけで、誰でもそのメールボックス内のメッセージを聞くことができる場合もあります。もちろん、契約が「このイベントが発生したときに、このメールボックスにメッセージを投稿します。」というメールボックスを持つことができます。
イベントの場合、デリゲートまたはコールバックをイベントの所有者に登録します。オブジェクト指向プログラミングでは、これは、イベントの所有者が、イベントを受け取るために登録されたオブジェクトへの参照を保持することを意味します。これにより、イベントハンドラーの登録を解除するのを忘れたオブジェクトを特定しようとする、簿記の悪夢につながる場合があります。これは、ターゲットが何も役に立たなくなった場合でも、イベント所有者がガベージコレクションを実行するまで、ターゲットをガベージコレクションできないことを意味します。
個人的には、Windows GUIプログラミングなど、イベントがユーザーに強制される場合を除いて、イベントを渡すメッセージを選択します。