.NETからアクセス可能な恒久サブスクライバを実装するためにどの技術を使用する必要がありますか？

Question

グリーンフィールドプロジェクトを想定すると、テクノロジ、ライブラリ、ミドルウェアなどの選択によって、Windowsおよび.NET上の永続サブスクリプションでパブリッシュ/サブスクライブメッセージングを実装するのが最も簡単になります。 Googleを使ってWCF Peer Channelを見つけましたが、これは私が必要とするものの大部分を占めるようですが、メッセージの順序付けを保証するものではなく、メッセージをディスクに残して信頼性を確保するものでもありません。マイクロソフトでは、これらの機能を上に重ねることができると述べていますが、私は既にその機能を備えているものを探していました。

MSMQの配布リストは私が望むものに近いものですが、メッセージングレイヤーがすべてのクライアントを知っている必要のないものを好むでしょう。

加入者数は、おそらく20未満

両方パブリッシャとサブスクライバは、C＃/。NETで実装し、Windows上で実行されている、大規模ではありません。

EDIT：私は、メッセージ指向のミドルウェアとサービスバスの提案を検討しています。私はこの分野のエンタープライズ向け製品に精通しています。シンプルで軽量なものを探しています。各製品を見るにはしばらく時間がかかりますが、私は自分の所見を要約しようとします。

Answer 1

私はこれと同じことをしました（パブリッシャーとコンシューマーはC＃on .NETで）。これは永続的なサブスクリプションが多数あり、実際にはこれを使用しました。 JMSプロバイダとして請求されますが、例外的にうまく機能するJMS APIと非常によく似た純粋な.netクライアントライブラリを持っています。

私はRabbitMQに非常に精通しており、ブローカのメモリ領域を使い果たした場合、永続的なサブスクリプションをサポートしていません（実際にディスクに流すことはできません）。メッセージフロー（プロデューサとコンシューマ）がすべてメモリに収まる場合には優れたソリューションですが、永続的な永続サブスクリプションシステムが必要な場合には適していません。

このプロジェクトの一環として、ActiveMQ、Tibco EMS、FioranoMQを評価しました.SonicMQは、特にC＃クライアントにとって、遠く離れた最高のソリューションでした。高価ですが、見る価値があります。

Answer 2

あなたはRabbitMQを見ましたか？私は自分自身の経験を持っていたとは言えませんが、うさぎの人が仕事で技術的な話をしたとき、彼らは話していたことを知っているようでした:)

Answer 3

メッセージバスタイプのアーキテクチャを見てみるとどうなりますか？そこにMSMQの上に座っていくつかのオープンソースのバスの実装があります。それが必要な時はいつでもあなたのサービスは、 "イベント"（メッセージ）を発行することができ、これらのライブラリのいずれかを使用してMassTransit

Rhino Service Bus

NServiceBus

• 。起動時に、サーバーは事前にクライアントに関する情報を設定する必要はありません。クライアントは開始されると、既知のサーバーエンドポイントに加入し、そこからサーバーはメッセージを発行するたびにサーバーを公開します。

Answer 4

Apache ActiveMQは.NET（および他の多くの言語）もサポートしています。オープンソースであり、商業的サポートも提供されています。

http://activemq.apache.org

簡単にセットアップおよび構成します。 メッセージ宛先の自動作成。 ピアツーピアおよびパブリッシュ/サブスクライブの通信モデルをサポートします。

Answer 5

ZeroMq（トランスポート）、Cassandra（ピア発見と永続性）、Protobuf（シリアル化）に基づいて、ピアツーピアメッセージバスZebusを作成しました。

これはオープンソースと生産が

Zebusが活発に開発されており、それが重い、社内の生産使用しているhttps://github.com/Abc-Arbitrage/Zebusをテストしています。