そして、何かありますか？私にとって、MBはサブスクライバーとパブリッシャーの両方を知っており、メディエーターとして機能し、サブスクライバーに新しいメッセージを通知します（事実上「プッシュ」モデル）。一方、MQは、コンシューマーがメッセージをキューからプルする「プル」モデルに近いものです。

私はここで完全に軌道に乗っていないのですか？

私はいくつかのモジュールで構成され、それらが互いに情報を共有することを要求するアプリケーションに取り組んでいます。例：モジュールがいくつかの情報（状態変数など）をパブリッシュし、特定の情報に関心のあるモジュールがそれを取得するパブリッシュ/サブスクライブシナリオ。または、関心のあるモジュールが情報について明示的に質問し、回答を得た要求/応答シナリオ。

私はさまざまなメッセージバスの実装、つまりD-bus、ØMQ、RabbitMQ、およびQPID（後者の2つはAMQPに基づいています）を調査してきました。しかし、誰かが、複雑で重いメッセージバスの実装を試す代わりに、問題を解決するために単にマルチキャストを使用しないのはなぜかと指摘しました。

マルチキャストが私の問題を本当に解決できるかどうかを確認し、2つのソリューションの長所と短所を理解するための経験が不足しているので、専門家に助けを求めたいと思います。よろしくお願いします。

最近、私は分散型メッセージングとそれに関連するパターンについて多くのことを読んでいます。たとえばNServiceBusなどのツールでサポートされているものをいくつか使用しました。

それらのパターンの多くは、インターネット上で説明されています。私が最近読んだそれらのいくつかは次のとおりです。

• メッセージ ブローカー: http://msdn.microsoft.com/en-us/library/ff648849.aspx
• メッセージ バス : http://msdn.microsoft.com/en-us/library/ms978583.aspx
• SOA のメッセージング パターン: http://msdn.microsoft.com/en-us/library/aa480027.aspx
• 相違点に関する Udi Dahan の投稿 : http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences/

NService バスなどのツールを使用すると、インフラストラクチャの問題についてあまり考えずに多くのことを実行できる場合、基本的なメッセージ バスとコマンド ハンドラーを実装しようとしたときに、いくつかの疑問が生じました。実際、これらのパターンに関しては、それらの間に多くの違いは見られません。

長いのでコードは貼りませんが、私が話したい実装のアイデアをよく説明している 2 つのブログ投稿を見つけました。

• メッセージバス : http://brentedwards.net/2010/04/13/roll-your-own-simple-message-bus-event-aggregator/

アイデアは単純です。メッセージ バスはサブスクライバーを追跡し、関心があれば別のサブスクライバーにメッセージをディスパッチします。

• コマンド ハンドラー: http://weblogs.asp.net/shijuvarghese/archive/2011/10/18/cqrs-commands-command-handlers-and-command-dispatcher.aspx

メッセージバスによく似ています。コマンド バスは、特定のコマンド タイプのコマンド ハンドラを呼び出します。

したがって、どちらの場合も類似点があります。

あるパターンを別のパターンと使用した場合の実際の違いと利点は何ですか (ツールのサポートについて話しているのではありません)。何が欠けていますか？

2番目の質問はです。サポートツールなしでメッセージバスは価値がありますか? すべてのテナントへのサポートを単独で推進するつもりはありません。

長くて紛らわしい質問で申し訳ありませんが、詳細については遠慮なくお尋ねください。

私は、OSGi サービスに基づく、カスタムメイドのテクノロジのより大きなセットに基づく主要なソフトウェア システムを移行するプロジェクトの最中です。このためには、OSGi サービスとうまく連携するある種のメッセージ バスが必要になるでしょう。

• 同期および非同期配信
• ポイントツーポイントのみ
• 保証された配信 - ファイルを介した永続性が望ましい
• 同じクライアント (非同期モード) から注文された厳密なメッセージですが、異なるクライアントから注文する必要があります
• プロセス間およびノー​​ド間のサポートは適切ですが、厳密には必須ではありません

オープン ソース ソリューションが優先されますが、必須ではありません。

私はイベントバスを見てきました（https://stackoverflow.com/a/1953453/796559で推奨されているように）が、うまく機能していないようです。

問題は、どのテクノロジーが上記に一致するかということです。

2 つの Python オブジェクトが通信できるメッセージ バス フレームワークが必要です。使用できる既存のフレームワークにはどのようなものがありますか? この時点で DBus はやり過ぎだと思います (外部デーモンを使用する必要があります)。

私は現在、レールプロセスと複数のワーカープロセスを備えたアーキテクチャを構築しています。これらのプロセスには、特定のイベント（オブジェクトの作成など）を通知する必要があります。

次のことをしたい

プロセス（API、ワーカー、デーモンなど）がメッセージバスにサブスクライブしている間、メッセージが着信するとブロックが呼び出されます。

現在、ローカルのUNIXドメインソケットを使用しており、JSONをでプッシュしUNIXSocketて取得しEventMachine.start_unix_domain_serverます。しかし、それは双方向のコミュニケーションしか許しません。resqueの使用も考えましたが、これはバスが必要なときのメッセージキューです。そしてそれはredisに依存します。ルビーにメッセージバスを実装する宝石があるはずですが、グーグルしても結果は得られませんでした

私は非常に大きなアプリケーションを構築することを計画しています (機能ではなく、同時ユーザー/リクエスト数の点で大きい)。

基本的に、コマンドが実行されるのを待っているサービスをどこかに用意し、後で完了を確認します。このサービスはサービス バスを使用して通信し、確認メッセージが発行される前に実行を最終的に行います。

このサービスのコンシューマーは、あらゆる種類のアプリケーション (WPF、SL、...) にすることができますが、私のメイン (および最初の) クライアントは、asp.net MVC アプリケーション + WebApi (.Net 4.5) または MVC のみ (.Net 4.0 ) ajax コントローラー アクションを使用します。

Web アプリケーションは、Ajax 呼び出しに依存して、ユーザー フレンドリーな応答性の高いアプリケーションを維持します。

私はこのような完全な非同期アーキテクチャにまったく慣れていないため、将来の頭痛の種を避けるためにいくつか質問があります。

• 私の Web API 呼び出しには時間がかかる場合があります。長時間実行される操作 (ある種の非同期?) をサポートするために、API を適切に設計するにはどうすればよいですか? 新しい async キーワードについて読んだことがありますが、知識のために、背後にあるものを理解したいと思います。
• サービスへの私の呼び出しは、メッセージを公開し、ack メッセージを待つことで構成されます。これを単一のメソッドにラップする場合、このメソッドをどのように記述すればよいですか? ACK を受信するまで「ブロック」する必要がありますか (すべきではないと思います)。Task オブジェクトを返して、消費者に決定させるべきですか?
• また、SignalR が役立つかどうかも疑問です。signalR を使用すると、実際の「ファイア アンド フォーゲット」コマンドを発行して、クライアントにルーティングしてメッセージを確認できると思います。
• 私は完全に話題から外れていますか?別のアプローチを取るべきですか?

実装の詳細/フレームワークに関しては、次を使用すると思います。

• メッセージング システムとしての Rabbitmq
• メッセージング システムを抽象化する Masstransit
• UIを構築するためのasp.MVC 4
• コマンド発行をUIコントローラーから分離し、他の種類のクライアントがコマンドを発行できるようにするWebapi

私のシステムは、個別のハンドラーでコマンドパターンを使用しています。私のコマンドは、現在処理中のすべてのコマンドを処理するCommandServiceで実行されます。

遅い操作であるこれらのことの少なくとも1つを実行する特定のコマンドがあります：

1. メールを送信します
2. PDFを生成します
3. ファックスを送信します
4. サードパーティのWebサービスと対話します

UIがよりスッキリするように、これらのコマンドをすべてアウトプロセスで処理する必要があります。

これらのコマンドだけにメッセージングバスを使用する必要がありますか、それともインプロセスコマンドハンドラーを呼び出す必要がありますBeginInvoke()か？

編集-追加情報

システムのユーザー数は少ないため（忙しい日に同時に100人になる可能性があります）、キューが長くなることはほとんどありません。ここでの主なことは、PDFが添付された電子メール（問題のコマンド）を送信するときにUIがブロックされる時間を短縮することです。従業員はそのコマンドを1日に何度も実行する必要があります。

BeginInvoke()全体的な状況を念頭に置いて、私はいくつかの理由で今のところ行くつもりだと思います：

1. コマンドが成功したかのように動作することを確認するには、すべてのUIインタラクションに触れる必要があります。「このドキュメントを送信する必要があります」というリマインダーはUIの複数の場所にあり、レポートが送信されるとページ全体が更新されます。
2. クライアントの忙しい季節の真っ只中です（夏には年間ビジネスの50％以上を行っています）。そのため、現時点では、管理に慣れていないまったく新しいインフラストラクチャを導入するのは賢明ではないようです。 。

しかし、私が今知っていることを知っていると、新しいシステムでは、遅いコマンドには最初からサービスバスを使用し（事実上すべてのシステムが電子メールを送信する必要があります）、コマンドを同期からより簡単に切り替えることができるようにUIを設計します非同期処理に。実装では、これは基本的にすべてのPOSTがAJAXであり、成功したかのようにUIでアクションを実行することを意味します。（この例については、Facebookがコメントを処理する方法を確認してください。）

メッセージバスの使用に関するLiferayドキュメント6.1に書かれています。

メッセージ バスの構成は、次のファイルを使用して行われます。 WEB-INF/src/META-INF/messaging-spring.xml - 宛先、リスナー、および相互のマッピングを指定します。プラグインのデプロイメント記述子の。このファイルの Spring 構成のリストに、messaging-spring.xml を必ず追加してください。

message-spring.xml は web.xml にどのようにリストされますか?

私はこれを試しました

しかし、Tomcatはログに記録しました

org.apache.catalina.core.standardcontext 開始重大エラー リスナー開始

そして、私が削除したとき

tomcat がログに記録されました

コンテナ org.apache.catalina.core.ContainerBase.[Catalina].[localhost]. 開始されていません

メッセージバスを試してみたいだけで、メッセージを送信するときにリスナーを呼び出すことができません

私はLiferay 6.0.5で開発しています助けてくれてありがとう

message / event / servicebusを使用して外部システムにメッセージを渡したい場合、Node.JSはまったく初めてです。Nodeとうまく統合できる代替手段はありますか？

メッセージは単なるJSON文字列であり、外部システムはC＃エージェントなどの任意のものにすることができます。

（多分これはプログラミングよりも技術的な質問なので、stackoverflow以外のサイトクルーザーの他の部分にあるはずです）？