「メッセージパッシング」システムと「イベントベース」システムのメリット

私の質問は、いくぶん教育されていない視点から来ています。

「メッセージパッシング」システムと「イベントベース」システムの相対的なメリットは何ですか。

なぜ一方が他方を選択するのですか？彼らの長所と短所は何ですか？

「理論的に」だけでなく、「実際に」も知りたいです。

編集：

特定の問題：

小規模なサービスとして動作するプラグ可能なコンポーネントのシステムを構築したい（それぞれが小さなタスクを実行したり、情報を提供したりする）。

サービスは次のことができます。

• 1つのサービスの出力が別のサービスへの入力の1つとして機能できるように階層化される
• 前の文で述べたように、特定の入出力関係がなくても1つのサービスを別のサービスに含めることができるように、包含階層があります。

システムの目標は、別のシステムの低レベルイベントの単一のフローを高レベルの情報と機能に変換し、さらに単一のイベントを提供する他のシステムへのチャネルを提供することです。

これで十分でない場合、詳細を提供できます。

もう少し見て回った後。これとこれはおそらく、より良い私の状況を説明しています。

これは私の状況に適しているようです：http : //akka.io/

私の経験では、唯一の特定の違いは、ほとんどのメッセージパッシングシステムで、メッセージの送信者がメッセージの受信者が誰であるかを認識している（そしてしばしば宣言している）ことです。

そのため、イベントを発生させてイベントに参加している人にイベントを通知する代わりに、送信者は目的の受信者または受信者の論理グループのIDを定義し、メッセージを直接送信するか、メッセージブローカーを経由します（ただし、OSはイベントベースのシステムではメッセージブローカーと見なすことができます）。

TelastynがC＃のイベントの実装で言及しているスレッド化のケースがありますが、異なるスレッドで実行する独自のpub / subモデルを作成できます。

これはリンゴとオレンジです：

イベント駆動型システムは、イベントが発生すると、メッセージ（このコンテキストのメッセージは不変の非共有データを意味します）として渡されるイベントに反応できます。これは、純粋なアーキテクチャ設計です。

メッセージパッシングシステムは、メッセージを作成して渡すイベントによって駆動できます。これは純粋な実装設計です。

2つは相互に排他的ではありません。

例：イベント駆動設計は、Erlangのようにメッセージパッシング環境でもある任意の言語で実装できます。

「メッセージパッシング」と「イベントベース」の混乱の多くは、アーキテクチャの詳細と実装の詳細に関係しています。OSが提供するメッセージを実装するためのメッセージを実際に使用するイベント駆動型システムを見てきました（そして記述しました）。あなたは本当に建築のアイデアに言及していると思います。

多くの人がすでに「メッセージパッシング」と「イベントベース」を指摘しているように、あいまいさを避けるのに十分な用語ではありません。

「メッセージパッシング」システムと「イベントベース」システムの相対的なメリットは何ですか。

メッセージの受け渡し

まず、「メッセージパッシング」システムと言うとき、あるオブジェクトが特定の他のオブジェクトへのメッセージを費やすシステムについて話していると思います。このパラダイムに基づいたシステムを考えるとき、より一般的には、何かを検出するオブジェクトが、誰かに何かを伝える必要があることを知っているシステムを考えます。（私はそれが知っている方法を指定しているのではなく、知っていることだけを指定しています。）

このタイプのアーキテクチャは、生産者と消費者がよく知られているシステムに非常に適しています。メッセージのプロデューサーは、誰がメッセージを受信する必要があるかを知っているか、または消費者はメッセージの送信元を知る必要があります。

銀行のアプリケーションを作成している場合、トランザクションの送信者と送信者を本当に知りたいと思うでしょう。

イベントベース

「イベントベース」システムと言うとき、あなたが考えているもう一つのシステムは、誰が（誰でも）応答するかを知らずにオブジェクトが「イベント」を発生させるシステムです。

このタイプのイベント駆動型アーキテクチャは、プロデューサーがイベントの消費者を気にかけないシステムや、消費者がイベントの生成者を気にしないシステムに非常に適しています。

一般に、これらのシステムは、消費者と生産者の関係がわからない場合や、関係が動的であると予想される場合に最適です。

これを使用したシステムの1つは、実行時にロードされた動的に構成されたモジュール（プラグイン）でアプリケーションが実際に構成されたシステムでした。モジュールがロードされると、そのモジュールは関心のあるイベントを登録します。その結果、機能を非常に簡単に拡張できるシステムができました。

たとえば、条件AでイベントEAが発生し、通常は応答RAが発生したとします。応答RAを引き起こしたオブジェクトは、イベントEAを受信するために登録され、到着したときにアクションを実行しました。ここで、RA_1と呼ばれる新しい応答をEAに追加するとします。これを行うには、EAを探して応答RA_1を生成する新しいオブジェクトを追加するだけです。

以下にいくつかの例を示します（用語を使用）：

• 「メッセージの受け渡し」：上司からタイムシートに記入するように指示されます。
• 「イベント駆動型」：部門長官が全員にメールを送信し、今日のタイムシートが期限であることを通知します。

SOAには、コマンドメッセージとイベントメッセージの概念があります。両方が必要です。

ただし、コマンドメッセージは、エンドポイントに何らかの機能を実行するよう明示的に要求しているため、受信者エンドポイントとのより高い動作結合を持っています。特定のエンドポイントに関連付ける必要はありません（これは実行時に構成または決定できます）。

一方、イベントメッセージには、受信者がメッセージをどう処理するかわからないため、送信者/受信者間の動作のカップリングがありません。誰かがイベントにサブスクライブしているかどうかさえ知りません。

さらなる背景については、こちらのサービスバスサイトをご覧ください：http : //www.servicebus.co.za

私の経験では、両者の最大の違いは、メッセージパッシングシステムのメッセージはファーストクラスのオブジェクトであるのに対して、イベント駆動型システムのイベントははるかに単純であることです。メッセージには情報が含まれる傾向があり、その情報は変換、保存、取得、および再送信されます。イベントは、より小さく、より焦点を絞った情報を運ぶ傾向があり、すぐに消費されてから破棄されます。メッセージはイベントソースから1つ以上のイベントシンクに直接送信される傾向がありますが、メッセージは多くの場合、複数の受信者間でルーティングされ、ルート上の任意のポイントで変換/変換/ラップまたはその他の方法で処理されます。彼らは同様の技術（バス、キュー、フィルターなど）を使用しますが、実際には異種の獣です。

実用的な観点から、メッセージは通常、送信者のアドレス空間から受信者のアドレス空間にコピーされる（またはそうでなければ不変オブジェクトに強制される）メモリブロックとして実装されるため、すぐにスレッドセーフを取得できます。

メッセージを渡す場合、送信者は受信者を指定する必要がありますが、他の場合では、メールボックスにメッセージを投稿するだけで、誰でもそのメールボックス内のメッセージをリッスンできるため、それらがどれほど緊密に結合されているかについてある程度の柔軟性があります。もちろん、契約が「このイベントが発生したときにこのメールボックスにメッセージを投稿します」というメールボックスを持つことができます。

イベントの場合、イベントの所有者にデリゲートまたはコールバックを登録しています。オブジェクト指向プログラミングでは、これは、イベントの所有者が、イベントを受信するために登録したオブジェクトへの参照を保持することを意味します。これにより、イベントハンドラの登録解除を忘れたオブジェクトを把握しようとして、簿記の悪夢につながる場合があります。これは、ターゲットが有用なことを行っていない場合でも、イベント所有者がガベージコレクションされるまでターゲットをガベージコレクションできないことを意味します。

個人的には、Windows GUIプログラミングなど、イベントがユーザーに強制される場合を除き、イベントを通過するメッセージを選択します。